Le sujet de la souveraineté des données dans l’IA est passé de “préoccupation théorique des DSI sensibles” à “discussion de comité de direction normal” en moins de deux ans. En 2026, quand une PME envisage d’intégrer des agents IA dans ses opérations, la question revient systématiquement : où vont les données ?
Cet article décrit ce que nous appliquons en mission Pôle IA externalisé. Pas un discours, des choix opérationnels.
Ce qui a changé en 2026
Trois faits ont déplacé le sujet :
Le RGPD est devenu un sujet d’audit. Les assureurs cyber et les clients grands comptes exigent désormais des preuves de conformité formelles, pas juste une mention dans la politique de confidentialité. Quand un agent IA traite des données clients, la question “où vont-elles ?” devient une obligation contractuelle.
Le débat USA / Europe s’est durci. Les ré-évaluations du Privacy Shield et du Data Privacy Framework ont laissé un brouillard juridique permanent. Les directions juridiques de plus en plus de PME préfèrent ne plus dépendre d’API hébergées aux États-Unis pour des traitements sensibles.
Les alternatives européennes sont devenues sérieuses. Mistral et plusieurs offres françaises et européennes ont atteint un niveau de qualité opérationnel pour la plupart des cas d’usage PME. Le surcoût d’aller chez un éditeur souverain est devenu marginal.
Les trois niveaux de souveraineté possibles
Nous classons les missions selon trois niveaux d’exigence de souveraineté. Le choix dépend de la criticité métier, pas d’un dogme.
Niveau 1 : API publiques avec contractualisation
Pour des cas où les données traitées ne sont pas particulièrement sensibles (contenu marketing public, formulation de réponses à partir de documents non confidentiels, automatisation de tâches sans donnée personnelle), nous utilisons les API publiques (OpenAI, Anthropic, Google) avec le cadre contractuel standard.
Précautions appliquées. Activation des modes “no training” pour empêcher l’utilisation de vos prompts pour l’entraînement futur. Journalisation côté client de ce qui est envoyé. Documentation explicite des données traitées dans le registre.
À quand c’est adapté. Marketing, contenu public, support sur des données qui ne sortent pas du périmètre déjà accessible.
Niveau 2 : modèles hébergés en Europe
Pour des cas avec des données personnelles ou des données métier confidentielles (CRM, RH, finance courante), nous basculons sur des éditeurs hébergeant en Europe : Mistral, certaines offres Anthropic via Bedrock région Paris, ou OVH avec des modèles open source.
Précautions appliquées. Sélection de modèles avec hébergement contractuel en Europe, sans transfert hors UE. Chiffrement en transit et au repos. Audit par notre équipe avant chaque mise en production.
Quand c’est adapté. La grande majorité des cas où des données personnelles non sensibles sont en jeu : tri de mails de clients, qualification de leads, synthèse de documents internes.
Niveau 3 : modèles auto-hébergés
Pour des cas avec des données réellement sensibles (santé, légal, finance régulée, données stratégiques d’industriels), nous installons des modèles open source sur l’infrastructure du client ou sur un hébergeur souverain dédié.
Précautions appliquées. Modèle open source choisi pour son ratio qualité/empreinte (Llama, Mistral, Qwen selon le cas). Infrastructure dédiée. Aucune donnée ne sort de l’environnement client. Documentation complète des accès et journalisation.
Quand c’est adapté. Santé, mutuelles, professionnels du chiffre traitant des dossiers clients, professionnels du droit, industries avec données stratégiques.
La discipline qu’on applique dans tous les cas
Indépendamment du niveau de souveraineté retenu, six règles s’appliquent à chaque mission Pôle IA externalisé :
-
Cartographie des données traitées. Avant toute mise en production, on documente quelles données sortent et où elles vont. Ce livrable rejoint le registre des traitements.
-
Minimisation à la source. L’agent ne reçoit que ce qui est strictement nécessaire à son traitement. Pas de dossier complet quand seul un champ est utile.
-
Anonymisation quand possible. Les noms et identifiants sont remplacés par des codes avant envoi quand le traitement n’en a pas besoin (par exemple : classer un message ne nécessite pas le nom du client).
-
Journalisation des accès. Chaque appel à un modèle externe est journalisé côté client. En cas d’audit, on peut reconstituer ce qui s’est passé.
-
Décision humaine sur les cas sensibles. Les décisions qui engagent (acceptation d’un dossier, rejet, conseil patrimonial) restent toujours signées par un humain. L’IA prépare, ne décide pas.
-
Plan de réversibilité. À tout moment, on peut basculer vers un autre fournisseur ou un autre niveau de souveraineté. Pas de lock-in technique.
Le piège des “POC IA” qui dérapent
Une erreur que nous voyons régulièrement : une équipe métier teste un outil IA en mode “POC” sur des données réelles, en utilisant son compte ChatGPT personnel. Au bout de trois mois, l’outil est devenu opérationnel sans avoir été passé par le filtre conformité. Les données ont circulé partout sans être documentées.
À ce stade, plusieurs choses se sont passées sans contrôle : des données clients ont été utilisées pour l’entraînement de modèles tiers, des accès ont été partagés entre collaborateurs, et personne ne peut documenter ce qui s’est passé en cas d’audit.
C’est ce piège que notre méthode contourne. Aucun POC sur données réelles sans cadrage préalable. Et tout POC qui devient opérationnel doit passer par les six règles ci-dessus.
Comment on en parle avec votre DSI ou votre DPO
Nous fournissons systématiquement, dans le périmètre d’une mission Pôle IA externalisé :
- la liste des modèles utilisés et leur localisation d’hébergement
- les flux de données entre vos systèmes et les modèles
- les journaux d’accès que vous pouvez consulter à tout moment
- les clauses contractuelles que nous signons avec les fournisseurs amont
- une note technique présentable à votre DPO ou à votre auditeur
Ce n’est pas un bonus. C’est dans le périmètre standard. Une mission IA en PME sans cette documentation est, en 2026, une mission qui crée du risque, pas qui en résout.
Quand on refuse une mission
Trois cas où nous refusons une mission Pôle IA externalisé pour raisons de souveraineté :
- Le client veut absolument utiliser des modèles US publics sur des données ultra-sensibles (santé, donnée client en zone régulée), sans accepter d’isolement.
- Le besoin métier exige une garantie technique de localisation que les fournisseurs européens actuels ne peuvent pas tenir (par exemple : certaines exigences de cloud souverain pour défense).
- Le client n’a pas d’interlocuteur conformité et ne veut pas en désigner un. La mission devient impossible à documenter, et c’est notre exposition.
Dans ces cas, on oriente franchement vers un acteur spécialisé (Cap Gemini, Thales, ou un cabinet dédié à la souveraineté). Ce n’est pas notre cœur de métier.
Pour aller plus loin
- Pôle IA externalisé : la mécanique de la mission
- Pôle IA pour services financiers : déclinaison avec des contraintes de souveraineté renforcées
- Pôle IA pour PME santé : déclinaison HDS / RGPD renforcé
- L’IA en PME en 2026, où on en est vraiment : la photographie d’ensemble du marché