Les causes structurelles de l’échec des projets IT : l’ignorance managériale répétée et son coût

baeba · 2025-11-26T09:56:15+09:00

Vue d’ensemble du résumé : Sujet central : les échecs des projets IT ne proviennent pas de difficultés techniques, mais de l’« ignorance volontaire » des dirigeants et de leur arrogance qui les pousse à refuser d’apprendre des échecs passés. Principaux chiffres : en 20 ans, les dépenses IT mondiales ont triplé (5,6 billions de dollars), mais le taux de réussite stagne, tandis que 75 % des budgets sont absorbés par la seule maintenance des systèmes legacy. Cas clés : la défaillance globale de gestion du système Phoenix au Canada et la dissimulation contraire à l’éthique dans l’affaire Horizon au Royaume-Uni relèvent non d’une simple « erreur » (Blunder), mais d’un « mal administratif » (Administrative Evil). 1. Introduction : des taux d’échec qui ne s’améliorent pas malgré des investissements massifs Efficacité en stagnation malgré les investissements : Depuis 2005, les dépenses IT mondiales sont passées de 1,7 à 5,6 billions de dollars en 2025, soit plus qu’un triplement. Pourtant, malgré ces coûts considérables, le taux de réussite des projets logiciels n’a pas montré d’amélioration nette au cours des 20 dernières années. Se méfier des illusions autour de l’IA : De nombreux dirigeants espèrent que les outils d’IA ou les assistants de code comme Copilot permettront de faire réussir des projets de grande ampleur, mais l’auteur se montre sceptique. L’IA ne peut pas résoudre la complexité de l’ingénierie système, les arbitrages financiers, ni surtout les « politiques organisationnelles » (Organizational Politics) au sein d’un projet. Un phénomène d’échec universel : Les échecs logiciels surviennent indistinctement quels que soient le pays, la taille de l’entreprise ou le statut lucratif/non lucratif ; ils résultent moins d’une simple erreur technique que d’un « manque d’imagination humaine » et d’objectifs irréalistes. 2. Analyse : typologie des échecs et causes profondes 2.1. Les Blunder à répétition et le refus d’apprendre Distinguer échec et erreur : L’échec comme forme de « destruction créatrice » (Creative Destruction), lorsqu’on repousse des limites techniques, devrait être bien accueilli. Mais la plupart des échecs IT ne sont que des « erreurs stupides » (Blunder), qui répètent des causes documentées depuis des décennies (absence de gestion des risques, sous-estimation de la complexité, etc.). L’arrogance des dirigeants : Les responsables de projet ont tendance à affirmer que leur projet est « spécial et unique », en ignorant les cas d’échec passés et les données disponibles. Il ne s’agit pas d’une simple ignorance, mais d’une « ignorance volontaire » (Willful Ignorance) qui consiste à détourner sciemment le regard des signaux de risque. Le piège des systèmes legacy : Aux États-Unis, les organisations dépensent plus de 520 milliards de dollars par an pour la seule maintenance des systèmes legacy, soit 70 à 75 % de leur budget IT total. Par peur de l’échec d’un remplacement, elles repoussent la modernisation jusqu’à l’effondrement physique du système (par exemple le mainframe du service des véhicules de Louisiane) ou jusqu’à la disparition totale de toute efficacité économique. 2.2. Détails des grands échecs et effets en cascade Le système de paie Phoenix au Canada : Erreur initiale : en adoptant une solution du marché (PeopleSoft), le projet a tenté de personnaliser 80 000 règles de paie et 105 conventions collectives. Le prix des coupes budgétaires : pour exécuter le projet avec moins de 60 % du budget proposé par le fournisseur, les équipes ont imposé la suppression de fonctions critiques de paie, la réduction des tests et l’abandon de tests pilotes indispensables. Résultat : effondrement immédiat après la mise en service en 2016. Les erreurs de paie ont provoqué une forte détresse financière chez les employés, certaines étant même citées comme facteur dans des suicides. Coût : le budget initial était de 310 millions de dollars canadiens, mais les coûts de correction et de remédiation dépassent aujourd’hui 5,1 milliards de dollars canadiens (environ 3,6 milliards de dollars US). Le scandale Horizon de la Poste britannique : Défaillance technique : un bug middleware dans le système fourni par Fujitsu a provoqué des erreurs de déséquilibre comptable. Dissimulation organisée : bien que la direction connaisse les défauts du logiciel, elle les a cachés et a au contraire poursuivi 3 500 responsables de bureaux de poste pour détournement et vol. 900 ont été condamnés et emprisonnés. Coût social : faillites, divorces, incarcérations et suicides parmi les victimes. L’affaire est considérée comme l’un des pires échecs IT et scandales judiciaires de l’histoire du Royaume-Uni. 2.3. La décision automatisée et le « mal administratif » La violence des algorithmes : Les systèmes MiDAS dans le Michigan (détection de fraude aux allocations chômage) et Robodebt en Australie (détection de fraude aux aides sociales) ont rendu des décisions en s’appuyant uniquement sur des algorithmes, sans supervision humaine. Des dizaines de milliers de citoyens innocents ont été traités comme des criminels, mais les bureaucraties ont refusé d’indemniser les victimes ou ont éludé leurs responsabilités même après la preuve des erreurs du système. Les risques de l’adoption de l’IA : Ce « mal administratif » (Administrative Evil) ne fera que s’aggraver à mesure que l’IA s’enfonce dans les infrastructures publiques. L’UE a introduit un « droit à l’explication », mais il devient urgent, à l’échelle mondiale, de renforcer la transparence et la responsabilité autour des algorithmes. 3. Conclusion : pistes de solution et défis pour la communauté IT Les méthodologies (Agile/DevOps) ne sont pas une clé universelle : Des rapports indiquent que le taux d’échec des projets Agile peut atteindre 65 %, preuve qu’aucune méthodologie ne garantit à elle seule le succès. Sans leadership cohérent ni discipline organisationnelle, toute nouvelle méthode échoue. Évaluation honnête des risques et responsabilité éthique : Avant de lancer un projet, il faut mener une analyse d’écart (Gap Analysis) honnête sur « ce que l’on sait et ce que l’on ne sait pas ». Le concept d’« IA centrée sur l’humain » (Human-centered AI) devrait être étendu à tous les projets IT afin d’intégrer dans les analyses coûts-bénéfices les dommages émotionnels et financiers que les défaillances système peuvent infliger aux utilisateurs finaux. Appel à un changement d’attitude chez les dirigeants : Le logiciel est par nature fragile (Fragile) et complexe. Les dirigeants doivent respecter et soutenir le développement logiciel non seulement comme détenteurs du pouvoir budgétaire, mais aussi comme acteurs responsables en cas d’échec. Mettre fin à la répétition des mêmes erreurs est le seul moyen pour l’industrie IT de sortir de sa « crise » (Crisis).

