schéma de création d'une application mobile

Fréquemment, les entreprises qui sollicitent Wopata décrivent leur projet d’application autour de 3 dimensions :

  • Une idée, exprimée de manière plus ou moins aboutie, agrémentée de mots-concepts, parmi lesquels : gamification, partage sur Facebook, notifications push, géolocalisation de l’utilisateur, réalité augmentée, machine learning
  • Un budget, ou une fourchette budgétaire, [Budget, Budget + 25%]
  • Une date de mise en production de l’application sur les stores Apple et Google

Même une bonne idée d’application, exprimée de manière précise, ne peut remplacer une analyse fonctionnelle détaillée. D’autant que les « mots-concepts » mentionnés plus haut, manquent parfois d’ancrage concret, dans le contexte de l’application envisagée.

Toutes les applications mobiles n’ont pas besoin d’une fonction de partage sur Facebook ; pourtant, la plupart de nos clients formulent cette demande , presque comme un automatisme. Il leur semble impossible de se priver du fameux « share on Facebook« . Partager d’accord, mais partager quoi au juste ? Récemment, lorsque grâce à l’utilisation de simples marqueurs statistiques, nous avons constaté que moins de 0,1% des utilisateurs d’une application consumériste destinée au plus grand nombre touchaient le bouton « partager sur Facebook », nous dûmes justifier cet échec auprès de notre client, qui était pourtant à l’origine de la demande, en dépit de notre scepticisme. Le partage sur Facebook n’est pas une recette miracle qui garantit la promotion virale d’une application. Pourquoi ? Parce que les utilisateurs sont de vraies personnes : si ce partage n’est pas justifié de leur point de vue, il ne sera tout simplement jamais utilisé.

Il en va de même pour les notifications push qui ne sont pas systématiquement souhaitables. Pourquoi ? Parce que si l’envoi de telles notifications n’est pas considéré comme pertinent par les utilisateurs, l’agacement de l’utilisateur peut conduire à la désinstallation de l’application ; rappelons que seuls 12% des utilisateurs de l’iPhone savent désactiver le push notification pour une application spécifique (via les réglages systèmes de l’appareil).

Côté budget, personne n’envisageait de figer le budget dédié à la construction d’un immeuble avant même de disposer des plans de celui-ci. Cependant, 75% des demandes que nous recevons font explicitement référence à une enveloppe budgétaire prédéfinie et figée. Nous recevons parfois des demandes ubuesques dans le style : « nous disposons de 10.000 € et nous voulons créer un nouveau Twitter, plus fort, plus convivial et plus beau que l’original ». Cette approche conduit systématiquement au même résultat ; les entreprises qui procèdent de la sorte dépensent 10.000 € pour acheter leur échec. Il est normal et souhaitable de faire jouer la concurrence, de contrôler les dépenses et d’inscrire un développement d’application dans une perspective économique de rentabilité. En revanche, personne ne peux concevoir et développer le Uber de demain pour 10.000 €, maintenance comprise.

Pour ce qui concerne les délais, tant que l’application n’est pas développée, il n’est pas souhaitable d’arrêter sa date de publication sur les stores. En dépit des recommandations strictes d’Apple en la matière, certaines entreprises planifient des campagnes de promotion marketing (nécessairement floues, donc mal ciblées, parce que les avantages concurrentiels de l’application ne sont pas encore identifiés). Il n’est pas rare qu’Apple rejette la première version d’une application, pour des raisons difficiles à prévoir, allant d’une simple imprécision dans la description du fonctionnement de l’app (metadata rejection) au dysfonctionnement de l’app, tel que constaté par le testeur dans des conditions spécifiques. À plusieurs reprises, nous avons assisté impuissants à la publication d’articles promotionnels, plusieurs semaines avant la mise à disposition effective d’une application sur les stores.

Une analyse fonctionnelle détaillée permet d’éviter ces écueils

Chez Wopata, nous aimons rappeler qu’une analyse fonctionnelle détaillée doit être produite en amont de tout développement.

