Développer une application d'entreprise : étapes clés

La découverte précise quel problème l'application doit résoudre. Qui est l'utilisateur, quand et pourquoi l'ouvrira-t-il, et pourquoi un site mobile ou un outil existant ne peut-il pas répondre à ce besoin ? Un projet lancé sans réponses honnêtes finit souvent en une application que personne n'ouvre une fois en ligne.

Les systèmes existants sont aussi cartographiés à ce stade : où se trouvent les données des utilisateurs, avec quel système interne l'application doit-elle dialoguer, l'accord de qui faut-il obtenir ? Pensez à une application d'adhésion et de réservation pour un groupe de spas. Si les informations de réservation se trouvent dans un logiciel distinct dans chaque établissement, le vrai travail de l'application consiste à dialoguer en sécurité avec ce logiciel. Le nombre et la nature de ces connexions façonnent chaque étape ultérieure.

Le périmètre est la liste écrite des fonctionnalités de la première version. L'erreur la plus courante est de vouloir tout y faire entrer. L'approche plus saine consiste à livrer la plus petite version qui accomplit la tâche principale de l'utilisateur, puis à ordonner le reste d'après des données d'usage réelles.

Quand le périmètre est rédigé, les fonctionnalités se répartissent en trois groupes : essentielles, souhaitables et pour plus tard. Si cette répartition n'est pas consignée par écrit, chaque demande ajoutée en cours de route élargit discrètement le périmètre. La dérive du périmètre est la cause la plus fréquente des projets en retard.

• Écrire la tâche principale de l'utilisateur en une phrase
• Classer chaque fonctionnalité comme essentielle, souhaitable ou pour plus tard
• Lister les systèmes internes et les prestataires auxquels l'application se connectera
• Décider à l'avance comment une modification du périmètre est demandée

Le design n'est pas seulement l'apparence. C'est la construction du parcours. Par quels écrans l'utilisateur passe-t-il pour terminer une tâche, que voit-il quand quelque chose échoue, que se passe-t-il quand la connexion tombe ? Ces questions s'éprouvent dans un prototype cliquable avant qu'une ligne de code soit écrite, car modifier un parcours sur le papier coûte bien moins cher que dans le code.

Le prototype est montré à quelques vrais utilisateurs. Les personnes de l'organisation connaissent le parcours et ne s'en écartent pas. Ce qu'il faut apprendre, c'est où hésite quelqu'un qui découvre le produit pour la première fois. L'accessibilité est aussi prise en compte ici : une taille de texte lisible, un contraste suffisant et des zones de toucher confortables ne sont pas des détails à ajouter plus tard.

Le développement avance par courtes périodes, et un morceau fonctionnel est présenté à la fin de chacune. Ainsi, les surprises arrivent tôt plutôt que tard. Les tests ne sont pas non plus une étape laissée à la fin. Ils accompagnent le développement : vérifications automatisées, essais sur de vrais appareils et regard sur différentes tailles d'écran.

Dans les applications d'entreprise, les tests comptent surtout pour les connexions. Même si une liaison de paiement, de notification ou de système interne fonctionne bien, il faut voir ce qui se passe sur un réseau lent ou lors d'une panne. Si l'équipe terrain d'un fabricant de revêtements de sol utilise surtout l'application sur site avec un signal faible, le comportement hors connexion est le cœur du produit.

La recette est réalisée avec l'équipe propre de l'entreprise. Les personnes qui connaissent le flux de travail réel trouvent des lacunes que l'équipe technique ne peut pas voir. Si le temps accordé à cette étape est réduit, les défauts se découvrent après l'arrivée de l'application sur le store.

La soumission au store est une étape avec son propre processus de validation, dont la durée ne se prédit pas exactement. C'est pourquoi la date de lancement est planifiée en laissant de la marge pour la validation. Les règles des stores et les déclarations de confidentialité sont aussi préparées avant la publication, car une déclaration manquante peut entraîner le rejet de l'application.

La publication est le début du travail, non sa fin. Dans la première période, on surveille les rapports de plantage, les avis des utilisateurs et les données d'usage de base. L'application continue de vivre au rythme des mises à jour du système d'exploitation, du renouvellement des bibliothèques et des nouvelles fonctionnalités. Si le plan de maintenance n'est pas discuté avant la publication, l'application vieillit en silence.

La première erreur est de sauter la découverte et de passer directement au design. Un projet qui ne connaît pas le problème construit un produit joli mais inutile. La deuxième est d'associer tard les décideurs. Une objection de la direction en plein développement est la modification la plus coûteuse qui soit.

La troisième erreur est de se concentrer uniquement sur la date de lancement et de ne pas planifier la maintenance. La quatrième est d'avancer sur des hypothèses sans jamais parler aux utilisateurs. La cinquième est de bâtir une structure qui dépend d'une seule personne. Le code, les identifiants d'accès et les comptes des stores doivent toujours être au nom de l'organisation.

Tous les besoins n'appellent pas une application. Lorsque les utilisateurs lisent des informations de temps à autre et n'ont besoin d'aucune fonction de l'appareil comme l'appareil photo ou les notifications, un site mobile ou une application web bien conçus suffisent souvent. Et si vous ne savez pas à quelle fréquence les utilisateurs reviendront vers votre produit, un petit essai préalable est la démarche raisonnable.

Le critère : l'utilisateur accomplit-il cette tâche encore et encore, et les fonctions de l'appareil apportent-elles de la valeur ? Si les deux réponses sont oui, une application a du sens. Sinon, l'investissement sera mieux employé dans un autre canal. Pour voir comment se comporte votre site actuel sur mobile, notre test de vitesse du site vous donne gratuitement une première impression.