L'indice Frankenstein — mesurer les coutures, pas les pièces¶

🎯 À retenir

Le frankenstein (unité : fkn 🧟, 0 à 10 par axe) est notre métrique d'évaluation de la qualité des applications qu'on construit ensemble. Elle ne note pas les pièces (le moteur, l'écran, la garde — ils peuvent être excellents) : elle note les coutures, c'est-à-dire l'incohérence entre les pièces. Bas = good job 🙂 ; haut = uggly 🙁. Orthogonale au périmètre (ajouter une feature ne fait jamais baisser le score), elle pénalise la sur-ingénierie par construction. Statut v0.1, proposée le 2026-06-19, à débattre (axes, poids et bandes négociables).


Statut	🧟 v0.1 — proposée le 2026-06-19 ; appliquée d'office sur tous nos projets (ActuaryLab, bfev, Quantis), révisable à tout moment
Nature	Métrique d'évaluation de qualité transverse (pas spécifique à l'actuariat) ; rubrique de jugement, pas un test automatisé
Unité	`frankenstein` — abrégé `fkn` 🧟 — de 0 (cohérent) à 10 (monstrueux) par axe
Invocation	« frankenstein de [module / feature / PR] » → bulletin par axe + agrégat + bande + coutures à recoudre

Pourquoi cette métaphore — la vraie définition¶

La créature de Frankenstein n'est pas laide parce que ses organes sont mauvais : ils sont excellents, prélevés sur les meilleurs cadavres. Elle est monstrueuse parce qu'ils ne vont pas ensemble — les coutures, les greffes, les sutures qui jurent.

Le frankenstein mesure les COUTURES, pas les pièces. Deux bons morceaux mal cousus marquent plus haut qu'un tout médiocre mais cohérent.

Deux corollaires rendent la métrique non triviale :

Orthogonale au périmètre. Une petite app cohérente vaut 0 fkn. Ajouter des features ne baisse jamais le score ; greffer un membre « au cas où » le monte. La métrique pénalise donc la sur-ingénierie par construction — elle épouse le principe capturer ≠ prioriser.
C'est la pire couture qui fait le monstre, pas la moyenne. L'agrégat doit pencher vers le max, pas se contenter de la moyenne.

L'échelle (0 à 10 par axe, haut = pire)¶

fkn	Bande	Verdict
0–1	D'une seule coulée	une seule main, une seule intention. good job 🙂
2–3	Couture nette	parties distinctes, sutures invisibles
4–5	Coutures visibles	ça tient, mais on voit les agrafes
6–7	Membre greffé	un bout manifestement rapporté d'ailleurs, qui jure
8–9	La créature	patchwork réanimé, marche par éclairs, grince partout
10	« C'est vivant ! »	incohérent, fragile, effrayant à maintenir. uggly 🙁

Les six axes (chacun 0 à 10, haut = pire)¶

Backend — moteur correct, tests verts sur oracles, migrations (le piège _COLONNES_AJOUTEES), robustesse, séparation pur / IO. Monstre : logique dupliquée, 500 en prod, tests rouges ou absents.
Frontend — DESIGN.md respecté (pas d'em-dash dans l'UI, laiton, couleur retenue), états busy / empty / error, cohérence d'un écran à l'autre, modale justifiée. Monstre : styles inline disparates, composants copiés-collés qui divergent.
Sécurité & intégrité — auth/SSO auto-réparante, scoping tenant journalisé, gardes require_personas, intégrité d'audit (approuvé = livré), aucun secret commité. Monstre : garde manquante, fuite cross-tenant, valeur figée non vérifiée.
Unicité — source unique de vérité, DRY, un seul chemin de code, doc ↔ app alignés. Monstre : trois écrans qui réimplémentent le même vocabulaire, deux vérités qui divergent.
Architecture — frontières nettes (les deux bancs, les étages), décisions tracées (ADR), modèle mental qui tient. Monstre : abstractions qui fuient, le « pourquoi » perdu.
Sobriété — la solution à la taille du problème. Monstre : membres spéculatifs, abstraction prématurée.

L'agrégat¶

\[ \text{frankenstein} = 0{,}6 \cdot \overline{\text{axes}} \; + \; 0{,}4 \cdot \max(\text{axes}) \]

La pire couture pèse (le terme max), sans écraser le reste (le terme moyenne). Les poids 0,6 / 0,4 sont un point de départ, pas un dogme.

La clause anti-monstre¶

Un rapport frankenstein qui flatte est lui-même un Frankenstein.

Le bulletin est adverse par défaut : score honnête, chaque point chiffré cité avec preuve (fichier:ligne), les pires coutures nommées, et une liste de remédiation (les sutures à recoudre). C'est l'exigence de critique sincère du projet, transformée en règle de notation. Une note complaisante viole la métrique.

Comment l'invoquer¶

Dis « frankenstein de [module / feature / PR] ». Le rendu est, à chaque fois :

un score par axe (0 à 10) avec, pour chaque point retiré, la couture précise qui le coûte ;
l'agrégat et sa bande (de « d'une seule coulée » à « c'est vivant ! ») ;
la liste des sutures à recoudre, par ordre de gravité.

À ne pas confondre — le « compteur Frankenstein »

Dans une discussion ultérieure est apparu un compteur Frankenstein, distinct : le nombre de rustines correctives déployées après coup sur une même feature. C'est un signal de processus (on a beaucoup itéré en prod au lieu d'éprouver avant), utile pour décider quand câbler un garde-fou déterministe (un hook). Il ne remplace pas l'indice ci-dessus, qui mesure la cohérence du résultat, pas le nombre de retouches du chemin.

Étalonnage de référence¶

Au moment de sa création, ActuaryLab tournait autour de 2–3 fkn (« couture nette ») : moteur testé, ADR partout, source unique doc ↔ app ; les rares agrafes visibles étaient les petites incohérences qu'on recoud au fil des sessions (synthèse mono vs genrée, vocabulaire des trois écrans de revue). Ce repère vaut point de comparaison pour les bulletins chiffrés à venir.

Statut & révision¶

Métrique v0.1, proposée — tout est négociable à la reprise : les six axes, les poids 0,6 / 0,4, les noms de bandes. Elle est transverse : ce document en est la référence côté ActuaryLab ; si on veut qu'elle fasse foi sur tous les modules Quantis, elle a vocation à être hissée au niveau umbrella (voir la gouvernance de portabilité du harness). Le fait qu'elle ait failli se perdre — définie en conversation, jamais persistée dans une surface versionnée — est précisément la raison d'être de ce fichier : le savoir fondateur vit dans le repo, pas dans la mémoire d'agent.