Depuis quelques mois, mon VPS héberge six environnements isolés. Ils servent des entreprises ou des projets différents. Plusieurs modèles peuvent intervenir selon les workflows : Claude Code, Codex, Hermes et, sur certains parcours, Grok.
Au départ, cet ensemble ressemblait surtout à un grenier numérique.
Des consignes dispersées dans plusieurs dépôts. Des procédures installées à des endroits différents. Des tâches planifiées qui connaissaient leur propre routine, mais pas toujours le reste de l’entreprise. Une correction faite dans une conversation restait parfois dans cette conversation.
J’avais déjà assez d’IA. Il me manquait une organisation.
Qui possède le travail ? Où l’agent écrit-il ? Quel livrable doit-il rendre ? Quand doit-il s’arrêter ? Que reste-t-il de son passage une fois la conversation fermée ?
C’est ce que je construis aujourd’hui sur mon VPS. J’appelle ce système le Bureau. Chez Ambactos, le Bureau est l’un des quatre produits, aux côtés de la Mémoire, de l’Agent et de la Suite. Ambactos reste l’entreprise. Ce n’est pas un agent.
Le modèle ne dirige pas l’entreprise
Dans mon architecture, le modèle reste remplaçable.
Un pilote peut choisir le bon agent, lancer un travail, suivre son état et présenter les décisions à prendre. Claude Code, Codex ou Hermes peuvent jouer ce rôle selon le moment. Ce n’est pas eux qui « possèdent » le résultat.
Le travail appartient aux agents métier.
J’impose une règle assez stricte : chaque agent doit posséder à la fois un périmètre et un livrable final.
L’agent marketing possède la présence et l’acquisition. L’agent financier possède les livrables financiers. L’agent de veille produit un rapport daté. Le navigateur, le modèle, le planificateur et les connecteurs restent des capacités utilisées par ces agents.
Cette distinction évite de créer un « agent » chaque fois qu’un nouvel outil apparaît dans le diagramme. C’est aussi ce qui permet d’organiser des agents IA sans confondre le prestataire, le produit et le poste de travail.
Le VPS est divisé en trois espaces
Le Bureau est le lieu du travail.
Il contient les agents, leurs procédures, leurs exécutions, les validations en attente et les livrables produits.
La Mémoire est le lieu des faits durables.
Elle conserve les sources, les faits qui doivent survivre, les relations et leur provenance. Un rapport opérationnel reste dans le Bureau. Seule la connaissance qui mérite de survivre au travail rejoint la Mémoire, après contrôle.
Le pilote reste à l’extérieur.
Il coordonne sans s’approprier le livrable. Entre le Bureau et la Mémoire, un contrôle d’écriture empêche une hypothèse de travail de devenir silencieusement une vérité d’entreprise.
Cette séparation paraît théorique jusqu’au jour où un agent se trompe. On sait alors quelle couche corriger, sans réécrire un prompt de deux mille lignes.
Pour le détail d’un agent métier déjà en production, j’ai raconté comment j’ai automatisé la facturation de mes opérations. Ici, je parle de l’étage au-dessus : l’organisation qui rend ce type de travail répétable.
Le workflow qui m’a permis de vérifier le système
J’ai choisi un travail très banal : la veille quotidienne de The Granges.
Tous les jours à 5 h 15 UTC, un workflow recherche les mouvements du marché autour des loisirs immersifs, du tourisme local, des concurrents et des canaux de réservation.
Son contrat est borné :
- Entrées : les thèmes actifs et les sources autorisées dans un fichier d’instance, plus la mémoire de l’entreprise en lecture seule.
- Exécution : une recherche séparée par thème, avec récupération réelle des pages.
- Sortie : un rapport HTML daté, enregistré dans le dossier de l’agent de veille.
- Limites : aucune publication, aucune modification de la mémoire, aucun nouvel abonnement et aucune source ajoutée sans intervention humaine.
La règle de l’agent tient en six mots : pas de récupération, pas de fait.
Chaque information du rapport doit renvoyer vers une page réellement ouverte pendant l’exécution. Une trace indépendante compte les sessions lancées et les récupérations réussies. Le rapport n’est livré que si cette trace confirme ce que la synthèse prétend avoir fait.
Le 10 août 2026, l’exécution a laissé quatre sessions Grok distinctes dans la trace. Trois ont récupéré des sources externes. Sur 35 tentatives de lecture, 32 ont abouti.
TripAdvisor était bloqué par son rendu JavaScript. La commission de Funbooker n’était pas publiée sur les pages consultées. Le rapport l’indique au lieu de compléter les trous.
La garde d’intégrité a autorisé la livraison.
Le dossier contient maintenant neuf rapports quotidiens et une première synthèse mensuelle. Ce n’est plus une démonstration faite à la main pour une capture d’écran. Le workflow se réveille, travaille, échoue parfois sur une source et laisse de quoi vérifier son résultat.
Les sept règles qui structurent maintenant mon VPS
1. Nommer le livrable avant de créer l’agent
« Agent SEO » ou « agent finance » ne suffit pas.
Je définis ce qu’il possède, ce qu’il produit et les dossiers dans lesquels il peut écrire. Sans livrable nommé, la responsabilité finit presque toujours chez le pilote.
2. Isoler les entreprises
Chaque entité dispose de son propre Bureau, de son état d’exécution et de ses agents. Une instance ne parcourt pas les dossiers d’une autre entreprise pour chercher du contexte.
Le registre du VPS compte actuellement six environnements actifs.
3. Garder les constitutions courtes
Le fichier d’identité de l’agent fixe le vocabulaire, les frontières et les décisions qui exigent un arrêt.
Les procédures détaillées vivent dans des compétences chargées au moment du travail. Les outils sont présentés comme des capacités. Je ne verse plus toute l’entreprise dans chaque prompt.
4. Séparer le travail de la mémoire
Une exécution, une correction en cours et une validation appartiennent au Bureau.
Un fait vérifié, une décision conservée ou une source durable appartient à la Mémoire.
Cette séparation empêche une hypothèse de travail de devenir silencieusement une vérité d’entreprise. C’est le même principe que j’expose côté produit dans la mémoire de l’entreprise.
5. Faire appliquer les limites par le moteur d’exécution
La veille est en lecture seule. Elle utilise donc une garde d’intégrité mécanique et peut fonctionner sans approbation quotidienne.
Une publication LinkedIn, un envoi de courriel, la suppression d’un sitemap ou un acte financier suivent une autre politique. Le moteur attend une validation humaine et refuse l’action si la référence d’approbation manque.
La sécurité ne dépend pas de la bonne humeur du modèle ce jour-là.
6. Donner une trace à chaque exécution
Chaque exécution conserve son agent, son workflow, son déclencheur, ses événements, ses validations et ses livrables.
Au 10 août 2026, l’instance The Granges comptait 64 exécutions, 138 entrées de livrables, 26 demandes de validation et quatre tâches planifiées actives.
Certaines exécutions ont échoué. D’autres attendent encore une décision. Je les laisse visibles : un historique honnête vaut davantage qu’un tableau entièrement vert qui oublie les ratés.
7. Corriger la bonne couche
Une nouvelle information va dans la mémoire ou dans les sources de l’entité.
Une meilleure façon de travailler modifie une procédure.
Une séquence répétitive devient un workflow.
Un risque récurrent devient une règle d’approbation.
Un problème de responsabilité retourne dans le contrat de l’agent.
La correction ne doit plus mourir dans la conversation qui l’a fait apparaître.
Ce qui fonctionne et ce qui reste à construire
Les services d’API, les connecteurs d’outils et le planificateur tournent. Les six environnements sont enregistrés. Le contrat agentique de The Granges passe son audit sans erreur ni avertissement : huit agents de périmètre, trois fonctions système, vingt-cinq sous-agents et quatre-vingt-dix-huit compétences.
La surface du Bureau reste en chantier.
Je travaille maintenant sur trois modules : un graphe pour construire les workflows, un Kanban pour suivre le travail confié aux agents et un parapheur pour les décisions humaines. Toute la boucle n’est pas encore raccordée.
C’est aussi la raison pour laquelle je documente le projet maintenant. Je veux montrer le système pendant qu’il se construit, avec ses choix, ses erreurs et ses limites.
Le gain que je ressens le plus n’est pas une réponse plus brillante.
C’est la continuité.
Je peux remplacer un modèle sans perdre le propriétaire du travail, la procédure, les sources, les règles d’approbation et l’historique des corrections.
Un bon agent ne se résume pas à une conversation réussie. Il doit pouvoir reprendre le travail demain, trouver le bon contexte, produire un livrable identifiable, s’arrêter avant une action risquée et laisser une trace compréhensible.
C’est ce que j’essaie de faire tenir dans mon VPS, et ce qu’Ambactos construit pour les entreprises qui veulent le même cadre sans empiler des démonstrations.
Dans le prochain article, je montrerai comment je pars d’un savoir-faire humain pour en faire une capacité complète : une procédure, un agent propriétaire, un outil, un workflow et une porte de validation.
Si vous avez déjà des agents dispersés et aucune réponse claire à « qui possède le travail ? », le prochain pas n’est pas un modèle plus grand. C’est un Bureau. L’Agent de découverte reste En formation. Lorsqu’il sera disponible, il pourrait aider à transformer une responsabilité prioritaire en premier projet de mandat gouvernable : commencer avec un agent.