Souveraineté et réversibilité de l'IA d'entreprise : changer de modèle ou de fournisseur sans perdre sa mémoire

Une IA souveraine, pour une entreprise, n'est pas d'abord une IA hébergée en France : c'est un système dont l'organisation garde la maîtrise, y compris le jour où un fournisseur change ses prix, ses conditions ou retire le modèle utilisé. La réversibilité est la capacité de quitter un outil ou un fournisseur en récupérant tout ce qui a de la valeur, dans un format exploitable. L'interchangeabilité des modèles est la capacité de remplacer le moteur d'IA sans reconstruire le reste.

Ces trois notions sont souvent confondues, et le débat public les réduit à une question de localisation des serveurs. Or un projet d'IA d'entreprise crée une dépendance sur quatre couches distinctes : l'hébergement, la juridiction, le modèle et, surtout, la mémoire que l'organisation accumule (données, documents, échanges, décisions, règles). Ce guide les sépare, rappelle les faits juridiques et techniques vérifiables (CLOUD Act, SecNumCloud, Data Act, politiques de fin de vie des modèles), puis propose un plan de sortie en sept étapes. Il fait partie de notre série sur le deuxième cerveau, l'IA agentique et l'IA en environnement réglementé.

Souveraineté, réversibilité, interchangeabilité : trois notions à ne pas confondre

Définition courte : la souveraineté numérique désigne la capacité d'une organisation à décider seule de ce qu'il advient de ses données et de ses outils, sans qu'un tiers (fournisseur, État étranger) puisse le lui imposer. La réversibilité en est la traduction contractuelle et technique : pouvoir sortir. L'interchangeabilité en est la traduction architecturale : pouvoir remplacer une brique sans toucher aux autres.

Leur contraire commun porte un nom : le verrouillage fournisseur (« vendor lock-in »), situation où le coût de sortie (financier, technique ou humain) est tel que l'organisation reste, même quand le service ne lui convient plus. Le verrouillage n'est pas forcément contractuel ; il est souvent le résultat d'une accumulation silencieuse : des années d'échanges, de notes et de paramétrages qui n'existent que dans un outil.

La dernière ligne mérite d'être soulignée. L'absence d'engagement de durée protège contre un prix, pas contre une perte. Un outil résiliable à tout moment peut verrouiller davantage qu'un contrat de trois ans, si la connaissance accumulée ne peut pas en sortir. C'est pourquoi la série traite la mémoire d'entreprise comme un actif : la question de la souveraineté porte d'abord sur elle.

Les quatre couches de dépendance d'un système d'IA : hébergement, juridiction, modèle, mémoire

Un système d'IA d'entreprise, même simple, empile quatre couches. Chacune crée sa propre dépendance, et une garantie sur l'une ne couvre pas les autres. Les confondre conduit à des décisions mal ciblées, par exemple exiger un hébergement français tout en laissant la mémoire du cabinet dans l'historique d'un assistant grand public.

Analyse. Les couches 1 et 2 relèvent surtout de la conformité (RGPD, secret professionnel, sensibilité des données). La couche 3 relève de la continuité d'activité : un modèle d'IA évolue et disparaît à un rythme qui n'a rien à voir avec celui d'un logiciel métier. La couche 4 relève de la valeur : c'est elle qui grossit chaque jour d'usage, et c'est elle qui rend la sortie coûteuse. Une politique de souveraineté sérieuse traite les quatre, avec une priorité sur la dernière.

Cette grille se combine avec celle des quatre architectures d'IA et de leur niveau d'exposition (assistant grand public, offre professionnelle, IA intégrée à un logiciel, système déployé dans l'environnement de l'organisation) : l'architecture dit où passent les données ; les quatre couches disent de qui l'organisation dépend.

Juridiction et extraterritorialité : pourquoi « hébergé en Europe » ne suffit pas

Définition courte : l'extraterritorialité désigne la possibilité, pour un État, d'imposer ses lois à une entreprise pour des données situées hors de son territoire. Le texte le plus cité est le CLOUD Act américain de 2018, qui permet aux autorités des États-Unis d'exiger d'un fournisseur soumis à leur juridiction la communication de données qu'il contrôle, quel que soit leur lieu de stockage.

