Le vrai calendrier du développement d'application : de l'idée au lancement

Si vous demandez à dix agences combien de temps prend le développement d'une application, vous obtiendrez dix réponses assurées et pas une seule ne sera vraie. La réponse honnête, c'est que personne ne peut vous le dire précisément le premier jour, mais quiconque a réellement livré du logiciel peut vous en décrire la forme : quelles étapes existent, lesquelles dévorent discrètement le calendrier et où vos propres décisions accélèrent les choses ou les bloquent net. C'est cette forme, écrite noir sur blanc.

J'ai vu beaucoup de dirigeants de petites entreprises aborder un projet d'application en attendant une marche bien rangée et linéaire, du croquis à l'App Store. Ce qu'ils obtiennent ressemble plutôt à une succession de paliers et de bonds soudains. Des semaines où l'on dirait qu'il ne se passe rien, puis un jour où tout s'emboîte d'un coup. Rien de tout cela n'est le signe que quelque chose cloche. C'est simplement la manière dont se fabrique le logiciel, et dès que vous savez nommer les étapes, tout le processus cesse d'être une boîte noire dans laquelle vous payez en espérant que ça marche.

Fixons donc des attentes réalistes. Pour une première version ciblée d'une application d'entreprise — non pas une plateforme tentaculaire, mais une première version qui fait bien une seule chose — vous vous situez généralement dans une fourchette de trois à cinq mois, d'un démarrage sérieux à un vrai lancement. Où vous tomberez dans cette fourchette dépend moins de la technologie que de votre clarté, de la rapidité avec laquelle vous décidez et de tout ce que vous tentez de caser avant le lancement. Parcourons cela.

Pourquoi l'estimation qu'on vous a donnée est probablement fausse

Le chiffre de six semaines n'est pas tout à fait un mensonge : c'est le temps nécessaire pour construire la partie que tout le monde peut imaginer. Les écrans. Les boutons. Ce qu'on peut montrer en démo. Ce que ce chiffre ignore en silence, c'est tout ce qui entoure l'application visible : les décisions, les données, les intégrations avec des outils que vous utilisez déjà, les tests, la validation du store, l'inévitable tour de « au fait, est-ce qu'elle pourrait aussi faire ça ? »

Une façon utile de le voir : le code est rarement le goulot d'étranglement. Le goulot, c'est la clarté. Chaque heure où votre développeur attend une décision — quel prestataire de paiement, que se passe-t-il quand une réservation est annulée, qui voit quoi — est une heure que le calendrier perd. Les projets qui aboutissent vite ne sont pas ceux qui ont les meilleurs ingénieurs. Ce sont ceux où la dirigeante répond aux questions en un jour plutôt qu'en deux semaines.

En lisant les étapes ci-dessous, repérez donc les moments où la balle est dans votre camp. Ce sont les points où un projet garde son élan ou s'enlise discrètement pendant trois semaines parce qu'un e-mail est resté sans réponse. Le calendrier est une responsabilité partagée, et la moitié qui revient au client est celle que l'on sous-estime.

Étape 1 : Cadrage et périmètre (1 à 3 semaines)

Avant que quiconque ne conçoive un seul écran, il y a une étape qui ne ressemble pas à de l'avancement mais qui détermine tout : déterminer ce que vous construisez réellement et, plus important encore, ce que vous ne construisez pas. C'est là qu'une idée floue (« une application pour mes clients ») devient une liste concrète et bouclable de fonctionnalités pour la version un.

Bien menée, cette phase de cadrage est surtout faite de conversations et de questions qui dérangent. Qui l'utilise, et sur quel appareil ? Quelle est la seule chose qu'elle doit faire à la perfection ? Qu'est-ce qui peut attendre la version deux ? Un bon partenaire vous tiendra tête ici, et c'est ce que vous voulez : chaque fonctionnalité que vous coupez maintenant, ce sont des semaines que vous récupérez. Le résultat est en général un périmètre écrit et court et un wireframe grossier, quelque chose que vous pouvez tenir en main et dont vous pouvez dire oui, c'est bien ça.

Étape 2 : Design et prototype (2 à 4 semaines)

