Le blogReprendre la main · Épisode 1/5

Publié le 20 juillet 2026

Reprendre la main : comment se lancer dans l'IA souveraine en France en 2026

Un état des lieux, une feuille de route, et la seule question qui compte vraiment.

Série « Reprendre la main », Épisode 1/5 · 2. L'AI Act expliqué · 3. RGPD et IA · 4. Construire son agent IA souverain · 5. Passer à l'échelle

Un lundi matin comme un autre

Imaginez la scène. Lundi, 9 h. Le directeur des systèmes d’information (DSI) d'une PME industrielle découvre que son équipe R&D a branché un assistant IA grand public sur la base de plans techniques de l'entreprise. Pratique. Gratuit. Efficace. Sauf que ces plans, quinze ans de savoir-faire, partent désormais, requête après requête, vers des serveurs qu'il ne contrôle pas, sous une juridiction qui n'est pas la sienne.

Personne n'a rien décidé. L'IA est simplement entrée par la fenêtre pendant que la direction réfléchissait encore à la stratégie.

Cette histoire, c'est celle de la majorité des organisations françaises aujourd'hui. En 2026, la majorité des données sensibles part encore vers des IA américaines soumises au Cloud Act. Et les fournisseurs américains captent environ 83 % du marché européen du cloud-logiciel, 54 milliards d'euros rien que pour la France (étude Asterès pour le Cigref et Numeum, 2025).

Voilà le point de départ. Maintenant, parlons de comment vous, vous allez faire autrement.

Le basculement : pourquoi 2026 est l'année pivot

Il y a dix ans, l'Europe regardait la révolution numérique se faire en Californie. Aujourd'hui, trois forces se sont alignées, et elles changent tout.

Un État qui finance. Dans le cadre de France 2030, environ 2,5 milliards d'euros ont été engagés sur l'IA, plus 655 millions supplémentaires annoncés en juin 2026. L'État déploie « L'Assistant », un agent conversationnel souverain construit avec Mistral sur une infrastructure certifiée, à l'ensemble de ses agents publics (un million de fonctionnaires).

