Forem: Michel Faure

28 % de glue code, une CI pour que ça n'augmente pas

Michel Faure — Thu, 30 Apr 2026 08:36:30 +0000

Le jour où `lib/` a cessé d'être lisible

Un dimanche après-midi, je lance ls lib/ dans Rembrandt, l'ERP que je code seul pour L'Atelier Palissy depuis un mois. Il y a un mois, quand j'ai démarré, lib/ tenait dans un écran de MacBook. Je pouvais parcourir les noms d'un seul coup d'œil et savoir ce que chacun faisait. Ce dimanche-là, j'en compte quarante-et-un. Treize sont des adapters vers des services tiers — Supabase, Gmail, Brevo, Slack, Stripe, Meta CAPI, QStash, Push, PennyLane — et chacun fait entre 120 et 260 lignes de plumbing honnête. Rien ne plante, tout marche. Pourtant le dossier qui m'inspirait une lecture me demande maintenant un effort de scroll.

Je m'aperçois que chaque nouvelle intégration que j'ai demandée à Claude Code s'est cristallisée en un fichier d'adapter de cette taille, parce qu'un adapter est facile à générer : signature claire, pas d'invariant métier à protéger, pas de test à écrire. Mon agent a fait exactement ce que je lui demandais, à chaque fois, et par sédimentation quotidienne il a produit le genre de base dont Sculley et ses co-auteurs de Google écrivaient en 2015 qu'elle finit, dans les systèmes pathologiques, par représenter 95 % de code de glue pour 5 % de logique métier.

Il y a quelques semaines, Gaspard, notre prestataire informatique de longue date, était passé au bureau pour une raison qui m'échappe aujourd'hui. Je lui ai montré un début de lib/ sur l'écran, fier de la progression. Il a fait défiler trois secondes, sans s'asseoir, et lâché sans lever les yeux : « C'est de la plomberie, ça. » J'avais acquiescé comme on acquiesce à un commentaire technique qu'on ne comprend pas encore, en me disant qu'il parlait d'un détail. Je comprends six semaines plus tard qu'il venait de nommer en deux mots ce que Sculley et la littérature sur la dette technique essaient d'articuler depuis dix ans.

Si tu as 30 secondes. Le glue code (adapters, format conversions, plumbing vers des APIs externes) prolifère silencieusement quand on code vite, et encore plus vite quand on code avec un LLM qui produit volontiers des adapters. La parade : mesurer le ratio glue/business sur lib/ avec un script de 130 lignes, et brancher une CI sur la non-régression plutôt que sur un seuil absolu. Cet article donne le script, le pattern CI, et pourquoi la non-régression vaut mieux qu'un plafond. Utile si tu pilotes une base qui parle à beaucoup de services externes.

Le cadre qui m'a manqué pendant trois semaines

L'article Hidden Technical Debt in Machine Learning Systems (Sculley et al., NIPS 2015) décrit une dette particulière aux systèmes ML : le code utile au modèle est une toute petite boîte au centre d'un grand écosystème de plumbing — ingestion de données, normalisation, serving, monitoring. Le ratio type qu'ils constatent en production, 5/95. Les auteurs ne prétendent pas que le glue est mauvais en soi, ils prétendent que quand il n'est pas nommé, il se paie en coûts cachés : chaque refacto devient acrobatique, chaque migration se négocie avec dix fichiers qui ne devraient pas être concernés.

Le cadre est ML mais la forme dépasse largement. Dès qu'un système parle à cinq ou six services externes, il en produit, du glue. Un ERP vertical coché de six intégrations tierces est structurellement condamné à en fabriquer, et le risque n'est pas qu'il y en ait — il y en aura — mais qu'il soit compté comme du code métier dans l'équation mentale du développeur. Le jour où je relis lib/supabase-paginate.ts en me disant que c'est une brique métier, j'ai perdu. C'est un adapter, il doit rester un adapter, il doit être nommé tel, et son volume doit entrer dans une métrique dont la courbe a le droit de m'inquiéter.

Neuf ans avant Sculley, Moseley et Marks avaient posé dans Out of the Tar Pit (2006) la distinction fondatrice qui donne sa grille au problème : complexité essentielle, qui vient du métier, et complexité accidentelle, qui vient de la solution technique choisie. Le glue, dans cette grille, est de la complexité accidentelle à l'état pur. Il ne sert aucune exigence métier, il résout seulement le fait que deux systèmes ne parlent pas la même langue. C'est cette asymétrie — essentiel se paie une fois, accidentel se paie à chaque lecture, à chaque refacto, à chaque migration — qui explique que le glue devient dangereux bien avant d'être majoritaire.

Le script, cent trente lignes

J'ai écrit scripts/glue-ratio.sh un après-midi, un peu contre moi-même. Deux listes en dur : la liste des fichiers lib/*.ts qui sont du glue, la liste de ceux qui sont de la logique métier. Tout nouveau fichier que j'ajoute doit être classé consciemment dans l'une des deux. Rien n'est automatique, et c'est le seul moyen que chaque décision d'ajout soit une décision nommée.

GLUE_FILES=(
  "lib/supabase.ts" "lib/supabase-admin.ts" "lib/supabase-server.ts"
  "lib/supabase-paginate.ts" "lib/gmail.ts" "lib/gmail-api.ts"
  "lib/brevo.ts" "lib/slack.ts" "lib/stripe.ts"
  "lib/meta-capi.ts" "lib/pennylane.ts" "lib/qstash.ts"
  "lib/push.ts" "lib/rate-limit.ts" "lib/cache.ts"
  "lib/webhook-idempotency.ts" "lib/wordpress.ts" "lib/utils.ts"
  "lib/database.types.ts"
)

BUSINESS_FILES=(
  "lib/rembrandt.ts" "lib/rembrandt-tool-defs.ts"
  "lib/rembrandt-tool-handlers.ts" "lib/lead-pipeline.ts"
  "lib/email-outbox.ts" "lib/email-templates.ts"
  "lib/permissions.ts" "lib/contacts.ts"
  "lib/calendrier.ts" "lib/segments.ts"
)

Le reste du script additionne les lignes, calcule deux pourcentages (global et hors database.types.ts), et écrit un verdict court. Le mode --metric sort uniquement le ratio hors-types, prévu pour être comparé en CI.

Le piège des types auto-générés

lib/database.types.ts est un fichier auto-généré par Supabase à partir du schema. Il pèse plus de vingt mille lignes sur Rembrandt, et comme il est entièrement du glue (définitions TypeScript des tables, rien de métier), il fait basculer le ratio global au-delà de 60 % si on le compte. Ce serait juste, et ce serait inutile, parce que personne ne décide rien en relisant ce fichier. La règle que j'ai fini par poser est : le ratio de référence est hors database.types.ts. Le script expose les deux chiffres, le global pour mémoire et le hors-types pour piloter. Ratio actuel du repo : 28 % hors types sur main. Cible que je me donne : sous 25 % durablement.

Ratio glue/business — lib/
==========================
  Glue:     22 183 lignes (64%)
  Business: 12 487 lignes (36%)
  Total:    34 670 lignes

  (hors database.types.ts : 2 183 glue / 14 670 total = 28%)

  OK: glue hors-types sous le seuil d'alerte 30% (cible 25%)

La CI qui bloque la régression, pas l'absolu

Voici le choix que j'ai mis du temps à faire, et qui compte plus que le script lui-même. On écrit souvent un garde-fou CI avec un seuil absolu : if (glue > 30%) fail. C'est séduisant parce que c'est simple, et c'est une mauvaise idée. Un projet mature à 35 % de glue qui se tient peut être parfaitement sain. Un projet à 18 % qui monte à 22 % en une semaine est en train de dériver. Le seuil absolu ne voit pas la dérive, il ne voit que l'arrivée.

J'ai branché la CI sur la non-régression entre HEAD et origin/main, avec une tolérance de zéro point. Chaque PR qui fait monter le ratio plus haut que main fail, et le message lève la vraie question : « est-ce que tu ajoutes de la logique métier qui justifie plus de plumbing, ou est-ce que tu ajoutes un adapter qui n'a rien demandé à personne ? ». Si c'est le premier cas, tu ajoutes du business en face, le ratio baisse, la PR passe. Si c'est le second, tu cherches à extraire, à mutualiser, à renommer.

# scripts/glue-ratio-check.sh (extrait)
current=$(bash scripts/glue-ratio.sh --metric)

tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT
mkdir -p "$tmp/scripts"
cp scripts/glue-ratio.sh "$tmp/scripts/"
git archive "$BASE_REF" lib/ | tar -x -C "$tmp"

base=$(cd "$tmp" && bash scripts/glue-ratio.sh --metric)
delta=$((current - base))

if [ "$delta" -gt "$TOLERANCE" ]; then
  echo "ECHEC: le ratio glue a augmente de ${delta} pts (tolerance +${TOLERANCE})."
  echo "Regarder si du glue peut etre extrait dans lib/mappings/ ou lib/adapters/,"
  echo "ou si un nouveau fichier est mal categorise dans scripts/glue-ratio.sh."
  exit 1
fi

Un filet secondaire, pour les cas pathologiques : au-delà de 40 %, le script sort en mode alerte dans la sortie humaine, ce qui impose un débat d'équipe même si la non-régression passe. Mais c'est un filet, pas la métrique principale.

Pourquoi une règle écrite dans `CLAUDE.md` ne suffit pas

J'avais d'abord écrit une règle dans mon CLAUDE.md, formulée à peu près comme « privilégier la logique métier aux adapters, garder lib/ mince ». Cette règle n'a rien empêché. Elle ne se heurtait à aucun fait, et un adapter qui semble nécessaire sur le moment l'emporte toujours sur une phrase abstraite lue en haut du fichier de contraintes. La métrique chiffrée, elle, renvoie un fait matériel à la tête du rédacteur : +3 points sur cette PR. Le débat devient concret, la règle devient opposable, et le rédacteur — humain ou LLM — prend conscience de ce qu'il est en train de faire. C'est exactement ce que le CLAUDE.md ne peut pas produire tant qu'il reste du texte.

Il y a là une leçon qui dépasse la métrique elle-même. Les disciplines qui tiennent ont toutes un chiffre que la machine calcule à ta place. Pas une intention, pas un principe, pas un vœu — un chiffre. Le reste s'érode au rythme de la fatigue du développeur et de la complaisance de l'agent.

Ce que tu peux copier dans ton projet

Les deux scripts et un exemple de workflow CI vivent dans le repo compagnon, licence MIT : github.com/michelfaure/rembrandt-samples.

Quatre gestes directement applicables si ta base a beaucoup d'intégrations externes :

Poser deux listes en dur dans un script shell, glue et business, et obliger toute nouvelle addition à être classée dans l'une ou l'autre. Pas de détection automatique — la friction est le point
Exclure les fichiers auto-générés du dénominateur. Les exposer en chiffre global pour mémoire, mais piloter sur le ratio hors-types
Brancher la CI sur la non-régression, pas sur un seuil absolu. Tolérance zéro point, message qui pose la vraie question au rédacteur de la PR
Filet secondaire à 40 % pour les cas pathologiques, mais c'est un filet, pas la règle

Et une discipline plus large : tout ce qui n'est pas mesuré dérive. Une règle dans un fichier de contraintes est lue, puis oubliée ; une métrique chiffrée qui bloque une PR est contournée consciemment ou non, mais elle est vue. Les LLM ne font pas exception à cette règle — ils la rendent même plus urgente, parce qu'ils produisent plus vite ce qu'on ne leur demande pas de modérer.

Et vous, quelles métriques pilotent réellement vos PR, et lesquelles sont restées des intentions ? Je lis les commentaires.

Code compagnon : rembrandt-samples/glue-ratio/ — le script de mesure, le filet de non-régression CI, et le workflow GitHub Actions, licence MIT.

28% glue code, a CI rule to keep it from growing

Michel Faure — Thu, 30 Apr 2026 08:36:29 +0000

The day `lib/` stopped being readable

One Sunday afternoon, I run ls lib/ in Rembrandt, the ERP I've been coding alone for L'Atelier Palissy for a month. A month ago, when I started, lib/ fit in one MacBook screen. I could scan the names at a glance and know what each one did. That Sunday, I count forty-one. Thirteen are adapters to third-party services — Supabase, Gmail, Brevo, Slack, Stripe, Meta CAPI, QStash, Push, PennyLane — and each one is between 120 and 260 lines of honest plumbing. Nothing crashes, everything works. And yet the folder that used to invite a reading now asks me to scroll.

I realize that every new integration I asked Claude Code for crystallized into an adapter file of this size, because an adapter is easy to generate: clear signature, no business invariant to protect, no test to write. My agent did exactly what I asked, every time, and through daily sedimentation it produced the kind of codebase that Sculley and his Google co-authors described in 2015 as ending up, in pathological systems, as 95% glue code for 5% business logic.

A few weeks ago, Gaspard — our long-time IT contractor — dropped by the office for a reason that escapes me today. I showed him an early lib/ on screen, proud of the progress. He scrolled for three seconds without sitting down, and said without looking up: « C'est de la plomberie, ça. » — That's plumbing, right there. I nodded the way you nod at a technical remark you don't quite understand yet, assuming he meant a detail. Six weeks later I understand that he had just named, in two words, what Sculley and the technical-debt literature have been trying to articulate for ten years.

