Processus de développement d’une app : guide pour le fondateur qui paie

Le processus de développement d’une app est vendu comme un tapis roulant en six étapes. Voici ce qui se passe vraiment à chacune, quelle est votre seule tâche, et où le fondateur perd discrètement le contrôle du produit qu’il paie pour faire construire.

Une fondatrice avec qui nous avons travaillé avait tout validé. Elle avait signé les wireframes, hoché la tête à chaque démo de sprint et transféré la date de lancement à son investisseur principal. Trois semaines avant le go-live, le développeur a mentionné, en passant, que l’app ne pouvait pas envoyer d’e-mail de réinitialisation de mot de passe. Cela n’avait jamais été dans le périmètre. Personne ne lui avait menti. Elle avait simplement validé six mois de travail sans jamais savoir ce qu’elle était censée vérifier à chaque étape.

Le processus de développement d’une app est la séquence qu’une idée logicielle parcourt pour devenir un produit qui fonctionne : discovery, design, construction, tests, lancement et maintenance. Chaque agence et chaque software house le décrit comme un ensemble bien rangé d’étapes, presque toujours numérotées, presque toujours avec une flèche vers la droite. Ce dessin est vrai et inutile. Vrai parce que ces phases se déroulent bel et bien dans cet ordre. Inutile parce qu’il est tracé depuis le siège de celui qui construit, et vous n’êtes pas dans ce siège. Vous êtes celui qui paie la facture, et votre tâche à chaque phase est différente de la leur.

Voici un guide de ces mêmes six phases depuis l’endroit où vous êtes vraiment assis. Pour chacune : ce qui se passe, la seule chose qu’il vous revient de bien faire, et le signe précis que la phase tourne mal pendant que tout le monde sourit encore.

La seule règle qui régit tout le processus de développement d’une app

Avant les phases, la règle qui donne un sens à toutes :

Votre pouvoir d’influence sur un build est maximal avant qu’une seule ligne de code ne soit écrite, et il baisse chaque semaine ensuite. Dépensez votre attention là où elle vaut le plus : sur les deux phases avant la construction, pas sur les standups pendant celle-ci.

La plupart des fondateurs débutants font l’inverse. Ils restent à l’écart pendant le discovery et le design, quand une phrase de leur part pourrait réorienter tout le projet, puis se remplissent d’anxiété et s’impliquent pendant la construction, quand les décisions coûteuses sont déjà coulées dans le béton. Le temps que vous regardiez les standups quotidiens, vous gérez la météo. L’influence est partie sans vous.

Phase 1 : Discovery, décider ce qu’il ne faut pas construire

Le discovery, c’est là où l’équipe transforme votre idée en une liste précise de ce que la version un fera et ne fera pas. Les bonnes équipes mènent des entretiens, esquissent des parcours et fixent la poignée de choses que le produit doit faire pour valoir la peine d’être lancé. Les équipes faibles sautent cette étape et se mettent à dessiner des écrans, ce qui ressemble à du progrès et n’est en réalité que deviner avec un outil plus joli.

Votre seule tâche ici est de soustraire. L’équipe peut ajouter des features toute la journée ; vous seul pouvez décider ce dont l’entreprise n’a pas besoin dans la première version. Chaque feature que vous coupez au discovery est de l’argent que vous ne dépensez pas et un bug que vous n’aurez jamais à corriger. C’est la phase où le travail de discovery produit se rentabilise plusieurs fois, parce que c’est l’endroit le moins cher de tout le processus pour changer d’avis.

Le signal d’alerte : l’équipe veut commencer à construire dès la première semaine et traite le discovery comme une formalité. Une software house pressée de sauter le discovery est une software house payée pour construire, pas pour réfléchir, et la différence apparaîtra sur votre facture dans trois mois, sous forme de reprise de travail.

Phase 2 : Design, le dernier endroit peu coûteux pour se tromper

Le design transforme les décisions du discovery en quelque chose que vous pouvez voir et cliquer : d’abord les wireframes (le squelette), puis des mockups plus fidèles et, en général, un prototype interactif. C’est la dernière phase où changer d’avis coûte un après-midi plutôt qu’une semaine. Déplacer un bouton dans un fichier de design est gratuit. Le déplacer après qu’il est câblé à des données réelles et testé, non.

Votre tâche est de cliquer le prototype comme un client méfiant, pas de l’admirer comme un parent fier. Essayez de faire les trois choses que vos vrais utilisateurs feront le plus souvent. Si l’une d’elles demande plus de taps qu’elle ne le devrait, dites-le maintenant. Comprendre la différence entre un wireframe et un mockup compte ici, parce que les fondateurs valident souvent un squelette gris en croyant avoir validé l’apparence finale, puis se sentent trompés quand la version réelle arrive.

