Exemple de transformation digitale ratée : 5 cas documentés
L’exemple de transformation digitale ratée le mieux documenté en France est un projet public, arrêté après douze années de travaux. Quatre autres dossiers analysés par la Cour des comptes montrent les mêmes engrenages : un périmètre trop large, des règles de gestion jamais écrites, des utilisateurs absents du cahier des charges.
Un exemple de transformation digitale ratée se mesure sur trois cibles
Le National Audit Office estonien a analysé en septembre 2019 neuf projets portés par huit ministères. Sa définition de l’échec tient en une phrase : le non-respect d’au moins un des trois objectifs de départ, budget, délais ou fonctionnalités attendues. Quatre des neuf projets entraient dans cette catégorie.
Cette grille déplace le diagnostic : un projet livré à l’heure et dans son budget, mais couvrant la moitié des usages prévus, reste un échec qu’aucun reporting financier ne signale.
Côté français, la direction interministérielle du numérique suit une cinquantaine de grands projets de l’État, chacun au coût supérieur à 9 millions d’euros. La neuvième édition de son panorama, reprise par la Cour des comptes, fait apparaître des dérives moyennes de 36,1 % sur les délais et de 35,6 % sur les coûts, pour une durée prévisionnelle située entre six et sept ans.
Une transformation digitale ratée ne démarre donc presque jamais par une panne spectaculaire. Elle commence par un écart de quelques semaines que personne ne tranche.
Louvois : un calculateur branché sur des systèmes inachevés
Engagé en 2001 par le ministère de la défense, le projet Louvois devait unifier et automatiser le calcul des soldes des militaires dans un logiciel unique. Son déploiement est intervenu dix ans plus tard, sur une partie seulement des employeurs visés. Fin 2012, le ministre suspend toute nouvelle intégration ; fin 2013, l’abandon à terme est annoncé.
Dans un référé du 27 décembre 2013, la Cour des comptes évalue les erreurs de calcul du système à 465 millions d’euros pour la seule année 2012. La commission des affaires étrangères, de la défense et des forces armées de l’Assemblée nationale, dans son avis sur le projet de loi de finances 2019, estime le coût initial de développement à environ 80 millions d’euros, auxquels s’ajoutent 156,4 millions de surcoûts induits par les dysfonctionnements depuis 2013.
La mécanique de l’échec se lit en trois temps. Les spécifications détaillées des règles de solde n’ont jamais été rédigées. Le calculateur devait se brancher sur des systèmes de gestion des ressources humaines eux-mêmes en cours de développement. Et des réductions d’effectifs décidées pour des raisons budgétaires ont fait disparaître les experts capables de traiter à la main les erreurs détectées par les contrôles automatiques.
L’Opérateur national de paye : une cible hors d’atteinte dès le départ
Lancé en 2007, ce programme visait la paye de 2,7 millions d’agents publics grâce à un calculateur unique alimenté par les systèmes de ressources humaines des ministères, avec un gain de productivité annoncé de 3 800 postes.
La Cour des comptes documente un écart de complexité rarement mesuré avant signature. De grandes entreprises gèrent une centaine de règles de paie, quand l’État rémunère ses agents sur la base d’environ 1 500 éléments de paie distincts, déclinés différemment d’un ministère à l’autre. Le programme supposait aussi que huit systèmes ministériels partagent des référentiels communs restant largement à bâtir.
Un choix de conception a scellé le dossier : contrairement à la plupart des grands projets, celui-ci ne prévoyait aucun livrable intermédiaire. Rien d’utilisable avant la bascule complète, donc aucune preuve avant la fin. La Cour chiffre le coût complet engagé à environ 346 millions d’euros à fin 2013, sur six ans, et l’arrêt s’est traduit par une dépréciation de 140 millions à l’actif de l’État.
Sirhen : douze années de travaux pour 18 000 dossiers gérés
Le système de gestion des ressources humaines de l’éducation nationale a démarré en 2007, doté de 60 millions d’euros, pour une échéance fixée à 2012. Dès 2014, le coût dépasse 300 millions d’euros hors personnel interne. Une trajectoire actualisée en 2016 fixe une enveloppe de 496,4 millions, alors que plus de 200 millions avaient déjà été dépensés fin 2015.
Le chiffre le plus parlant du dossier date du premier semestre 2018 : 75 % du budget consommés pour couvrir 5 % des populations cibles et réaliser 60 % des points de fonction prévus. En juillet 2018, l’arrêt est annoncé après douze années de travaux et près de 400 millions d’euros investis, alors que le système ne gérait que 18 000 personnels.
La Cour des comptes relève que les défauts repérés dès 2016 n’ont pas été corrigés : architecture mal conçue, besoins fonctionnels insuffisamment documentés, acteurs désalignés, pilotage stratégique défaillant, emprise forte des prestataires extérieurs sans moyens internes de suivi proportionnés. Le passage aux méthodes agiles, décidé lors de la refondation, n’a pas produit ses effets assez vite.
Cassiopée : un cahier des charges écrit sans ses utilisateurs
Décidé en 2001, ce projet devait remplacer les applications du ministère de la justice jugées obsolètes et unifier la chaîne pénale dans un système unique. Près de vingt ans plus tard, certaines de ces applications étaient toujours en service.
Au moment du déploiement, en 2013, le coût et la durée s’établissaient environ au double des prévisions initiales, sans répondre aux attentes des utilisateurs. La Cour des comptes désigne la cause en une ligne : les besoins des magistrats instructeurs n’avaient pas été pris en compte au stade du cahier des charges. Le projet a aussi vu se succéder sept directeurs entre 2001 et 2014.
Deux enseignements transposables. Un utilisateur absent du cadrage revient toujours, mais au moment de la recette, quand chaque correction coûte beaucoup plus cher. Et la rotation des responsables efface la mémoire des arbitrages, jusqu’à ce que personne ne sache plus pourquoi telle règle a été codée ainsi.
Un cinquième dossier hors de France : 200 systèmes remplacés d’un coup
La Cour des comptes cite aussi des cas étrangers. Le plus net concerne l’Expeditionary Combat Support System de l’armée de l’air américaine, destiné à rationaliser et automatiser ses opérations en remplaçant plus de 200 systèmes historiques. Le programme a été arrêté en 2012, huit ans après son lancement, pour un coût de 1,1 milliard de dollars.
Le point commun avec les dossiers français saute aux yeux : remplacer simultanément tout un parc applicatif multiplie les dépendances, et chaque dépendance devient une occasion de blocage. La même juridiction cite à l’inverse des réussites notables, comme le prélèvement à la source, et défend une doctrine de projets plus modestes et plus modulaires, celle que suivent nos exemples de transformation numérique aboutie.
Les causes qui reviennent d’un dossier à l’autre
| Projet | Décision documentée | Cause dominante relevée |
|---|---|---|
| Louvois, solde des militaires | Abandon annoncé fin 2013 | Règles jamais spécifiées, dépendance à des systèmes inachevés |
| Opérateur national de paye | Arrêt après six années engagées | Ambition excessive, aucune livraison intermédiaire |
| Sirhen, ressources humaines | Arrêt annoncé en juillet 2018 | Besoins mal documentés, suivi des prestataires insuffisant |
| Cassiopée, chaîne pénale | Périmètre en deçà de la cible | Utilisateurs absents du cadrage, sept directeurs successifs |
| Expeditionary Combat Support System | Arrêt en 2012 | Remplacement simultané de plus de 200 systèmes |
Un dénominateur traverse les cinq dossiers : la sous-estimation en amont. La mission conjointe de l’inspection générale des finances et du conseil général de l’économie l’écrivait dès mars 2012 : les difficultés rencontrées trouvent principalement leur origine dans une mauvaise appréhension des choix majeurs, au lancement comme dans la conduite des programmes.
L’étude menée en 2012 par McKinsey avec l’université d’Oxford sur plus de 5 400 projets numériques, citée par la Cour des comptes, relève que près de la moitié des grands projets dépassent massivement leur budget et que chaque année de durée supplémentaire ajoute en moyenne 15 % de coût. Pour 17 % d’entre eux, l’impact serait tel que la survie de l’entreprise pourrait être mise en cause.
Le détail des mécanismes internes, service par service, figure dans notre analyse des projets de transformation numérique qui échouent ; les dossiers ci-dessus en donnent la version chiffrée.
Les signaux d’alerte pendant votre projet
Aucun de ces dossiers n’a basculé du jour au lendemain : chacun a émis des signaux d’alerte pendant des mois. Voici ceux qui se repèrent dans une PME, sans audit particulier.
- Les cas de gestion les plus tordus de votre activité ne sont écrits nulle part, alors que le paramétrage a commencé.
- Deux chantiers dépendants avancent en parallèle, le nouvel outil et la refonte du référentiel censé l’alimenter.
- Le premier livrable réellement utilisable arrive après la bascule totale, pas avant.
- La reprise des données glisse de réunion en réunion, faute de propriétaire désigné.
- Le paramétrage n’est documenté que par le prestataire, sans procédure interne équivalente.
- Les personnes qui connaissent les exceptions métier quittent le service avant la mise en production.
- Le glissement de calendrier passe d’un comité à l’autre sans décision.
Le cinquième point renvoie au rapport sur Sirhen, qui pointe une emprise forte des prestataires sans suivi interne proportionné. Les critères pour cadrer cette relation figurent dans notre article sur le conseil en transformation digitale : périmètre écrit, livrables nommés, transfert de compétences au contrat.
Ce qu’un dirigeant de PME retient concrètement
Six décisions découlent de ces dossiers, et aucune ne demande de budget supplémentaire.
- Écrire les règles de gestion avant de choisir l’outil, en commençant par les exceptions. Un fournisseur se juge sur sa réponse à votre cas le plus tordu.
- Découper le périmètre par paliers, avec un livrable utilisable toutes les six à huit semaines. Une preuve d’usage vaut mieux qu’un plan à dix-huit mois.
- Désigner une responsabilité unique, avec un mandat écrit et du temps dégagé.
- Poser un jalon de décision et ses critères d’arrêt avant le premier euro dépensé, puis l’examiner sans le déplacer.
- Protéger les personnes qui détiennent la connaissance des exceptions, et documenter le paramétrage en interne au fil de l’eau.
- Prévoir une recette fonctionnelle avant mise en production et un bilan de fin de projet partagé, deux des sept bonnes pratiques du Cigref reprises par la Cour des comptes.
Ces arbitrages se préparent au chiffrage, pas en cours de route. L’ordre des étapes est détaillé dans notre guide stratégique de la transformation digitale, et les aides mobilisables sur la partie investissement dans notre article sur le financement d’une transformation numérique.
Prochaine étape : reprenez le dernier projet numérique lancé chez vous et vérifiez trois points, les règles de gestion écrites, la date du prochain livrable utilisable, le nom de la personne qui décide. Un vide sur l’un des trois localise votre risque.