(spectrum.ieee.org)

3 points par baeba 2025-11-26 | 1 commentaires | Partager sur WhatsApp

Vue d’ensemble du résumé :
- Sujet central : les échecs des projets IT ne proviennent pas de difficultés techniques, mais de l’« ignorance volontaire » des dirigeants et de leur arrogance qui les pousse à refuser d’apprendre des échecs passés.
- Principaux chiffres : en 20 ans, les dépenses IT mondiales ont triplé (5,6 billions de dollars), mais le taux de réussite stagne, tandis que 75 % des budgets sont absorbés par la seule maintenance des systèmes legacy.
- Cas clés : la défaillance globale de gestion du système Phoenix au Canada et la dissimulation contraire à l’éthique dans l’affaire Horizon au Royaume-Uni relèvent non d’une simple « erreur » (Blunder), mais d’un « mal administratif » (Administrative Evil).

1. Introduction : des taux d’échec qui ne s’améliorent pas malgré des investissements massifs

Efficacité en stagnation malgré les investissements :
- Depuis 2005, les dépenses IT mondiales sont passées de 1,7 à 5,6 billions de dollars en 2025, soit plus qu’un triplement.
- Pourtant, malgré ces coûts considérables, le taux de réussite des projets logiciels n’a pas montré d’amélioration nette au cours des 20 dernières années.
Se méfier des illusions autour de l’IA :
- De nombreux dirigeants espèrent que les outils d’IA ou les assistants de code comme Copilot permettront de faire réussir des projets de grande ampleur, mais l’auteur se montre sceptique.
- L’IA ne peut pas résoudre la complexité de l’ingénierie système, les arbitrages financiers, ni surtout les « politiques organisationnelles » (Organizational Politics) au sein d’un projet.
Un phénomène d’échec universel :
- Les échecs logiciels surviennent indistinctement quels que soient le pays, la taille de l’entreprise ou le statut lucratif/non lucratif ; ils résultent moins d’une simple erreur technique que d’un « manque d’imagination humaine » et d’objectifs irréalistes.

