Pourquoi les grands projets informatiques du gouvernement échouent-ils toujours ?

En Suisse, les personnes bénéficiant de l'aide sociale à Zurich reçoivent chaque mois un budget : un montant pour le loyer, un autre pour les besoins de la vie quotidienne. Avec le nouveau logiciel des services sociaux, ce budget n'a pas pu être reproduit de façon compréhensible jusqu'en février 2026, comme le note l'ombudsman de la ville dans un rapport. L'argent indûment perçu par quelqu'un a pu être récupéré par la ville en 2025. Le système ne prévoyait aucune récupération.

Les exigences pour ce logiciel ont été recueillies par des experts de Berne, Bâle et Zurich en 2013 lors d'ateliers. En janvier 2018, l'association commune des trois villes a attribué le mandat. Berne a changé en 2023, Zurich en janvier 2025, Bâle devrait le faire début 2027. Plus de onze ans se sont écoulés entre le premier atelier et le premier cas zurichois. L'ombudsman conclut dans son rapport annuel une conclusion succincte : le lancement doit être « malheureusement considéré comme un échec à Zurich ».

Le 20 octobre 2026, le gouvernement fédéral a lancé un appel d'offres pour un cloud d'une valeur maximale de 7 milliards de francs public. Les contrats s'étendent sur 14 ans au total.

Un logiciel d'aide sociale et un cloud ont peu de points communs. Leur problème reste le même. L'État échoue avec le logiciel non pas malgré sa prudence, mais à cause de celui‑ci. Il le conçoit comme un tunnel, le confie en une seule fois et le finance comme un projet à terme. Or, le logiciel n'a pas de fin.

Pas de pannes, mais un modèle

Citysoftnet, le logiciel zurichois, n'est pas un cas isolé. La liste des grands projets informatiques qui ont dérapé est suffisamment longue pour tenir dans un tableau :

Les projets proviennent de différents ministères et décennies, mais ils se ressemblent. Au départ, il s'agit d'un système global destiné à remplacer de nombreux anciens systèmes en une fois. Les exigences sont définies des années avant que le premier utilisateur ne voie le système. La migration se fait à une date butoir, quand l'ancien système est déconnecté. Les rôles clés sont occupés par des externes qui quittent le projet après coup. Dans le cas d'INSIEME, le rapport parlementaire indique que les postes étaient « majoritairement occupés par des experts externes ».

Ce n'est pas une question de malchance. Le Contrôle financier fédéral a évalué en 2026 ses examens des grands projets informatiques sur deux ans, 24 rapports couvrant un volume de 3 à 5 Mrd de francs. Leur constat : les déficits majeurs identifiés déjà en 2016 persistent. Un chapitre du rapport s'intitule « L'organisation n'apprend pas systématiquement ».

Le secrétariat du gouvernement fédéral répond dans sa prise de position. Sur les quelque 200 projets clôturés chaque année, la grande majorité réussit. Je le crois, et cela renforce l'argument plutôt que de le contredire. Les petits projets fonctionnent. Ce sont les gros qui échouent.

Un tunnel est achevé, le logiciel jamais

La Suisse peut construire un tunnel ferroviaire de 57 km à travers le Gothard. La procédure est bien rodée : planifier, estimer les coûts, lancer l'appel d'offres, construire, réceptionner. Dans le domaine logiciel, on appelle cela le modèle en cascade, car chaque phase s'écoule vers la suivante sans retour en arrière. Cela convient à un tunnel. Il doit relier deux portes, et rien ne change pendant les 17 ans de construction.

Pour les logiciels, c’est l’inverse. Au départ, on sait le moins. Ce dont un travailleur social a réellement besoin ne devient évident qu’une fois qu’il utilise le système. Et la technologie évolue plus vite que le processus d’appel d'offres. Qui aurait commandé en 2012 un cloud pour 14 ans n’aurait pas pu imaginer des outils comme Kubernetes ou les grands modèles d'IA. Aujourd'hui, ils sont monnaie courante.