Les faits. Le 10 juin 2025, lors d'une audition sous serment devant la commission d'enquête du Sénat sur la commande publique, le directeur des affaires publiques et juridiques de Microsoft France a été interrogé sur ce point. À la question de savoir s'il pouvait garantir que des données ne seraient pas transmises aux autorités américaines sans l'accord des autorités françaises, il a répondu : « Non, je ne peux pas le garantir », tout en précisant que la situation ne s'était jamais produite (compte rendu du Sénat). La réponse ne vise pas un défaut propre à cet acteur : elle décrit la situation juridique de tout prestataire soumis à ce droit.

Deux autres repères complètent le tableau :

• Les transferts de données personnelles vers les États-Unis reposent depuis juillet 2023 sur la décision d'adéquation dite Data Privacy Framework. Le 3 septembre 2025, le Tribunal de l'Union européenne a rejeté le recours en annulation formé par le député Philippe Latombe (affaire T-553/23). Le cadre est donc valide aujourd'hui, mais ses deux prédécesseurs (Safe Harbor, Privacy Shield) ont été invalidés par la Cour de justice : la stabilité à long terme n'est pas acquise.
• Le référentiel SecNumCloud de l'ANSSI qualifie des offres de cloud selon des exigences de sécurité qui incluent, depuis la version 3.2, une protection contre les lois extra-européennes (présentation sur cyber.gouv.fr). L'article 31 de la loi SREN du 21 mai 2024, précisé par un décret d'avril 2026, en fait la règle pour certaines données sensibles de l'État. Cette obligation vise les administrations et certains opérateurs publics, pas les entreprises privées.

Analyse : proportionner l'exigence. Pour une petite structure privée, aucune règle n'impose aujourd'hui un cloud qualifié SecNumCloud. La question n'est pas « faut-il un label ? » mais « quel niveau de risque est acceptable pour quelles données ? ». Des notes de vigilance sur un client, des pièces d'identité ou des informations de santé ne se traitent pas comme une plaquette commerciale. Trois questions suffisent à cadrer : où sont traitées les données (y compris par le modèle d'IA, souvent hébergé ailleurs que l'application) ; à quelle juridiction répond chaque maillon ; quelles données sensibles sortent en clair. Le dernier point se traite par la minimisation et la pseudonymisation, détaillées dans notre article sur l'IA et le secret professionnel.

Un point est souvent oublié : dans un outil d'IA, l'application et le modèle peuvent être hébergés chez deux prestataires différents. Une application hébergée en France qui envoie les requêtes à un modèle opéré ailleurs fait sortir des données à chaque question. La cartographie doit donc suivre le trajet complet d'une requête, pas seulement le lieu de stockage.

Voir comment Brain répond aux quatre couches

Vous venez de séparer hébergement, juridiction, modèle et mémoire. La page Sécurité de Brain détaille comment chacune est traitée : mémoire hébergée chez Scaleway à Paris, chiffrée en AES-256, avec une seconde copie synchronisée en continu chez le cabinet ; données qui n'entraînent aucun modèle public ; données sensibles pseudonymisées, qui ne sortent jamais en clair ; moteur d'IA interchangeable. C'est la lecture utile avant de comparer avec vos outils actuels.

Lire la page Sécurité et souveraineté L'étape « continuité et sortie »

Hébergement à Paris (UE) • Deux copies de la mémoire • Moteur d'IA interchangeable

Le modèle d'IA est une pièce d'usure : fin de vie, prix et règles qui changent

Définition courte : la dépréciation d'un modèle est l'annonce par son fournisseur qu'il ne sera plus maintenu, assortie d'une date de retrait, après laquelle le modèle ne répond plus. Contrairement à un logiciel installé, un modèle d'IA consommé à distance n'appartient pas à l'utilisateur : son cycle de vie est fixé par le fournisseur.

Les faits. Les grands fournisseurs le documentent publiquement :

