La souveraineté de l'IA se prouve le jour où l'accès disparaît

Une IA est souveraine si l'on peut continuer sans son fournisseur. Pour le vérifier, il faut simuler la coupure d'accès avant qu'elle n'arrive.

La souveraineté de l’IA se prouve le jour où l’accès disparaît

Une IA est souveraine lorsqu’on peut continuer sans son fournisseur. Quand un accès est suspendu, un modèle retiré ou un outil abandonné, l’organisation doit pouvoir poursuivre le service, récupérer ses actifs et reprendre la main.

Ce vendredi 9 octobre, Reuters rapporte que le développeur de l’agent ARTEX passe son projet en source fermée, sans nouvelles versions ni maintenance, après que des entreprises de cybersécurité l’ont associé à une campagne visant des banques sud-coréennes ; ces attributions restent celles de tiers. Indépendamment de ces accusations, cet abandon pose une question immédiate aux organisations qui auraient intégré l’outil : qui corrigera les failles, assurera les mises à jour et accompagnera la sortie ?

Le vrai test arrive rarement à la signature du contrat. Il arrive un vendredi soir : l’API ne répond plus, un connecteur est désactivé, le fournisseur change ses conditions. Que se passe-t-il le lundi matin ? Les équipes assurent-elles encore la fonction attendue, ou la décision d’un tiers bloque-t-elle une activité essentielle ?

Avec l’IA agentique, la dépendance ne se limite plus au modèle. Elle porte aussi sur les identités techniques qui ouvrent les accès, les connecteurs et l’orchestrateur. Elle touche les formats de données, les journaux, les mises à jour et le support. L’agent agit dans une chaîne de services dont plusieurs maillons appartiennent à des fournisseurs différents. Remplacer le modèle ne suffit donc pas toujours à rétablir le service.

Être souverain ne signifie pas se passer de prestataires. Cela signifie ne pas leur abandonner, sans recours praticable, la décision de poursuivre une activité. Il faut distinguer la souveraineté juridique de la souveraineté opérationnelle. Héberger les données sur un territoire donné relève de la première et répond à une exigence réelle. Cela ne garantit ni la disponibilité d’une API, ni la portabilité d’un état de travail, ni la maintenance d’un connecteur : c’est le domaine de la seconde.

La gestion des identités est un point faible connu. Selon le CISO AI Leverage Report de l’Open Future Forum (octobre 2026), 37 % des 49 répondants concernés par les méthodes d’accès déclarent utiliser des comptes de service partagés, contre 14 % une identité déléguée ou un accès médié. L’échantillon n’est pas représentatif, mais il illustre une pratique dont les risques sont bien connus : un compte partagé rend l’attribution d’une action plus difficile et la révocation plus périlleuse pour les autres traitements.

Une clause de réversibilité ne suffit donc pas ; il faut éprouver la sortie. Pour chaque service reposant sur l’IA, le DSI devrait pouvoir répondre à quatre questions :

1. Quelle fonction métier doit continuer si le modèle est indisponible ?

2. Quels identifiants et droits l’agent utilise-t-il, et qui peut les révoquer directement ?

3. Quelles données, configurations et traces peut-on récupérer dans des formats réutilisables ?

4. Quelle procédure permet de basculer vers un autre outil ou un mode manuel, avec quel délai et quelle perte de capacité ?

Le test doit aussi couvrir ce qui survit au remplacement : historique des décisions, état des dossiers, règles configurées, résultats intermédiaires. Changer de modèle ne garantit pas que la mémoire de l’agent soit récupérable dans un format exploitable. Cette part invisible peut transformer une sortie contractuelle en migration longue et coûteuse.

Ces réponses se vérifient par un exercice. On désactive un connecteur, on simule l’indisponibilité du modèle, on révoque un jeton, puis on demande à l’équipe métier de poursuivre la tâche par une procédure de secours. L’exercice révèle les dépendances oubliées : une identité détenue par le fournisseur, une mémoire non exportable, une validation humaine devenue théorique, une opération aval impossible à annuler. Il fournit aussi des mesures simples : temps de reprise, volume d’activité dégradée, données récupérables, décisions à reconstituer.

Le contrat doit ensuite pérenniser cette capacité : préavis en cas d’évolution ou d’arrêt, durée de support, accès aux journaux, formats d’export, conditions de restitution, assistance à la transition. L’architecture doit limiter les comptes partagés, isoler les droits de chaque agent et éviter qu’un changement de modèle impose de reconstruire toute la chaîne. Aucune clause ne compensera une dépendance technique que personne n’a cartographiée.

La question décisive n’est pas seulement "quel modèle utilisons-nous ?", mais "que pouvons-nous encore faire demain si nous ne pouvons plus l’utiliser ?". Une organisation peut parler de souveraineté lorsqu’elle a déjà éprouvé sa réponse.

Jacky Galicher est consultant indépendant en gouvernance du numérique et en souveraineté numérique. Ancien DSI de l’académie de Normandie et ancien DSI-RSSI de l’académie de Versailles, il accompagne les organisations sur la maîtrise de leurs dépendances numériques.