fotsopatrick
/
tour-community
Tour de controle — edition Community (AGPL) : briques libres + agents Chloe et Braignak
Tour de contrôle — édition Community
L'édition Community est publique.
Les briques libres de la tour, installables sur un Odoo standard :
- Code source (AGPL) : https://github.com/fotsopatrick/tour-community
- Démo en ligne : https://democommunity.matourdecontrole.fr (compte demo / demo)
Ce qu'elle contient (15 briques autonomes) :
- Les agents libres : Chloé (chat) et Braignak (observateur), avec votre clé DeepSeek.
- Les briques : Actus, Apprentissage, Condense, Cookie Secure, CV, Messages, Nouveautés, Projets, Rappels, Rate Login, Recette, Réponses, Retours, Sauvegardes, Webapps.
Aucune clé API exigée pour installer. Le cœur de la tour (agents complets coffre, circuits, gouvernance) reste une édition séparée, sous licence propriétaire.
La Tour de contrôle (https://matourdecontrole.fr) est une plateforme de pilotage : un tableau de bord, une équipe d'agents, des circuits de validation et des garde-fous. L'édition Community contient des briques autonomes qui s'installent sur un Odoo standard et s'utilisent seules — avec Chloé et Braignak, les deux agents libres.
…
Les agents IA deviennent capables de lire du code, d'appeler des API, d'exécuter des commandes, de modifier des fichiers et d'enchaîner plusieurs opérations.
Mais une question me semble encore insuffisamment traitée :
Que sait réellement un agent de l'environnement dans lequel il agit ?
Donner à un agent une liste d'outils est une chose.
Lui permettre de comprendre le système derrière ces outils en est une autre.
C'est le problème que j'explore avec un projet personnel que j'appelle La Tour de contrôle.
L'idée
La Tour de contrôle est un prototype de control plane agentique conçu pour se placer entre les agents IA et les systèmes qu'ils peuvent utiliser.
Les agents peuvent être différents :
Claude Code
OpenCode
Gemini
DeepSeek
autres agents
L'idée est qu'ils n'aient pas besoin de porter seuls tout le contexte opérationnel.
La structure ressemble plutôt à ceci :
AGENTS IA
Claude Code OpenCode Gemini
\ | /
\ | /
└────────┴──────┘
│
▼
┌──────────────────┐
│ TOUR DE CONTRÔLE │
├──────────────────┤
│ Carte vivante │
│ Mémoire │
│ Circuits │
│ MCP / outils │
│ Politiques │
│ État │
│ Observabilité │
└────────┬─────────┘
│
▼
Systèmes réels
La Tour n'a donc pas vocation à remplacer Claude Code ou OpenCode.
Elle cherche plutôt à fournir l'environnement opérationnel dans lequel l'agent peut agir.
La carte vivante
C'est probablement la partie du projet qui m'intéresse le plus.
La Tour possède une représentation graphique de l'environnement, que je compare volontairement à GNS3 ou Packet Tracer.
Mais au lieu de représenter uniquement des équipements réseau, cette carte peut représenter :
agents
services
applications
outils
circuits
dépendances
capacités
états
Dans la version actuelle, la cartographie couvre notamment :
serveurs
conteneurs
volumes
webapps
agents / équipe
outils
et la documentation du système recense notamment 76 webapps et 202 outils dans la carte actuelle.
La carte est alimentée par une découverte de l'environnement et est actuellement rafraîchie périodiquement. Une couche de suivi temps réel est en cours de finalisation.
L'idée n'est donc pas d'avoir un joli diagramme d'architecture.
L'idée est d'avoir une représentation exploitable de l'environnement.
Pourquoi donner une carte à un agent ?
Prenons une demande simple :
« Analyse le problème et lance la procédure appropriée. »
Avec une simple liste d'outils, l'agent doit reconstruire mentalement la structure du système.
Avec une carte, le parcours peut devenir :
Demande
↓
Carte
↓
Capacité pertinente
↓
Circuit
↓
Outil
↓
Action
↓
Résultat
↓
État mis à jour
L'hypothèse derrière cette approche est simple :
Un agent ne devrait peut-être pas seulement savoir quels outils il peut appeler. Il devrait comprendre où ces outils se situent dans l'environnement.
Les circuits
La Tour possède aussi une notion de circuit.
Un circuit représente une procédure opérationnelle réutilisable.
L'idée est d'éviter de demander au modèle de réinventer une procédure déjà connue à chaque exécution.
On peut alors avoir :
Problème
↓
Procédure
↓
Exécution
↓
Vérification
↓
Workflow réutilisable
La logique est donc :
raisonner quand c'est nécessaire, réutiliser une capacité quand elle est déjà connue.
Cette distinction me paraît importante dans des systèmes qui deviennent de plus en plus agentiques.
La mémoire
La mémoire de la Tour ne se limite pas à l'historique d'une conversation.
Le système peut conserver notamment :
connaissances
procédures
expériences
circuits
état opérationnel
Une capacité peut donc suivre une chaîne du type :
Découverte
↓
Apprentissage
↓
Conservation
↓
Récupération
↓
Réutilisation
L'objectif est que l'organisation ne perde pas son savoir opérationnel simplement parce que le modèle ou l'agent change.
MCP comme interface
La Tour expose aussi certaines capacités via MCP.
Dans cette architecture :
Agent
↓
MCP
↓
Tour
↓
outil / circuit
↓
système réel
MCP sert donc d'interface.
La Tour cherche à être la couche qui organise ce qui se trouve derrière cette interface :
contexte
politiques
workflows
état
outils
exécution
observation
Plusieurs agents, un même environnement
C'est une autre hypothèse importante du projet.
J'ai utilisé la Tour avec différents agents et modèles.
Claude Code et OpenCode sont ceux que j'utilise le plus dans mon travail, et j'ai également testé d'autres modèles.
L'observation intéressante est la suivante :
Les agents peuvent changer alors que l'environnement opérationnel reste le même.
Cela conduit à une architecture de ce type :
Claude Code ─┐
OpenCode ────┤
Gemini ──────┤
DeepSeek ────┤
▼
TOUR DE CONTRÔLE
▼
Systèmes réels
Je ne présente pas cela comme un benchmark général des modèles.
C'est simplement ce que j'ai observé sur mon propre environnement.
Le contrôle des actions
Une fois qu'un agent peut agir sur des systèmes réels, une question devient centrale :
Qu'est-ce qu'il a le droit de faire ?
Je ne pense pas qu'un prompt doive être l'unique mécanisme de contrôle.
La logique recherchée est plutôt :
Raisonnement
↓
Capacité demandée
↓
Contrôle / politique
↓
Exécution
↓
Observation
Cela permet d'introduire une séparation entre :
ce que l'agent peut concevoir,
ce que la plateforme lui permet de faire,
et ce qui a réellement été exécuté.
Sécurité
La Tour contient également des composants liés à la sécurité et à la défense opérationnelle.
Parmi les capacités présentes dans la cartographie et les interfaces figurent notamment :
défense réseau
verrouillage d'urgence
veille intrusion
pare-feu
Il existe également des fonctions liées au pentest.
Je préfère cependant être précis : je ne présente pas la Tour comme une plateforme complète de pentest.
Je la présente comme une plateforme qui intègre également des capacités de sécurité et de contrôle opérationnel.
Observabilité
Un autre objectif du projet est de pouvoir observer non seulement le résultat final mais aussi l'exécution.
Le suivi recherché ressemble à ceci :
Quel agent ?
↓
Quel workflow ?
↓
Quel outil ?
↓
Quel système ?
↓
Quel résultat ?
↓
Quel nouvel état ?
Autrement dit :
passer de « l'agent a répondu » à « voici ce que le système a réellement fait ».
La couche de suivi temps réel est actuellement en cours de finalisation.
Ce que la Tour n'est pas
Je préfère être explicite.
La Tour n'est pas :
un nouveau modèle de langage ;
un remplacement de Claude Code ;
un remplacement d'OpenCode ;
un simple chatbot ;
un produit enterprise fini.
C'est aujourd'hui un prototype fonctionnel de control plane pour systèmes agentiques, construit et utilisé dans un environnement réel.
Certaines parties sont avancées.
D'autres sont expérimentales.
Certaines capacités sont testées en production personnelle.
D'autres doivent encore être industrialisées.
Pourquoi ce problème m'intéresse
Les agents deviennent capables de faire de plus en plus de choses :
lire
raisonner
écrire
exécuter
appeler des APIs
modifier des systèmes
enchaîner des opérations
À mesure que leurs capacités augmentent, le problème change.
Il ne s'agit plus seulement de demander :
« Quel agent dois-je utiliser ? »
Mais aussi :
« Dans quel environnement cet agent évolue-t-il ? »
« Que peut-il voir ? »
« Que peut-il exécuter ? »
« Quelle procédure doit-il suivre ? »
« Que s'est-il réellement passé ? »
« Comment retrouver l'état précédent ? »
« Comment changer de modèle sans reconstruire toute l'organisation autour de lui ? »
Cela commence à ressembler à un problème de plateforme, pas seulement à un problème de modèle IA.
Le marché commence lui aussi à traiter ce problème
Je ne prétends évidemment pas avoir inventé cette catégorie.
Microsoft, AWS, IBM, Salesforce, Snowflake, Kong et d'autres travaillent déjà sur des problèmes voisins : gouvernance des agents, orchestration, observabilité, gestion des outils, identité et contrôle.
C'est justement ce qui m'intéresse.
Cela signifie que la question devient moins :
« Les entreprises auront-elles besoin de contrôler leurs agents ? »
et davantage :
« À quoi doit réellement ressembler un control plane agentique ? »
Mon hypothèse actuelle
L'hypothèse derrière la Tour est :
Les agents devraient pouvoir changer, tandis que le contexte opérationnel, les capacités, les workflows, les politiques, l'état et l'observabilité devraient appartenir à une couche indépendante d'un agent ou d'un modèle particulier.
Et peut-être que cette couche doit également fournir quelque chose de plus fondamental :
une carte vivante de l'organisation que les humains et les agents peuvent comprendre et parcourir.
Ce que je cherche à savoir maintenant
Le projet a été construit par itérations, à partir de problèmes réels rencontrés en développant et en opérant le système.
Je cherche maintenant à confronter cette approche à des personnes qui travaillent réellement avec des systèmes complexes.
Pour un CTO ou un responsable plateforme
Est-ce que ce problème existe aujourd'hui dans votre organisation ?
Pour un développeur
Une carte opérationnelle de ce type rendrait-elle réellement vos agents plus utiles ?
Pour un architecte
Où placeriez-vous une telle couche dans une architecture d'entreprise ?
Pour un responsable sécurité
Quels contrôles devraient absolument exister avant de laisser un agent agir sur une infrastructure réelle ?
Pour un responsable produit
Est-ce un vrai problème à résoudre, ou simplement une abstraction intéressante techniquement ?
Et pour ceux qui travaillent déjà avec les agents
Qu'est-ce que je rate ?
Je cherche surtout des critiques concrètes.
La question centrale
Nous sommes en train de construire des agents capables d'agir de plus en plus directement sur nos systèmes.
La prochaine question n'est peut-être plus seulement :
« Comment rendre les agents plus intelligents ? »
Mais :
« Quelle couche doit se trouver entre le raisonnement d'un agent et l'organisation réelle ? »
C'est la question que j'explore avec La Tour de contrôle.
Vos retours sont les bienvenus.
Top comments (0)