Valorisation d'une application : la méthode

Votre application vaut-elle ce que dit votre bilan, votre banquier ou votre code ?

Posez la question « combien vaut mon application ? » à trois personnes et vous obtiendrez trois réponses qui n'ont rien à voir. L'expert-comptable sort une valeur nette comptable. Le banquier ou le fonds applique un multiple de chiffre d'affaires. Le CTO que vous mandatez pour une due diligence ouvre le dépôt Git et sort un chiffre encore différent. Un seul de ces trois chiffres résiste à une négociation sérieuse.

Dans cet article, vous allez découvrir :

• •Les trois méthodes de valorisation d'une application (SaaS, application mobile ou logiciel métier) et ce que chacune mesure vraiment
• •Pourquoi le coût de reconstruction et les multiples d'ARR surévaluent systématiquement un actif logiciel
• •La méthode « actif moins risque technique » que nous appliquons chez ONDEV, poste par poste, avec les décotes associées
• •Ce que l'exploitation de SaaS comme Wiloq et Swap&Share nous a appris sur ce qui fait tenir une valeur dans le temps

La valeur d'une application se lit dans son code. Tout le reste est une hypothèse sur le code.

Pourquoi la valorisation d'une application est un exercice à part

Une application n'est pas une machine-outil. Elle ne s'use pas de façon linéaire, elle ne se revend pas sur un marché de l'occasion, et elle peut valoir zéro le jour où une dépendance critique cesse d'être maintenue. À l'inverse, un logiciel amorti à 100 % au bilan peut être l'actif qui génère tout le chiffre d'affaires de l'entreprise.

C'est ce décalage qui rend la valorisation d'un SaaS ou d'une application mobile si piégeuse. Les méthodes financières classiques ont été conçues pour des actifs dont le risque est externe (marché, concurrence, réglementation). Pour une application, le risque principal est interne : il est dans le code, l'architecture, les dépendances et l'équipe qui sait encore le faire tourner.

Trois publics se posent la question en même temps, avec des intérêts opposés :

• •Le dirigeant qui vend ou lève des fonds veut le chiffre le plus haut défendable
• •L'acquéreur ou l'investisseur veut savoir ce qu'il achète réellement, et ce qu'il devra réinvestir dans les 18 mois
• •Le DAF ou l'expert-comptable doit inscrire une valeur au bilan sans avoir les moyens de juger la qualité technique

Les trois méthodes ci-dessous répondent chacune à l'un de ces publics. Une seule répond honnêtement aux trois.

