DEV Community: Michel Faure

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.

DEV Community: Michel Faure

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 chiffre qui ne tient pas

Le week-end qui a tout changé

Les trois défauts structurels du modèle LOC

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

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

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

Le pivot : quatre dimensions

Ce que ça change concrètement

Le moment où j'ai vraiment basculé

Ce que je n'ai pas encore résolu

Trois choses à retenir

Et vous ?

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

TL;DR

Who is writing this

The number that doesn't hold

The weekend that changed everything

The three structural flaws of the LOC model

1. The model runs counter to real cost

2. The model flattens commodity and singular

3. The model makes non-code assets invisible

The pivot: four dimensions

What it changes concretely

The moment I really flipped

What I haven't yet resolved

Three things to remember

What about you?

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

Trap 2 — RPC functions open to `anon`