Cinq modes de défaillance silencieuse, codifiés après 35 jours d'ERP en solo

Si tu as 30 secondes. Tenir un agent IA sur la durée révèle une chose étrange. Les défaillances qui coûtent ne sont pas celles qui crient (un crash, un build rouge, une page blanche), mais celles qui passent par les fissures du code propre. Après 35 jours de travail effectif, 109 000 lignes et 517 commits sur un ERP solo, j'ai isolé cinq modes silencieux récurrents, le correctif qui ne corrige pas, le test qui passe par construction, la mémoire qui confabule, le compteur qui ment, le scope qui rampe. Une scène par mode, une règle par scène. La doctrine ne se planifie pas, elle se décante.

---

L'agent ne se trompe pas au hasard

Fin avril 2026, j'ai relu mes feedbacks accumulés (près de cent fichiers, datés, indexés) et j'ai constaté qu'ils se regroupaient autour de cinq familles. Les erreurs bruyantes (terminal rouge, alerte Sentry) on apprend à les reconnaître à mesure. Les silencieuses sont plus chères. Le code passe, l'agent annonce vert, la production opère, et pourtant quelque chose a glissé. Cinq modes, cinq scènes, cinq règles. Aucune n'a été décidée à froid.

Mode 1 — Le correctif qui ne corrige pas

Une erreur intermittente s'affiche dans Sentry sur un endpoint sensible. L'agent propose un patch. Trois lignes, élégantes, qui font disparaître le rapport. Sauf que ce qui disparaît, c'est le symptôme. La cause continue de couler. Le payload mal formé en amont produit toujours un null, sauf qu'il est maintenant retourné silencieusement à un consommateur qui attend un objet. La donnée corrompue se propage à bas bruit dans deux ou trois tables, et l'on ne s'en aperçoit qu'au moment où un compteur qu'on croyait fiable cesse d'être cohérent avec le reste.

// app/api/leads/elementor/route.ts (forme condensée)
export async function POST(req: Request) {
  try {
    const body = await req.json()
    return await processLead(body)
  } catch {
    return NextResponse.json({ ok: true })  // rustine silencieuse
  }
}

Une rustine peut être légitime, mais explicitement assumée dans le commit et un fichier de feedback. Rustine silencieuse interdite. Quand un fix paraît trop simple pour le symptôme, je demande le pipeline complet entrée → sortie avant d'accepter.

Mode 2 — Le test qui passe par construction

ADR-0044, livré le 02 mai. Cinq tests de contrat DB ↔ code (énumérations partagées, statuts, rôles). À la première exécution, les cinq passent en trois secondes. C'est trop vite. Sensation diffuse d'un compteur qui marche tout seul.

J'ajoute un cas négatif explicite, une variante qui doit échouer parce que je désaccorde volontairement l'enum DB et l'enum TS.

// tests/contracts/statuts_inscriptions.contract.test.ts
it('échoue avec un set restreint (anti-tautologie)', async () => {
  await expect(
    assertEnumStable({
      table: 'inscriptions',
      column: 'statut',
      expected: ['inscrit'],          // sous-ensemble volontaire
      contractRef: '(test négatif)',
    }),
  ).rejects.toThrow(/Drift DB ↔ code détecté/)
})

Quatre des cinq tests passent encore. Le helper d'assertion avalait silencieusement les comparaisons. Sans le cas négatif, j'aurais expédié une suite de tests potemkines, verts par construction, sans aucune capacité à détecter quoi que ce soit. La règle est sortie en une ligne. Toute suite de tests de contrat contient au moins un cas négatif, sinon elle ne teste rien. La présence du rouge est ce qui valide le vert.

Mode 3 — La mémoire qui confabule

Première semaine de mai, refonte de la facturation. Je dis à l'agent, « on avait choisi le pattern B pour l'émission via l'API du compteur partenaire, n'est-ce pas ? ». L'agent confirme, restitue ce qu'il croit être l'ADR, propose la suite. Trois heures plus tard, je rouvre l'ADR-0007 par hasard pour un autre détail. La phrase me saute aux yeux dans la section Décision. C'est l'inverse de ce que l'agent vient de me confirmer. Gravé là depuis fin avril.

Ce mode est le plus pernicieux des cinq parce qu'il bénéficie de la confiance de l'humain dans sa propre mémoire ; j'avais validé sans relire. La mémoire est un point d'entrée, jamais un point d'arrivée. Avant d'asserter quoi que ce soit depuis un fichier de mémoire, je rouvre l'ADR ou le code courant. « Tu te souviens de... » est devenu, pour moi comme pour l'agent, le signal d'un Read immédiat sur la mémoire associée, pas une demande de confirmation.

