Pourquoi votre IA ne devrait pas trancher seule un audit ou une permission

Pourquoi votre IA ne devrait pas trancher seule un audit ou une permission

Pourquoi votre IA ne devrait pas trancher seule un audit ou une permission

Mardi après-midi, 16 mai. Catherine appelle de l'antenne Maisons-Laffitte. La ligne s'ouvre sur sa formule habituelle, « hum ça bug mais c'est vite corrigé », glissée dans le combiné avant même qu'elle nomme le problème. Cette fois ce n'est pas un bug. Il faut remplacer un formateur en cours d'année sur un cours déjà signé, déjà émargé deux fois.

La question apparente paraît techniquement insultante de simplicité. Un UPDATE sur la table des inscriptions, le nom du nouveau formateur dans le bon champ, dix secondes. Ma main est sur le clavier, l'agent attend ses instructions, et je suis sur le point d'écrire cinq lignes que j'aurais refaites une semaine plus tard.

Parce que la question apparente n'est pas la question réelle. La question réelle, c'est qui peut faire cette opération dans notre ERP, à quel statut la modification doit laisser l'inscription, quelle trace on garde pour qu'un parent puisse, dans six mois, savoir pourquoi la signature de son enfant a changé. Aucune de ces trois questions ne sort de l'expertise SQL. Elles sortent du workflow, du RBAC, de l'audit. Chacune, prise seule, semble si évidente qu'on tranche. Cumulées, elles produisent le re-do qui m'attend la semaine d'après si je tranche seul maintenant.

Trois raisons qui me poussent à trancher, et qui mentent toutes les trois

Coder en solo avec une IA produit une économie apparente que la pratique m'a appris à lire à l'envers. Trois forces internes me poussent à trancher avant d'avoir formulé.

L'orgueil du contexte me souffle que j'ai vu l'incident, je connais la table, je vois la solution, et me dispense de poser la question à voix haute. La vitesse mesure le code écrit et jamais le code refait, me persuade que formuler trois options consomme trente secondes perdues alors que coder fait avancer. L'amortissement cognitif, sensation tenace que chaque décision déléguée à l'agent grignote mon autonomie de praticien, me pousse à revendiquer la décision pour la décision.

Les trois se renforcent, les trois mentent. L'orgueil du contexte ignore que mon contexte est précisément ce qui me rend aveugle aux options que je n'ai pas envisagées. La vitesse compte une seule courbe, celle de l'écriture, jamais celle du re-do. L'amortissement cognitif confond décider avec exécuter, alors que l'agent qui me propose trois options ne décide rien. Je tranche toujours. Je tranche simplement mieux.

Le pattern, trois options structurellement distinctes

J'ai inversé le réflexe. Avant toute modification touchant un audit, une permission ou un workflow, je demande à l'agent trois options. Pas trois variantes de la même. Trois options structurellement distinctes, chacune avec son trade-off explicite sur trois axes nommés, effet métier, surface de code touchée, coût opérationnel.

Catherine, mardi. Sept mots à l'agent, « changement formateur sur inscription signée, trois options ». Vingt-cinq secondes plus tard, trois options retournées via AskUserQuestion. (a) UPDATE direct, traçabilité dans notes libres, audit faible. (b) clôture de l'inscription courante avec motif explicite, création d'une nouvelle liée au nouveau formateur, traçabilité dans le statut, audit fort. (c) flag annexe et note manuelle, audit moyen.

J'ai tranché (b) en cinq secondes. Solo à l'instinct, j'aurais pris (a). Le piège de (a) s'ouvre une semaine plus tard quand un parent demande pourquoi la signature de son enfant a changé. Je cherche la trace dans les notes libres, personne ne pense à fouiller un champ libre, et trois heures partent à reconstruire l'historique depuis les logs d'émargement.

La règle, étroite par choix

Le pattern s'applique seulement quand la question touche une transition de système qui laisse une trace côté métier, audit, permission, workflow. Si la question est « quel index Postgres sur cette colonne » ou « quelle signature TypeScript pour ce helper », l'expertise tranche directement. Demander dilue plus qu'elle n'éclaire.

Trente secondes pour entendre trois options structurellement distinctes, c'est les trois heures de re-do qu'on ne paiera pas la semaine d'après. La règle ne se mesure pas en lignes écrites. Elle se mesure en lignes non-réécrites.

Skill source : ask-3-options-before-code/SKILL.md dans github.com/michelfaure/doctrine-counterpart (R13).