Pourquoi tant de projets de développement logiciel dépassent leur budget initial

Plus d’un projet sur deux dépasse son budget initial. La cause est rarement là où on la cherche. Elle est dans la façon dont le prix a été fixé au départ : une liste de fonctionnalités, une estimation pour chacune, une addition.

Ce que disent les chiffres

Le scénario, vous le connaissez peut-être. Un devis signé, un planning accepté. Puis, entre le deuxième et le sixième mois, un premier avenant que personne n’avait prévu. Puis un second.

Ce n’est pas un cas isolé. 52,1 % des projets, tous types confondus, dépassent le budget estimé, d’après Flyvbjerg, How Big Things Get Done, 2023 (16 000 projets). Sur les projets informatiques, c’est pire : le dépassement moyen atteint 80 % par rapport au devis, d’après Flyvbjerg et al., JMIS 2022 (4 677 projets IT). Sur le même échantillon de 16 000 projets, tous secteurs confondus, 0,5 % seulement des grands projets respectent à la fois le budget, le calendrier et la valeur attendue.

Un projet sur deux, ce n’est plus de la malchance. Ce n’est pas non plus un chef de projet qui aurait mal fait son travail. À cette échelle, c’est la méthode qui est en cause : la façon dont on calcule le prix d’un projet informatique.

Comment l’industrie fixe le prix d’un logiciel

La méthode est la même chez les ESN, les agences et les développeurs indépendants, et elle paraît raisonnable. On liste les fonctionnalités. On estime chacune d’elles : tant de jours pour celle-ci, tant pour celle-là. On additionne, comme on empile des blocs. Et il en sort un budget, au jour près.

Cela ressemble à de la science. Les chiffres sont précis, le tableau est propre, la somme est juste. Mais chaque ligne du tableau est une supposition, et une somme de suppositions n’est pas une mesure. C’est de la pseudo-science : on a la forme d’un calcul, pas ce qui le rend fiable.

Additionner des tâches pour prédire une durée, c’est une idée qui vient de la mécanique. C’est le taylorisme, l’ingénierie industrielle : décomposer en tâches, tout planifier avant de construire quoi que ce soit, livrer une fois le plan terminé. Un siècle plus tard, on gère encore le logiciel comme une chaîne de montage. Or l’ingénierie logicielle n’est pas de l’ingénierie mécanique. Dans le développement logiciel, additionner des tâches n’apporte aucune prévisibilité.

La science le dit depuis longtemps : le tout n’est pas la somme des parties. En 1972, le physicien Philip Anderson (prix Nobel de physique, 1977) publie « More is Different » dans Science. Sa thèse : à chaque niveau de complexité, de nouvelles propriétés émergent qui ne peuvent être prédites en étudiant les parties isolément. Le développement logiciel n’est pas une addition de tâches.

P.W. Anderson, « More is Different », Science, 177(4047), 393–396, 1972.

Une estimation reste une supposition

Il n’existe aujourd’hui aucun outil scientifique pour estimer de façon fiable un temps de développement : les estimations ne sont que des suppositions très hasardeuses, posées sur une liste de fonctionnalités dont l’utilité est encore inconnue de tout le monde.

Cette phrase dit deux choses, qui s’additionnent.

La première : on ne sait pas estimer. Un travail qu’on refait à l’identique devient prévisible, et d’ailleurs on finit par l’automatiser. Un logiciel, lui, se développe toujours pour la première fois. Sinon, on l’installerait.

La seconde : la liste elle-même. Le cahier des charges s’écrit avant que le logiciel n’existe. Et quand Microsoft mesure l’effet de ses idées par expérience contrôlée, une sur trois seulement améliore l’indicateur visé. Un tiers n’a aucun effet, un tiers le dégrade (Kohavi et Thomke, Harvard Business Review, 2017). Quand on chiffre un cahier des charges ligne par ligne, on chiffre donc aussi les deux tiers qui n’apporteront pas la valeur attendue. Personne ne sait encore lesquels.

Certaines équipes disent avoir arrêté d’estimer. En pratique, elles comptent le travail terminé sur une période, en font la moyenne et projettent ce rythme sur la suite. C’est plus honnête qu’une devinette. Mais cela reste une prédiction. On a remplacé une supposition sur l’avenir par une extrapolation du passé. Et si ces équipes en sont arrivées là, c’est parce qu’autour d’elles, on continue de réclamer des prévisions.

Fixer un prix sur une supposition

Fixer un prix sur ces suppositions crée le surcoût dont beaucoup de projets ne se relèvent pas. Et le logiciel n’est pas utilisable pour autant pendant les mois de développement.

