OpenRig : préserver le contexte entre deux sessions

L'essentiel à retenir

Un agent de code peut avancer pendant une session, puis imposer une reconstruction manuelle le lendemain. Le terminal a été fermé. La machine a redémarré. La conversation ne reprend plus. Il faut retrouver le mandat, les décisions, les fichiers touchés et le prochain geste utile.

OpenRig traite cette rupture comme un problème de continuité opérationnelle. Une « seat » garde une identité et une adresse stables, même lorsque la conversation active change. La commande rig down --snapshot capture l’état du rig. rig up <name> restaure ensuite le dernier snapshot et qualifie le résultat de chaque nœud : resumed, fresh-primed, awaiting-decision, attention_required ou failed.

Cette liste compte davantage qu’une promesse vague de mémoire. Elle dit si l’agent a réellement repris, s’il repart avec un contexte préparé, s’il attend une décision ou si la restauration a échoué. La continuité n’est donc pas magique. Elle devient observable.

Le bon usage consiste à tester la reprise avant d’en dépendre : interrompre volontairement une session, restaurer le rig, examiner chaque état et vérifier ce que l’agent sait encore. Puis nettoyer le contexte conservé. Une mémoire persistante peut éviter une reconstruction. Elle peut aussi prolonger une mauvaise hypothèse. Garder. Vérifier. Élaguer.

Le problème que ça résout

La plupart des démonstrations d’agents de code commencent au lancement. Le prompt part, les outils s’activent, le code change. En production, la question difficile arrive plus tard : que reste-t-il après l’interruption ?

Une conversation contient plusieurs couches mêlées. On y trouve l’objectif initial, les contraintes du dépôt, les décisions prises en cours de route, les tentatives abandonnées, les résultats de commandes et une intention encore inachevée. Si la session disparaît, le code présent sur disque ne suffit pas toujours à expliquer la suite. Un diff montre ce qui a changé. Il ne dit pas forcément pourquoi l’agent a écarté une option, quel contrôle reste à lancer ou quelle question bloque l’avancement.

La reprise manuelle paraît simple : rouvrir un agent et lui résumer le travail. Sauf que le résumé devient un nouveau point de défaillance. Une décision est omise. Une hypothèse provisoire se transforme en règle. Un fichier important n’est pas cité. La personne qui relance croit transmettre le contexte ; elle transmet sa reconstruction du contexte.

Le redémarrage crée un second piège : confondre processus vivant et travail reprenable. Un terminal persistant peut conserver un programme actif. Il ne garantit pas que l’agent possède encore une conversation exploitable, que son identité reste claire ni que l’état restauré correspond au dépôt actuel. Maintenir une fenêtre ouverte n’est pas encore organiser une reprise.

OpenRig sépare donc l’identité de la conversation. La seat reste l’adresse stable du travail. La conversation qui l’occupe peut être reprise ou remplacée. Le contexte produit à cette adresse peut rester disponible. Cette distinction permet de poser une question précise après une interruption : cette seat a-t-elle retrouvé sa conversation, reçu un contexte neuf ou besoin d’une décision ?

Le gain recherché n’est pas de rendre l’agent immortel. Il est d’éviter le faux redémarrage, celui où tout semble reparti alors que personne ne sait ce qui a été perdu.

Pour une PME belge de 10 à 50 personnes, le sujet devient concret dès qu’un développement s’étale sur plusieurs jours avec peu de personnes capables de reprendre le dossier. Le dirigeant ou le responsable de produit n’a pas besoin d’administrer lui-même les sessions. Il doit exiger un point de reprise vérifiable : objectif encore valable, changement présent dans le dépôt, contrôle restant et décision qui réclame son arbitrage. L’outil est utile s’il réduit le temps passé à reconstituer ces quatre éléments. Sinon, un suivi écrit plus simple suffit.

Ce que c'est concrètement

OpenRig est un logiciel open source sous licence Apache 2.0, écrit en TypeScript. Il fonctionne comme un daemon local avec une CLI, une interface terminal, un serveur MCP, une base SQLite et des sessions tmux. Le projet prend en charge des agents de code, dont Claude Code et Codex, dans un système qui conserve leur identité, leur état et du contexte adressable.

