- Les dépenses IT mondiales ont plus que triplé depuis 2005, mais le taux de réussite des grands projets logiciels ne s’est presque pas amélioré
- Les échecs de gestion, d’organisation et d’éthique se répètent dans le système de paie Phoenix au Canada, le Post Office Horizon au Royaume-Uni, ainsi que dans des systèmes de prestations sociales et d’administration aux États-Unis et en Australie
- Les outils d’IA ou copilots ne peuvent pas résoudre ces problèmes, et le manque d’imagination humaine, des objectifs irréalistes et l’échec de la gestion des risques restent les causes principales
- Les coûts de maintenance des systèmes legacy représentent 70 à 75 % des budgets IT, et même l’adoption d’Agile et de DevOps échoue souvent sans leadership organisationnel ni changement culturel
- Les erreurs de gestion répétées et l’évitement des responsabilités alourdissent le coût social, tandis que la transparence, l’éthique et une conception des systèmes centrée sur l’humain sont présentées comme des priorités essentielles
Le problème persistant des échecs logiciels
- Au cours des 20 dernières années, les dépenses IT sont passées de 1,7 à 5,6 billions de dollars, mais le taux de réussite des logiciels reste stagnant
- Les échecs surviennent quels que soient le pays, le secteur ou le type d’organisation
- Le coût social et économique des échecs continue d’augmenter
- La limite de l’IA face aux problèmes de gestion est clairement soulignée
- Il est difficile pour l’IA de maîtriser les jeux d’intérêts complexes et les facteurs politiques des grands projets
- Les projets IT comportent déjà beaucoup de décisions irrationnelles, ce qui laisse peu de cas pertinents dont l’IA puisse apprendre
- Les causes des échecs incluent le manque d’imagination humaine, des objectifs flous, l’échec de la gestion de la complexité et l’absence de contrôle des risques
- Les mêmes facteurs se répètent depuis des décennies, prolongeant un phénomène de « failure déjà vu »
Le système de paie Phoenix au Canada
- Le système Phoenix, lancé en 2016 pour CA$310 millions, a échoué en tentant d’intégrer 80 000 règles de paie et 105 conventions syndicales
- Pour réduire le budget, les procédures de test et de pilote ont été raccourcies, et des fonctions essentielles ont été supprimées
- Résultat, sur 9 ans, 70 % des 430 000 employés ont subi des erreurs de paie
- En mars 2025, 349 000 erreurs restaient non résolues, dont plus de la moitié avec plus d’un an de retard
- Des cas de suicide parmi les employés ont même été signalés
- Le coût total dépasse CA$5,1 milliards, et le bureau d’audit a parlé d’un « échec incompréhensible de la gestion et de la supervision du projet »
Le système Horizon du Post Office au Royaume-Uni
- Déployé en 1999, le système POS Horizon de Fujitsu a dissimulé des erreurs internes et conduit à la poursuite de 3 500 responsables de bureau de poste pour fausse comptabilité et fraude
- 900 condamnations, 236 incarcérations et plus de 13 suicides
- Des échecs techniques, managériaux, juridiques et éthiques se sont combinés
- Middleware truffé de bugs, dérive de périmètre non maîtrisée, tests insuffisants, manque de personnel
- La direction s’est montrée hostile envers les lanceurs d’alerte, a dissimulé des preuves et tenté un camouflage organisationnel
- Les tentatives de remplacement en 2016 et 2021 ont elles aussi échoué, et Horizon est toujours utilisé
- Budget du nouveau système : £410 millions, décision attendue en juillet 2026
Autres grands cas d’échec
- Minnesota MNLARS : lancé en 2016, annulé en 2019, coût de 100 millions de dollars
- Australie Modernising Business Registers : budget passé de AU$480 millions à AU$2,8 milliards, annulation en 2022
- Système d’immatriculation des véhicules en Louisiane : pannes répétées d’un mainframe vieux de 50 ans, état d’urgence déclaré en 2025
- Jaguar Land Rover : cyberattaque en 2025 entraînant plus d’un mois d’arrêt mondial des opérations, pertes de 1,2 à 1,9 milliard de dollars
- Lidl ERP : échec d’un ERP SAP à 500 millions d’euros, retour à un système interne (2017)
- Boeing 737 Max : défaut de conception du MCAS ayant causé 346 morts, coût total estimé à 74 milliards de dollars
- Mise à niveau F-35 Block 4 : calendrier retardé de 5 ans, coût passé de 10,5 à 16,5 milliards de dollars
Le coût économique des échecs
- Aux États-Unis, le coût des échecs logiciels en 2022 a atteint 1,81 billion de dollars, dont 260 milliards liés aux échecs de développement
- Le total dépasse le budget de la défense (778 milliards de dollars)
- Les coûts annuels de maintenance des systèmes legacy atteignent 520 milliards de dollars et représentent 70 à 75 % des budgets IT
- Les remplacements sont retardés en raison de leur coût élevé et du risque d’échec
- Rapport NTT DATA 2024 : 80 % des organisations déclarent que les technologies vieillissantes freinent l’innovation
- La plupart des dirigeants estiment que les infrastructures legacy entravent la réactivité au marché
Les limites d’Agile et de DevOps
- Malgré la généralisation des approches de développement itératif et incrémental, les taux d’échec restent élevés
- Certains rapports évoquent jusqu’à 65 % d’échec pour les projets Agile et 90 % pour DevOps
- Une adoption réussie exige leadership, discipline organisationnelle, formation et transformation culturelle
- Pourtant, la plupart des organisations ne parviennent pas à maintenir ces efforts dans la durée
Des erreurs de gestion qui se répètent et peu d’apprentissage
- Les responsables de projets IT disent souvent que « notre projet est différent » et ignorent les leçons des échecs passés
- Le gouvernement canadien a répété avec Phoenix les leçons déjà tirées d’un premier échec de système de paie en 1995
- La plupart des échecs proviennent de banales erreurs de gestion plutôt que de tentatives innovantes
- On est plus proche d’une « destruction financière » que d’une « destruction créatrice »
- Exemples d’échecs de systèmes administratifs basés sur l’IA
- Le système d’allocations chômage MiDAS aux États-Unis et le Centrelink Robodebt en Australie ont injustement poursuivi des centaines de milliers de personnes à cause d’algorithmes erronés
- Les gouvernements ont montré peu d’empressement à reconnaître les erreurs et à indemniser les victimes
La nécessité de responsabilité, d’éthique et de transparence
- Les décisions opaques des systèmes intégrant de l’IA font craindre des atteintes aux droits des citoyens
- L’UE garantit juridiquement le « droit à une explication des décisions algorithmiques »
- Le besoin de faire de la transparence et de la responsabilité des systèmes automatisés un droit humain est soulevé à l’échelle mondiale
- Il existe des discussions autour de lois sur la responsabilité logicielle et de licences professionnelles, mais leur mise en œuvre paraît peu probable
- L’alternative la plus réaliste consiste à renforcer l’honnêteté des dirigeants, l’esprit critique et le jugement éthique
- Il faut identifier clairement les risques et se méfier des promesses excessives des fournisseurs
- L’importance d’appliquer des principes de conception centrée sur l’humain à tous les systèmes IT, y compris ceux intégrant l’IA est soulignée
Conclusion : arrêter de répéter les mêmes erreurs
- Le développement logiciel est par nature complexe et fragile, et de petites erreurs peuvent avoir des conséquences majeures
- Des ressources suffisantes, du leadership et de la responsabilité sont indispensables pour mener à bien les projets
- Il faut évaluer les coûts en tenant compte aussi des dommages émotionnels et économiques subis par les utilisateurs
- Plus de 50 ans après la crise du logiciel de 1968, les mêmes erreurs se répètent encore
- « Faites de nouvelles erreurs »
> « Tout le monde peut se tromper, mais il n’y a que l’imbécile qui persiste dans son erreur » — Cicéron, orateur romain
5 commentaires
Avis Hacker News
J’ai trouvé la solution proposée à la fin de l’article un peu décevante
La vraie solution, selon moi, est de commencer petit et valider en conditions réelles d’exploitation
Par exemple, pour construire un système national de paie, il faudrait d’abord le tester dans une petite ville de 50 personnes, corriger les bugs, puis l’étendre progressivement à des villes plus grandes
Il n’existe pas de processus de développement logiciel qui permette de passer directement à l’échelle nationale sans résoudre les problèmes à petite échelle
Le volume de transactions était faible, donc même en cas de problème on pouvait corriger manuellement, et cela permettait d’éviter les contraintes PCI
C’est grâce à ce type de test avant le déploiement en magasin réel que nous avons pu tenir les délais sans incident majeur
Si nous avions déployé d’emblée dans des magasins clients, des erreurs de calcul de taxes ou des problèmes de performance auraient provoqué un grand désordre
L’extension progressive tend à accumuler de la dette technique, et plus personne ne finit par avoir confiance dans le cœur du codebase, d’où une peur de la réécriture
Même pour un produit simple comme WhatsApp, il faut dès le départ une conception d’ingénierie pensée pour la scalabilité à grande échelle
Plus un système est petit et réussi, plus il est facile qu’une telle personne émerge, gagne la confiance des utilisateurs comme des développeurs, et permette une croissance progressive
Les grands projets ayant une forte probabilité d’échec, il faut commencer petit selon le principe de précaution (Precautionary Principle)
Quel que soit le projet, cette boucle d’itération est la base
Commencer petit, puis modulariser avant d’étendre. Le cas de la mégafactory de Tesla m’a marqué
En étudiant l’histoire des technologies, j’ai eu le sentiment que l’industrie du hardware apprend de ses succès et de ses échecs passés, mais que l’industrie du logiciel ne le fait pas
La plupart des développeurs n’apprennent pas en démontant les systèmes du passé, et chaque génération revit les mêmes problèmes
Lors des rétrospectives, on demande toujours seulement « qu’est-ce que les développeurs devraient faire différemment la prochaine fois ? », et les managers n’assument jamais aucune responsabilité
Au final, les mêmes problèmes se répètent, et la charge retombe sur les développeurs
Les générations passées résolvaient les problèmes dans les couches basses de la stack, alors qu’aujourd’hui on essaie de tout résoudre par le haut
Résultat : on empile des tours d’abstractions, on consomme plus de ressources pour des fonctionnalités comparables
Nous entrons maintenant dans une époque où l’on ajoute encore une couche logicielle par-dessus les modèles d’IA
L’expérience comme la personnalité comptent, et il faut absolument un ego modéré et une pensée orientée résolution de problèmes
La plupart des gens sous-estiment la complexité des projets
Pendant mes études supérieures, j’ai passé une semaine à lire le code source de TinyOS pour en comprendre l’architecture, et cette expérience m’a énormément aidé
La capacité à comprendre rapidement un codebase inconnu est très utile
Si de nouveaux langages ou frameworks apparaissent régulièrement, les entreprises peuvent continuer à recruter des juniors peu coûteux
Je pense que c’est l’une des raisons pour lesquelles le logiciel n’est pas traité comme les autres disciplines d’ingénierie
Fondamentalement, ce n’est pas un problème de programmation mais un problème d’incompétence managériale
Dans la plupart des projets, les exigences métier ne sont pas clairement définies, et tout avance sur la base de suppositions
L’échec des grands projets IT publics se comprend quand on regarde la structure des contrats et les incitations
Le problème vient d’un modèle trop dépendant de consultants facturant au temps passé plutôt que des compétences réelles
Les projets qui réussissent reposent moins sur la technique que sur l’alignement entre organisations (alignment) et la compétence (competence)
Je pense que la vraie question dans la Silicon Valley, c’est la discrimination liée à l’âge
L’expérience est ignorée, et les leçons du passé ne sont jamais intégrées
L’industrie du hardware, elle, a poursuivi l’innovation tout en respectant son héritage
Selon ce point de vue, ceux qui ont appris des échecs passés seraient incapables de tenter quelque chose de nouveau
Les projets logiciels échouent au fond à cause des défaillances humaines
Plus que les processus ou les outils parfaits, ce qui compte, ce sont des personnes motivées et responsables
Il faut de véritables conséquences (Consequences) juridiques pour que les gens fassent correctement leur travail
Comme dans les travaux physiques, chaque étape devrait avoir sa vérification indépendante et son responsable
En pratique, il faut donc avancer en acceptant un certain niveau de risque
Les projets qui ont réussi l’ont fait grâce à quelques individus dotés d’intelligence émotionnelle et de leadership
Au bout du compte, l’ingénierie logicielle est un problème humain
Mais l’industrie reste prisonnière de l’évitement des responsabilités et de la course aux modes
Ce genre de problème n’est pas propre au logiciel
De grands projets de génie civil comme Auburn Dam, Columbia River Crossing ou Big Dig sont eux aussi tristement célèbres pour leurs dépassements de budget
Si le budget initial était irréaliste, cela veut simplement dire que le coût a été ramené à la réalité
C’est pourquoi une approche fondée sur de petits projets étendus progressivement est importante
Je ne suis ni développeur ni PM, mais je me demandais quels étaient les grands exemples de réussite à grande échelle
Comme je travaille à l’hôpital, des cas de réussite dans la santé m’intéresseraient encore plus
J’ai lu The Phoenix Project et cela m’a permis de mieux comprendre l’état d’esprit Agile et DevOps, mais c’est difficile à appliquer dans la pratique
J’aimerais semer les graines du succès dans de petits projets
Tout est parti d’une réaction à la complexité de Multics, quand Ken Thompson a écrit Unix lui-même en trois semaines
Voir cet article
La loi de Conway, le risque lié aux personnes clés, une propriété claire, une culture du test, tout cela est indispensable
Plus que tout, il faut avoir le courage de dire « non »
Il existe aussi des cas comme healthcare.gov, qui a échoué avant d’être amélioré
Avant d’accuser la communauté IT, il faut regarder la culture d’entreprise centrée sur les gains à court terme
La sécurité et la stabilité sont toujours les premières victimes des coupes budgétaires
Les dirigeants partent avec un parachute doré même après un échec, et la responsabilité reste sur les développeurs
Les pouvoirs publics ne sanctionnent pas réellement les entreprises pour leurs graves incidents de sécurité
Au final, on retombe toujours sur ce réalisme cynique consistant à dire qu’on va régler ça avec de l’IA, des consultants ou de l’externalisation
Déverser des milliers de milliards dans l’IA n’améliorera pas la situation, au contraire, cela va l’aggraver
Les sociétés occidentales sont déjà instables et penchent vers l’extrême droite
La prochaine crise pourrait ne pas être un simple effondrement financier, mais un effondrement social
L’humanité doit avancer par le progrès fondé sur la compréhension, et non par la crise
Avec de bons processus, elle améliore les résultats ; avec de mauvais processus, elle accélère les problèmes
Au final, la direction reste la même, seule la vitesse change
Si un problème n’a toujours pas été corrigé après aussi longtemps, n’est-ce pas plutôt un problème du côté de l’exploitation qui doit l’adopter, plutôt qu’un problème de techniques ou de principes de développement…
Le scandale de la Poste britannique a aussi eu droit à une adaptation dramatique.
Les victimes n’ont toujours pas été indemnisées, donc l’affaire est encore en cours.
Un exemple récent en Corée du Sud qui me vient à l’esprit est l’échec du projet de mise en place du système informatique de nouvelle génération de la Gyeonggi Credit Guarantee Foundation.
https://v.daum.net/v/20251111165048155
Dans d’autres pays aussi, on mène des projets SI énormes ?