Grands projets informatiques publics : pourquoi ils dérapent
- Les chiffres d'échec les plus cités reposent sur des méthodes discutées ; les études universitaires montrent surtout une queue de distribution très épaisse
- Les rapports d'audit publics décrivent des mécanismes récurrents : ambition en un bloc, responsabilité diluée, complexité réglementaire sous-estimée, bascule sans repli
- Le secteur public ajoute des contraintes propres : règles changeantes, visibilité politique, difficulté à arrêter
- Les signaux précoces sont observables ; ce qui manque le plus souvent, c'est un dispositif pour les remonter et une autorité pour décider
En 2011, deux chercheurs d’Oxford, Bent Flyvbjerg et Alexander Budzier, publiaient dans la Harvard Business Review l’analyse de près de 1 500 projets informatiques. Le dépassement moyen de budget y était modéré. Mais un projet sur six dépassait son budget d’environ 200 % en moyenne, avec un retard de près de 70 %. Ce résultat déplace la question des échecs des grands projets informatiques publics : le risque n’est pas un dépassement moyen que l’on pourrait provisionner, c’est une queue de distribution où quelques projets coûtent plusieurs fois ce qui était prévu.
Cet article confronte les études quantitatives aux rapports d’audit publiés sur des projets publics emblématiques, pour en tirer les mécanismes récurrents. Il propose ensuite une hypothèse et une manière de suivre ces mécanismes dans un portefeuille de projets.
Ce que mesurent les études
Le chiffre le plus cité dans les présentations reste celui des rapports CHAOS du Standish Group, qui classent depuis les années 1990 les projets en « réussis », « contestés » et « échoués ». Ces rapports ont popularisé l’idée qu’une majorité de projets informatiques échouent. Leur méthode a été discutée : en 2010, J. Laurenz Eveleens et Chris Verhoef montraient dans IEEE Software que la définition de la réussite, fondée sur l’écart à l’estimation initiale, mesure autant la qualité des estimations que celle des projets, et que l’échantillon n’était pas représentatif. Les chiffres CHAOS disent quelque chose ; ils ne disent pas ce qu’on leur fait dire.
Les travaux qui portent sur de grands échantillons de projets documentés convergent sur un autre constat. Une étude conduite en 2012 par McKinsey avec l’université d’Oxford sur plus de 5 000 projets concluait qu’en moyenne, les grands projets informatiques dépassaient leur budget de 45 % et leur calendrier de 7 %, tout en délivrant 56 % de valeur de moins que prévu. Les travaux de Flyvbjerg et Budzier insistent, eux, sur la forme de la distribution : les dépassements extrêmes sont bien plus fréquents qu’une loi « normale » ne le laisserait penser.
Le danger d’un grand projet informatique n’est pas le dépassement moyen. C’est la probabilité, sous-estimée, d’un dépassement qui change d’ordre de grandeur.
Ces études mélangent projets publics et privés. Pour comprendre ce qui se passe dans le public, il faut se tourner vers une autre source, plus qualitative mais très détaillée : les rapports des institutions de contrôle.
Ce que racontent les rapports d’audit
Plusieurs projets publics ont fait l’objet d’analyses approfondies par les cours des comptes, les auditeurs parlementaires ou les vérificateurs généraux. En France, le logiciel de solde des militaires Louvois et le projet d’Opérateur national de paye ont été arrêtés après des années de difficultés, et examinés par la Cour des comptes. Au Royaume-Uni, le programme national d’informatisation du service de santé (National Programme for IT) a été démantelé à partir de 2011, après des rapports critiques du National Audit Office et de la commission des comptes publics. Au Canada, le système de paye Phénix, mis en service en 2016, a fait l’objet de rapports du vérificateur général. Aux États-Unis, le lancement du site HealthCare.gov en octobre 2013 a été suffisamment difficile pour conduire, l’année suivante, à la création du United States Digital Service.
Ces projets sont différents par leur objet, leur pays et leur époque. Leurs rapports décrivent pourtant des mécanismes qui se ressemblent beaucoup.
| Mécanisme | Comment il se manifeste | Signal précoce observable |
|---|---|---|
| L’ambition en un bloc | Remplacer d’un coup plusieurs systèmes, pour toutes les populations, à une date unique | Aucune livraison utilisable avant la bascule finale |
| La complexité réglementaire sous-estimée | Des milliers de règles (paie, prestations, fiscalité), souvent mal documentées et qui changent pendant le projet | Le recensement des règles est encore en cours alors que le développement a commencé |
| La responsabilité diluée | Plusieurs directions, plusieurs ministères ou organismes, personne qui puisse trancher | Des arbitrages reportés d’un comité à l’autre |
| La perte de maîtrise interne | Le savoir sur le système et sur les règles se trouve chez le prestataire, plus dans l’administration | L’équipe interne ne peut pas expliquer seule l’état réel du projet |
| La bascule sans repli | L’ancien système est arrêté ou figé avant que le nouveau ait fait ses preuves | Pas de fonctionnement en parallèle prévu, ou prévu puis supprimé pour tenir la date |
| L’optimisme de planification | Budget et calendrier fixés sur ce que l’on espère, pas sur ce qu’ont coûté des projets comparables | Aucune comparaison avec des projets de même nature dans le dossier d’engagement |
Le dernier mécanisme est le mieux documenté par la recherche. Daniel Kahneman et Amos Tversky ont décrit dès la fin des années 1970 l’« erreur de planification », cette tendance à estimer un projet à partir de son scénario idéal. La parade proposée, la prévision par classe de référence, consiste à partir de la distribution réelle des coûts et des délais de projets comparables, puis à ajuster. Flyvbjerg en a fait une méthode appliquée aux grands projets d’infrastructure, puis informatiques.
Pourquoi le secteur public est plus exposé
Rien dans ces mécanismes n’est propre au public. Plusieurs traits de l’action publique les rendent toutefois plus probables et plus coûteux.
La règle change pendant le projet. Une réforme législative ou réglementaire peut modifier les calculs au milieu du développement, avec une date d’application fixée par le texte et non par l’avancement technique.
Le périmètre est universel. Une entreprise peut lancer un nouveau système sur une filiale ou un segment de clientèle. Un système de paye ou de prestations doit souvent traiter tout le monde, y compris les cas rares et complexes, dès le premier jour.
Arrêter est difficile. Un projet annoncé publiquement, engagé sur plusieurs exercices budgétaires et porté politiquement, est plus difficile à interrompre qu’un projet interne d’entreprise. Les rapports d’audit montrent des projets poursuivis longtemps après l’apparition de signaux graves.
Le marché est figé tôt. Les règles de la commande publique imposent de décrire le besoin avant de contracter. Un besoin mal compris au moment du marché se corrige ensuite par avenants, souvent coûteux. D’où l’importance de la préparation, détaillée dans notre dossier sur l’achat numérique public.
Ce qui a changé en quinze ans
Les échecs des années 2000 et 2010 ont produit des réponses institutionnelles. Le Royaume-Uni a créé en 2011 le Government Digital Service, avec des standards de service qui imposent de livrer par étapes et de tester avec les usagers. Les États-Unis ont créé le United States Digital Service en 2014. En France, la démarche des startups d’État, portée depuis 2013 par ce qui est devenu beta.gouv.fr, a montré qu’on pouvait construire des services publics par petites équipes et par itérations courtes. La direction interministérielle du numérique publie un panorama des grands projets numériques de l’État, qui rend visibles leur coût et leur calendrier.
Ces réponses partagent une logique : découper, livrer tôt, garder la maîtrise en interne, rendre les écarts visibles. Elles ont fait leurs preuves sur des services nouveaux. Elles restent plus difficiles à appliquer aux grands systèmes de gestion (paye, fiscalité, prestations sociales), où l’on remplace un existant massif qui ne peut pas s’arrêter.
Une hypothèse et une manière de la vérifier
Notre hypothèse de travail est la suivante : le meilleur prédicteur d’un dérapage grave n’est ni la technologie choisie, ni la méthode de développement, mais la combinaison de deux facteurs. La taille du plus petit lot livrable en production d’une part ; l’existence d’une autorité unique, capable d’arbitrer le périmètre et d’arrêter le projet, d’autre part. Un projet qui livre par petits lots sous une autorité claire peut se tromper, mais il se trompe tôt et à petite échelle.
Cette hypothèse peut être examinée sur un portefeuille de projets, à partir d’informations que toute organisation possède :
- Pour chaque projet, la date de la première livraison utilisée en production, rapportée à la durée totale prévue.
- Le nom de la personne qui peut arbitrer le périmètre et décider d’un arrêt, et la fréquence réelle de ses arbitrages.
- L’existence d’une estimation fondée sur des projets comparables, et l’écart entre cette estimation et le budget engagé.
- La part des règles métier recensées et testées au moment où le développement commence.
- La présence d’un fonctionnement en parallèle ou d’un plan de repli pour la bascule.
- La capacité de l’équipe interne à présenter seule l’état réel du projet.
Croiser ces informations avec les dépassements constatés, sur quelques dizaines de projets, permettrait de tester l’hypothèse. À défaut d’étude formelle, ces six points constituent déjà une grille de revue utilisable à chaque jalon.
Limites
Les projets examinés par les institutions de contrôle sont, par construction, ceux qui ont mal tourné : les projets réussis sont moins étudiés, ce qui biaise toute lecture qualitative. Les études quantitatives citées mêlent secteurs et pays, et leurs données ne sont pas toujours publiques. Enfin, les mécanismes identifiés interagissent : une ambition démesurée produit une gouvernance diluée, qui empêche d’arrêter. Isoler une cause unique serait une erreur de méthode.
Pour un acheteur public ou une direction de projet, la conclusion pratique reste solide : mesurer tôt, découper, garder un arbitre, et faire relire régulièrement le projet par des personnes qui n’y ont pas d’intérêt. C’est le rôle de notre expertise benchmark et appels d’offres, sans lien avec aucun éditeur ; et c’est ce que permet de prouver, après coup, une traçabilité des décisions comme celle que propose notre produit Gouvernance et traçabilité.
- Bent Flyvbjerg et Alexander Budzier, « Why Your IT Project May Be Riskier Than You Think », Harvard Business Review, septembre 2011.
- Michael Bloch, Sven Blumberg et Jürgen Laartz, « Delivering large-scale IT projects on time, on budget, and on value », McKinsey & Company, en collaboration avec l’université d’Oxford, 2012.
- J. Laurenz Eveleens et Chris Verhoef, « The Rise and Fall of the Chaos Report Figures », IEEE Software, 2010.
- Daniel Kahneman et Amos Tversky, travaux sur l’erreur de planification (planning fallacy), fin des années 1970.
- Cour des comptes (France), National Audit Office (Royaume-Uni), Bureau du vérificateur général du Canada : rapports publics sur les projets cités.
Questions fréquentes
Quel pourcentage de projets informatiques échouent ?
Il n'existe pas de chiffre fiable et universel. Les pourcentages les plus repris viennent d'enquêtes dont la définition de l'échec et l'échantillon ont été critiqués. Les travaux universitaires sur de larges échantillons concluent plutôt que le dépassement moyen est modéré, mais qu'une minorité de projets connaît des dérapages extrêmes, qui pèsent l'essentiel des pertes.
Les méthodes agiles suffisent-elles à éviter les dérapages ?
Elles réduisent un risque majeur, celui de découvrir tard que le système ne convient pas, en livrant tôt des parties utilisables. Elles ne règlent ni la gouvernance, ni la complexité des règles métier, ni la question de la bascule. Un grand projet découpé en itérations mais sans responsable capable d'arbitrer reste un grand projet à risque.
Comment savoir si un projet en cours dérape ?
Quelques signaux précèdent presque toujours les dérapages graves : un périmètre qui s'étend sans réévaluation du budget, des livraisons intermédiaires repoussées, des tests de bout en bout reportés à la fin, un écart croissant entre l'avancement déclaré et ce que les utilisateurs peuvent réellement faire. Une revue indépendante, conduite par des personnes qui ne dépendent ni du prestataire ni de l'équipe projet, permet de les objectiver.