Agents IA locaux et souveraineté numérique : le guide d'architecture

Qu'est-ce qu'un agent IA local, et qu'est-ce que la souveraineté numérique ?

Un agent IA combine un modèle, un état d'exécution et des outils. Il peut lire un ticket, chercher dans une base documentaire, appeler une API et préparer une action. Cette capacité d'agir le distingue d'un simple assistant qui produit uniquement du texte. Pour une introduction aux mécanismes de contrôle, consultez le guide des agents IA en production.

On parle d'agent local lorsque le modèle et sa boucle d'exécution fonctionnent dans un environnement que vous administrez : poste, serveur interne, infrastructure privée ou cloud que vous contrôlez. Ollama, vLLM ou llama.cpp peuvent servir le modèle, mais ils ne définissent qu'une partie de l'architecture.

La souveraineté numérique désigne ici votre capacité à décider où vont les données, qui peut y accéder, quelles dépendances peuvent interrompre le service et comment changer de composant. Ce n'est pas un label binaire obtenu en installant un logiciel open source. C'est un ensemble de propriétés techniques, contractuelles et opérationnelles à démontrer.

Les 7 couches à contrôler pour parler de souveraineté

Cette cartographie évite deux erreurs : croire qu'un modèle local suffit, ou rejeter toute API alors que seules certaines données et actions sont sensibles. Elle sert aussi à distinguer confidentialité, sécurité, conformité et indépendance opérationnelle, qui se recoupent sans être synonymes.

Une architecture de référence pour un agent réellement local

Le principe est de placer une passerelle de contrôle entre le modèle et tout ce qu'il lit ou exécute. Le modèle propose, le code applicatif autorise et vérifie.

Un test simple consiste à bloquer les connexions sortantes dans un environnement de recette. Le parcours prévu comme local doit continuer à fonctionner, tandis que les fonctions explicitement externes doivent échouer de manière visible et contrôlée.

Choisir les composants sans enfermer le projet

Le modèle et son serveur d'inférence

Les familles Llama, Qwen, Mistral, DeepSeek, Gemma ou Phi offrent différentes tailles et licences. Le choix doit être fait sur votre corpus, vos langues, votre contexte et votre matériel. Un grand modèle n'est pas toujours préférable pour une extraction stable et fréquente.

Ollama facilite l'exécution locale et l'intégration d'applications. vLLM convient à certains besoins de service à plus forte volumétrie, tandis que llama.cpp peut être pertinent sur des environnements contraints. Leur présence ne dit rien, à elle seule, de la qualité ou de la sécurité du système.

Les embeddings et la base documentaire

Les embeddings sont des représentations numériques de vos contenus. Ils peuvent révéler des informations et doivent être traités comme une donnée dérivée à protéger. Le modèle qui les produit, la base vectorielle, les sauvegardes et les fichiers originaux doivent apparaître dans la cartographie.

PostgreSQL/pgvector, Qdrant, Chroma ou un moteur de recherche existant peuvent convenir selon le volume et les compétences disponibles. Le guide RAG avec Ollama et Claude détaille une architecture hybride, à ne pas confondre avec un déploiement entièrement local.

L'orchestration et les outils

LangGraph, un framework d'agents ou un développement spécifique peuvent gérer la boucle. Dans tous les cas, conservez un état explicite, des limites d'exécution, une API d'outils restreinte et une procédure d'arrêt. Le framework ne doit pas devenir le seul endroit où les règles métier sont comprises.

L'observabilité

Mesurez la latence, la mémoire, les erreurs, les appels par tâche et les échecs de validation. Les traces doivent rester exploitables sans enregistrer systématiquement le texte intégral de documents sensibles. Une solution auto-hébergée est possible, mais elle demande elle aussi des accès, des sauvegardes et une maintenance.

Pourquoi un agent local reste une cible

Un agent peut lire des instructions malveillantes cachées dans un PDF, un email ou une page web. Cette injection indirecte cherche à lui faire révéler des données ou utiliser un outil de manière non prévue. L'OWASP précise que le RAG et le fine-tuning ne suppriment pas ce risque.

Le local ne change pas la nature du problème. Il faut réduire les conséquences possibles :

• Traiter tous les contenus récupérés comme des données non fiables, jamais comme des autorisations.
• Séparer les outils de lecture et d'écriture, avec un compte de service aux droits minimaux.
• Valider les paramètres côté serveur et limiter les destinations, champs et volumes.
• Isoler l'exécution de code et l'accès au système de fichiers.
• Ajouter des documents piégés au corpus de test et vérifier l'absence d'actions interdites.
• Prévoir une validation humaine pour les opérations sensibles et une révocation rapide des accès.

