Combien de temps faut-il pour développer une app ? Une vraie réponse

Les fourchettes honnêtes, les quatre facteurs qui font vraiment bouger le chiffre et comment un fondateur non technique peut lire l’estimation d’un développeur sans se faire avoir.

Une fondatrice avec qui nous avons travaillé l’an dernier avait déjà annoncé à son investisseur principal que l’app serait prête en huit semaines. Elle tenait le chiffre d’un freelance qui avait survolé une description d’un paragraphe et lâché « ouais, deux mois ». Quatre mois plus tard, elle était toujours en développement, l’investisseur posait des questions pointues à chaque call, et elle était convaincue que l’équipe était lente. L’équipe n’était pas lente. L’estimation était une fiction, et elle l’avait répétée à la seule personne avec qui elle avait le plus besoin de garder la confiance.

Alors : combien de temps faut-il pour développer une app ? Pour la plupart des produits en phase initiale, une première version crédible prend de trois à six mois, d’un périmètre clair jusqu’à quelque chose qu’un client payant peut utiliser. Un petit outil interne se livre en quatre à huit semaines. Un produit transactionnel ou réglementé (paiements, données de santé, tout ce qui touche à la conformité) prend six à neuf mois ou plus. Ces fourchettes supposent une équipe concentrée, un périmètre défini et un fondateur qui décide vite. Changez l’une de ces variables et le chiffre bouge, parfois beaucoup.

Voilà la réponse. Le reste de cet article explique pourquoi les fourchettes sont aussi larges et comment savoir si le chiffre précis qu’on vient de vous donner est réel.

« Combien de temps » est la mauvaise première question

Quand un fondateur demande combien de temps prend une app, il veut généralement dire l’une de trois choses différentes, et la réponse change pour chacune.

Il y a le démo : quelque chose que vous affichez à l’écran pendant un pitch, que vous parcourez et qui sert à raconter une histoire. Il y a la première vraie version : quelque chose qu’un client payant utilise pour de bon, avec de vraies données, de vrais cas limites et les parties ennuyeuses qui rendent un logiciel fiable (authentification, gestion des erreurs, un moyen de réparer quand ça casse). Et il y a la vision complète : le produit tel que vous l’avez décrit au tableau, avec toutes les fonctionnalités.

Ce ne sont pas le même projet, et ils ne sont pas sur le même calendrier. Le démo peut prendre deux semaines. La première vraie version, c’est le chiffre de trois à six mois ci-dessus. La vision complète prend en général un an ou plus, et vous ne voulez presque jamais la construire d’un seul tenant, parce que le marché va vous apprendre que la moitié est fausse.

L’erreur la plus coûteuse que nous voyons, c’est le fondateur qui cite à son conseil le délai du démo tout en s’attendant à voir arriver la première vraie version. Donc, avant de demander combien de temps, décidez laquelle des trois vous cherchez vraiment à livrer, pour quand et pourquoi cette date compte. « Combien de temps jusqu’à quoi » est la question qui donne une réponse utile.

Ce qui fait vraiment bouger le chiffre

Deux apps qui semblent identiques en une phrase peuvent être à trois mois d’écart dans la réalité. Quatre facteurs expliquent l’essentiel de cet écart.

La clarté du périmètre. La plus grande variable n’est pas la taille de l’app. C’est à quel point elle est clairement définie. Un produit bien cadré, avec un document d’exigences à partir duquel un studio peut chiffrer, se construit plus vite qu’un vague « comme Airbnb mais pour X », parce que l’équipe ne refait pas le même écran trois fois pendant que vous découvrez ce que vous vouliez dire. L’ambiguïté n’apparaît pas comme une ligne de budget. Elle apparaît en semaines.

Les intégrations. Chaque fois que votre app doit parler à quelque chose que vous ne contrôlez pas (un prestataire de paiement, une banque, un ERP, une API publique, un service tiers instable), vous avez ajouté un risque que vous ne pouvez pas bien estimer d’avance. Une intégration, ça va. Cinq intégrations, chacune avec sa propre qualité de documentation et ses limites de requêtes, c’est là que les délais doublent en silence. Nous avons vu une fonctionnalité de deux semaines en devenir six parce qu’une API externe se comportait tout autrement que ce que sa documentation promettait.

