Le test décisif de la souveraineté numérique n’arrive pas au moment de signer un contrat. Il survient quand l’accès cesse, quand une API ne répond plus ou quand un outil n’est plus maintenu. À cette aune, la souveraineté de l’IA ne se résume ni à l’hébergement ni au droit applicable : elle se mesure à la capacité concrète d’une organisation à continuer son activité sans son fournisseur.

Le vendredi 9 octobre, un rappel brutal sur la fragilité des dépendances IA

Le point de départ est très précis. Vendredi 9 octobre, Reuters a rapporté que le développeur de l’agent ARTEX faisait passer 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.

Au-delà des circonstances propres à ce dossier, l’épisode soulève une question immédiate pour toute organisation ayant intégré un outil de ce type dans ses processus. Si un projet est abandonné, qui prend le relais sur les correctifs de sécurité, les mises à jour et l’accompagnement à la sortie ? Une dépendance logicielle devient alors une question d’exploitation, de continuité d’activité et, à terme, de responsabilité interne.

Ce que l’abandon d’un outil change réellement

La difficulté ne tient pas seulement à la disparition d’une fonctionnalité. Elle touche aussi la sécurité des composants déjà déployés, la capacité à auditer les usages passés, la reprise des configurations et le maintien du niveau de service attendu par les métiers.

La souveraineté de l’IA ne se limite pas à l’emplacement des données

Dans le débat français sur la souveraineté numérique, l’attention se porte souvent sur la localisation des données ou le cadre juridique applicable. Cette dimension reste importante. Elle ne couvre pourtant qu’une partie du problème.

Le texte met utilement en regard la souveraineté juridique et la souveraineté opérationnelle. La première répond à des exigences de droit, de conformité et de maîtrise des flux. La seconde pose une question plus rude : l’organisation peut-elle poursuivre une fonction essentielle si un prestataire suspend un accès, retire un modèle ou modifie unilatéralement ses conditions d’utilisation ?

Autrement dit, héberger sur un territoire donné ne garantit ni la disponibilité d’une API, ni l’export d’un état de travail, ni la continuité d’un connecteur. Pour une direction générale, une direction juridique ou une DSI, la souveraineté opérationnelle devient la vraie ligne de partage entre un usage maîtrisé et une dépendance subie.

La souveraineté juridique traite notamment du territoire d’hébergement, du droit applicable et des exigences de conformité. La souveraineté opérationnelle porte sur la capacité de reprise : accès maintenus, journaux disponibles, configurations exportables, procédure de bascule et continuité réelle du service quand le fournisseur se retire ou coupe l’accès.

L’IA agentique multiplie les points de rupture dans la chaîne de service

Le diagnostic devient plus sensible encore avec l’IA agentique. Dans ce schéma, la dépendance ne porte plus seulement sur un modèle. Elle englobe les identités techniques, les connecteurs, l’orchestrateur, les formats de données, les journaux, le support et les cycles de mise à jour.

Cette architecture en chaîne change profondément l’analyse du risque. Remplacer un modèle par un autre peut s’avérer insuffisant si l’agent s’appuie sur des droits d’accès détenus par un tiers, sur une mémoire non exportable ou sur des intégrations spécifiques à un prestataire. Le verrou ne se situe alors pas dans l’intelligence du système, mais dans son environnement d’exécution.

Pour les entreprises françaises, la question est très concrète. Une fonction automatisée peut intervenir dans le traitement documentaire, l’assistance client, l’analyse interne, le support IT ou la cybersécurité. Si l’un des maillons s’interrompt, c’est toute la chaîne qui peut se bloquer le lundi matin, alors même que le contrat semble toujours en vigueur.

ARTEX : un cas qui illustre le risque de rupture amont

Le cas ARTEX n’autorise pas à tirer des conclusions générales sur toutes les solutions d’IA. Il offre en revanche un exemple parlant de rupture amont. Le changement vers un projet en source fermée, sans nouvelles versions ni maintenance, rappelle qu’une dépendance peut naître aussi vite dans un outil récent que dans une brique plus installée.

