Agents · méthode
Jarvis, le contexte qui suit
Un espace de travail versionné qui donne à chaque session d'agent la même mémoire : qui je suis, ce que je construis, ce qui a été décidé, ce qui reste à faire. Une base tierce, reprise et taillée à ma façon depuis mai 2026.
- État
- en usage quotidien depuis mai 2026
- Stack
- Markdown, commandes de session, journal tenu par l'agent, un skill documenté par projet
- Depuis
- 2026
- Preuves
- journal tenu par l'agent depuis mai 2026, contexte en sept parties, une fiche de projet par outil
Le problème
Un assistant de code repart de zéro à chaque conversation. Il faut lui réexpliquer qui l’on est, ce qu’on construit, pourquoi on a choisi telle bibliothèque et refusé telle autre. Au dixième projet, on passe plus de temps à raconter le contexte qu’à avancer, et les décisions déjà prises se rediscutent à chaque session.
Ce que j’ai construit
Jarvis est un dossier, pas un programme. Il vient d’un kit partagé au sein d’une communauté ; je l’ai installé fin mai 2026 et je n’ai cessé de le réécrire depuis.
Au sommet, un fichier d’identité que l’agent charge automatiquement : qui il assiste, comment communiquer (français direct, pas de jargon, pas de tirets longs), et neuf principes d’opération, dont quatre fondations et cinq règles de décision : le problème avant la solution, la validation avant le code, le coût de maintenance pesé, l’itération plutôt que la perfection, les compromis explicites.
En dessous, un contexte en sept parties : qui je suis, ce que je fais, mes objectifs à court et long terme, les projets en cours, mes outils et préférences, un playbook d’exécution (ce qu’on vérifie avant de coder, avant d’ajouter une dépendance, comment rendre compte), et les règles pour tout ce qui est publié.
Un journal chronologique, écrit par l’agent lui-même sur commande et jamais à la main, garde la trace de chaque étape structurante. Un dossier d’import reçoit les documents à analyser ; c’est là que sont archivés les deux audits de ce site. Et chaque outil que je fabrique a sa fiche, lisible par un agent : architecture, pièges connus, procédures, décisions prises.
Une session commence par une commande qui charge tout cela. Elle se termine, quand quelque chose a changé, par une mise à jour proposée du contexte. L’agent a pour consigne de la proposer lui-même dès qu’il détecte un changement structurant.
Ce que ça raconte
- La mémoire est un livrable. Le contexte est versionné, relu, corrigé, comme du code. C’est lui qui rend les sessions reproductibles.
- Trois rôles distincts. Jarvis donne le contexte aux sessions de travail. Hermes surveille ce qui tourne. Le second cerveau garde ce que j’apprends. Aucun des trois ne fait le travail des deux autres.
- Une base reprise, pas une invention. Le kit de départ n’est pas de moi. Ce qui l’est : le playbook, les règles de publication, les fiches par projet, et l’habitude de faire auditer mon propre travail par deux agents distincts avant de le publier.
Ce que j’ai vérifié
- Signal observé : des décisions rediscutées à chaque session, et du contexte réexpliqué à chaque projet.
- Test ou contrôle : chaque session part du même contexte chargé ; le journal est relu à froid avant chaque mise à jour importante.
- Résultat : des sessions qui reprennent un projet là où la précédente l’a laissé, y compris après plusieurs semaines.
- Limite actuelle : un contexte non mis à jour reste faux jusqu’à la prochaine relecture ; l’agent le propose, mais c’est moi qui valide, et il m’arrive d’oublier.