Les données et la conformité. Une app qui stocke des noms et des e-mails, c’est une chose. Une app qui gère de l’argent, des dossiers médicaux ou tout ce qui intéresse un régulateur, c’en est une autre. Le travail de conformité, c’est de la vraie ingénierie, pas de la paperasse qu’on ajoute à la fin, et ça ne se comprime pas. Si vous êtes dans la fintech ou la healthtech, intégrez les mois supplémentaires dès le premier jour.

La forme de l’équipe. Une équipe concentrée qui a déjà construit des systèmes similaires avance plus vite qu’une équipe plus grande qui se constitue pour la première fois. Plus de monde ne veut pas dire plus de vitesse. Au-delà d’un petit nombre, le coût de coordination mange le gain. C’est pourquoi un partenaire compétent qui a déjà livré le même schéma l’emporte souvent sur le recrutement de quatre ingénieurs qui passent ensuite les deux premiers mois à apprendre à travailler ensemble.

Les trois choses qui font exploser les délais en silence

Les fondateurs s’attendent à ce que les délais glissent à cause de la « complexité technique ». En pratique, ce qui détruit les estimations est rarement technique. Ce sont des décisions.

La première, c’est un périmètre indéfini déguisé en spec terminée. Un document qui dit « l’utilisateur peut gérer son profil » paraît complet jusqu’à ce que le développement commence et que l’équipe découvre que personne n’a décidé ce qui est modifiable, ce qu’il advient des anciennes données, ou si un admin peut le faire aussi. Chacune de ces interrogations est une question, et chaque question qui attend une réponse est une tâche à l’arrêt. Une vraie phase de discovery anticipe ces questions pour qu’elles ne surgissent pas en plein développement.

La deuxième, c’est la roulette de l’intégration. Vous ne pouvez pas savoir combien de temps prend une intégration avant d’être dedans. Les bonnes équipes réduisent ce risque en touchant chaque dépendance externe dans les deux premières semaines, pas les deux dernières. Si votre équipe n’a même pas regardé l’API dont elle dépend à la troisième semaine, votre délai est déjà en danger et personne ne vous l’a encore dit.

La troisième, et celle que les fondateurs provoquent eux-mêmes, c’est la taxe de lenteur de décision. Un logiciel se construit à la vitesse du décideur le plus lent, et sur un petit projet, ce décideur, c’est généralement vous. Chaque « laissez-moi réfléchir » sur un choix de design, chaque message Slack sans réponse sur le sens d’un parcours, c’est quelqu’un à l’arrêt ou, pire, en train de construire la mauvaise chose. Nous avons vu un projet de trois mois s’étirer à quatre parce que la fondatrice était en déplacement et que les questions s’étaient accumulées. Le code n’a jamais été le goulot d’étranglement.

Une fourchette réaliste par type de projet

Voici la carte approximative que nous donnons aux fondateurs avant tout cadrage détaillé. Traitez-la comme un point d’ancrage, pas comme une promesse. L’estimation détaillée vient du périmètre.

Remarquez : ce qui coûte le moins cher à sous-estimer, c’est le milieu ennuyeux, la première vraie version. Le fondateur chiffre mentalement le démo, puis tombe des nues quand le travail de qualité production coûte plus. Il coûte plus parce que « ça marche dans le démo » et « ça marche quand un vrai client arrive à 23 h avec une mauvaise saisie » sont deux problèmes d’ingénierie différents. Pour le versant financier de la même décision, voyez combien coûte la construction de la même app, parce que le temps et l’argent vont ensemble, mais pas en synchronie parfaite.

Comment lire une estimation qu’on vous a donnée

Quand quelqu’un vous donne un délai, vous n’évaluez pas s’il est intelligent. Vous évaluez si le chiffre repose sur quelque chose. Trois tests rapides.

Demandez sur quoi il se fonde. Une estimation fiable renvoie à un périmètre : « avec ces écrans et cette intégration, six à huit semaines ». Une estimation peu fiable ne renvoie à rien : « deux mois ». Steve McConnell, qui a écrit plus que presque personne sur l’estimation logicielle, décrit l’incertitude initiale comme un cône qui se resserre seulement à mesure que le périmètre se définit. Au début, une estimation sérieuse peut se tromper d’un facteur quatre dans un sens comme dans l’autre, et elle ne se resserre que lorsque le travail devient concret. Un chiffre donné avant l’existence du périmètre, c’est une devinette en costume.

