Taux d'echec des projets IT : les vraies statistiques (et ce qu'elles cachent)
30 ans de donnees Standish Group decortiquees. Ce que les chiffres disent vraiment - et ce qu'ils ne mesurent pas.
Un taux d'échec de projets IT n'a de sens qu'avec sa définition, son année et son échantillon. Un abandon, un retard et un projet livré sans valeur utile ne mesurent pas la même chose. Pour votre portefeuille, suivez séparément les engagements tenus, les dépassements et les bénéfices effectivement obtenus.
Ce que disent — et ne disent pas — les chiffres publies
Depuis 1994, le Standish Group publie son rapport CHAOS, la reference la plus citee sur les taux de reussite des projets IT. C'est aussi un rapport payant : nous n'avons pas pu rapprocher les series qui circulent de leur edition primaire.
Nous avons donc retire de cette page les pourcentages de succes, de projets « challenges » et d'echecs que nous y affichions. Ils etaient repris de sources secondaires, et deux editions differentes circulaient sous la meme annee. Republier un chiffre qu'on ne peut pas rattacher a une edition, une definition et un echantillon reviendrait a propager l'erreur qu'on reproche a ces citations.
Un taux d'echec sans son edition, sa definition et son echantillon n'est pas une statistique : c'est un slogan. Ce qui suit explique comment lire ces chiffres quand vous les rencontrez, et quoi mesurer sur votre propre portefeuille.
Ce qu'on appelle 'echec' dans ces statistiques
Le Standish Group utilise une definition precise - et discutable - de l'echec. Comprendre cette definition est essentiel pour interpreter les chiffres.
Depassement de delai
Le projet livre apres la date initialement prevue. Meme un jour de retard compte comme 'challenge'.
En realite : En realite, peu de projets complexes livrent exactement a la date prevue 18 mois plus tot. La vraie question est : le retard etait-il acceptable ?
Depassement de budget
Le projet coute plus que l'estimation initiale. Le critere ne distingue pas +10% et +300%.
En realite : Une estimation a 18 mois est une conjecture. La recherche montre que les estimations initiales ont une marge d'erreur de +/- 400% pour les projets complexes.
Perimetre incomplet
Le projet livre moins de fonctionnalites que prevu initialement.
En realite : Souvent, c'est une bonne chose. Un projet qui livre 60% du perimetre mais les 60% les plus importants cree plus de valeur qu'un projet qui livre 100% d'un perimetre mal defini.
Abandon ou non-utilisation
Le projet est annule, ou livre mais jamais adopte par les utilisateurs.
En realite : C'est le seul critere qui mesure vraiment l'echec — un projet annule, ou livre puis jamais adopte. C'est aussi le moins frequent des quatre : le confondre avec le total « non reussi » est l'erreur de lecture la plus courante sur ces statistiques.
La definition du Standish Group mesure le respect des engagements initiaux, pas la creation de valeur. Un projet 'challenge' peut etre un succes business. Un projet 'succes' peut etre un desastre strategique.
L'evolution historique : ce qu'on peut en dire sans la source primaire
Le premier rapport CHAOS date de 1994, et les chiffres de plusieurs millesimes circulent largement. Nous avions publie ici une frise annee par annee ; nous l'avons retiree faute de pouvoir rapprocher chaque ligne de son edition d'origine.
Le probleme n'est pas seulement l'exactitude d'un pourcentage. D'une edition a l'autre, le Standish Group a fait evoluer sa methode et ses criteres — dont la definition meme de ce qu'est un projet « reussi ». Comparer deux annees revient alors a comparer deux regles de comptage, pas deux realites. C'est pourquoi nous ne reprenons pas la lecture « le taux d'echec n'a pas bouge depuis trente ans » : elle suppose une continuite de definition que nous ne pouvons pas verifier.
La vraie question n'est pas « quelle nouvelle methode va tout changer ? », mais « que mesurons-nous exactement, et sur quel perimetre ? »
L'impact de la taille : une regularite robuste, des chiffres a manier
C'est le constat le plus constant de la litterature sur les projets IT : plus un projet est gros et long, plus il derape. Nous affichions ici un taux de succes par tranche de budget ; ces taux venaient des memes series non rapprochees et ont ete retires.
Le sens de la relation, lui, ne depend pas d'un pourcentage precis : un projet de dix-huit mois accumule dix-huit mois d'hypotheses avant sa premiere confrontation au reel, et une estimation faite a cette distance est une conjecture. Ce qui se verifie chez vous, sans aucune source externe, c'est la duree entre deux points de decision reels.
Pour une ETI, la conclusion pratique est inchangee : decoupez vos grands projets en initiatives de trois a six mois. Chaque livraison intermediaire est un point de decision, pas un jalon administratif.
L'impact des methodes agiles : mieux, mais pas miraculeux
L'agilite est souvent presentee comme la solution aux echecs de projets. Nous comparions ici deux lignes chiffrees waterfall / agile ; elles proviennent des memes series non rapprochees et ont ete retirees. Les reserves d'interpretation ci-dessous, elles, tiennent quelle que soit la valeur exacte de l'ecart.
Correlation vs causalite
Les organisations qui adoptent l'agilite sont peut-etre deja plus matures. L'effet serait alors lie a la culture, pas a la methode.
Definition floue
Qu'est-ce qu'un projet 'agile' ? Une equipe qui fait des sprints de 2 semaines mais subit une roadmap imposee n'est pas vraiment agile.
Biais de survie
Les projets agiles sont souvent plus petits. Et on a vu que la taille est le facteur determinant.
L'agilite aide, mais elle ne resout pas le probleme fondamental : trop de projets pour la capacite disponible, pas d'arbitrage reel, engagements irrealistes des le depart.
Ce que ces statistiques ne mesurent pas
Les chiffres Standish Group mesurent le respect des engagements initiaux. Ils ne mesurent pas ce qui compte vraiment pour une entreprise.
La valeur business reellement creee
Un projet peut livrer dans les temps et le budget, mais ne jamais generer le ROI attendu. A l'inverse, un projet 'challenge' peut creer une valeur disproportionnee.
Un ERP livre avec 6 mois de retard mais qui transforme l'efficacite operationnelle est-il un echec ?
Le cout d'opportunite
Pendant qu'une equipe travaille sur un projet qui depasse, elle ne travaille pas sur autre chose. Ce cout invisible n'est jamais mesure.
18 mois sur un projet qui derape, c'est 18 mois de non-innovation ailleurs.
L'impact sur les equipes
Les projets en difficulte epuisent les equipes. Le turnover, le burn-out, la perte de competences ne sont jamais comptabilises.
Un projet 'reussi' au prix de 3 demissions cle est-il vraiment un succes ?
La qualite de la decision initiale
Les statistiques mesurent l'execution, pas la pertinence du projet. Livrer parfaitement un projet inutile reste un echec strategique.
Combien de projets 'reussis' n'auraient jamais du etre lances ?
Les statistiques Standish Group sont utiles pour prendre conscience du probleme. Elles sont insuffisantes pour le resoudre.
Pourquoi votre entreprise n'est pas une statistique
Face a ces chiffres, deux reactions sont possibles. La resignation : 'C'est comme ca, on ne peut rien y faire.' Ou la lucidite : 'Ces statistiques decrivent la moyenne, pas une fatalite.'
Votre entreprise n'est pas condamnee a un taux d'echec de 70%. Les 30% qui reussissent ne sont pas plus intelligents - ils ont mis en place des mecanismes differents.
Ils disent non
Les organisations qui reussissent refusent activement des projets. Pas parce qu'ils sont mauvais - parce qu'elles n'ont pas la capacite de les faire bien.
Ils decoupent les gros projets
Au lieu d'un projet de 18 mois, ils font 6 initiatives de 3 mois. Chaque livraison est un point de decision.
Ils mesurent la realite, pas le plan
Ils savent ce qui consomme de la capacite, ce qui avance vraiment, ce qui bloque. Pas des tableaux green/orange/red.
Ils ajustent en continu
Un projet qui derape n'est pas un echec a cacher. C'est une information pour decider : on continue, on reduit, ou on arrete.
La vraie question n'est pas 'Quel est le taux d'echec moyen ?' C'est 'Que devez-vous changer pour ne pas etre dans la moyenne ?'
L'approche Quarter Plan : s'attaquer aux causes, pas au score
La methode Quarter Plan s'attaque aux causes d'echec que ces statistiques designent — surcharge, horizon trop long, absence d'arbitrage — sans promettre de faire basculer un taux.
Engagements trimestriels, pas annuels
Plus l'horizon d'engagement est long, plus l'estimation initiale s'eloigne du reel avant la premiere confrontation. Quarter Plan structure tous les engagements sur 90 jours maximum.
Impact : Vous passez de 3 gros paris a 12 ajustements mesurables par an
Arbitrage par la capacite
L'echec vient souvent de la surcharge : trop de projets pour les equipes disponibles. Quarter Plan lie explicitement engagement et capacite reelle.
Impact : Vous arretez de promettre ce que vous ne pouvez pas tenir
Visibilite totale du portefeuille
Ces statistiques ne comptent que les projets « officiels ». Mais la capacite est aussi consommee par le run, les urgences et les initiatives jamais arbitrees.
Impact : Vous voyez enfin tout ce qui consomme de la capacite - et pouvez arbitrer
Boucles de feedback courtes
Un projet qui derape pendant 18 mois accumule 18 mois de dette. Des bilans trimestriels permettent de corriger en 90 jours.
Impact : Les problemes sont visibles et traitables, pas caches et catastrophiques
Quarter Plan ne garantit pas 100 % de succes - c'est impossible. Il agit sur les causes systemiques que ces statistiques designent : trop de projets pour la capacite disponible, des engagements pris trop loin de leur echeance, et des arbitrages jamais rendus explicites.
Les resultats a mesurer sur votre portefeuille
Nous affichions ici quatre resultats chiffres de l'approche Quarter Plan et un temoignage anonyme. Ni le perimetre, ni l'effectif, ni la periode de ces chiffres n'etaient verifiables : nous les avons retires plutot que de les sourcer apres coup. Ils ne reviendront qu'avec un cas identifiable, son perimetre et sa periode.
Avant le premier cycle, relevez le nombre de projets en cours, le delai d'arbitrage, les engagements arrives a echeance et leur etat reel. A la fin du trimestre, comparez ces indicateurs avec les memes regles de calcul. Cette mesure decrit votre portefeuille ; elle ne constitue pas une garantie de performance du Quarter Plan.
Projets en cours
Comptes au meme jour du trimestre, selon la meme definition de « en cours » — y compris ceux que personne n'a officiellement lances.
Delai d'arbitrage
Temps entre la demande et la decision, tenue ou refusee. Une decision refusee reste une decision : ne comptez pas seulement les « oui ».
Engagements arrives a echeance
Part tenue parmi ceux qui devaient l'etre sur la periode. Fixez la regle avant le cycle, pas apres l'avoir lu.
Benefices effectivement obtenus
Le plus souvent non mesure au depart. Si c'est le cas, notez-le comme « non disponible » et designez qui en etablira la reference — ne le remplacez pas par zero.
Ressources complementaires
70% des projets strategiques echouent
Analyse approfondie des causes systemiques d'echec et comment les eviter.
La methode Quarter Plan
Vue complete de l'approche en 4 etapes : cartographier, arbitrer, engager, livrer.
Gouvernance de portefeuille
Comment installer une gouvernance qui prend des decisions et les tient.
Nos offres d'accompagnement
Comment nous pouvons vous aider a passer dans les 30% qui reussissent.
Autres benchmarks IT
Budget IT moyen des ETI
Les chiffres de référence par taille et secteur d'activité.
Nombre de projets en portefeuille
Combien de projets une DSI peut-elle gérer efficacement ?
Durée de mandat des DSI
Pourquoi le turnover DSI est le plus élevé du COMEX.
Ratio budget IT / CA
Êtes-vous dans la moyenne de votre secteur ?
Prêt à passer de l'intention à l'exécution ?
Étude exclusive · 15 ans de données · 9 295 DSI