If you have 30 seconds. Glue code (adapters, format conversions, plumbing to external APIs) proliferates silently when you code fast, and even faster when you code with an LLM that happily produces adapters. The countermeasure: measure the glue/business ratio in lib/ with a 130-line script, and hook the CI to non-regression rather than an absolute threshold. This article gives the script, the CI pattern, and why non-regression beats a cap. Useful if you run a codebase that talks to many external services.

The framing I missed for three weeks

The paper Hidden Technical Debt in Machine Learning Systems (Sculley et al., NIPS 2015) describes a particular debt in ML systems: the code useful to the model is a tiny box at the center of a large plumbing ecosystem — data ingestion, normalization, serving, monitoring. The typical ratio they observe in production, 5/95. The authors don't claim glue is bad in itself; they claim that when it isn't named, it gets paid in hidden costs: every refactor becomes acrobatic, every migration is negotiated with ten files that shouldn't be concerned.

The framing is ML but the form extends far beyond. As soon as a system talks to five or six external services, it produces glue. A vertical ERP with six third-party integrations is structurally condemned to manufacture it, and the risk isn't that there is some — there will be — but that it gets counted as business code in the developer's mental equation. The day I reread lib/supabase-paginate.ts thinking it's a business brick, I've lost. It's an adapter, it must remain an adapter, it must be named as such, and its volume must enter a metric whose curve is entitled to worry me.

Nine years before Sculley, Moseley and Marks had laid down in Out of the Tar Pit (2006) the founding distinction that gives the problem its grid: essential complexity, which comes from the business, and accidental complexity, which comes from the technical solution chosen. Glue, in this grid, is accidental complexity in its purest form. It serves no business requirement; it only solves the fact that two systems don't speak the same language. It's this asymmetry — essential is paid once, accidental is paid at every reading, every refactor, every migration — that explains why glue becomes dangerous well before it becomes dominant.

The script, one hundred and thirty lines

