8 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Vous préparez une levée de fonds, ou une demande de financement, pour faire développer votre application. Il vous faut un chiffre. Vos investisseurs le demandent, votre plan de financement aussi.
La question « combien ? » est légitime. Elle n’est pourtant qu’une partie de la réponse. Un même montant peut financer une application que personne n’utilise, ou une application dont vos clients se servent depuis des mois. Ce qui fait la différence, ce n’est pas la somme. C’est la façon de construire l’application avec cette somme.
Les guides qui répondent à « combien coûte de développer une application » suivent presque tous la même méthode. On liste les fonctionnalités. On attribue à chacune un nombre de jours, simple, moyen ou complexe. On ajoute une marge pour les imprévus, puis la maintenance de la première année. Il en sort une fourchette.
Cette méthode tient sur deux appuis : une estimation, et une liste de fonctionnalités. Nous ne nous appuyons sur aucun des deux.
Pourquoi une estimation reste une supposition, nous l’avons détaillé dans notre article sur les dépassements de budget. Ici, c’est la liste qui nous intéresse. Son défaut est moins visible. Elle déplace l’attention.
Martin Fowler, l’un des signataires du Manifeste agile et directeur scientifique de Thoughtworks, a donné un nom à ce glissement : la FeatureDevotion. C’est l’état dans lequel on accorde plus de valeur au fait de cocher des fonctionnalités qu’au résultat réel du projet. Un budget construit ligne à ligne sur une liste y mène presque naturellement, puisque chaque ligne cochée devient la preuve que l’argent a été bien dépensé.
L’erreur la plus courante se trouve là. On confond l’objectif à atteindre avec les choses à construire. On croit qu’en livrant les fonctionnalités prévues, on atteindra l’objectif.
Or une liste de fonctionnalités n’est qu’une hypothèse sur le chemin. Dave Farley, ingénieur logiciel et coauteur du livre Continuous Delivery, rappelle ce que disent les données du secteur : même dans les meilleures entreprises de logiciel au monde, deux idées sur trois ne produisent aucune valeur, ou une valeur négative (Modern Software Engineering, p. 51). Personne ne sait d’avance lesquelles. Ronny Kohavi a dirigé l’équipe d’expérimentation de Microsoft. Avec ses collègues, il arrive au même constat (« Online Experimentation at Microsoft », 2009) : environ un tiers seulement des idées censées améliorer un indicateur l’améliorent.
Allen Holub, architecte logiciel et formateur en agilité des organisations, le dit en une phrase : « Building the wrong thing on time and in budget doesn’t buy you much. » Construire la mauvaise chose dans les délais et dans le budget ne rapporte pas grand-chose.
Ce qui compte, c’est donc de savoir si l’objectif est atteint. Pas de savoir quelles fonctionnalités ont été livrées.
Le peu que l’on construit doit viser juste. Dès le premier mois de développement, l’application fonctionne. Elle fait peu de choses. Mais ce qu’elle fait crée de la valeur sur l’essentiel, aux yeux des personnes à qui vous voulez la vendre.
Ensuite, elle continue de fonctionner, à tout moment. C’est la raison d’être de la livraison continue : chaque modification est vérifiée avant d’arriver dans l’application, pour que ce qui marchait hier marche encore aujourd’hui.
Il ne s’agit pas d’aller loin. Chaque jour, la question est la même : quelle est la chose la plus utile à faire aujourd’hui ? C’est ce que permet l’approche adaptative. Elle va vite à l’essentiel. Puis elle garde l’attention, chaque jour, sur la valeur attendue ce jour-là.
Les personnes à qui vous voulez vendre l’application sont celles qui savent ce qui est essentiel. Interrogées à l’avance, elles ne savent pas toujours le dire. Farley le constate aussi : même quand on demande aux utilisateurs ce qu’ils veulent, ils ne le savent pas (p. 51). Devant une application qui fonctionne, en revanche, elles réagissent.
La boucle de retours démarre donc le plus tôt possible. L’application passe entre leurs mains. On écoute ce qu’elles en disent. On ajuste. Et on recommence.
Avant même de construire, une idée peut d’ailleurs se tester : c’est le rôle d’un MVP.
Supposons que la boucle ne s’ouvre qu’au bout de six mois de développement. Ce n’est plus une boucle. Ce sont plusieurs boucles à la fois.
Les retours arrivent ensemble : ce qui manque, ce qui gêne, ce qui ne sert pas. Chacun appelle une modification. On ne sait plus par laquelle commencer. Et six mois de développement sur une liste fixée au départ ont consommé une bonne partie du budget.
Le manque d’argent n’est d’ailleurs presque jamais la cause première. CB Insights, une société qui analyse les entreprises non cotées, a étudié 385 jeunes entreprises financées par du capital-risque et fermées depuis 2023. 70 % ont manqué de fonds. Le rapport précise que c’est presque toujours la cause finale de la fermeture, pas le problème de départ. Pour 43 % d’entre elles, le produit ne trouvait pas son marché (CB Insights, mars 2026).
Quand on a passé des mois à construire des choses dont personne n’avait besoin, il reste une leçon que personne n’a tirée. C’est ce que nous trouvons le plus dommage. Personne n’a expliqué ce qu’est un code de qualité, ni ce qu’il vaut.
Un code de qualité, c’est un code que l’on peut modifier facilement.
Farley le dit à sa manière : on découvre souvent qu’une conception est bonne ou mauvaise au moment où l’on essaie de la modifier (p. 108). Il rappelle aussi le sous-titre que Kent Beck a choisi pour son livre sur l’Extreme Programming : Embrace Change, accueillir le changement. Selon Farley, tout le reste découle de cette idée : garder la capacité de changer d’avis, de code, de technologie, à mesure qu’on apprend (p. 155).
Pour une application construite à partir des retours de ses utilisateurs, cette capacité décide de tout. Chaque retour demande une modification. Si chaque modification coûte cher, ou casse autre chose, la boucle ralentit, et le budget part en réparations. Farley le résume ainsi : sur la durée, on ne choisit pas entre un logiciel meilleur et un logiciel plus rapide à produire, on choisit entre « better software faster » et « worse software slower » (p. 154).
Pour une levée de fonds, il faut tout de même un montant. Ce montant ne s’obtient pas en additionnant des fonctionnalités. Il s’obtient en décidant ce que vous investissez chaque mois, et pendant combien de mois vous voulez pouvoir apprendre de vos utilisateurs avant la décision suivante.
Holub fait le même raisonnement. Quand l’équipe dépense chaque mois la même somme, le budget et la date se confondent. Si le budget est fixé, la seule variable qui reste, c’est le périmètre. Martin Fowler arrive au même endroit : un prix fixe est possible, un périmètre fixe ne l’est pas. On choisit ensemble, en chemin, les fonctionnalités les plus utiles.
L’approche adaptative prédit ce qui est prévisible : le budget mensuel et les jours de développement par mois. Elle ne cherche pas à prédire l’imprévisible : ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains.
Chez DEVEDANOS, c’est ainsi que nous travaillons. Nous développons votre application sur mesure pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer.
Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez. Nous appliquons le jour même ce que l’usage nous apprend sur une fonctionnalité. Une application vivante n’est jamais finie : si l’on cesse de la faire évoluer, elle ne reçoit plus que des correctifs de sécurité et des mises à jour des composants sur lesquels elle repose, et c’est une application qui se meurt.
Ce qui est fixé, c’est le budget et le problème à résoudre. Votre enveloppe achète du travail pour atténuer ce problème en permanence, dès le premier jour de développement. Nous visons sa résolution complète, sans pouvoir la garantir ni la dater. Vous n’attendez pas ce jour-là pour que l’atténuation commence. Chaque mois vous voyez ce qui en sort, et vous décidez de continuer.
Fixer à la fois le prix et la liste des fonctionnalités, ou payer au temps passé : qui porte le risque quand le besoin change, c’est le sujet de notre article sur le forfait et la régie.
Vous levez des fonds pour développer votre application, ou vous cherchez le bon budget ? On en parle ?
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.
Approche prédictive ou adaptative ? La vraie différence n'est pas entre le cycle en V et l'agilité, mais entre prédire et s'adapter. Ce que cela change pour un logiciel.