Un prix fixé sur une liste de fonctionnalités traite le projet comme un seul bloc, à livrer à la fin. Or un logiciel n’est pas un groupe de fonctionnalités figées. C’est un ensemble de fonctionnalités qui s’utilisent chacune séparément, et qu’on peut livrer une par une. Le bloc, lui, oblige à tout prévoir d’avance, puis à tout attendre jusqu’à la fin.

Quand on fige en même temps le prix et la liste des fonctionnalités, tout le risque retombe sur l’une des deux parties. Et plus personne ne peut s’adapter. Chaque découverte faite en cours de route devient un avenant. Chaque avenant creuse l’écart avec le devis. Le pilotage du projet finit par se résumer à une chose : défendre une liste écrite le jour où l’on en savait le moins.

Pendant ce temps, vos équipes attendent. Elles découvrent le logiciel quand le budget est déjà consommé. Et c’est à ce moment-là que vous apprenez ce dont elles avaient vraiment besoin. Pas avant.

Quel est le prix d’un logiciel sur mesure ?

Le coût du développement d’un logiciel sur mesure repose sur le temps que vous décidez d’investir dans son développement et dans ses ajustements quotidiens pour suivre l’évolution de votre activité, au regard de ce que vous coûte son absence.

Ce que vous coûte son absence, vous le savez déjà. Les mêmes informations saisies dans plusieurs outils qui ne communiquent pas entre eux. Les erreurs que cela produit. La seule personne de l’entreprise qui tient tout cela à jour. Le logiciel payé cher dont vos équipes n’utilisent qu’une partie, et dont l’éditeur ne fait pas les ajustements que vous demandez. C’est à ce chiffre-là qu’il faut comparer l’investissement. Pas à une estimation.

La vie d’un logiciel commence en production. Le traiter comme un projet livré, puis réduire la maintenance au minimum, c’est ce qui le transforme en gouffre au lieu d’en faire un actif. Il coûte d’ailleurs trois à quatre fois plus cher à maintenir qu’à développer (Applied Software Measurement, Capers Jones). La date de fin du projet importe donc assez peu. Ce qui compte, c’est ce que vous investissez sur toute sa durée de vie.

Pour connaître le coût du développement de votre logiciel avec notre approche, où il est utilisable en un mois, contactez-nous.

Décider du temps qu’on investit, mois après mois

Avant de lancer un développement, vous attendez sans doute une durée et un prix. C’est ce qu’on donne d’habitude. Comme si tout pouvait se prévoir. Nous ne savons pas tout à l’avance. Nous préférons le dire. Avancer une durée malgré tout, ce serait vous donner une supposition hasardeuse, que notre métier appelle à tort une estimation. Nous ne le faisons pas.

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. Elle pose une seule question : quelle est la chose la plus utile à faire maintenant ? Et elle y répond avec ce qu’on sait à ce moment-là. Pas avec ce qu’on imaginait le jour du devis.

Elle ne cherche pas non plus la solution complète avant de livrer. Cette recherche-là n’a pas de fin : « vouloir résoudre complètement ou parfaitement un problème, c’est la promesse d’un délai qui va tendre vers l’infini » (Frédéric Leguédois, conférence « Éloge de la simplicité »). On accepte une solution incomplète, on la met au plus tôt entre les mains de vos équipes, et on l’ajuste d’après ce qu’elles en disent.

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é. Elle est utilisable en un mois. Utilisable ne veut pas dire finie : vos équipes s’en servent dès le premier mois, et c’est cet usage qui décide de ce que nous développons le mois suivant. Ensuite, nous l’ajustons à l’évolution de vos besoins aussi longtemps que vous le souhaitez. Le budget ne bouge pas. Ce que nous développons, en revanche, suit ce que vos équipes apprennent en s’en servant.

Votre enveloppe achète du travail sur ce problème, pas sa résolution. Chaque mois vous voyez ce qui en sort, et vous décidez de continuer.

Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons la Garantie Zéro Régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.

Période d’essai jusqu’à 15 jours ouvrés sur le premier mois, et les livrables vous appartiennent dès que vous réglez.

Il n’y a plus d’estimation à dépasser. Il y a un budget que vous avez choisi, et un logiciel que vos équipes utilisent déjà.

Pour aller plus loin

Notre guide reprend ces sources en détail. Vous y trouverez aussi les questions à poser avant de signer un devis de développement.

Vous avez un logiciel à faire développer, ou un outil qui ne suit plus votre activité ? On en parle ?