Aucun constructeur automobile ne choisirait l’habillage intérieur d’une voiture avant que cette dernière ne soit dûment dessinée et que sa motorisation soit parfaitement définie ! Dans l’industrie comme dans de nombreux secteurs du tertiaire, des professionnels travaillent quotidiennement au sein de bureaux d’études à la rédaction d’analyses fonctionnelles détaillées, afin de lancer un nouveau produit / service ou de faire évoluer un produit / service existant. Pourtant, lorsqu’il s’agit de l’écosystème mobile, ces pratiques paraissent moins légitimes et sont considérées comme synonymes de perte de temps, ou de risque concurrentiel. Certes, le développement d’applications mobiles de complexité faible ou moyenne s’inscrit dans des cycles courts, souvent sous le contrôle et le pilotage d’une direction opérationnelle, en coordination avec le service informatique de l’entreprise. Cependant, il n’est pas rare de produire une mauvaise application, même rapidement, et le coût marginal relatif à la publication d’une telle application sur les stores peut devenir exorbitant.

L’analyse fonctionnelle s’intéresse aux aspects suivants de l’application :

  • Planification du projet global
  • Périmètre fonctionnel précis de l’application
  • Description de l’ensemble des fonctions et services proposés à l’utilisateur
  • Scénarisation de ces fonctions et services dans les différents écrans de la future application (appelées vues)
  • Ergonomie – comportement dynamique des écrans – expérience utilisateur (UX)
  • Design fonctionnel détaillé des écrans (zoning, wireframes…) et comportement en fonction de la taille de l’écran
  • Description des objets impliqués : modèles d’objets, diagrammes d’états, modèles de données
  • Services web (back-end) exploités par l’application
  • Contrat d’échanges entre l’application et les services web du back-end (API)
  • Comportement de l’application en mode dégradé (absence de réseau ou réseau DATA à très faible débit), fonctionnement en mode local totalement déconnecté
  • Cycle de vie de l’application (gestion des interruptions, reprise après interruption), préservation d’un état, modèles de transition
  • Achats intégrés
  • Fonctions de partagenotifications, etc.

Cette analyse constitue un document de référence indispensable autant qu’un support contractuel qui rythme et garantit la qualité de la relation entre l’entreprise et ses prestataires.

Dans seulement 20% des cas, un tel document existe, plus ou moins abouti. Nous sommes alors seulement sollicités pour commenter une analyse existante et / ou développer l’application qui en résulte. Dans 30% des cas, nos clients nous demandent explicitement de produire un tel document ; une solide expertise fonctionnelle et technique nous permet d’atteindre un taux de satisfaction proche de 100% dans ce domaine. Enfin, la moitié au moins de nos clients préfèrent ignorer l’importance de produire une analyse fonctionnelle de qualité, refusant pas un instant d’y consacrer une partie de leur budget.

Un retour sur investissement totalement garanti

Dans 100% des cas, l’analyse fonctionnelle permet de découvrir et d’anticiper des problèmes d’exploitation et d’évolutivité d’une application. Dans 100% des cas, elle permet d’estimer le véritable budget nécessaire à sa production : design graphique, développement du back-end, développement du code exécuté sur le téléphone de l’utilisateur (l’app elle-même), budget consacré à la promotion de l’app, etc.

Une fois clairement rédigée, et validée par tous les départements concernés au sein de l’entreprise, l’analyse sera utilisée par :

  • Les designers graphiques qui se chargeront d’appliquer une charte graphique à votre zoning
  • Des développeurs du back-end
  • Des développeurs du code client (iOS, Android, hybride, etc.)
  • Des personnes chargées de promouvoir l’application auprès de ses cibles futures (plan de promotion, plan de communication)
  • Des personnes chargées de commercialiser l’application et / ou les services qu’elle offrira à ses futurs utilisateurs

Un dernier chiffre édifiant mérite d’être mentionné. Chaque fois que nous avons pu produire une analyse fonctionnelle, ou chaque fois qu’on nous l’a fournie en amont de tout développement, les budgets estimés ont été respectés à 10% près. Autant dire que dans le cas contraire, les dérives budgétaires sont souvent conséquentes, sans parler de véritables échecs que la confidentialité et les respect de nos clients nous interdisent naturellement de mentionner.