La taille même constitue le risque, comme le montrent les chiffres. Une étude de McKinsey et de l'Université d'Oxford portant sur plus de 5 400 projets informatiques a conclu que les gros projets de plus de 15 Mio de dollars dépassent en moyenne leur budget de 45 % et offrent 56 % de bénéfices en moins que prévu. Ainsi, les gros commanditaires obtiennent en moyenne moins de la moitié des bénéfices pour presque une fois et demie plus d'argent. Chaque année supplémentaire augmente le dépassement de 15 %. Bent Flyvbjerg et Alexander Budzier ont trouvé, parmi 1 471 projets informatiques, qu'un sixième coût en moyenne trois fois plus que prévu.

Au cours des 25 dernières années, j'ai co‑fondé plusieurs entreprises dont le cœur était le logiciel, notamment un commerce en ligne et un gestionnaire d'actifs numérique. Aucun n'a été développé à partir d'un cahier des charges. Nous avons commencé petit, testé chaque étape immédiatement auprès de vrais clients et n'avons développé que ce qui fonctionnait. Il n'y avait pas de budgets de projet. Il y avait des équipes dédiées en permanence à un domaine, chacune avec une personne qui décide de la prochaine fonctionnalité, le Product Owner. Nous étions rapides, mais chaque étape était si petite qu'une erreur coûtait peu. C’est la vraie différence. Ce n’est pas une question de vitesse contre prudence, mais de nombreux petits risques plutôt qu’un grand.

Le système récompense le gros paquet

Tout d'abord : je ne prétends pas que les mauvaises personnes occupent les postes. Ce serait une accusation facile et fausse. Qui lit les règles selon lesquelles l'État commande des logiciels voit autre chose. Le grand projet est là le choix raisonnable.

Tout commence avec l'argent. Un projet informatique fédéral nécessite un crédit d'engagement. Le Finanzhaushaltgesetz le décrit comme « montant maximal » jusqu'auquel le Conseil fédéral peut prendre des engagements « pour un but précis ». Il est calculé « sur la base de calculs soigneux établis selon des règles professionnelles ». Qui veut de l'argent doit donc définir dès le départ ce qu'il construit et combien cela coûte. Exactement au moment où il sait le moins. Quand on apprend en cours de route, on a besoin d'un crédit supplémentaire, et cela est publiquement reconnu comme une admission d'erreur. Dans les villes ce n'est pas différent : Berne a dû demander depuis 2023 mehrere Nachkredite pour Citysoftnet.

Ensuite, l'appel d'offres est lancé, comme un contrat à un fournisseur. Pour Citysoftnet, le droit des marchés de l'époque interdisait tout dialogue avec les fournisseurs. Les offres et les prix reposaient donc « partiellement sur de fausses hypothèses », a déclaré le Berner Gemeinderat plus tard. Une fois le prix attribué, chaque changement devient coûteux. La Beschaffungsgesetz permet alors même d'attribuer des marchés subséquents sans appel d'offres au même fournisseur, si un changement entraînait des « coûts substantiels ». Le Bundesrat a expliqué en 2025 pourquoi il a prolongé les contrats cloud existants de gré à gré : un changement de fournisseur pour la période de transition « entraînerait des risques d'interruption et de sécurité importants ainsi que des coûts excessifs ». Voilà à quoi ressemble un verrouillage, une dépendance dont il n'est plus facile de sortir.

Et chaque projet a une fin. La méthode de projet du gouvernement, HERMES, connaît depuis 2022 aussi les projets agiles. Mais même ceux-ci sont clôturés. Le contrôle financier résume la contradiction en une phrase qui pourrait être affichée dans chaque administration : « Les projets se développent de plus en plus de façon orientée produit et itérative, tandis que la gouvernance reste basée sur les projets. » Le logiciel est donc construit comme un produit et géré comme un tunnel.

C'est pourquoi il aide peu que les équipes travaillent de façon agile, c'est‑à‑dire en cycles courts avec des retours continus. Chez Citysoftnet, le fournisseur a travaillé selon un Gutachten pour le parlement municipal de Berne de façon agile, les projets suivaient eux-mêmes HERMES. Dans le domaine des télécommunications de l'armée, un projet d'environ 1,9 milliards de francs, un sous‑projet a été décidé en 2025, après l'attribution, d'adopter une approche agile. Cela doit maintenant être reflété rétroactivement « dans les structures contractuelles », et selon le Finanzkontrolle cela a engendré « d'autres retards ». J'appelle cela une cascade avec des sprints : des équipes agiles dans un cadre qui fixe tout dès le départ.

