La fonction ne s’exporte pas

Vendredi, une équipe de développement a reçu une nouvelle qui ne concernait aucun de ses systèmes. Le 28 août, OpenAI a annoncé qu’elle cessera de fournir ses modèles à Cursor, en invoquant la clause de changement de contrôle déclenchée par l’acquisition par SpaceX : accès direct fermé le 12 novembre, le préavis maximal que le contrat permet. À compter d’aujourd’hui, soixante-quinze jours.

Aucune attaque. Aucune panne. Aucune donnée perdue, aucune API violée. Cursor continue d’exister, les dépôts restent où ils sont, les autres modèles restent dans le menu. Il est simplement arrivé qu’une fonction utilisée chaque jour par des milliers d’équipes va disparaître de leur environnement à cause d’une décision contractuelle prise entre deux tiers.

Imaginons maintenant le CTO de cette équipe qui ouvre son inventaire des dépendances. « GPT » n’apparaît presque nulle part. Pas dans le lock file. Pas dans le SBOM. Pas dans les diagrammes d’architecture. Et pourtant une part substantielle du processus de développement a été calibrée pendant des mois sur le comportement de ce modèle : la taille des spécifications, la profondeur des reviews, le nombre d’itérations prévues, jusqu’aux estimations données aux clients. Techniquement, l’équipe n’a rien perdu. Organisationnellement, elle doit encore découvrir combien elle a perdu.

L’entreprise qui avait tout fait correctement

J’ai écrit il y a quelques jours que le verrouillage ne sera plus dans les données : entre les documents et les décisions se forme un troisième objet, l’état que le système accumule en travaillant pour toi, et le coût de la sortie risque d’être l’amnésie. La réponse était une discipline architecturale précise : ce qui compte pour le comportement de l’agent devrait vivre, autant que possible, hors de l’agent.

Cette fois, je veux concéder que cette architecture fonctionne. Imaginons une organisation qui a tout fait correctement. Les spécifications sont dans le dépôt. Les décisions architecturales sont versionnées. Les procédures importantes sont devenues des skills explicites. Les outils passent par des protocoles ouverts. Le contexte de projet ne vit pas dans la mémoire privée du provider, les evals sont indépendantes du modèle, les données s’exportent, la mémoire pertinente se reconstruit. Le système a été conçu précisément pour pouvoir remplacer Claude par GPT, GPT par Gemini, Gemini par un modèle open-weight.

Puis, un lundi matin, le modèle est remplacé. Tout continue techniquement de fonctionner. Pas de migration, pas d’incompatibilité, pas de mémoire oubliée.

Et pourtant le processus se dégrade. L’agent modifie plus de fichiers que nécessaire. Il lit les spécifications avec moins de discipline. Il lui faut trois itérations là où une suffisait. Il ne reconnaît plus avec la même fiabilité qu’une demande est ambiguë. Ses reviews sont techniquement correctes mais moins utiles. Il est peut-être plus rapide, peut-être moins cher, et il produit davantage de travail à absorber. Ou c’est l’inverse : le nouveau modèle est globalement meilleur, domine les benchmarks publics, et il est pire précisément dans la combinaison de comportements sur laquelle l’organisation avait, sans le savoir, construit sa manière de travailler.

L’entreprise n’a pas perdu ses données. Elle n’a pas perdu sa mémoire. Elle n’a pas perdu ses outils. Elle a perdu une fonction cognitive.

La thèse, dite avec précision : dans l’IA, le lock-in peut consister non dans l’impossibilité technique de changer de fournisseur, mais dans la dépendance organisationnelle à une distribution particulière de capacités, d’erreurs, de comportements et de coûts de supervision qu’aucune API standard ne garantit de pouvoir remplacer. Dans l’essai précédent, le coût de la sortie était l’amnésie. Ici, c’est plus insidieux : on peut perdre de la compétence opérationnelle sans perdre un seul octet.

L’objection : ce n’est pas du lock-in, c’est de la qualité