Méthode 1 : le coût de reconstruction (ce qu'il faudrait dépenser pour la refaire)

C'est la méthode intuitive. On estime le nombre de jours de développement nécessaires pour reconstruire l'application à l'identique, on multiplie par un taux journalier, on ajoute le design, la gestion de projet et l'infrastructure. Le résultat donne un « prix de revient » qui sert de valeur plancher.

Ce que cette méthode mesure vraiment

Elle mesure un effort passé, pas une valeur future. Elle ne distingue pas une fonctionnalité utilisée chaque jour par tous les clients d'une fonctionnalité livrée il y a trois ans et jamais ouverte. Elle ne voit pas non plus qu'une application de 100 000 lignes de code peut se reconstruire en 30 000 lignes avec une stack moderne, parce qu'une bonne partie du volume est de la dette accumulée.

Pourquoi elle surévalue presque toujours

Le coût de reconstruction compte la dette technique comme un actif. Plus le code est lourd, redondant et mal découpé, plus il « coûte » à reconstruire, donc plus il semble valoir. C'est exactement l'inverse de la réalité : un acquéreur paiera moins pour une application qu'il devra réécrire en partie.

Cette méthode a une seule utilité légitime : fixer un plancher pour une application sans revenu (un MVP, un outil interne), à condition de la corriger du coût de la reprise. Nous détaillons ce calcul de reprise dans notre page dédiée à la due diligence technique d'une application avant acquisition, parce que c'est là que la différence entre « ce qu'elle a coûté » et « ce qu'elle vaut » se joue.

Méthode 2 : les multiples d'ARR ou de chiffre d'affaires

C'est la méthode des investisseurs et des banques d'affaires. On prend le revenu récurrent annuel (ARR) ou le chiffre d'affaires, et on applique un multiple observé sur des transactions comparables. Le multiple varie selon la croissance, la rétention, la marge brute et la taille du marché.

Ce que cette méthode mesure vraiment

Elle mesure la capacité de l'application à générer du revenu demain, en supposant que le produit continue à fonctionner comme aujourd'hui. Cette hypothèse est énorme et rarement explicitée. Le multiple intègre le risque de marché et le risque commercial ; il ignore presque complètement le risque technique.

Là où le raisonnement casse

Deux SaaS avec le même ARR, la même croissance et le même churn obtiendront le même multiple. Pourtant, si l'un tourne sur une base de code testée, documentée et déployée automatiquement, et l'autre sur un monolithe que seul le fondateur sait redéployer à la main, ils ne valent pas la même chose. Le second porte un risque de rupture que le multiple ne voit pas, et que l'acquéreur découvrira six mois après le closing.

Les multiples restent indispensables pour une valorisation de startup SaaS : ils donnent l'ordre de grandeur que le marché accepte. Mais ils donnent une valeur avant déduction du risque technique, pas une valeur finale.

À lire aussi : Créer une application avec Supabase - comment nous construisons des SaaS dont l'architecture tient la revente, dès la première ligne.

Méthode 3 : l'actif moins le risque technique (la seule honnête)

La troisième méthode part d'une valeur de référence (le multiple d'ARR pour un SaaS qui génère du revenu, le coût de reconstruction corrigé pour une application qui n'en génère pas encore), puis déduit, poste par poste, ce qu'il faudra dépenser ou risquer pour que cette valeur se réalise.

C'est la méthode qu'un acquéreur sérieux applique de toute façon pendant la due diligence. Autant l'appliquer avant lui, côté vendeur, pour ne pas découvrir la décote en pleine négociation.

Les six postes de risque qui font bouger le prix

Pourquoi c'est la seule méthode honnête pour un actif logiciel

Parce qu'elle est la seule qui va regarder l'actif lui-même. Les deux premières raisonnent sur des indicateurs autour de l'application (le temps qu'elle a coûté, l'argent qu'elle rapporte). La troisième ouvre le dépôt, lit l'historique des commits, lance les tests, vérifie que le déploiement se reproduit depuis une machine vierge. Elle traite l'application comme ce qu'elle est : un actif technique, avec une usure technique.

C'est aussi la seule méthode qui récompense le travail bien fait. Une application construite proprement obtient une décote faible, donc une valeur proche du multiple de marché. Avec les deux autres méthodes, la qualité du code ne change rien au prix. Avec celle-ci, elle devient l'argument de vente principal.

Ce que l'exploitation de SaaS en production nous a appris

Chez ONDEV, nous ne faisons pas que développer des applications web et SaaS sur-mesure pour nos clients : nous en exploitons nous-mêmes. Cette double position (concepteur et exploitant) change la façon dont on lit la valeur d'une application.

Wiloq : la valeur se mesure en interfaces qui tiennent ensemble

Wiloq, application SaaS de vestiaire numérique pour l'événementiel, compte 12+ fonctionnalités réparties sur 3 interfaces distinctes (organisateur, personnel sur site, participant) et s'appuie sur 2 sites vitrines. Construite sur Next.js, Supabase et PostgreSQL, déployée sur Vercel.

Ce que cette architecture nous a appris pour la valorisation : la valeur n'est pas dans le nombre de fonctionnalités, mais dans le fait qu'un seul schéma de données alimente les trois interfaces sans duplication de logique. Un acquéreur qui audite Wiloq trouve un déploiement reproductible et une base dont les règles de sécurité sont écrites au niveau de la donnée, pas dispersées dans le code applicatif. C'est ce qui réduit la décote sur les postes « dépendance aux personnes » et « sécurité ».

