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 :

1. 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 »
2. 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
3. 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.