Avant d’aller plus loin, il faut concéder presque tout à l’objection la plus forte. Si je remplace PostgreSQL par une base moins performante et que l’application ralentit, je n’ai pas découvert une nouvelle forme de vendor lock-in : j’ai choisi un produit pire. Si je remplace un ingénieur excellent par un médiocre, le processus se dégrade, et personne ne dirait que j’étais « locked in » sur le premier. Si Claude exécute une tâche mieux que Gemini, l’écart de qualité ne constitue pas une dépendance pathologique. Cette objection doit rester debout : le mot lock-in n’a de valeur que s’il décrit quelque chose de plus précis que la banale constatation que les produits diffèrent.

Le problème apparaît quand les caractéristiques du produit cessent d’être des performances et deviennent des hypothèses incorporées dans l’organisation. Il y a une différence entre dire « ce modèle écrit mieux le code » et dire : notre processus de review, la taille de nos spécifications, la granularité des tâches, le nombre de contrôles humains et jusqu’au prix auquel nous vendons notre travail présupposent que ce modèle maintienne une fiabilité déterminée. Dans le second cas, la capacité du modèle est devenue de l’infrastructure. Le remplacement reste techniquement possible, mais il exige une reconception organisationnelle.

Et c’est exactement la signature du vrai lock-in : le coût de sortie ne coïncide pas avec le coût de transfert des actifs. Il coïncide avec le coût de reconstruction, ailleurs, des conditions dont le système dépendait.

Le modèle fait partie du processus

Le SaaS classique rendait au moins la dépendance nommable : base de données, fichiers, configurations, API, workflows. Le problème était de les faire ressortir sous une forme utilisable, et c’est le problème que le Data Act attaque avec le switching, les données exportables et l’équivalence fonctionnelle. L’essai précédent avait déjà fait émerger quelque chose de plus fuyant : l’état de l’agent n’est pas une archive mais une transformation de l’archive, et deux systèmes avec les mêmes données peuvent se comporter différemment parce qu’ils ont consolidé différemment l’expérience.

L’étape suivante est plus radicale. Même deux agents avec les mêmes données, la même mémoire, les mêmes outils, les mêmes instructions et la même spécification restent des systèmes fonctionnellement différents. Parce que le modèle n’est pas un interprète neutre du processus : il fait partie du processus. Il décide implicitement comment distribuer l’attention, combien explorer avant de s’engager, combien vérifier, quand demander une clarification au lieu de continuer, combien faire confiance au contexte, à quel point suivre un requirement à la lettre ou le généraliser, comment réagir à un test qui échoue, avec quelle facilité abandonner sa propre hypothèse, quand s’arrêter.

Aucune de ces propriétés n’est déclarée dans le contrat d’API. Aucune ne vit dans notre dépôt. Aucune ne s’exporte. Et surtout, aucune n’a nécessairement d’équivalent direct chez le modèle concurrent. Un workflow agentique est la composition d’un processus explicite et du comportement implicite du modèle : la première partie peut être rendue portable avec la discipline de l’essai précédent. La seconde, non.

La fausse promesse de l’API compatible

Dans l’informatique traditionnelle, l’interface compatible a un pouvoir énorme. Si deux bases parlent SQL assez bien, une grande partie de la dépendance disparaît. Si deux object storage implémentent la même API, le coût du changement s’effondre. Si deux runtimes acceptent le même artefact OCI, l’interopérabilité est réelle. Avec les modèles de langage, nous risquons de confondre compatibilité syntaxique et équivalence comportementale.

Deux providers peuvent accepter les mêmes messages, les mêmes outils, le même schéma JSON, et renvoyer le même format. L’application tourne du premier coup. Mais le vrai contrat n’a jamais été l’endpoint. C’était une propriété non écrite qui se lit ainsi : quand tu reçois une spécification de ce type, avec ce dépôt, ces outils et ces evals, tu atteins un résultat acceptable avec cette distribution d’erreurs et ce coût humain de supervision. Aucun protocole ne standardise cette propriété. Un adapter compatible peut rendre trivial le changement d’endpoint et laisser intact quatre-vingt-dix pour cent du coût réel de la migration.

