La nuit où une fiche élève m'a appris à ne plus regarder la fiche
Un mardi de mai 2026, vers 22 h. Catherine me ping depuis Maisons-Laffitte : « ça bug sur Loubna, c'est vite corrigé. » Sentry s'ouvre sur mon téléphone. Cannot read properties of undefined sur la fonction qui rend une feuille d'émargement hebdomadaire. L'enfant n'a pas de nom de famille en base. La main est déjà sur le clavier pour taper l'UPDATE qui rajoute Sebti dans la colonne nom et qui fermerait le ticket en huit secondes.
Je ne tape pas l'UPDATE. Je tape une requête plus large, parce qu'un mois plus tôt une autre fiche m'a appris que la fiche n'est jamais le problème.
SELECT statut, COUNT(*) FROM contacts
WHERE statut = 'inscrit'
AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = ''));
-- → 16
Seize, pas un. Deux fiches au nom et prénom totalement vides, quatorze contacts au prénom vide hérité d'un vieil import Airtable où le champ ne mappait pas, et celui que Catherine venait de voir crasher. Si j'avais patché la fiche, quinze autres feuilles d'émargement seraient tombées au fil des semaines, chacune signalée comme un incident isolé, chacune patchée comme une exception, chacune laissant la classe latente attendre tranquillement la suivante.
Le réflexe qu'il faut désamorcer
Quand un utilisateur signale un bug, ce qu'il vous donne n'est pas une description du problème. C'est une amorce de sonde, un cas pathologique qui a franchi son filtre cognitif jusqu'à votre Slack. Sa rareté apparente est un artefact de son canal d'observation, pas une propriété du système. Catherine voit ce qui crashe sous ses doigts à Maisons-Laffitte ; elle ne voit pas les quinze fiches dormantes sur les autres ateliers qui crasheront dans trois semaines.
Le bon premier geste n'est pas le git diff sur la fiche. C'est la requête GROUP BY qui demande au système combien d'autres lignes portent la même pathologie. Quatre-vingt-dix secondes de probe matérielle, et la nature du fix change radicalement.
Pourquoi un agent IA aggrave le risque
Quand le patch nominatif coûte huit secondes à générer, le coût marginal apparent de sauter la probe tombe à zéro. L'agent ne va pas vous suggérer de chercher la classe. Il sait répondre à la question posée, et la question posée par votre prompt c'est « corrige cette fiche », pas « cartographie toutes les fiches dans cet état ». Le réflexe humain ancien, la lenteur qui obligeait à formuler, à se demander si l'effort valait la peine pour un cas, disparaît avec l'agent. Il faut le rematérialiser par discipline.
Je n'ai pas modifié mon agent. J'ai modifié mon prompt initial. Quand un bug remonte de la prod, le premier message que je tape ne dit jamais « fixe cette fiche ». Il dit « écris la requête GROUP BY qui révèle la classe complète des cas similaires en base ». Le fix vient après, quand la classe est cartographiée. Si la probe ne remonte qu'un cas, ça arrive, le commit le mentionne explicitement, probe pattern : 1/1, comme preuve que la question a été posée.
Trois questions avant tout fix
Quoi que vous pensiez de votre flair de senior, posez les trois, et posez-les dans l'ordre. Quelle est la classe dont ce cas est l'instance, formulée comme un critère SQL ou un regex de grep, pas comme une intuition ? Combien d'instances la classe contient en prod, à l'instant où vous lisez le ticket ? Le fix proposé traite-t-il la classe ou seulement l'instance signalée ? Si la troisième réponse est seulement l'instance, vous n'avez pas un fix, vous avez un palliatif daté. La classe attend.
Le réflexe d'élargissement porte un nom dans le Counterpart Toolkit, *Widen before correcting, cousin de Falsify before fix : github.com/michelfaure/doctrine-counterpart*