La brique utile ici est la seat. Elle possède un rôle et une adresse stables, par exemple dev-build@starter. La conversation peut changer sans effacer cette adresse ni le contexte qui lui est associé. Après une coupure, on ne demande donc pas « quelle fenêtre faisait ce travail ? ». On revient vers la même seat et on examine son état réel.

Le mécanisme de snapshot formalise l’arrêt. rig down --snapshot capture l’état complet annoncé par le README. La restauration se fait avec rig up <name>, à partir du dernier snapshot. OpenRig rapporte alors un résultat par nœud :

• resumed : la conversation d’origine a pu reprendre ;
• fresh-primed : une nouvelle conversation a été lancée avec un contexte préparé ;
• awaiting-decision : la conversation d’origine ne peut pas reprendre et le système attend le choix d’un départ neuf avec --fresh ;
• attention_required : une intervention est nécessaire avant de considérer la reprise comme terminée ;
• failed : la restauration du nœud a échoué.

Ces états empêchent de réduire la reprise à un voyant vert global. Un rig peut revenir sans que chaque seat revienne de la même manière. L’une reprend sa conversation. Une autre redémarre avec un contexte préparé. Une troisième attend une décision. Le système expose cette différence au lieu de la cacher derrière le mot « restauré ».

Le contexte reste distribué. Chaque agent conserve sa propre fenêtre. OpenRig peut projeter des éléments de guidance, des ressources et du contexte dans l’espace de travail, mais il ne transforme pas toutes les conversations en mémoire unique. C’est une limite utile. La continuité consiste à remettre le bon agent devant les bons éléments, pas à lui verser toutes les archives du projet.

L’interface permet aussi d’inspecter l’état des seats, leur runtime, leur contexte et leur activité. Les sessions tmux sous-jacentes restent accessibles. On peut donc croiser la déclaration de reprise avec ce que le terminal et le dépôt montrent réellement. La persistance devient un objet à contrôler, pas une croyance.

Comment s'en servir

Commencez par un scénario d’interruption, pas par un scénario de performance. Le test doit répondre à une question : après un arrêt réel, combien de travail faut-il pour retrouver une situation compréhensible et sûre ?

Étape 1 : définir ce qui doit survivre

Écrivez le minimum nécessaire à la reprise avant le lancement : objectif courant, périmètre autorisé, état du dépôt, décision en attente, artefact produit et prochaine action prévue. Ce contenu doit rester court. Une reprise exige un point d’appui, pas la transcription complète de tout ce que l’agent a pensé.

Séparez aussi les informations stables des informations temporaires. Les conventions du dépôt et les contraintes durables peuvent suivre la seat. Une hypothèse de débogage, un chemin exploré puis abandonné ou une erreur liée à un état ancien doivent pouvoir disparaître. Persister ne signifie pas sanctuariser.

Étape 2 : donner une identité stable au travail

Utilisez une seat comme adresse durable. Son nom doit permettre de retrouver le travail après plusieurs jours sans dépendre du titre d’un terminal ou du souvenir de l’opérateur. L’objectif n’est pas de dessiner une organisation complète. Il est d’avoir un point de reprise qui reste le même lorsque la conversation change.

Notez l’identifiant du rig et la seat concernée dans le suivi du travail. Après une interruption, l’équipe doit savoir où regarder avant de tenter un nouveau prompt. Deux relances concurrentes sur le même problème recréent précisément la confusion que la persistance devait éviter.

Étape 3 : créer un snapshot à un moment lisible

Lancez rig down --snapshot lorsque l’état du travail peut encore être expliqué. Avant l’arrêt, vérifiez que les changements utiles sont présents sur disque, que le blocage éventuel est formulé et que la prochaine décision est identifiable.

Un snapshot n’améliore pas le contenu qu’il capture. S’il fige une session confuse, il préservera surtout la confusion. Le bon moment se situe après une mise au point courte : ce qui est fait, ce qui reste ouvert et ce qui ne doit pas être repris comme vérité.

Étape 4 : restaurer et lire chaque état

