Introduction
Le 12 juin 2026, Anthropic a annoncé avoir reçu une directive du gouvernement américain lui imposant de suspendre l’accès à ses modèles Fable 5 et Mythos 5 pour tout ressortissant étranger, y compris les ressortissants étrangers situés aux États-Unis et certains employés de l’entreprise. En quelques heures, une question théorique est devenue très concrète : que se passe-t-il lorsqu’une organisation dépend 1 d’un modèle d’intelligence artificielle dont l’accès peut être restreint pour des raisons politiques, réglementaires ou de sécurité nationale ?
Cet épisode ne concerne pas seulement Anthropic. Il révèle une réalité beaucoup plus large : l’intelligence artificielle n’est plus un simple outil logiciel. Elle devient une infrastructure stratégique. Elle s’intègre dans les processus de conformité, de cybersécurité, de relation client, d’analyse documentaire, de veille, de développement logiciel, de prise de décision et parfois même de continuité opérationnelle.
Dans ce contexte, la souveraineté IA ne peut plus être réduite à une question d’hébergement ou de nationalité du fournisseur. Une organisation peut héberger ses données en Europe tout en restant dépendante d’un modèle étranger, d’une API propriétaire, d’un cloud non maîtrisé, d’un fournisseur unique ou d’un système dont elle ne contrôle ni les évolutions, ni les conditions d’accès, ni les preuves d’audit.
La vraie question n’est donc plus : “utilisons-nous une IA performante ?”
La vraie question devient : “si ce système IA devient inaccessible demain, que maîtrisons-nous encore ?”
C’est précisément à cette interrogation que répond la notion de souveraineté IA. Elle ne se décrète pas. Elle se démontre par des preuves : cartographie des usages, maîtrise des données, traçabilité des décisions, documentation des modèles, gestion des fournisseurs, sécurité, réversibilité et capacité d’audit.
La souveraineté IA n’est pas un slogan technologique
La souveraineté IA est souvent présentée comme un choix binaire : utiliser une solution européenne ou non, héberger localement ou non, internaliser ou externaliser. Cette lecture est trop simple. Dans les faits, une organisation peut utiliser des solutions internationales tout en conservant une vraie capacité de maîtrise. À l’inverse, elle peut choisir un hébergement local tout en restant capt captive d’un modèle propriétaire, d’une architecture fermée ou d’un fournisseur difficilement remplaçable.
La souveraineté IA doit donc être comprise comme une capacité organisationnelle. Une organisation souveraine sur ses systèmes IA est capable de répondre à plusieurs questions simples, mais exigeantes :
- Quels systèmes IA sont réellement utilisés ?
- Dans quels processus métiers sont-ils intégrés ?
- Quelles données leur sont transmises ?
- Quels modèles, fournisseurs, API et sous-traitants interviennent ?
- Les résultats produits sont-ils traçables ?
- Les décisions assistées par IA peuvent-elles être expliquées ?
- Le système peut-il être audité ?
- L’organisation peut-elle changer de fournisseur ou de modèle sans rupture majeure ?
Cette approche déplace le débat. Il ne s’agit plus seulement de savoir où se trouve l’infrastructure.
Il s’agit de savoir qui contrôle la chaîne de dépendance.
Un système IA n’est pas un serveur isolé. C’est une chaîne : données d’entrée, prompts, modèles, connecteurs, API, bases documentaires, systèmes RAG, journaux, interfaces métiers, contrôles humains et parfois agents autonomes. La souveraineté se mesure sur l’ensemble de cette chaîne, pas sur un seul maillon.
L’affaire Anthropic : un signal d’alerte sur la dépendance aux modèles
L’épisode Anthropic/Fable 5/Mythos 5 est important parce qu’il montre que l’accès à un modèle avancé peut devenir une variable géopolitique.
Pour une organisation qui utilise un modèle IA uniquement pour des tâches secondaires, une restriction d’accès peut être gênante, mais limitée. Pour une organisation qui l’a intégré dans un processus critique, les conséquences peuvent être beaucoup plus fortes : interruption de service, dégradation d’un processus métier, perte de capacité d’analyse, rupture dans la chaîne de conformité ou incapacité à maintenir certains workflows.
Ce type d’événement oblige les organisations à regarder leurs usages IA autrement.
Un fournisseur IA n’est pas seulement un prestataire technique. Il peut devenir un point de dépendance stratégique. Ses décisions, ses contraintes réglementaires, son pays d’origine, ses obligations d’export control, ses choix commerciaux et ses changements de modèle peuvent avoir un impact direct sur l’activité de ses clients.
La souveraineté IA consiste donc à ne pas subir ces dépendances à l’aveugle.
Elle ne signifie pas nécessairement refuser tout fournisseur étranger. Elle signifie identifier les dépendances, les documenter, les contractualiser, les tester et prévoir des alternatives réalistes.
De la dépendance fournisseur à la dépendance décisionnelle
La dépendance IA n’est pas seulement technique. Elle peut devenir décisionnelle.
Lorsqu’un modèle résume des dossiers, classe des priorités, détecte des anomalies, recommande une action, rédige une analyse ou assiste un collaborateur dans une décision, il influence la manière dont l’organisation agit.
Même si l’humain reste responsable, l’IA modifie le chemin de décision. Elle sélectionne, reformule, priorise, interprète ou simplifie l’information. Elle peut donc produire de la valeur, mais aussi introduire des biais, des erreurs, des angles morts ou une forme d’automatisation implicite de la décision.
C’est ici que la traçabilité devient centrale.
Une organisation ne peut pas se contenter de dire qu’un humain valide toujours à la fin. Elle doit être capable de démontrer comment le système a été utilisé, quelles données ont été mobilisées, quel modèle a produit quel résultat, quelles validations ont eu lieu et quelles limites étaient connues au moment de l’usage. Autrement dit, l’enjeu n’est pas seulement de savoir si l’IA “décide”. L’enjeu est de savoir si l’organisation peut expliquer l’influence de l’IA dans ses décisions.
La souveraineté IA est une capacité de preuve
Le vrai changement introduit par la gouvernance de l’IA tient en un mot : la preuve. Affirmer qu’un système IA est conforme, sécurisé ou responsable n’a que peu de valeur si l’organisation ne peut pas le démontrer. Une preuve n’est pas une intention, une charte ou une déclaration générale. C’est un élément concret, daté, vérifiable : registre d’usage, documentation technique, analyse de risques, journal d’activité, politique interne, trace de validation, preuve de test, clause contractuelle, procédure de réversibilité.
Cette logique est cohérente avec les exigences croissantes autour de l’AI Act, du RGPD, des normes de management et des attentes des auditeurs. Pour les systèmes à risque, les notions de documentation, de journalisation, de supervision humaine, de robustesse, de cybersécurité et de gestion des risques deviennent structurantes.
Même lorsqu’un système IA n’entre pas dans une catégorie à haut risque, cette logique probatoire devient une référence de bonne gouvernance.
Une organisation qui n’a pas de preuves s’expose à plusieurs fragilités :
- elle ne connaît pas l’inventaire réel de ses usages IA
- elle ne maîtrise pas les données qui sortent vers les outils IA
- elle ne sait pas expliquer certains résultats
- elle ne détecte pas les dérives de performance
- elle ne peut pas démontrer sa conformité
- elle ne peut pas rassurer un client, un assureur, un auditeur ou une autorité
- elle ne sait pas mesurer son niveau de dépendance fournisseur.
La souveraineté IA n’est donc pas un discours. C’est un dossier.
Quatre questions simples pour révéler votre niveau réel de maîtrise
Sans entrer immédiatement dans une démarche complète d’audit, quatre questions permettent déjà d’évaluer la maturité d’un système IA.
Première question : pouvez-vous reconstituer les conditions d’une décision assistée par IA prise il y a six mois ?
Il ne s’agit pas toujours de reproduire exactement une sortie, car certains modèles peuvent être probabilistes. Mais l’organisation doit pouvoir retrouver les éléments essentiels : données utilisées, version du modèle, contexte, prompt critique, paramètres, base documentaire mobilisée, utilisateur, résultat généré et validation humaine éventuelle.
Deuxième question : pouvez-vous changer de fournisseur ou de modèle sans rupture majeure ?
Si le fournisseur modifie ses tarifs, ses conditions, son modèle ou son accès, l’organisation dispose-t-elle d’une alternative testée ? Peut-elle récupérer ses données ? Migrer ses workflows ? Reprendre ses prompts ? Conserver ses historiques ? Maintenir son activité ?
Troisième question : le système a-t-il été testé face aux risques spécifiques de l’IA ?
Un système IA peut être exposé au prompt injection, à l’injection indirecte d’instructions, à la fuite de données, à la manipulation d’une base RAG ou à des usages détournés. Une sécurité uniquement déclarative ne suffit pas.
Quatrième question : pouvez-vous produire un dossier d’audit exploitable rapidement ?
Un dossier d’audit ne se prépare pas au moment du contrôle. Il doit exister dans le fonctionnement normal du système : documentation, responsabilités, risques, contrôles, journaux, incidents, fournisseurs, clauses et mesures correctives. Si la réponse à l’une de ces questions est “non” ou “je ne sais pas”, l’organisation tient déjà un point de vulnérabilité.
Traçabilité : un système qu’on ne peut pas expliquer est un système subi
La traçabilité IA ne consiste pas simplement à savoir qu’un outil d’intelligence artificielle a été utilisé. Elle consiste à pouvoir reconstituer les conditions d’un usage. Cela suppose de documenter plusieurs éléments :
- les données mobilisées
- les prompts ou instructions critiques
- la version du modèle
- les paramètres utilisés
- la base documentaire interrogée
- l’utilisateur ou le service à l’origine de la requête
- le résultat généré
- la validation humaine éventuelle
- la décision finale prise par l’organisation
Cette traçabilité devient essentielle dès que l’IA intervient dans des processus sensibles : recrutement, scoring, conformité, cybersécurité, analyse financière, traitement de données personnelles, relation client ou gestion documentaire.
Le jour où un client, un auditeur, un régulateur ou une personne concernée demande des explications, “le modèle a changé depuis” ne peut pas devenir la seule réponse. La traçabilité protège aussi contre un risque plus discret : la dérive. Un système IA peut être pertinent lors de son déploiement, puis devenir moins fiable si les données, les usages, les performances ou le contexte métier évoluent.
C’est tout l’enjeu du model drift et de la conformité IA continue. Un système souverain n’est donc pas seulement un système bien choisi au départ. C’est un système suivi, documenté, surveillé et réévalué dans le temps.
Réversibilité : le vrai test de souveraineté
La réversibilité est probablement le critère le plus concret de la souveraineté IA. Une organisation peut être satisfaite d’un outil IA, l’avoir intégré à ses processus, l’utiliser quotidiennement et en tirer une forte valeur. Mais si elle ne peut pas en sortir, elle n’est pas réellement souveraine. Elle est captive.
La réversibilité désigne la capacité à reprendre la main :
- récupérer les données
- migrer les prompts et paramétrages
- transférer les historiques
- comprendre les dépendances AP
- documenter les connecteurs
- activer des clauses de sortie
- tester une alternative technique
- maintenir une compétence interne minimale.
Le scénario à anticiper n’est pas exceptionnel. Un fournisseur peut modifier son modèle, changer ses conditions contractuelles, augmenter ses tarifs, restreindre une fonctionnalité, retirer une offre ou être soumis à une contrainte réglementaire dans son pays d’origine.
Les organisations qui ont préparé un scénario de bascule peuvent absorber le choc. Les autres découvrent trop tard que leur architecture, leurs données et leurs usages sont verrouillés. Dans une démarche de souveraineté IA, la maîtrise des fournisseurs IA n’est donc pas seulement un sujet juridique. C’est un sujet de continuité, de conformité et de stratégie.
Sécurité IA : il y a ceux qui ont testé, et ceux qui espèrent
La souveraineté IA est indissociable de la cybersécurité.
Les systèmes IA introduisent de nouvelles surfaces d’attaque : fuite de données, prompt injection, injection indirecte d’instructions, manipulation de systèmes RAG, mauvaise gestion des accès, exposition de bases documentaires internes, absence de cloisonnement ou dépendance à des composants externes.
Ces risques sont à la fois techniques et organisationnels.
Un collaborateur peut copier un document confidentiel dans un outil non validé. Une équipe peut connecter un assistant IA à une base documentaire interne sans revue de sécurité. Un service peut adopter un SaaS “augmenté par l’IA” sans impliquer la conformité, le juridique ou la cybersécurité.
C’est pourquoi la sécurité IA ne peut pas être traitée après coup. Elle doit être pensée dès la conception des usages : données accessibles, droits, logs, tests offensifs, scénarios d’abus, robustesse, supervision, cloisonnement et réponse à incident.
DEVFORMA a déjà analysé les risques de sécurité des applications LLM ainsi que le risque d’injection indirecte dans les systèmes RAG et les agents IA. La logique est simple : une IA non testée n’est pas réputée sûre. Elle est réputée inconnue. Et un système dont on ignore la robustesse réelle ne peut pas être déclaré maîtrisé.
Shadow AI : on ne peut pas auditer ce qu’on ne connaît pas
Le Shadow AI désigne l’usage d’outils IA en dehors des cadres validés par l’organisation.
Il peut s’agir d’un collaborateur qui utilise un chatbot public pour traiter un document interne, d’une équipe qui adopte un outil IA sans validation, ou d’un service qui automatise une tâche avec une solution non référencée.
Le problème est immédiat : on ne peut pas gouverner ce que l’on ne voit pas.
Le Shadow AI fragilise toute démarche de souveraineté. Il rend impossible la cartographie des flux, la maîtrise des données, l’identification des fournisseurs, la traçabilité des décisions et la production de preuves.
La réponse ne peut pas être uniquement l’interdiction. Une interdiction trop générale risque de pousser les usages dans l’informel. L’enjeu est plutôt de construire un cadre lisible : outils autorisés, usages interdits, règles de protection des données, processus de validation, sensibilisation, contrôle et gouvernance.
C’est l’objet de notre analyse sur le Shadow AI et la gouvernance des usages IA. La souveraineté IA commence souvent par une étape très concrète : savoir où, comment et pourquoi l’IA est réellement utilisée.
Passeport de souveraineté IA : un outil d’auto-diagnostic, pas une certification
Le Passeport de souveraineté IA ne doit pas être compris comme une certification officielle, ni comme une obligation réglementaire.
Son intérêt est méthodologique.
Il permet de structurer une première lecture de maturité autour de questions essentielles : maîtrise des données, dépendance fournisseur, traçabilité, sécurité, réversibilité, gouvernance, gestion des risques et auditabilité.
L’objectif n’est pas de dire qu’une organisation est “certifiée souveraine”. L’objectif est d’identifier les angles morts et de prioriser les actions.
Un tel passeport peut notamment aider à répondre à des questions comme : les usages IA sont-ils cartographiés ?
- les données envoyées aux systèmes IA sont-elles connues ?
- les fournisseurs et sous-traitants sont-ils identifiés ? les modèles utilisés sont-ils documentés ?
- les résultats produits par l’IA sont-ils traçables ?
- les risques ont-ils été évalués ?
- les systèmes ont-ils été testés ?
- un plan de réversibilité existe-t-il ?
- les preuves sont-elles disponibles en cas d’audit ?
Le Passeport de souveraineté IA devient alors un outil de dialogue entre la direction, les métiers, la DSI, la sécurité, la conformité, le juridique et les équipes opérationnelles.
Il transforme une intuition — “nous dépendons peut-être trop de nos outils IA” — en diagnostic structuré.
ISO/IEC 42001 : transformer le diagnostic en système de management
Une auto-évaluation permet d’identifier les vulnérabilités. Mais pour les traiter durablement, il faut un cadre de pilotage.
C’est le rôle d’ISO/IEC 42001, première norme internationale dédiée aux systèmes de management de l’intelligence artificielle. Elle permet de structurer la gouvernance IA autour de responsabilités, politiques, objectifs, risques, contrôles, audits, documentation et amélioration continue.
Dans cette logique, le Passeport de souveraineté IA peut servir de point d’entrée. ISO/IEC 42001 permet ensuite de transformer les constats en système organisé. Pour les organisations qui souhaitent structurer cette démarche, la formation ISO/IEC 42001 Lead Implementer permet de comprendre comment mettre en œuvre, piloter et maintenir un système de management de l’intelligence artificielle.
Pour les profils chargés d’évaluer la conformité et l’efficacité d’un SMIA, la formation ISO/IEC 42001 Lead Auditor permet de développer une approche d’audit adaptée aux systèmes de management de l’IA. L’enjeu est de passer d’un discours sur la souveraineté à une gouvernance documentée, contrôlable et améliorable.
Gestion des risques IA : surveiller, mesurer, réévaluer
Un système IA peut être performant et risqué en même temps.
Il peut générer de la valeur tout en exposant l’organisation à des erreurs, des biais, des fuites de données, des dépendances fournisseurs, des problèmes de robustesse, des dérives de performance ou des difficultés de conformité.
La souveraineté IA suppose donc une gestion continue des risques.
Cette gestion doit permettre d’identifier les systèmes, de qualifier leur criticité, d’évaluer les données traitées, de mesurer les impacts possibles, de définir des contrôles, de surveiller les incidents, de suivre les performances et de réévaluer régulièrement les usages. Cette logique rejoint les grands cadres de management des risques IA : gouverner, cartographier, mesurer, traiter et améliorer.
La formation Lead AI Risk Manager s’inscrit dans cette logique. Elle permet de structurer une démarche de gestion des risques IA, depuis l’identification des risques jusqu’au reporting et à l’amélioration continue. La souveraineté IA n’est donc pas un état figé. C’est une discipline continue.
Former les équipes : la preuve la plus fragile est humaine
Aucun système de gouvernance IA ne tient durablement si les équipes ne comprennent pas les règles qu’elles doivent appliquer.
Un système peut être conforme sur le papier et exposé par les pratiques. Il peut être sécurisé techniquement, mais fragilisé par un usage imprudent. Il peut être bien documenté, mais contourné par des usages non maîtrisés.
Les métiers, managers, juristes, auditeurs, responsables conformité, responsables sécurité, RH et utilisateurs finaux doivent comprendre ce qu’est un système IA, quelles sont ses limites, quelles données peuvent être utilisées, quels usages sont interdits, quels résultats doivent être vérifiés et pourquoi la traçabilité est une protection.
La certification Certified Artificial Intelligence Professional — CAIP permet de développer cette culture commune autour de l’IA, de ses usages, de ses risques et de ses enjeux responsables. La souveraineté IA ne dépend pas seulement des experts. Elle dépend aussi des comportements quotidiens.
Conclusion : la souveraineté IA, c’est la capacité de ne pas subir
L’affaire Anthropic/Fable 5/Mythos 5 rappelle une chose essentielle : l’accès aux modèles d’intelligence artificielle peut devenir conditionnel. Il peut dépendre d’un fournisseur, d’un État, d’un régime d’export control, d’une décision contractuelle, d’une évolution de modèle ou d’une contrainte de sécurité nationale. Pour les organisations, ce signal doit être pris au sérieux. La souveraineté IA ne consiste pas à tout internaliser. Elle consiste à ne pas subir.
Ne pas subir une coupure d’accès.
Ne pas subir une dépendance fournisseur invisible.
Ne pas subir une absence de traçabilité.
Ne pas subir une architecture impossible à migrer.
Ne pas subir un défaut de preuve en cas d’audit.
Ne pas subir des usages IA dispersés et non gouvernés.
La souveraineté IA repose sur une capacité très concrète : savoir ce que l’on utilise, comprendre ce que l’on dépend, documenter ce que l’on décide, sécuriser ce que l’on expose, auditer ce que l’on affirme et remplacer ce qui peut devenir critique.
Dans un monde où l’IA devient une infrastructure stratégique, la question n’est plus seulement : “quel modèle utilisons-nous ?”
La vraie question est : “que maîtrisons-nous encore si ce modèle n’est plus disponible demain ?”
Évaluer la souveraineté de vos systèmes IA
Vous souhaitez évaluer la maîtrise, la traçabilité et la réversibilité de vos systèmes IA ? DEVFORMA vous propose une première grille d’auto-diagnostic à travers le Passeport de souveraineté IA.
Pour faire une demande, contactez-nous via le formulaire en indiquant en objet : Demande de Passeport de souveraineté IA.
