Quand on cherche à comprendre pourquoi les projets informatiques échouent, on tombe d'abord sur des pourcentages, mais rarement sur le contexte qui les sous-tend. Les études ne se contredisent qu'en apparence, car chacune définit l'échec différemment. Plus importante que le taux d'échec, c'est la cause sous-jacente, et celle-ci s'avère étonnamment identique d'une enquête à l'autre.
Selon les définitions, 17 à 19 % des projets informatiques échouent complètement, et environ la moitié d'entre eux rencontrent des problèmes importants en termes de budget, de délais ou de périmètre. Les causes les plus fréquentes sont des exigences floues et un périmètre de projet qui ne cesse de s'étendre, cité par 82 % des entreprises interrogées. Les méthodes agiles permettent d'identifier ce problème plus tôt, mais ne le résolvent pas.
Le taux d'échec des projets informatiques : les chiffres
Le rapport Standish CHAOS 2024 considère que 31 % des projets étudiés ont été couronnés de succès, 50 % ont été menés à terme malgré des problèmes et 19 % ont échoué (Standish Group). L'étude du PMI pour l'Allemagne, réalisée la même année, fait état d'un taux d'échec inférieur, à 17 %. Toutefois, seuls 68 % des projets y atteignent effectivement leurs objectifs commerciaux au final (données du PMI via Haufe, 2024).
| enquête | Avec succès | Avec des problèmes | Échec | Ce qui est considéré comme un échec |
|---|---|---|---|---|
| Rapport Standish CHAOS 2024 | 31 % | 50 % | 19 % | annulé avant la livraison |
| PMI Allemagne 2024 | 68 % d'entre eux atteignent leurs objectifs commerciaux | non indiqué | 17 % | Objectifs commerciaux non atteints au final |
Cette différence n'est pas une contradiction. Elle met en évidence un problème de définition. Standish considère comme des échecs les projets qui ont été interrompus avant même qu'un produit ou un service n'ait été livré. Le PMI, en revanche, évalue si les objectifs commerciaux initiaux ont été atteints au final. Il s'agit là d'un critère nettement plus strict. Un projet peut être livré dans les délais et dans les limites du budget tout en étant considéré comme un échec s’il ne répond pas aux besoins réels.
Ce que signifie « dépassement » dans la pratique
Dépassement budgétaire moyen des grands projets informatiques en 2024. Le retard s'élève à 46 %, et le logiciel livré offre en moyenne 39 % de valeur en moins que prévu.
McKinsey, 2024
Cette tendance est encore plus marquée dans le cadre des déploiements de SAP S/4HANA. 60 % des projets dépassent à la fois le budget et le calendrier prévus, tandis que 30 % prennent plus de temps que prévu (étude Horváth via WirtschaftsWoche, 2025).
Les projets S/4HANA sont des migrations complexes comportant de nombreuses dépendances vis-à-vis des systèmes existants. Ce chiffre ne peut donc pas s'appliquer à l'identique à chaque projet logiciel. Il montre toutefois à quel point l'ampleur et la complexité du système pèsent sur les chances de réussite, même chez les prestataires disposant d'un modèle de procédure bien établi et d'un vaste réseau de partenaires.
Pour les entreprises de l'industrie et du commerce, le chiffre S/4HANA revêt une importance particulière, car les migrations ERP comptent depuis des années parmi leurs plus grands projets informatiques. Une entreprise de production qui migre simultanément ses stocks, son pilotage de la production et sa comptabilité financière vers un nouveau système présente un profil de risque différent de celui d’un simple éditeur de logiciels qui développe une seule application. Les interdépendances entre les modules, les interfaces avec les systèmes de commande des machines et les solutions spécifiques mises en place au fil du temps s’accumulent. Quiconque se lance dans un tel projet devrait considérer ce chiffre de 60 % comme une hypothèse de base réaliste pour sa propre planification.
Pourquoi les projets informatiques échouent-ils dans la pratique ?
Derrière ces pourcentages, il y a généralement une cause qui revient plus souvent que les autres.
des entreprises interrogées citent des exigences floues et un périmètre de projet croissant comme le défi le plus fréquent au cours du projet.
SDZeCOM, 2024
Cela correspond à une observation tirée de nombreux projets en cours. Au début, il manque une définition solide de ce que le système doit être capable de faire. Chaque exigence ultérieure est alors considérée comme une exception, jusqu’à ce que toutes ces exceptions finissent par donner naissance à un deuxième projet non prévu. Pour savoir comment mettre un terme à cette évolution, consultez l’article sur Dérive du périmètre, et le travail préparatoire est assuré par un bon Cahier des charges.
Malgré dix ans de pratiques agiles, le taux de réussite global n’a guère évolué. Il stagne depuis 2017 à un niveau similaire (PM World Journal, 01/2026). C’est décevant pour tous ceux qui pensaient que les sprints et les rétrospectives résoudraient le problème de fond. Les processus agiles permettent de mettre les problèmes en évidence plus tôt. Ils ne remplacent toutefois pas une définition claire des missions et une direction capable de prendre des décisions.
Les limites de la méthodologie CHAOS
Le rapport CHAOS fait l'objet de critiques depuis des années. Standish ne divulgue pas entièrement l'échantillon exact ni la méthode d'enquête, et les catégories « réussite », « en difficulté » et « échec » ont été modifiées à plusieurs reprises au fil du temps. Quiconque cite le chiffre de 19 % doit savoir qu’il n’est que partiellement comparable aux éditions précédentes du rapport CHAOS des années 1990 et 2000, dans lesquelles le taux d’échec était nettement plus élevé. Cela n’enlève rien à la valeur du chiffre actuel. Cela limite simplement les conclusions que l’on peut en tirer pour son propre cas.
Ce que ces chiffres signifient pour votre projet
Pour les dirigeants et les responsables informatiques dans l’industrie et le commerce, la question pratique n’est pas tant de savoir quelle étude a raison. Ce qui importe davantage, c’est de déterminer à quel moment il faut prendre au sérieux ses propres signaux d’alerte. Le fait de ne pas atteindre un objectif intermédiaire ne constitue pas encore un motif d’inquiétude. Deux jalons non atteints d’affilée, auxquels s’ajoute une liste d’exigences qui s’allonge chaque semaine, constituent un schéma que les études citées décrivent parfaitement. Celui qui attend que le budget soit déjà dépassé de 75 % a déjà manqué le moment le plus propice pour corriger le tir. Vous trouverez dans cet article des détails sur l'analyse des causes d'un dépassement en cours. concernant le dépassement budgétaire dans le projet informatique.
Deux jalons manqués ?Dans ce cas, c'est maintenant le moment idéal pour réorienter votre projet. Nous ferons le point sur votre projet lors d'un entretien, sans aucune pression commerciale.
Foire aux questions
Combien de projets informatiques échouent réellement ?
Selon la définition retenue, entre 17 et 19 % échouent complètement, et environ 50 % supplémentaires rencontrent des problèmes importants de budget, de calendrier ou de périmètre (Standish Group 2024, données du PMI via Haufe 2024). Le chiffre exact dépend de la question de savoir si l'on compte comme échec un projet interrompu ou un projet livré mais qui manque ses objectifs.
Combien coûte un projet informatique qui a échoué ?
Les seuls coûts du projet ne représentent généralement qu'une partie de la facture. McKinsey chiffre le dépassement budgétaire moyen en 2024 à 75 % du budget initial, auxquels s'ajoutent les bénéfices perdus du fait d'une livraison tardive ou inexistante. Pour les projets de grande envergure, tels que les déploiements de SAP S/4HANA, le taux de dépassement s'élève à 60 % des projets (Horváth via WirtschaftsWoche, 2025).
Quand faut-il faire appel à une aide extérieure ?
Dès que deux jalons consécutifs ne sont pas atteints ou que la liste des exigences dépasse nettement le cadre initial, il est utile de recourir à une expertise externe. À ce stade, les causes sont généralement encore clairement identifiables et les options d'action sont plus nombreuses qu'au bout de trois mois. Comment un CTO par intérim Nous décrivons sur notre page « Services » comment nous procédons concrètement dans une telle situation.
La prochaine étape
torck observe régulièrement ces schémas dans ses propres projets informatiques pour l'industrie et le commerce. Dès les premiers signes de dérive, nous prenons en charge la direction technique et la réalisation d'une seule main, en nous appuyant sur nos propres équipes de développement à Maxhütte-Haidhof, Vienne et Rabat. Prenez rendez-vous pour un premier entretien sans engagement, afin de classer votre projet.
German 
English 
French