Le matin où j'ai cru que c'était une seule journée

Samedi 16 mai, huit heures dix. Café tiède dans la tasse à tête de Françoise, héritée d'un anniversaire de bureau. Le tableau Sentry de la nuit affiche un point rouge isolé sur un cron à trois heures, et un message vocal de Catherine arrivé à sept heures cinquante — « Hum, ça bug. Mais c'est vite corrigé. » Sept mots dans son ton habituel, ni urgent ni inquiet, l'évidence d'une journée qui commence par un ticket à fermer avant les autres.

Catherine n'a presque jamais tort sur la première moitié de sa phrase, et elle a parfois tort sur la seconde. Le bug du jour, ce n'est pas un bug, ce sont quatre, et entre celui de huit heures et celui de dix-huit heures se loge une journée entière qui ressemble à une seule chose vue de loin, et à quatre choses très différentes vue de près. Nous avons tous tendance à compter les incidents par tickets, par messages, par sessions, ce qui revient à compter par symptômes. Les compter par hypothèses falsifiables, c'est en trouver quatre là où nous croyions n'en avoir qu'un.

L'autopsie qui suit n'est pas un cas d'école. C'est une journée ordinaire que j'aurais préféré finir à dix-neuf heures et que j'ai finie à vingt-trois, parce que sur le quatrième bug j'ai sauté le protocole que les trois premiers m'avaient pourtant réappris à respecter le matin même.

Bug numéro un, les signatures qui se dédoublent

Catherine remonte qu'un cours de l'antenne affiche, dans le PDF d'émargement, chaque élève signé deux fois. Le réflexe productif arrive avant la réflexion : « le formulaire double-poste sur double-clic, on ajoute une unique-constraint et on passe ». Quinze lignes de migration et c'est plié. Sauf que c'est faux.

Le skill /challenger impose un autre départ. Hypothèse en une phrase : « la jointure emargements ↔ seances ramène N×M lignes quand un cours a plusieurs séances générées pour la même date. » Une cause structurelle, pas un symptôme. Trois sondes pour réfuter, pas pour confirmer :

-- Sonde 1 — combien de séances pour ce cours, cette date ?
SELECT cours_id, date_seance, COUNT(*) AS n_seances
FROM seances
WHERE date_seance = '2026-05-16'
GROUP BY cours_id, date_seance
HAVING COUNT(*) > 1;
-- 4 cours touchés, 18 séances dédoublées (filtre année scolaire mal câblé)

La sortie réfute l'hypothèse initiale du double-clic et confirme un drift plus profond. Dix-huit séances apparaissent en double parce que le générateur de séances a filé deux passes avec un filtre getAnneeScolaire(date) mal câblé entre 2025-2026 et 2026-2027 sur les cours pivotant à la rentrée. Le fix qu'on aurait posé sur le formulaire n'aurait pas effacé une seule séance fantôme, il aurait juste empêché les futures doubles signatures, en laissant le PDF du jour gâté.

La sonde a coûté quatre-vingt-dix secondes. Le rollback qu'elle a évité, je l'estime à une bonne demi-heure de cycle commit-deploy-Sentry-Catherine-rappelle. Premier ratio de la journée, six pour un.

Bug numéro deux, les notes du formateur qui s'évaporent

Onze heures. Une formatrice signale, calmement, que les notes pédagogiques qu'elle saisit à la fin d'un émargement ne réapparaissent pas quand un autre formateur la remplace la séance suivante. Hypothèse de surface, séduisante : « le formulaire ne précharge pas les notes du précédent émargement ». Une ligne de useEffect aurait l'air d'un fix correct.

Hypothèse /challenger reformulée : « le champ notes_formateur est lié à l'identifiant utilisateur signataire, pas au cours ou à la séance, donc un remplacement par un autre signataire masque légitimement les notes saisies par le titulaire. » Trois sondes : (a) lecture du schema, (b) lecture du composant, (c) question à la formatrice elle-même, parce qu'aucune sonde technique ne peut trancher si c'est un bug ou un choix métier.

C'est ici que /challenger cède la place à un autre skill, ask-3-options-before-code, promu source dans la doctrine v0.7. Avant d'écrire la moindre ligne, formuler trois options à arbitrer hors technique, que les notes soient par séance et visibles à tous les signataires successifs, qu'elles soient privées au signataire et jamais partagées, ou qu'elles soient partagées au sein de l'équipe pédagogique d'un cours sans être exposées aux remplaçants ponctuels. La formatrice tranche pour la deuxième. Il n'y a pas de bug, il y a un choix de design qui mérite une décision écrite plutôt qu'un fix patché à l'oreille. ADR mini, zéro ligne de code, deux minutes de discussion.