Une réglementation qui se durcit. L'AI Act s'applique par vagues : les interdictions et l'obligation de former les équipes sont déjà en vigueur, l'application générale et les sanctions arrivent au 2 août 2026, et la conformité complète des systèmes à haut risque (RH, crédit, santé...) est fixée au 2 décembre 2027 depuis le réaménagement « Digital Omnibus » de mai 2026. Travailler avec un prestataire hors UE complique sérieusement la démonstration de conformité. (Nous décortiquons ce règlement dans l'épisode 2 de cette série.)

Un champion crédible. Mistral AI, valorisée 11,7 Md€ lors de sa série C de septembre 2025 (un nouveau tour en discussion la porterait autour de 20 Md€), propose des modèles open weight qui rivalisent désormais avec les meilleurs. En 2023, l'écart entre modèles propriétaires et open source était béant. En 2026, sur 80 % des cas d'usage métier, il a quasiment disparu.

Et pourtant : en 2025, seules 18 % des entreprises françaises de 10 salariés ou plus utilisaient l'IA, sous la moyenne européenne de 20 % (Eurostat). La fenêtre d'avance est grande ouverte. C'est maintenant.

La seule idée à retenir : souveraineté ≠ localisation

Si vous ne deviez retenir qu'une phrase de cet article, ce serait celle-ci.

Une donnée hébergée en France mais soumise à une loi étrangère n'est pas souveraine.

Les serveurs européens de Microsoft, Google ou Anthropic n'y changent rien : le Cloud Act américain permet à la justice des États-Unis d'y accéder. Le vrai critère, ce n'est pas la géographie du datacenter. C'est l'immunité juridique.

En France, cette immunité a un nom officiel : le label SecNumCloud de l'ANSSI, qui interdit toute prise de contrôle par une puissance extra-européenne. Au niveau européen, l'équivalent le plus strict s'appelle SEAL-4.

Retenez donc trois piliers pour juger de la souveraineté d'une solution :

Les données sont traitées et stockées dans l'UE, avec une gouvernance claire des accès.
Les modèles tournent sur une infrastructure que vous ou un acteur européen maîtrisez.
Le calcul repose sur un cloud immunisé contre les lois extraterritoriales.

Un détail qui compte : le pays d'origine du modèle est neutre dès lors qu'il tourne sur votre infrastructure. Un modèle chinois (DeepSeek, Qwen) ou américain (Gemma, Llama) auto-hébergé en Europe est souverain. Le même modèle appelé via son API d'origine ne l'est pas. La souveraineté se joue au niveau de l'exécution, pas du logo.

De quoi avez-vous besoin, concrètement ?

C'est ici que la plupart des articles vous laissent tomber. Pas celui-ci. Voici les cinq décisions qui composent votre feuille de route.

Décision 1 : Cartographier vos usages par criticité

Avant tout choix technique, posez-vous une seule question par cas d'usage : que se passe-t-il si cette donnée fuite ?

Données non sensibles (contenus marketing, brainstorming, code non stratégique) → tout est permis, y compris une API classique.
Données personnelles / RGPD (RH, clients) → périmètre UE obligatoire, pas de Cloud Act.
Données ultra-sensibles (santé, juridique, défense, R&D critique) → SecNumCloud ou auto-hébergement, point final.

La bonne stratégie n'est presque jamais « tout souverain » ou « tout API ». C'est l'hybridation : le bon outil pour le bon niveau de risque.

Décision 2 : Choisir votre voie : API souveraine, cloud GPU, ou on-premise

Il existe trois chemins, du plus simple au plus exigeant.

Voie	Ce que c'est	Pour qui
A. API souveraine	Vous appelez un modèle via l'API de Mistral, Scaleway ou OVHcloud (données en UE, pas de Cloud Act)	Démarrer vite, sans gérer d'infra
B. Cloud GPU souverain	Vous déployez un modèle open weight sur des GPU loués en France (Scaleway, OVHcloud, Outscale)	Volumes importants, contrôle fort
C. On-premise	Vous faites tourner le modèle sur votre propre matériel	Air-gap (machine totalement isolée du réseau), données classifiées, très gros volumes

La bonne nouvelle : une API souveraine est déjà un immense pas en avant par rapport à une API américaine, pour un effort quasi identique. C'est souvent le meilleur point de départ.

Décision 3 : Choisir votre modèle

L'écosystème Mistral (français, licence Apache 2.0, donc utilisation commerciale et auto-hébergement libres) couvre presque tous les besoins :

Ministral 3 (3B / 8B / 14B) : les petits modèles. Tournent respectivement sur ~8, 12 et 24 Go de VRAM. Parfaits pour classification, extraction, RAG léger, edge.
Mistral Small 4 (119B, MoE, 6,5B actifs) : multimodal, contexte 256k, Apache 2.0, et tient (quantifié) sur un seul GPU haut de gamme. Le meilleur rapport qualité/coût pour démarrer sérieusement.
Mistral Medium 3.5 (~128B) : pensé pour les agents (appels d'outils, sorties structurées, raisonnement multi-étapes).
Mistral Large 3 (675B, MoE, 41B actifs) : le vaisseau amiral open weight, contexte 256k. Architecture mixture-of-experts : il a la capacité d'un 675B mais le coût de calcul d'un ~41B. Sur l'API, environ 0,50 $ / 1,50 $ par million de tokens (entrée/sortie).

Et si vous n'êtes pas dogmatique : DeepSeek ou Qwen pour le code et le raisonnement, Gemma ou Llama en généralistes, tous auto-hébergeables en UE.

Décision 4 : Choisir votre moteur d'inférence

Le modèle, c'est le moteur. Il lui faut un châssis pour servir les requêtes.

Ollama : « le Docker des LLM ». Une commande, ça tourne. Endpoint compatible OpenAI. Idéal pour prototyper, un seul utilisateur, ou du dev local. Parallélisme limité par défaut, puis file d'attente : la latence explose sous charge.
vLLM : le standard de production. Sa technique PagedAttention et son continuous batching lui permettent de servir bien plus de requêtes en parallèle sur un même GPU que le parallélisme limité d'Ollama, un débit nettement supérieur sous forte concurrence. À réserver dès que vous servez plusieurs utilisateurs simultanément.
LM Studio : interface graphique, parfait pour tester et comparer des modèles sans ligne de commande.
llama.cpp / SGLang : pour les cas pointus (Apple Silicon, offload CPU, RAG multi-tours).

Point crucial pour la migration : tous exposent un endpoint compatible OpenAI. Basculer d'une API vers votre propre serveur ne demande souvent que de changer une seule ligne (base_url). Vos autres appels API vous ont donc déjà entraîné à ce format.

Décision 5 : Dimensionner le matériel

La règle de VRAM à connaître par cœur :

VRAM ≈ (nombre de paramètres × bits par poids) ÷ 8 + cache KV + ~20 % de marge

En clair, la quantification 4 bits (Q4) réduit fortement la mémoire nécessaire tout en préservant l'essentiel de la qualité, de quoi faire tenir de gros modèles sur peu de GPU :

7–13B → tient sur une seule RTX 3090/4090 (24 Go).
70B en Q4 → un A100/H200 80 Go, ou deux GPU 24 Go en parallèle.
Très gros modèles (400B+) → nœud multi-GPU, terrain de spécialistes.

Côté cloud souverain français, en ordre de grandeur : GPU H100 chez Scaleway autour de 2 à 3 €/h (le plus lisible et dev-friendly, datacenters à Paris) ; OVHcloud avec ses AI Endpoints prêts à l'emploi (~0,09 €/M tokens en entrée) et son offre Hosted Private Cloud qualifiée SecNumCloud ; Outscale (Dassault), A100 80 Go autour de 3,60 €/h dans un périmètre SecNumCloud complet, pour les données les plus sensibles.

La feuille de route en 4 phases

Voici comment enchaîner tout ça sans se noyer.

Phase 0, Cadrage (1 semaine). Listez 3 cas d'usage. Classez chaque donnée par criticité. Fixez un budget mensuel cible.

Phase 1, Preuve de valeur (2–4 semaines). Prenez le cas d'usage le moins sensible. Branchez l'API souveraine de Mistral ou Scaleway Managed Inference. Mesurez : qualité, latence, coût réel au token. Vous avez maintenant une baseline chiffrée.

Phase 2, Contrôle (1–2 mois). Pour un cas d'usage sensible ou à fort volume, déployez Mistral Small 4 quantifié sur un GPU loué chez Scaleway ou OVHcloud, servi par vLLM, avec Open WebUI en interface. Comparez le coût à votre baseline API.

Phase 3, Industrialisation (au besoin). Ajoutez du RAG sur vos bases internes, du fine-tuning si nécessaire, du monitoring (Prometheus/Grafana), de la redondance. Passez en Outscale SecNumCloud ou on-premise si la réglementation l'exige.

Ne sautez jamais la Phase 1. Elle vous donne les chiffres qui rendront toutes les décisions suivantes évidentes.

Pros & cons : auto-hébergement vs appels API

C'est la question. Voici la réponse honnête, et elle n'est pas philosophique, c'est un problème de maths.

Les avantages de l'auto-hébergement (vs API)

Souveraineté maximale. Vos prompts et vos données ne quittent jamais votre périmètre. C'est la seule voie pour l'air-gap et les données classifiées.
Coût marginal quasi nul à fort volume. Une fois le GPU payé, chaque token supplémentaire ne coûte que de l'électricité. Le coût est fixe, pas linéaire.
Latence. L'inférence locale supprime l'aller-retour réseau (temps au premier token < 100 ms, contre souvent +300 ms pour une API distante). Décisif pour les agents qui enchaînent des appels.
Pas de dépendance fournisseur. Pas de limite de débit imposée, pas de modèle déprécié du jour au lendemain, pas de changement de CGU.
Contrôle total. Fine-tuning, quantification, versions figées : le modèle est à vous.

Les inconvénients de l'auto-hébergement (vs API)

Coût fixe même à vide. Vous payez le GPU 24 h/24, que vous l'utilisiez ou non. À faible volume, c'est ruineux comparé à une API à l'usage.
Complexité opérationnelle. Drivers CUDA, tuning vLLM, cache KV, monitoring, redondance : un GPU seul est un point de défaillance unique. Comptez 200–500 €/mois d'infra annexe, et surtout du temps d'ingénieur.
Compétences requises. Sans expertise, les trois premiers mois coûtent plus cher en heures GPU gaspillées et en débogage qu'une année entière d'API.
Vous portez tout. Mises à jour, sécurité, disponibilité : c'est votre problème, plus celui d'un fournisseur.

Les avantages des appels API (vs auto-hébergement)

Démarrage immédiat. Une clé, quelques lignes de code, opérationnel en minutes.
Coût à l'usage. Vous ne payez que ce que vous consommez. Imbattable à faible et moyen volume.
Zéro maintenance. Scalabilité, disponibilité, mises à jour du modèle : géré pour vous.
Accès aux plus gros modèles sans investir dans un cluster.

Les inconvénients des appels API (vs auto-hébergement)

Souveraineté conditionnelle. Une API non souveraine (OpenAI, Anthropic, Google) expose au Cloud Act, même avec des serveurs en UE. Une API souveraine (Mistral, Scaleway, OVHcloud) lève ce point : mais vos données transitent quand même par un tiers.
Coût qui explose à l'échelle. Le coût croît linéairement avec les tokens. À très fort volume, la facture devient l'argument n°1 pour internaliser.
Dépendance. Limites de débit, dépréciation des modèles, évolution des prix et des conditions : vous subissez.
Latence réseau incompressible.

Le point de bascule chiffré

Tant que seuls des humains consomment : même une centaine de collaborateurs assidus, soit quelques euros par personne et par mois, l'API (idéalement souveraine) est presque toujours moins chère. Ne self-hostez pas.
Autour de quelques centaines de milliers de requêtes par mois : typiquement quand des pipelines automatisés s'ajoutent aux humains, le calcul dépend de votre modèle, de votre GPU et de votre équipe. C'est la zone grise : faites tourner les chiffres de la Phase 1.
Au-delà, ou dès qu'une contrainte réglementaire impose le périmètre souverain, l'auto-hébergement devient rationnel.

La formule à retenir : le self-hosting est un problème de coût sauf quand c'est un problème de conformité. Si la loi vous impose SecNumCloud, le débat sur le point de bascule ne se pose même plus.

Le mot de la fin

En 2023, la souveraineté numérique était une affaire de RSSI. En 2026, c'est un sujet de comité de direction, et bientôt, une simple question d'hygiène professionnelle, au même titre que sauvegarder ses fichiers.

La vérité, c'est qu'il n'existe pas de souveraineté « totale ». Il existe une architecture : le bon niveau de contrôle pour le bon niveau de risque. Commencez petit, avec une API souveraine sur un cas non sensible. Mesurez. Puis reprenez la main, brique par brique, là où ça compte.

Le DSI de notre histoire du lundi matin n'avait rien décidé. Vous, désormais, vous avez les clés pour prendre une décision.

La question n'est plus « fournisseur américain ou français ? ». Elle est : qui contrôle vos données quand la géopolitique tremble ? Ceux qui auront bâti leur architecture dès maintenant seront les seuls à naviguer sereinement dans le monde qui vient.

À vous de jouer.

📖 Dans la même série, Épisode 2 : « L'AI Act expliqué à ceux qui n'ont pas le temps » (la pyramide des risques, vos obligations, les cinq pièges) · Épisode 3 : « RGPD et IA » (bases légales, AIPD, droits des personnes) · Épisode 4 : « Construire son premier agent IA souverain » (les 5 briques, 7 étapes, budgets) · Épisode 5 : « Passer à l'échelle » (utilisateurs, modèles, machines et euros). La souveraineté répond au « où », l'AI Act au « comment avoir le droit », le RGPD au « que doit-on aux personnes », l'épisode 4 assemble le tout, et l'épisode 5 le fait grandir.

*Sources principales : info.gouv.fr, numerique.gouv.fr, docs Mistral AI, comparatifs cloud souverain (Scaleway/OVHcloud/Outscale), INSEE, étude Asterès pou

← Retour au blog