IA souveraine en environnement régulé : le vrai coût de la souveraineté
Retour d'expérience sur la mise en place d'un agent IA pour un acteur de l'épargne-retraite, où la donnée ne doit jamais sortir d'un périmètre maîtrisé.
Dans la finance, et plus encore dans l'épargne-retraite, deux exigences ne se négocient pas : l'anonymat et la souveraineté des données. Quand nous avons commencé à concevoir un agent IA pour ce contexte, la première question n'a pas été « quel est le modèle le plus intelligent ? », mais « où, et comment, fait-on tourner ce modèle sans jamais perdre le contrôle de la donnée ? ».
C'est cette question — beaucoup moins glamour que le choix du LLM, mais autrement plus structurante — que je voudrais détailler ici.
Le choix du modèle compte-il vraiment ?
Sur le plan réglementaire, étonnamment peu.
Le seul point critique remonté par le service juridique tient à un scénario : si l'éditeur d'un modèle était un jour condamné pour avoir entraîné son modèle sur des données collectées illégalement, il pourrait être contraint de le retirer du marché — et vous, de changer de moteur en urgence.
En pratique, ce risque est aujourd'hui quasi nul, au vu de la manière dont les grands modèles sont distribués et utilisés. Mais il existe, et il décroît à mesure que les données d'entraînement d'un modèle sont « propres » et documentées. C'est donc un critère à garder en filigrane dans le choix, pas un critère bloquant.
La vraie question est ailleurs : l'infrastructure.
Les trois manières de faire tourner un modèle
Il existe aujourd'hui trois grandes façons d'exécuter un modèle, que l'on peut classer du moins au plus souverain.
1. L'API mutualisée (SaaS)
Le modèle tourne « quelque part », sur une machine partagée avec d'autres utilisateurs, et vous l'appelez via une API (OpenRouter en est un bon exemple). C'est simple et économique, mais cela se paie sur deux plans.
Côté performance d'abord : latence, temps au premier token et débit sont tous variables, car vous partagez la ressource.
Côté réglementaire surtout : vos données transitent sur une infrastructure mutualisée, sans cloisonnement garanti. C'est le niveau de garantie le plus bas — et de loin le plus laxiste. Pour un acteur qui doit garantir l'anonymat et la non-divulgation, c'est généralement disqualifiant.
2. Le cloud à machine dédiée
Un cran au-dessus : on vous attribue une machine GPU dédiée… mais seulement le temps de l'inférence. Une fois la machine relâchée, elle est réattribuée à un autre client.
Le risque se déplace : si la mémoire (VRAM, RAM) n'est pas parfaitement purgée entre deux usages, on s'expose à des fuites ou à de la corruption de données. Et en audit, certains organismes très régulés se font retoquer pour la seule raison que la machine est partagée avec un tiers — même lorsque l'hébergeur affiche les bonnes certifications.
Car c'est un point souvent mal compris : la certification du prestataire ne vous dispense de rien. C'est à vous, l'entreprise cliente, de diligenter vos propres audits et campagnes de sécurité pour prouver que cette certification est bien appliquée dans la durée. Une contrainte loin d'être anodine.
3. Le serveur d'inférence dédié
Le maximum de sécurité : votre propre machine, votre propre GPU, rien de partagé. La donnée ne quitte jamais un périmètre que vous maîtrisez de bout en bout.
C'est aussi, aujourd'hui, le plus difficile à obtenir : les GPU se font rares, chers, et compliqués à louer. Nous avons eu la chance d'accéder, chez un hébergeur, à une carte de génération Blackwell (dans les ~100 Go de mémoire). C'est ce dernier scénario que nous avons retenu — et c'est là que les choses deviennent concrètes.
Ce que ça coûte vraiment
Pour une machine de ce type, comptez autour de 1 500 € par mois. Sur un modèle d'environ 30 milliards de paramètres en architecture MoE, on obtient de l'ordre de 900 tokens par seconde — on plafonne sous la barre des 1 000.
Rapporté au token, le coût paraît raisonnable. Sauf qu'un détail change tout : l'usage. Notre service tourne sur des horaires de bureau. La machine, elle, est facturée en continu. Résultat : la moitié — voire les deux tiers — du temps, le serveur ne fait rien, et le coût réel par token grimpe en flèche. Cela reste attractif, mais c'est nettement plus cher qu'une API générative facturée à l'usage.
En contrepartie, on gagne quelque chose qui n'a pas de prix en environnement régulé : le contrôle total. Maîtrise de la latence, du temps au premier token, de la qualité de service, et surtout liberté complète de paramétrer chaque modèle exactement comme on le souhaite.
⚠️ Une précision indispensable : tous ces chiffres et tarifs sont propres à la configuration que je décris. Ils dépendent étroitement du serveur, de son taux d'utilisation et des modèles employés. Ils n'ont aucune valeur de référence ni d'audit — chaque cas est particulier et n'est pas extrapolable.
Le coût caché : la performance
C'est le point que l'on évoque le moins, et c'est pourtant le plus important.
Si vous avez l'habitude de bâtir des agents sur des géants — Claude, Gemini, les gros Llama — la souveraineté totale va vous décevoir. Ces modèles-là, vous ne les ferez pas tourner chez vous à un coût raisonnable. Il faut l'assumer clairement : exiger à la fois la souveraineté maximale et la puissance d'un modèle de raisonnement de pointe, c'est viser un coût astronomique.
Mais — et c'est le vrai message de ce retour d'expérience — ce n'est pas un problème pour 90 % des usages.
On a tendance à sur-dimensionner. On n'a pas besoin d'une usine à gaz pour extraire, classer, router, reformuler ou structurer de l'information. Des modèles bien plus modestes (autour de 30B, parfois moins) suffisent largement — à condition de savoir les paramétrer et les calibrer. C'est là que se joue la compétence réelle : pas dans la taille du modèle, mais dans l'orchestration, le réglage fin et l'architecture qui l'entoure.
Une seule machine, tout le stack, 100 % souverain
Concrètement, sur cette unique machine dédiée, j'ai fait cohabiter, sous vLLM :
- un modèle de garde-fou (guardrail),
- un modèle d'embedding,
- un modèle de speech-to-text,
- et le modèle de texte qui porte l'agent.
Le tout configuré finement, modèle par modèle : nombre de séquences concurrentes, tokens maximum, manière d'interroger… jusqu'au fine-tuning MoE du LLM principal. En pic, on tient autour de 50 utilisateurs simultanés — largement suffisant au regard de l'usage réel.
Et surtout : pas une seule donnée client ne quitte le périmètre.
En résumé
La souveraineté a un coût, financier comme en performance. Le nier ne rend service à personne. Mais avec une architecture pensée autour de modèles raisonnablement dimensionnés et bien calibrés, elle est non seulement atteignable, mais pleinement opérationnelle — y compris sur un marché aussi exigeant que l'épargne-retraite.
Dans un prochain article, j'entrerai dans le choix des modèles eux-mêmes : lesquels, pour quels usages, avec quels atouts et quels compromis.
Ce retour d'expérience partage une mise en œuvre concrète ; il ne constitue ni un conseil juridique, ni une référence d'audit. Chaque contexte régulé est particulier.