2. Analyse : typologie des échecs et causes profondes

2.1. Les `Blunder` à répétition et le refus d’apprendre

Distinguer échec et erreur :
- L’échec comme forme de « destruction créatrice » (Creative Destruction), lorsqu’on repousse des limites techniques, devrait être bien accueilli.
- Mais la plupart des échecs IT ne sont que des « erreurs stupides » (Blunder), qui répètent des causes documentées depuis des décennies (absence de gestion des risques, sous-estimation de la complexité, etc.).
L’arrogance des dirigeants :
- Les responsables de projet ont tendance à affirmer que leur projet est « spécial et unique », en ignorant les cas d’échec passés et les données disponibles.
- Il ne s’agit pas d’une simple ignorance, mais d’une « ignorance volontaire » (Willful Ignorance) qui consiste à détourner sciemment le regard des signaux de risque.
Le piège des systèmes legacy :
- Aux États-Unis, les organisations dépensent plus de 520 milliards de dollars par an pour la seule maintenance des systèmes legacy, soit 70 à 75 % de leur budget IT total.
- Par peur de l’échec d’un remplacement, elles repoussent la modernisation jusqu’à l’effondrement physique du système (par exemple le mainframe du service des véhicules de Louisiane) ou jusqu’à la disparition totale de toute efficacité économique.

2.2. Détails des grands échecs et effets en cascade

Le système de paie Phoenix au Canada :
- Erreur initiale : en adoptant une solution du marché (PeopleSoft), le projet a tenté de personnaliser 80 000 règles de paie et 105 conventions collectives.
- Le prix des coupes budgétaires : pour exécuter le projet avec moins de 60 % du budget proposé par le fournisseur, les équipes ont imposé la suppression de fonctions critiques de paie, la réduction des tests et l’abandon de tests pilotes indispensables.
- Résultat : effondrement immédiat après la mise en service en 2016. Les erreurs de paie ont provoqué une forte détresse financière chez les employés, certaines étant même citées comme facteur dans des suicides.
- Coût : le budget initial était de 310 millions de dollars canadiens, mais les coûts de correction et de remédiation dépassent aujourd’hui 5,1 milliards de dollars canadiens (environ 3,6 milliards de dollars US).
Le scandale Horizon de la Poste britannique :
- Défaillance technique : un bug middleware dans le système fourni par Fujitsu a provoqué des erreurs de déséquilibre comptable.
- Dissimulation organisée : bien que la direction connaisse les défauts du logiciel, elle les a cachés et a au contraire poursuivi 3 500 responsables de bureaux de poste pour détournement et vol. 900 ont été condamnés et emprisonnés.
- Coût social : faillites, divorces, incarcérations et suicides parmi les victimes. L’affaire est considérée comme l’un des pires échecs IT et scandales judiciaires de l’histoire du Royaume-Uni.

2.3. La décision automatisée et le « mal administratif »

La violence des algorithmes :
- Les systèmes MiDAS dans le Michigan (détection de fraude aux allocations chômage) et Robodebt en Australie (détection de fraude aux aides sociales) ont rendu des décisions en s’appuyant uniquement sur des algorithmes, sans supervision humaine.
- Des dizaines de milliers de citoyens innocents ont été traités comme des criminels, mais les bureaucraties ont refusé d’indemniser les victimes ou ont éludé leurs responsabilités même après la preuve des erreurs du système.
Les risques de l’adoption de l’IA :
- Ce « mal administratif » (Administrative Evil) ne fera que s’aggraver à mesure que l’IA s’enfonce dans les infrastructures publiques.
- L’UE a introduit un « droit à l’explication », mais il devient urgent, à l’échelle mondiale, de renforcer la transparence et la responsabilité autour des algorithmes.

3. Conclusion : pistes de solution et défis pour la communauté IT

