Grands projets numériques de l’Etat : un exercice d’équilibriste

La cour des comptes, dans l’un de ses derniers rapports, dresse un bilan sévère de la conduite des grands projets numériques de l’Etat. A croire que les bonnes pratiques connues depuis longtemps et les retours d’expériences des échecs de grands projets ne servent à rien.

Dans son dernier rapport sur les grands projets numériques de l’Etat (*), la Cour des comptes reconnait que c’est « un exercice difficile, qui n’est pas l’apanage du secteur public. Si l’État a connu des réussites notables, comme récemment celui du prélèvement à la source, il a néanmoins subi des échecs, à l’instar de grandes entreprises du secteur privé, françaises ou étrangères. » Bien évidemment, des leçons ont été tirées des difficultés passées.

La Cour des comptes, qui a audité une cinquantaine de grands projets numériques (de plus de neuf millions d’euros), déplore « le peu de progrès et des bonnes pratiques encore trop souvent méconnues. » Ainsi, les écarts entre les coûts et délais de réalisation constatés et les prévisions faites au début des projets se sont fortement dégradés depuis 2015 : les dérives ont plus que doublé et dépassent sensiblement le seuil de 30 %.

Pour les magistrats, « l’ambition, posée en 2019 par le plan d’action gouvernemental pour le numérique Tech.Gouv, de ramener ces dérives à moins de 20 % d’ici 2022, apparaît difficilement atteignable sans de strictes mesures de redressement sur l’ensemble du portefeuille des projets de l’État. À de rares exceptions près, comme pour la mise en œuvre du prélèvement à la source, les ministères ont du mal à resserrer les durées de réalisation des projets. Cela témoigne de leur incapacité à ajuster le nombre et les ambitions des projets aux budgets nécessaires, pour les réaliser sur des durées plus courtes, ainsi que de leur difficulté à arrêter des projets dont l’échec est inéluctable. »

On se souvient des échecs passés, notamment ceux concernant les projets Louvois, ONP et Cassiopée. Le premier, engagé en 2001 pour unifier et automatiser la gestion des soldes des militaires à travers un seul logiciel, mais déployé dix ans plus tard, a été victime « d’une défaillance organisationnelle, impliquant de trop nombreux intervenants, d’une mise en œuvre prématurée de réductions d’effectifs dans les services gestionnaires de la solde pour des raisons budgétaires et d’une sous-estimation de la difficulté du projet. »

Le deuxième, lancé en 2007, visait à établir la paye de 2,7 millions d’agents publics grâce à un nouveau calculateur qui aurait été alimenté automatiquement par les systèmes d’information pour les ressources humaines (SIRH) des ministères. Initiative ambitieuse, elle impliquait, d’une part, la réécriture complète des programmes de la chaîne de paiement des rémunérations et, d’autre part, l’adaptation des SIRH des ministères pour intégrer automatiquement des flux d’informations vers les applications de paiement. Son échec est imputable, selon la Cour des comptes « à son ambition excessive, à un manque de pragmatisme, à sa gouvernance défaillante et au manque d’expérience de ses responsables. »

Quant au troisième, il devait remplacer l’ensemble des applications existantes au sein du ministère de la Justice, considérées comme obsolètes, et unifier la chaîne pénale en un seul système d’information. Mais, près de vingt ans plus tard, certaines de ces applications sont encore utilisées. Ce projet a été mené sans prendre en compte, au stade du cahier des charges, les besoins des utilisateurs. Le fait que se sont succédés, entre 2001 et 2014, pas moins de sept directeurs de projets n’a rien arrangé, d’autant qu’ils n’avaient pas autorité sur les équipes de développement !

Quatre domaines à risque

On trouve plusieurs facteurs à l’origine des dysfonctionnements, que l’on peut d’ailleurs aussi identifier dans les projets menés par les entreprises privées.

  • Les facteurs organisationnels. Ils concernent le nombre trop important de parties prenantes au projet, porteurs d’intérêts et de points de vue divergents, et les trop fréquentes réorganisations engagées dans le projet.
  • Les aspects budgétaires. Ils tiennent à la mise en œuvre prématurée de réductions d’effectifs. Par, exemple, pour le projet Louvois, des ressources expertes ont ainsi disparu, faisant défaut pour réaliser les contrôles automatiques intégrés, indispensables dans la nouvelle application.
  • Les difficultés techniques. On observe souvent une sous-estimation de la difficulté du projet, au regard de la complexité des règles de gestion. Les spécifications fonctionnelles détaillées de ces règles ne sont pas suffisamment explicitées. Par ailleurs, le cadencement du projet et son architecture fonctionnelle s’avèrent inadaptés : par exemple, pour le projet Louvois, il était prévu de connecter le calculateur de paye à des systèmes de gestion des ressources humaines censés l’alimenter, alors qu’eux-mêmes étaient également en cours de développement.
  • Le manque de compétences. Pour la Cour des comptes, « l’État peine, tout comme le secteur privé, à se doter des compétences dont il a besoin et à les conserver. La direction générale de l’administration et de la fonction publique (DGAFP) et la Dinum ont identifié quinze métiers en tension, dont six ont trait à la conduite des grands projets numériques ». Les délais de recrutement par concours restent cependant trop longs et ne sont pas adaptés à un marché en tension. Ils laissent peu de chance face à la concurrence du secteur privé qui peut recruter ces compétences en quelques jours. D’où un recours fréquent à la sous-traitance : les achats de prestations intellectuelles informatiques représentaient, en 2018, près de 830 millions d’euros (160 millions de plus qu’en 2016…), dont près des deux-tiers sont consacrés à la conception et au développement d’applications dans le cadre de projets. L’État dispose en permanence de 500 postes de statut fonctionnaire ou contractuel ouverts dans le numérique, de bac +3 à bac +5 et plus.