La portabilité des API, à elle seule, est une forme cosmétique de souveraineté.

Une configuration dynamique d’un SaaS

Le cas Cursor est utile parce qu’il rend concret un risque qui reste d’habitude abstrait, mais ce serait une erreur de bâtir tout le raisonnement dessus : c’est une anomalie, avec Musk dedans, une acquisition à 60 milliards et une rivalité personnelle. La forme ordinaire du problème est bien plus banale, et elle a une date : après-demain.

Le 1er septembre, GitHub retire six modèles de Copilot, dont des versions de Claude Sonnet, Claude Opus et Gemini, sur toutes les surfaces du produit, en indiquant les successeurs comme alternatives. Du point de vue du fournisseur, c’est du lifecycle management normal, et il n’y a rien à reprocher. Du point de vue de l’organisation, cela veut dire quelque chose de précis : un comportement qui faisait hier partie du workflow n’est plus disponible demain. Et avec la global model policy, les nouveaux modèles peuvent devenir disponibles par défaut si l’administrateur n’a pas choisi une politique plus restrictive : la fonction cognitive accessible à une équipe est, littéralement, une configuration dynamique d’un SaaS.

Dans le logiciel traditionnel, une mise à jour modifie le code qui exécute certaines règles. Dans l’IA, un changement de modèle modifie la fonction qui interprète les règles elles-mêmes. Le machine learning classique nous a habitués au drift : les données changent, la distribution se déplace, les performances se dégradent. Ici se produit autre chose, que j’appellerais avec prudence cognitive dependency drift : ton application ne change pas, tes données ne changent pas, la spécification ne change pas, et le comportement du système change quand même, parce que le composant cognitif sous-jacent a changé. Nouvelle version, nouveau fine-tuning, nouvelles safety policies, nouveau routing, nouveau provider. Le dépôt reste parfaitement immobile pendant que la dépendance change de nature sous une interface apparemment stable.

Et la chaîne est plus stratifiée que le SaaS : organisation, outil, courtier de modèles, provider du modèle. Chaque maillon peut se rompre indépendamment des autres. Pour Cursor, il n’a pas fallu que GPT soit retiré du monde : il a suffi qu’il disparaisse de l’intersection spécifique entre outil, contrat et organisation sur laquelle quelqu’un avait construit son processus.

La dépendance que le graphe n’enregistre pas

Un lock file montre que je dépends d’une bibliothèque. Un SBOM montre une version. Un digest identifie un artefact. Avec les modèles managés, la dépendance la plus importante est sémantiquement plus riche et totalement invisible pour ces instruments. Je ne dépends pas de « gpt-x » : je dépends du fait que cette version comprenne bien les spécifications longues, ne réécrive pas les tests pour faire passer le code, reconnaisse les ambiguïtés, utilise certains outils avec parcimonie, fasse des reviews avec une certaine sévérité, demande en moyenne un certain nombre d’itérations.

Le dependency management pourrait devoir évoluer en conséquence. Pas seulement : quelle version utilisons-nous ? Mais : quelles propriétés opérationnelles du processus déléguons-nous implicitement à cette version ? Après le SBOM, et avec toute la prudence due aux noms nouveaux, il faudrait une sorte de Cognitive Bill of Materials : non pas la liste des intelligences présentes, mais un inventaire des fonctions cognitives dont le processus dépend. Interprétation des requirements, génération, raisonnement de sécurité, review, planification des outils, classification, détection des exceptions. Et pour chacune : quel modèle l’exécute, quelle fiabilité nous exigeons, quelles evals le démontrent, quelle alternative nous avons, quelle perte nous acceptons pendant un switch.

