Hook

Après avoir enterré la méthode « lignes × TJM avec décote IA » pour mon ERP de 91 000 lignes, je me suis retrouvé devant une question plus dure que la première. Par quoi la remplacer ? J'ai passé deux jours à tester tous les modèles mono-dimensionnels disponibles. Aucun n'a tenu. Voici le cimetière de mes essais, et ce qui a fini par marcher : quatre dimensions, sommées, pas pondérées, avec une règle de déduplication SQL que j'ai mis une semaine à trouver.

Si tu as 30 secondes. Aucune métrique unique ne tient pour valoriser un ERP interne : ARR, coût de remplacement SaaS seul, valeur d'usage seule — tous écrasent la réalité. Cet article propose une méthode à quatre dimensions sommées (SaaS équivalent, usage, données, stratégique), avec la fonction TypeScript de consolidation, la requête SQL de déduplication entre dimensions, et le cron hebdo qui produit un snapshot défendable. Utile si tu dois justifier la valeur d'un logiciel sans prix de marché.

Le cimetière des modèles mono

Premier essai, ARR. La méthode préférée des pitchs SaaS, propre, universellement comprise. J'ai ouvert une feuille, tapé trois formules, et j'ai compris en quinze minutes que je n'avais pas de revenu récurrent à mettre dedans. Rembrandt est un outil interne, pas un produit vendu. ARR mort en quinze minutes.

Deuxième essai, coût de remplacement SaaS. L'idée : « combien L'Atelier Palissy paierait en abonnements si Rembrandt n'existait pas ». J'ai listé Odoo, Brevo, Monday, Digiforma, Edusign. Total mensuel autour de 425 euros, soit une centaine de milliers sur cinq ans, actualisé. Défendable en face d'un expert-comptable. Mais faux à l'envers : aucun SaaS du marché ne couvre les 10 000 lignes de logique de rattrapages quatre périodes par an sur six sites avec règles Qualiopi. Le contrefactuel sous-valorise ce qui fait précisément la spécificité de l'outil. Modèle mort un dimanche soir.

Troisième essai, valeur d'usage seule. « Combien d'heures Rembrandt fait économiser à Françoise, Hélène, Catherine, Claire ». La mesure la plus alignée sur l'économie réelle, et de loin. Mais inapplicable sans friction : chronométrer quelqu'un au bureau est socialement coûteux, et l'auto-déclaration trimestrielle reste biaisée par l'humeur du jour. J'ai commencé à rédiger un formulaire Google. Je l'ai refermé. Modèle mort avant naissance.

Le diagnostic tient en une phrase. Rembrandt est un actif composite qui mélange code, données, productivité évitée et optionalité stratégique. Lui appliquer une métrique unique écrase au moins trois de ces dimensions. Il faut les reconnaître toutes les quatre.

Les quatre dimensions

Chacune mesure une chose réelle que les trois autres ne voient pas. La dimension 1 voit le marché mais pas le singulier. La dimension 2 voit le temps humain mais pas les données. La dimension 3 voit le patrimoine mais pas l'usage. La dimension 4 voit l'avenir possible mais rien de ce qui existe aujourd'hui. Aucune n'est réductible à une autre. C'est précisément ce qui impose d'en avoir quatre.

La règle d'agrégation, somme plutôt que max

C'est le point méthodologique central, et c'est celui qui se discute le plus.

