La souveraineté en matière d'IA mise à l'épreuve par la perte d'accès

La souveraineté en matière d'IA se définit comme la capacité d'une organisation à poursuivre ses activités sans dépendre du fournisseur d'un outil d'IA. Cela suppose de simuler une coupure d'accès avant qu'elle ne se produise, afin de s'assurer que l'organisation peut toujours fonctionner, récupérer ses données et conserver le contrôle.

L'agent ARTEX passe en source fermée

Reuters a rapporté vendredi 9 octobre que le développeur de l'agent ARTEX fait passer son projet en source fermée, en mettant fin aux nouvelles versions et à la maintenance. Cette décision fait suite à l'association, par des entreprises de cybersécurité, de cet outil à une campagne visant des banques sud-coréennes, même si ces attributions proviennent toujours de sources tierces.

Une dépendance qui va au-delà du modèle d'IA

La dépendance aux agents d'IA ne se limite pas au modèle lui-même : elle inclut aussi les identités techniques, les connecteurs et les orchestrateurs. Ces éléments influencent les formats de données, les journaux, les mises à jour et l'assistance. Lorsqu'une chaîne de services fait intervenir plusieurs fournisseurs, remplacer un modèle ne suffit pas forcément à rétablir le service.

Souveraineté juridique et souveraineté opérationnelle

La souveraineté juridique consiste à héberger les données dans une région déterminée pour répondre aux exigences réglementaires. La souveraineté opérationnelle, elle, garantit la disponibilité des API, la portabilité des états de travail et le maintien des connecteurs. Ces deux aspects sont distincts, mais tout aussi importants dans l'intégration de l'IA.

Les comptes de service partagés présentent des risques

Selon le CISO AI Leverage Report publié par l'Open Future Forum (octobre 2026), 37 % des personnes interrogées utilisent des comptes de service partagés pour gérer les accès, contre 14 % qui recourent à des identités déléguées ou à un accès médiatisé. Cette pratique rend plus difficile l'attribution des actions et la révocation des accès, ce qui souligne la nécessité d'une gestion des identités plus sécurisée.

Les DSI doivent répondre à quatre questions clés

Pour chaque service fondé sur l'IA, le DSI doit être en mesure de répondre à quatre questions essentielles : quelles fonctions métier doivent continuer si le modèle est indisponible, quels identifiants et droits l'agent utilise, quelles données peuvent être récupérées, et quelles procédures permettent de basculer vers un autre outil ou un mode manuel. Ces questions garantissent une préparation face à d'éventuelles perturbations.

Tester le scénario de sortie

Les organisations devraient simuler une perte d'accès en désactivant un connecteur, en révoquant un jeton ou en simulant l'indisponibilité du modèle. Cet exercice permet de repérer les dépendances cachées, comme une mémoire non exportable ou des procédures manuelles jamais testées, et fournit des résultats mesurables, tels que le temps de rétablissement et la perte de données.

Une architecture qui doit réduire les dépendances

L'architecture du système doit réduire au minimum les comptes partagés, isoler les droits des agents et éviter de devoir tout reconstruire lorsqu'on change de modèle. Les dépendances techniques doivent être cartographiées et traitées, car aucune clause juridique ne peut compenser un manque de préparation. La question essentielle reste la suivante : que peut encore faire une organisation si elle ne peut plus utiliser un modèle d'IA spécifique ?