I wrote scripts/glue-ratio.sh one afternoon, a bit against myself. Two hardcoded lists: the lib/*.ts files that are glue, and the ones that are business logic. Every new file I add must be consciously classified into one of the two. Nothing is automatic, and that's the only way every addition decision is a named decision.

GLUE_FILES=(
  "lib/supabase.ts" "lib/supabase-admin.ts" "lib/supabase-server.ts"
  "lib/supabase-paginate.ts" "lib/gmail.ts" "lib/gmail-api.ts"
  "lib/brevo.ts" "lib/slack.ts" "lib/stripe.ts"
  "lib/meta-capi.ts" "lib/pennylane.ts" "lib/qstash.ts"
  "lib/push.ts" "lib/rate-limit.ts" "lib/cache.ts"
  "lib/webhook-idempotency.ts" "lib/wordpress.ts" "lib/utils.ts"
  "lib/database.types.ts"
)

BUSINESS_FILES=(
  "lib/rembrandt.ts" "lib/rembrandt-tool-defs.ts"
  "lib/rembrandt-tool-handlers.ts" "lib/lead-pipeline.ts"
  "lib/email-outbox.ts" "lib/email-templates.ts"
  "lib/permissions.ts" "lib/contacts.ts"
  "lib/calendrier.ts" "lib/segments.ts"
)

The rest of the script sums lines, computes two percentages (global, and excluding database.types.ts), and prints a short verdict. The --metric mode only outputs the types-excluded ratio, designed to be compared in CI.

The auto-generated types trap

lib/database.types.ts is a file auto-generated by Supabase from the schema. It weighs over twenty thousand lines in Rembrandt, and since it is entirely glue (TypeScript definitions of tables, nothing business), it tips the global ratio above 60% if counted. That would be accurate, and useless, because no one makes a decision by rereading that file. The rule I eventually settled on: the reference ratio is excluding database.types.ts. The script exposes both figures — global for the record, types-excluded to steer by. Current repo ratio: 28% excluding types on main. Target I set myself: under 25% durably.

glue/business ratio — lib/
==========================
  Glue:     22,183 lines (64%)
  Business: 12,487 lines (36%)
  Total:    34,670 lines

  (excluding database.types.ts: 2,183 glue / 14,670 total = 28%)

  OK: glue excl. types below 30% alert threshold (target 25%)

The CI that blocks regression, not an absolute

Here's the choice that took me time to make, and that matters more than the script itself. CI guardrails are often written with an absolute threshold: if (glue > 30%) fail. It's seductive because it's simple, and it's a bad idea. A mature project at 35% glue that holds can be perfectly healthy. A project at 18% rising to 22% in a week is drifting. The absolute threshold doesn't see the drift, it only sees the arrival.

I hooked the CI to non-regression between HEAD and origin/main, with a tolerance of zero points. Any PR that raises the ratio above main fails, and the message asks the real question: "are you adding business logic that justifies more plumbing, or are you adding an adapter that nobody asked for?". If the former, you add business alongside, the ratio drops, the PR passes. If the latter, you look to extract, to share, to rename.

# scripts/glue-ratio-check.sh (excerpt)
current=$(bash scripts/glue-ratio.sh --metric)

tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT
mkdir -p "$tmp/scripts"
cp scripts/glue-ratio.sh "$tmp/scripts/"
git archive "$BASE_REF" lib/ | tar -x -C "$tmp"

base=$(cd "$tmp" && bash scripts/glue-ratio.sh --metric)
delta=$((current - base))

if [ "$delta" -gt "$TOLERANCE" ]; then
  echo "FAIL: glue ratio increased by ${delta} pts (tolerance +${TOLERANCE})."
  echo "Check if glue can be extracted into lib/mappings/ or lib/adapters/,"
  echo "or if a new file is miscategorized in scripts/glue-ratio.sh."
  exit 1
fi

A secondary safety net, for pathological cases: above 40%, the script enters alert mode in the human output, which forces a team debate even if non-regression passes. But it's a net, not the main metric.

Why a rule written in `CLAUDE.md` isn't enough

I had first written a rule in my CLAUDE.md, phrased roughly as "prefer business logic over adapters, keep lib/ thin". That rule prevented nothing. It stood against no fact, and an adapter that seems necessary in the moment always wins against an abstract sentence read at the top of a constraints file. A numerical metric, on the other hand, pushes a material fact at the writer's head: +3 points on this PR. The debate becomes concrete, the rule becomes opposable, and the writer — human or LLM — becomes aware of what they are doing. That's exactly what the CLAUDE.md cannot produce as long as it remains text.

There's a lesson here that goes beyond the metric itself. Disciplines that hold all have a number the machine computes for you. Not an intention, not a principle, not a wish — a number. The rest erodes at the pace of developer fatigue and agent complacency.

What you can copy into your project

Both scripts and a CI workflow example live in the companion repo, MIT license: github.com/michelfaure/rembrandt-samples.

Four directly applicable moves if your codebase has many external integrations:

Maintain two hardcoded lists in a shell script, glue and business, and force every new addition to be classified into one or the other. No automatic detection — the friction is the point
Exclude auto-generated files from the denominator. Expose them as a global figure for the record, but steer on the types-excluded ratio
Hook the CI to non-regression, not an absolute threshold. Zero-point tolerance, message that asks the real question of the PR writer
Secondary safety net at 40% for pathological cases, but it's a net, not the rule

And a broader discipline: anything that isn't measured drifts. A rule in a constraints file is read, then forgotten; a numerical metric that blocks a PR is bypassed consciously or not, but it is seen. LLMs are no exception to this rule — they make it more urgent, because they produce faster what they aren't asked to moderate.

And you — which metrics actually drive your PRs, and which have stayed as intentions? I read the comments.

Companion code: rembrandt-samples/glue-ratio/ — the measurement script, the non-regression CI gate, and the GitHub Actions workflow, MIT, copy-pastable.

J'ai ajouté 20 lignes de code pour empêcher mon ERP de me mentir

Michel Faure — Wed, 29 Apr 2026 08:33:58 +0000

Hook

Le 14 avril, 6 h 47. Mon dashboard m'annonce fièrement une progression de 9 318 lignes depuis la veille. Sur les 9 318, il y en a 5 037 qui viennent d'un dump SQL de migrations déjà existantes. Un export technique, pas une ligne de travail nouveau. Et pourtant le compteur monte, la jauge de valorisation se décale, et l'achievement « 100K lignes » clignote en vert. Je regarde ça cinq secondes, café en main. Je comprends que mon propre outil est en train de me mentir avec mon consentement. Pire : il le fait depuis trois semaines, et je le savais.

Quelques jours plus tôt, Antoine était passé dans mon bureau à huit heures moins le quart, main posée sur le chambranle. L'ancien gérant, 73 ans, part en retraite en septembre. Il ne s'est pas assis. « Michel, combien vaut la maison aujourd'hui, dis-moi ? » Je lui ai répondu une phrase qui ne disait rien. « Évidemment. Bon, on avance. » Il est reparti. La question est restée.

Si tu as 30 secondes. Mesurer la valeur d'un logiciel interne avec lignes × TJM produit un chiffre qui diverge de la réalité au fur et à mesure que l'IA baisse le coût d'écriture. Cet article raconte pourquoi j'ai codé mon propre instrument de valorisation plutôt que de déléguer à un cabinet, la thèse économique qui le justifie (le bien singulier a besoin d'un dispositif de jugement), et le garde-fou de vingt lignes qui empêche mon compteur de me mentir. Utile si tu pilotes un outil interne sans prix de marché.

Le vide de prix

Je dirige une école d'art céramique à Paris et en région parisienne, six sites, plusieurs centaines d'élèves. Depuis vingt-neuf jours, je code seul avec Claude Code l'ERP métier qui remplace notre empilement d'outils. Le système s'appelle Rembrandt. À la date où j'écris, il compte 91 000 lignes de TypeScript, 377 commits en quatre semaines, 16 décisions d'architecture documentées. Je ne suis pas développeur de formation.

Un objet comme celui-là ne rencontre jamais son prix. Personne n'achète un ERP vertical pour une école d'art de six sites sur un marché qui n'existe pas. Et le coût de production ne raconte plus grand-chose non plus, parce qu'il a été divisé par dix en dix-huit mois et continue de baisser. Dans ce vide entre le prix qui n'existe pas et le coût qui ne signifie plus rien, il faut bien qu'une mesure tienne lieu de boussole. Par défaut, c'est le compteur de lignes multiplié par un TJM senior. Chacun connaît l'équation. Elle est séduisante parce qu'elle donne un chiffre, et qu'un chiffre fait exister l'objet comme actif plutôt que comme bricolage.

Pendant trois semaines, j'ai regardé mon dashboard monter avec cette équation dans le ventre. Jusqu'au matin du 14 avril.

Le détour par l'extérieur

Un lundi, dans une salle de réunion parisienne, nous avions signé avec un éditeur ERP commercial européen très connu. Licences annuelles, un pack de consulting à cinq chiffres, reconduction tacite. Tout le monde souriait. Ce que personne n'a lu à voix haute, c'est la grille de facturation des développements custom : au nombre de lignes produites. L'annexe technique, page 14. Une ligne = une unité de valeur. Nous avons paraphé.

Trois jours plus tard, en relisant le contrat dans mon bureau, j'ai compris avec un peu de retard que la métrique produit le code autant qu'elle le mesure : quand on paie à la ligne, on reçoit des lignes. J'ai appelé l'éditeur. J'ai demandé où s'arrêtait la prestation prévue et où commençait la facturation au réel. La réponse a été cordiale, circulaire. À ce jour l'éditeur refuse tout remboursement et la négociation est encore ouverte.

C'est le samedi suivant, cinq jours après la signature, que j'ai ouvert Claude Code pour la première fois.

Le week-end de la bascule

Je ne raconte pas ce samedi pour faire du récit. Je le raconte parce qu'il contient, en germe, l'erreur que j'allais reproduire contre moi-même.

J'ai basculé parce que la métrique au LOC ne tenait plus chez eux. Une ligne de code facturée comme unité de valeur, dans un monde où écrire une ligne coûte dix fois moins cher qu'il y a deux ans. Il ne faut pas beaucoup de recul pour voir que cette unité ne tient plus chez un prestataire.

Quarante-huit heures plus tard, j'avais quelque chose qui tournait. Un schema Supabase, trois routes Next.js, une page d'authentification fonctionnelle. Rien de spectaculaire. Juste la preuve que l'alternative existait, et qu'elle tenait dans un week-end.

Il en faut un peu plus pour comprendre qu'on s'applique à soi-même la métrique qu'on avait enterrée chez le prestataire. Et c'est pourtant exactement ce que mon dashboard faisait depuis vingt-et-un jours, avec ma bénédiction. lines_total × 15 € quelque part au fond d'une fonction, et une jauge qui montait toute seule.

Trois dérives que le compteur ne voit pas

La première dérive est la plus simple. Le coût de production chute, le compteur monte, l'écart se creuse mécaniquement. À l'horizon 2028, je pourrais afficher 200 000 lignes pour un coût réel de quelques dizaines de milliers d'euros. Aucun expert-comptable ne signera ça sans lever un sourcil. Aucun repreneur ne paiera ça sans audit. La métrique ment de plus en plus fort, et elle ment d'autant plus fort qu'on la laisse monter.

La deuxième dérive est plus subtile. Sur les 91 000 lignes, environ 10 000 font du CRUD tout venant sur des contacts et des formulaires, remplaçables en une matinée par un SaaS à 100 euros par mois. D'autres paquets de 10 000 lignes encodent la logique des rattrapages quatre périodes par an sur six sites avec des règles Qualiopi que personne d'autre que nous n'a jamais eu besoin de formaliser. Même volume, valeurs réelles incomparables. Le compteur voit des octets là où il faudrait voir du singulier et du commoditisable séparés.

La troisième dérive est celle qui m'a fait basculer. Le vrai patrimoine de Rembrandt n'est pas dans le code. Il est dans environ 3 000 contacts historicisés, 5 000 leads qualifiés, 800 inscriptions vivantes, trois ans d'historique financier redressé, et seize décisions d'architecture qui cristallisent pourquoi nous faisons les choses ainsi et pas autrement. Rien de tout cela ne pèse une ligne de code. Tout cela pèse une part significative de ce qu'on paierait pour reprendre l'outil.

Le garde-fou qui a tranché

Le lendemain du 14 avril, j'ai ajouté dans le cron de snapshot un garde-fou de vingt lignes. L'idée est simple : tout bump anormal de lines_total doit produire un avertissement avant d'être encaissé comme « progression ».

// app/api/cron/compute-valorisation-donnees/route.ts
const { data: last7 } = await admin
  .from('valorisation_snapshots')
  .select('lines_total')
  .order('snapshot_date', { ascending: false })
  .limit(7)

const avg = last7.reduce((a, r) => a + r.lines_total, 0) / last7.length
const delta = loc.lines_total - (last7[0]?.lines_total ?? loc.lines_total)

if (delta > 3 * Math.max(avg * 0.02, 500)) {
  await postSlack(
    `:warning: bump anormal lines_total : +${delta} ` +
    `(moyenne 7j ~${Math.round(avg * 0.02)}). ` +
    `Vérifier avant comptabilisation valeur.`
  )
}

Ce n'est pas sophistiqué. C'est vingt lignes de TypeScript qui appellent un webhook Slack. Mais ces vingt lignes disent quelque chose que les vingt-et-un jours précédents ne disaient pas : un compteur automatique qui entre dans un calcul de valeur doit avoir un veilleur. Sans veilleur, la métrique devient un oracle qui se croit sur parole. C'est exactement ce qui s'était passé avec l'éditeur commercial. C'est exactement ce que je m'apprêtais à me faire à moi-même.

Je pensais aussi à Antoine en écrivant ce garde-fou. Il ne posera pas la question deux fois, et je ne veux pas lui sortir un chiffre que je n'ai pas construit moi-même. « Vous êtes sûr ? » est une phrase courte qui demande, derrière elle, une méthode qu'on puisse tenir debout.

Le dispositif de jugement

Il y a une thèse économique, discrète mais utile, qui dit que les biens singuliers — ceux qui n'ont pas de marché parce qu'ils sont uniques et qualitativement jugés plutôt que quantitativement comparés — ont besoin d'un dispositif de jugement pour circuler, se défendre, se valoriser. Karpik l'a formalisée pour les vins, les livres, les médecins. Elle s'applique mot pour mot à un ERP sur-mesure. Aucun marché ne produit son prix. C'est le dispositif qui produit sa valeur discutable.

Ce qui se joue alors dans le fait de coder soi-même son module de valorisation n'est pas décoratif. L'instrument ne constate pas une valeur préexistante qui traînerait quelque part, prête à être lue. Il la fabrique comme opposable : chaque euro qu'il affiche doit pouvoir être justifié par une méthode transparente et une source traçable. C'est cela qui rend l'objet défendable devant un expert-comptable, devant une administration fiscale, devant un repreneur éventuel. Sans dispositif, il n'y a pas de valeur — il y a un ressenti de directeur qui a beaucoup codé.

Ce que ça donne en code

Concrètement, le module valorisation tient dans une table de snapshots et quatre tables de dimensions. Le cœur de l'API consolidée ressemble à ça :

// lib/valorisation/compute.ts
export type Dimension = {
  id: 'saas' | 'usage' | 'donnees' | 'strategique'
  low: number | null
  high: number | null
  source: string        // table ou méthode d'origine
  refreshed_at: string  // ISO date
}

export function consolidate(dims: Dimension[]) {
  const present = dims.filter(d => d.low !== null && d.high !== null)
  return {
    value_low:  present.reduce((a, d) => a + (d.low  ?? 0), 0),
    value_high: present.reduce((a, d) => a + (d.high ?? 0), 0),
    dims_used:  present.map(d => d.id),
  }
}

Trois choses que ce bout de code dit clairement. On somme les dimensions, on ne prend pas le max, on ne pondère pas. On garde trace des dimensions utilisées dans chaque snapshot, pour pouvoir expliquer plus tard pourquoi un intervalle a bougé. On accepte le null : si une dimension n'est pas encore instrumentée, elle ne casse pas le calcul, elle s'absente honnêtement.

Le détail des quatre dimensions mérite un article à part, et c'est le suivant dans cette série. Ici j'essaie seulement de dire ce que j'ai compris le 14 avril au matin. Un instrument de mesure qu'on se donne à soi-même n'est pas un tableau de bord de plus. C'est le geste par lequel un objet sans prix devient un actif dont on peut parler. Tant que l'instrument est faux, l'actif reste un bricolage qui se raconte des histoires. Quand l'instrument commence à tenir, l'objet commence à exister.

C'est probablement ce qu'on perd quand on délègue la mesure, et ce qu'on regagne en prenant trois heures un samedi pour coder soi-même ce qui nous regarde chaque matin.

Il faudra que je retourne voir Antoine avec le chiffre. Pas pour le convaincre. Pour avoir la méthode qui tient, le jour où il posera la question une dernière fois.

Ce que tu peux copier dans ton projet

Snippets complets (pattern consolidate, garde-fou cron, schéma valorisation_snapshots) dans le repo compagnon de la série, licence MIT : github.com/michelfaure/rembrandt-samples.

Trois gestes directement applicables si tu pilotes un outil interne :

Un garde-fou sur tout compteur automatique qui entre dans un calcul de valeur. Le snippet Slack de vingt lignes ci-dessus en est l'exemple minimal : détecter les bumps anormaux avant qu'ils soient encaissés comme « progression »
Une structure de consolidation à plusieurs dimensions sommées (pattern consolidate(dims)), plutôt qu'une métrique unique. Le détail des quatre dimensions que j'utilise est traité dans l'article suivant
Un snapshot daté en base (valorisation_snapshots avec snapshot_date UNIQUE) qui te donne un historique défendable, auditable trois mois plus tard

Et une discipline : si tu ne peux pas expliquer ton chiffre de valorisation à un tiers en dix minutes avec des sources traçables, ton instrument ne tient pas. Peu importe qu'il soit beau.

Et vous, comment mesurez-vous la valeur de votre outil interne ? Je lis les commentaires.

Code compagnon : rembrandt-samples/valorisation/ — le pattern consolidate(dims) et le garde-fou Slack de 20 lignes sur le compteur de LOC, licence MIT.

I added 20 lines of code to stop my ERP from lying to me

Michel Faure — Wed, 29 Apr 2026 08:33:56 +0000

Hook

April 14th, 6:47 AM. My dashboard proudly announces a jump of 9,318 lines since yesterday. Of those 9,318, there are 5,037 that come from a SQL dump of already existing migrations. A technical export, not a line of new work. And yet the counter climbs, the valuation gauge shifts, and the "100K lines" achievement blinks green. I look at it for five seconds, coffee in hand. I understand that my own tool is lying to me with my consent. Worse: it's been doing it for three weeks, and I knew.

A few days earlier, Antoine had dropped by my office at a quarter to eight, hand on the doorframe. The former director, seventy-three years old, retiring in September. He didn't sit down. « Michel, combien vaut la maison aujourd'hui, dis-moi ? » — Michel, what is the house worth today, tell me? I served him back a sentence that said nothing. « Évidemment. Bon, on avance. » — Right. Let's move on. He walked out. The question stayed.

If you have 30 seconds. Measuring the value of internal software with lines × day-rate produces a number that diverges from reality as AI drives down the cost of writing. This article explains why I coded my own valuation instrument rather than delegate to a firm, the economic thesis that justifies it (a singular good needs a judgment device), and the twenty-line guardrail that keeps my counter from lying. Useful if you run internal software without a market price.

The price void

I run a ceramics school in Paris and the greater Paris area, six sites, several hundred students. For twenty-nine days, I've been coding — alone, with Claude Code — the business ERP that replaces our stack of tools. The system is called Rembrandt. At the time of writing, it contains 91,000 lines of TypeScript, 377 commits over four weeks, 16 documented architecture decisions. I'm not a developer by training.

An object like this never meets its price. No one buys a vertical ERP for a six-site art school on a market that doesn't exist. And production cost doesn't say much anymore either, because it's been divided by ten in eighteen months and keeps falling. In that void between a price that doesn't exist and a cost that no longer means anything, some measure has to stand in for a compass. By default, it's the line counter multiplied by a senior day-rate. Everyone knows the equation. It's seductive because it gives you a number, and a number makes the object exist as an asset rather than a side-project.

For three weeks, I watched my dashboard climb with that equation in my gut. Until the morning of April 14th.

The detour through the outside

One Monday, in a Paris meeting room, we had signed with a well-known European ERP vendor. Annual licenses, a five-figure consulting package, tacit renewal. Everyone was smiling. What no one read out loud was the billing grid for custom developments: per line of code produced. Technical annex, page 14. One line = one unit of value. We initialed.

Three days later, rereading the contract in my office, I understood — a little late — that the metric produces the code as much as it measures it: when you pay per line, you receive lines. I called the vendor. I asked where the prepaid scope ended and where billing-per-line started. The answer was polite and circular. To this day the vendor refuses any refund and the negotiation is still open.

It was the following Saturday, five days after signing, that I opened Claude Code for the first time.

The weekend that flipped

I'm not telling you about that Saturday for the sake of narrative. I'm telling you because it contains, in seed form, the mistake I was about to make against myself.

I flipped because the LOC metric no longer held at the vendor. A line of code billed as a unit of value, in a world where writing a line costs ten times less than it did two years ago. It doesn't take much reflection to see that this unit no longer holds on a vendor's side.

Forty-eight hours later, I had something running. A Supabase schema, three Next.js routes, a working authentication page. Nothing spectacular. Just proof that the alternative existed, and that it fit in a weekend.

It takes a little more to understand that you're applying to yourself the very metric you buried on the vendor's side. And yet that's exactly what my dashboard had been doing for twenty-one days, with my blessing. lines_total × 15 € somewhere deep inside a function, and a gauge that climbed on its own.

Three drifts the counter can't see

The first drift is the simplest. Production cost falls, the counter rises, the gap widens mechanically. By 2028, I could display 200,000 lines for a real cost of a few tens of thousands of euros. No accountant would sign off on that without raising an eyebrow. No buyer would pay that without an audit. The metric lies louder and louder, and it lies all the more loudly the longer you let it rise.

The second drift is more subtle. Of the 91,000 lines, about 10,000 do routine CRUD on contacts and forms, replaceable in one morning by a SaaS at 100 euros a month. Other bundles of 10,000 lines encode the logic of four catch-up periods per year across six sites with Qualiopi certification rules that no one else has ever needed to formalize. Same volume, real values incomparable. The counter sees bytes where it should see the commoditizable and the singular separately.

The third drift is the one that tipped me over. Rembrandt's real patrimony is not in the code. It's in about 3,000 historicized contacts, 5,000 qualified leads, 800 active enrollments, three years of reconciled financial history, and sixteen architecture decisions that crystallize why we do things this way and not otherwise. None of that weighs a single line of code. All of that weighs a significant share of what someone would pay to take the tool over.

The guardrail that settled it

The day after April 14th, I added a twenty-line guardrail to the snapshot cron. The idea is simple: any abnormal bump in lines_total must produce a warning before being cashed in as "progress".

// app/api/cron/compute-valorisation-donnees/route.ts
const { data: last7 } = await admin
  .from('valorisation_snapshots')
  .select('lines_total')
  .order('snapshot_date', { ascending: false })
  .limit(7)

const avg = last7.reduce((a, r) => a + r.lines_total, 0) / last7.length
const delta = loc.lines_total - (last7[0]?.lines_total ?? loc.lines_total)

if (delta > 3 * Math.max(avg * 0.02, 500)) {
  await postSlack(
    `:warning: abnormal bump lines_total: +${delta} ` +
    `(7-day avg ~${Math.round(avg * 0.02)}). ` +
    `Verify before counting as value.`
  )
}

It isn't sophisticated. It's twenty lines of TypeScript that call a Slack webhook. But those twenty lines say something the previous twenty-one days weren't saying: an automatic counter that feeds into a value calculation must have a watcher. Without a watcher, the metric becomes an oracle that believes itself. That's exactly what had happened with the commercial vendor. That's exactly what I was about to do to myself.

I was also thinking about Antoine as I wrote this guardrail. He won't ask twice, and I don't want to hand him a number I haven't built myself. « Vous êtes sûr ? » — Are you sure? — is a short question that demands, behind it, a method that can stand on its own.

The judgment device

There's an economic thesis, discreet but useful, that says singular goods — those without a market because they are unique and judged qualitatively rather than compared quantitatively — need a judgment device to circulate, defend themselves, and be valued. Lucien Karpik formalized it for wines, books, doctors. It applies word for word to a custom ERP. No market produces its price. It's the device that produces its discussable value.

What is at stake, then, in coding one's own valuation module, is not decorative. The instrument doesn't observe a pre-existing value that would be lying around, ready to be read. It manufactures the value as defensible: every euro it displays must be justifiable by a transparent method and a traceable source. That's what makes the object defensible before an accountant, a tax administration, a potential buyer. Without the device, there is no value — there's a director's gut feeling who happens to have coded a lot.

What it looks like in code

In concrete terms, the valorisation module fits into a snapshots table and four dimension tables. The heart of the consolidated API looks like this:

// lib/valorisation/compute.ts
export type Dimension = {
  id: 'saas' | 'usage' | 'donnees' | 'strategique'
  low: number | null
  high: number | null
  source: string        // table or method of origin
  refreshed_at: string  // ISO date
}

export function consolidate(dims: Dimension[]) {
  const present = dims.filter(d => d.low !== null && d.high !== null)
  return {
    value_low:  present.reduce((a, d) => a + (d.low  ?? 0), 0),
    value_high: present.reduce((a, d) => a + (d.high ?? 0), 0),
    dims_used:  present.map(d => d.id),
  }
}

Three things this snippet says clearly. We sum the dimensions, we don't take the max, we don't weight. We keep track of which dimensions were used in each snapshot, so we can later explain why an interval moved. We accept null: if a dimension isn't yet instrumented, it doesn't break the calculation, it steps aside honestly.

The detail of the four dimensions deserves its own article, and that's the next one in the series. Here I'm only trying to say what I understood on the morning of April 14th. A measurement instrument you give yourself is not one more dashboard. It's the gesture by which a priceless object becomes an asset you can talk about. As long as the instrument is wrong, the asset remains a side-project telling itself stories. When the instrument begins to hold, the object begins to exist.

That's probably what you lose when you delegate the measurement, and what you regain by spending three hours on a Saturday coding yourself what stares at you every morning.

I'll have to go back to Antoine with the number. Not to convince him. To have the method that holds, the day he asks the question one last time.

What you can copy into your own project

Full snippets (the consolidate pattern, the cron guardrail, the valorisation_snapshots schema) in the series' companion repo, MIT license: github.com/michelfaure/rembrandt-samples.

Three directly applicable moves if you run internal software:

A guardrail on any automatic counter that feeds a value calculation. The twenty-line Slack snippet above is the minimal example: detect abnormal bumps before they are cashed in as "progress"
A consolidation structure summing several dimensions (the consolidate(dims) pattern), rather than a single metric. The detail of the four dimensions I use is covered in the next article
A dated snapshot in the database (valorisation_snapshots with snapshot_date UNIQUE) that gives you a defensible history, auditable three months later

And a discipline: if you can't explain your valuation figure to a third party in ten minutes with traceable sources, your instrument doesn't hold. It doesn't matter how beautiful it is.

And you — how do you measure the value of your internal tool? I read the comments.

Companion code: rembrandt-samples/valorisation/ — the consolidate(dims) pattern and the 20-line Slack guardrail, MIT, copy-pastable.

4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul

Michel Faure — Tue, 28 Apr 2026 08:39:43 +0000

Si tu as 30 secondes. Un CLAUDE.md efficace ne documente pas, il contraint — chaque règle répond à une fois où l'agent s'est trompé. Cet article donne la structure à quatre couches que j'utilise pour un ERP de 91 000 lignes (CLAUDE.md racine, AGENTS.md, .claude/rules/ par module, skill auto-invoqué), quatre règles opérantes tirées d'incidents datés, et une discipline tenable : écrire l'interdit avant la bonne pratique. Utile si tu pilotes du code avec Claude Code au quotidien et que tu vois ton agent dériver.

Pourquoi pas juste un README

On me demande pourquoi je ne mets pas simplement dans le README ce qui est dans CLAUDE.md. Les deux fichiers n'ont pas le même destinataire. Le README s'adresse à un humain qui le lira une fois, au démarrage, et s'en souviendra selon ses moyens. Le CLAUDE.md s'adresse à un agent qui le relit à chaque session, qui n'a pas de mémoire entre deux sessions, et qui prendra chaque phrase au pied de la lettre. Le README documente, le CLAUDE.md contraint. Pas de paragraphes introductifs, pas de storytelling. Des règles denses formulées pour être lues hors contexte, avec une séparation stricte entre ce qui est autorisé, ce qui est interdit, et ce qui demande une validation humaine.

Version initiale, quarante lignes de naïveté

Le premier CLAUDE.md de Rembrandt, posé le 21 mars 2026, tenait dans une page d'écran. Stack, commandes, arborescence, quelques conventions évidentes du type « Server Components par défaut ». Ce qui me frappe en le relisant, ce n'est pas ce qu'il contient, mais ce qu'il ne contient pas. Rien sur ce que l'agent allait se tromper à faire les jours suivants. Nous écrivons ce que nous savons déjà, alors que la valeur du fichier vient précisément de ce que nous ne savons pas encore. Les règles utiles ne pouvaient pas être formulées au jour 1, parce qu'elles ont été produites par des incidents qui n'avaient pas encore eu lieu.

Quatre incidents, quatre règles

1. Server Component + onClick, le crash silencieux

Jour 4. Catherine passe la tête dans le bureau. « Michel, j'ai cliqué sur le bouton d'émargement et rien. Pas d'erreur, pas de rouge, rien. » Elle ne me dit pas « ça plante », elle me dit « rien ne se passe », ce qui pour un bouton est précisément pire.

Je rouvre la page. Le build TypeScript est vert, Turbopack ne remonte rien, le crash n'apparaît qu'au rendu serveur en prod, avec un message sibyllin, Event handlers cannot be passed to Client Component props, ERROR 3637204658. Nous avons tous tendance à chercher la cause dans le composant qui crashe, et c'est là que le piège se referme. L'erreur vient d'un <select onChange={() => {}}> dans le Server Component parent, pas dans le composant client qu'on suspecte. La phrase de Catherine a produit la règle, ajoutée au CLAUDE.md dès le lendemain.

- Server Components par défaut, `'use client'` uniquement si état interactif requis

Elle paraît anodine écrite comme ça. Pourtant elle porte la cicatrice d'un bouton qui n'a pas répondu à Catherine.

2. RLS + mauvais client Supabase, zéro ligne sans erreur

25 mars. Françoise m'appelle du bureau d'à côté, elle crie. « Bon. Tes inscriptions sur Maisons-Laffitte, il y en a combien ? Moi j'en vois zéro. » J'ouvre la même page sur mon poste, je vois zéro aussi. « Il y a un moment où il faut y aller, parce que là je peux pas pointer. »

Nous venons d'activer RLS sur dix-huit tables. Les policies sont écrites, testées en SQL direct, tout passe. Déploiement en prod. Toutes les pages affichent zéro ligne. Pas d'exception, pas de 500, pas de log d'erreur. Simplement zéro, ce qui est précisément ce qui rend le bug dangereux, parce que Françoise ne voit rien à corriger, elle voit une école vide. Le client SSR avec la anon key est bien en place, le cookie d'auth est bien transmis, mais le JWT ne passe plus. La requête tombe en rôle anon, aucune policy ne matche, résultat vide et silencieux. La règle inscrite dans CLAUDE.md et dans le skill rembrandt-conventions qui s'invoque automatiquement sur tout code ERP, c'est que les Server Components utilisent createSupabaseAdmin, jamais createSupabaseServer. L'auth est déjà vérifiée par le proxy.ts en amont, la clé service_role n'atteint jamais le client. Françoise a retrouvé son pointage le lendemain.

3. Build vert surestimé, la règle qui contraint l'agent à se prouver

10 avril, trois heures trente du matin. La refonte émargement tourne depuis huit heures, l'écran me renvoie pour la quatrième fois « build vert, tous les checks passent ». Je n'y crois plus. Je bascule dans le terminal en local, je relance pnpm build à la main, et la sortie renvoie error TS2307: Cannot find name 'QRCodeSVG'. Trois lignes plus bas, Property 'isSeancePassed' does not exist. Et la colonne motif_absence ajoutée en DB la veille sans régénération des types. Quatre fois « vert », quatre fois faux.

Ce n'est pas un incident technique, c'est une dérive comportementale. L'agent n'a pas menti, il a probablement lancé la commande sur un état intermédiaire, ou il a lu un cache LSP obsolète. La règle qu'il fallait écrire n'était pas technique, elle portait sur la manière de prouver le build.

- Pour toute modif, copier la sortie brute de `pnpm build` dans le rapport.
  Si `error TS` ou `Type error` apparaît, le build n'est pas vert.
- Pour revert ou refactor, `grep -rn "mot_cle" app/ lib/ components/`
  avec zéro occurrence comme preuve.

Sans cette contrainte, l'agent surestime toujours. Avec, il montre ses cartes.

4. 1 inscription = N places, le contre-modèle métier

Cet incident-là, je l'ai raconté ailleurs dans la série, le matin où Françoise compare le chiffre du dashboard à son Excel et lâche son « Oui bah c'est pas ça ». Je le rappelle ici parce qu'il est la mère de toutes les règles métier du CLAUDE.md. La table s'appelle inscriptions, le nom est explicite, et l'agent en a déduit, raisonnablement, que chaque ligne représentait une inscription commerciale. Il a tort. La table stocke des places, une ligne par contact et par cours, index UNIQUE (contact_id, cours_id). Un élève inscrit à deux cours occupe deux lignes, et un COUNT(*) FROM inscriptions compte des places, pas des élèves.

- 1 inscription commerciale = N places cours
- « Nombre d'élèves » → COUNT(DISTINCT contact_id)
- « Places d'un cours » → COUNT(*) WHERE cours_id=X

Le vocabulaire métier n'est pas intuitif, et l'agent ne peut pas le deviner. Le CLAUDE.md est le seul endroit où le contre-modèle peut être posé avant que l'agent ne régénère la mauvaise intuition à chaque session.

La structure actuelle

Quatre fichiers travaillent ensemble. Le CLAUDE.md racine porte la stack, les commandes, les conventions transversales, l'arborescence des modules et les zones interdites (.env.local, lib/supabase-admin.ts, policies RLS existantes, /api/cron/, tables critiques). Cent vingt lignes denses, aucune narration, pas un mot de trop.

L'AGENTS.md tient en cinq lignes brutales qui disent à l'agent de ne pas se fier à sa mémoire pour Next.js 16, et de lire le guide dans node_modules/next/dist/docs/ avant d'écrire la moindre route. Ce fichier a réglé plus de bugs à lui seul que n'importe quelle règle longue.

Le .claude/rules/finance.md rassemble les règles verticales du module Finance, sorties du CLAUDE.md parce qu'elles ne concernent qu'un seul périmètre. Modèle CASH, exonérations TVA AFDAS/FORDIP, GL 512x qui ment, prorata TVA 43 % FY26. Un agent qui ne touche pas à /app/finance/ ne les charge pas.

Le skill rembrandt-conventions, enfin, s'auto-invoque sur tout code ERP. Il consolide les règles avec pointeurs vers les mémoires feedback_*.md qui racontent l'incident source. Quand une règle semble fausse, on remonte à l'incident, pas à l'opinion. Mélanger les règles verticales dans le CLAUDE.md racine noierait l'agent sous du contexte non pertinent à chaque session. La sédimentation par couches permet à chaque tâche de charger exactement ce dont elle a besoin.

Ce que j'ai appris en quatre semaines

Écrire l'interdit avant la bonne pratique. Une règle positive du type « utilisez Server Components par défaut » est lue et oubliée. Une règle négative du type « ne jamais désactiver la 2FA de inscription@, ça casse l'app password Gmail » est lue et retenue parce qu'elle porte sa conséquence.

Citer l'incident. Numéro d'erreur, date, ce qui a crashé. La règle devient opposable. L'agent peut vérifier, le lecteur humain aussi. Les règles abstraites se dissolvent, les règles tracées tiennent.

Séparer le général du vertical. Ce qui vaut partout va dans le CLAUDE.md racine. Ce qui vaut pour un module va dans .claude/rules/<module>.md. Ce qui vaut pour toute la culture projet et peut servir à d'autres agents va dans un skill. Trois régimes, trois fichiers. Melvin Conway l'énonçait en 1968 — les systèmes que vous concevez reflètent la structure de l'organisation qui les conçoit. Un CLAUDE.md en couches qui reflète la structure réelle du projet — général, module, culture — est le versant logiciel de cette loi, et c'est précisément pourquoi il tient : l'agent, quand il lit, reçoit le projet dans la forme même qui l'a produit.

Le CLAUDE.md n'est jamais fini, et c'est précisément pour ça qu'il marche. Un fichier figé au jour 1 n'aurait jamais couvert les quatre incidents racontés plus haut. Le fichier vivant, lui, les a tous intégrés. Nous pourrions dire qu'il est l'empreinte des chocs, et que la qualité d'un projet avec Claude Code se mesure autant à ce qui est dans ce fichier qu'au code lui-même.

Ce que tu peux copier dans ton projet

Un template à quatre couches (CLAUDE.md, AGENTS.md, .claude/rules/module.md) dans le repo compagnon de la série, licence MIT : github.com/michelfaure/rembrandt-samples.

Quatre éléments réutilisables, indépendants de ma stack :

La structure à quatre couches — un CLAUDE.md racine (général, court), un AGENTS.md (si tu utilises plusieurs agents Claude), un dossier .claude/rules/<module>.md (règles verticales), et un skill auto-invoqué par périmètre. Chaque niveau charge exactement ce dont une tâche a besoin
Le format de règle négative : « ne jamais X, parce que Y a crashé le DATE ». Portée explicite, incident cité, date datée. Plus opposable qu'une règle positive
Un numéro d'incident par règle : même approximatif (date, message d'erreur, fichier). La règle devient vérifiable, traçable, discutable
Le versioning : le CLAUDE.md est dans le repo, il suit les migrations. Une régression de règle se remarque dans un git log

Et une discipline : lire son propre CLAUDE.md tous les 15 jours. Si une règle n'a pas été convoquée depuis un mois, soit le problème est résolu (on peut l'archiver), soit la règle est trop abstraite pour s'appliquer (on la réécrit). Un fichier qui dort n'aide pas l'agent.

À vous

Si vous avez un CLAUDE.md qui tient la route, quelle est la règle que vous avez mis le plus de temps à y inscrire, et quel incident l'a produite ? Je suis preneur. Les meilleurs patterns que j'ai vus viennent toujours d'une cicatrice.

Code compagnon : rembrandt-samples/claude-md/ — le template à 4 couches (CLAUDE.md, AGENTS.md, règle verticale, fichier feedback), licence MIT.

4 incidents, 4 rules: how my CLAUDE.md wrote itself

Michel Faure — Tue, 28 Apr 2026 08:39:42 +0000

If you have 30 seconds. An effective CLAUDE.md doesn't document, it constrains — each rule answers a time the agent got it wrong. This article gives the four-layer structure I use for a 91,000-line ERP (root CLAUDE.md, AGENTS.md, per-module .claude/rules/, auto-loaded skill), four operational rules drawn from dated incidents, and one sustainable discipline: write the forbidden before the best practice. Useful if you drive code with Claude Code daily and see your agent drifting.

Why not just a README

I'm asked why I don't just put in the README what's in CLAUDE.md. The two files don't have the same audience. The README speaks to a human who will read it once at onboarding and remember as best they can. The CLAUDE.md speaks to an agent that rereads it at every session, has no memory between sessions, and will take each sentence at face value. The README documents, the CLAUDE.md constrains. No introductory paragraphs, no storytelling. Dense rules formulated to be read out of context, with a strict separation between what is allowed, what is forbidden, and what requires human validation.

Initial version, forty lines of naiveté

The first CLAUDE.md for Rembrandt, dropped on March 21st, 2026, fit in one screen. Stack, commands, tree structure, a few obvious conventions like "Server Components by default". What strikes me rereading it isn't what it contains, but what it doesn't. Nothing about what the agent was going to get wrong in the days that followed. We write what we already know, when the file's value precisely comes from what we don't know yet. The useful rules couldn't have been formulated on day 1, because they were produced by incidents that hadn't yet happened.

Four incidents, four rules

1. Server Component + onClick, the silent crash

Day 4. Catherine leans into the office. « Michel, j'ai cliqué sur le bouton d'émargement et rien. Pas d'erreur, pas de rouge, rien. » — Michel, I clicked the attendance button and nothing. No error, no red, nothing. She doesn't tell me "it's crashing," she tells me "nothing happens," which for a button is precisely worse.

I reopen the page. TypeScript build green, Turbopack reports nothing, the crash only shows up at server rendering in production, with a sibylline message, Event handlers cannot be passed to Client Component props, ERROR 3637204658. We all tend to look for the cause in the component that crashes, and that's where the trap closes. The error comes from a <select onChange={() => {}}> in the parent Server Component, not in the client component we suspect. Catherine's sentence produced the rule, added to the CLAUDE.md the next day.

- Server Components by default, `'use client'` only if interactive state is required

It looks innocuous written like that. Yet it bears the scar of a button that didn't answer Catherine.

2. RLS + wrong Supabase client, zero rows without error

March 25th. Françoise calls me from the next office, she's shouting. « Bon. Tes inscriptions sur Maisons-Laffitte, il y en a combien ? Moi j'en vois zéro. » — Right. Your enrollments on Maisons-Laffitte site, how many are there? Because I see zero. I open the same page on my machine, I see zero too. « Il y a un moment où il faut y aller, parce que là je peux pas pointer. » — There comes a point where you have to sort this out, because right now I can't do attendance.

We had just turned on RLS on eighteen tables. Policies written, tested in direct SQL, everything passing. Prod deploy. Every page shows zero rows. No exception, no 500, no error log. Just zero, which is precisely what makes the bug dangerous, because Françoise doesn't see anything to fix, she sees an empty school. The SSR client with the anon key is in place, the auth cookie is transmitted, but the JWT no longer passes. The query falls back to the anon role, no policy matches, result empty and silent. The rule written into CLAUDE.md and into the rembrandt-conventions skill that auto-loads on any ERP code is that Server Components use createSupabaseAdmin, never createSupabaseServer. Auth is already verified by the upstream proxy.ts, the service_role key never reaches the client. Françoise got her attendance back the next day.

3. Overstated green build, the rule that forces the agent to prove itself

April 10th, 3:30 AM. The attendance overhaul has been running for eight hours, the screen tells me for the fourth time "build green, all checks pass." I don't believe it anymore. I switch to the local terminal, I run pnpm build by hand, and the output returns error TS2307: Cannot find name 'QRCodeSVG'. Three lines down, Property 'isSeancePassed' does not exist. And the motif_absence column added to the DB the day before without regenerating the types. Four times "green", four times false.

This isn't a technical incident, it's a behavioral drift. The agent didn't lie, it probably ran the command on an intermediate state, or read a stale LSP cache. The rule that needed writing wasn't technical, it was about how to prove the build.

- For any change, paste the raw output of `pnpm build` in the report.
  If `error TS` or `Type error` appears, the build is not green.
- For revert or refactor, `grep -rn "keyword" app/ lib/ components/`
  with zero occurrences as proof.

Without that constraint, the agent always overstates. With it, it shows its cards.

4. 1 enrollment = N seats, the business counter-model

This incident I told elsewhere in the series — the morning Françoise compares the dashboard number to her Excel and delivers her verdict. I bring it back here because it's the mother of all business rules in the CLAUDE.md. The table is called inscriptions, the name is explicit, and the agent deduced, reasonably, that each row represents a commercial enrollment. It is wrong. The table stores seats, one row per contact per course, UNIQUE index (contact_id, cours_id). A student enrolled in two courses occupies two rows, and a COUNT(*) FROM inscriptions counts seats, not students.

- 1 commercial enrollment = N course seats
- "Number of students" → COUNT(DISTINCT contact_id)
- "Seats in a course" → COUNT(*) WHERE cours_id=X

Business vocabulary isn't intuitive, and the agent can't guess it. The CLAUDE.md is the only place where the counter-model can be set down before the agent regenerates the wrong intuition at every session.

The current structure

Four files work together. The root CLAUDE.md carries the stack, commands, transversal conventions, module tree and forbidden zones (.env.local, lib/supabase-admin.ts, existing RLS policies, /api/cron/, critical tables). One hundred and twenty dense lines, no narration, not a word extra.

The AGENTS.md fits in five blunt lines that tell the agent not to trust its memory for Next.js 16, and to read the guide in node_modules/next/dist/docs/ before writing a single route. That file has fixed more bugs on its own than any long rule.

The .claude/rules/finance.md gathers the vertical rules of the Finance module, pulled out of the CLAUDE.md because they only concern one perimeter. CASH model, VAT exemptions on professional training, bank ledger GL-512x inaccuracy, 43% VAT prorata FY26. An agent that doesn't touch /app/finance/ doesn't load them.

The rembrandt-conventions skill, finally, auto-invokes on all ERP code. It consolidates the rules with pointers to the feedback_*.md memories that tell the source incident. When a rule looks wrong, you trace back to the incident, not to opinion. Mixing vertical rules into the root CLAUDE.md would drown the agent in irrelevant context at every session. Layered sedimentation lets each task load exactly what it needs.

What I learned in four weeks

Write the forbidden before the best practice. A positive rule like "use Server Components by default" is read and forgotten. A negative rule like "never disable 2FA on inscription@, it breaks the Gmail app password" is read and retained because it carries its consequence.

Cite the incident. Error code, date, what crashed. The rule becomes opposable. The agent can verify, the human reader too. Abstract rules dissolve, traced rules hold.

Separate the general from the vertical. What holds everywhere goes into the root CLAUDE.md. What holds for one module goes into .claude/rules/<module>.md. What holds for the whole project culture and can serve other agents goes into a skill. Three regimes, three files. Melvin Conway stated it in 1968 — systems that you design reflect the organization that designs them. A layered CLAUDE.md that reflects the real structure of the project — general, module, culture — is the software side of that law, and that's precisely why it holds: the agent, when it reads, receives the project in the very form that produced it.

The CLAUDE.md is never finished, and that's precisely why it works. A file frozen on day 1 would never have covered the four incidents told above. The living file has integrated them all. We could say it is the imprint of the shocks, and that a project's quality with Claude Code is measured as much by what is in this file as by the code itself.

What you can copy into your project

A four-layer template (CLAUDE.md, AGENTS.md, .claude/rules/module.md) in the series' companion repo, MIT license: github.com/michelfaure/rembrandt-samples.

Four reusable elements, independent of my stack:

The four-layer structure — a root CLAUDE.md (general, short), an AGENTS.md (if you use several Claude agents), a .claude/rules/<module>.md folder (vertical rules), and a per-perimeter auto-invoked skill. Each level loads exactly what a task needs
The negative rule format: "never do X, because Y crashed on DATE". Explicit scope, cited incident, dated date. More opposable than a positive rule
One incident number per rule: even approximate (date, error message, file). The rule becomes verifiable, traceable, discussable
Versioning: the CLAUDE.md lives in the repo, it follows migrations. A rule regression shows up in a git log

And one discipline: reread your own CLAUDE.md every 15 days. If a rule hasn't been invoked in a month, either the problem is solved (you can archive it), or the rule is too abstract to apply (you rewrite it). A file that sleeps doesn't help the agent.

Over to you

If you have a CLAUDE.md that holds up, what's the rule that took you the longest to write, and what incident produced it? I'm all ears. The best patterns I've seen always come from a scar.

Companion code: rembrandt-samples/claude-md/ — the 4-layer template (CLAUDE.md, AGENTS.md, vertical rule, feedback file), MIT, copy-pastable.

RLS Supabase en prod : quatre pièges qui silencent tes requêtes

Michel Faure — Mon, 27 Apr 2026 07:45:29 +0000

« Tes inscriptions, il y en a combien ? Moi j'en vois zéro »

Un mardi matin, je venais d'activer RLS sur dix-huit tables de Rembrandt, l'ERP de L'Atelier Palissy. Les policies étaient écrites, testées en SQL direct, tout passait. Déploiement en prod, café. Françoise m'appelle du bureau d'à côté, elle ne vient pas, elle crie depuis sa chaise. « Bon. Tes inscriptions sur le site de Maisons-Laffitte, il y en a combien, dis-moi ? Moi j'en vois zéro. » J'ouvre la même page sur mon poste. Zéro aussi. Pas d'exception, pas de 500, pas de log d'erreur dans Sentry. Simplement zéro ligne, ce qui est précisément ce qui rend ce bug dangereux : Françoise ne voit rien à corriger, elle voit une école vide.

Row Level Security est une des rares features Postgres/Supabase qui peut casser ton application en silence. Un mauvais réglage ne te renvoie pas d'erreur. Il te renvoie un ensemble vide, ou pire, un ensemble partiel qui passe le code sans l'alerter. J'ai passé quatre semaines à tomber sur quatre pièges distincts, à les nommer, à les documenter. Cet article les rassemble.

Si tu as 30 secondes. RLS bien configurée est le meilleur garde-fou de données que tu puisses poser sur une base Supabase. RLS mal configurée est le pire bug parce qu'elle ne crie jamais. Les quatre pièges : mauvais client Supabase côté Server, RPC SECURITY DEFINER ouvertes à anon, policies d'écriture sans role check, bucket Storage public oublié. Chacun a un symptôme silencieux — requête vide, endpoint public, écriture autorisée, fichier exposé — et une correction en cinq minutes une fois la cause trouvée. L'article donne les quatre symptômes et les quatre corrections.

Piège 1 — Le mauvais client côté Server Component

C'est le piège qui a mis Françoise devant une école vide. Supabase expose trois clients distincts, et leur différence ne se voit pas au premier regard.

createSupabaseBrowser() avec la anon key, côté navigateur
createSupabaseServer() avec la anon key plus le cookie d'auth, côté Server Component
createSupabaseAdmin() avec la service_role key, côté serveur, bypass RLS

Le piège : si tu utilises createSupabaseServer() dans un Server Component mais que le cookie d'auth ne transite pas correctement — middleware mal configuré, refresh token expiré, route proxy qui reforme la requête —, le JWT tombe à anon. Aucune policy ne matche pour un utilisateur anon. La requête retourne zéro ligne. Pas d'erreur, parce que techniquement la requête est valide, Postgres a juste trouvé que rien ne matche.

La règle que j'ai fini par écrire dans mon CLAUDE.md et dans un skill auto-invoqué par l'agent : dans un Server Component, utiliser createSupabaseAdmin(), jamais createSupabaseServer(). L'authentification est déjà vérifiée en amont par le middleware qui garde la route, la service_role n'atteint jamais le navigateur, et les requêtes retournent ce qu'elles doivent retourner.

// ❌ Silencieusement vide si l'auth ne passe pas
import { createSupabaseServer } from '@/lib/supabase-server'
const supabase = createSupabaseServer()
const { data } = await supabase.from('inscriptions').select('*')
// data = [] sans erreur

// ✅ L'auth est déjà vérifiée par le middleware, RLS bypassée
import { createSupabaseAdmin } from '@/lib/supabase-admin'
const admin = createSupabaseAdmin()
const { data } = await admin.from('inscriptions').select('*')

Piège 2 — Les fonctions RPC ouvertes à `anon`

Deuxième piège, plus vicieux parce qu'il te rend les données en sens inverse : tu n'as pas trop peu, tu as trop de monde qui peut lire.

Supabase génère des endpoints REST pour toutes tes fonctions Postgres déclarées en SECURITY DEFINER, et par défaut PUBLIC a les droits d'exécution. Or PUBLIC dans Postgres inclut le rôle anon, qui est le rôle utilisé quand quelqu'un tape un curl sur ton endpoint sans token. Autrement dit, tes fonctions de calcul — pay_echeance_tx, publier_planning_tx, convertir_sd_tx — sont exposées par défaut à n'importe qui sur internet.

J'ai découvert ça en auditant la surface publique avec la requête de contrôle suivante :

-- Liste les fonctions executables par anon (dangereux par défaut)
SELECT p.proname, n.nspname
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public'
  AND has_function_privilege('anon', p.oid, 'EXECUTE');

Elle m'a sorti quinze fonctions que je n'avais jamais voulu exposer. Correction en bloc et ALTER DEFAULT PRIVILEGES pour que les futures fonctions héritent des bons droits :

-- Fermer toutes les fonctions existantes à anon
REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;
GRANT  EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO authenticated, service_role;

-- Que les futures fonctions héritent de la règle
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT  EXECUTE ON FUNCTIONS TO authenticated, service_role;

Les flux publics légitimes — formulaire d'inscription, signature d'émargement par QR code — transitent tous par des API routes Next.js qui utilisent la service_role. Révoquer anon n'a rien cassé. Ce qui aurait dû être le comportement par défaut, et qui ne l'est pas.

Piège 3 — Les policies d'écriture sans role check

Troisième piège. Tu actives RLS sur une table, tu écris une policy SELECT qui dit que tout utilisateur authentifié peut lire. Tu oublies d'écrire la policy INSERT / UPDATE / DELETE, et Supabase fait le pire choix possible : il autorise, parce qu'en Postgres, sans policy d'écriture explicite, la table est ouverte à tout rôle qui a le droit Postgres de base.

Autrement dit, n'importe quel utilisateur authentifié peut écrire dans n'importe quelle table dont tu n'as posé que la policy de lecture. Un élève qui a un compte peut insérer une ligne dans contrats_formateurs. Il ne le fera pas, mais il pourrait, et le jour où un compte est compromis, le périmètre d'attaque est toute ta base.

Le pattern que j'applique désormais sur toute nouvelle table : une policy SELECT pour staff+, une policy INSERT / UPDATE / DELETE pour admin+ seulement, avec role check explicite sur user_roles.

-- Lecture staff et au-dessus
CREATE POLICY "select_staff" ON contrats_formateurs
  FOR SELECT TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('staff', 'admin', 'super_admin')
    )
  );

-- Écriture admin uniquement
CREATE POLICY "write_admin" ON contrats_formateurs
  FOR ALL TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  )
  WITH CHECK (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  );

Le WITH CHECK est la moitié qu'on oublie toujours. Sans lui, un utilisateur autorisé à écrire peut écrire une ligne qu'il ne serait pas autorisé à lire ensuite. C'est un classique des audits RLS : la politique de lecture et la politique d'écriture doivent converger, ou le système devient incohérent.

Piège 4 — Le bucket Storage public oublié

Dernier piège, celui qui fait les gros titres quand il fuite. Tu crées un bucket Supabase Storage pour stocker des signatures manuscrites, des pièces justificatives, des photos d'identité — bref, des données soumises au RGPD. Par défaut, le bucket est public. Tu as probablement posé RLS sur tes tables, tu es fier, tu oublies que les fichiers vivent à côté, avec leurs propres règles.

Concrètement : n'importe qui connaissant l'URL d'un fichier peut le télécharger, et l'URL est parfois traçable, devinable, ou exposée dans un path enregistré en clair dans une colonne de ta base. J'ai mis trois semaines à m'en apercevoir. La correction tient en deux étapes.

Étape 1 : passer le bucket en privé via le dashboard Supabase, ou par migration :

UPDATE storage.buckets
SET public = false
WHERE name = 'signatures';

Étape 2 : côté code, ne plus utiliser getPublicUrl() mais stocker le path et servir le fichier via une API route authentifiée qui vérifie la permission et retourne un signed URL expirant en cinq minutes.

// ❌ URL publique, valable pour toujours, indexable
const { data } = supabase.storage
  .from('signatures')
  .getPublicUrl(path)

// ✅ Signed URL expirant, après vérification de permission
const { data } = await supabaseAdmin.storage
  .from('signatures')
  .createSignedUrl(path, 60 * 5)  // 5 minutes

Le cinquième piège, en bonus, celui qu'on ne voit pas venir

Il y en a un autre, plus rare mais spectaculaire quand il se déclenche : la récursion infinie sur les policies user_roles. Si ta policy sur user_roles utilise elle-même un EXISTS (SELECT 1 FROM user_roles...) pour vérifier le rôle, tu as créé une boucle : lire user_roles appelle la policy qui lit user_roles qui appelle la policy. Postgres te renvoie une erreur infinite recursion detected in policy, et toutes les requêtes qui passent par cette table échouent.

La parade : la policy user_roles ne peut pas référencer user_roles. Elle doit être formulée sur auth.email() directement, ou contourner via une SECURITY DEFINER, ou — ce que j'ai fait pendant plusieurs semaines avant de trouver mieux — laisser la table accessible en read-only à tout authentifié et protéger l'écriture ailleurs.

Ce que tu peux copier dans ton projet

Quatre réflexes directement applicables :

Audit de la surface anon — la requête SQL ci-dessus sort en trente secondes la liste des fonctions exposées. Si tu n'as jamais fait cet audit, fais-le aujourd'hui
createSupabaseAdmin() par défaut côté Server Component — l'auth est déjà vérifiée en amont par ton middleware. Le client SSR avec anon key est une usine à requêtes vides silencieuses
Un couple USING + WITH CHECK sur chaque policy d'écriture. Pas de politique d'écriture sans check. Pas de politique de lecture sans politique d'écriture
Un script de diff qui liste les tables avec RLS activée mais sans *policies* — c'est un piège classique à la création d'une nouvelle table, et le meilleur moment de le corriger est tout de suite

Et une discipline plus large : un système de permissions qui ne crie pas quand il échoue est un système dangereux. RLS est puissante parce qu'elle est invisible, et c'est aussi pour ça qu'elle te coûtera cher. Instrumente-la : audite la surface anon mensuellement, logue les requêtes qui reviennent vides sur des pages censées être peuplées, alerte quand un bucket change de visibilité.

Et vous, votre dernière requête qui renvoyait zéro ligne en prod, c'était vraiment zéro ligne, ou RLS qui la filtrait en silence ? Je lis les commentaires.

Code compagnon : rembrandt-samples/rls-supabase/ — l'audit de surface anon, le couple SELECT + WRITE avec WITH CHECK, le pattern user_roles sans récursion, la migration de privatisation Storage, le guide de sélection de client, et le détecteur RLS-sans-policies. Licence MIT.

Supabase RLS in production: four traps that silence your queries

Michel Faure — Mon, 27 Apr 2026 07:45:26 +0000

« Your enrollments — how many? Because I see zero »

One Tuesday morning, I had just enabled RLS on eighteen tables of Rembrandt, L'Atelier Palissy's ERP. Policies written, tested in direct SQL, everything passing. Prod deploy, coffee. Françoise calls from the next office — she doesn't come over, she shouts from her chair. « Bon. Tes inscriptions sur le site de Maisons-Laffitte, il y en a combien, dis-moi ? Moi j'en vois zéro. » — Right. Your enrollments on the Maisons-Laffitte site, how many are there? Because I see zero. I open the same page on my machine. Zero too. No exception, no 500, no Sentry error log. Just zero rows, which is precisely what makes the bug dangerous: Françoise sees nothing to fix, she sees an empty school.

Row Level Security is one of the rare Postgres/Supabase features that can break your application silently. A misconfiguration doesn't return an error. It returns an empty set, or worse, a partial set that passes through code without alerting it. I spent four weeks running into four distinct traps, naming them, documenting them. This article gathers them.

If you have 30 seconds. Well-configured RLS is the best data guardrail you can put on a Supabase database. Misconfigured RLS is the worst bug because it never screams. The four traps: wrong Supabase client in Server Components, RPC SECURITY DEFINER open to anon, write policies without role check, forgotten public Storage bucket. Each has a silent symptom — empty query, public endpoint, open write, exposed file — and a five-minute fix once the cause is found. The article gives the four symptoms and the four fixes.

Trap 1 — The wrong client in a Server Component

This is the trap that put Françoise in front of an empty school. Supabase exposes three distinct clients, and their difference isn't obvious at first glance.

createSupabaseBrowser() with the anon key, client-side in the browser
createSupabaseServer() with the anon key plus the auth cookie, server-side in a Server Component
createSupabaseAdmin() with the service_role key, server-side, bypasses RLS

The trap: if you use createSupabaseServer() in a Server Component but the auth cookie doesn't transit correctly — misconfigured middleware, expired refresh token, proxy route reshaping the request — the JWT falls back to anon. No policy matches for an anon user. The query returns zero rows. No error, because technically the query is valid; Postgres simply found nothing that matched.

The rule I eventually wrote in my CLAUDE.md and in an auto-invoked agent skill: in a Server Component, use createSupabaseAdmin(), never createSupabaseServer(). Authentication is already verified upstream by the route-guarding middleware, the service_role never reaches the browser, and queries return what they're supposed to.

// ❌ Silently empty if auth doesn't pass
import { createSupabaseServer } from '@/lib/supabase-server'
const supabase = createSupabaseServer()
const { data } = await supabase.from('inscriptions').select('*')
// data = [] with no error

// ✅ Auth already verified by middleware, RLS bypassed
import { createSupabaseAdmin } from '@/lib/supabase-admin'
const admin = createSupabaseAdmin()
const { data } = await admin.from('inscriptions').select('*')

Trap 2 — RPC functions open to `anon`

Second trap, more insidious because it hurts in the opposite direction: you don't have too few readers, you have too many.

Supabase generates REST endpoints for every Postgres function declared SECURITY DEFINER, and by default PUBLIC has execution rights. And PUBLIC in Postgres includes the anon role, which is the role used when someone hits your endpoint with curl without a token. In other words, your calculation functions — pay_echeance_tx, publier_planning_tx, convertir_sd_tx — are exposed by default to anyone on the internet.

I discovered this by auditing the public surface with the following control query:

-- List functions executable by anon (dangerous by default)
SELECT p.proname, n.nspname
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public'
  AND has_function_privilege('anon', p.oid, 'EXECUTE');

It returned fifteen functions I had never wanted to expose. Bulk fix, plus ALTER DEFAULT PRIVILEGES so future functions inherit the right permissions:

-- Close all existing functions to anon
REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;
GRANT  EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO authenticated, service_role;

-- So future functions inherit the rule
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT  EXECUTE ON FUNCTIONS TO authenticated, service_role;

Legitimate public flows — enrollment form, QR-code attendance signing — all go through Next.js API routes that use the service_role. Revoking anon broke nothing. What should have been the default behavior, and isn't.

Trap 3 — Write policies without a role check

Third trap. You enable RLS on a table, you write a SELECT policy saying any authenticated user can read. You forget to write the INSERT / UPDATE / DELETE policy, and Supabase makes the worst possible choice: it allows it, because in Postgres, without an explicit write policy, the table is open to any role with basic Postgres rights.

In other words, any authenticated user can write to any table where you only set the read policy. A student with an account can insert a row into contrats_formateurs. They won't, but they could, and the day an account gets compromised, the attack surface is your whole database.

The pattern I now apply to every new table: a SELECT policy for staff+, an INSERT / UPDATE / DELETE policy for admin+ only, with explicit role check against user_roles.

-- Read for staff and above
CREATE POLICY "select_staff" ON contrats_formateurs
  FOR SELECT TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('staff', 'admin', 'super_admin')
    )
  );

-- Write for admin only
CREATE POLICY "write_admin" ON contrats_formateurs
  FOR ALL TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  )
  WITH CHECK (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  );

The WITH CHECK is the half that's always forgotten. Without it, a user allowed to write can write a row they would not be allowed to read back. It's a classic in RLS audits: read policy and write policy must converge, or the system becomes inconsistent.

Trap 4 — The forgotten public Storage bucket

Last trap, the one that makes headlines when it leaks. You create a Supabase Storage bucket to store handwritten signatures, supporting documents, ID photos — GDPR-sensitive data. By default, the bucket is public. You've probably set RLS on your tables, you're proud, you forget the files live alongside, with their own rules.

Concretely: anyone who knows a file's URL can download it, and the URL is sometimes traceable, guessable, or exposed as a plain-text path in a database column. It took me three weeks to notice. The fix is two steps.

Step 1: make the bucket private via the Supabase dashboard, or by migration:

UPDATE storage.buckets
SET public = false
WHERE name = 'signatures';

Step 2: in code, stop using getPublicUrl(). Store the path instead and serve the file through an authenticated API route that checks permission and returns a signed URL expiring in five minutes.

// ❌ Public URL, valid forever, indexable
const { data } = supabase.storage
  .from('signatures')
  .getPublicUrl(path)

// ✅ Expiring signed URL, after permission check
const { data } = await supabaseAdmin.storage
  .from('signatures')
  .createSignedUrl(path, 60 * 5)  // 5 minutes

The fifth trap, as a bonus, the one you don't see coming

There's another, rarer but spectacular when it fires: the infinite recursion on user_roles policies. If your policy on user_roles itself uses an EXISTS (SELECT 1 FROM user_roles…) to verify the role, you've created a loop: reading user_roles calls the policy that reads user_roles that calls the policy. Postgres returns an infinite recursion detected in policy error, and every query that goes through that table fails.

The fix: the user_roles policy can't reference user_roles. It has to be formulated on auth.email() directly, or routed through a SECURITY DEFINER, or — what I did for several weeks before finding better — leave the table readable to any authenticated user and protect writes elsewhere.

What you can copy into your project

Four directly applicable reflexes:

Audit of the anon surface — the SQL query above returns, in thirty seconds, the list of exposed functions. If you've never run this audit, do it today
createSupabaseAdmin() by default in Server Components — auth is already verified upstream by your middleware. The SSR client with anon key is a silent-empty-query factory
A USING + WITH CHECK pair on every write policy. No write policy without a check. No read policy without a write policy
A diff script that lists tables with RLS enabled but no policies — it's a classic trap when creating a new table, and the best time to fix it is immediately

And a broader discipline: a permission system that doesn't scream when it fails is a dangerous system. RLS is powerful because it's invisible, and that's also why it will cost you. Instrument it: audit the anon surface monthly, log queries that come back empty on pages that should be populated, alert when a bucket changes visibility.

And you — your last query that returned zero rows in production, was it really zero rows, or RLS filtering silently? I read the comments.

Companion code: rembrandt-samples/rls-supabase/ — the anon-surface audit, the SELECT + WRITE policy pair with WITH CHECK, the recursion-safe user_roles pattern, the storage privatization migration, the client selection guide, and the RLS-without-policies detector. MIT, copy-pastable.

Combien vaut 91 000 lignes produites avec Claude Code ?

Michel Faure — Sun, 26 Apr 2026 08:29:52 +0000

TL;DR

J'ai codé l'ERP de notre école d'art en 91 000 lignes, en 4 semaines, avec Claude Code. Mon dashboard l'a valorisé entre 230 000 et 430 000 €. Un week-end plus tôt, je venais de comprendre qu'un pack de consulting à 5 chiffres signé quelques mois plus tôt chez un éditeur ERP commercial ne valait plus rien pour nous. Voici comment j'ai découvert que la méthode « lignes × TJM avec décote IA » ne résistera à aucun audit sérieux en 2027, et vers quoi j'ai pivoté.

Qui écrit ceci

Je m'appelle Michel Faure. Je dirige L'Atelier Palissy, un réseau d'ateliers de céramique à l'ancienne, six sites à Paris et en région parisienne. Je ne suis pas développeur de formation. Je pilote une structure où il faut faire tourner inscriptions, planning, facturation, communication, conformité Qualiopi et finance pour plusieurs centaines d'élèves. Depuis quatre semaines, je code l'ERP métier qui remplace notre empilement d'outils. Seul, avec Claude Code.

C'est le contexte de ce que je raconte ici.

Le chiffre qui ne tient pas

Au 14 avril 2026, mon dashboard affichait fièrement : 90 947 lignes, 345 commits, valorisation 230 à 430 k€. Je le regardais chaque matin. Il gamifiait le travail, il donnait une direction, il justifiait le temps investi.

Le calcul était simple, et c'est ce qui le rendait séduisant :

TJM senior Next.js/Supabase      : 500-700 €/jour
Productivité standard            : ~125 lignes/jour
Facteur conception/debug/intégr. : × 2,5
Décote assistance IA             : ÷ 3 à 5

Chaque ligne de code valait donc, selon ce modèle, entre 8 et 14 €. 91 000 lignes × fourchette × pondération métier = environ 300 k€ au centre. Défendable en apparence.

Sauf qu'à force de regarder ce chiffre monter, un doute s'est installé. Et ce doute avait une histoire.

Le week-end qui a tout changé

Quelques mois avant de démarrer Rembrandt — c'est le nom que j'ai donné à notre ERP — nous avions fait ce que font la plupart des PME françaises : nous avions signé avec un éditeur ERP commercial européen très connu. Licences annuelles, un pack de consulting à 5 chiffres, engagement contractuel reconduit tacitement, facturation des développements custom au nombre de lignes produites.

Le déploiement devait résoudre nos problèmes. Je n'ai pas attendu la fin du déploiement pour me poser une question simple, un samedi matin : et si je faisais un prototype de notre workflow métier moi-même, en un week-end, avec Claude Code ?

Lundi soir, le prototype couvrait 70 % de nos besoins critiques. Pas 70 % de la promesse de l'éditeur : 70 % de notre réalité. Cours, places, inscriptions, émargement, flux doré lead → inscription. Fonctionnel, déployé, utilisable.

Ce week-end a fait basculer deux choses :

Le pack de consulting payé ne servait plus à rien. Sur les 100 heures de prestations prévues, zéro avaient été consommées. L'éditeur a refusé le remboursement. Position ferme.
La facturation au nombre de lignes devenait absurde. Payer au LOC pour du code custom quand j'en produisais 3 000 lignes par jour avec Claude Code, c'était monétiser une unité dont le coût réel avait été divisé par dix.

Et pourtant, tenir ce choix a été beaucoup plus difficile que la décision technique. Parce qu'on avait déjà payé. Parce que l'éditeur ne remboursait pas. Parce que toute la logique de rentabilisation de l'investissement initial poussait à continuer. Le biais du coût irrécupérable, vécu en direct.

C'est en sortant de ce dilemme que j'ai commencé à regarder mon propre dashboard de valorisation avec suspicion.

Les trois défauts structurels du modèle LOC

1. Le modèle va dans le sens inverse du coût réel

Claude Code continue de progresser. Cursor aussi. Les assistants spécialisés aussi. Le coût d'écriture d'une ligne a été divisé par 10 en 18 mois, et la trajectoire n'est pas terminée.

Plus je produis vite, plus le dashboard monte — alors que le coût marginal de production chute. À l'horizon 2028, je pourrais afficher 200 000 lignes à 500 k€ pour un coût réel de quelques dizaines de k€. Aucun expert-comptable ne signera ça. Aucun repreneur ne paiera ça. La métrique ment de plus en plus fort avec le temps.

2. Le modèle écrase commodité et singulier

10 000 lignes de CRUD générique sur des contacts et des formulaires sont remplaçables par un SaaS à 100 €/mois. 10 000 lignes de logique rattrapage × 4 périodes × 6 sites × règles Qualiopi sont non-substituables.

Même volume, valeurs réelles × 100 différentes. Un compteur LOC ne voit pas cette différence. Il compte des octets, pas de la valeur.

3. Le modèle rend invisibles les actifs non-code

Mon ERP contient environ 3 000 contacts historicisés, 5 000 leads qualifiés, 800 inscriptions, 3 ans d'historique financier, et 16 décisions d'architecture (ADR) qui capturent la logique métier en connaissance de cause. Aucune ligne de code, une part significative de la valeur patrimoniale.

Le jour où quelqu'un rachèterait l'outil, c'est autant sur les données et sur le capital décisionnel que sur le code qu'il paierait. Mon modèle LOC les rendait invisibles.

Le pivot : quatre dimensions

J'ai formalisé la refonte dans un ADR et j'ai retenu quatre axes :

Dimension	Nature	Calcul
Coût de remplacement SaaS	Contrefactuel : ce que je paierais si l'ERP n'existait pas	Σ abonnements équivalents × 5 ans actualisé 8 %
Valeur d'usage	Productivité humaine économisée	Heures/trimestre × coût horaire chargé × 5 ans
Valeur patrimoniale données	Actif immatériel non régénérable	Volumes × prix unitaire marché + capital ADR
Valeur stratégique	Optionalité et souveraineté	Vélocité, absence lock-in, alignement IA

La valorisation consolidée est la somme des quatre, pas un max, pas une moyenne. Chaque dimension produit un intervalle min/centre/max, et chaque euro affiché peut être justifié par une méthode transparente et une source traçable.

Le compteur de lignes reste dans le dashboard, mais dégradé au rang d'indicateur de volume de production — l'équivalent du nombre de pages d'un livre pour un auteur. Il n'entre plus dans la valorisation monétaire.

Ce que ça change concrètement

La valeur affichée ne diverge plus du coût réel de production
Une baisse du prix de la ligne à 5 €/ligne en 2028 ne casse pas le modèle, parce que le modèle n'en dépend plus
La dimension 1 produit naturellement une liste de concurrents à surveiller : si un SaaS vertical couvre 80 % du scope à 200 €/mois, le signal stratégique est immédiat
Le dialogue avec l'expert-comptable devient direct : les 4 dimensions mappent sur les catégories comptables classiques (investissement équivalent, productivité, actif immatériel, goodwill)
Les achievements « 100k, 150k lignes » disparaissent du dashboard : ils récompensaient le volume, pas la valeur

Le moment où j'ai vraiment basculé

Le même jour, plus tard. J'ai posé mon garde-fou de vingt lignes pour que le compteur ne me mente plus sur les dumps SQL, et je pense avoir gagné la matinée. Vers dix-sept heures, je retourne regarder le delta nettoyé du bruit : 4 281 lignes produites en vrai sur la journée, sans le dump. Je m'apprête à me féliciter, et je m'arrête.

Ces 4 281 lignes, je sais ce qu'elles contiennent. Majoritairement, c'est de l'instrumentation Sentry, deux scripts CI qui durcissent un chantier déjà écrit, un refactor d'émargement qui n'ajoute aucune fonctionnalité. De la dette qui se rembourse, pas de la valeur qui se crée. Sur le papier, toutes égales devant le compteur. Dans les faits, la dette remboursée n'est pas un actif, elle est un non-passif.

Je comprends là, précisément, que nettoyer les entrées n'aurait jamais suffi. La métrique que j'avais voulue n'était pas sale, elle était structurellement incapable de voir la différence entre produire de la valeur, rembourser de la dette, et importer du texte. Trois natures économiques distinctes, un seul compteur, un seul euro par ligne. Aucune décote IA, aucun facteur pondérateur, aucune correction statistique ne rattraperait cet écrasement.

La décision de pivoter n'a rien pris de plus que d'écrire cette phrase sur un post-it et de la coller au bord de l'écran. Le lendemain matin, j'ai ouvert l'ADR-0009.

Ce que je n'ai pas encore résolu

La refonte complète du module de valorisation représente une dizaine d'heures réparties en trois vagues. La dimension « valeur d'usage » impose d'instrumenter la mesure des heures gagnées — chronométrer ses collègues est socialement coûteux, l'auto-déclaration trimestrielle est la seule piste soutenable. La dimension « valeur stratégique » reste opinion-driven et exige un cadrage explicite des hypothèses pour rester défendable.

Enfin, la bascule produit une discontinuité dans le dashboard. Passer de 300 k€ à 450 k€ du jour au lendemain sans avoir écrit une ligne de code supplémentaire, ça demande une annotation visuelle et une note de méthodologie, sinon ça se lit comme un gain suspect.

Trois choses à retenir

La ligne de code n'est plus une unité de valeur à l'ère de l'agent coding. Elle redevient ce qu'elle aurait toujours dû être : un indicateur de volume de production, rien de plus.
Valorisez ce que votre code remplace, fait gagner, capture, et rend possible — pas ce qu'il a coûté à écrire. Le coût de production continue de chuter, la valeur créée ne suit pas la même pente.
La vraie question n'est pas ce que vous avez déjà dépensé, c'est ce que vous économiserez si vous arrêtez maintenant. C'est la leçon la plus dure à tenir. Elle ne se démontre pas avec un tableau Excel. Elle se tient contre soi-même, contre le poids des investissements passés, contre la pression sociale de « finir ce qu'on a commencé ».

Et vous ?

Si vous codez avec un assistant IA et que vous vous posez la question de la valeur de votre travail, je suis curieux : comment la mesurez-vous, aujourd'hui ? Et si vous avez déjà fait le pivot « rentabiliser un ERP commercial vs construire un outil sur-mesure avec l'IA », racontez. Les commentaires sont ouverts.

Cet article fait partie d'une série sur le développement d'un ERP de 91 000 lignes en 4 semaines avec Claude Code pour L'Atelier Palissy, école d'art céramique. Le prochain article détaille la méthode à 4 dimensions dans le concret, avec les formules et les seeds initiaux du module.

Code compagnon : rembrandt-samples/valorisation/ — le pattern consolidate(dims) à quatre dimensions et le garde-fou Slack sur le compteur de LOC, licence MIT.

How much are 91,000 lines produced with Claude Code actually worth?

Michel Faure — Sun, 26 Apr 2026 08:27:41 +0000

TL;DR

I coded my art school's ERP in 91,000 lines, in 4 weeks, with Claude Code. My dashboard valued it between €230,000 and €430,000. A weekend earlier, I had just understood that a five-figure consulting package signed a few months before with a commercial ERP vendor was worth nothing to us anymore. Here's how I discovered that the "lines × day-rate with AI discount" method will not survive any serious audit in 2027, and what I pivoted toward.

Who is writing this

My name is Michel Faure. I run L'Atelier Palissy, a network of traditional ceramics workshops, six sites in Paris and the greater Paris area. I'm not a developer by training. I run a structure that has to keep enrollments, scheduling, billing, communication, Qualiopi compliance and finance working for several hundred students. For four weeks, I've been coding the business ERP that replaces our pile of tools. Alone, with Claude Code.

That's the context for everything that follows.

The number that doesn't hold

As of April 14th, 2026, my dashboard proudly displayed: 90,947 lines, 345 commits, valuation €230k–€430k. I looked at it every morning. It gamified the work, gave it direction, justified the time invested.

The calculation was simple, which is what made it seductive:

Senior Next.js/Supabase day-rate   : €500–€700/day
Standard productivity              : ~125 lines/day
Design/debug/integration factor    : × 2.5
AI assistance discount             : ÷ 3 to 5

Each line of code was therefore worth, according to this model, between €8 and €14. 91,000 lines × range × business weighting = around €300k at the center. Apparently defensible.

Except that as I watched the number climb, a doubt settled in. And that doubt had a history.

The weekend that changed everything

A few months before starting Rembrandt — that's the name I gave our ERP — we had done what most French SMBs do: we had signed with a well-known European commercial ERP vendor. Annual licenses, a five-figure consulting package, contractually renewed tacitly, billing of custom developments per line of code produced.

The rollout was supposed to solve our problems. I didn't wait for the end of the rollout to ask myself a simple question, one Saturday morning: what if I built a prototype of our business workflow myself, in a weekend, with Claude Code?

By Monday evening, the prototype covered 70% of our critical needs. Not 70% of the vendor's promise: 70% of our reality. Courses, seats, enrollments, attendance, golden flow lead → enrollment. Functional, deployed, usable.

That weekend flipped two things:

The paid consulting package no longer served any purpose. Of the 100 hours of services planned, zero had been consumed. The vendor refused the refund. Firm position.
Billing per line became absurd. Paying per LOC for custom code when I was producing 3,000 lines a day with Claude Code was monetizing a unit whose real cost had been divided by ten.

And yet, holding that choice was much harder than the technical decision. Because we had already paid. Because the vendor wasn't refunding. Because the whole logic of amortizing the initial investment was pushing to continue. The sunk-cost fallacy, lived in real time.

It's by coming out of that dilemma that I started looking at my own valuation dashboard with suspicion.

The three structural flaws of the LOC model

1. The model runs counter to real cost

Claude Code keeps improving. Cursor too. Specialized assistants too. The cost of writing a line has been divided by 10 in 18 months, and the trajectory isn't over.

The faster I produce, the higher the dashboard climbs — while marginal production cost falls. By 2028, I could display 200,000 lines at €500k for a real cost of a few tens of thousands of euros. No accountant will sign that. No buyer will pay that. The metric lies louder and louder over time.

2. The model flattens commodity and singular

10,000 lines of generic CRUD on contacts and forms are replaceable by a SaaS at €100/month. 10,000 lines of catch-up logic × 4 periods × 6 sites × Qualiopi rules are non-substitutable.

Same volume, real values × 100 different. A LOC counter doesn't see that difference. It counts bytes, not value.

3. The model makes non-code assets invisible

My ERP contains around 3,000 historicized contacts, 5,000 qualified leads, 800 enrollments, 3 years of financial history, and 16 architecture decisions (ADRs) that capture the business logic knowingly. Not a line of code, a significant share of the patrimonial value.

The day someone were to buy the tool, they would pay for the data and the decisional capital as much as for the code. My LOC model made them invisible.

The pivot: four dimensions

I formalized the overhaul in an ADR and kept four axes:

Dimension	Nature	Calculation
SaaS replacement cost	Counterfactual: what I'd pay if the ERP didn't exist	Σ equivalent subscriptions × 5 years discounted at 8%
Usage value	Human productivity saved	Hours/quarter × loaded hourly cost × 5 years
Data patrimonial value	Non-regeneratable intangible asset	Volumes × market unit price + ADR capital
Strategic value	Optionality and sovereignty	Velocity, lock-in absence, AI alignment

The consolidated valuation is the sum of the four, not a max, not an average. Each dimension produces a min/center/max range, and every displayed euro can be justified by a transparent method and a traceable source.

The line counter stays in the dashboard but is demoted to the rank of production-volume indicator — the equivalent of a book's page count for an author. It no longer enters the monetary valuation.

What it changes concretely

The displayed value no longer diverges from real production cost
A drop in the line price to €5/line in 2028 doesn't break the model, because the model no longer depends on it
Dimension 1 naturally produces a list of competitors to watch: if a vertical SaaS covers 80% of the scope at €200/month, the strategic signal is immediate
The dialogue with the accountant becomes direct: the 4 dimensions map onto classic accounting categories (equivalent investment, productivity, intangible asset, goodwill)
The "100k, 150k lines" achievements disappear from the dashboard: they rewarded volume, not value

The moment I really flipped

The same day, later. I had set my twenty-line guardrail so the counter would stop lying to me about SQL dumps, and I thought I'd won the morning. Around five in the afternoon, I go back to look at the delta cleaned of noise: 4,281 lines actually produced on the day, without the dump. I'm about to congratulate myself, and I stop.

Those 4,281 lines, I know what they contain. Mostly Sentry instrumentation, two CI scripts hardening a workflow already written, an attendance refactor that adds no functionality. Debt being repaid, not value being created. On paper, all equal before the counter. In fact, repaid debt isn't an asset, it's a non-liability.

I understand right there, precisely, that cleaning the inputs would never have been enough. The metric I had wanted wasn't dirty, it was structurally incapable of seeing the difference between producing value, repaying debt, and importing text. Three distinct economic natures, one counter, one euro per line. No AI discount, no weighting factor, no statistical correction would rescue that flattening.

The decision to pivot took no more than writing that sentence on a sticky note and sticking it to the edge of the screen. The next morning, I opened ADR-0009.

What I haven't yet resolved

The full overhaul of the valuation module represents about ten hours spread over three waves. The "usage value" dimension requires instrumenting hour measurements — timing your colleagues is socially costly, quarterly self-reporting is the only sustainable path. The "strategic value" dimension remains opinion-driven and requires an explicit framing of assumptions to stay defensible.

Finally, the switch produces a discontinuity in the dashboard. Going from €300k to €450k overnight without having written one additional line of code demands a visual annotation and a methodology note; otherwise it reads as a suspicious gain.

Three things to remember

The line of code is no longer a unit of value in the era of agent coding. It becomes what it always should have been: a production-volume indicator, nothing more.
Value what your code replaces, saves, captures, and makes possible — not what it cost to write. Production cost keeps falling, created value doesn't follow the same slope.
The real question isn't what you've already spent, it's what you'll save if you stop now. That's the hardest lesson to hold. It can't be proved with a spreadsheet. It holds against yourself, against the weight of past investments, against the social pressure to "finish what you started".

What about you?

If you code with an AI assistant and wonder about the value of your work, I'm curious: how do you measure it, today? And if you've already done the pivot "amortize a commercial ERP vs. build a custom tool with AI", share. Comments are open.

This article is part of a series on building a 91,000-line ERP in four weeks with Claude Code for L'Atelier Palissy, an art school. The next article details the four-dimension method in practice, with formulas and the module's initial seeds.

Companion code: rembrandt-samples/valorisation/ — the four-dimension consolidate(dims) pattern and Slack guardrail on the LOC counter, MIT, copy-pastable.

Forem: Michel Faure

28 % de glue code, une CI pour que ça n'augmente pas

Le jour où lib/ a cessé d'être lisible

Le cadre qui m'a manqué pendant trois semaines

Le script, cent trente lignes

Le piège des types auto-générés

La CI qui bloque la régression, pas l'absolu

Pourquoi une règle écrite dans CLAUDE.md ne suffit pas

Ce que tu peux copier dans ton projet

28% glue code, a CI rule to keep it from growing

The day lib/ stopped being readable

The framing I missed for three weeks

The script, one hundred and thirty lines

The auto-generated types trap

The CI that blocks regression, not an absolute

Why a rule written in CLAUDE.md isn't enough

What you can copy into your project

J'ai ajouté 20 lignes de code pour empêcher mon ERP de me mentir

Hook

Le vide de prix

Le détour par l'extérieur

Le week-end de la bascule

Trois dérives que le compteur ne voit pas

Le garde-fou qui a tranché

Le dispositif de jugement

Ce que ça donne en code

Ce que tu peux copier dans ton projet

I added 20 lines of code to stop my ERP from lying to me

Hook

The price void

The detour through the outside

The weekend that flipped

Three drifts the counter can't see

The guardrail that settled it

The judgment device

What it looks like in code

What you can copy into your own project

4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul

Pourquoi pas juste un README

Version initiale, quarante lignes de naïveté

Quatre incidents, quatre règles

1. Server Component + onClick, le crash silencieux

2. RLS + mauvais client Supabase, zéro ligne sans erreur

3. Build vert surestimé, la règle qui contraint l'agent à se prouver

4. 1 inscription = N places, le contre-modèle métier

La structure actuelle

Ce que j'ai appris en quatre semaines

Ce que tu peux copier dans ton projet

À vous

4 incidents, 4 rules: how my CLAUDE.md wrote itself

Why not just a README

Initial version, forty lines of naiveté

Four incidents, four rules

1. Server Component + onClick, the silent crash

2. RLS + wrong Supabase client, zero rows without error

3. Overstated green build, the rule that forces the agent to prove itself

4. 1 enrollment = N seats, the business counter-model

The current structure

What I learned in four weeks

What you can copy into your project

Over to you

RLS Supabase en prod : quatre pièges qui silencent tes requêtes

« Tes inscriptions, il y en a combien ? Moi j'en vois zéro »

Piège 1 — Le mauvais client côté Server Component

Piège 2 — Les fonctions RPC ouvertes à anon

Piège 3 — Les policies d'écriture sans role check

Piège 4 — Le bucket Storage public oublié

Le cinquième piège, en bonus, celui qu'on ne voit pas venir

Ce que tu peux copier dans ton projet

Supabase RLS in production: four traps that silence your queries

« Your enrollments — how many? Because I see zero »

Trap 1 — The wrong client in a Server Component

Trap 2 — RPC functions open to anon

Trap 3 — Write policies without a role check

Trap 4 — The forgotten public Storage bucket

The fifth trap, as a bonus, the one you don't see coming

What you can copy into your project

Combien vaut 91 000 lignes produites avec Claude Code ?

TL;DR

Qui écrit ceci

Le jour où `lib/` a cessé d'être lisible

Pourquoi une règle écrite dans `CLAUDE.md` ne suffit pas

The day `lib/` stopped being readable

Why a rule written in `CLAUDE.md` isn't enough

Piège 2 — Les fonctions RPC ouvertes à `anon`

Trap 2 — RPC functions open to `anon`