Souveraineté des agents IA : le vrai sujet n'est pas le modèle, c'est la dépendance

Fable 5 : le précédent du « kill switch » IA

L’affaire Fable 5 a marqué les esprits parce qu’elle illustre une dépendance nouvelle : celle aux modèles d’IA avancés utilisés comme assistants de développement et outils d’augmentation du travail humain.

Lorsqu’une équipe s’appuie sur un agent IA pour coder, analyser un projet, proposer des refactorisations, générer des tests ou assister au debugging, elle ne dépend pas seulement de la qualité des réponses. Elle dépend aussi de la disponibilité du modèle, de sa politique commerciale, de sa juridiction, de ses règles de sécurité, de ses garde-fous, de ses conditions d’usage et parfois même de décisions politiques prises à l’étranger.

Un modèle peut devenir indisponible non pas parce qu’il est techniquement obsolète, mais parce qu’un gouvernement, un fournisseur ou une autorité de régulation décide qu’il ne doit plus être accessible dans certaines conditions.

Pour une équipe de développement, ce n’est pas un détail. Si un agent IA est intégré dans le quotidien - lecture de code, génération de fonctions, assistance à la conception, interaction avec un IDE - alors sa disparition ne provoque pas forcément une panne visible, mais une perte brutale de productivité et une rupture dans les habitudes de travail.

C’est là que la souveraineté IA devient un sujet concret, non pas seulement pour les workflows automatisés, mais pour les outils qui augmentent directement les humains.

Mistral dans le secteur public : souveraineté ou dépendance déplacée ?

La France pousse désormais des solutions souveraines autour de Mistral AI pour les agents publics. Sur le papier, la logique est compréhensible : les données publiques doivent être traitées dans un cadre maîtrisé, sur des infrastructures conformes, avec un acteur européen capable de répondre aux exigences de sécurité, de confidentialité et de gouvernance.

C’est une réponse pragmatique à une dépendance excessive aux grands fournisseurs américains. Pour l’État, il est difficilement acceptable que des documents administratifs, des synthèses internes ou des données sensibles transitent par des infrastructures non maîtrisées.

La vraie souveraineté, ce n’est pas seulement « utiliser un modèle national ». C’est être capable de changer de modèle, de déplacer son inférence, de garder ses données, de maîtriser ses prompts, de versionner ses workflows, de mesurer la qualité des réponses et de dégrader intelligemment le service si le modèle principal devient indisponible.

Un agent IA souverain ne devrait donc pas être conçu autour d’un seul modèle. Il devrait être conçu autour d’une architecture multi-modèles.

Tous les workflows n’ont pas besoin d’un modèle frontier

Une erreur fréquente consiste à penser que chaque usage IA nécessite le modèle le plus puissant disponible. C’est faux. Dans beaucoup de cas, le modèle le plus puissant est surtout le plus coûteux, le plus lent, le plus dépendant d’un fournisseur externe et le plus complexe à gouverner.

Pour de l’extraction de données structurées, un petit modèle bien cadré peut suffire. Si l’entrée est propre, si le schéma de sortie est strict, si les exemples sont bons et si une validation automatique existe derrière, il n’est pas forcément nécessaire d’utiliser un modèle énorme.

Pour de la classification asynchrone, le besoin est encore différent. On ne cherche pas toujours une réponse parfaite en temps réel. On cherche un coût faible, une robustesse suffisante et une capacité à traiter du volume. Dans ce cas, un modèle local de petite ou moyenne taille peut être plus intéressant qu’un modèle cloud très performant. Il est même possible d’utiliser des modèles relativement lents, capables de produire seulement quelques tokens par seconde, mais offrant une bonne qualité de résultat. Sur des tâches asynchrones, cette latence est souvent acceptable. Cela permet de réutiliser des infrastructures existantes, comme d’anciens serveurs avec une mémoire limitée, et de transformer ces contraintes matérielles en avantage économique.

Pour de la génération de code, de l’analyse complexe, de l’architecture logicielle ou du raisonnement multi-étapes, le besoin monte rapidement. Le modèle doit comprendre le contexte, raisonner sur plusieurs fichiers, éviter les hallucinations, proposer des corrections cohérentes et parfois manipuler des dépendances techniques complexes. Là, les modèles plus puissants gardent un vrai avantage. Autrement dit, la souveraineté ne signifie pas « tout faire en local » : elle signifie savoir ce qui doit être local, ce qui peut être cloud, et ce qui doit avoir une stratégie de secours.

Ce que l’on peut réellement faire en local

Aujourd’hui, il est possible d’héberger des modèles utiles sur des machines relativement modestes. Pas pour remplacer systématiquement les meilleurs modèles cloud, mais pour couvrir une partie importante des workflows.

Sur une machine avec 8 à 16 Go de RAM, on peut déjà faire tourner des petits modèles quantifiés pour de la classification simple, de l’extraction de champs, du routage de demandes, de la reformulation ou de la vérification basique.

Sur une machine avec 32 Go de RAM, ou une carte graphique avec suffisamment de VRAM, on peut utiliser des modèles plus confortables en 7B, 8B, 14B ou parfois davantage selon la quantification. Cela ouvre la porte à des agents internes capables de traiter des documents, répondre sur une base de connaissances, préremplir des formulaires ou assister des équipes métier.

Sur une station plus puissante, avec 24 Go de VRAM ou plus, on peut commencer à viser des modèles plus lourds pour du code, de l’analyse avancée, du raisonnement plus long ou des agents multi-étapes plus ambitieux.