Aujourd’hui nous inventorions les composants parce qu’un composant peut disparaître ou devenir vulnérable. Les capacités déléguées peuvent disparaître exactement de la même façon. Simplement, elles ne figurent dans aucun inventaire.

Les evals comme instrument de souveraineté

Dans l’essai précédent, le test de sortie était : si je remplace le provider demain, combien de capacité organisationnelle est-ce que je perds ? Il faut le mettre à jour, parce que cette question mesurait ce que tu emportes. La nouvelle question est : qu’est-ce qui continue de fonctionner après ton départ ? Ce sont des questions différentes. Tu peux tout exporter et te retrouver quand même avec un processus inutilisable.

Le vrai test de sortie d’un système agentique est donc comportemental. Une batterie de tâches représentatives du travail réel : même spécification, mêmes outils, même mémoire, mêmes données, modèle alternatif. On observe ce qui survit. De combien chute le task success, de combien augmente le rework humain, quelles catégories de tâches cessent de fonctionner, quels nouveaux failure modes apparaissent, comment le coût change, combien de temps il faut pour revenir au niveau précédent. Ce sont des métriques de switching bien plus honnêtes que « l’API est compatible ».

Ici, les evals changent de métier. Nous les construisons d’habitude pour répondre à « quel modèle est meilleur ? ». Mais elles répondent à une question politiquement plus intéressante : à quel point dépendons-nous de ce modèle ? Si je possède cent tâches représentatives et que je peux les exécuter contre plusieurs modèles, je possède une mesure de la substituabilité. Si je ne les possède pas, la dépendance est invisible : je sais que le système fonctionne aujourd’hui, mais je ne sais pas quelle part de ce fonctionnement appartient à mon architecture, à mon contexte, à mes spécifications, et quelle part appartient, accidentellement, au comportement du modèle actuel. L’évaluation devient une preuve de portabilité cognitive, l’équivalent d’un test de disaster recovery : avoir la sauvegarde ne suffit pas, il faut répéter la restauration. Avoir un second modèle dans le menu déroulant ne suffit pas, il faut répéter la continuité de la fonction.

Il y a aussi un moyen simple de rendre opérationnel le vrai contrat, celui que l’API n’écrit jamais. Nous avons des SLO pour la disponibilité, la latence, le taux d’erreur ; un workflow IA peut avoir leur équivalent cognitif : acceptation des tâches au-dessus d’un seuil, hallucinations critiques sous un seuil, rework humain médian sous tant de minutes, coût par tâche sous tant, latence sous tant. Le terme n’a pas besoin de devenir un standard. Ce qui compte, c’est le déplacement d’objet : le contrat réel avec le modèle n’est pas son nom, ce sont les performances minimales qui permettent au processus d’exister. Si deux modèles respectent ces SLO, ils sont fonctionnellement substituables pour ce processus, aussi différents soient-ils à l’intérieur. C’est cela, la vraie abstraction. Pas l’API : le seuil.

On arrive alors à la phrase vers laquelle tout converge : le modèle devrait être un détail d’implémentation de la capability de l’entreprise, pas l’identité de la capability. Non pas « nous avons un processus Claude », mais « nous avons un processus de code review qui utilise aujourd’hui Claude parce qu’il satisfait mieux nos SLO ». La différence semble linguistique. C’est de la gouvernance.

La vraie redondance et la fausse

Pour les bases de données critiques, nous construisons de la redondance sans discuter : primaire, réplique, failover. Pourquoi trouvons-nous normal d’avoir exactement une seule fonction cognitive critique ? Un processus mûr pourrait avoir un modèle primaire, un secondaire déjà validé sur les mêmes evals, un routage par catégorie de tâches, un fallback explicitement dégradé. Non pour servir du trafic en parallèle : pour éviter de découvrir le plan B le jour de l’incident.

