Réussir son projet informatique : ce que trente ans d'échecs nous apprennent

Trente ans de rapports CHAOS : le constat n’a pas changé

En 1994, le Standish Group publie son premier rapport CHAOS à partir de l’analyse de plusieurs milliers de projets logiciels aux États-Unis. Le constat est brutal : à peine 16 % des projets aboutissent dans les délais, le budget et le périmètre fonctionnel prévus. Près d’un tiers sont purement et simplement annulés. Les projets qui survivent coûtent en moyenne 189 % de leur estimation initiale.

Trente ans et une quinzaine d’éditions plus tard, les chiffres ont à peine bougé. Le rapport CHAOS 2020 indique que 31 % des projets sont considérés comme des succès, 50 % sont livrés en souffrance (retard, surcoût, périmètre amputé) et 19 % échouent totalement. Les petits projets s’en sortent nettement mieux, avec un taux de réussite avoisinant 90 %. Les grands programmes, eux, affichent un taux de succès inférieur à 10 %.

En 2024, une enquête Gartner confirme la tendance : seuls 48 % des projets atteignent pleinement leurs objectifs. L’étude Bain de la même année est encore plus sévère, estimant que 88 % des transformations digitales échouent à atteindre leurs ambitions initiales. Le coût global de ces échecs est estimé à 2 300 milliards de dollars par an.

Ces chiffres ne sont pas un phénomène anglo-saxon. Une analyse européenne aboutit à des résultats comparables : environ 30 % de projets réussis et 20 % d’échecs complets.

Le prix de la mauvaise qualité logicielle

Au-delà des projets qui échouent, il y a ceux qui fonctionnent mal. Le Consortium for Information & Software Quality (CISQ), rattaché à l’université Carnegie Mellon, estime dans son rapport 2022 que le coût de la mauvaise qualité logicielle aux États-Unis atteint 2 410 milliards de dollars par an. Ce montant englobe les pannes opérationnelles, la maintenance de systèmes obsolètes, les failles de cybersécurité et les projets avortés. La dette technique accumulée représente à elle seule 1 520 milliards de dollars.

Les organisations du Global 2000 perdent collectivement 400 milliards de dollars par an en pannes informatiques. En 2024, 54 % des pannes majeures en datacenter ont coûté plus de 100 000 dollars chacune. Le coût moyen d’une minute d’indisponibilité atteint 14 056 dollars, et dépasse 5 millions de dollars par heure pour certaines entreprises du Fortune 500.

Quand les bugs font des victimes : trois fiascos modernes

Le scandale Horizon de la Post Office britannique

C’est probablement le pire désastre informatique de l’histoire en termes de conséquences humaines. Entre 1999 et 2015, le logiciel comptable Horizon, développé par Fujitsu pour la Post Office britannique, a généré de faux déficits dans les comptes de milliers de bureaux de poste. Plutôt que d’admettre les défauts du système, la Post Office a poursuivi ses propres gérants.

Le bilan est accablant. Plus de 900 gérants de bureaux de poste ont été condamnés à tort pour vol ou fraude. Certains ont été emprisonnés, d’autres ont fait faillite, perdu leur maison, vu leur famille éclater. Au moins treize personnes se sont suicidées. Le Premier ministre Rishi Sunak a qualifié l’affaire de plus grande erreur judiciaire de l’histoire britannique.

L’enquête publique, qui s’est achevée en décembre 2024, a révélé que Fujitsu savait que le système comportait des erreurs pouvant causer des pertes inexpliquées, mais a continué à témoigner en justice que le logiciel était fiable. La police métropolitaine enquête désormais pour homicide involontaire d’entreprise contre la Post Office. Le coût des indemnisations devrait dépasser le milliard de livres sterling. Et le système Horizon, faute de remplacement réussi, est toujours en service.

Phoenix : le système de paie qui a ruiné les fonctionnaires canadiens

En 2016, le gouvernement canadien déploie Phoenix, un système centralisé de paie destiné à remplacer un logiciel vieillissant. Le résultat est catastrophique : des centaines de milliers de fonctionnaires sont mal payés, pas payés, ou trop payés. Certains se retrouvent dans l’incapacité de payer leur loyer. D’autres reçoivent des avis d’imposition erronés des années plus tard.

Fin mars 2025, plus de 349 000 erreurs restaient non résolues, dont 53 % en attente depuis plus d’un an. Le coût total pour le contribuable canadien dépasse 5,1 milliards de dollars canadiens (3,6 milliards de dollars US). Le gouvernement a dépensé au moins 100 millions de dollars rien que pour choisir un remplaçant, qui coûtera plusieurs centaines de millions supplémentaires et prendra des années à déployer.

CrowdStrike : la mise à jour qui a paralysé le monde

En juillet 2024, une mise à jour défectueuse du logiciel de cybersécurité Falcon Sensor de CrowdStrike provoque l’écran bleu de la mort sur 8,5 millions de machines Windows dans le monde entier. Aéroports, hôpitaux, banques, commerces : tout s’arrête simultanément.

Les pertes financières globales dépassent 10 milliards de dollars. Delta Air Lines perd à elle seule 500 millions de dollars. Les hôpitaux absorbent 1,94 milliard de dollars de surcoûts en basculant sur des processus manuels. Le problème n’était pas la correction logicielle, diffusée rapidement par CrowdStrike, mais le temps nécessaire pour redémarrer manuellement des millions de machines dispersées sur toute la planète.

