Projets informatiques : ce que disent vraiment les chiffres sur les dépassements et les échecs

Les chiffres à retenir

• Sur un échantillon de 1 471 projets informatiques, Bent Flyvbjerg et Alexander Budzier (Université d'Oxford) ont mesuré en 2011 un dépassement de coût moyen de 27 %.
• Dans cette même étude publiée par la Harvard Business Review, un projet sur six dépassait son budget de 200 % en moyenne et son calendrier de près de 70 %.
• Sur 5 392 projets informatiques achevés entre 2002 et 2014, l'étude de Flyvbjerg et de ses coauteurs publiée en 2022 trouve un projet médian qui respecte son budget.
• Selon cette étude de 2022, les dépassements de coût des projets informatiques suivent une loi de puissance : les dérapages extrêmes sont rares mais bien plus fréquents qu'on ne le suppose.
• Une étude publiée en 2012 par McKinsey et le BT Centre for Major Programme Management de l'Université d'Oxford, citée par Flyvbjerg et ses coauteurs, indique que les grands projets informatiques dépassent leur budget de 45 % en moyenne.
• Sur 1 355 projets informatiques publics, Budzier et Flyvbjerg calculent que chaque année de durée supplémentaire augmente le risque moyen de dépassement de coût de 4,2 points.
• Dans l'enquête Stripe de 2018, les développeurs estiment consacrer 17,3 heures par semaine à la maintenance du code, et 20,9 heures en France.
• Le CISQ estime le coût de la mauvaise qualité logicielle aux États-Unis à au moins 2 410 milliards de dollars en 2022, dont environ 1 520 milliards de dette technique.

De combien les projets informatiques dépassent-ils leur budget ?

Les grandes bases de données de projets donnent deux réponses complémentaires : le projet typique reste proche de son budget, mais une minorité dérape de plusieurs fois son montant initial. Flyvbjerg et Budzier ont mesuré sur 1 471 projets un dépassement moyen de 27 %, avec un projet sur six dont le dépassement atteint 200 % en moyenne.

Les auteurs parlent de « cygnes noirs » pour désigner ces projets rares mais dévastateurs. Leur article rappelle que des projets informatiques hors de contrôle ont coûté leur poste à des dirigeants et fait tomber des entreprises entières. Le message central n'est pas que les projets informatiques dérapent tous : c'est que le risque se loge dans la queue de la distribution, là où les moyennes ne regardent pas.

Pourquoi la moyenne des dépassements trompe-t-elle ?

La moyenne trompe parce que les dépassements de coût des projets informatiques suivent une loi de puissance, selon l'étude de Flyvbjerg, Budzier et de leurs coauteurs publiée en 2022 dans le Journal of Management Information Systems. Le projet médian tient son budget, mais la queue de distribution est si épaisse que la variance n'est pas définie et que, selon les auteurs, une moyenne des dépassements n'a guère de sens.

Le cas extrême est parlant : ce n'est pas un chantier géant, mais un petit projet de personnalisation de workflow. Les auteurs avancent une explication : les composants techniques d'un système sont interdépendants, et un problème sur un seul composant peut déclencher une réaction en chaîne sur les autres. Ils en concluent qu'il faut évaluer le risque de coût dès le départ, en repérant les composants fortement liés au reste du système. Dans un projet de PME, ce sont typiquement la connexion à l'ERP ou à la comptabilité et la reprise de données anciennes.

Les projets publics et les projets longs dérapent-ils davantage ?

Sur 1 355 projets informatiques publics, Budzier et Flyvbjerg trouvent que le projet typique n'a pas de dépassement de coût mais dure 24 % de plus que prévu, et que 18 % des projets dépassent leur budget de plus de 25 %. Chaque année de durée supplémentaire ajoute 4,2 points de risque moyen de dépassement.

Deux enseignements concernent directement une PME. D'abord, un progiciel standard n'élimine pas le risque : 24 % des projets de ce type dépassent leur budget de plus de 25 % dans cet échantillon, contre 18 % pour l'ensemble. Ensuite, la durée est un facteur de risque en soi, ce qui plaide pour des livraisons découpées en lots courts plutôt qu'un tunnel de deux ans.

Combien coûtent la dette technique et la maintenance ?

Dans l'enquête « The Developer Coefficient » publiée par Stripe en septembre 2018, les développeurs estiment passer 17,3 heures par semaine en moyenne sur la maintenance, dont 13,5 heures sur la dette technique, pour une semaine de 41,1 heures. La France affiche la moyenne la plus élevée des pays interrogés, avec 20,9 heures.

Ces montants décrivent l'après-projet : un logiciel livré dans les temps mais difficile à faire évoluer coûte ensuite, chaque semaine, du temps de développement. Le CISQ, consortium cofondé par l'Object Management Group et le Software Engineering Institute de l'université Carnegie Mellon, présente la dette technique comme le principal obstacle à toute modification des bases de code existantes. La notion est expliquée dans notre fiche dette technique, et la page moderniser un logiciel ancien traite de sa réduction.

Que valent les taux d'échec du rapport CHAOS ?

Les taux de réussite et d'échec du rapport CHAOS du Standish Group sont très repris, mais l'éditeur ne les publie pas en accès libre : ses rapports sont vendus, et les pourcentages qui circulent en ligne proviennent de reprises secondaires que YMHB Web n'a pas pu vérifier à la source.

Le Standish Group présente son rapport « Decision Latency Theory » de 2018 comme fondé sur plus de 50 000 profils de projets et consacré aux causes profondes de la réussite ou de l'échec des projets logiciels, avec pour fil conducteur la latence de décision. Les chiffres du Pulse of the Profession du Project Management Institute, autre source souvent citée, n'ont pas pu être consultés sur le site de l'éditeur en octobre 2026 : ils ne sont pas repris ici.

Le programme de recherche DORA suit cinq mesures de la performance de livraison logicielle, réparties entre débit et instabilité. Ses travaux concluent de façon répétée que vitesse et stabilité ne s'opposent pas : les équipes les plus performantes réussissent sur les cinq mesures à la fois.

Qu'est-ce qui réduit le risque, selon ces études ?

Les études convergent vers trois leviers : estimer le risque dès le départ, réduire la complexité et la durée de chaque étape, et livrer souvent. Budzier et Flyvbjerg recommandent de situer son organisation par rapport aux autres, de corriger les biais dans les décisions, de réduire la complexité des projets et de former des maîtres d'œuvre aguerris, qu'ils appellent « Masterbuilders ».

Traduit en pratique pour un logiciel métier :

1. Un cadrage avant tout prix, qui cartographie les flux, les données et les connexions aux autres logiciels, c'est-à-dire les composants interdépendants où naissent les dérapages. Le cahier des charges d'un logiciel métier en détaille le contenu.
2. Un périmètre écrit, exclusions comprises, pour que chaque demande nouvelle soit identifiée et arbitrée. Le choix du contrat compte aussi, voir forfait ou régie.
3. Des lots courts, puisque chaque année de durée ajoute du risque, avec une version testable entre les mains des utilisateurs.
4. Une recette organisée, avec des critères d'acceptation connus d'avance, comme le décrit le guide de la recette logicielle.

Ce que ces chiffres signifient pour une PME

Ces études portent surtout sur des projets plus gros que ceux d'une PME : 130 millions de dollars en moyenne pour l'échantillon public de Budzier et Flyvbjerg. Leurs conclusions s'appliquent pourtant à petite échelle, puisque le dépassement record de l'étude de 2022 concerne un projet budgété 1 500 dollars.

Pour un dirigeant, trois réflexes en découlent. Regarder le pire scénario plausible plutôt que la moyenne. Identifier les points de contact avec l'existant (comptabilité, ERP, données à reprendre), car c'est là que les dépendances se nouent. Et refuser les projets en tunnel, sans version utilisable avant la fin.

C'est la logique de la méthode de YMHB Web : le chiffrage suit le cadrage, le périmètre liste aussi ce qui n'est pas inclus, la construction avance par cycles courts avec une version testable accessible en permanence, et le code appartient au client au paiement intégral. Ce dernier point limite un autre risque, celui de rester captif d'un prestataire si le projet se passe mal.

Méthode et limites

• Périmètres différents. L'étude de 2011 porte sur 1 471 projets, celle de 2012 sur 1 355 projets publics de grande taille, celle de 2022 sur 5 392 projets de 66 pays achevés entre 2002 et 2014, publics et privés. Aucune ne porte spécifiquement sur des PME françaises.
• Définition du dépassement. L'étude de 2022 compare le coût réel au coût estimé lors de la décision finale d'investissement. Un projet dont le périmètre a été volontairement élargi apparaît donc en dépassement.
• Biais de sélection. Les auteurs de 2022 notent que les entreprises qui acceptent de partager leurs données sont probablement celles qui suivent le mieux leurs projets : le risque réel pourrait être sous-estimé.
• Sources secondaires. Le chiffre de 45 % de l'étude McKinsey et Université d'Oxford de 2012 est repris tel que cité dans l'article de 2022 ; la page de McKinsey n'a pas pu être consultée directement en octobre 2026.
• Enquêtes déclaratives. Les heures de l'enquête Stripe sont des estimations déclarées par les répondants, pas des mesures. Les chiffres du CISQ concernent les États-Unis uniquement.
• Ce qui manque. Aucune statistique nationale récente sur les dépassements des projets informatiques des entreprises françaises n'a été trouvée en accès libre lors des recherches menées en octobre 2026.