Workshop#
Une méthode de suivi pour travailler avec un agent IA. Son sujet est simple : ce qu’un agent doit lire pour être utile, et ce qu’une session doit laisser pour que la suivante reparte avec le bon contexte.
Son vocabulaire vient du développement logiciel — dépôt, commit — mais la méthode parle seulement de fichiers et d’ordre de lecture.
Six situations#
Elles paraissent différentes. En réalité, c’est le même problème.
D’un projet à l’autre, vous gardez les mêmes habitudes. Une manière de nommer, un format de date, une règle d’écriture. Rien n’est écrit, parce que cela vous semble évident. L’agent redemande, ou choisit autre chose, et la même correction revient.
Certaines règles ne valent que pour un seul projet. L’un tourne sur PostgreSQL, l’autre sur une base locale. Les types diffèrent, les migrations aussi, et ce qui a été décidé d’un côté n’a pas de raison de valoir de l’autre. Pourtant cela y revient, parce que la portée de la règle n’était pas claire.
Vous arrêtez quinze jours. À la reprise, les fichiers sont là. Les raisons, non. Ce qui a déjà été essayé puis écarté ne laisse pas de trace, et c’est exactement ce qui revient.
Vous revenez sur une décision prise trois semaines plus tôt. Les deux décisions se défendent, mais elles ne tiennent pas ensemble, et rien ne les met face à face. Vous aviez la vue d’ensemble ; l’agent, non.
Vous avez écrit vos conventions, mais l’agent ne les lit pas. Le fichier existe, il est à jour, il est bon — mais l’agent ne l’a pas lu, et rien ne vous l’a signalé.
Le suivi devrait être à jour, mais il est toujours remis à plus tard. La session a été longue, le travail est fait, et la mise à jour attend demain. Demain ne la fait pas non plus ; au bout de quelques reports, le suivi ne dit plus la même chose que le disque, et on cesse de le lire.
Ce n’est pas un problème de discipline. C’est un problème d’organisation de l’écrit : pas de périmètre clair, pas de place fixe, pas de garantie de lecture, pas de mécanisme d’entretien.
Où Workshop se place#
Ce que vous faites avec un agent ne change pas : vous demandez, il répond, il écrit, il explique. Workshop n’est pas l’agent, et n’en remplace aucun. Le vôtre reste celui que vous avez choisi. La méthode demande seulement qu’il puisse lire et écrire les fichiers d’un dossier que vous lui désignez. Et si le mot même d’agent reste flou, son fonctionnement est décrit à part.
Workshop ne remplace pas non plus votre fichier d’instructions — AGENTS.md, ou le nom propre à
votre outil. Ce fichier relu au démarrage est le premier niveau. Workshop prend le relais quand un
seul document ne suffit plus. Tant que tout tient dans un fichier, cela fonctionne. Puis le coût de
lecture monte, et les contradictions apparaissent. La méthode répond en découpant, en disant quand
lire quoi, et en donnant un protocole d’entretien. Résultat : l’agent peut voir qu’une décision
prise aujourd’hui contredit une autre plus ancienne, parce qu’il a lu les deux dans la même
session.
Un agent est un modèle et son harnais — la connaissance générale, et le programme qui lui donne ses accès. Trois couches se superposent, chacune apportant ce qui manque à la précédente, et Workshop est la dernière :
| Couche | Ce qu’elle apporte | Ce qui lui manque |
|---|---|---|
| Le modèle | Une connaissance générale : langages, outils, solutions éprouvées | Votre situation, et la date du jour |
| Le harnais | L’accès à vos fichiers, l’exécution, un périmètre borné | Ce qui, dans ces fichiers, fait autorité |
| Workshop | Où l’agent se trouve : ce qui existe, ce qui est ouvert, ce qui a été décidé et pourquoi | Toute capacité d’agir — ce sont des documents |
Les deux premières lignes forment l’agent. Workshop n’en fait pas partie. Il fournit des documents à lire ; il n’ajoute aucune capacité. Le choix de l’agent vous appartient, et l’installation dit la seule chose que la méthode attende de lui.
Quatre manques, quatre mécanismes#
Tout part d’un fait simple : ce qui n’est pas écrit n’existe pas pour l’agent. Votre mémoire ne peut pas servir de source : elle n’est pas accessible depuis l’endroit où le travail se fait. Écrire est donc nécessaire. Mais cela ne suffit pas. Les quatre manques ci-dessous disent pourquoi, et chacun a son mécanisme.
Un périmètre. Tout écrit a une portée, et son emplacement la déclare. Ce qui vaut pour tous vos travaux — une façon de nommer, des conventions techniques, la manière dont un agent doit s’adresser à vous — va dans un corpus transverse. Le reste appartient à un atelier, c’est-à-dire une unité de travail avec son propre cadrage. Une session ouverte sur un atelier ne lit que ce cadrage-là. Rien ne passe d’un atelier à l’autre sans message explicite.
Une place assignée. Ce qui existe et fonctionne, ce qui est ouvert, ce qui est volatil, ce qui est terminé : quatre états, quatre documents, et un élément vit dans exactement l’un d’eux. Le même fait n’a donc pas plusieurs copies qui finissent par diverger.
Une garantie de lecture. Un seul fichier se lit sans condition : la carte. Elle dit ce qui existe et dans quel cas lire le reste — « seulement si vous écrivez du SQL », « seulement avant de clore une session ». La décision se prend donc avant d’ouvrir un fichier, parce qu’un fichier ouvert coûte déjà du contexte ; les règles de lecture disent comment la carte et les fichiers se répondent. Le corpus peut ainsi grandir sans alourdir chaque démarrage.
Quelqu’un pour le porter. Les règles de clôture — quoi enregistrer, dans quel fichier, dans quel ordre — sont assez précises pour être exécutées sans improvisation. L’agent écrit, range, contrôle et enregistre en fin de travail, sans qu’une session entière y passe. Le cadrage est donc entretenu au fil du travail, au lieu de dépendre d’un effort de fin de journée. La relecture et les décisions restent à votre charge, et le partage exact est détaillé à part.
Workshop tient dans cela : des emplacements, une carte, un protocole — des fichiers que votre agent lit et entretient, pas un outil de plus.
Ce qui vient en plus#
Deux effets utiles s’ajoutent, au-delà du seul démarrage de session.
Ce qui a coûté à apprendre ne se perd plus aussi facilement. Un garde-fou — la raison pour laquelle une chose ne doit plus être refaite de telle façon — ne disparaît pas avec le travail qui l’a produit : il quitte la liste de l’ouvert et rejoint ce qui fait autorité. Un sujet fermé garde aussi le récit de ce qui a été essayé, puis écarté, et pourquoi.
Écrire aide aussi à clarifier ce qui n’est pas encore tranché. Un sujet dont le raisonnement ne tient pas sur une ligne obtient son propre document, et il peut l’obtenir avant toute décision : chaque document de forme longue porte son statut, de l’idée en examen jusqu’à la décision arrêtée. Poser une idée encore floue devant un agent qui a lu vos documents la met à l’épreuve : ce qui ne tient pas se voit, ce qui manque se nomme, et ce qui reste à trancher est marqué comme tel.
Ce que cela vous demande#
Les contreparties doivent se lire avant d’adopter la méthode.
- Du temps de lecture à chaque démarrage. Il est mesuré et le contrôle le rapporte, ce qui l’empêche de dériver. Il n’est jamais nul.
- De l’écriture. L’agent en fait beaucoup ; vous relisez et vous arbitrez.
- Un dépôt git, fortement conseillé. Le dossier qui porte ces documents est créé comme un dépôt, et l’installeur s’en charge : vous n’avez pas à savoir vous en servir pour en bénéficier. Ce qu’il apporte est double — l’historique porte le récit factuel, ce qui autorise le fichier de reprise à rester court, et le contrôle vous prévient tant que rien n’est sauvegardé hors de cette machine.
Les bornes#
Deux compromis, une fois en place#
Ils apparaissent à l’usage. Ils ne se corrigent pas après coup ; ils se choisissent.
- Des règles, pas des mécanismes. Une règle lue au début d’une session et due trois heures plus tard perd face au cas concret. Là où le coût d’un oubli est réel, il faut un mécanisme — un contrôle qui échoue — et savoir lequel des deux vous tient réellement.
- Deux dépôts au lieu d’un. Le cadrage vit hors des dépôts de code, ce qui le protège du publish et le prive du même geste que le code.
Ce que la méthode ne décide pas#
La méthode déclare des emplacements ; vous les remplissez.
Votre identité, la façon dont un agent doit s’adresser à vous, vos conventions techniques, l’arborescence de vos dépôts, votre outil : rien de cela n’est imposé par la méthode.
La frontière est simple : qu’il existe un corpus de conventions transverses, lu par déclencheur avant d’écrire ce genre de code relève de la méthode. Ce que ce corpus dit relève de vous.
Votre instance a donc une place précise : la méthode décide quand ses fichiers se lisent ; leur contenu vous appartient.
Continuer#
- Comment fonctionne un agent — ce qu’il lit, retient et oublie. À lire si ce fonctionnement ne vous est pas familier.
- En pratique — l’installation, le mode d’emploi, la construction du corpus. À lire le jour où vous l’essayez.
- Dans le détail — les documents, les règles de lecture, la session, le contrôle. Se lit en travaillant, pas avant.
Aller plus loin#
Le besoin auquel Workshop répond est étudié ailleurs. L’écosystème le découpe souvent en deux
questions : ce qui survit d’une session à l’autre — la mémoire d’agent, agent memory — et ce qui
est rechargé dans la session suivante — le context engineering. Workshop relie les deux : les
quatre documents portent la première partie, la carte et ses conditions de lecture portent la
seconde, et le protocole de clôture les tient ensemble. D’autres réponses existent — le Memory Bank
de Cline, la convention AGENTS.md, le développement dirigé par les spécifications. Ici, Workshop
repose sur trois choix : la portée par atelier, la lecture conditionnelle et l’entretien confié à
l’agent.
La méthode est publiée sous licence MIT : github.com/SharpPyxis/SharpPyxis.Workshop. Elle ne redistribue aucun composant tiers ; le lint et l’installeur n’utilisent que la bibliothèque standard de Python.
method/organization.md
est le seul fichier à lire en entier et dans l’ordre ; tous les autres sont atteints depuis lui quand
leur déclencheur s’applique. Les lire tous d’avance ferait perdre exactement le budget que la
méthode cherche à protéger.
sample/ est un exemple
complet : le cadrage d’un atelier fictif — atlas, todo, handoff et récit d’un chantier fermé — sans
nom de produit ni de personne.
État : en construction, déjà en usage. Les dépôts d’où elle vient tournent déjà dessus : plusieurs
ateliers, chacun avec son cadrage, qui lisent organization.md au démarrage de chaque session,
depuis une copie posée exactement comme décrit plus haut.