Le signal d’alerte : on vous montre des images statiques et on vous demande d’imaginer le parcours. Si vous ne pouvez pas réellement parcourir le trajet principal du doigt avant que la construction ne commence, vous validez une histoire à propos de l’app, pas l’app.

Phase 3 : Construction, où votre influence est déjà dépensée

Maintenant les ingénieurs écrivent le code. C’est la phase la plus longue et la plus chère et, contre l’intuition, celle où vous avez le moins à apporter. Les décisions qui comptaient ont été prises dans les deux phases que vous avez peut-être traversées à la hâte. Ce que vous pouvez encore faire ici, c’est protéger le build de vous-même.

Chaque fois que vous introduisez une idée nouvelle en pleine construction, vous n’ajoutez pas une feature, vous rouvrez le plan. L’équipe doit re-séquencer le travail, et le coût est rarement seulement la chose nouvelle ; c’est tout ce que la chose nouvelle touche. C’est le mécanisme derrière la plupart des délais qui explosent. Si vous voulez comprendre pourquoi le chiffre a bougé, lisez votre estimation de développement logiciel comme une fourchette qui suppose que vous arrêtez de changer d’avis, parce que cette hypothèse fait un travail silencieux et énorme.

Votre seule tâche pendant la construction est de garder une version qui fonctionne sous les yeux. Demandez un lien que vous ouvrez vous-même, pas un enregistrement d’écran que quelqu’un a monté. Un logiciel qui n’existe que dans une démo est un logiciel que vous ne pouvez pas inspecter. Le signal d’alerte, c’est une phase de construction où chaque mise à jour est une diapositive et jamais un lien.

Phase 4 : Tests, la phase qu’on coupe en premier

Le test, c’est là où l’équipe essaie de casser l’app avant que vos clients ne le fassent : fonctionne-t-elle sur un Android bon marché, survit-elle à un mauvais réseau, que se passe-t-il quand quelqu’un tape un emoji dans le champ du nom. C’est la phase la plus susceptible d’être discrètement comprimée quand la construction prend du retard, parce que c’est la dernière debout entre une date qui glisse et un lancement.

Vous ne pouvez pas lire le code de test, mais vous pouvez demander le résultat : un rapport court de ce qui a été testé, de ce qui a cassé et de ce qui a été corrigé. Vous n’auditez pas l’ingénierie. Vous vérifiez que le test a eu lieu comme une activité avec un livrable, et non comme un mot que quelqu’un a prononcé en réunion. L’e-mail de réinitialisation de mot de passe que personne n’a mis dans le périmètre est exactement le genre de chose qu’une vraie passe de tests attrape et qu’une passe comprimée laisse passer.

Le signal d’alerte : « on a testé au fur et à mesure » offert en remplacement d’une phase de tests. Tester au fur et à mesure est une bonne pratique et une mauvaise excuse. S’il n’y a pas d’artefact montrant ce qui a été vérifié, supposez que la couverture est celle qui était pratique.

Phase 5 : Lancement, un événement d’ingénierie avant d’être un événement marketing

Le lancement, ce n’est pas la fête. C’est le travail ennuyeux et à fort enjeu de mettre l’app devant de vrais utilisateurs sur une vraie infrastructure : revue de l’app store, données de production, monitoring et un plan pour la première fois où quelque chose casse à deux heures du matin. Le lancement marketing peut attendre une semaine. Le lancement d’ingénierie a cent petites portes qu’il faut toutes fermer, et la plupart vous sont invisibles.

Votre tâche est de savoir qui tient le pager. Posez une question : quand quelque chose casse dans les 48 premières heures, qui s’en aperçoit et en combien de temps peut-il le corriger. Si la réponse est vague, vous n’avez pas un plan de lancement, vous avez un espoir. Le lancement a aussi des gardiens que vous ne contrôlez pas : les directives de revue de l’App Store d’Apple peuvent rejeter un build pour des raisons qui n’ont rien à voir avec son bon fonctionnement, et un rejet à quelques jours de votre date est un problème de lancement que vous voulez entendre en phase un, pas en phase cinq.

Le signal d’alerte : le plan de go-live est une date et rien d’autre. Une date n’est pas un plan. Un plan dit qui fait quoi quand la chose que vous n’attendiez pas se produit.

Phase 6 : Maintenance, la phase que tout le monde oublie de chiffrer