Les méthodologies (Agile/DevOps) ne sont pas une clé universelle :
- Des rapports indiquent que le taux d’échec des projets Agile peut atteindre 65 %, preuve qu’aucune méthodologie ne garantit à elle seule le succès. Sans leadership cohérent ni discipline organisationnelle, toute nouvelle méthode échoue.
Évaluation honnête des risques et responsabilité éthique :
- Avant de lancer un projet, il faut mener une analyse d’écart (Gap Analysis) honnête sur « ce que l’on sait et ce que l’on ne sait pas ».
- Le concept d’« IA centrée sur l’humain » (Human-centered AI) devrait être étendu à tous les projets IT afin d’intégrer dans les analyses coûts-bénéfices les dommages émotionnels et financiers que les défaillances système peuvent infliger aux utilisateurs finaux.
Appel à un changement d’attitude chez les dirigeants :
- Le logiciel est par nature fragile (Fragile) et complexe. Les dirigeants doivent respecter et soutenir le développement logiciel non seulement comme détenteurs du pouvoir budgétaire, mais aussi comme acteurs responsables en cas d’échec.
- Mettre fin à la répétition des mêmes erreurs est le seul moyen pour l’industrie IT de sortir de sa « crise » (Crisis).

1 commentaires

baeba 2025-11-26

Résumé des réactions dans les commentaires de Hacker News

1. Absence de déploiement progressif et de stratégie de montée en charge (Start Small)

Échec inévitable de l’approche « big bang » : déployer un projet à l’échelle nationale en une seule fois relève du suicide. Il est indispensable d’adopter une stratégie d’extension avec validation séquentielle par petites unités (village → ville → pays).
Différence entre produit et système : contrairement à un produit unique comme WhatsApp, un système d’entreprise complexe doit supporter une échelle massive dès le départ, ce qui exige une approche différente.
Solution clé : le principe « construire petit, valider, puis ajouter des fonctionnalités » est ignoré.

2. Incompétence du management et fuite des responsabilités (Management Issues)

Structure de pouvoir sans responsabilité : en cas d’échec du projet, les développeurs rattrapent le coup en faisant des heures sup, tandis que les dirigeants qui prennent les décisions n’assument aucune responsabilité, voire touchent des bonus — une structure paradoxale vivement critiquée.
Manque de compréhension technique : l’imposition de calendriers irréalistes qui ignorent la difficulté technique, ainsi qu’une culture hiérarchique qui refuse d’entendre les « mauvaises nouvelles », empêchent de résoudre les problèmes.
Décisions politiques : les solutions ont tendance à être choisies en fonction de la politique interne de l’entreprise ou des relations avec des prestataires externes (ristournes, etc.) plutôt que de leur adéquation technique.

3. Exigences incontrôlables et complexité (Complexity & Scope Creep)

Absence de simplification préalable des processus : comme dans le cas du projet Phoenix, tenter d’informatiser tel quel un ensemble de 80�00 règles de paie sans les rationaliser est une cause profonde du problème. Un processus hors ligne chaotique ne peut produire qu’un système numérique chaotique.
Changements fréquents des exigences : l’élargissement du périmètre en cours de projet (scope creep), provoqué par les revirements du management ou du client, entraîne le projet dans un bourbier.

4. Culture développeur et mauvaises incitations (Developer Culture)

Resume-Driven Development (RDD) : au lieu de privilégier la réussite du projet, certains imposent à marche forcée les dernières technologies à la mode (frameworks) pour favoriser leur mobilité professionnelle, ce qui alourdit la dette technique.
Rupture dans l’apprentissage : une culture du job hopping tous les 2 à 3 ans empêche les développeurs de voir les échecs à long terme du code qu’ils ont écrit et d’en tirer des leçons.
Obsession de la réinvention : pratique inefficace consistant à réécrire le code depuis zéro pour satisfaire son ego, plutôt que de s’appuyer sur des solutions existantes et éprouvées.

5. La nature particulière du génie logiciel (Engineering Nature)

Absence de contraintes physiques : contrairement au bâtiment ou au hardware, le software n’a pas de contraintes physiques, ce qui permet une complexité infinie et finit par provoquer une perte de contrôle.
Absence d’apprentissage du passé : dans les autres disciplines de l’ingénierie, les échecs (par exemple l’effondrement d’un pont) sont analysés rigoureusement pour en tirer des leçons, alors que l’industrie du logiciel répète ses erreurs passées en mode « YOLO » en se disant que « cette fois, c’est différent ».