Pourquoi pas le maximum. Prendre le max (« la dimension qui valorise le plus l'emporte ») est une figure rhétorique, pas une méthode. Elle masque trois dimensions sur quatre et produit un chiffre qui ne dit pas ce qu'il mesure. On retombe dans le mono-dimensionnel par la petite porte.

Pourquoi pas la moyenne. La moyenne dissout la différence de nature entre les dimensions. Dire que la valorisation de Rembrandt c'est en moyenne du SaaS, du temps humain, des données et du stratégique, c'est prétendre qu'elles sont commensurables alors qu'elles ne le sont précisément pas.

Pourquoi pas de coefficients pondérés. La pondération introduit un arbitraire supplémentaire qui n'est pas plus défendable que le choix initial des dimensions. On résout un problème en en créant un autre, moins visible.

Reste la somme. Elle n'est pas un agrégat naturel, elle est un parti pris explicite. Elle affirme que chaque dimension existe indépendamment, que le système vaut leur cumul, et que chaque euro affiché est traçable à une source et à une méthode.

En code, le cœur du calcul tient en douze lignes :

// lib/valorisation/compute.ts
type Dim = { id: DimId; low: number | null; high: number | null }

export function consolidate(dims: Dim[]) {
  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 décisions y sont inscrites. On somme sans pondérer. Une dimension non encore instrumentée ne casse pas le calcul — elle s'absente et c'est noté. L'appelant sait toujours quelles dimensions ont participé, ce qui rend chaque snapshot auditable trois mois plus tard.

Le piège de la sur-addition

C'est le passage technique le plus délicat du modèle et je ne l'ai pas vu au début. Un contact historicisé contribue à la fois au patrimoine données (dimension 3) et au coût de remplacement d'un CRM SaaS (dimension 1). Sans correction, on compte deux fois le même actif. J'ai mis une semaine à comprendre que mes intervalles gonflaient parce que je faisais précisément l'erreur qu'une somme naïve autorise.

La parade tient dans une colonne scope_couvert_pct sur la table des SaaS équivalents : chaque SaaS ne compte que pour la part du scope qu'il couvrirait réellement, et la part déjà captée par la dimension 3 est retranchée. La requête de dim.1, au réveil, est celle-ci :

-- dim 1 : coût de remplacement SaaS, avec déduplication dim 3
SELECT
  SUM(
    cout_mensuel_eur * 12
    * (scope_couvert_pct / 100.0)
    * (1 - 0.30)  -- part déjà captée par dim 3 (données CRM)
    * 3.9927      -- VAN annuité 5 ans @ 8%
  ) AS saas_centre
FROM valorisation_saas_equivalents
WHERE actif = true;

Le 1 - 0.30 n'est pas tombé du ciel. C'est la part estimée du scope CRM qui serait déjà payée une fois au titre du patrimoine données (3 000 contacts × prix unitaire marché). Elle est documentée, datée, révisable. Rien n'est magique. Tout est justifiable.

Le rappel hebdomadaire

Un modèle de valorisation qui vit dans une feuille ne tient pas un trimestre. J'ai donc mis le calcul dans un cron hebdomadaire qui fait trois choses le lundi à 4 h du matin :

// app/api/cron/compute-valorisation-donnees/route.ts (extrait)
const centre =
  (contacts + leads + inscriptions) * PRIX_UNITAIRE_CONTACT_EUR +
  ANNEES_HISTORIQUE_FINANCE * VALEUR_ANNEE_HISTORIQUE_EUR +
  adrsCount * VALEUR_ADR_EUR

const donnees_low  = Math.round(centre * 0.75)
const donnees_high = Math.round(centre * 1.25)

await admin.from('valorisation_snapshots').upsert({
  snapshot_date: today,
  donnees_low, donnees_high,
  saas_low, saas_high,
  usage_low, usage_high,
  strategique_low, strategique_high,
  value_low:  sumLow,
  value_high: sumHigh,
}, { onConflict: 'snapshot_date' })

Le cron compte les contacts, leads et inscriptions en direct sur Supabase, recalcule dim 3, relit les dims 1, 2 et 4 (moins volatiles), somme les quatre, et écrit un snapshot daté. Chaque snapshot est un point défendable. La valeur de Rembrandt au 14 avril est une ligne de ma base ; celle au 21 avril sera une autre ligne, avec son explication. On peut remonter, comparer, expliquer les ruptures.

Quatre limites à assumer

La dimension 4 est opinion-driven. Scorée 1-10 sur quatre axes, avec justification écrite. Subjective, et affichée comme telle. La parade : cadrer les hypothèses explicitement, dater chaque score, forcer une révision trimestrielle.

La dimension 2 a un biais optimiste. L'auto-déclaration trimestrielle par Françoise, Hélène, Catherine, Claire reste imparfaite. Elle est corrigée en tendance, pas ponctuellement.

Le cadre impose un coût de maintenance. Saisie des heures, révision des prix SaaS de référence, mise à jour du scoring stratégique, relecture du scope_couvert_pct de chaque SaaS. Une à deux heures par trimestre, pas plus. C'est le prix de la défendabilité.

La dim. 1 peut dériver avec le marché SaaS. Un concurrent qui casse son prix, un outil open source qui monte en charge, et la table valorisation_saas_equivalents devient fausse en silence. Le garde-fou est humain : revue annuelle, notes datées dans chaque ligne.

Le passage chez Étienne

J'avais besoin d'un contradicteur, et j'avais le bon sous la main. Étienne Brossard est mon associé majoritaire — soixante pour cent de Palissy. Il travaille la semaine dans un fonds d'investissement qui rachète des éditeurs de logiciels. Sa thèse professionnelle quotidienne consiste précisément à mettre un prix sur des actifs software dont les vendeurs préféreraient qu'il en mette un autre. Quand il regarde un tableau de valorisation, il ne le lit pas en comptable — il le lit en acquéreur.

Nous nous sommes vus un samedi matin dans un café à mi-chemin entre nos deux bureaux. J'ai sorti le tableau des quatre dimensions sur mon laptop. Il a regardé trente secondes, sans toucher son café, et il a posé sa première question, qui est toujours la même. « Sur quoi c'est calé, la dimension 1 ? » J'ai répondu par la source : la table valorisation_saas_equivalents, onze lignes, prix publics relus en mars, colonne scope_couvert_pct documentée. Hochement. Il est passé à la 3. J'ai cité le cron du lundi 4 h, les comptages Supabase directs, la constante PRIX_UNITAIRE_CONTACT_EUR. Hochement.

La 2 l'a arrêté plus longtemps. « Comment tu chiffres les heures ? » J'ai expliqué l'auto-déclaration trimestrielle, quatre personnes, coût horaire chargé reconstitué à partir du bulletin moyen. « Défendable si tu affiches la méthode. Pas si tu affiches le chiffre seul. Une auto-déclaration sans cadre, c'est ce qui fait sauter une transaction en data room. » Sur la 4, il a été plus rapide. « Ça c'est de l'opinion, pas du chiffre. Affiche-le comme tel, et ça tient. Si tu déguises ça en multiple, on te démonte en quinze minutes. »

Puis il a fermé son carnet et il a dit la phrase que je voulais entendre, sans la chercher. « Il faut bien chorégraphier pour éviter les frictions financières. Ce que tu montres là, je l'ai vu chez quinze boîtes ce trimestre. Trois ont survécu à la due diligence. Toi tu as une chance de plus que les autres : tu as écrit ton modèle avant qu'on te le demande. »

Ce qui vaut dans cette conversation n'est pas qu'Étienne ait validé le tableau. C'est qu'il ait pu poser quatre fois la même question — celle qu'il pose chaque semaine à des fondateurs qui essaient de lui vendre leur boîte — et recevoir quatre fois une réponse qui tient. Il n'évaluait pas un module. Il évaluait, à voix basse, ce qu'il avait acheté en entrant à mon capital.

Ce qui vaut, ce n'est pas la justesse du modèle

Un modèle de valorisation n'est pas vrai ou faux. Il est défendable ou il ne l'est pas. Les quatre dimensions sont défendables parce que chacune peut se tenir indépendamment devant un expert-comptable, un repreneur ou un auditeur. La somme est défendable parce qu'elle assume son statut de convention explicite plutôt que de le masquer derrière un chiffre prétendument objectif.

Le pivot le plus important n'est donc pas le passage d'une dimension à quatre. C'est l'acceptation que toute valorisation d'actif logiciel est une construction, et qu'une construction bien documentée, avec ses fragilités nommées et son code versionné, pèse plus lourd dans une discussion qu'un calcul apparemment mécanique qui cache ses hypothèses.

Pour quiconque code avec une IA et se demande comment parler de la valeur de son travail, la vraie question n'est pas « combien ça vaut ». C'est « sur combien de régimes de valeur distincts suis-je prêt à défendre le chiffre que j'avance ». À un seul, nous serions démontés au premier contradicteur sérieux. À quatre, indépendamment argumentés et honnêtement sommés, nous avons une chance.

Ce que tu peux copier dans ton projet

Quatre éléments réutilisables directement, par ordre de facilité de mise en œuvre :

1. La fonction consolidate(dims) (douze lignes TS) — somme sans pondérer, null-safe, trace les dimensions utilisées dans chaque calcul
2. Le pattern scope_couvert_pct — chaque source de valeur déclare explicitement quel pourcentage du périmètre elle couvre, ce qui rend la déduplication mécanique plutôt qu'à l'œil
3. Le schema valorisation_snapshots avec snapshot_date UNIQUE — un point daté par semaine, auditable plus tard
4. Le cron hebdo qui agrège contacts/leads/inscriptions en direct et écrit le snapshot du lundi matin

Et une règle : toute valorisation agrégée est une convention, jamais un fait. Assume-le dans ton dashboard (note méthodologique visible), documente chaque hypothèse, date chaque score. Un modèle honnête avec ses fragilités nommées pèse plus lourd qu'un chiffre précis qui cache ses hypothèses.

Et vous, quelles dimensions vous manquent dans votre mesure actuelle ? Je lis les commentaires.

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. L'article précédent racontait pourquoi j'ai abandonné la méthode « lignes × TJM ». Le suivant détaillera la trajectoire d'instrumentation du module /admin/valorisation en trois vagues (migration schema, refonte UI, cron mensuel).

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