Il y a dix-huit mois encore, héberger ses propres modèles relevait du choix idéologique ou de la contrainte extrême. La situation a changé sur les trois axes qui comptent. Les modèles, d'abord : la génération actuelle de poids ouverts — Qwen, GLM, Mistral, DeepSeek et consorts — couvre avec un niveau largement suffisant la majorité des usages d'entreprise : synthèse, extraction, RAG documentaire, assistance au code, triage. Le matériel, ensuite : une paire de GPU professionnels récents suffit à servir un modèle de classe 30 à 70 milliards de paramètres quantifié pour une organisation de taille intermédiaire. Le contexte, enfin : entre les exigences RGPD sur les données sensibles, le secret des affaires, et le précédent des contrôles d'exportation américains appliqués en juin à des modèles de frontière, la dépendance exclusive aux API extra-européennes est devenue un risque identifié, documenté, et opposable en comité des risques.
Ce que « souverain » veut dire ici
Soyons précis : exécuter un modèle chinois ou américain à poids ouverts sur ses propres serveurs ne rend pas le modèle européen. Mais cela change ce qui compte : les données ne quittent jamais le périmètre, aucune télémétrie ne remonte, aucune condition d'usage ne peut évoluer unilatéralement, et aucune décision étrangère ne peut retirer des poids déjà téléchargés. La souveraineté d'usage — maîtrise du traitement, du contexte, du journal — est acquise. La souveraineté de conception — qui a entraîné le modèle, sur quoi, avec quels biais — reste un chantier européen, celui des acteurs de modèles du continent, qui mérite d'être soutenu par la demande.
La question posée après l'incident de juillet
Un débat révélateur a suivi la publication du post-mortem de l'intrusion de juillet. Des praticiens ont posé publiquement la question qui fâche : la réponse à incident assistée par IA — celle-là même qui a permis de détecter l'attaque et de déchiffrer ses charges utiles — est-elle réservée aux organisations riches en GPU ? Les retours d'expérience sont plus encourageants qu'attendu : des modèles ouverts de taille moyenne, servis sur des configurations modestes, suffisent à une analyse forensique utile ; certains rapportent des analyses complètes menées sur quelques machines compactes. La capacité de réponse souveraine n'exige pas un supercalculateur ; elle exige d'avoir monté et testé la chaîne avant l'incident.
Les termes honnêtes de l'arbitrage
L'inférence locale a des coûts qu'il faut nommer : investissement matériel et compétences d'exploitation (serving, quantification, mises à jour, évaluation continue), écart de performance réel avec les modèles de frontière sur les tâches de raisonnement les plus exigeantes, responsabilité de sécurisation — un serveur d'inférence mal isolé est une surface d'attaque, et l'été l'a rappelé : les connecteurs et outils qu'on branche aux modèles doivent être authentifiés et bornés comme n'importe quel accès à privilèges. L'architecture raisonnable est donc hybride et hiérarchisée : local par défaut pour tout ce qui touche aux données sensibles, API de frontière — idéalement européennes, ou contractuellement encadrées — pour les tâches de pointe sur données non sensibles, et une bascule testée entre les deux.
Le test des trois questionsPeut-on couper toutes les API externes et continuer à fonctionner en mode dégradé ? Sait-on précisément quelles données partent aujourd'hui vers quels fournisseurs de modèles ? A-t-on déjà servi un modèle ouvert en production, même sur un cas modeste ? Trois « non » : la dépendance cognitive est totale et non pilotée.
L'inférence locale ne remplacera pas les modèles de frontière. Elle rétablit quelque chose de plus important : une position de négociation. On ne discute pas de la même façon avec un fournisseur qu'on peut quitter.