• Anthropic indique notifier ses clients au moins 60 jours avant le retrait d'un modèle publié, et précise qu'après la date de retrait « les requêtes échouent » (page des dépréciations). Par exemple, Claude Sonnet 3.7 a été déprécié le 28 octobre 2025 et retiré le 19 février 2026, soit moins d'un an après sa sortie. L'éditeur s'est par ailleurs engagé à conserver les poids des modèles retirés, sans les rendre de nouveau accessibles à ce stade (engagements de dépréciation).
• OpenAI tient une page de dépréciations dont les préavis varient selon le type de modèle. Côté produit grand public, GPT-4 a été remplacé dans ChatGPT le 30 avril 2025.

Analyse. À l'échelle d'une organisation, cela signifie qu'un projet d'IA durera plus longtemps que le modèle sur lequel il a démarré. Il faut donc prévoir au moins un changement de modèle par an, voulu ou subi, auquel s'ajoutent trois autres causes de bascule : une hausse de prix, une modification des conditions d'utilisation (conservation, localisation, usages autorisés) et un changement de comportement à version constante, quand l'outil intègre une nouvelle version sans que l'utilisateur le décide.

Un système conçu pour l'interchangeabilité réunit quatre conditions :

1. La mémoire vit hors du modèle. Données, documents, échanges et règles sont stockés par l'organisation ; le modèle les lit, il ne les détient pas.
2. Les consignes sont portables. Procédures, modèles de documents et règles de rédaction sont écrits en langage métier, pas en astuces propres à un modèle.
3. Les index se recalculent. Les index de recherche sémantique (« embeddings ») dépendent du modèle qui les a produits : ils ne se transfèrent pas tels quels, mais se reconstruisent à partir des sources si celles-ci sont conservées. Notre article sur le RAG, la mémoire et l'agent explique pourquoi cette distinction compte.
4. Un jeu de test permet de comparer. Avant de basculer, on rejoue le même jeu de test (« golden set ») sur l'ancien et le nouveau modèle, famille de questions par famille de questions.

Méfiez-vous d'un argument fréquent : « notre outil propose plusieurs modèles ». C'est utile, mais insuffisant si la mémoire, l'historique et le paramétrage restent stockés chez l'éditeur de l'outil. On change alors de moteur sans changer de dépendance.

Réversibilité : ce qu'il faut pouvoir récupérer, et sous quelle forme

Définition courte : la réversibilité d'un outil d'IA est complète quand l'organisation peut récupérer, dans un délai connu et un format exploitable par un autre outil, tout ce qui permet de reconstituer son activité, et pas seulement ses fichiers. Un export qui livre des documents sans leurs rattachements oblige à tout reclasser à la main : c'est une réversibilité de façade.

Le cadre juridique a évolué. Depuis le 12 septembre 2025, le chapitre VI du règlement (UE) 2023/2854, dit Data Act (articles 23 à 31), encadre le changement de fournisseur de services de traitement de données. Il prévoit notamment un préavis maximal de deux mois pour engager le changement, une période de transition de trente jours (prolongeable jusqu'à sept mois en cas d'impossibilité technique justifiée), un délai d'au moins trente jours pour récupérer ses données, et la suppression des frais de changement à partir du 12 janvier 2027 (article 29). Ces règles ont des limites, notamment pour les services développés sur mesure (article 31) ; notre article sur garder ses outils ou changer de logiciel les détaille.

Le règlement fixe un plancher, pas une méthode. Il ne dit pas quels rattachements doivent accompagner un document, ni dans quel format un historique d'échanges doit être livré. Ces points se négocient dans le contrat (clause de réversibilité, assistance à la sortie, formats) : la grille de notre article sur le contrat avec un fournisseur d'IA en donne la liste. Surtout, ils se vérifient en pratique, avant d'en avoir besoin.

Plan de sortie en sept étapes : tester sa réversibilité avant d'en avoir besoin

Un plan de sortie est un document court qui décrit comment l'organisation quitterait un outil ou changerait de modèle, et qui a été essayé au moins une fois. Il se rédige au moment du choix de l'outil, pas au moment de la rupture. Voici une méthode adaptée à une petite structure.