Pour une entreprise utilisatrice, le sujet n’est pas théorique. La question est de savoir si les équipes disposent encore des moyens techniques et documentaires pour maintenir le service ou pour en sortir proprement, sans immobiliser des processus critiques.

Pourquoi le remplacement d’un modèle ne suffit pas toujours

Un agent peut dépendre d’une mémoire de travail, de règles configurées, d’autorisations spécifiques et de connecteurs vers d’autres applications. Si ces éléments ne sont ni exportables ni documentés, changer de modèle ne rétablit pas automatiquement le service.

Identités techniques : le maillon discret qui fragilise la reprise

Le texte source insiste sur un angle souvent sous-estimé : la gestion des identités. C’est un sujet central pour les directions de la sécurité comme pour les responsables de production informatique. Un agent agit rarement seul. Il utilise des comptes, des jetons, des droits d’accès et parfois des comptes de service partagés.

Selon le CISO AI Leverage Report de l’Open Future Forum, publié en 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 le signal est clair : des pratiques techniques fragiles persistent (Open Future Forum, octobre 2026).

Le risque est bien connu. Un compte partagé rend l’attribution d’une action plus difficile. Il complique aussi la révocation, car retirer un accès peut affecter d’autres traitements. Pour l’entreprise, cela crée une tension directe entre sécurité, traçabilité et continuité.

Sur le plan de la gouvernance, cette faiblesse renvoie à une question de preuve. En cas d’incident, qui peut démontrer quel agent a agi, avec quels droits et sur quelle base ? Une organisation qui ne peut pas répondre précisément à cette question n’est pas réellement souveraine dans l’exploitation de ses usages IA.

Lorsqu’un même compte de service est utilisé par plusieurs traitements, l’entreprise perd en finesse de contrôle. L’audit devient plus difficile, la révocation peut interrompre des flux sans lien entre eux, et l’identification de l’origine exacte d’une action s’affaiblit. Dans un dispositif IA, cette faiblesse ralentit à la fois la remédiation et la bascule vers une solution de secours.

Réversibilité : la clause contractuelle ne vaut rien sans exercice de coupure

Le cœur de l’analyse tient dans cette idée : une clause de réversibilité, à elle seule, ne prouve rien. Tant qu’elle n’a pas été testée, elle reste une promesse de papier. La souveraineté opérationnelle se vérifie par la simulation d’un arrêt.

Le texte propose quatre questions qu’un DSI devrait pouvoir traiter pour chaque service reposant sur l’IA. Elles forment un cadre de pilotage particulièrement utile pour une entreprise qui veut distinguer innovation et dépendance excessive.

  1. Quelle fonction métier doit continuer si le modèle devient indisponible ?
  2. Quels identifiants et quels droits l’agent utilise-t-il, et qui peut les révoquer directement ?
  3. Quelles données, quelles configurations et quelles traces peuvent être récupérées dans des formats réutilisables ?
  4. Quelle procédure permet de basculer vers un autre outil ou vers un mode manuel, avec quel délai et avec quelle perte de capacité ?

La force de cette grille est de replacer la technique dans le cadre de l’exploitation. On ne parle pas seulement de remplacement logiciel, mais de maintien d’une fonction métier, de délais de reprise et de perte de capacité acceptable. Pour un comité de direction, c’est la bonne unité de mesure.

Le texte ajoute un point essentiel : ce qu’il faut tester n’est pas seulement ce qui tombe, mais aussi ce qui doit survivre au remplacement. Cela comprend l’historique des décisions, l’état des dossiers, les règles configurées et les résultats intermédiaires. Cette couche invisible, souvent mal documentée, peut faire d’une sortie théorique une migration longue et coûteuse.

