Le sovereign compute ne s’achète pas. Il se pilote avec un modèle opérationnel.

Il existe un type d’échec très particulier, qui ne se voit qu’après l’inauguration.

Le système existe. Les factures sont payées. Les dashboards sont au vert. Et puis… rien. Ou pire : quelques enthousiastes s’en servent, pendant que tous les autres contournent la plateforme, parce qu’elle est plus lente, plus difficile, plus risquée, ou tout simplement déconnectée des objectifs de chacun.

C’est la leçon, peu confortable, du cas danois : un supercalculateur public a été qualifié de projet à haut risque, avec des alertes sur la dérive des coûts et la dépendance à des conseillers externes ; puis un bilan a montré que plus de 90 % de la capacité de calcul est restée inutilisée.

Le réflexe, c’est d’en faire une histoire de technologie : mauvais fournisseur, mauvais dimensionnement, mauvaise architecture, pas assez de formation, pas assez de « stratégie IA ».

Ce n’est pas une histoire de technologie. C’est une histoire de modèle opérationnel. Le sovereign compute échoue lorsqu’on le traite comme un acte d’achat, plutôt que comme un produit avec des clients, des contraintes, et une trajectoire d’adoption mesurable.

L’erreur de fond : d’abord la capacité, ensuite la demande

Le compute devient une utility seulement quand vous avez structuré la demande autour. Avant cela, ce n’est qu’une option coûteuse : vous payez pour garder des possibles ouverts.

Cela peut se défendre, mais uniquement si vous considérez l’« usage » comme le premier livrable, pas comme un effet secondaire. Sinon, la plateforme devient un musée : impressionnante, inerte, défendue politiquement, et orpheline sur le plan opérationnel.

Quand les équipes ne migrent pas leur travail vers un nouvel environnement de compute, ce n’est généralement pas une question d’idéologie. Elles répondent à des incitations. Elles choisissent ce qui préserve leur flux de delivery :

• L’accès rapide prime sur une souveraineté parfaite. Si obtenir un environnement prend des semaines, les équipes prendront une autre voie.
• La friction bat la politique. Si l’identité, l’accès aux données et les outils ne collent pas au quotidien, la plateforme reste théorique.
• L’optimisation locale l’emporte. Si chaque direction supporte la douleur mais qu’une autre récupère le bénéfice, l’adoption cale.

Le bon correctif n’est pas « plus de communication ». C’est une structuration de la demande, avec des engagements fermes.

Donnez-lui un responsable capable de dire « non » et « stop »

Les programmes de sovereign compute meurent souvent d’une responsabilité diluée. Tout le monde est consulté. Personne n’est comptable du résultat.

Il vous faut une personne responsable des outcomes, en couvrant trois plans en même temps :

• Santé de la plateforme (disponibilité, performance, posture de sécurité, coût par type de workload).
• Adoption (délai d’onboarding, nombre de projets actifs, réutilisation, migration des workloads).
• Adéquation du portefeuille (quels workloads ont leur place ici, lesquels non, et ce qu’on refuse).

Cette personne doit avoir la main sur la priorisation et l’intake. Sinon, la plateforme devient une liste de souhaits, faite de demandes incompatibles, chacune justifiée comme « stratégique ».

J’ai vu une plateforme cloud, au sein d’une organisation produit multi-pays, devenir réellement utile seulement lorsque l’équipe qui l’opérait a eu le droit de refuser des workloads qui l’auraient déformée durablement. Le déclic n’a pas été un meilleur stack. C’était une gouvernance qui protégeait l’intention de la plateforme.

Définissez des KPI d’usage qui obligent à avoir la vraie discussion

L’« utilisation » est un indicateur grossier. On peut faire monter l’utilisation avec de mauvais workloads et échouer malgré tout. Vous voulez des KPI qui révèlent si la plateforme devient le chemin par défaut, pour le bon travail.

Voici sept métriques qui font souvent apparaître la réalité très vite :

• Time to first job : temps médian entre la demande et le premier run réussi.
• Monthly active projects : pas des utilisateurs, des projets qui livrent des outputs.
• Repeat rate : part des projets qui relancent un run le mois suivant.
• Workload mix : pourcentage d’expérimentations R&D vs pipelines en production vs batch analytics.
• Data gravity fit : pourcentage de workloads exécutés là où les données résident déjà (ou peuvent résider légalement).
• Cost per outcome proxy : coût par modèle entraîné, par cohorte traitée, par cycle de reporting, par run de simulation. Choisissez des proxys alignés sur la mission.
• Abandonment reasons : motifs tagués, revus chaque mois, et rattachés à un responsable de correction.

La plupart des organisations ne formalisent jamais les raisons d’abandon. C’est pourtant là que le modèle opérationnel cache ses échecs : contraintes achats, friction d’accès, frontières de support floues, bibliothèques manquantes, responsabilité compliance non clarifiée, réponse aux incidents trop lente.

Le chargeback ne parle pas d’argent. Il parle de sérieux.

Si le compute est « gratuit », la demande devient performative. On réserve de la capacité parce qu’on le peut. Vous obtenez des files d’attente, du bruit et des batailles politiques — pas de la valeur.

