cadrage d'un projet d'app mobile

Avant d’entamer les développements d’une application mobile, il est nécessaire de s’assurer de la bonne compréhension des besoins du client. C’est lors de la phase initiale d’un projet, appelée phase de cadrage chez DzMob, et via un ensemble d’outils méthodologiques que le chef de projet valide sa bonne compréhension des besoins du client et de sa vision précise du projet.

Mais avant la phase de cadrage, il y a d’abord, comme nous le demandons souvent à nos prospects, la rédaction dans un document appelé « cahier des charges » de la liste des fonctionnalités souhaitées dans l’application. « Afficher les catégories de produits sur l’écran d’accueil » ou « Pour une catégorie donnée, afficher la liste des produits » sont deux exemples de fonctionnalités sur une application type m-commerce.
C’est ce document qui nous permettra d’établir un 1er chiffrage estimatif (qui servira d’ailleurs de pré-cadrage).

Une fois projet entamé, voici les différentes phases de cadrage :

1) Réunions :

Les 1ère réunions sont la 1ère brique de la phase de cadrage. Pour la fonctionnalité Afficher les catégories de produits sur l’écran d’accueil, un ensemble de questions ouvertes puis de questions fermées (stratégie de l’entonnoir) permettront de définir précisément le besoin du client et d’avoir une vision très claire et sans ambiguïté de l’écran d’accueil de l’application.

Un exemple de questions :

  1. Comment voyez-vous cet écran d’accueil ? Laisser parler le client ensuite.
  2. Vos catégories sont-elles amenées à changer ? à quelle fréquence ? La réponse à ces questions implique de développer soit une API ou de stocker les catégories sur le smartphone.
  3. Combien de catégories auriez-vous à peu près ? Combien au maximum ? La même question mais formulée différemment de façon délibérée pour faire “plus parler” le client. Les différentes réponses possibles ont des conséquences : intégrer une pagination par exemple etc…
  4. Voudriez-vous afficher les catégories si l’utilisateur n’est pas connecté à internet ? Qu’affiche-t-on sinon ?
  5. Quelles informations d’une catégorie souhaitez-vous que l’utilisateur voit ? Laisser parler d’abord puis enchaîner avec des questions fermées pour l’orienter : image ? titre ? description ? …

Les questions ci-dessus ne sont pas exhaustives mais donnent un aperçu de la discussion à avoir sur chaque fonctionnalité. Le besoin précis du client sera de plus en plus clair au fur et à mesure de l’échange.
À la fin, il est important de reformuler notre échange et compréhension de cet écran d’accueil au client en étant le plus explicite possible et en évoquant les différentes hypothèses.
Attention à ne pas supposer que tel ou tel point ne nécessite pas de reformulation, les futurs points d’incompréhension ou de divergences commenceront peut-être là.
Une fois que tout est ok, on peut passer à une étape plus concrète : les mockups.

2) Wireframe / Design / mockups / UI & UX :

Étape plus concrète et plus palpable surtout, le design de l’écran en question. ça peut être du wireframing ou des mockups directement. Le wireframing permettra de dessiner l’écran tel que discuté pour que le client ait une vision plus concrète, puis de valider la disposition des éléments (boutons, images…), le choix des couleurs (avec les mockups), le wording…

A cette étape, le client commence à être rassuré car son besoin commence à être traduit réellement en application. Bien sûr, des allers-retours entre le client et le chef de projet vont s’opérer éventuellement jusqu’à aboutir à l’écran tel qu’imaginé par le client. Ce processus d’allers-retours est bien naturel. Ce n’est pas forcément du 1er coup que la maquette correspond parfaitement à la vision du client.

Il est à noter qu’au delà du design de chaque écran séparément, c’est à cette étape que la parcours utilisateur au sein de l’application est discuté, conçu puis validé.

3) Spécifications fonctionnelles détaillées :

La fonctionnalité est claire pour le client et le prestataire, le design validé par le client. Il ne reste qu’un point, expliquer toutes les interactions possibles sur l’écran en question et les faire valider par le client.

L’exemple le plus pertinent est l’écran login d’une application :

  • Que se passe-t-il si je clique sur se connecter sans saisir l’email ou le mot de passe ?
  • Que se passe-t-il si je saisi un email erroné ? un mot de passe erroné ?
  • Si je clique sur le bouton se connecter mais que je ne suis pas connecté à internet, que se passe-t-il ?

Le document de spécifications fonctionnelles détaillées permet de prendre le temps de réfléchir, de poser et de répondre à toutes les questions non encore abordées lors des 1ères réunions et qui ne sont pas visibles dans le design. Il permet surtout de formaliser par écrit tous les scénarios.
Les spécifications de chaque fonctionnalité seront suivies par un échange, des allers-retours avec éventuellement des modifications puis une validation par le client. Si toute l’étape de login par exemple est cadrée, nous pouvons lancer son développement.

Il est à relever que la qualité des spécifications fonctionnelles influera grandement sur la qualité du livrable final (de l’application mobile). L’exigence dans leur rédaction est un point clé.

4) Validation ?

Toutes les fonctionnalités ont été discutées, le design de toute l’application (et éventuellement le backoffice) a été validé, les spécifications fonctionnelles ont été soumises, discutées puis validées. Le développement peut être lancé et les développeurs ont la matière nécessaire pour avancer.

Chez DzMob et vu la durée moyenne des projets qui varie entre 3 et 4 mois en moyenne, la phase de cadrage concerne en général tout le projet. Cette phase peut concerner uniquement un sprint et une partie seulement d’une application dans le cadre d’une démarche agile et un projet découpé. Dans tous les cas de figure et même après le lancement des développements, des livraisons régulières (toutes les 2 semaines par exemple) permettent de rassurer le client sur son application mais aussi, aider à soulever des remarques ou questions non évoquées lors de la phase de cadrage.
Il est toujours préférable de repérer les manquements ou incohérences tôt dans un projet.

Conclusion :

La phase de cadrage nécessite du chef de projet un bon relationnel pour faire sortir les idées, les questions mais aussi une maîtrise de la stratégie de l’entonnoir pour faire avancer les discussions dans un but précis. La connaissance du mobile est évidemment très importante pour orienter les échanges et être force de proposition. Enfin, le niveau de détails des besoins du client est une aide non négligeable à la réussite de cette phase déterminante.

Laissez un commentaire