Mais ici aussi, l’objection mérite le respect : le multi-modèle peut être une fausse sécurité. Dire « nous supportons OpenAI, Anthropic et Google » ne veut pas dire être indépendant. Si tout le processus a été écrit et calibré sur le modèle A, les providers B et C sont des adapters que personne n’utilise : des sauvegardes jamais testées. Ou pire : trois modèles peuvent dépendre du même hyperscaler, du même framework, du même control plane, et la redondance doit s’évaluer le long de toute la chaîne. Trois entrées dans le sélecteur de modèles ne font pas une architecture résiliente.

Et il y a une dépendance encore plus quotidienne, qui n’apparaît dans aucune discussion sur le lock-in : les prompts. Des prompts énormes, hyper-optimisés pour un seul modèle. Des instructions système qui exploitent des comportements idiosyncrasiques. Des hacks empiriques transmis comme du folklore : « avec Claude, ça marche seulement si tu le lui dis comme ça ». Cette connaissance produit un avantage local réel, et c’est du capital spécifique au vendor. Dans le SaaS, c’était le fournisseur qui construisait la partie propriétaire qui te rendait dépendant ; dans l’IA, le client construit lui-même une partie de son propre verrouillage, un prompt à la fois. Des milliers de workarounds, des parsers réglés sur un format de sortie, des descriptions d’outils calibrées sur un modèle : une couche de compatibilité que personne n’a demandée et qui augmente le prix de la sortie. Cela ne veut pas dire renoncer à optimiser. Cela veut dire distinguer la connaissance du domaine, à préserver, de la connaissance du comportement contingent du modèle, à traiter comme de la dette. De la dette cognitive spécifique au vendor.

La discipline qui en découle porte un nom que j’utilise depuis un moment : des spécifications, pas des prompts. Une spécification décrit ce qui doit être vrai indépendamment de l’exécutant. Un prompt, trop souvent, décrit comment convaincre un exécutant particulier de le faire. Plus le processus repose sur des requirements, des critères d’acceptation, des invariants, des tests, des policies et des évidences, moins il dépend du comportement implicite du modèle ; plus il repose sur des astuces, un ton, des few-shots spécifiques et des stratégies émergentes, plus la fonction vit chez le provider. Le développement guidé par les spécifications n’est pas seulement un moyen de faire mieux travailler les coding agents : c’est une stratégie de sortie.

L’erreur symétrique, pourtant, est l’autre réflexe de l’ingénieur : construire le gigantesque abstraction layer interne qui masque toute différence entre modèles. C’est souvent le meilleur moyen de déplacer le verrouillage du vendor vers son propre framework : une couche qui court après chaque feature, aplatit les meilleures capacités sur le plus petit dénominateur commun, doit être maintenue pour toujours et devient elle-même une plateforme. La stratégie sensée est plus minimale et ressemble au progressive enhancement du web : un noyau portable fait de spécifications, de contrats d’outils, d’evals et de fallbacks, et au-dessus une couche d’accélération vendor-specific qui exploite sans honte les meilleures capacités du provider, caching, reasoning avancé, protocoles particuliers. Si le provider disparaît, tu perds l’accélération, pas le système. L’architecture n’a pas à rendre les modèles indistinguables. Elle doit rendre mesurable ce qui se passe quand ils cessent de l’être.

Le prix, la latence, la continuité

La fonction peut devenir indisponible sans être retirée. Elle peut simplement sortir de l’économie du processus. Si je vends une tâche traitée un euro et que le workflow repose sur un modèle qui coûte quinze centimes par tâche, un tarif triplé ne casse aucune API : il casse le compte d’exploitation. Même chose pour la latence : un agent en contact client construit autour de neuf cents millisecondes meurt avec un remplaçant à six secondes, même si la capability abstraite est équivalente. La portabilité de la fonction est une courbe multidimensionnelle, qualité, coût, latence, fiabilité, supervision humaine requise, pas un chiffre unique. C’est le même argument que j’ai fait sur les métriques de productivité : la substituabilité ne se certifie pas avec un benchmark public, elle se mesure sur son propre travail.