La Cour des comptes rappelle les trois grandes règles de l’art qu’il convient de respecter pour limiter les échecs. D’abord, réduire la taille des projets numériques et les allotir pour procéder à des mises en service successives selon des jalons courts, apportant de la valeur de façon continue. « Elles mettent également en avant l’importance de l’organisation et des méthodes de pilotage, qui doivent notamment faciliter des prises de décision rapides », estime la Cour des comptes.

Ensuite, surtout dans le cas de projets complexes, il est essentiel de désigner un responsable unique, ayant autorité pour prendre les décisions et les faire appliquer par l’ensemble des équipes chargées de la conception, de la réalisation, des tests de recettes, de l’intégration, de la reprise des données, de la mise en production et du déploiement des applications.

Enfin, rappelle la Cour des comptes, « la prise en compte des besoins et de l’avis des utilisateurs à tous les stades du projet est également indispensable à sa réussite finale. » D’autant que les enjeux financiers sont colossaux : environ six milliards d’euros, en ce qui concerne les logiciels et applications mis en service à fin décembre 2018, et un flux annuel d’investissements évalué à 380 millions d’euros en 2019, soit 3 % des investissements totaux de l’État.

Pour la Cour des comptes, le succès repose sur l’atteinte de quatre cibles : budgétaire, calendaire, fonctionnelle et satisfaction des utilisateurs. « L’échec peut alors être considéré comme le fait de ne pas atteindre l’une ou l’autre de ces cibles, et conduire, dans des cas de dépassement ou de manquement extrêmes, à l’abandon du projet. Les directions métier considèrent que l’atteinte de la cible fonctionnelle et la satisfaction des utilisateurs sont des critères d’évaluation prioritaires. »

(*) La conduite des grands projets numériques de l’Etat, Cour des comptes. Document téléchargeable sur le site de la Cour des comptes : www.ccomptes.fr/system/files/2020-10/20201014-58-2-conduite-grands-projets-numeriques-Etat.pdf


Les recommandations de la Cour des comptes

  • Ne prévoir aucun grand projet numérique dont la réalisation dépasserait cinq ans.
  • S’engager dans une démarche de simplification des procédures/processus (et de la réglementation, pour le secteur public) préalablement au lancement des projets numériques d’ampleur.
  • S’assurer, pour chacun des grands projets, de la désignation d’un responsable unique ayant autorité pour prendre les décisions et les faire appliquer par l’ensemble des équipes engagées dans le projet.
  • Privilégier un pilotage par les délais, en structurant les projets autour de jalons courts, correspondant à un apport de valeur et de fonctionnalités aux utilisateurs du service numérique.
  • Respecter les ratios minimaux de ressources humaines internes nécessaires au pilotage et à la réalisation des projets.
  • Intégrer, dès la conception des projets numériques et tout au long de leur développement, les besoins des utilisateurs et évaluer systématiquement leur satisfaction.
  • Améliorer les plans d’investissement numérique et leur description analytique en distinguant, pour chaque projet, les coûts de construction des coûts récurrents.
  • Examiner, préalablement au lancement d’un projet, la possibilité de privilégier une solution mutualisée.

Les facteurs de risques

A partir d’une analyse des projets menés entre 2011 et 2019, la Dinum (Direction interministérielle du numérique) a identifié les dix facteurs de risques les plus fréquents (par ordre décroissant d’importance) :

  • Une trajectoire de projet inadaptée.
  • Une insuffisance du financement et des moyens humains.
  • Une inadaptation de la gouvernance.
  • Une insuffisance de l’évaluation du projet.
  • Une insuffisance du dossier technique.
  • Une sous-estimation des enjeux de mutualisation et d’ouverture des données.
  • Une sous-estimation des besoins des utilisateurs.
  • Une insuffisance des spécifications fonctionnelles.
  • Une prise en compte insuffisante des enjeux de sécurité.
  • Une maîtrise insuffisante des méthodes agiles.

Les principaux facteurs d’échecs des projets numériques

  • Des changements de fonctionnalités ont été demandés en cours de projet.
  • Les directeurs de projet n’ont pas suffisamment pris en compte les attentes des utilisateurs.
  • La coopération entre les intervenants a été insuffisante.
  • Les rôles des différents participants aux projets n’étaient pas clairement définis.
  • Les changements dans les équipes ont été trop fréquents.
  • La législation qui sous-tendait les fonctionnalités du projet a été modifiée en cours de route.
  • Les plans de développement étaient trop optimistes.