La personne chargée de l’exploitation relance avec rig up <name>, puis examine le résultat nœud par nœud. Le responsable de la PME n’a pas à interpréter chaque détail technique : il doit recevoir un compte rendu qui distingue reprise effective, nouveau départ, décision attendue et échec. Ne traitez pas tous les états comme des synonymes de succès.

Avec resumed, vérifiez que la conversation retrouvée correspond au dépôt actuel et qu’elle connaît encore la prochaine action. Avec fresh-primed, demandez à la nouvelle conversation de reformuler son mandat, les faits hérités et la première vérification qu’elle compte effectuer. Ce contrôle révèle vite un contexte trop pauvre ou contradictoire.

awaiting-decision impose un choix explicite. La conversation d’origine ne peut pas reprendre ; il faut décider si une seat neuve doit repartir avec --fresh. Avant de le faire, identifiez ce qui sera conservé comme contexte et ce qui sera abandonné avec l’ancienne conversation.

Pour attention_required, lisez le besoin d’intervention avant de renvoyer du travail. Pour failed, arrêtez la reprise automatique et inspectez la cause. Relancer à l’aveugle peut créer une seconde exécution alors que la première a déjà modifié le dépôt.

Dans une petite entreprise, traduisez ce contrôle en règle de gestion : aucun travail repris n’est présenté comme « en cours » tant que l’état de la seat et le dépôt ne concordent pas. Toute décision produit, budgétaire ou liée au périmètre remonte à la personne nommée pour trancher. L’opérateur contrôle la mécanique. L’entreprise garde la décision.

Étape 5 : provoquer une vraie interruption

Fermez volontairement une session pendant le pilote. Redémarrez la machine ou le daemon dans un environnement de test si votre usage doit survivre à ce cas. Restaurez ensuite le rig et vérifiez trois choses : l’identité de la seat est-elle intacte, l’état annoncé est-il compréhensible, et le prochain geste proposé correspond-il aux artefacts présents ?

Demandez à l’agent repris de citer les fichiers qu’il pense avoir modifiés, le contrôle restant et la décision ouverte. Comparez sa réponse au dépôt et au suivi du travail. Une reprise réussie se prouve par cohérence, pas par une phrase rassurante dans le terminal.

Étape 6 : nettoyer après la reprise

Une fois le travail terminé, retirez du contexte ce qui n’aidera pas la prochaine session. Gardez les décisions encore valides, les contraintes stables et les procédures vérifiées. Supprimez les hypothèses réfutées, les journaux devenus inutiles et les instructions liées à une version dépassée du dépôt.

Cette hygiène évite l’effet millefeuille. Sans elle, chaque snapshot augmente le volume à relire et la probabilité qu’une ancienne consigne contredise l’état présent. La continuité gagne quand le contexte survit. La fiabilité gagne quand une partie du contexte sait mourir.

Ce que ça coûte vraiment

OpenRig est open source, mais la persistance consomme du stockage, du calcul, des appels aux fournisseurs d’agents et du temps humain. Les sessions, l’état du daemon, la base locale, les snapshots, les fichiers de contexte et les intégrations doivent être exploités comme un système. Rien de tout cela ne devient gratuit parce que la licence permet d’utiliser le code.

Le premier coût est la duplication. Une reprise fresh-primed peut réinjecter des éléments déjà présents dans le dépôt ou dans la nouvelle fenêtre. Plus le contexte préparé est long, plus le redémarrage consomme avant même que l’agent recommence à agir. Conserver toute la conversation par peur de perdre une information revient souvent à payer pour relire du bruit.

Le deuxième coût est l’entretien. Une seat stable accumule du contexte écrit, des décisions et des traces. Quelqu’un doit réviser cet ensemble. Sinon, l’identité reste stable tandis que sa compréhension du projet dérive. La persistance amplifie autant les bonnes consignes que les mauvaises.

Le troisième coût est opérationnel. Le README indique qu’OpenRig écrit de l’état d’instance, des intégrations de fournisseurs et des fichiers dans l’espace de travail. Il peut aussi écrire des réglages de confiance et des hooks exécutables. Le projet recommande d’examiner ce qui change et de sauvegarder les fichiers concernés avant le premier usage. Une restauration d’agents ne remplace pas la sauvegarde du dépôt ni celle de la configuration locale.