Pourquoi les projets continuent d’échouer

Les causes identifiées par le Standish Group en 1994 restent remarquablement actuelles. Les trois facteurs principaux de succès n’ont pas changé en trente ans : l’implication des utilisateurs, le soutien de la direction, et la clarté des exigences. À l’inverse, les projets échouent toujours pour les mêmes raisons.

Le cahier des charges est flou ou incomplet. Près d’un quart des projets échouent à cause d’exigences mal définies. Certains donneurs d’ordre rédigent volontairement des spécifications vagues, espérant pouvoir ajouter des fonctionnalités au fil de l’eau. C’est exactement ce qui tue un projet : chaque ajout non prévu déstabilise le planning, le budget et l’architecture technique.

La complexité est sous-estimée. Les estimations de coût et de délai sont systématiquement optimistes, surtout sur les grands programmes. Le Standish Group observe que les projets dépassant 10 millions de dollars ont des chances de succès proches de zéro.

Le contrôle est défaillant. Planification approximative, suivi financier rapporté au budget global plutôt qu’aux livrables, gestion des modifications inexistante, supervision laxiste des fournisseurs : le cocktail est connu, et toujours aussi fréquent.

La dette technique s’accumule. Les organisations américaines consacrent 520 milliards de dollars par an à la maintenance de systèmes existants, et 70 à 75 % de leurs budgets IT y sont absorbés. Remplacer un système obsolète coûte souvent plusieurs fois le coût de sa maintenance, ce qui pousse les dirigeants à repousser indéfiniment la migration, jusqu’au point de rupture.

L’IA ne changera pas la donne à court terme. Pour ceux qui espèrent que les outils d’IA résoudront le problème, la réponse est non, pas dans un avenir prévisible. Comme le souligne l’IEEE Spectrum, les grands projets IT ne sont pas des démonstrations de prise de décision rationnelle. Ils impliquent des arbitrages entre ingénierie système, gestion de projet, contraintes financières, objectifs métier et politique interne que l’intelligence artificielle ne sait pas naviguer.

Les facteurs de réussite : ce qui fonctionne vraiment

Le Standish Group a fait évoluer ses recommandations au fil des éditions du rapport CHAOS. En 2020, trois facteurs ont été ajoutés : un bon environnement de travail, une équipe compétente et un sponsor engagé.

Mais la recommandation la plus radicale concerne l’approche même du projet. Le Standish Group préconise désormais d’arrêter de traiter le développement logiciel comme un projet avec une fin définie. Un projet a un budget, un délai, un périmètre figé. Lorsqu’il est livré, les utilisateurs découvrent que leurs besoins ont changé. L’approche recommandée consiste à adopter un développement continu par petites améliorations successives, testées et validées au fur et à mesure par les utilisateurs.

Voici les principes qui augmentent significativement les chances de réussite.

Impliquer les utilisateurs dès le départ et tout au long du processus. C’est le facteur de succès numéro un depuis trente ans. Un système développé sans ses futurs utilisateurs ne sera pas utilisé.

Découper le projet en petites unités livrables. Les méthodes agiles ont prouvé leur efficacité : livrer tôt et souvent permet de valider les choix, de corriger rapidement les erreurs et de réajuster les priorités. Les petits projets ont un taux de réussite proche de 90 %.

Obtenir un sponsor engagé au plus haut niveau. Sans soutien de la direction, un projet est condamné dès que survient le premier obstacle politique ou budgétaire.

Formuler des exigences claires et mesurables. Éliminer les ambiguïtés initiales permet de dresser des spécifications fonctionnelles précises, de chiffrer correctement le projet et de maîtriser les changements de périmètre.

Dimensionner correctement le projet. Plus un projet est gros, plus il risque d’échouer. Si un programme ne peut pas être découpé en sous-ensembles autonomes de taille raisonnable, c’est un signal d’alarme.

Piloter par la valeur livrée, pas par le budget consommé. Contrôler les coûts par rapport aux livrables plutôt que par rapport au budget théorique permet de détecter les dérives avant qu’elles ne deviennent irréversibles.

Désigner un interlocuteur unique côté prestataire. Lorsqu’un projet implique plusieurs fournisseurs, le client ne doit jamais devenir le coordinateur technique. C’est un rôle qui requiert une expertise que le client n’a généralement pas, et que le prestataire principal doit assumer.

Un problème humain avant d’être technique

Si les dépenses IT mondiales ont triplé en vingt ans pour atteindre 5 600 milliards de dollars sans que le taux de réussite des projets ne s’améliore significativement, c’est que le problème n’est pas technique. Les outils, les langages, les méthodologies et les infrastructures se sont considérablement améliorés. Ce qui n’a pas changé, ce sont les travers humains et organisationnels : l’optimisme excessif dans les estimations, la résistance au changement, la politique interne, le manque de communication entre les parties prenantes, et la tentation permanente de sous-investir dans la phase de spécification pour gagner du temps.

La bonne nouvelle, c’est que ces facteurs sont identifiés, documentés et, pour la plupart, évitables. La mauvaise, c’est qu’ils exigent de la rigueur, de la discipline et une volonté de faire les choses correctement dès le départ, ce qui a un coût que peu d’organisations acceptent de payer avant d’avoir subi leur premier échec.