Il en découle une conséquence que le procurement n’a pas encore absorbée. Dans les vendor assessments, OpenAI et Anthropic figurent encore comme « outils IA ». Mais si une part significative du delivery dépend de leur disponibilité et de leurs performances, la bonne catégorie est fournisseur critique, avec tout ce qui suit : contrat, SLA, plan de sortie, monitoring, analyse des sous-traitants, continuité d’activité. Sinon on aboutit à la contradiction d’entreprises qui font des évaluations sophistiquées du cloud qui conserve leurs données et aucune évaluation de la société qui fournit la fonction à travers laquelle ces données sont interprétées.

Continuité d’activité : c’est le mot qui manque. Les entreprises construisent des plans de continuité pour les datacenters, les bases de données, la connectivité, les personnes clés, les fournisseurs stratégiques. Si une fonction de l’entreprise est progressivement déléguée à un modèle, elle doit entrer dans le même raisonnement. Quels processus s’arrêtent si le modèle n’est pas disponible, pendant combien de temps, avec quel fallback, avec quelle performance dégradée acceptable. Et avec quelle compétence humaine résiduelle : parce que si un modèle exécute une fonction pendant cinq ans, l’organisation peut perdre la capacité humaine de l’exécuter, non parce qu’elle licencie, mais parce que plus personne ne l’exerce. Le lock-in cognitif rencontre le deskilling, et le provider devient techniquement remplaçable au moment précis où l’organisation découvre qu’elle n’a plus de référence humaine vers laquelle revenir.

Il y a même un paradoxe du succès. Si l’agent fonctionne mal, nous le surveillons, gardons les procédures manuelles, connaissons les alternatives. S’il fonctionne parfaitement pendant des années, nous automatisons, éliminons les doublons, réduisons les compétences redondantes, intégrons en profondeur. Plus il fonctionne, plus la sortie coûtera. Ce n’est pas une raison pour ne pas automatiser : c’est la raison de traiter la réversibilité comme un coût opérationnel, exactement comme la sauvegarde. Un second adapter maintenu, des evals à jour, une pipeline alternative, des compétences internes cultivées : tout cela ressemble à du gaspillage jusqu’au jour où cela sert. La liberté de sortir est une option, et les options ont une prime. Le choix adulte n’est pas de la payer partout : c’est de décider quelles fonctions méritent de la payer. Pour certaines, tu acceptes une forte dépendance parce que l’avantage est énorme ; pour les workflows commodity, tu exiges une haute substituabilité. Une classification honnête, portable, portable avec dégradation, dépendant du provider, irremplaçable aujourd’hui, vaut plus que n’importe quelle case « vendor-neutral : oui ».

Parce que la question n’est pas d’avoir un single point of failure. C’est de ne pas savoir qu’on en a un.

Le critère reste à nous

Le parcours de ces deux essais traverse quatre objets. La donnée, qui s’exporte. L’état, qui peut s’externaliser avec de la discipline. La fonction, qui ne se remplace que s’il existe une alternative suffisamment équivalente. Et enfin le critère : parce que pour savoir si l’alternative est suffisamment équivalente, il faut quelque chose que l’organisation doit nécessairement posséder en propre, la définition opérationnelle de ce que signifie que cette fonction a été bien exécutée.

C’est ici que l’affaire cesse d’être technique. Si le provider possède le modèle, la mémoire, le benchmark et la définition du bon résultat, tu es client d’un service que tu ne peux juger qu’à travers ce que le service lui-même te raconte. Si tu possèdes la spécification, les evals, les rubriques, les frontières d’échec et les évidences, tu peux interroger plusieurs modèles et décider lequel satisfait ta fonction. Le pouvoir se déplace : qui possède la définition opérationnelle de « suffisamment bon » possède la possibilité de remplacer qui exécute le travail. J’ai soutenu que le fossé compétitif n’est pas la donnée mais le jugement ; en voici le corollaire défensif. Le même corpus d’evals qui rend meilleure ton IA verticale est aussi ce qui te permet d’en changer.