Il faut enfin surveiller les reprises partielles. Un état global qui semble sain peut masquer une seat en attention_required ou failed. L’opérateur doit lire le détail, rapprocher les états des artefacts et décider s’il faut poursuivre. La persistance déplace une partie du coût : moins de reconstruction improvisée, davantage de discipline autour des snapshots, des contrôles et du nettoyage.

Le calcul reste sobre. Si les interruptions sont rares et que le contexte se reconstitue en quelques minutes, la couche peut coûter plus qu’elle ne rapporte. Si le travail traverse régulièrement des sessions, des redémarrages ou des changements de conversation, rendre la reprise explicite peut éviter des heures perdues et des erreurs discrètes. Mesurez votre reconstruction, pas la beauté du tableau de bord.

Pour qui ce n'est pas

OpenRig est excessif pour une tâche courte, terminée et vérifiée dans la même session. Capturer puis restaurer un état que personne ne réutilisera ajoute une procédure sans bénéfice. Un fichier de notes et un dépôt propre suffisent souvent.

Il ne répond pas non plus au besoin limité de garder une commande active après une déconnexion. Tmux peut maintenir un processus. OpenRig ajoute une identité de seat, du contexte adressable, un état de coordination et une logique de restauration. Si ces éléments ne servent pas, choisissez l’outil plus simple.

Évitez aussi la persistance si l’équipe refuse de nettoyer le contexte. Une mémoire jamais révisée devient une accumulation d’instructions dont personne ne connaît encore la validité. Le danger n’est plus l’oubli. C’est la confiance accordée à une consigne périmée parce qu’elle a survécu plusieurs redémarrages.

Même réserve lorsque le dépôt ne permet pas de vérifier l’état repris. Sans diff lisible, sans commandes de contrôle et sans suivi minimal du travail, vous ne pourrez pas distinguer une vraie continuité d’un agent qui improvise une histoire cohérente après le redémarrage.

Enfin, OpenRig ne convient pas à une organisation qui attend une reprise garantie de chaque conversation. Les états fresh-primed, awaiting-decision, attention_required et failed existent précisément parce que toutes les restaurations ne produisent pas resumed. L’outil rend l’incertitude visible. Il ne l’abolit pas.

Le critère d’adoption tient dans une question : perdez-vous assez souvent le fil entre deux sessions pour justifier un mécanisme de reprise explicite ? Si oui, testez l’interruption avant de célébrer la persistance. Si non, gardez votre système léger.

Source : https://github.com/mvschwarz/openrig

FAQ

OpenRig conserve-t-il toute la conversation d’un agent ?

OpenRig peut reprendre une conversation ou lancer une conversation neuve avec un contexte préparé, selon le résultat de la restauration. Le README ne promet pas que chaque conversation reprendra à l’identique. L’état retourné indique ce qui s’est réellement passé pour chaque nœud.

Quelle différence entre resumed et fresh-primed ?

resumed indique que la conversation d’origine a repris. fresh-primed signifie qu’une nouvelle conversation a été lancée avec du contexte préparé. Dans le second cas, vérifiez que l’agent reformule correctement le mandat et confronte le contexte hérité au dépôt actuel.

Que faire avec un état awaiting-decision ?

La conversation d’origine ne peut pas reprendre. Le système attend une décision avant un départ neuf avec --fresh. Examinez d’abord les artefacts, le blocage et le contexte à transmettre afin de ne pas transformer une impossibilité de reprise en redémarrage aveugle.

Un snapshot OpenRig remplace-t-il une sauvegarde Git ?

Non. Le snapshot vise l’état du rig et sa restauration. Le dépôt, les branches, les changements locaux et la configuration de la machine doivent garder leurs propres mécanismes de sauvegarde et de vérification.

Comment éviter qu’un contexte persistant devienne obsolète ?

Révisez-le après chaque travail important. Conservez les contraintes stables et les décisions encore actives. Retirez les hypothèses réfutées, les procédures dépassées et les détails de conversation qui n’aident plus à décider ou à agir.

---

Publié le 17 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.