L’IA à l’échelle : Pourquoi je veux un Control Plane pour mes agents

Lancer son premier agent IA est assez simple et gratifiant. Mais dès qu’on veut passer à l’échelle, avec plusieurs agents et des serveurs MCP, on se rend compte que la gestion devient vite ingérable.

Le problème est concret : on se retrouve avec des fichiers de configuration dispersés, des clés API copiées-collées et des accès trop larges. Si vous changez une clé ou ajoutez un outil, vous devez modifier chaque agent un par un. Pire encore, un agent conçu pour lire des documents peut finir par supprimer des fichiers s’il a accès au même serveur MCP avec les même droits qu’un administrateur. On ne peut pas gérer une infrastructure sérieuse avec des fichiers .env et des espoirs.

Séparer l’exécution de la commande

L’idée est d’emprunter un concept du réseau (le SDN) : on sépare le flux de données du flux de commande.

Le Data Plane, c’est le bras armé. C’est par là que le LLM génère du texte ou que le serveur MCP exécute une commande. Le Control Plane, lui, est la couche d’intelligence qui pilote tout ça. Il ne fait pas le travail, il décide qui a le droit d’y accéder et comment.

En pratique, je souhaiterai transformer ma gateway (que j’utilise déjà pour monitorer mes tokens) en ce Control Plane. Elle deviendrai le point de passage obligé.

Au lieu de donner les clés de tous les serveurs MCP à chaque agent, la gateway gère l’identité et le routage. L’agent ne possède plus la clé API finale ; c’est la gateway qui l’injecte juste avant l’appel. Ça permet de changer une clé à un seul endroit sans tout redémarrer. On peut aussi router les requêtes dynamiquement : un modèle léger pour les tâches simples, un modèle lourd pour la réflexion, le tout sans que l’agent n’ait à s’en soucier.

Sécuriser les serveurs MCP et le “Human-in-the-Loop”

Le protocole MCP est puissant, mais donner un accès shell à une IA est risqué. Une seule hallucination peut être fatale pour un serveur.

Pour éviter ça, je ne me contente pas de limiter les accès. Je veux instaurer une distinction entre les commandes “safe” et les commandes “critiques”. La lecture d’un fichier est automatique, mais toute action destructive (suppression, modification de DB, envoi d’email) doit être bloquée par le Control Plane.

L’agent génère l’intention, mais la gateway suspend l’exécution et envoie une notification de validation. L’action ne part vers le serveur MCP que si un humain clique sur “Approuver”. C’est la seule manière de déployer des agents autonomes sans risquer un crash système majeur.

Le flux de données final

Concrètement, le cheminement est le suivant : l’utilisateur passe par l’interface (Open WebUI), la requête traverse la gateway, l’agent réfléchit et demande l’exécution d’un outil. La gateway intercepte cette demande, vérifie les droits, demande une validation si c’est critique, puis libère l’accès au serveur MCP.

C’est un cycle simple mais robuste. L’agent exécute, mais la gateway gouverne.

Conclusion : Vers un système d’exploitation pour l’IA

On passe ici d’une logique d’outils isolés à une véritable infrastructure. L’enjeu n’est plus de savoir si l’IA peut agir, mais de s’assurer qu’on garde la main sur le bouton “Valider”.

En combinant Ollama, Open WebUI et un Control Plane rigoureux, on ne se contente plus de lancer des containers. On bâtit un système où la sécurité est portée par l’infrastructure, et non par la chance ou la qualité du prompt. C’est la base nécessaire pour toute autonomie réelle et maîtrisée.