Pourquoi les projets logiciels échouent-ils ? 10 causes et leur impact

Les projets logiciels tournent plus souvent mal que bien. L’étude la plus récente du Project Management Institute (décembre 2025) montre que seule la moitié des projets est jugée réussie. Pour les transformations d’entreprise, le tableau est encore plus net : Bain calculait en avril 2024 que 88 % de ces démarches n’atteignent pas leurs ambitions initiales. IEEE Spectrum le résumait ainsi début 2026 : les dépenses informatiques mondiales ont triplé depuis 2005, mais les taux de réussite des logiciels n’ont guère progressé en vingt ans.

En Belgique, où nous sommes installés, l’actualité fournit régulièrement un nouvel exemple. Fin 2025, le ministre belge Quintin a mis fin à i-Police, le projet de numérisation de la police fédérale : sur un contrat de 299 millions d’euros, 75,8 millions ont été versés, sans résultat opérationnel. Selon une reconstitution de De Tijd et de L’Echo, le coût réel pour la collectivité se chiffre en centaines de millions. Début 2026, le gouvernement flamand a arrêté pour les mêmes raisons le projet éducatif Persona, après 16 millions d’euros. Lieselot Danneels, professeure en numérisation des pouvoirs publics, résumait la situation à la radio flamande Radio 1 : « Seul 1 projet sur 4 réussit, et dans le secteur public c’est même 1 sur 5. » Les projets publics sont plus visibles que les projets B2B, mais les schémas sous-jacents sont étonnamment semblables.

Nous sommes dans le métier depuis un moment (d’abord comme indépendants, aujourd’hui ensemble chez Tandem), et nous voyons revenir sans cesse les dix mêmes pièges dans les projets B2B. Les voici. Et comme il serait trop facile de dire « nous, bien sûr, nous faisons mieux », nous plaçons notre approche juste à côté. Y compris là où nous ne faisons pas de miracles non plus.

Les dix raisons pour lesquelles ça tourne mal

1. Des besoins mal définis. Les clients ne savent pas toujours exactement ce dont ils ont besoin. Ce qui apparaît en surface, c’est souvent le processus actuel, alors que le vrai besoin métier se trouve une couche plus bas. Le résultat : un logiciel conforme à la spécification sur papier, mais qui ne fait pas avancer le terrain.

2. Un product owner faible côté client. Quelqu’un doit être autorisé à prendre des décisions et en être capable. Sans cela, chaque nœud reste bloqué pendant des semaines, pendant que le compteur du prestataire continue de tourner et que l’équipe perd son élan à chaque escalade.

3. Des parties prenantes mal alignées. Les ventes, les opérations, la finance et l’informatique veulent souvent des choses différentes. Si ce n’est pas clarifié au départ, cela remonte pendant la construction, et à ce moment-là corriger coûte cher : démonter des fonctionnalités tout juste livrées, en ajouter d’autres après coup, et le temps nécessaire pour en faire un produit cohérent s’ajoute par-dessus.

4. Des intégrations sous-estimées. ERP vieillissants, bases de données en désordre, API non documentées. « On se branche vite fait sur le système X » s’avère invariablement 2 à 5 fois plus lourd que prévu, et on le découvre généralement quand le chemin critique en dépend déjà.

5. La livraison « big bang ». Douze mois de construction sans vrais utilisateurs, c’est un pari. Ce n’est qu’à la livraison que vous découvrez ce qui manque vraiment, ou pire : que le produit tel qu’il a été demandé ne fait pas ce qu’il devrait. À ce stade, une grande partie du budget est déjà dépensée et le soutien pour un second tour a généralement disparu.

6. Pas d’adoption. Le logiciel fonctionne, mais personne ne l’utilise comme prévu. La formation, la conduite du changement et la politique interne sont chroniquement oubliées, et l’investissement s’évapore en silence : les vieux fichiers Excel restent en usage, l’outil officiel devient une coquille vide où l’on ne coche que la case obligatoire.

7. La mauvaise forme de contrat. Le forfait sur un terrain inconnu oppose prestataire et client : l’un veut réduire le périmètre, l’autre l’élargir. Plus personne ne construit de produit, tout le monde gère le contrat. Les réunions portent sur ce qui figure ou non dans le devis, plutôt que sur ce dont l’utilisateur final a vraiment besoin. Une conséquence moins visible : pour se ménager de la marge et de la sécurité autour d’un périmètre incertain, le prestataire choisit souvent plus d’architecture que strictement nécessaire. Ce schéma, nous l’appelons la sur-ingénierie, et il agit comme un facteur de coût caché qui se niche aussi dans plusieurs autres causes ci-dessus et ci-dessous.

8. La sécurité et le RGPD après coup. Ne penser à la conformité qu’à la livraison impose des changements d’architecture au pire moment possible : juste avant la mise en production, quand tout devrait être figé. Le résultat : des lancements reportés, des reprises coûteuses et, dans les secteurs réglementés, un refus net lors des audits.

9. Une dérive du périmètre sans discipline. Chaque nouveau souhait ajouté sans prix, c’est l’érosion du budget au ralenti. En même temps, l’échéance recule, la qualité baisse et l’équipe s’épuise à force de priorités qui changent sans cesse. La fin n’est jamais en vue, car elle est renégociée chaque semaine.

10. Les derniers 20 %. Durcissement, cas limites, gestion des erreurs, stabilité en production. La démo après trois mois a fière allure, mais la finition laborieuse est structurellement sous-estimée. Et plus un projet traîne, plus vite il dérape : l’équipe s’épuise, des personnes clés partent, et ce qui marchait en démo casse en production face à de vrais utilisateurs et de vraies données.