L'application devient maintenant quelque chose que vous pouvez voir et cliquer, avant qu'une seule ligne de code réel ne vous engage sur quoi que ce soit. Les designers transforment le wireframe en véritables écrans — les couleurs, le flux, la vraie sensation d'usage — généralement sous forme de prototype interactif que vous pouvez parcourir au doigt sur votre propre téléphone.

Cette étape vaut de l'or pour une raison : changer un design coûte peu, changer un logiciel déjà construit coûte cher. Déplacer un bouton dans un prototype prend cinq minutes. Le déplacer une fois la fonctionnalité codée, testée et reliée à vos données peut prendre une journée. C'est donc le moment d'être exigeant, de le montrer à quelques vrais clients ou collaborateurs et d'attraper les problèmes du type « ah, personne ne comprendra ça » tant qu'ils sont encore indolores à corriger.

La cause la plus fréquente d'allongement de cette étape n'est pas le designer, c'est l'indécision de votre côté. Des séries interminables de petites retouches, ou trois personnes disposant d'un droit de veto qui ne s'accordent jamais. Décidez tôt qui valide, donnez vos retours par lots plutôt qu'au compte-gouttes, et cette étape reste serrée.

Étape 3 : Développement (6 à 12 semaines)

C'est la partie que tout le monde imagine en pensant à « faire une application », et c'est le plus long segment d'un seul tenant — mais rarement le plus imprévisible, si les deux premières étapes ont été bien menées. Les développeurs construisent l'application par morceaux, généralement par cycles courts où vous voyez des éléments fonctionnels toutes les une à deux semaines, plutôt que de disparaître trois mois pour réapparaître avec un produit fini.

Ce rythme compte. Vous voulez réagir tôt à un logiciel réel et en marche, pas à un rapport d'état. Quand vous pourrez vraiment utiliser le parcours de réservation en semaine quatre, vous remarquerez des choses qu'aucune spécification n'aurait pu saisir, et les corriger en semaine quatre coûte bien moins cher qu'en semaine dix. Un bon processus de développement rend l'application visible pour vous en continu, et pas seulement à la fin.

Ce qui allonge discrètement le développement

Deux choses font gonfler un développement plus que tout. La première, ce sont les intégrations : chaque système externe avec lequel l'application doit dialoguer (votre prestataire de paiement, votre outil de réservation existant, votre logiciel de comptabilité, un service de livraison) ajoute du travail, et chacun peut réserver ses propres surprises. La seconde, c'est la dérive du périmètre : le goutte-à-goutte régulier de petits ajouts, chacun semblant minime mais qui, ensemble, repoussent le lancement d'un mois. Les deux sont gérables, mais seulement si vous les voyez venir.

• Chaque intégration externe ajoute des jours, parfois des semaines : budgétez-les explicitement, ne les considérez pas comme gratuites.
• « Juste une petite fonctionnalité de plus » est de loin la cause la plus fréquente d'une date de lancement manquée.
• Les vraies données sont plus désordonnées que les données de test ; prévoyez du temps pour les cas limites que votre tableur tolérait en silence.
• Les comptes utilisateurs, les paiements et les notifications sont trompeusement profonds : ils coûtent toujours plus qu'il n'y paraît.
• Les validations et les contenus que vous devez à l'équipe (logos, textes, mentions légales) peuvent bloquer un développement aussi sûrement qu'un bug.

Étape 4 : Tests et corrections (2 à 4 semaines)

Voici une étape dont on oublie l'existence, puis qu'on déplore quand elle surgit. Une fois l'application construite, il faut la mettre à l'épreuve : sur différents téléphones, avec une mauvaise connexion, par des personnes qui ne l'ont pas construite et qui feront des choses que personne n'avait anticipées. Tester n'est pas une formalité. C'est la différence entre une application en laquelle vos clients ont confiance et une qu'ils désinstallent après le premier plantage.

Attendez-vous à voir surgir ici une liste de bugs et d'aspérités. Ce n'est pas le signe que le développement s'est mal passé ; c'est tout l'objet de l'étape. Certains sont des corrections rapides, d'autres révèlent une décision à revoir. Les équipes qui gèrent bien cela le traitent comme une part normale et planifiée du travail — pas comme une urgence, ni comme quelque chose à sauter parce que le lancement approche. Sauter les tests ne fait pas gagner de temps. Cela déplace simplement les bugs de votre téléphone de test vers ceux de vos clients, où ils coûtent dix fois plus cher à corriger.