Si le compute est mal tarifé, vous obtenez l’effet inverse : les directions protègent leur budget en évitant la plateforme, même lorsqu’elle serait moins chère au total.

L’objectif du chargeback, c’est de créer une décision claire à la marge. Quelques patterns pragmatiques fonctionnent mieux que le théâtre habituel des prix de cession internes :

• Commencer par le showback pendant 1 à 2 trimestres : visibilité des coûts réels par projet et par direction, sans facturation.
• Passer à un chargeback simple avec deux tarifs : un pour la capacité réservée, un pour le burst. Gardez-le lisible.
• Budgéter un fonds de migration centralisé : les équipes demandent des crédits limités dans le temps pour financer le refactoring et les premiers runs.
• Tarifer la douleur, pas l’élégance : facturer davantage les workloads qui exigent du support sur mesure, des dépendances fragiles, ou des exceptions de sécurité non standard.

Dès qu’une équipe ressent le coût d’un « cas particulier », soit elle standardise, soit elle sait expliquer pourquoi elle ne le peut pas. Dans les deux cas, c’est plus sain que l’entropie silencieuse.

La pièce manquante que la plupart des achats ignorent : les portes de sortie

L’article de Version2 mentionne un risque de dépendance à des conseillers externes et une alerte sur la dérive des coûts. C’est exactement le type de risque qui devient irréversible si les contrats n’intègrent pas de portes de sortie.

Une porte de sortie n’est pas une menace. C’est un principe de design : vous partez du principe que certains choix seront mauvais, et vous construisez à l’avance la capacité à corriger, sans réécriture, sans négociations d’otage.

Pour le sovereign compute, ces portes de sortie doivent être explicites à cinq endroits :

1. Portabilité des données : formats, propriété, et chemins d’export automatisés pour les datasets, les métadonnées et la traçabilité (lineage).
2. Portabilité des workloads : standards de containers, baselines d’infrastructure-as-code, et templates CI capables de cibler un autre environnement.
3. Identité et accès : éviter les constructions IAM spécifiques à un provider, impossibles à mapper ailleurs.
4. Plafonds de dépendance au support : services de conseil limités dans le temps, avec obligations de transfert de connaissances et critères de passation mesurables.
5. Clauses commerciales de sortie : options pré-négociées pour réduire le périmètre ou arrêter certains composants si les KPI d’adoption ne sont pas au rendez-vous.

Sans cela, une impasse pilotée par un fournisseur devient l’option par défaut. La plateforme continue d’exister parce qu’on vous amène à croire que changer de direction coûterait plus cher que le gaspillage.

Si vous voulez approfondir l’angle achats, la même logique est développée dans Denmark’s AI Problem Isn’t Models. It’s Procurement Without Exit Ramps.

Un modèle opérationnel praticable pour le sovereign compute, en une page

Si vous reconstruisez ce trimestre, je commencerais par une charte d’une page, qui force la clarté :

• Mission : quels résultats ce compute doit permettre — et lesquels il ne doit pas viser.
• Liste de clients : directions et programmes nommés, avec des workloads engagés.
• Intake : un parcours de demande simple, avec un SLA de décision et des critères de refus.
• Golden paths : deux ou trois patterns de workloads supportés, entièrement documentés.
• KPI : time to first job, projets actifs, repeat rate, workload mix, et raisons d’abandon.
• Économie : showback maintenant, chargeback ensuite, plus un fonds de migration limité dans le temps.
• Portes de sortie : standards de portabilité et break clauses indexées sur les métriques d’adoption.

Puis vous la pilotez comme un produit : décisions d’intake chaque semaine, revue KPI mensuelle, triage du portefeuille chaque trimestre. Focus sans concession sur les golden paths. C’est ainsi que vous évitez de construire une plateforme superbe que personne ne choisit.

C’est aussi pour cela que les débats sur le « sovereign cloud » passent souvent à côté du sujet. La question n’est pas seulement où tournent les workloads. C’est : savez-vous les exécuter de façon fiable, les déplacer quand il le faut, et justifier le coût ? J’ai traité ce cadrage plus large du portefeuille dans Sovereign Cloud Is Portfolio Triage, Not a Vendor Swap.

Mon point de vue : le sovereign compute se mérite, il ne se décrète pas

Le vocabulaire politique de la souveraineté peut être utile : il crée de l’urgence et débloque des budgets. Mais il peut aussi masquer une réalité plus simple : une plateforme ne compte que si elle est utilisée.

Le cas danois, où plus de 90 % de la capacité est restée à l’arrêt, n’est pas un scandale parce que l’utilisation était faible. C’est un signal d’alerte : des achats sans modèle opérationnel transforment des investissements de bonne foi en récits de coûts irrécupérables.

Si vous voulez que le sovereign compute fonctionne, arrêtez de le traiter comme un monument national. Traitez-le comme un service : des clients, des signaux de prix, et une sortie quand une partie du design est mauvaise. C’est ce qui évite que la souveraineté devienne un alibi au gaspillage.