Reste la question de qui possède le savoir. Le contrôle financier spricht indique un « pourcentage déjà aujourd'hui élevé de personnel externe dans les projets informatiques ». L'approvisionnement externe est « relativement coûteux » et augmente « le risque de perte de connaissances ». Qui ne construit pas lui‑même ne peut que commander. Et qui commande doit tout écrire à l'avance.

Le cloud suit le même plan de construction

Un cloud n'est pas un système de gestion de cas. C'est une infrastructure : centres de données, stockage, réseau. On achète ce type de chose, on ne l'invente pas. Et le nouvel appel d'offres est mieux conçu que INSIEME. Le gouvernement vergibt trois lots à cinq fournisseurs différents, ne paie que ce qu'il utilise, et rouvre le marché après sept ans. Les 7 milliards de francs constituent un plafond et non une dépense, répartis sur 14 ans jusqu'à 500 millions de francs par an. La différence entre le plafond et la consommation peut être illustrée par les contrats cloud existants : sur un plafond de coûts de 110 millions de francs, le gouvernement avait récupéré jusqu'en septembre 2025 rund 61 Mio. abgerufen.

Pourtant le cloud se construit selon l'ancien plan. La stratégie cloud du gouvernement date de décembre 2020. Les premières prestations doivent être obtenues à l'automne 2027, à moins que des plaintes n'interviennent. Il faut donc sept ans entre la stratégie et le premier appel. Les contrats-cadres courent jusqu'en 2034, certains contrats jusqu'en 2041.

Personne ne sait aujourd'hui si cela vaut la peine. Le Botschaft des Bundesrats a indiqué en 2024 qu'il n'existait « qu'un cadre budgétaire, pas d'analyse coût‑bénéfice ». Le Finanzkontrolle a écrit en 2025 que le bénéfice économique n'était « pas encore démontré ». L'utilisation n'est pas obligatoire, et les administrations ne se sont « jusqu'à présent pas engagées ». Le risque de nouveaux retards et de plaintes lors de l'approvisionnement est jugé élevé dans le même rapport. Ici encore, on ne verra que lors de l'ouverture si le tunnel vaut la peine.

Ce qui m'occupe le plus, c'est autre chose. Le parlement a beschlossen de privilégier, dans le cloud, « si possible » les solutions open source et les entreprises basées en Suisse. L' Ausschreibung n'autorise cependant aucun consortium, donc aucune association de plusieurs entreprises, et chaque fournisseur ne peut concourir que pour un lot. Un fournisseur suisse, trop petit pour le faire seul, ne peut pas s'associer avec d'autres. En tant que sous‑fournisseur d'un grand, il peut participer, mais pas en tant que partenaire à égalité. Qui veut soutenir les fournisseurs suisses devrait leur permettre de se regrouper. L'appel d'offres fait exactement le contraire.

J'écris cela en tant qu'entrepreneur qui bénéficie d'un fort pôle technologique suisse. Il faut le savoir lorsqu'on examine l'argument. En pluriel, j'ai présenté le problème comme une problématique dans une idée d'initiative pour un département technologique fédéral, à laquelle je reviendrai à la fin :

Je ne dis pas que le cloud échouera. Je dis qu'il sera construit selon le même plan que les projets qui ont échoué : grand, long, et le bénéfice ne se voit qu'à la fin.

Petit, autonome, durable

Le meilleur contre‑exemple vient de la même administration fiscale qui a dû abandonner INSIEME. Le projet successeur FISCAL‑IT a également rencontré des difficultés en 2016, une grande version a dû être annulée à cause d’erreurs critiques. Ensuite l’administration a changé d’approche : des équipes agiles avec le Bureau fédéral de l’informatique, à la fin de chaque cycle de développement de 14 jours, une démonstration du logiciel. En 2020, la Finanzkontrolle, qui ont «prouvé» le développement agile et les équipes communes. L’administration fiscale veut désormais «éviter autant que possible» les solutions globales de ses systèmes.

