Le problème de l’IA au Danemark n’est pas une affaire de modèles. C’est une commande publique sans porte de sortie.

Il existe un type d’échec très particulier, qu’on ne voit que dans des sociétés matures et bien gérées. Celui où tout le monde est compétent, où les dossiers sont impeccables… et où le programme s’effondre malgré tout sous son propre poids.

Le Danemark connaît bien ce scénario. Nous excellons dans les comités, l’équité et l’art de s’assurer que personne ne brûle les étapes. Puis nous nous étonnons que des programmes technologiques finissent en verrouillage progressif, puis en dépréciation publique, puis en : « nous continuons sur l’ancien système, pour l’instant ».

Lorsque les universités du pays ont abandonné un projet IT de plus de 300 millions de DKK et sont revenues à un système hérité des années 1990, les détails comptaient moins que la mécanique. Ce n’est pas un problème d’université. C’est un problème de gouvernance et d’achats, qui se répétera à chaque « transformation IA » que nous lancerons, tant que nous ne changerons pas notre manière d’acheter, de jalonner, d’intégrer et d’arrêter.

L’IA aggrave le phénomène parce qu’elle pousse les dirigeants à acheter un « programme » : une plateforme, une stack fournisseur, une roadmap pluriannuelle, et la promesse que la valeur apparaîtra plus tard. C’est exactement l’inverse. La valeur de l’IA est presque toujours locale au départ. Elle ne s’accumule qu’une fois les handoffs maîtrisés, les data contracts explicites, et l’intégration traitée comme le produit.

Le tueur silencieux : des achats optimisés pour l’équité, pas pour l’aptitude

La plupart des processus d’achats sont conçus pour répondre à une question : « Avons-nous choisi équitablement ? » Ils ne sont pas conçus pour répondre à : « Est-ce que ça va être livré, intégré, et tenir au contact du réel ? »

L’équité compte. La répétabilité aussi. Mais, dans le digital complexe, l’optimisation de la conformité procédurale produit trois effets prévisibles :

• On achète un périmètre plutôt que des résultats. Le contrat décrit des fonctionnalités, des modules, des livrables, pas un comportement mesurable dans un workflow en production.
• On externalise l’incertitude. On fait comme si le fournisseur pouvait chiffrer l’inconnu, puis on le sanctionne quand il le découvre ; cela alimente les avenants et une livraison défensive.
• On supprime le bouton stop. Une fois le programme validé, l’arrêter devient un acte politique. Il dérive donc jusqu’à ce que l’argent soit déjà dépensé.

Voilà pourquoi la « transformation IA » se transforme si souvent en théâtre. L’organisation devient experte en decks, pilotes et comités de pilotage. Pendant ce temps, les contraintes réelles se nichent dans l’intégration, les frontières de sécurité, la qualité des données et le travail peu glamour qui consiste à changer la manière dont les gens font réellement leur métier.

Si vous cherchez l’angle spécifiquement danois, le voici : nos institutions sont suffisamment solides pour continuer à financer un programme qui échoue pendant des années, parce qu’aucune personne n’est autorisée à être pleinement responsable de l’arrêter. La responsabilité est distribuée. Le risque est mutualisé. Le coût négatif l’est aussi — et, au final, il n’appartient à personne.

Les stage gates ne sont pas de la bureaucratie. Ce sont un mécanisme d’honnêteté.

Toute transformation sérieuse a besoin de stage gates. Pas le rituel où l’on re-présente les mêmes slides de statut. De vrais jalons qui obligent une décision binaire : continuer, mettre en pause, ou arrêter.

Voici un ensemble qui fonctionne pour l’IA (intelligence artificielle) et pour de grands chantiers IT, sans se transformer en méga-programme.

Gate 0 : prouver le workflow

Avant d’acheter quoi que ce soit de significatif, décrivez le workflow en langage simple. Qui fait quoi, avec quels systèmes, sous quelles contraintes. Puis choisissez une tranche suffisamment petite pour être livrée en semaines, pas en trimestres.

• Exit criteria : un workflow, un owner, un résultat mesurable, une frontière de sécurité.
• Kill criteria : si le « use case » exige l’accord de cinq départements avant même de pouvoir le tester, ce n’est pas un premier use case. C’est un programme déguisé en pilote.

Gate 1 : un prototype « integration-first »

La plupart des pilotes IA meurent au moment où ils rencontrent la stack réelle. Faites donc de l’intégration la première preuve, pas la dernière.

• Exit criteria : le prototype lit depuis la source réelle, réécrit dans le system of record réel, et journalise chaque décision.
• Kill criteria : si l’accès aux données et aux API nécessite des mois d’exceptions, l’organisation n’est pas prête pour l’IA. Corrigez d’abord le modèle d’accès.

Gate 2 : ownership des décisions et contrôles

Si un système d’IA produit une recommandation, qui est responsable de l’appliquer. S’il agit, qui est responsable du résultat. Cela doit être nommé, pas sous-entendu.

• Exit criteria : un owner identifié à chaque point de décision, un circuit d’escalade, et un plan de rollback.
• Kill criteria : « c’est le métier qui possède » n’est pas de l’ownership. C’est une manière de garantir un jeu de blâme plus tard.

Gate 3 : ne scaler que ce qui tient en conditions d’exploitation

Scaler, ce n’est pas ajouter des utilisateurs. C’est ajouter des modes de panne. On scale après avoir prouvé le monitoring, le contrôle des coûts et la gestion des incidents.