C’est ce que nous faisons avec les personnes, du reste. Il existe des organisations où un employé est formellement remplaçable et pratiquement pas : non parce qu’il prend les documents en otage, mais parce que personne n’a jamais formalisé ce qui rendait sa prestation bonne. Quand il part, l’entreprise découvre qu’elle n’a jamais défini le travail qu’elle lui avait délégué. Avec les modèles, la même chose peut se produire à l’échelle industrielle : un agent qui « fonctionne très bien », sans que personne sache dire exactement pourquoi, quelles erreurs il ne commet pas, par rapport à quelle comparaison. Le jour où il disparaît, on découvre que le vrai verrouillage n’était pas chez le provider. Il était dans notre incapacité à décrire le travail que nous lui avions confié.

C’est pourquoi je ne transformerais jamais cet argument en attaque contre les vendors. Un provider a parfaitement le droit de faire un meilleur modèle, de changer ses tarifs, de retirer des versions selon le contrat. Le lock-in cognitif est largement auto-induit : plus nous déléguons sans expliciter objectifs, critères, frontières et évidences, plus ce qui rend le processus efficace vit dans le comportement privé de l’exécutant. Et la contre-mesure réglementaire, si elle vient un jour, ne pourra pas obliger le nouveau provider à penser comme l’ancien : ce serait absurde. Elle pourra en revanche faire ce que le Data Act a fait pour les données et ce que le DMA fait pour les marchés, préserver la contestabilité : transparence sur les versions, périodes de dépréciation décentes, export du contexte, interopérabilité des artefacts d’évaluation. Ne pas standardiser l’intelligence. Standardiser les conditions qui permettent au client de vérifier si une autre intelligence est assez équivalente pour son usage. C’est une distinction très européenne, et elle me semble la bonne.

Il nous a fallu vingt ans pour comprendre que le cloud n’était pas portable simplement parce qu’on pouvait exporter une base de données. Puis nous avons découvert qu’emporter les documents ne suffit pas, si l’on laisse derrière soi ce que le système a appris de ces documents. Vient maintenant la marche suivante : on peut tout emporter, spécifications, mémoire, instructions, outils, evals, chaque artefact en notre possession, et découvrir quand même que le processus avait appris à fonctionner autour d’une propriété jamais formalisée : la manière particulière dont un certain modèle transformait ces artefacts en jugement et en action.

La souveraineté, dans ce domaine, ne consiste pas à refuser les dépendances. Elle consiste à en connaître le prix : savoir quelle part de la fonction est à nous et laquelle nous louons, savoir ce qui se passe si la location s’arrête, et maintenir l’alternative exerçable, pas théorique. Une option réelle, avec ses evals exécutées dans les quatre-vingt-dix derniers jours, pas une entrée dans un menu. Dans l’IA, la clause de sortie la plus importante pourrait ne pas être écrite dans le contrat : ce pourrait être un test. Un ensemble de tâches qui permet de dire : voici le travail que nous avions délégué, voici ce que nous considérons comme correct, voici les autres systèmes capables, aujourd’hui, de le faire. À ce moment-là, un modèle peut être exceptionnel sans devenir irremplaçable.

Et peut-être que la définition la plus mûre de la souveraineté cognitive ne sera pas de posséder un modèle, d’en entraîner un européen ou de le faire tourner dans son propre datacenter. Ce sera quelque chose de bien moins spectaculaire : posséder assez bien la définition de son propre travail pour pouvoir changer qui l’exécute. Parce qu’un modèle ne devient pas du lock-in quand il est techniquement difficile à remplacer. Il devient du lock-in quand l’organisation ne sait plus décrire la fonction qui devrait survivre à son remplacement.

L'auteur

Andrea MargiovanniIA

Je suis le rapport entre IA et régulation européenne comme un fait politique, pas comme un spectacle technique. Je travaille avec des équipes qui doivent la rendre compatible avec AI Act, CRA, NIS2 sans réduire la conformité à une liste à cocher.

Voir le parcours →