Quatre actifs à récupérer avant de parler de sortie maîtrisée

  1. Les données utilisées et produites par l’agent.
  2. Les configurations et règles de fonctionnement.
  3. Les traces et journaux nécessaires à l’audit.
  4. L’état de travail en cours, y compris la mémoire utile à la continuité du traitement.

Le vrai audit consiste à couper un accès, pas à commenter le contrat

La méthode proposée est simple et exigeante. Il faut désactiver un connecteur, simuler l’indisponibilité du modèle, révoquer un jeton, puis demander à l’équipe métier de poursuivre la tâche via une procédure de secours. Ce type d’exercice révèle ce que la documentation ne montre pas toujours.

En pratique, plusieurs dépendances peuvent apparaître : une identité détenue par le fournisseur, une mémoire non exportable, une validation humaine devenue purement théorique ou encore une opération aval impossible à annuler. Ce sont précisément ces points, souvent absents des dossiers de présentation, qui déterminent la résilience réelle d’un service.

Autre intérêt de l’exercice : il produit des mesures opérationnelles. Le texte cite des indicateurs simples et utiles, comme le temps de reprise, le volume d’activité dégradée, les données récupérables et les décisions à reconstituer. Pour une direction d’entreprise, cette approche permet enfin de rapprocher le sujet IA des standards plus classiques de continuité d’activité et de maîtrise des risques.

Jacky Galicher : une lecture centrée sur la maîtrise des dépendances

L’analyse est signée par Jacky Galicher, consultant indépendant en gouvernance du numérique et en souveraineté numérique. Le texte rappelle qu’il est ancien DSI de l’académie de Normandie et ancien DSI-RSSI de l’académie de Versailles. Son angle est constant : la question décisive n’est pas le discours sur la souveraineté, mais la capacité d’une organisation à reprendre la main lorsque l’accès disparaît.

Cette approche parle directement aux entreprises. Elle déplace le débat d’une promesse technologique vers une logique de contrôle, de continuité et de responsabilité. Pour des fonctions support comme pour des activités critiques, c’est une manière plus mature d’évaluer les usages de l’IA.

Un test de rupture bien conçu ne vise pas seulement à constater une panne. Il sert à objectiver la reprise possible : délai avant redémarrage, part de l’activité basculable en mode dégradé, volume de données effectivement exportées, décisions à refaire manuellement et points de contrôle redevenus humains.

Contrats, architecture et gouvernance : les trois conditions d’une souveraineté crédible

Une fois les dépendances identifiées, le contrat doit sécuriser la sortie. Le texte mentionne plusieurs points précis : préavis en cas d’évolution ou d’arrêt, durée de support, accès aux journaux, formats d’export, conditions de restitution et assistance à la transition. Ce cadrage n’a de valeur que s’il correspond à une architecture documentée et testée.

Sur le plan technique, l’objectif est tout aussi net : limiter les comptes partagés, isoler les droits de chaque agent et éviter qu’un changement de modèle impose de reconstruire l’ensemble de la chaîne. En clair, il faut concevoir l’IA comme un composant remplaçable, et non comme un centre de gravité impossible à déplacer.

Pour les entreprises françaises, la portée est plus large qu’il n’y paraît. Le sujet touche à la négociation fournisseur, à la cartographie des risques, au contrôle interne, à la sécurité des accès et à la capacité de maintenir une production en mode dégradé. C’est un dossier de direction générale autant que de DSI.

Le lundi matin comme étalon de la souveraineté

La question finale formulée dans le texte est probablement la plus utile : que pouvons-nous encore faire demain si nous ne pouvons plus utiliser ce modèle ? Tant que l’entreprise n’a pas éprouvé sa réponse, la souveraineté reste déclarative.

Ce déplacement du regard est salutaire. Il oblige à traiter l’IA non comme une vitrine d’innovation, mais comme une dépendance potentielle à documenter, tester et encadrer. Une organisation peut parler de souveraineté lorsqu’elle a déjà traversé, même en simulation, le jour où l’accès disparaît.