1. Inventorier les dépendances. Pour chaque outil d'IA utilisé, remplir les quatre couches : où sont les données, quelle juridiction, quel modèle, où vit la mémoire. La cartographie des sources fournit la base.
2. Classer les données par sensibilité. Trois niveaux suffisent (publique, interne, sensible). Le niveau d'exigence sur l'hébergement et la juridiction en découle.
3. Lister ce qui doit sortir. Reprendre le tableau ci-dessus et cocher, pour chaque élément, le format réellement obtenu, pas celui promis.
4. Faire un export à blanc. Exporter un échantillon (dix dossiers, par exemple) et vérifier qu'une personne qui ne connaît pas l'outil peut retrouver, à partir de l'export seul, le client, ses documents, ses derniers échanges et les décisions prises.
5. Simuler un changement de modèle. Rejouer le jeu de test avec un second modèle et noter les écarts par famille de questions. Si la bascule est impossible sans réécrire le paramétrage, la dépendance au modèle est forte.
6. Fixer les délais et les rôles. Qui déclenche la sortie, qui contrôle la reprise, quelle période en parallèle, quel critère pour éteindre l'ancien outil. Les délais du Data Act servent de repère.
7. Réviser chaque année et à chaque événement. Changement de modèle, nouvelle source reliée, modification des conditions du fournisseur : le plan se met à jour, et l'export à blanc se refait.

L'étape 4 est la plus révélatrice. Beaucoup d'outils exportent des fichiers ; peu exportent une mémoire. La différence apparaît dès qu'on essaie de reconstruire un dossier à partir de l'export seul. Ce test prend une demi-journée et vaut davantage que n'importe quelle déclaration commerciale, y compris la nôtre.

Le cas d'un cabinet patrimonial : proportionner l'exigence de souveraineté

Prenons un cabinet fictif de conseil en gestion de patrimoine, quatre personnes, trois cents clients. Il utilise un CRM, une messagerie, un stockage de documents et, depuis un an, un assistant d'IA grand public auquel deux collaborateurs collent des extraits de dossiers. Il veut structurer son usage de l'IA sans s'enfermer.

L'inventaire des quatre couches fait apparaître trois constats. D'abord, la mémoire du cabinet est éclatée : une partie dans le CRM, une partie dans les boîtes mail, une partie dans l'historique de l'assistant, qui n'est rattaché à aucun dossier. Ensuite, des données sensibles (situation familiale, patrimoine, éléments de vigilance) sortent en clair vers un modèle dont le cabinet ne maîtrise ni la juridiction ni la durée de conservation. Enfin, aucun export n'a jamais été tenté.

La réponse proportionnée ne consiste pas à tout migrer vers un cloud qualifié. Elle consiste à séparer la mémoire du moteur : regrouper la connaissance du cabinet dans un espace qu'il contrôle, avec une copie chez lui ; pseudonymiser ce qui part vers un modèle ; garder la possibilité de changer de modèle ; puis faire l'export à blanc. C'est aussi un argument de continuité : le jour d'une cession ou d'un départ, la mémoire du cabinet existe en dehors des outils et des personnes.

Comment Brain traite ce point. Selon les informations publiées sur brain.majors.fr, la mémoire du cabinet vit en deux copies, l'une hébergée chez Scaleway à Paris et chiffrée en AES-256, l'autre chez le cabinet (serveur, poste ou disque externe défini lors de l'audit), synchronisée en continu, et « aucune des deux copies n'appartient à un fournisseur d'IA ». Le moteur est interchangeable : le cabinet choisit le modèle (Mistral, Claude, ChatGPT…) et, si un fournisseur change ses prix ou ses règles ou coupe l'accès, un autre répond à la même mémoire, sans ressaisie. La sixième étape de la méthode, « continuité et sortie », fait de la sortie une composante du projet plutôt qu'un sujet tabou. Pour les données structurées de conformité, la Suite Majors® est elle aussi hébergée en Europe ; la reprise d'un ancien logiciel est décrite dans notre guide de migration depuis Harvest ou Wealthcome.

Cet exemple est une illustration, pas un cas client. Il montre surtout qu'une exigence de souveraineté utile tient en une phrase vérifiable : la mémoire de l'organisation doit pouvoir survivre à n'importe lequel de ses fournisseurs. Notre article de présentation de Majors Brain et du deuxième cerveau d'entreprise replace ce principe dans la démarche d'ensemble.