Cas de travail augmenté par l'IA
Les preuves de la famille : un cas par projet réel mené avec la méthode, disant ce qu'il a coûté et produit. Allers-retours, temps, où chaque erreur a été attrapée (par une vérification, par le modèle, par la personne), quelles décisions sont parvenues à la personne et combien de fois la même. Les autres membres disent comment travailler ; celui-ci consigne ce qui s'est passé quand quelqu'un l'a fait.
Cette page en anglais : README.md. Les deux versions suivent le même état.
État (2026-11-03) : version 0.1.0. Construit : la première revue (une première passe, 42 sources) avec sa référence nommée, six principes sur une carte, cinq vérifications et 32 tests unitaires, la forme d'un cas, et deux cas avec un programme qui prend leurs comptes : la journée où six dépôts ont été bâtis à la fois, le 2026-10-29, et la nuit où huit dépôts ont reçu leur premier travail, le 2026-11-02. Ouvert : il y a deux cas et aucun témoin, les questions arrivées jusqu'à la personne sont comptées à la main, et le programme ne sait pas compter les arrêts, les reprises ni les poussées. Le nom reste provisoire. Ce n'est ni une norme officielle, ni une étude relue par des pairs, ni un résultat nouveau.
Comment il est fait : avec Claude, un assistant IA d'Anthropic, sous la direction du mainteneur, comme reader-ergonomics. Les corrections sont bienvenues sous forme d'issues.
L'adopter
Dix minutes, sans lire la revue. La forme générale est la section « Take your own version » de reader-ergonomics ; la voici pour écrire un cas.
Épingler la norme par son commit, pour que ses vérifications ne changent pas sous vos pieds :
git clone https://github.com/Tewf/reader-ergonomics && git -C reader-ergonomics checkout 2e5b6f0(v1.21.0).Copier ce dont vous avez besoin, une fois : la forme shapes/case.md. Puis les cinq vérifications de checks/local/, avec leur aide
_cases.py, dans lechecks/local/de votre dépôt. Enfin measures.py, qui prend les comptes d'une journée dans l'historique git. Les copies sont à vous. Notez le commit d'où vous les avez prises.Configurer avec un
checks/config.tomlqui étend la norme et recopie l'entréecasede[shape_conformance]de celui-ci :extends = "reader-ergonomics"Écrire et lancer. Mettez chaque cas dans
cases/<date>-<slug>/README.mdavec une ligne Shape qui renvoie à la forme, prenez ses comptes avecpython3 measures.py --root DIR --day AAAA-MM-JJ, puis lancezpython3 reader-ergonomics/checks/run.py .Désaccord : ouvrez une issue sur ce dépôt, avec la preuve. Une règle de la norme elle-même va aux issues de reader-ergonomics ; une préférence de votre lecteur va dans un style de lecteur, comme dérogation.
Où il se place
Graphviz source
// Where ai-augmented-cases sits: what it measures, who reads it. Colours: AI-augmented family green,
// reader-ergonomics family blue, each named in its box; this repository has the thick border.
digraph where_it_sits {
graph [rankdir=TB, nodesep=0.45, ranksep=0.5, bgcolor="white", pad=0.2, fontname="Inter"];
node [shape=box, style="rounded,filled", fontname="Inter", fontsize=13, margin="0.2,0.1", penwidth=1.5, fontcolor="#1F2328"];
edge [fontname="Inter", fontsize=11, color="#3D434B", fontcolor="#55575F", penwidth=1.3, arrowsize=0.8];
F [label=<<b>ai-augmented-foundations</b><br/><font point-size="11" color="#55575F">AI-augmented family: takes the cases as its data</font>>, fillcolor="#E6F2EA", color="#2E7D4F"];
C [label=<<b>ai-augmented-cases</b><br/><font point-size="11" color="#55575F">AI-augmented family: real projects, measured</font>>, fillcolor="#E6F2EA", color="#2E7D4F", penwidth=2.6];
AP [label=<<b>ai-augmented-project</b><br/><font point-size="11" color="#55575F">AI-augmented family: the method</font>>, fillcolor="#E6F2EA", color="#2E7D4F"];
AG [label=<<b>ai-augmented-agents</b><br/><font point-size="11" color="#55575F">AI-augmented family: several agents</font>>, fillcolor="#E6F2EA", color="#2E7D4F"];
P [label=<<b>reader-ergonomics-project</b><br/><font point-size="11" color="#55575F">reader-ergonomics family: the steps</font>>, fillcolor="#E8EEF8", color="#2F5DA8"];
F -> C [label=" reads"];
C -> AP [label=" measures"];
C -> AG [label=" measures"];
C -> P [label=" measures"];
}- Il mesure les membres : un cas nomme la version de la méthode avec laquelle il a été mené, par commit, et dit si le raisonnement est passé par reader-ergonomics-blueprint, le pont.
- Il obéit à reader-ergonomics (v1.21.0) et exécute ses vérifications en CI.
- Il ne pointe que vers le bas. ai-augmented-foundations lit les cas ; aucun cas n'en dépend. La carte de la famille est ai-augmented.
Périmètre
| Quoi | Pourquoi | |
|---|---|---|
| dedans | un rapport par projet : ce qui a été demandé, mené, produit, et ce que cela a coûté | les affirmations de la famille sur sa méthode reposent là-dessus, ou sur rien |
| dedans | les mesures : allers-retours, temps, où les erreurs ont été attrapées, décisions parvenues à la personne, faits écrits deux fois | ce que la méthode promet de réduire doit être compté |
| dedans | des mesures qu'un programme prend dans le seul historique d'un dépôt, pour qu'un cas se rejoue | un compte à la main est une affirmation ; un compte par programme est une vérification |
| dedans | la forme d'un cas, pour qu'un lecteur absent puisse s'y fier | un cas écrit après coup, par l'un de ses agents, a besoin de règles |
| dehors | la théorie du pourquoi | ai-augmented-foundations |
| dehors | la méthode elle-même | ai-augmented-project, reader-ergonomics-project |
| dehors | un cas au sujet confidentiel | il reste privé ; seules ses mesures peuvent être rapportées |
Ce que la revue a trouvé
La revue est dans evidence/case-reports (en anglais) : 42 sources, 34 formelles et 8 grises, en cinq étapes.
- Le nom du domaine diffère du nôtre. Un rapport écrit par ceux qui ont participé est un rapport d'expérience, pas une étude de cas : la norme communautaire de l'étude de cas l'exclut. Un cas ici est un rapport d'expérience avec des mesures de dépôt, et le dit (cadrage).
- Un historique trompe de façons connues. Un dépôt n'est pas un projet, les commits se déplacent et se réécrivent, et les gros commits n'ont pas la même intention. Dans le premier cas, 434 commits additionnés sur sept dépôts font 415 commits distincts, et 50 étiquettes font 6 publications sur l'hébergeur.
- Aucune étude ne compte ce que ce dépôt demande. Les études sur les agents de code mesurent surtout une tâche, une demande de fusion ou un projet. Les récits d'entreprises donnent sessions et coût. Aucune de la sélection ne compte les questions parvenues à une personne en une journée.
- La confiance repose sur la convention. Les guides sont bâtis sur d'autres guides et sur l'expérience ; aucune étude ne montre qu'une liste de contrôle rend un cas plus crédible. Le point faible de la liste pour un rapport de l'intérieur est la triangulation.
La référence
La liste de contrôle du lecteur de Runeson 2009, 12 points, lue avec les critères du rapport d'expérience d'ICSE 2003 et les normes d'étude de cas et de fouille de dépôts. Un cas répond à chaque point, tenu ou non avec une raison, et un programme prend tous les comptes qu'il peut ; un compte à la main est signalé (référence, fiche 0002).
Questions auxquelles la revue a répondu
- Dans le seul historique. Un programme peut prendre commits, fichiers, étiquettes et fiches de décision par jour. Il ne peut pas prendre les questions parvenues à la personne, ni distinguer un commit d'une unité de travail.
- Confiance. Ce qui est cité, compté et laissé de côté est dit dans le cas ; sa forme est shapes/case.md.
- Le premier cas. La journée du 2026-10-29 : 434 commits, 50 étiquettes, 47 fiches ; 16 décisions sont parvenues à la personne, comptées à la main.
- Comparaison. Il n'y a pas de témoin. Un cas se compare aux cas antérieurs de la méthode et à un contraste interne au cas ; le premier cas n'a pas d'antérieur, et le second ne se compare à lui que par nature.
- Le second cas. La nuit du 2026-11-02 : 33 commits sur huit dépôts, 16 fiches, aucune étiquette. 6 décisions sont parvenues à la personne, comptées à la main, et 5 sessions ont calé sur un changement de réseau. Le programme ne peut compter ni les messages de la personne, ni les calages, ni les retours, ni les poussées.
La carte
La norme compte six principes. Trois portent sur le comptage : imprimer la réserve à côté du compte (mesuré, descriptif), le travail distinct plutôt que les commits bruts (mesuré, descriptif) et un compte à la main est marqué (convention). Trois portent sur le rapport, tous de convention : le rapport d'un participant est un retour d'expérience, la liste du lecteur est suivie, et aucun modèle n'analyse les données. La forme est shapes/case.md ; les programmes sont dans checks/local/, et la fiche 0003 dit quels constats sont restés des constats.
Vérifier
git clone https://github.com/Tewf/reader-ergonomics && git -C reader-ergonomics checkout 2e5b6f0
python3 reader-ergonomics/checks/run.py chemin/vers/ce/depotLa CI exécute d'abord les tests unitaires des vérifications et du programme de mesures, puis les mêmes vérifications, à chaque push, et une exécution échoue à la première erreur (checks.yml). Chaque push sur master construit aussi le site, tewf.github.io/ai-augmented-cases (pages.yml).
Contenu
| Partie | Résumé |
|---|---|
| standard.md | la carte : six principes avec leurs niveaux de preuve et leurs vérifications |
| principles | un fichier par principe : énoncé, niveau, preuve, vérification, ce qu'il demande, pourquoi, limites |
| evidence | la revue derrière ce dépôt et sa bibliographie |
| shapes | la forme d'un cas, tirée de la référence, avec son tableau de mesures |
| checks | la configuration, les réponses, et les programmes de local/ avec leurs tests |
| cases | un dossier par projet réel : le rapport, le programme qui prend ses comptes, et les nombres de son exécution |
| decisions | une fiche par choix qui façonne ce dépôt, chacune ouvrant sur la décision en une phrase |
Licence
Code sous Apache License 2.0 ; prose sous CC BY 4.0. Réutilisez-le comme vous le souhaitez, en créditant ce dépôt ; CITATION.cff donne une citation si besoin.