Pourquoi les projets informatiques de l’État échouent si souvent, selon Lilith Wittmann et David Zellhöfer

Lilith Wittmann et David Zellhöfer ont consacré un échange à un sujet récurrent dans l’administration, l’échec à répétition des grands projets numériques. Invités du podcast c’t uplink, les deux spécialistes reviennent sur des mécanismes structurels qui dépassent le simple bug ou la faute d’un prestataire. Leur diagnostic vise un empilement de décisions, de procédures et d’incitations qui rendent l’issue défavorable presque prévisible, puis interroge un autre mot devenu central dans le débat public, la souveraineté numérique, dont ils contestent l’usage inflationniste et parfois performatif.

Leur propos s’inscrit dans un contexte européen où l’État est sommé d’accélérer, sous contrainte budgétaire et sous pression politique. En France, la Cour des comptes a déjà pointé, à plusieurs reprises, des dérives de coûts et de délais dans des programmes informatiques publics, et la Commission européenne rappelle régulièrement, via l’indice DESI, l’écart entre ambitions affichées et maturité réelle des services numériques. Dans cet environnement, la parole de praticiens qui dissèquent les causes d’échec et les angles morts du discours public apporte un contrepoint utile.

Des cahiers des charges figés, incompatibles avec des besoins qui changent

Une cause centrale décrite par Lilith Wittmann et David Zellhöfer tient à la façon dont l’administration formalise ses besoins. Les grands projets publics démarrent fréquemment par un cahier des charges exhaustif, conçu pour sécuriser l’achat, verrouiller le périmètre et limiter le risque juridique. Sur le papier, l’approche rassure. Dans la pratique, elle fige des hypothèses au moment même où le besoin opérationnel évolue, sous l’effet de réformes, de changements réglementaires, d’arbitrages internes ou de nouveaux usages.

Le problème n’est pas seulement technique. Il est organisationnel. Quand les spécifications deviennent un contrat plus qu’un outil de dialogue, l’équipe projet se retrouve à livrer une conformité documentaire plutôt qu’un service utilisable. Les invités de c’t uplink soulignent que l’informatique est un domaine où l’apprentissage par itération compte autant que la planification. Or l’achat public privilégie souvent la promesse initiale, au détriment de la capacité à corriger rapidement, à simplifier, à supprimer des fonctionnalités inutiles.

Cette logique nourrit une spirale classique, la dérive de périmètre. Chaque acteur veut inscrire sa demande dans le cahier des charges, car il sait que la fenêtre de tir est limitée. Résultat, le produit final devient une addition de cas particuliers, difficile à tester et encore plus difficile à maintenir. Les deux intervenants insistent sur le fait que la complexité administrative se retrouve copiée dans le logiciel, au lieu d’être questionnée. Le numérique, censé rationaliser, se transforme en miroir d’un millefeuille de procédures.

Dans beaucoup de programmes, la réussite est mesurée par la livraison d’un lot à une date donnée plutôt que par des indicateurs d’usage, de satisfaction, de taux d’erreur ou de temps gagné. Les méthodes agiles sont parfois invoquées, mais sans les prérequis, une autonomie réelle des équipes, un droit à réduire le périmètre, et une gouvernance capable d’arbitrer rapidement. Le discours agile devient alors une étiquette, pendant que la mécanique reste celle d’un projet linéaire.

Achats publics, prestataires et responsabilité, un triangle qui dilue les décisions

Le second nud analysé par David Zellhöfer et Lilith Wittmann touche à la relation entre l’administration et ses prestataires. Les projets d’État mobilisent souvent des chaînes de sous-traitance longues, avec intégrateurs, éditeurs, cabinets de conseil et fournisseurs d’infrastructure. Chaque maillon ajoute une couche de coordination, de reporting, de contractualisation. À mesure que l’organigramme s’épaissit, la responsabilité se dilue. Quand un incident survient, l’explication se perd dans les interfaces.

Les règles d’achat public, conçues pour garantir l’égalité d’accès et la transparence, créent aussi des incitations paradoxales. Elles valorisent des dossiers de réponse très structurés, des promesses de conformité et des références, parfois plus que la capacité à livrer un service robuste dans un environnement changeant. Les invités de c’t uplink décrivent un système où l’on peut gagner un marché en maîtrisant l’art du dossier, puis se retrouver à exécuter un contrat qui laisse peu de place à l’adaptation.

À cela s’ajoute un déséquilibre de compétences. Quand l’État ne dispose pas en interne d’assez d’architectes, de chefs de produit, de spécialistes sécurité ou de développeurs seniors, il devient dépendant de l’expertise externe pour juger ce qu’il achète. Cette dépendance ne signifie pas que les prestataires sont coupables par nature, mais elle réduit la capacité du client public à challenger les choix techniques, à négocier des compromis réalistes, à refuser des options coûteuses. La conséquence est souvent une inflation de coûts et un verrouillage technologique.