Demandez une fourchette, pas une date. Les vraies estimations ont des marges d’erreur au début, et elles se resserrent à mesure que le travail se définit. Une équipe qui vous donne une date unique et confiante pour un projet indéfini est soit inexpérimentée, soit en train de vous gérer. « Six à huit semaines, et on saura laquelle après les deux premières » est la forme d’une réponse honnête.

Demandez ce qui le ferait durer plus longtemps. La réponse vous dit si l’équipe a vraiment réfléchi à votre projet. Une bonne équipe vous renverra vos risques spécifiques : « l’intégration bancaire est l’inconnue ; si leur sandbox est lent, ajoutez deux semaines ». Une équipe qui dit « rien, c’est maîtrisé » n’a pas regardé d’assez près. Que vous ayez structuré la mission au forfait ou en régie change qui porte ce risque, mais ne le fait jamais disparaître.

Ce que vous pouvez faire cette semaine pour livrer plus vite

Vous avez plus de prise sur le délai que vous ne le pensez, et presque rien n’est technique.

Taillez la première version plus fort que ce qui paraît confortable. La majeure partie de ce qui est sur votre tableau n’est pas nécessaire pour mettre le produit devant un client payant, et chaque fonctionnalité que vous reportez, c’est du temps récupéré tout de suite. La discipline de livrer moins est la vitesse la moins chère à votre portée.

Rendez le périmètre concret avant que le développement commence, pas pendant. Une après-midi à trancher les cas ambigus en amont vous épargne des semaines d’arrêts en cours de route. Écrivez ce qui est dedans et, surtout, ce qui est dehors.

Ensuite, protégez la vitesse de l’équipe en restant disponible. Décidez vite, répondez aux questions le jour même, et ne disparaissez pas une semaine en espérant que le délai tienne. Un logiciel se construit à la vitesse de vos décisions. Si vous traitez le développement comme quelque chose qui se passe sans vous, il prendra exactement la durée de votre semaine la plus lente, multipliée sur l’ensemble du projet.

Rien de tout cela n’exige que vous lisiez du code. Cela exige que vous traitiez le délai comme quelque chose que vous copossédez avec l’équipe, pas comme un chiffre que vous lui extorquez avant de croiser les doigts. Les fondateurs qui livrent à temps ne sont pas ceux qui ont trouvé des développeurs plus rapides. Ce sont ceux qui ont demandé « combien de temps jusqu’à quoi », cadré honnêtement et se sont écartés du chemin du développement.

Questions fréquentes

Combien de temps faut-il habituellement pour développer une app ?
Pour une première vraie version qu’un client payant peut utiliser, de trois à six mois, avec une équipe concentrée et un périmètre clair. Un petit outil interne peut prendre de quatre à huit semaines. Un produit transactionnel ou réglementé prend en général six à neuf mois ou plus.

Quel est le délai moyen de développement d’une app ?
Il n’y a pas de moyenne qui vaille la peine d’être citée, parce qu’« une app » va d’un démo d’une semaine à une plateforme d’un an. Les repères utiles sont par type de projet : outil interne (4–8 semaines), première vraie version du produit (3–6 mois), place de marché (5–8 mois), produit réglementé (6–9+ mois).

Quelles sont les sept étapes du développement d’une app ?
Les étapes que l’on liste (discovery, design, développement, intégration, tests, lancement, maintenance) comptent moins que de savoir lesquelles consomment le temps. Sur la plupart des projets, le discovery et l’intégration dévorent bien plus du calendrier que le fondateur ne l’imagine, et les tests sont l’étape sacrifiée sous la pression, celle qui cause le retard plus tard.

À quelle vitesse une app peut-elle être développée ?
Un démo cliquable peut être prêt en une à deux semaines. Mais « vite » signifie souvent couper les parties qui rendent un logiciel fiable, donc la vitesse achetée avant que le périmètre soit défini est presque toujours une dette contre un retard futur. Les développements vraiment rapides viennent du fait de couper dans le périmètre, pas de couper les coins.