Un LLM souverain suffit-il à être souverain ?

De plus en plus de directions techniques font un choix de bon sens : retenir un fournisseur de modèle de langage européen, plutôt qu’un acteur soumis à une législation extraterritoriale. Cette orientation est légitime et constitue un progrès tangible en matière de gouvernance : elle réduit l’exposition juridique, simplifie la relation avec le régulateur et rapproche le traitement des données du cadre européen. Une question reste pourtant entière, et elle change la grille d’évaluation : ce modèle souverain, aussi conforme soit-il, reçoit toujours vos données réelles pour travailler. Cet article précise la portée exacte de ce choix, sans le remettre en cause, afin qu’un DSI, un DPO ou un RSSI puisse l’évaluer avec justesse.

Deux questions souvent confondues

Le terme « souveraineté » recouvre, dans les faits, deux questions distinctes qu’il est utile de séparer.

La première porte sur le modèle : qui l’a entraîné, où il est hébergé, à quelle législation son éditeur est soumis. Un modèle européen apporte ici une réponse claire et favorable. C’est la dimension la plus visible, et celle que la plupart des grilles d’évaluation retiennent.

La seconde porte sur la donnée : le contenu réel que vous soumettez au modèle pour qu’il travaille. Documents internes, échanges clients, identifiants, données métier. Cette donnée quitte-t-elle votre périmètre, et si oui, sous quelle forme ? C’est une question différente, et un modèle souverain n’y répond pas à lui seul.

« Hébergé en Europe » ne signifie pas « la donnée ne transite pas »

Pour qu’un modèle de langage traite une demande, il doit recevoir le texte de cette demande. C’est le principe même de fonctionnement : le contenu est transmis au modèle, qui le lit, le traite et renvoie une réponse. Que ce modèle soit européen ou non, hébergé à Paris ou ailleurs, ne change rien à ce mécanisme. La donnée réelle est bien envoyée au modèle.

Un hébergement européen et une conformité RGPD encadrent ce traitement : ils déterminent la base légale, la durée de conservation, les droits des personnes concernées, la localisation des serveurs. Ce sont des garanties sérieuses. Mais elles portent sur la manière dont la donnée est traitée une fois reçue, non sur le fait qu’elle reste chez vous. La conformité organise la sortie de la donnée ; elle ne l’empêche pas.

Cette distinction n’est pas un détail de juriste. Pour certaines catégories de données, l’enjeu n’est pas seulement « le traitement est-il conforme ? » mais « cette donnée a-t-elle le droit de sortir de mon périmètre, sous quelque forme que ce soit ? ». Données de santé relevant de l’article 9 du RGPD, secrets industriels, dossiers soumis à une clause de confidentialité contractuelle : pour ces cas, le critère déterminant est le transit lui-même, indépendamment de la qualité du destinataire.

Une couche complémentaire, pas un produit concurrent

Il découle de ce qui précède que la souveraineté de la donnée se traite à un autre endroit que le choix du modèle : en amont de l’appel, sur votre propre infrastructure. L’objectif est de faire travailler le modèle sur le sens d’un document sans lui transmettre les éléments qui identifient les personnes ou les organisations concernées.

Concrètement, avant tout appel, les identifiants sensibles (noms, adresses, IBAN, numéros de sécurité sociale, identifiants clients) sont détectés et remplacés en local par des codes typés et cohérents d’un document à l’autre. Le modèle reçoit un texte où les valeurs réelles ont été substituées. Il raisonne sur les codes, et la réponse est reconstituée en local avec les vraies valeurs. Le modèle n’a jamais vu qui était concerné.

Cette approche est volontairement indifférente au modèle. Elle se place au-dessus du fournisseur que vous avez choisi, qu’il s’agisse d’un modèle européen, d’un autre acteur du marché, ou d’un modèle exécuté entièrement en local. Un LLM souverain et une couche d’anonymisation locale ne sont donc pas en concurrence : ils répondent à deux questions différentes et fonctionnent ensemble. Retenir un modèle européen reste un bon choix ; y ajouter une couche d’anonymisation locale étend la garantie de la souveraineté du modèle à la souveraineté de la donnée.

Ce qui se mesure, et ce qui ne se promet pas

Par souci d’honnêteté, une précision s’impose : aucune détection automatique d’identifiants n’est parfaite. Le sérieux d’une telle couche se juge à deux choses : la mesure, et le comportement en cas de doute.

Côté mesure, nos évaluations situent le rappel à 94,2 % sur un corpus interne de 206 documents synthétiques français multi-métiers (écrits pour le test), et à environ 75 % sur un benchmark public français (dans le périmètre des types de données que nous prétendons couvrir, et que l’évaluation cible explicitement). Ces deux chiffres sont délibérément donnés ensemble : le second, plus exigeant car indépendant, dit où se situe la marge de progression réelle. Nous ne revendiquons pas, et ne revendiquerons pas, une détection parfaite à 100 %.

Côté comportement, c’est le point décisif. Parce qu’aucune détection n’est infaillible, la couche repose sur un principe de fail-closed : en cas de doute, la donnée n’est pas envoyée, elle est conservée en local ou soumise à une validation humaine. Plusieurs mécanismes se superposent : formats connus reconnus par des règles déterministes (IBAN, numéro de sécurité sociale), reconnaissance d’entités, listes propres à l’entreprise. La garantie tient par du code vérifiable et un filet humain, non par le bon vouloir du modèle. Enfin, chaque envoi est journalisé, ce qui permet à l’entreprise de produire elle-même le rapport de ce qui est sorti.

Sur le plan réglementaire, ce sujet gagne en importance avec l’EU AI Act, dont l’application est échelonnée et dont une étape majeure intervient le 2 août 2026. La capacité à documenter précisément quelles données sont soumises à un système d’IA, et sous quelle forme, deviendra un élément attendu de la gouvernance. Disposer d’un journal de ce qui sort, plutôt que d’un engagement contractuel sur ce qui se passe une fois la donnée partie, constitue de ce point de vue une position plus défendable.

En synthèse pour un comité d’évaluation

• Modèle souverain : traite le risque lié au fournisseur (juridiction, hébergement, usage). Choix recommandé et utile.
• Donnée souveraine : traite le risque lié au transit du contenu réel. Non couvert par le seul choix du modèle.
• Les deux ensemble : un modèle européen complété d’une anonymisation locale et journalisée étend la souveraineté du modèle à la donnée elle-même.

La question n’est donc pas « tel modèle est-il plus souverain qu’un autre ? », mais « ma chaîne de traitement garantit-elle, et prouve-t-elle, que le réel ne sort pas indûment ? ». Le choix d’un LLM souverain est un bon premier pas. La souveraineté de la donnée se joue, elle, à l’étape d’avant.

Pour aller plus loin

C’est précisément le rôle que CLEVYA se donne : une couche d’anonymisation locale, indifférente au modèle, qui se place au-dessus du fournisseur que vous avez choisi, un modèle européen inclus. Pour comprendre le positionnement d’ensemble, voir la page Pourquoi CLEVYA. Sur la différence entre un engagement contractuel et une preuve technique, voir l’article Souveraineté IA : contrat vs preuve technique. Et pour la préparation réglementaire, l’article EU AI Act 2026 : ce qu’il faut préparer.

Enfin, si vous voulez évaluer cette approche sur vos propres documents et contraintes, parlez-nous de votre contexte.