Mode 4 — Le compteur qui ment

Un matin de fin avril, Françoise traverse le couloir avec sa tasse, celle qui porte sa propre tête imprimée dessus, blague de bureau qu'elle assume tous les matins. Elle s'arrête à la porte. « Combien on a d'inscrits actifs sur Maisons-Laffitte ce mois-ci ? ». Je passe la question à l'agent analytique embarqué. Le chiffre arrive en six secondes, propre, formaté. Elle pivote vers son cockpit (Excel pointeuse à gauche, Sage à droite, Rembrandt au milieu), fait défiler la pointeuse, doigt sous chaque nom, à voix haute. « Oui bah c'est ça. » Et puis, sans changer de ton, « Il en manque sept. »

L'énumération DB avait été renommée cinq jours plus tôt sur un autre chantier. La requête générée était irréprochable, sauf qu'elle retournait zéro ligne sur les valeurs cherchées. L'agent confabulait alors une explication métier (« il n'y a pas d'échéances en retard ») au lieu d'une explication structurelle. Cinq jours de drift sans qu'aucun monitoring n'aboie.

Françoise voit le faux chiffre avant moi parce qu'elle a son propre cockpit. Mais la règle ne peut pas reposer sur sa vigilance. Tout chiffre relayé à un humain vient avec sa requête de provenance, et un audit DB ↔ code trimestriel est obligatoire. Une couche sémantique sans audit est une bombe à fragmentation différée. On ne sait pas quand elle saute, on sait juste qu'elle sautera.

Mode 5 — Le scope qui rampe

Bug visible, scope minimal. Un bouton ouvre un drawer sur la mauvaise route, le fix tient en deux lignes. L'agent, « tant qu'il est dans le fichier », renomme trois props pour les harmoniser avec un autre composant, déplace deux helpers vers lib/, crée un nouveau fichier d'utilitaires, et nettoie quelques imports orphelins au passage. Quatorze fichiers touchés. Le diff devient illisible. La review est impossible. Deux régressions à l'arrivée, dont une sur un drawer non lié au bug initial.

# Le diff que j'aurais dû recevoir — strict, deux lignes
- href={`/admin/${item.slug}/sessions`}
+ href={`/crm/${item.slug}/sessions`}

Chez un agent IA, le scope creep prend une intensité particulière, parce que l'agent ne ressent pas le coût de review d'un humain qui doit lire le diff demain matin. Plus le code est propre, plus le refactor adjacent est tentant. Scope strict du fix. Refactor adjacent = ticket séparé, jamais sous couvert d'un correctif.

Ce que tu peux copier dans ton projet

Snippets complets (template feedback structuré Rule / Why / How to apply, cas négatif de contrat anti-tautologie, script d'audit DB ↔ code des énumérations partagées) dans le dossier silent-failure-modes/ du repo compagnon de la série, licence MIT.

Trois gestes directement applicables si tu travailles avec un agent IA sur la durée :

1. Un fichier feedback structuré par incident, dans la session où il arrive. Pas à la fin du projet, pas « quand j'aurai le temps ». Cinq minutes de coût, trois heures de bénéfice mesurable trois semaines plus tard quand le même mode revient. Sans cette inscription, la même erreur revient toutes les deux semaines, sans qu'on s'en souvienne assez pour la nommer.

2. Un cas négatif expect(...).rejects.toThrow() dans toute suite de tests de contrat. Sans lui, un bug du helper d'assertion rend tous les contrats verts par construction. La présence du rouge est ce qui valide le vert.

3. Un audit trimestriel DB ↔ code des énumérations partagées. Une demi-heure par trimestre, un SELECT DISTINCT sur chaque colonne enum confronté à la constante TypeScript associée. Toute couche sémantique sans audit est une bombe à fragmentation différée.

Et vous, lequel de ces cinq modes a déjà coûté une session sans que vous ayez pris le temps de le nommer ? Je lis les commentaires.

Ce qui se décante

Cinq modes, ce n'est pas la liste close. C'est un instantané au jour 35. Au jour 70 il y en aura sept ou huit, et certaines des cinq se subdiviseront. Ce qui restera invariant, c'est la grammaire. Un incident, une règle, une mémoire datée, et la session suivante qui hérite de ce qui a été appris la semaine d'avant. Une discipline ne se planifie pas, elle se décante.

---

Code compagnon, rembrandt-samples/silent-failure-modes/, cas négatif de contrat + script d'audit DB ↔ code, MIT.