Mais il ne faut pas mentir : un modèle local sur une petite machine ne donnera pas la même qualité qu’un modèle frontier cloud. Il sera plus limité, parfois plus lent, moins bon en raisonnement complexe, moins fiable sur les tâches ambiguës. Son intérêt est ailleurs : il reste disponible, contrôlable, économique à grande échelle et indépendant d’une API externe.

Une stratégie réaliste : router les tâches par niveau de criticité

La bonne approche consiste à classer les workflows IA en plusieurs niveaux.

Premier niveau : les tâches simples, répétitives et vérifiables. Extraction de dates, montants, références, catégories, intention client, langue, type de document. Ces tâches peuvent souvent être confiées à des petits modèles locaux, surtout si elles sont suivies par des règles de validation.

Deuxième niveau : les tâches asynchrones. Classification de mails, pré-analyse de tickets, scoring de demandes, préparation de brouillons, résumé interne non critique. Ici, la latence n’est pas toujours un problème : on peut accepter qu’un traitement prenne quelques secondes de plus si le coût et la souveraineté sont meilleurs.

Troisième niveau : les tâches sensibles. Données confidentielles, informations clients, documents publics, données réglementées, secrets industriels. Ces tâches doivent être traitées dans un environnement maîtrisé : local, cloud souverain ou infrastructure certifiée.

Quatrième niveau : les tâches complexes. Développement, architecture, raisonnement juridique, analyse de contrats, arbitrage métier, décision critique. Ici, le modèle doit être plus performant, mais il ne doit pas être laissé seul. Les approches classiques de RAG sont aujourd’hui dépassées dans beaucoup de cas : on s’oriente vers des architectures MCP (Model Context Protocol) beaucoup plus performantes, capables de connecter dynamiquement des sources, des outils et des environnements.

Cette logique permet d’éviter deux pièges : utiliser un modèle trop puissant pour des tâches simples, ou utiliser un petit modèle local pour des tâches qui dépassent clairement ses capacités.

Le local comme plan de continuité

L’hébergement local ne doit pas être vu uniquement comme une alternative idéologique au cloud. Il doit être vu comme un plan de continuité.

Même si une entreprise continue d’utiliser des modèles cloud très performants, elle devrait se demander : que se passe-t-il si l’API devient indisponible ? Si les prix changent ? Si certains usages sont interdits ? Si le fournisseur impose une rétention de données incompatible avec notre politique interne ?

Un modèle local, même moins performant, peut permettre de maintenir un service dégradé. Par exemple, si l’agent principal ne peut plus générer une réponse complète, un modèle local peut continuer à classifier les demandes, extraire les champs importants, préparer un brouillon ou router le dossier vers un humain.

Ce n’est pas parfait, mais c’est mieux qu’un arrêt complet.

Le vrai enjeu : concevoir des agents IA remplaçables

Un agent IA ne devrait jamais être construit comme une dépendance directe à un modèle unique. Il faut séparer le workflow métier du moteur d’inférence. Le modèle doit être une brique interchangeable, pas le cœur indémontable du système.

Cela implique plusieurs bonnes pratiques :

• standardiser les entrées et sorties ;
• utiliser des schémas JSON stricts ;
• conserver les prompts et les versions de prompts ;
• mesurer la qualité par tâche ;
• prévoir plusieurs modèles selon les cas d’usage ;
• garder une capacité de fallback local ou souverain ;
• tracer les décisions importantes ;
• valider automatiquement ce qui peut l’être ;
• garder l’humain dans la boucle pour les décisions sensibles.

Dans cette logique, l’utilisation d’un proxy LLM comme LiteLLM peut jouer un rôle clé. Ce type d’outil permet d’unifier les appels à différents fournisseurs (OpenAI, Mistral, Anthropic, modèles locaux, etc.) derrière une interface unique. On s’affranchit ainsi des variations de formats d’API, des changements de paramètres ou des évolutions spécifiques à chaque fournisseur. Concrètement, cela permet de :

• changer de modèle sans modifier le code applicatif ;
• router dynamiquement les requêtes selon le coût, la latence ou la qualité attendue ;
• implémenter facilement des stratégies de fallback ;
• centraliser la gestion des clés, des quotas et des logs ;
• tester plusieurs modèles sur un même cas d’usage sans refactorisation lourde.

Ce type d’abstraction est essentiel pour rendre les agents réellement remplaçables et éviter que des choix techniques initiaux ne deviennent des contraintes structurelles. La souveraineté IA ne se résume donc pas à choisir Mistral, OpenAI, Anthropic, Google, Meta ou un modèle open source : elle consiste à ne pas rendre son entreprise prisonnière d’un seul choix.

Conclusion : la souveraineté, c’est l’architecture avant le drapeau

L’affaire Fable 5 rappelle qu’un modèle d’IA peut devenir un point de rupture stratégique. Le déploiement de Mistral dans le secteur public montre que la France cherche à reprendre du contrôle sur ses usages critiques. Les modèles locaux montrent qu’il existe une troisième voie : accepter que tous les workflows n’ont pas besoin du même niveau de puissance.

La bonne stratégie n’est pas de tout mettre dans le cloud, ni de tout faire tourner en local. La bonne stratégie est de construire des agents IA capables de choisir le bon modèle pour la bonne tâche. Pour l’extraction de données, un petit modèle local peut suffire. Pour la classification asynchrone, un modèle léger est souvent un excellent compromis. Pour le développement, l’analyse complexe ou les agents à long horizon, les modèles plus puissants restent nécessaires. Mais dans tous les cas, l’architecture doit prévoir le changement.

La souveraineté IA ne se gagne pas uniquement avec un champion national. Elle se gagne avec des systèmes capables de survivre à la panne, au changement de prix, à la restriction réglementaire, au changement de fournisseur et à la prochaine crise géopolitique.