Un logiciel n’est pas un bâtiment qui tient debout une fois le ruban coupé. Les téléphones se mettent à jour, les bibliothèques cassent, les utilisateurs trouvent des recoins que vous n’aviez jamais imaginés, et l’app a besoin d’une attention constante et sans gloire pour continuer à fonctionner. La maintenance n’est pas une phase après le processus ; c’est le processus qui ne s’arrête pas. Les fondateurs qui traitent le lancement comme une ligne d’arrivée le découvrent la première fois qu’Apple change quelque chose et que leur app ne s’ouvre plus.

Votre tâche est de refuser l’idée que la maintenance est optionnelle. Décidez, avant le lancement, qui garde la lumière allumée et ce que cela coûte par mois. La version la moins chère de cette conversation a lieu maintenant. La version la plus chère a lieu après que votre unique développeur est parti et que personne parmi ceux qui restent ne peut modifier une ligne en sécurité.

Le signal d’alerte : une proposition qui s’arrête au lancement, sans une ligne sur ce qui se passe après. Un build sans plan de maintenance est une voiture vendue sans aucun moyen d’acheter du carburant.

Le test du handoff : comment savoir qu’une phase s’est vraiment terminée

Voici le seul outil qui relie les six phases. À chaque frontière entre phases, il existe un artefact que vous devriez pouvoir tenir en main :

• Après le discovery : un périmètre d’une page que vous lisez en cinq minutes et qui liste ce qui est exclu, pas seulement ce qui est inclus.
• Après le design : un prototype cliquable du parcours principal, pas un dossier d’images.
• Après la construction : un lien vers une version qui fonctionne et que vous ouvrez vous-même.
• Après les tests : un rapport court de ce qui a été vérifié et de ce qui a cassé.
• Après le lancement : un runbook nommant qui répond quand quelque chose échoue.

Le test est simple. Si une phase se termine et que vous ne pouvez pas tenir son artefact, la phase ne s’est pas vraiment terminée. Elle a seulement poussé son risque en aval, vers la phase suivante et, au bout du compte, vers vous. Chaque désastre dans un build est une version d’une phase déclarée terminée sans avoir produit la chose qui prouve qu’elle l’était. Le test du handoff, c’est ainsi qu’un fondateur non technique audite un processus dont il ne peut pas lire le code : vous ne vérifiez pas le travail, vous vérifiez que chaque phase a laissé une preuve derrière elle.

Vous remarquerez que cela vous dit aussi à quelle software house faire confiance. Une équipe qui pense en artefacts vous les remet sans que vous les demandiez. Une équipe qui pense en factures vous remet un point d’avancement et espère que vous vous sentirez rassuré. La manière dont vous choisissez une entreprise de développement devrait s’appuyer fortement là-dessus : demandez ce que vous pourrez tenir en main à la fin de chaque phase, et observez si la réponse est précise.

Questions fréquentes

Quelles sont les étapes du processus de développement d’une app ?

Six : discovery (décider quoi construire), design (le rendre visible et cliquable), construction (écrire le code), tests (le casser avant les utilisateurs), lancement (le mettre en ligne en sécurité) et maintenance (le garder fonctionnel). Certains guides divisent cela en sept ou douze étapes, mais les chiffres supplémentaires sont en général des sous-tâches de ces six. Le nombre importe moins que de savoir quelle est votre tâche dans chacune.

Combien de temps dure le processus de développement d’une app ?

Une première vraie version prend en général de trois à six mois, le discovery et le design prenant quelques semaines et la construction absorbant l’essentiel. La réponse honnête dépend de combien vous coupez au discovery et du nombre de fois où vous changez d’avis pendant la construction. Les deux leviers que vous contrôlez sont à l’avant du processus, pas au milieu.

Quelle est la phase la plus importante pour un fondateur non technique ?

Les deux avant la construction : discovery et design. C’est là que votre influence est la plus grande et qu’un changement coûte le moins. Les fondateurs qui investissent leur attention là, puis prennent du recul pendant la construction, obtiennent de meilleures apps pour moins d’argent que ceux qui font l’inverse.

Puis-je sauter le discovery pour aller plus vite ?

Vous le pouvez, et c’est la façon la plus courante de dépenser plus pour obtenir moins. Sauter le discovery n’élimine pas les décisions sur ce qu’il faut construire ; il les pousse simplement dans la phase de construction, où les changer coûte dix fois plus. Les départs rapides ici achètent en général des arrivées lentes.

Comment garder le contrôle d’un build que je ne peux pas évaluer techniquement ?

Utilisez le test du handoff. À la fin de chaque phase, demandez l’artefact qui prouve qu’elle a eu lieu : une page de périmètre, un prototype cliquable, un lien qui fonctionne, un rapport de tests, un runbook. Vous n’avez pas besoin de lire du code pour remarquer quand une phase s’est terminée sans laisser de preuve derrière elle.