Étape 5 : Lancement et l'attente du store (1 à 2 semaines, plus la validation)

Le lancement tient moins d'un instant unique que d'un déploiement soigné. S'il s'agit d'une application web, vous maîtrisez entièrement le timing : vous appuyez sur l'interrupteur quand vous êtes prêt. Si elle part sur l'App Store d'Apple ou Google Play, vous cédez une partie du calendrier : leur processus de validation peut prendre d'un jour à plus d'une semaine, et il leur arrive de la renvoyer avec quelque chose à corriger. Mieux vaut le savoir à l'avance pour que cela ne prenne pas de court une date de lancement promise à vos clients.

La manière intelligente de lancer n'est pas une révélation en fanfare à toute votre clientèle. C'est d'abord une mise en ligne discrète auprès d'un petit groupe — une poignée de clients bienveillants ou vos propres collaborateurs — pour attraper les problèmes du monde réel avant que tout le monde ne les voie. Puis vous ouvrez la porte plus grand. Un lancement qui paraît ennuyeusement sans histoire est un lancement réussi.

1. 1
   Lancement en douceur auprès d'un petit groupe

   Diffusez d'abord auprès d'une poignée d'utilisateurs bienveillants ou de collaborateurs. L'usage réel trouve ce que les tests ont manqué, avec les enjeux au plus bas.
2. 2
   Soumettez tôt si vous visez les stores

   Apple et Google maîtrisent l'horloge de la validation, pas vous. Soumettez avec une marge pour qu'une validation lente ou un refus ne fasse pas exploser la date promise.
3. 3
   Surveillez de près la première semaine

   Gardez quelqu'un sous la main pour réagir vite. La première semaine fait remonter les cas limites réels qu'aucun environnement de test ne reproduit.
4. 4
   Planifiez le travail du lendemain avant de lancer

   Une application n'est jamais 'terminée' au lancement. Convenez à l'avance de qui s'occupe des inévitables petites corrections et du premier tour de retours.

Assembler tout le calendrier

Empilées bout à bout, ces étapes donnent une image réaliste. Aucune n'est exotique ; ce qui fait trébucher les gens, c'est d'oublier que les peu reluisantes — cadrage, tests, attente du store — sont du temps réel au calendrier, pas des erreurs d'arrondi. Voici à peu près comment une première version ciblée tend à se répartir sur les mois.

Additionnez et vous comprenez pourquoi trois à cinq mois est la fourchette honnête pour une vraie première version, et pourquoi ceux qui promettent six semaines redéfinissent discrètement ce que signifie « une application ». Ce n'est pas du pessimisme : c'est la différence entre une date que vous tiendrez réellement et une pour laquelle vous passerez tout le projet à vous excuser.

Comment l'accélérer vraiment (et comment non)

Vous pouvez aller plus vite, mais les vrais leviers ne sont pas ceux vers lesquels on se précipite. Jeter plus de développeurs sur un projet à moitié défini le rend généralement plus lent, pas plus rapide. Les vrais accélérateurs sont peu reluisants : décidez ce que vous laissez de côté, répondez vite aux questions et résistez à l'envie d'ajouter des choses en cours de développement.

Le plus important de loin, c'est un périmètre impitoyable. Plus votre première version est petite et claire, plus tôt elle se lance, et une application lancée qui gagne sa place vous apprend davantage en deux semaines que deux mois de planification supplémentaires. Vous pouvez toujours ajouter. Vous ne pouvez pas récupérer les mois passés à construire des fonctionnalités dont personne ne voulait, finalement.

Il y a une vérité connexe qu'il vaut la peine de dire à voix haute : tout n'a pas besoin d'être une application sur mesure. Parfois, le vrai problème est une portion de travail manuel qu'une automatisation pourrait traiter discrètement, sans aucune application. Un bon partenaire vous le dira quand c'est le cas, plutôt que de vous vendre le développement plus gros, car l'application la moins chère est celle que vous n'avez pas eu à faire.

Questions fréquentes