Certes, un dev solo pressé aurait fait l'option 1 par défaut et déployé. Mais ce qui paraissait gagné en vitesse aurait coûté trois retours utilisateur la semaine d'après, la formatrice ayant ses notes lues par tout l'atelier, ce qu'elle ne voulait pas.

Bug numéro trois, le trait noir fantôme

Quatorze heures. Le planning éditeur affiche un fin trait noir vertical sur une seule colonne, traversant la grille du haut en bas. CSS qui fuit, voilà ce que dit l'œil. Hypothèse /challenger formulée : « un événement orphelin remonte une ligne vide qui se rend en bordure épaisse, parce qu'une suppression de cours n'a pas cascade-supprimé ses séances. » Trois sondes, l'inspect DOM, une requête de cohérence sur seances orphelines, et, la sonde qui réfute en dernier ressort par discipline acquise, git blame sur le composant <PlanningGrid>.

C'est la troisième sonde qui tranche. Un commit récent a ajouté un <hr> conditionnel pour séparer visuellement les ateliers dans la grille, en branchant sur une variable isLastOfAtelier mal calculée en bordure de tableau. Ce n'est pas un fantôme de la base de données, c'est une bordure d'interface. Une ligne TypeScript, pas de migration, deux minutes de fix. Aurais-je commencé par chercher en base, j'aurais perdu une heure à inspecter des cours et des séances qui n'avaient rien à se reprocher.

Bug numéro quatre, celui où j'ai sauté le protocole

Dix-huit heures. La fatigue est là, et avec elle ce qu'il faut bien appeler une certitude fragile. Une feuille d'émargement papier de secours imprime « jeudi 14h » alors que le cours est « mercredi 14h ». « Le PDF imprime le jour de la séance, pas le jour du cours », je me dis, et je commit sans sonde.

Vingt-cinq minutes plus tard, rollback. Désormais toutes les feuilles disent « mercredi », y compris les cours du jeudi. Le compteur Sentry remonte trois alertes en cinq minutes. Catherine, elle, n'a pas rappelé, elle a écrit « hum, ça bug » et m'a laissé seul avec la fatigue.

La cause réelle, qu'une sonde de quatre-vingt-dix secondes aurait remontée, c'est que creneau_label est stocké en Cache LSC sans rafraîchisseur, divergent depuis trois semaines pour les cours dont le jour_semaine a été corrigé sans propager le label vers la colonne dérivée. Pas un bug PDF, un bug de catégorisation Live/Snapshot/Cache déjà documenté dans la doctrine, que l'audit ADR-0024 avait flagué un mois plus tôt comme classe d'incident structurelle.

Un agent qui ne nous contredit pas n'est pas un counterpart, c'est une dactylo plus rapide ; un skill qu'on saute le soir n'est plus un skill, c'est une rigueur abandonnée. Le coût n'est pas dans l'oubli ponctuel, il est dans ce que l'oubli révèle, à savoir que le protocole tient à la discipline humaine, pas à un mécanisme matériel encore assez bloquant pour intercepter la fatigue de fin de journée.

Trois fix tenus, un rollback, le ratio qui fait tout

# ~/.claude/skills/challenger/SKILL.md (extrait)
name: challenger
description: Force la formulation d'une hypothèse en 1 phrase
  puis l'exécution de 3 sondes matérielles destinées à RÉFUTER
  cette hypothèse avant tout code de fix.

Sur la journée, le compte tient en quatre lignes. Bug numéro un, sonde tenue, fix juste, demi-heure gagnée. Bug numéro deux, protocole détourné vers la question métier, deux minutes au lieu d'une régression utilisateur. Bug numéro trois, sonde tenue, fix d'une ligne, une heure gagnée. Bug numéro quatre, protocole sauté, vingt-cinq minutes de rollback, alerte Sentry, et la note dans le journal de bord que le quatrième bug d'une journée n'a pas le droit d'être traité comme un fix isolé. Trois fix tenus pour un rollback, le ratio est plus parlant que la moyenne. Le skill ne nous évite pas l'erreur, il nous évite la troisième heure de la même erreur.

Une métaphore d'atelier ferait peut-être passer la chose : on ne cuit pas une pièce avant d'avoir vérifié la couche d'engobe. La cuisson, c'est le commit. L'engobe, c'est la sonde. Sauter l'engobe parce qu'on est pressé, c'est ce qui fait éclater la pièce dans le four.

Cinq à dix minutes de sonde évitent vingt à trente minutes de cycle fix-puis-rollback. Le calcul est trivial sur une journée, il devient écrasant sur soixante. Si une seule des quatre sondes vous évite, demain, le rollback que j'ai eu hier soir, le protocole s'est déjà remboursé.

Skill /challenger, Counterpart Toolkit v0.7 R4 Falsify before fix. Repo public github.com/michelfaure/doctrine-counterpart. Article #54 de la série My ERP with Claude Code, autopsie d'une journée de quatre incidents enchaînés.