Swap&Share : la valeur se mesure en transactions réelles

Swap&Share, plateforme SaaS d'échange de compétences entre professionnels, réunit 100 à 200 utilisateurs et a traité 200+ échanges via Stripe. Stack : React, Node.js, Strapi et Stripe.

Ici, la leçon est différente. Avec un multiple d'ARR, une plateforme de cette taille vaut peu. Avec le coût de reconstruction, elle vaut beaucoup trop. Avec la méthode « actif moins risque », on regarde ce qui compte : 200+ transactions passées par Stripe sans incident, un flux de paiement et de litige qui a été testé par de vrais utilisateurs, une intégration qui ne sera pas à refaire. C'est un actif technique validé en production, et c'est ainsi qu'il doit être présenté à un investisseur.

Ce que les deux cas ont en commun

Dans les deux projets, les éléments qui protègent la valeur sont invisibles dans un bilan et dans un tableau de multiples : la reproductibilité du déploiement, la couverture des cas limites de paiement, la séparation claire des rôles. Ils ne se lisent qu'en ouvrant le code. C'est tout le sens de la thèse ONDEV.

Les 5 erreurs qui faussent la valorisation d'une application

1. 1.Confondre prix de revient et valeur. Ce que l'application a coûté à développer n'intéresse pas l'acheteur ; ce qu'elle lui coûtera à maintenir, oui.
2. 2.Présenter le nombre de lignes de code ou de fonctionnalités comme un argument. Pour un auditeur technique, un volume élevé est d'abord un signal de risque à vérifier.
3. 3.Appliquer un multiple sans ajuster la marge brute. Si l'hébergement et le support technique dévorent la marge parce que l'architecture ne scale pas, le multiple doit baisser.
4. 4.Découvrir la dette technique pendant la due diligence de l'acquéreur. À ce stade, chaque constat devient une décote imposée. Réalisé en amont, le même constat devient un plan d'action chiffré que le vendeur maîtrise.
5. 5.Oublier la propriété intellectuelle du code. Un module développé par un freelance sans clause de cession, ou une bibliothèque sous licence incompatible avec un usage commercial, peut bloquer une transaction entière.

Comment procéder concrètement, côté vendeur comme côté acheteur

Si vous êtes vendeur, commandez l'audit avant de lancer le processus de cession. Vous obtiendrez une liste de constats, un chiffrage de remise à niveau et le temps de corriger ce qui pèse le plus sur la décote. Un acquéreur qui reçoit un rapport de due diligence technique déjà réalisé négocie différemment : il part de vos constats, pas des siens.

Si vous êtes acquéreur ou investisseur, exigez la méthode 3 et refusez de signer sur la base des deux premières. Le coût d'une due diligence technique représente une fraction du prix de la transaction ; le coût de découvrir un monolithe non déployable après le closing se compte en mois de retard et en réécriture.

Dans les deux cas, la question à poser à votre auditeur est la même : « pour chaque constat, qu'est-ce que ça change au prix ou au contrat ? ». Un audit qui ne répond pas à cette question est un rapport technique, pas une valorisation.

FAQ : valorisation d'une application, les questions qui reviennent

Côté vendeur, un audit de code réalisé avant la mise en vente vous permet de corriger les constats qui pèsent sur le multiple, au lieu de les découvrir dans le rapport de l'acheteur.

La valeur de votre application est déjà écrite : il suffit de la lire

Le bilan vous dit ce que l'application a coûté. Le marché vous dit ce que des applications comparables se vendent. Seul le code vous dit ce que la vôtre vaut, une fois le risque technique déduit. C'est la seule méthode qui résiste à une négociation, et la seule qui donne au vendeur comme à l'acheteur une base commune.

Si vous préparez une cession, une levée de fonds ou une acquisition, faites lire le code avant que l'autre partie ne le fasse.

Vous voulez savoir ce que vaut réellement votre application, ou celle que vous envisagez d'acheter ? Parlons de votre projet de due diligence technique : nous lisons le code et nous traduisons chaque constat en impact sur le prix.