Comment nous essayons de faire autrement

Notre approche repose sur deux choses qui se renforcent : travailler en spikes et travailler avec l’event sourcing.

Les spikes comme méthode de travail

Un spike est une itération courte et délimitée dans laquelle nous construisons ou testons quelque chose de concret. Au lieu de vouloir tout spécifier à l’avance pendant des mois, nous faisons d’abord un spike sur la partie la plus incertaine : typiquement une intégration, une règle métier complexe ou une question d’ergonomie.

Après chaque spike, tout le monde en sait plus, et nous savons ce que la phase suivante va vraiment coûter. Cela touche directement les points 1, 4, 5, 7 et 9 :

• les besoins deviennent concrets et vérifiables au lieu d’être spéculatifs ;
• les intégrations en désordre et les vieilleries héritées, nous les trouvons tôt, pas à mi-parcours ;
• il n’y a pas de livraison « big bang », car chaque spike livre quelque chose de vérifiable ;
• nous contractons par phase à prix fixe, pas de méga-budget à l’avance ;
• chaque nouveau souhait reçoit automatiquement un prix, car il entre dans le spike suivant.

C’est d’ailleurs la direction vers laquelle même l’État belge se tourne publiquement depuis l’affaire i-Police. Lors de l’arrêt du projet, le ministre Quintin a annoncé miser désormais sur des « projets à petite échelle et modulaires » plutôt que sur des méga-contrats.

Travailler avec l’event sourcing

L’event sourcing est notre choix d’architecture par défaut quand il convient. Au lieu de ne stocker que l’état actuel, nous enregistrons tous les événements métier (« client enregistré », « facture payée », « commande expédiée ») comme des faits immuables. Cela paraît abstrait, mais cela a trois effets concrets :

• En phase d’analyse, cela oblige les parties prenantes à penser en événements métier plutôt qu’en écrans ou en tables. Ventes, opérations et informatique s’alignent plus vite, parce qu’ils parlent des mêmes faits (point 3).
• Pendant la construction, chaque événement devient une interface naturelle. Un nouveau système s’abonne aux événements sans que le cœur ait à changer, ce qui apporte un gain direct pour les intégrations (point 4) et pour la souplesse du périmètre (point 9).
• Pour la conformité, vous obtenez gratuitement une piste d’audit complète : qui a fait quoi et quand, enregistré de façon immuable. Dans les secteurs B2B réglementés, cela vaut de l’or (point 8). Le droit à l’oubli demande un choix de conception délibéré, mais il se résout parfaitement.

En plus, nous hébergeons par défaut sur un cloud européen, avec le code et les données appartenant au client et sans dépendance à un fournisseur. Cela boucle la boucle autour du point 8.

Là où nous ne faisons pas de miracles non plus

Deux points pour lesquels aucun prestataire n’a de solution complète. Nous non plus.

Un product owner faible côté client (point 2). Nous pouvons compenser beaucoup en restant proches du client et en allant chercher les questions nous-mêmes. Mais si personne en interne n’a le mandat pour trancher, chaque projet reste bloqué. Nous préférons en parler avant plutôt que pendant.

L’adoption et la conduite du changement (point 6). Notre approche UX aide : nous partons des personnes qui vont utiliser le logiciel, pas du système. Mais le volet organisationnel (formation, communication, adaptation des processus) reste en grande partie du côté du client. Nous aidons là où nous pouvons, nous ne pouvons pas le prendre en charge.

Pour conclure

Les chiffres bougent à peine depuis des décennies. Pas parce que nous serions de moins bons développeurs qu’avant, mais parce que le côté non technique de la construction de logiciels reste sous-estimé. C’est pourquoi nous préférons commencer là où ça se joue vraiment : avec les personnes qui vont l’utiliser, et avec les hypothèses que nous osons tester avant de les couler dans le code comme des vérités.

Vous voulez regarder ensemble où se trouve le plus grand piège dans votre entreprise ? Prenons rendez-vous pour faire connaissance.

Sources

Études internationales

• Project Management Institute, Step Up : Redefining the Path to Project Success with M.O.R.E. (décembre 2025). Étude auprès de plus de 5 800 professionnels de la gestion de projet : seule la moitié des projets est jugée globalement réussie.
• Bain & Company, 88% of business transformations fail to achieve their original ambitions (avril 2024). Seules 12 % des transformations d’entreprise atteignent leurs objectifs initiaux.
• IEEE Spectrum, Software Failures and IT Management’s Repeated Mistakes (janvier 2026). Les dépenses informatiques mondiales ont triplé depuis 2005, tandis que les taux de réussite des logiciels stagnent depuis deux décennies.
• Giulio Arcidiacono, Comparative research on IT project failure rates : a 2025 longitudinal update, PM World Journal (janvier 2026). Les données Standish CHAOS du cycle 2020-2024 confirment un taux d’échec durablement élevé et des taux de réussite qui stagnent.

Contexte belge (sources en néerlandais)

• De Tijd, Le parquet ouvre une enquête sur l’échec d’i-Police (27 janvier 2026). Reconstitution d’investigation du dossier i-Police, menée avec L’Echo.
• VRT NWS, Demir débranche à son tour : pourquoi les projets informatiques de l’État échouent-ils si souvent ? (27 janvier 2026). Analyse avec un entretien de Lieselot Danneels, professeure en numérisation des pouvoirs publics.
• VRT NWS, La numérisation de la police échoue : le ministre met fin à un contrat géant de 299 millions d’euros (26 décembre 2025). Annonce de l’arrêt du projet et du changement de cap annoncé vers des projets à petite échelle.