Le même bureau a reçu en mai 2021 le mandat pour le Covid-Zertifikat. Trois semaines plus tard, les premières personnes en Suisse tenaient un certificat en main. Le code source est ouvert, l’Autriche a construit son application dessus. Ça fonctionne donc, même dans la même administration.

D’autres pays ont tiré des leçons de leurs échecs. Le Royaume‑Uni beschloss 2014, ne plus conclure de contrat informatique de plus de 100 Mio de livres, sauf raison exceptionnelle. Il n’y a plus de renouvellements automatiques, les contrats d’hébergement durent au maximum deux ans. En France, de petites équipes d’État développent leurs propres services numériques. Le Rechnungshof comptait plus de 450 produits ainsi testés ou développés. Dans un échantillon, l’un coûtait en moyenne 290 000 € par an pour le développement et le design. C’est une fraction de ce qu’un grand projet coûte par an.

Cela conduit à une proposition en quatre parties. Premièrement, l’État finance des produits plutôt que des projets : des équipes permanentes pour un domaine, comme l’aide sociale ou les impôts, avec un budget annuel. Le Parlement les évalue selon ce que les citoyens et l’administration utilisent réellement, pas selon un livrable. Deuxièmement, une limite supérieure de taille et de durée des contrats informatiques, à l’image du Royaume‑Uni. Troisièmement, l’État construit le noyau avec ses propres développeurs et fait appel à des externes pour les pics. Selon Finanzkontrolle, le gouvernement peut payer des salaires conformes au secteur, sauf pour les fonctions très spécialisées. Quatrièmement, le code est ouvert, comme le Gesetz exige depuis 2024 pour les logiciels que le gouvernement développe ou fait développer, de toute façon.

Le quatrième point dépasse la technique. Lorsque l’État dépense des milliards en informatique, il influence quelles entreprises existeront dans dix ans. S’il achète de gros lots aux plus grands fournisseurs mondiaux, il finance leur croissance. S’il achète en petits lots, autorise les regroupements et rend son code ouvert, des entreprises suisses capables de ce travail émergent et pourront ensuite le vendre à d’autres clients. Cela crée des emplois et des recettes fiscales. Les grandes entreprises technologiques naissent souvent avec le soutien à long terme de l’État. Le fabricant de puces TSMC a été créé en 1987 commeGemeinschaftsunternehmen fondée par le gouvernement taïwanais, le groupe électronique Philips et des investisseurs privés. Aujourd’hui, il se décrit comme le principal fabricant sous contrat de puces informatiques au monde. Qui n’investit pas dans les fondations ne doit pas s’étonner en cas de manque.

Dans la même idée d’initiative, j’ai également présenté une proposition de solution qui va dans ce sens :

L’agilité n’est‑elle pas seulement une étiquette ?

On pourrait s’arrêter ici. Ce n’est pas si simple, et les objections les plus fortes viennent de la Finanzkontrolle elle‑même. Elle ne peut pas déduire de ses audits que les projets agiles respectent mieux le budget et les délais que les classiques. Et elle avertit que les méthodes agiles seraient «considérées comme prometteuses en soi» dans de nombreux projets.

Il existe des exemples. Le nouveau système de gestion des dossiers du canton de Berne devait être créé délibérément comme une petite première version, développé avec les premières communes et déployé en exploitation. Il est encore en crise malgré tout. Le crédit de 52 Mio de francs, selon le responsable du service, «ne sera probablement pas suffisant», et il déclare : «Avec le recul, le lancement a été trop tôt». Le programme douanier DaziT fonctionne de façon agile, le Finanzkontrolle a salué en 2022 sa gestion, et pourtant la transition des importations a été retardée de environ un an.