Le duo met aussi en avant un biais de gouvernance, la recherche de couverture. Dans une organisation publique, prendre une décision risquée peut exposer. Empiler les validations, les comités et les prestataires peut au contraire donner l’impression d’une prudence institutionnelle. Le prix à payer est une lenteur qui s’accorde mal avec l’IT moderne, où la sécurité et la qualité passent par des mises à jour fréquentes, des tests automatisés et une correction continue des failles.

Pourquoi la souveraineté numérique devient un slogan plus qu’un plan industriel

Dans l’échange, Lilith Wittmann et David Zellhöfer disent leur malaise face au hype autour de la souveraineté. Le concept recouvre des enjeux réels, dépendance aux fournisseurs extra-européens, exposition juridique, maîtrise des données, résilience des infrastructures. Mais ils critiquent un usage politique qui transforme parfois un objectif complexe en mot-valise. Dans ce cadre, annoncer une solution souveraine peut devenir plus important que prouver sa robustesse, sa maintenabilité et sa capacité à passer à l’échelle.

Le risque, selon leur analyse, est double. D’abord, la souveraineté peut servir d’argument d’autorité pour justifier des choix techniques discutables ou des dépenses mal calibrées. Ensuite, elle peut masquer les priorités qui font la différence, la qualité du produit, la sécurité opérationnelle, la documentation, la capacité à recruter et à retenir des talents. Un État peut héberger localement et rester fragile si son code est obsolète, si ses dépendances ne sont pas mises à jour, ou si son organisation ne sait pas gérer l’incident.

Ils pointent aussi une confusion fréquente entre souveraineté et autarcie. Construire maison n’est pas automatiquement synonyme de contrôle. Sans stratégie de maintenance sur dix ans, sans communauté, sans audits, sans capacité de correction rapide, une solution interne peut devenir un fardeau. À l’inverse, l’usage de composants ouverts, bien gouvernés, peut offrir une forme de souveraineté pragmatique, parce que le code est inspectable, forkable, et moins soumis à un fournisseur unique.

Cette critique vise moins l’idée de souveraineté que sa mise en scène. Le débat public se focalise volontiers sur le lieu d’hébergement ou la nationalité du fournisseur, alors que des critères plus concrets pèsent, la réversibilité contractuelle, l’export des données, la portabilité des applications, la gestion des identités, la traçabilité des accès. Pour les deux invités, l’État gagnerait à définir des exigences mesurables plutôt qu’à multiplier les labels.

Des pistes concrètes, équipes produit, itération et contrôle interne renforcé

Le propos de c’t uplink ne se limite pas au constat. Lilith Wittmann et David Zellhöfer insistent sur des leviers actionnables, centrés sur la façon de piloter et de construire. Première piste, passer d’une logique projet à une logique produit. Un service public numérique n’est pas un livrable ponctuel, c’est un organisme vivant qui doit évoluer. Cela suppose des équipes stables, responsables sur la durée, avec un budget de fonctionnement et pas seulement un budget de construction.

Deuxième piste, renforcer la compétence interne du client public. Sans une masse critique de profils capables d’architecturer, de relire un code, de mener un audit sécurité, de concevoir une expérience utilisateur, l’État reste en position de faiblesse. Les deux intervenants plaident pour un contrôle interne plus fort, pas sous forme de bureaucratie supplémentaire, mais comme capacité à décider. Dans plusieurs pays européens, des unités numériques centrales ont été créées pour mutualiser des expertises rares et imposer des standards d’API, d’accessibilité et de sécurité.

Troisième piste, contractualiser l’itération plutôt que la perfection initiale. Il s’agit de financer des versions successives, avec des objectifs d’usage et des métriques, taux de réussite d’une démarche, temps moyen de traitement, diminution des appels au support. La transparence est un autre levier. Publier des tableaux de bord, documenter les incidents, ouvrir le code quand c’est possible, permet de corriger plus vite et d’éviter la répétition d’erreurs. Sur ce point, le mouvement open source dans le secteur public, présent dans plusieurs administrations européennes, offre un cadre concret.

Enfin, ils reviennent sur un principe simple, la sobriété fonctionnelle. Beaucoup d’échecs naissent d’ambitions trop larges, lancées d’un seul bloc. Réduire le périmètre, livrer une fonctionnalité critique, tester en conditions réelles, puis étendre, coûte souvent moins cher que viser un système total. Cette approche ne supprime pas les contraintes réglementaires ou politiques, mais elle change la trajectoire du risque. L’informatique publique ne se redresse pas par des slogans, mais par une accumulation de pratiques de livraison et de contrôle qui, elles, se mesurent.

Selon le fil conducteur de leur échange, la question n’est pas seulement de moderniser l’État, mais de choisir ce que l’État accepte de maîtriser, de financer et d’assumer dans la durée, compétences, cycles de mise à jour, sécurité, et gouvernance. Sans cette discipline, la prochaine grande promesse, qu’elle s’appelle plateforme unique ou souveraineté, risque de se heurter aux mêmes mécanismes que les précédentes.