Comment réussir son projet d’application mobile
Un projet d’application mobile –B2B, B2C ou métier– n’est pas un projet IT, ni même un projet Web comme un autre. Pour réussir, il doit être mené avec agilité et rapidité, tout en privilégiant constamment l’expérience utilisateur. Des méthodes innovantes de conception et de prototypage collaboratif permettent de relever ce challenge et de livrer en 3 mois des applications en phase avec les attentes et les usages des publics auxquels elles s’adressent.
Chaque jour, des centaines de nouvelles applications mobiles apparaissent dans les principaux app stores du marché. C’est un euphémisme de dire que toutes ne rencontreront pas le succès escompté… Avec plus de 2,2 millions d’apps disponibles sur Google Play et 2 millions dans l’App store d’Apple, l’offre publique est pléthorique, mais dominée par une poignée d’applications phares –de jeux, de messageries instantanées et de réseaux sociaux– qui comptent des centaines de millions d’utilisateurs.
A côté de cette offre publique, il existe un marché moins visible mais en très forte croissance: celui des apps professionnelles ou «métier» qui, en transformant les façons de travailler, ouvrent de nouvelles perspectives de gain de productivité et d’efficacité, dans toutes les fonctions et dans tous les secteurs. Par exemple, la société Ricard a pu entièrement digitaliser le processus de contrôle qualité de son unité de production de Lormont (en Gironde) en équipant les opérateurs d’une application sur tablette qui permet d’effectuer et transmettre les relevés sans passer par le papier. Pour Alexandre Defrance, directeur du site industriel de Lormont: «Ce projet est un virage important pour les équipes de production, avec l’arrivée du digital dans le hall d’embouteillage. Nous conservons la maîtrise de notre processus qualité tout en gagnant en instantanéité, réactivité et fiabilité, le tout en zéro papier. Le caractère fédérateur et innovant du concept motive les collaborateurs à l’excellence opérationnelle.»
Inutile d’espérer concrétiser ces promesses et obtenir de tels résultats en transposant ou en adaptant au mobile une application initialement conçue pour des ordinateurs. Cette approche est vouée à l’échec. Que votre application mobile s’adresse au grand public, à vos clients ou à vos collaborateurs, il est essentiel de comprendre que c’est un projet à part entière et spécifique. Pour réussir, ce projet doit absolument:
>> être intégralement pensé et développé pour le mobile, dans l’esprit du mobile, et non comme un projet logiciel ou Web classique;
>> respecter les fondamentaux que tout utilisateur de smartphone ou de tablette attend implicitement d’une appli et qui sont des conditions sine qua non de son adoption: une dimension ludique, de la simplicité, de l’intuitivité et de la rapidité.
Ce n’est pas un hasard si les méthodes les plus efficaces de création d’applications mobiles reprennent précisément deux de ces fondamentaux. Centrées sur l’expérience utilisateur, elles sont résolument ludiques et privilégient la rapidité, notamment dans la phase de conception.
Un prototype «cliquable» en 3 semaines
Dans une véritable «mobile factory», les équipes de création et de développement travaillent main dans la main et, surtout, embarquent les futurs utilisateurs dès le début du projet, dans une logique de co-création reprenant les principes du Design Sprint. Née dans l’univers Google, cette méthodologie permet, dans un temps très court, de répondre par le design et le prototypage aux problématiques d’expérience utilisateur (UX) et d’interface utilisateur (UI).
Sans cahier des charges préalable, des ateliers de créativité à base de serious games permettent de faire émerger les attentes et les idées des utilisateurs et, très vite, de passer au prototypage collaboratif. Par exemple, avec une plateforme comme Invision, il est aujourd’hui facile de créer des maquettes «cliquables» à partir des interfaces dessinées par les créatifs –sans écrire une seule ligne de code et pour autant directement utilisable sur tablette ou smartphone! Cette technique de dynamisation d’image permet de lier les écrans et donc de tester les parcours utilisateurs de manière réaliste. Les utilisateurs peuvent «jouer» avec cette maquette qui sera facilement modifiée en fonction de leurs remarques jusqu’à ce qu’elle les satisfasse en termes d’usage et de navigation. Le secret de la réussite de cette phase de conception réside dans :
>> l’absence de cahier des charges traditionnel, ce qui donne toute liberté aux utilisateurs d’inventer l’appli qui leur convient, sans être freiné par des exigences fonctionnelles définies a priori et sans se soucier des réalités d’usage;
>> l’itération rapide entre utilisateurs et designers, qui évite de s’enferrer dans des erreurs ergonomiques rédhibitoires et qui seront difficiles et coûteuses à corriger une fois l’application codée;
>> la durée volontairement limitée du processus, qui élimine la tentation de vouloir tout couvrir du premier coup et oblige à se concentrer sur l’essentiel et l’indispensable, tant en termes d’usage que de fonctionnalités, pour avoir rapidement une première version opérationnelle de l’application.
Une V1 en 3 mois maximum
Lorsqu’on a «figé» la maquette, on entre dans la phase de fabrication, c'est-à-dire le codage qui va permettre de passer d’une succession d’écrans –qui ne sont que des images– à des interfaces fonctionnelles. L’utilisation de méthodes industrielles de développement, de test et d’intégration continue permet de s’assurer que le code produit est conforme aux standards du marché. La présence continuelle des créatifs auprès des développeurs garantit, quant elle, la conformité «au pixel près» de ce qui est développé à ce qui a été imaginé avec les utilisateurs lors de la phase de conception.
Il faut accepter –et ce n’est pas le plus facile pour des équipes IT d’entreprise– que la V1 d’une application mobile soit sinon basique, du moins limitée à l’essentiel en termes de fonctionnalités. C’est ce qui permet d’aller vite, sachant qu’un projet mobile qui dure plus de 3 mois a tendance à dériver, à s’enliser en tombant dans les travers du perfectionnisme. Mieux vaut commencer «petit» et livrer rapidement une première version –incomplète certes, mais irréprochable en termes d’UX– en ayant en tête qu’un projet mobile réussi ne s’achève jamais avec la V1.
Un vrai plan d’évolution, dès la V1
Quand la V1 est publiée –dans un app store public ou privé– la vraie vie de l’application commence et il faut déjà avoir en tête les premières étapes d’un plan d’évolution à 6 ou 9 mois, visant à:
>> enrichir la version suivante, en reprenant les idées de la phase de conception qui n’ont pas pu être mises en œuvre dans la V1;
>> intégrer les remarques, commentaires et retours des utilisateurs sur la V1 dans une logique d’amélioration continue de l’expérience utilisateur;
>> relancer l’intérêt des utilisateurs en annonçant régulièrement des nouveautés, des améliorations et des enrichissements.
Une application mobile qui n’évolue pas peut mourir très rapidement parce qu’elle déçoit les utilisateurs, parce qu’elle n’intègre pas les derniers codes graphiques ou modes de navigation… C’est la raison pour laquelle des acteurs proposant des applis très populaires, tels que Mappy et la SNCF, ont fait de leur stratégie de mise à jour un outil de marketing pour relancer très régulièrement l’intérêt des utilisateurs, avec des évolutions toutes les 2 à 4 semaines. Ils éditorialisent leur plan d’évolution et utilisent les méthodes bien connues du community management pour capter en permanence les retours de leurs utilisateurs, sur les app stores ou sur les réseaux sociaux.
Pour une application métier, le rythme d’évolution sera généralement moins soutenu mais il est judicieux de s’inspirer de ces méthodes d’animation communautaire pour impliquer les collaborateurs dans la vie des outils qu’ils utilisent au quotidien. On s’assure ainsi de rester au plus près non seulement de leurs besoins professionnels, mais aussi des normes d’usage qui conditionnent leur adhésion dans la durée –le plus gros défi étant, release après release, d’arriver à préserver la simplicité d’usage de l’application d’origine.
Ne pas hésiter à tuer une application vieillissante
Une application mobile ne peut pas évoluer à l’infini. La durée de vie des applications a d’ailleurs tendance à raccourcir: elle est aujourd’hui d’un an et demi, deux ans maximum, pour des raisons techniques mais surtout parce que la conception initiale est en décalage avec les usages du moment. Par exemple, le burger menu qui s’est généralisé en très peu de temps, fait paraître «ringarde» toute autre forme de menu, même dans une appli professionnelle. Des changements de mode de ce type sont difficiles à anticiper mais s’imposent rapidement à tous. Les intégrer dans une app existante peut devenir de plus en plus complexe et coûteux. Arrive un moment où il est plus pertinent de tuer l’ancienne application et de la redévelopper pour qu’elle soit de nouveau à l’état de l’art et puisse supporter un nouveau cycle d’évolution.
C’est la stratégie adoptée pour toutes les grandes applications grand public qui, pratiquement tous les ans, changent non seulement d’interface et d’ergonomie mais aussi en profondeur afin de tirer le meilleur parti des évolutions des systèmes d’exploitation et de l’environnement technique. Cette accélération, qui oblige à recoder, est particulièrement frustrante pour les développeurs: aujourd’hui, le succès d’une application mobile dépend moins d’un code bien écrit que de l’expérience utilisateur et du caractère «sexy» et innovant de l’interface. Cela vaut pour les applis grand public comme pour les applis métier, et ce pour une raison évidente: l’utilisateur quotidien de l’app Facebook, Twitter ou Snapchat, s’attend à retrouver dans ses applications professionnelles la même simplicité et la même qualité d’expérience. C’est une condition décisive d’acceptabilité, charge aux designers et aux développeurs de conjuguer leurs talents pour masquer la complexité sous-jacente et livrer des applications toujours plus simples et intuitives.
- Vouloir tout imaginer tout de suite pour avoir l’application la plus exhaustive possible. Cela rallonge les délais, or un projet mobile doit être rapide. L’objectif doit être de sortir une première version en moins de 3 mois.
- Concevoir l’appli sans les utilisateurs finaux, en partant d’un simple recueil de besoin. L’UX est la dimension cruciale pour l’adoption et l’adhésion à une appli. Les utilisateurs doivent être impliqués dans la phase de conception, création et validation de maquette.
- Partir d’un cahier des charges traditionnel. Le temps qu’il soit élaboré et finalisé, les besoins ont déjà changé. Adopter une approche fail fast est beaucoup plus efficace.
- Négliger la conduite du changement. Les applications mobiles métier remettent en cause les habitudes et les processus, voire les organisations. Les utilisateurs doivent être accompagnés pour bien vivre cette transition.
Les langages natifs Apple et Android sont les standards incontournables du marché. Une application développée dans l’un de ces langages ne fonctionne pas sur l’autre plateforme, ce qui oblige à développer l’application deux fois si l’on veut être présent dans les deux univers.
Les langages hybrides offrent une alternative en permettant de développer le cœur de l’application une seule fois et de spécialiser l’appli en bout de chaîne pour qu’elle soit utilisable sur les deux plateformes.
Si l’avantage économique est réel,
il faut savoir que les applis développées en langage natif offrent de meilleures performances dans des contextes transactionnels importants.
Jean-Philippe Clair participe en 1999, à la création de l’éditeur Knowings qui deviendra au fil des années un acteur majeur de solutions collaboratives. En 2011 il rejoint le groupe SQLI pour prendre le pilotage du pôle Enterprise Content Management (ECM) puis du pôle Conseil Digital de Wax Interactive à Lyon. Il rejoint Keyrus en 2014 pour diriger les opérations digitales en région, assurant aussi le pilotage de différentes missions de conseil sur les sujets Mobile & Transformation digitale, et prend la direction de l’Agence Keyrus Digital France en 2016
Pour contacter la rédaction: redaction@frenchweb.fr
Pour plus d'informations sur nos abonnements, merci de nous contacter à abonnement@frenchweb.fr
Vous souhaitez contribuer régulièrement en tant qu'expert sur FRENCHWEB.FR, merci de nous contacter à redaction@frenchweb.fr
- Ask A VC : comment modéliser un compte de résultat — Partie 6/6 : analyse de sensitivité - 21/05/2024
- Ask A VC : comment modéliser un compte de résultat — Partie 3/6 : les Coûts Fixes - 16/01/2024
- Question à un VC : Pourquoi les marges unitaires sont-elles si importantes pour votre modèle d’affaires? - 13/11/2023