À cela s’ajoute une objection fondamentale que je prends au sérieux. Elle se formule approximativement ainsi : l’agilité signifie que l’on ne sait pas ce que cela coûtera, pas quand cela sera terminé. Un parlement a toutefois le droit de connaître les deux avant d’approuver. Des règles fixes protègent également contre les abus. Pour INSIEME, les exigences ont été définies progressivement à partir de 2009 selon le Conseil fédéral, au lieu d’être fixées dès le départ. Pendant ces années, l’administration fiscale a attribué chaque année des dizaines de marchés juste en dessous du seuil sans appel d’offres. Et quiconque réclame une politique industrielle doit se demander si l’État peut choisir les gagnants. Pour chaque TSMC il existe des entreprises subventionnées par l’État dont personne ne parle plus. Une préférence pour les fournisseurs nationaux est déjà interdite par le droit suisse et international des marchés publics, comme le Bundesrat le rappelle.

Sur un point, la partie adverse a raison : l’étiquette n’aide pas. Un système pour 85 organisations avec un crédit de 52 Mio de francs reste un grand projet, même s’il débute avec une petite première version. L’essentiel n’est pas la méthode sur le papier, mais la taille de chaque étape, la rapidité avec laquelle de vrais utilisateurs la voient et si le savoir reste en interne.

Cet argument recèle un vrai dilemme et un autre qui ne fait que paraître. Le vrai conflit est entre la transparence des coûts à l’avance et l’apprentissage en cours. Personne ne peut maximiser les deux simultanément. Il semble y avoir un contraste entre contrôle et petites étapes. Un parlement qui voit chaque année ce qu’une équipe a livré en sait plus qu’un parlement qui accorde un crédit de sept ans et ne reçoit qu’un décompte à la fin. Qui veut contrôler les coûts devrait exiger de petites tranches, pas des engagements de 14 ans.

Même INSIEME ne s’oppose pas aux petites étapes. Les marchés libres étaient un grand projet découpé en petits contrats pour contourner l’appel d’offres. Et l’État n’a pas à choisir le gagnant. Il doit être un bon client : acheter en petits lots, autoriser les regroupements, exiger du code ouvert. Cela ne favorise personne selon son origine, mais les fournisseurs qui livrent un bon travail par petites étapes. Le fait que cela implique de nombreuses entreprises suisses est une conséquence, pas une condition.

Le contrôle financier indique également que l'argument selon lequel les lois empêchent la collaboration dont les méthodes agiles ont besoin se révèle souvent comme une excuse. Je le lis comme une bonne nouvelle. Si le droit autorise déjà le dialogue avec les fournisseurs, la concurrence de qualité et les contrats-cadres, le problème réside dans la pratique et les incitations. Les deux peuvent être modifiés plus rapidement qu'une loi.

Je ne sais pas si l'État trouve les personnes. En 2023, ses services informatiques n'ont pas pu pourvoir un quart des postes annoncés. Le contrôle financier estime que le développement des compétences et des structures pour le travail agile prendra trois à quatre ans. Ce n'est pas une raison d'attendre. C'est la raison de commencer maintenant et pas seulement après le prochain engagement de 14 ans.

Bon pour les tunnels, mauvais pour les logiciels

Pour le Gothard, la procédure était correcte. On savait où le tunnel commence et où il se termine. Pour les logiciels, on ne le sait jamais, et c'est pourquoi le contrôle financier arrive, après dix ans, à la même conclusion. L'État n'a pas besoin d'apprendre à gérer de gros projets informatiques. Il doit cesser d'en lancer.

Sur Plural, l'association CH++ a proposé une initiative qui s'adresse à l'État : un département dédié qui regroupe l'informatique, les données, la cybersécurité et l'IA. J'y ai ajouté moi-même quelques aspects, dont les deux mentionnés ci-dessus.

Ma position à ce sujet : Un nouveau département n'est qu'une réorganisation, et les réorganisations comportent le même risque que les grands projets. Cela ne vaut la peine que si cela change la façon dont l'État conçoit et paie les logiciels, et pas seulement s'il regroupe des responsabilités. On peut débattre avec de bons arguments pour savoir si un département est le levier approprié ou s'il suffit de réformer le budget et les achats.

Vous connaissez maintenant les deux côtés. Quel est votre avis ?

Oliver Herren est cofondateur de Plural, Digitec Galaxus et True Wealth. Il écrit ici son opinion personnelle, pas celle de Plural.