• Exit criteria : attentes de disponibilité, alerting, plafonds de coûts, et modèle de support.
• Kill criteria : si les coûts augmentent avec l’usage mais que personne ne sait expliquer l’économie unitaire, n’étendez pas. Mesurez d’abord.

C’est la différence entre livrer une capacité et financer un espoir.

Les kill criteria doivent être contractuels, pas émotionnels

La phrase la plus difficile, dans les grandes organisations, est : « Nous arrêtons. » Non pas parce que les dirigeants sont irrationnels, mais parce qu’arrêter est traité comme un échec.

En technologie, arrêter relève souvent de la compétence.

Vous voulez donc des kill criteria conçus dès le départ, et rattachés à des signaux objectifs. Ainsi, arrêter n’est pas un drame. C’est le plan.

• Basés sur le temps : si l’intégration du Gate 1 n’est pas atteinte à une date fixe, on arrête ou on re-scope.
• Basés sur la valeur : si le résultat du workflow ne s’améliore pas d’une marge définie sur un groupe pilote défini, on arrête ou on redessine.
• Basés sur le risque : si les exceptions de sécurité s’accumulent au-delà d’un seuil, on stoppe jusqu’à correction de l’architecture.
• Basés sur la complexité : si le nombre de systèmes dépendants dépasse ce que l’équipe peut maîtriser, on découpe ou on arrête.

Les achats peuvent rendre cela possible, mais seulement si les contrats rémunèrent les résultats et l’apprentissage, pas le volume de livrables. Payez le passage des gates. Payez les améliorations mesurables. Payez la documentation qui rend le système maintenable. Ne payez pas des slides et des « frameworks ».

Une architecture « integration-first » bat une ambition « platform-first »

L’erreur la plus coûteuse, dans une transformation IA, consiste à commencer par choisir la plateforme. Vous obtenez une couche brillante, incapable de toucher en sécurité aux systèmes qui comptent.

Une architecture « integration-first » commence ailleurs :

• Définissez le system of record pour chaque entité clé. Client, actif, facture, dossier, identité. Sans ambiguïté.
• Construisez des interfaces stables. API, événements ou contrats de fichiers, versionnés et testés.
• Faites de l’observability une exigence. Logs, traces et métriques ne sont pas optionnels pour l’IA. C’est ainsi que vous auditez les décisions.
• Gardez la partie « clever » petite. Les modèles changent. Les workflows et les intégrations durent.

C’est aussi pour cela qu’un « programme IA » ne doit pas être un méga-programme unique. Il doit plutôt ressembler à un portefeuille de petits paris, avec une plomberie partagée. Une approche d’intégration. Un modèle d’identité. Un standard d’audit. Et de nombreux use cases fins.

J’ai vu une bascule ERP dévorer du temps et de la confiance parce que l’intégration était traitée comme un détail d’implémentation. Ce n’en est jamais un. C’est le produit avec lequel votre organisation va vivre.

Si vous voulez une lecture plus approfondie sur la manière dont les choix de gouvernance provoquent des dérives de coûts, voir Budget overruns are rarely a surprise. They are a governance choice.

Réinitialiser les achats : quatre actions à mener ce trimestre

Voici la partie opérationnelle. Cela fonctionne dans une institution publique, une entreprise pilotée par son fondateur, ou un acteur régulé. La mécanique est la même.

1. Désignez un owner responsable par workflow. Pas un comité. Une personne. Son rôle : arbitrer et savoir dire stop si le gate échoue.
2. Réécrivez le RFP autour des gates. Les fournisseurs répondent d’abord sur le passage du Gate 0 et du Gate 1, avec des exit criteria explicites. Les Gate 2 et 3 deviennent des options, pas des présupposés.
3. Contractez l’intégration et les preuves. Exigez des connecteurs opérationnels vers les systems of record, des tests automatisés des interfaces, et des audit logs. Traitez-les comme des livrables assortis de tests d’acceptation.
4. Rendez la décision d’arrêt peu coûteuse. Plafonnez l’exposition par gate. Assurez-vous que l’IP et la documentation restent exploitables si vous mettez fin au contrat. Évitez les contrats qui vous pénalisent d’avoir appris.

C’est aussi là que l’IA appelle un autre réflexe de leadership. La question n’est pas « quel modèle » ou « quel fournisseur ». La question est : quel workflow, quel handoff, quel contrôle, quel changement mesurable.

Si vous développez des outils agentic, cela rejoint directement l’idée que la discipline de release compte davantage que les feature flags. J’en ai parlé dans Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle. Le même principe s’applique aux achats. Des dépenses « default-on » sans gates, c’est la meilleure façon de se coincer dans une impasse dont on ne peut plus sortir.

Mon avis : le Danemark n’a pas besoin de programmes IA plus gros. Il a besoin de meilleurs boutons stop.

L’abandon du projet des universités est un signal d’alarme, pas un scandale à commenter. Quand un système à plus de 300 millions de DKK est abandonné et qu’une plateforme des années 1990 reste en place, le coût ne se limite pas à l’argent. C’est de l’élan perdu. Cela apprend aux équipes que moderniser est dangereux ; elles se protègent donc en exigeant davantage de processus, ce qui rend la tentative suivante encore plus lente.

L’IA amplifiera cette boucle, sauf si nous traitons les achats comme une discipline produit : stage gates, kill criteria, ownership clair, et architecture qui commence par l’intégration. De petits paris. De vraies interfaces. Des résultats mesurables. Et l’arrêt précoce lorsque le réel contredit l’hypothèse.

C’est ainsi que vous obtenez une transformation, sans la gueule de bois du méga-programme.