La question revient dans presque tous les comités de direction qui se penchent sur un projet d'intelligence artificielle : où vont nos données quand nous appelons un modèle ? La réponse conditionne parfois le lancement du projet, et elle est rarement traitée avec la précision qu'elle mérite.
Le débat sur l'IA souveraine en France souffre d'une confusion tenace entre deux questions distinctes. La première est physique : dans quel pays se trouvent les serveurs qui traitent la donnée ? La seconde est juridique : à quel droit est soumise l'entreprise qui exploite ces serveurs ? On peut parfaitement traiter des données dans un centre de données situé en région parisienne tout en restant exposé au droit d'un pays tiers, si l'exploitant y est soumis.
Cet article démêle ces deux plans, puis passe en revue les quatre options réellement disponibles, du fournisseur européen à l'auto-hébergement sur cartes graphiques louées, avec ce que chacune implique en compétences internes et en facture mensuelle.
Localisation des serveurs et droit applicable : deux questions différentes
Commençons par le vocabulaire, parce que les plaquettes commerciales en jouent.
- Localisation des données. Le pays où la donnée est stockée et traitée. C'est une information factuelle, vérifiable, et que tout fournisseur sérieux documente.
- Transfert hors de l'Union européenne. Au sens du RGPD, un transfert n'est pas seulement un déplacement de fichier : un accès à distance depuis un pays tiers en est un. Une équipe d'assistance située hors de l'Union qui peut consulter vos données réalise un transfert, même si les serveurs sont à Roubaix.
- Droit applicable à l'exploitant. Une société soumise à une législation extra-européenne peut, dans certains cas, se voir demander des données qu'elle détient, y compris stockées ailleurs. C'est le cœur du sujet de la souveraineté, et la localisation seule n'y répond pas.
- Immunité et qualification. Certains référentiels de sécurité, dont le référentiel SecNumCloud publié par l'agence nationale de la sécurité des systèmes d'information, intègrent explicitement des critères de protection contre les législations extraterritoriales, en plus des exigences techniques.
Concrètement, si votre exigence est réglementaire (données de santé, secteur public, opérateur d'importance vitale), c'est la qualification qui vous intéresse. Si votre exigence est contractuelle ou commerciale, la localisation et un engagement écrit de non-réutilisation suffisent souvent. Ces deux situations n'appellent pas les mêmes budgets, et les confondre coûte cher.
Héberger un LLM en France : les quatre options réelles
Il n'existe pas trente-six chemins. Voici les quatre, classés par degré de maîtrise croissant et par simplicité décroissante.
| Option | Ce que vous maîtrisez | Compétences requises | Ordre de grandeur mensuel |
|---|---|---|---|
| API d'un éditeur européen | Localisation et droit applicable, sans exploitation | Aucune particulière : appel d'API | Quelques dizaines à quelques centaines d'euros pour un usage interne courant |
| API d'un éditeur non européen avec option de traitement en Europe | Localisation du traitement, pas le droit applicable | Aucune particulière | Comparable, parfois majoré |
| Modèle ouvert servi par un hébergeur français ou européen | Localisation, droit applicable, choix du modèle | Notions d'exploitation, supervision | De 300 à 2 000 euros selon la taille du modèle et la disponibilité exigée |
| Auto-hébergement sur GPU loués ou achetés | Tout, y compris les pannes | Exploitation système, GPU, sécurité, astreinte | De 700 euros à plusieurs milliers, hors temps humain |
Une remarque sur la deuxième ligne, qui piège beaucoup d'entreprises. Un grand fournisseur non européen qui propose un traitement dans une région européenne règle la question de la localisation, et souvent celle de la non-réutilisation des données pour l'entraînement, ce qui est déjà considérable. Il ne règle pas la question du droit applicable à sa maison mère. Si votre besoin est de rassurer un client sur la localisation, c'est suffisant. Si votre besoin est de répondre à une exigence de souveraineté au sens strict, ce ne l'est pas.
Ce que l'auto-hébergement coûte vraiment
C'est l'option la plus revendiquée et la moins souvent chiffrée. Reprenons le calcul de bout en bout pour un cas courant : un assistant interne servant une centaine de collaborateurs, avec un modèle ouvert de taille moyenne.
- Le matériel. Une carte graphique professionnelle avec suffisamment de mémoire embarquée pour charger le modèle. En location chez un hébergeur, comptez entre 700 et 1 500 euros par mois selon la carte et l'engagement. À l'achat, l'investissement se compte en dizaines de milliers d'euros, auxquels s'ajoutent l'hébergement physique et l'électricité.
- La redondance. Une seule machine signifie qu'une panne arrête le service. Une disponibilité correcte suppose deux machines, donc de doubler la ligne précédente.
- L'exploitation. Mises à jour du serveur d'inférence, supervision, gestion des pics, sauvegardes, correctifs de sécurité. Comptez entre un quart et un demi équivalent temps plein selon l'exigence de disponibilité. C'est de loin le poste le plus sous-estimé.
- Le rattrapage fonctionnel. Les API commerciales fournissent d'emblée des fonctions que vous devrez assembler vous-même : gestion des quotas par utilisateur, journalisation, filtres, suivi de consommation.
Le point de bascule économique se situe rarement là où on l'imagine. Pour un usage interne modéré, l'API reste moins chère pendant longtemps. L'auto-hébergement devient rationnel dans deux situations : un volume très élevé et régulier, qui amortit la machine, ou une contrainte de confidentialité qui interdit purement et simplement la sortie des données. Dans le premier cas, c'est un calcul ; dans le second, c'est une obligation, et le coût n'est plus le critère. Le raisonnement est celui que nous appliquions au chiffrage complet d'un projet dans notre article sur le coût réel d'un projet d'IA générative, où le temps humain pèse plus lourd que la facture technique.
Ce raisonnement rejoint celui que nous avons développé dans notre comparaison entre modèles ouverts et API propriétaires : la question n'est pas de savoir quelle option est la meilleure dans l'absolu, mais laquelle correspond à votre volume, à votre sensibilité et à vos compétences disponibles.
Le cas des données qui n'ont pas besoin de sortir
Avant de monter une infrastructure, posez-vous une question de bon sens : quelle proportion de vos traitements a réellement besoin d'un grand modèle ?
Beaucoup de tâches courantes, comme la classification de courriels, l'extraction de champs dans un formulaire, la détection de langue ou le résumé court, se traitent avec des modèles de petite taille qui tournent sur un serveur ordinaire, parfois sans carte graphique. La qualité est inférieure sur les tâches complexes, mais suffisante sur les tâches répétitives, et la donnée ne quitte jamais votre réseau.
Une architecture qui donne de bons résultats consiste à trier en amont : les traitements sensibles ou volumineux passent par un petit modèle local, les demandes complexes et non sensibles partent vers une API. Cette répartition réduit à la fois la facture et la surface d'exposition, et elle se met en place progressivement.
Autre levier, souvent plus efficace que le changement d'hébergeur : réduire ce que vous envoyez. Supprimer les noms, les numéros de dossier et les coordonnées avant l'appel élimine une grande partie du problème, et cette opération se fait localement. Une donnée pseudonymisée avant transmission n'est pas une donnée protégée pour autant, mais elle change la nature du risque.
Les points à faire écrire dans le contrat
Quelle que soit l'option retenue, six engagements doivent figurer noir sur blanc. Ils valent aussi bien pour un fournisseur français que pour un fournisseur étranger.
- La localisation précise des traitements et des stockages, y compris pour les journaux et les sauvegardes, qui sont trop souvent oubliés.
- La liste des sous-traitants ultérieurs et l'obligation de notifier tout ajout. Un fournisseur européen qui s'appuie sur un service tiers hors Union rouvre la question.
- L'engagement de non-réutilisation des données pour l'entraînement ou l'amélioration des modèles, formulé sans exception implicite.
- La durée de conservation des requêtes et des réponses, avec une valeur chiffrée. Zéro jour de rétention existe chez plusieurs fournisseurs, il faut le demander.
- Les conditions d'accès du personnel du fournisseur à vos données, et depuis quels pays.
- La réversibilité : format et délai de restitution, et suppression effective en fin de contrat.
Ces clauses relèvent de la même discipline que celle décrite dans notre article sur le RGPD appliqué aux projets d'IA en entreprise. Ajoutons un rappel utile : le règlement européen sur l'intelligence artificielle, entré en vigueur en 2024, impose des obligations qui s'échelonnent jusqu'en 2026 et 2027 selon la catégorie de système. Elles portent sur la documentation, la transparence et la gestion des risques, non sur la localisation. Souveraineté et conformité au règlement sont deux chantiers distincts, et satisfaire l'un ne dispense pas de l'autre.
Choisir selon la sensibilité, pas selon le discours
Une grille simple, applicable en une réunion :
- Données publiques ou déjà diffusées (contenu marketing, documentation ouverte) : n'importe quelle API fait l'affaire, choisissez sur le rapport qualité-prix.
- Données internes non sensibles (comptes rendus, notes de travail) : API avec traitement en Europe, engagement de non-réutilisation et rétention nulle.
- Données personnelles ou secrets d'affaires : fournisseur européen, ou modèle ouvert servi par un hébergeur européen, avec analyse d'impact documentée.
- Données relevant d'une exigence réglementaire forte : hébergement qualifié, voire auto-hébergement, et acceptez le coût d'exploitation qui va avec.
La souveraineté n'est pas un interrupteur que l'on bascule une fois pour toutes. C'est un ensemble de décisions par cas d'usage, dont la plupart se règlent par un contrat bien écrit et un tri des données en amont. Commencez par cartographier ce qui sort réellement de chez vous : la plupart des entreprises découvrent à cette occasion que le problème n'est pas là où elles le cherchaient, et que la solution la plus efficace consiste souvent à envoyer moins plutôt qu'à héberger davantage.
Laisser un commentaire