Nous rencontrons beaucoup d’entreprises, tout secteur confondu, pour lesquelles la mise en œuvre d’une application mobile Métier n’est plus une option. Cependant, elles sont aussi très nombreuses à s’interroger sur le meilleur moyen d’y parvenir. Car beaucoup de questions se posent, telles que :
- Comment s’assurer que les utilisateurs concernés soient engagés dans le projet et s’approprieront ce nouvel outil de travail ?
- Et même si les utilisateurs sont parties prenantes du projet, comment être sûr de concilier Réponse à leurs besoins « immédiats » et Durée des développements ?
- Aura-t ’on le budget pour répondre à leurs besoins (l’exhaustivité de certains cahiers des charges pouvant en effet refroidir les donneurs d’ordre) ?
- Le ROI sera-t-il à la hauteur de l’investissement consenti ?
- Comment faire pour convaincre en interne de la viabilité du projet ?
- Etc.
3 approches, qui ont déjà fait leur preuve dans le secteur industriel (et dans nombre de startups en recherche de financement), permettent d’aller rapidement de l’idée au produit, sans engager de budget trop conséquent et en minimisant les risques.
Il s’agit du Prototypage, du POC (Proof Of Concept ; preuve de concept) et du MVP (Minimum Viable Product). Si ces 3 approches ont en commun de permettre de tester une idée avant de se lancer dans le développement d’un cahier des charges conséquent, elles n’en ont pas moins des spécificités et des objectifs différents.
Dans cet article, nous vous expliquons quelles sont ces spécificités et nous vous indiquons sur quels critères vous appuyer pour choisir l’une ou l’autre de ces approches.
Prototype, POC, MVP : de quoi parle-t-on ?
Le prototype : une maquette plus ou moins aboutie, ne nécessitant pas de développement
Un prototype est un moyen de sonder rapidement le besoin des utilisateurs et de recueillir leur perception de l’application mobile (sa facilité d’usage, son objectif, son intérêt…) sans engager de développement. Il présente le parcours utilisateur sur une fonctionnalité majeure de l’application, permettant ainsi aux utilisateurs de visualiser les enchainements d’écran et de se mettre d’accord sur le parcours, avant d’avancer plus en profondeur dans la réflexion.
En réalité, le prototypage peut être réalisé de manière plus ou moins détaillée, et s’appuyer sur :
- Un Storyboard : dans ce cas, il s’agira d’une représentation graphique simple de la manière dont l’appli va fonctionner (cinématique de l’application décrivant le parcours utilisateur) ;
Des Wireframes (« fil de fer » en anglais) : ici, cela consiste à représenter de manière simple et visuelle (filaire) l’interface, ce qui permet d’indiquer, pour un écran de votre appli mobile, les différentes zones et les différents types de contenus qu’elles contiennent, les fonctionnalités offertes et l’ergonomie. Ces wireframes peuvent s’esquisser à la main ou à l’aide de logiciels spécialisés ;
Un Mockup (« maquette » en anglais) : il s’agira alors d’un prototype animé ou non (incluant la palette de couleurs, les différents blocs, boutons, interactions, visuels…), permettant aux futurs utilisateurs de visualiser l’application mobile, directement sur leur smartphone ou leur tablette, avant même que les développeurs n’aient commencé à travailler. Ce prototype comprendra des éléments cliquables qui simulent le fonctionnement de l’appli.
À titre d’exemple, nous avons récemment prototypé une appli à destination de techniciens de maintenance pour la société Accès Industrie. Ce prototype s’appuyait sur des mockups simulant une fonctionnalité majeure de l’application (une « kealer feature »), dont on pensait que les utilisateurs ne pourraient pas se passer. Le prototype imitait donc le parcours utilisateur sur cette fonctionnalité et permettait à la personne qui le manipulait de se projeter dans l’usage Métier concerné. Découvrez ici le témoignage d’Accès Industrie à ce sujet :
À l’issue du test réalisé, le retour des utilisateurs peut donner lieu à l’ajustement de la fonctionnalité décrite et permet de préciser les spécifications fonctionnelles de l’application. Dans le cas d’Accès Industrie, le test validé du prototype a donné lieu au développement d’un MVP.
Le POC : valider rapidement la faisabilité technique d’un point clé de l’appli
Le POC ou Preuve de Concept, consiste à tester rapidement et en « grandeur nature » un élément technique essentiel de l’appli, de manière à valider sa faisabilité ; ou de lever un doute par rapport à l’usage de l’application mobile.
Si votre application mobile comporte un risque technique (par exemple, en matière de connectivité, ou d’échanges de données s’il s’agit d’objets connectés…), si son fonctionnement est tributaire de paramètres que vous ne maitrisez pas, alors il est recommandé de faire un POC.
En résumé, faire un POC nécessite donc d’avoir en tête un objectif précis ; le test permettra de mesurer si cet objectif est atteint ou pas, avant d’entreprendre le développement d’une V1 de l’appli. Si le POC échoue, c’est l’occasion pour vous de revoir votre projet sans avoir dépensé trop d’argent à ce stade.
Donc, Prototype et POC se situent à l’étape 0 d’un projet ; ils peuvent se mettre en œuvre à la suite (ou en parallèle) d’un atelier de cadrage fonctionnel qui permet de définir les objectifs du test sur le terrain. Si l’enjeu est de valider l’adhésion du public cible de votre appli, en lui donnant une première idée de ce que pourrait être l’expérience utilisateur, alors le prototype est une bonne solution. En revanche, si vous souhaitez valider la faisabilité technique d’une fonctionnalité majeure de l’appli, le POC est recommandé. Enfin, vous l’aurez compris, le prototype comme le POC ne sont pas des produits exploitables, à la différence du MVP dont nous allons parler maintenant. Il est cependant intéressant de noter que si le test « sur le terrain » de votre prototype ou de votre POC s’avère positif, vous pouvez poursuivre la démarche en développant un MVP.
Le MVP : Une version minimum de l’appli, s’inscrivant dans une démarche Agile
Le Minimum Viable Product (MVP) d’une application mobile correspond à la version 1 de l’appli, répondant à un besoin essentiel de l’utilisateur, tout en demandant un minimum d’effort en développement. À la différence du Prototype et du POC, il s’agit donc d’une version fonctionnelle.
Pour définir le périmètre fonctionnel du MVP, on fait le choix de « sacrifier » des fonctionnalités jugées comme non prioritaires, afin d’obtenir un lancement plus rapide et moins coûteux. Si un prototype ou un POC a été réalisé suite à un atelier de cadrage en amont du développement, cette maquette peut être utilisée pour le développement de cette V1 minimum. Les fonctionnalités jugées moins prioritaires seront développées dans un deuxième temps, si le MVP est validé.
Suite à son lancement, vient donc une phase d’écoute et d’interview des utilisateurs afin de recueillir leur perception. À l’issue de cette phase, soit le test est invalidé et on clôture l’expérience ; soit il est validé et on itère (au sens Agile du terme) pour développer les autres fonctionnalités et évolutions de l’appli.
Le MVP permet de réduire le Time to Market de l’appli (c’est-à-dire le temps de mise à disposition de l’appli auprès de son public ou sur le marché) et s’inscrit dans une démarche itérative. Il offre la possibilité de ne pas partir sur un temps trop long de développement et de cultiver l’engagement des utilisateurs en allant crescendo dans le projet.
A titre d’exemple, nous avons récemment conçu le MVP d’une solution de gestion de l’inspection d’infrastructures industrielles complexes (Evolis) et nous l’avons mis entre les mains d’inspecteurs, en situation sur une plateforme pétrolière. Les problématiques auxquelles ce MVP devait apporter des réponses étaient que le temps passé à la réalisation des rapports d’inspection des infrastructures était très long et que leur qualité pourrait être grandement améliorée en fiabilisant les informations recueillies et en normalisant le reporting. Lors du test réalisé in-situ, les inspecteurs ont pu mesurer tous les bénéfices que la future solution pourrait leur apporter, mais aussi suggérer des améliorations liées aux contraintes de leur environnement de travail. Au MVP de l’application tablette, était d’ailleurs associé un prototype de l’application Backoffice permettant de comprendre comment les tâches de validation s’articulaient. Si aucun échange de données n’était bien sûr possible entre les deux applications à ce stade du test, celui-ci a permis de concrétiser les interfaces et le process.
En provoquant un effet « waou », le MVP génère une attente et un engagement immédiat des utilisateurs. En itérant rapidement sur des évolutions de l’appli prenant en compte les remontées des utilisateurs, on maintient cet engagement sur la durée.
Prototype, POC ou MVP : quels bénéfices ?
Nous l’avons vu, les principaux bénéfices que l’on tire de la mise en œuvre de ses approches sont la vitesse de réalisation et le gain de temps qui en résulte, ainsi que la réduction du risque de se lancer dans des développements conséquents qui, pour finir, ne répondraient pas aux besoins des utilisateurs.
L’une des dérives que nous constatons régulièrement chez nos clients, consiste à concevoir un cahier des charges très exhaustif. Il peut arriver également que les utilisateurs finaux de l’appli n’aient pas participé à l’élaboration du cahier des charges. Les approches Prototypage, POC et MVP permettent d’impliquer les utilisateurs très tôt dans le projet et de concentrer les développements sur ce qui a une réelle valeur ajoutée pour eux.
En ce sens, ces 3 démarches s’inscrivent dans une démarche numérique responsable, d’écoconception : le principe est d’aller à l’essentiel, de répondre à des besoins et non à des envies. Cela requiert d’intégrer les futurs utilisateurs très tôt dans la réflexion, et notamment de les faire participer aux ateliers de cadrage fonctionnel en amont du développement, afin de déceler au mieux les problématiques essentielles à résoudre, et d’écarter le superflu au plus tôt.
Enfin, il y a un bénéfice indirect que nous relevons assez régulièrement lors de la mise en place de Prototypes, de POC ou de MVP : c’est l’attente que génère le test. En effet, à l’issue du test, certains utilisateurs enthousiastes voudraient disposer immédiatement de l’application (ou de ses futures évolutions). Cela génère un bouche-à-oreille positif, ce qui est favorable à l’appropriation et à l’engagement des utilisateurs de la future application, comme en témoigne Accès Industrie dans la vidéo ci-dessus.
Alors, comment choisir entre Prototype, POC et MVP ?
Le choix entre ces différentes approches dépend donc d’un certain nombre de critères liés à votre contexte :
- Souhaitez-vous aller vite pour convaincre (un donneur d’ordre, votre direction, les utilisateurs) ? Ou plutôt, prendre votre temps pour recenser les besoins et évaluer immédiatement le budget global qu’il faudra engager dans ce projet ?
- Avez-vous déjà rédigé le cahier des charges de votre application mobile ?
- Votre projet est-il complètement défini ? Ou y’a-t-il encore beaucoup d’inconnues (liées à des aspects techniques, à l’usage…) ?
Vos réponses à ces questions permettront de vous orienter vers l’une ou l’autre des démarches présentées dans cet article. Quelle que soit l’approche choisie, l’organisation d’un atelier de cadrage fonctionnel permettra d’intégrer les futurs utilisateurs très tôt dans la réflexion, de faciliter l’expression de besoins et de prioriser les fonctionnalités tout en tirant le meilleur parti des fonctionnalités du terminal mobile.
Vous souhaitez réagir ou en savoir plus ?
Prenons rendez-vous pour échanger autour d’un café… et en attendant, découvrez notre configurateur en libre accès pour cadrer votre projet !