Le problème : « européen » et « souverain » ne veulent pas dire la même chose
Une entreprise peut choisir un LLM européen pour réduire sa dépendance, répondre à une politique d’achat ou mieux contrôler ses données. Mais l’adresse du siège de l’éditeur ne dit pas où les requêtes sont traitées, qui administre l’infrastructure ni si le modèle peut être déplacé.
La souveraineté n’est donc pas une étiquette. C’est un ensemble de capacités concrètes : choisir le lieu d’exécution, contrôler les accès, connaître les dépendances, conserver une possibilité de migration et faire appliquer les règles de l’organisation.
Commencer par définir votre exigence
Avant de choisir un modèle, répondez à ces questions :
- Les données peuvent-elles quitter votre réseau ?
- Doivent-elles rester en France, dans l’Union européenne ou dans l’Espace économique européen ?
- Une administration étrangère du cloud est-elle acceptable ?
- Avez-vous besoin d’accéder aux poids du modèle ?
- Devez-vous pouvoir changer d’hébergeur ?
- Quel niveau de service et de support est nécessaire ?
- Qui exploitera les GPU, les mises à jour et la sécurité ?
Ces réponses déterminent l’architecture possible avant même de comparer la qualité des modèles.
Les quatre dimensions de la souveraineté
Souveraineté des données
Elle concerne la collecte, le transfert, le stockage, les sauvegardes, les journaux et la suppression. Demandez où chaque étape a lieu et pendant combien de temps.
Souveraineté technique
Pouvez-vous exécuter le modèle ailleurs ? Les poids, le runtime et le format sont-ils disponibles ? Les outils reposent-ils sur des API propriétaires impossibles à reproduire ?
Souveraineté opérationnelle
Qui possède les clés, administre le service, intervient lors d’un incident et décide d’une mise à jour ? Un serveur situé en Europe peut rester dépendant d’une équipe ou d’un contrôle hors région.
Souveraineté contractuelle
Quelle entité signe le contrat ? Quels sous-traitants interviennent ? Quelles juridictions, garanties de sortie, obligations de notification et conditions de réversibilité s’appliquent ?
Trois architectures possibles
1. API managée
Votre application envoie les requêtes à l’API de l’éditeur. C’est l’option la plus simple : pas de GPU à gérer, mise à l’échelle rapide et accès immédiat aux nouveaux modèles.
Elle convient aux prototypes et aux produits dont les données sont compatibles avec les garanties proposées. Vérifiez région de traitement, rétention, entraînement, DPA, sous-traitants et possibilité d’épingler une version.
2. Hébergement dédié chez un fournisseur choisi
Un fournisseur exécute un modèle ouvert dans une région déterminée, parfois sur une infrastructure dédiée. Cette option combine davantage de contrôle avec une exploitation déléguée.
Vérifiez néanmoins l’accès administratif, le chiffrement, la suppression, la télémétrie, les sauvegardes et la chaîne complète de sous-traitance.
3. Auto-hébergement
Vous téléchargez les poids et exécutez le modèle sur votre infrastructure ou votre compte cloud. Vous maîtrisez le réseau, les accès et le rythme des mises à jour.
Le contrôle augmente, mais la responsabilité aussi : correctifs, GPU, supervision, sauvegardes, disponibilité, filtrage et réponse aux incidents deviennent vos tâches.
Comment lire une licence de modèle ?
Ne vous arrêtez pas au mot « ouvert ». Vérifiez séparément :
- usage commercial autorisé ;
- droit de modifier et fine-tuner ;
- droit de redistribuer les poids ou une dérivée ;
- seuils de taille d’entreprise ou de volume ;
- restrictions d’usage ;
- obligations de mention ;
- licence du code et licence des poids ;
- disponibilité ou non des données d’entraînement.
Une licence permissive simplifie la réversibilité, mais n’annule pas vos obligations liées aux données utilisées par l’application.
Résidence des données : la checklist
Pour chaque canal d’inférence, documentez :
| Question | Preuve attendue |
|---|---|
| Où la requête est-elle calculée ? | Région configurée et documentation de l’endpoint |
| Où sont stockés prompts et réponses ? | Politique de rétention et contrat |
| Les données servent-elles à entraîner ? | Paramètre de compte et engagement contractuel |
| Où vont les logs et sauvegardes ? | Architecture et liste des sous-traitants |
| Qui peut accéder aux données ? | RBAC, procédures support et accès administratifs |
| Comment supprimer ? | API ou procédure testée, délais inclus |
| Que se passe-t-il lors d’un fallback ? | Région et fournisseur de secours documentés |
Une promesse commerciale ne suffit pas. Conservez la preuve datée et testez les réglages réellement activés.
Exemple : assistant documentaire interne
Supposons qu’une entreprise souhaite interroger des contrats confidentiels.
Une première option consiste à utiliser une API européenne avec une région et une rétention compatibles. Une deuxième consiste à faire servir un modèle Mistral ou Apertus dans un cloud contrôlé. Une troisième consiste à auto-héberger le modèle.
La décision doit comparer qualité des réponses, citations, coût, latence, niveau de confidentialité et charge d’exploitation. Si l’équipe ne sait pas maintenir un service GPU disponible, un hébergement dédié peut être plus sûr qu’un auto-hébergement mal maîtrisé.
Construire une matrice de décision
Attribuez un poids aux critères avant le test :
- qualité métier : 30 % ;
- données et sécurité : 25 % ;
- réversibilité et licence : 15 % ;
- coût complet : 15 % ;
- latence et disponibilité : 10 % ;
- support et maturité : 5 %.
Adaptez ces poids au risque. Un service public sensible donnera davantage de poids aux données et à la réversibilité ; un prototype donnera davantage de poids au délai de mise en œuvre.
Les pièges fréquents
- croire qu’un datacenter européen suffit à garantir la souveraineté ;
- choisir l’auto-hébergement sans budget d’exploitation ;
- ignorer les logs, sauvegardes et outils d’observabilité ;
- confondre poids disponibles et licence commerciale permissive ;
- utiliser un alias de modèle qui change sans prévenir ;
- ne pas prévoir d’export ou de solution de remplacement ;
- traiter la conformité comme un contrôle effectué une seule fois.
Plan de mise en œuvre
- Classifiez les données et le niveau de risque.
- Définissez les contraintes de région, contrôle et licence.
- Sélectionnez deux ou trois architectures réalistes.
- Testez les modèles compatibles sur le même jeu de données.
- Faites valider DPA, licences et sous-traitants.
- Lancez un pilote avec données minimisées.
- Testez suppression, incident, fallback et réversibilité.
- Documentez la décision et sa date de révision.
FAQ
Un modèle français garantit-il que les données restent en France ?
Non. Le lieu de traitement dépend du service et de l’hébergement choisis.
Faut-il obligatoirement auto-héberger pour être souverain ?
Non. Un hébergement dédié et contractuellement encadré peut répondre au besoin. L’auto-hébergement offre davantage de contrôle, mais aussi davantage de responsabilités.
Le RGPD impose-t-il un modèle européen ?
Non. Il impose des règles au traitement des données personnelles. L’origine du modèle peut influencer l’analyse, mais ne remplace pas celle-ci.
Comment prouver la résidence des données ?
Avec la configuration de région, la documentation, le contrat, la liste des sous-traitants et des tests des flux techniques.
Quand réévaluer le choix ?
Lors d’une nouvelle version, d’un changement d’hébergeur, de sous-traitant, de licence ou de catégorie de données.