Gérer des équipes d’agents IA sans tout réexpliquer à chaque redémarrage

Travailler avec plusieurs assistants de code, c’est pratique… jusqu’au redémarrage. Chaque session repart de zéro. Il faut remettre le contexte, rappeler les décisions prises la veille, réexpliquer l’architecture. On a l’impression de réintégrer les mêmes prestataires tous les matins.

OpenRig change la donne en traitant les agents comme une vraie infrastructure.

Le vrai problème des workflows actuels

Aujourd’hui, chaque agent tourne dans son coin. Claude termine une tâche, GPT-4 arrive ensuite sans rien savoir de ce qui vient de se passer. Pas de mémoire partagée, pas d’identité persistante, pas d’équipe au sens propre.

Pour des micro-tâches, ça passe. Mais dès qu’on construit un vrai projet, on a besoin de :

• Une identité stable sur plusieurs jours ou semaines
• Une connaissance commune entre agents
• Des choix d’architecture qui survivent aux redémarrages
• Une coordination fluide quand le nombre d’agents augmente

Sans couche d’orchestration, tout s’effondre dès que la complexité grimpe.

Le concept de « rig » : une topologie définie en YAML

OpenRig emprunte une idée à l’infrastructure-as-code : le rig. Il s’agit d’un fichier YAML qui décrit comment les agents s’organisent et communiquent.

Ce n’est pas une simple liste. C’est un graphe. Les agents sont regroupés en pods qui partagent du contexte. Les pods sont reliés par des liens définis qui indiquent qui parle à qui. L’ensemble peut être sauvegardé, restauré, versionné.

Un seul fichier, une seule commande, et toute l’équipe redémarre dans l’état exact où elle s’était arrêtée.

pods:
  orchestration:
    agents:
      - lead (Claude Opus)
      - coordinator (Claude Sonnet)
  
  development:
    agents:
      - implementation (Claude Code)
      - review (Codex)
  
  research:
    agents:
      - explorer-1, explorer-2, explorer-3

Ce que ça change concrètement

Identité persistante

Un agent garde son rôle et sa mémoire d’une session à l’autre. Quand sa fenêtre de contexte est pleine, il bascule vers une nouvelle session en emportant tout son état. Il ne redémarre pas : il reprend.

Mémoire partagée

Dans un même pod, les agents peuvent externaliser et échanger leur état. Les décisions d’architecture, les patterns de code, les choix de design s’accumulent au lieu de disparaître à chaque redémarrage.

Un seul point de pilotage

Tout se pilote depuis une seule interface. On peut superviser l’ensemble de la flotte depuis un téléphone via Claude Remote Control. Pas besoin de jongler entre plusieurs outils.

Exemples d’usage déjà en production

• Revue croisée : deux agents analysent chaque pull request selon des angles différents.
• Cluster de recherche : quatre agents explorent un problème en pair-à-pair et partagent leurs découvertes.
• Renforcement de sécurité : des agents attaquent, d’autres corrigent, un observateur documente.
• Refactoring continu : le travail tourne la nuit pendant que l’équipe dort.
• Agent qui gère Vault : un agent administre HashiCorp Vault pour toute l’équipe.

Pourquoi ça compte pour l’architecture logicielle

Dès qu’on passe de « tester un agent » à « livrer du code en production », l’hypothèse « on peut tout jeter après chaque tâche » ne tient plus. Avec OpenRig :

• La connaissance s’accumule vraiment
• On évite de répéter les mêmes explications
• Chaque agent peut se spécialiser sans empiéter sur les autres
• Le travail asynchrone devient viable

Démarrer sans repartir de zéro

OpenRig propose un mode découverte (rig discover) qui analyse les sessions tmux ou existantes et génère automatiquement une première version du fichier YAML. On formalise ce qui fonctionne déjà.

Le reste se fait en ligne de commande : boot, snapshot, restore, visualize.

Open source et sans clé API supplémentaire, OpenRig s’intègre dans les pratiques déjà utilisées pour l’infrastructure : tout est défini, versionné, restaurable.

Votre réseau d’agents mérite d’être traité comme une infrastructure. OpenRig rend cela possible.