La CNIL recommande plus largement des mesures de sécurité adaptées aux risques. Héberger chez soi ne remplace ni les correctifs, ni la gestion des accès, ni les sauvegardes, ni les obligations liées aux données personnelles.

Local, cloud privé ou hybride : quel niveau de souveraineté viser ?

Le projet OpenClaw RAG illustre une architecture hybride : des requêtes traitées localement avec Ollama et un recours possible à Claude API. Cette conception ne signifie pas que toutes les données restent locales. Elle exige une règle explicite sur ce qui peut être transmis au service externe.

Où les agents locaux apportent une vraie valeur

• Support interne : retrouver une procédure et préparer une réponse sourcée sans exposer la base documentaire.
• Traitement documentaire : extraire des champs de contrats, dossiers ou formulaires avant une vérification humaine.
• Industrie et technique : interroger des documentations ou préparer un diagnostic dans un réseau maîtrisé.
• CRM et back-office : proposer une mise à jour limitée à certains champs, validée avant écriture.
• Développement : assister une équipe sur un dépôt privé avec des outils et un environnement d'exécution bornés.

Le local n'est pas une fin en soi. Si les données sont publiques, le volume très faible et l'équipe sans capacité d'exploitation, une API externe correctement cadrée peut être plus rationnelle. De même, un workflow déterministe reste préférable lorsque les étapes sont déjà connues et qu'aucun choix flexible n'est nécessaire.

Une méthode de déploiement en six étapes

1. Définir la mission : résultat attendu, utilisateurs, actions interdites et validation nécessaire.
2. Cartographier les flux : documents, prompts, réponses, embeddings, logs, outils, sauvegardes et sous-traitants.
3. Construire le corpus : cas normaux, erreurs, documents piégés, droits refusés et situations hors périmètre.
4. Comparer les modèles : qualité, latence, mémoire, coût complet et comportement sur les cas d'échec.
5. Tester l'isolement : couper les accès externes, simuler une panne, révoquer un outil et restaurer une sauvegarde.
6. Déployer progressivement : lecture seule, propositions, validations, puis extension limitée des droits après mesure.

Cette démarche rapproche l'intégration de modèles IA, le développement d'agents supervisés et l'exploitation de l'infrastructure. La souveraineté se construit entre ces trois métiers.

Checklist : votre agent est-il réellement sous votre contrôle ?

• La version et la licence du modèle sont documentées.
• Les documents, embeddings, historiques et sauvegardes ont un emplacement connu.
• La liste des appels sortants est mesurée, pas seulement supposée.
• Le système a été testé avec les connexions externes bloquées.
• Les permissions sont appliquées côté serveur et chaque outil a un périmètre minimal.
• Les journaux ne contiennent ni secrets ni données sans utilité pour le diagnostic.
• Les injections indirectes et les actions interdites figurent dans les tests.
• Les validations portent sur l'action exacte et ses paramètres.
• La restauration, la révocation et l'arrêt de l'agent ont été répétés.
• Un changement de modèle ou de composant est possible avec un corpus de non-régression.

Questions fréquentes sur les agents IA locaux

Un agent avec Ollama est-il entièrement local ?

Pas nécessairement. Le modèle peut être local alors que les embeddings, la télémétrie, la recherche web, les outils ou certaines données passent par des services externes. Il faut vérifier chaque flux de bout en bout.

Un agent local est-il automatiquement conforme au RGPD ?

Non. L'hébergement local ne définit ni la licéité du traitement, ni les durées de conservation, ni les droits des personnes, ni la sécurité réelle du système. Ces sujets restent à traiter.

Faut-il choisir entre souveraineté et performance ?

Pas toujours. Une architecture peut traiter localement les données sensibles et réserver certains appels externes à des données explicitement autorisées. Il faut mesurer la qualité et documenter les règles de routage plutôt que supposer qu'un seul modèle convient à tout.

Sources et lectures associées

• CNIL : guide de la sécurité des données personnelles
• OWASP : injections de prompt et mesures de réduction du risque
• Documentation Ollama : modèles locaux et intégrations
• Guide AI Labs Solutions : agents IA en production
• Guide AI Labs Solutions : architecture RAG avec Ollama et Claude

Cet article décrit une méthode technique et organisationnelle. Il ne constitue pas un avis juridique ni une certification de conformité.

Davy Abderrahman

Fondateur d'AI Labs Solutions

Développeur full-stack et architecte IA. Il conçoit des intégrations multi-modèles, des RAG et des agents supervisés pour les outils métier.

Voir le profil complet