Votre logiciel vaut zéro au bilan. Et si c'était votre principal actif ?
Un DAF ouvre la liasse, lit la ligne « immobilisations incorporelles », constate une valeur nette comptable proche de zéro et en conclut que l'actif est épuisé. Pendant ce temps, des dizaines de collaborateurs ouvrent ce même logiciel chaque matin, et l'activité s'arrêterait net sans lui. L'amortissement logiciel répond à une question comptable. Il ne répond pas à la question qui compte vraiment : combien vaut ce code, aujourd'hui, pour l'entreprise ?
Dans cet article, vous allez découvrir :
- •Les grands principes de l'amortissement d'un logiciel, acquis ou créé en interne, sans jargon inutile
- •Pourquoi la valeur nette comptable d'un logiciel ne dit presque rien de sa valeur réelle
- •Comment la dette technique agit comme une dépréciation cachée, invisible dans les comptes
- •La méthode pour lire la vraie valeur d'un actif logiciel : dans son code, pas dans son tableau d'amortissement
« La valeur d'une application se lit dans son code. » C'est la conviction qui structure notre travail d'audit et de due diligence technique chez ONDEV.
Amortissement logiciel : les règles comptables en bref
Avant le pivot, posons le cadre. Un logiciel est un actif incorporel : sans substance physique, mais porteur d'avantages économiques futurs. C'est à ce titre qu'il entre au bilan et s'amortit. Les règles diffèrent selon qu'il a été acheté ou développé en interne.
Logiciel acquis : une immobilisation incorporelle classique
Lorsque l'entreprise achète un logiciel (licence perpétuelle, progiciel, application développée par un prestataire et dont elle devient propriétaire), elle enregistre une immobilisation incorporelle. Le coût d'entrée comprend le prix d'acquisition et les frais directement attribuables à sa mise en service.
Ce coût est ensuite étalé dans le temps via l'amortissement. Chaque exercice, une dotation vient réduire la valeur comptable du logiciel et pèse sur le résultat. Rien de plus qu'une mécanique de répartition d'un coût passé.
Logiciel créé en interne : l'activation sous conditions
Quand l'entreprise développe elle-même son logiciel, la logique change. Les dépenses de la phase amont (études préalables, analyse fonctionnelle) restent en charges. Les dépenses de la phase de développement (conception détaillée, programmation, tests, documentation technique) peuvent, sous conditions, être activées : le projet doit notamment être nettement individualisé, avoir de sérieuses chances de réussite technique (et de rentabilité commerciale s'il est destiné à la vente ; pour un logiciel à usage interne, l'entreprise doit manifester sa volonté de le produire et de s'en servir durablement), et ses coûts doivent être suivis de façon fiable.
Autrement dit, le logiciel que votre équipe construit depuis trois ans peut figurer à l'actif, ou avoir été intégralement passé en charges, selon les choix comptables faits à l'époque. Deux entreprises avec le même code peuvent présenter deux bilans radicalement différents.
La durée d'amortissement : la durée d'utilisation attendue
Un logiciel s'amortit sur sa durée d'utilisation probable par l'entreprise. Cette durée est une estimation de la direction, pas une donnée technique. Elle dépend de l'usage envisagé, du rythme d'évolution de la technologie et de la politique de renouvellement de l'entreprise. En pratique, les durées retenues pour les logiciels sont courtes au regard d'autres immobilisations : c'est un actif que la comptabilité considère comme rapidement obsolète.
Le volet fiscal : un régime spécifique à vérifier
Le droit fiscal français a connu un régime d'amortissement spécifique aux logiciels, dont le périmètre a évolué avec les lois de finances successives. Les logiciels acquis ont longtemps pu bénéficier d'un amortissement exceptionnel sur douze mois (article 236 du CGI) ; cet avantage a été supprimé pour les logiciels acquis au cours des exercices ouverts à compter du 1er janvier 2017. Les dépenses de conception d'un logiciel créé en interne peuvent, elles, sur option, être déduites immédiatement ou immobilisées, selon ce même article. Selon la date d'acquisition ou de création et les options retenues, le traitement fiscal peut diverger du traitement comptable et créer des écarts à retraiter (amortissements dérogatoires). Ce point relève strictement de votre expert-comptable : ne l'improvisez jamais.
| Critère | Logiciel acquis | Logiciel créé en interne |
|---|---|---|
| Nature comptable | Immobilisation incorporelle | Immobilisation incorporelle si activation, sinon charges |
| Coût d'entrée | Prix d'achat + frais de mise en service | Coûts de développement éligibles, hors études préalables et analyse fonctionnelle |
| Condition d'entrée au bilan | Achat effectif et contrôle de l'actif | Projet individualisé, chances sérieuses de réussite, coûts suivis |
| Base d'amortissement | Coût d'entrée | Coûts activés |
| Durée d'amortissement | Durée d'utilisation probable | Durée d'utilisation probable |
| Ce que le bilan ignore | L'état réel du code | L'état réel du code |
Valeur nette comptable d'un logiciel : ce que le chiffre dit, ce qu'il tait
La valeur nette comptable (VNC) d'un logiciel, c'est son coût d'entrée diminué des amortissements cumulés et, le cas échéant, des dépréciations constatées. C'est le chiffre que lit le DAF, le banquier et l'acquéreur pressé.
Ce que la VNC mesure : la part du coût historique qui n'a pas encore été consommée comptablement. C'est tout.
Ce que la VNC ne mesure pas :
- •La capacité du logiciel à produire de la valeur demain : le nombre d'utilisateurs, les processus qu'il porte, le chiffre d'affaires qui dépend de lui
- •Son coût de remplacement : ce qu'il faudrait dépenser aujourd'hui pour reconstruire l'équivalent
- •Son risque technique : la probabilité qu'il tombe, qu'il devienne impossible à maintenir ou qu'il bloque une évolution de l'entreprise
- •Sa dépendance aux personnes : si un seul développeur comprend le code, l'actif tient à un contrat de travail
Le coût de remplacement, en particulier, surprend souvent les dirigeants. Les fourchettes que nous détaillons dans notre guide sur le prix d'un site internet en 2026 donnent un ordre de grandeur pour un site ; une application métier qui porte dix ans de règles de gestion se situe plusieurs crans au-dessus. Et ce coût de reconstruction n'apparaît nulle part dans les comptes.
Le paradoxe : amorti à zéro et pourtant stratégique, neuf au bilan et déjà un passif
Voici le pivot que la lecture comptable ne fait jamais. Deux situations, strictement opposées, que nous rencontrons régulièrement en audit.
Cas 1 : le logiciel amorti à zéro qui porte toute l'entreprise
Une application métier développée il y a plusieurs années, totalement amortie, dont la VNC est nulle. Elle n'apparaît plus que pour mémoire dans le tableau des immobilisations. Et pourtant : elle est utilisée quotidiennement, elle encode des processus que personne n'a documentés ailleurs, et l'arrêter coûterait des mois de production.
C'est exactement le profil de l'application métier que nous avons développée pour Dassault Aviation : plus de 100 fonctionnalités, plus de 90 utilisateurs actifs, environ une heure gagnée par processus. Le jour où un tel outil est amorti, sa valeur comptable tombe à zéro. Sa valeur d'usage, elle, n'a pas bougé d'un centime. Le bilan dit « épuisé ». La réalité dit « indispensable ».
Si cet actif est sain techniquement (code lisible, dépendances à jour, tests en place, documentation vivante), il vaut au minimum son coût de reconstruction. Et il vaut probablement davantage, parce qu'il embarque des années d'ajustements métier qu'aucun cahier des charges ne saurait restituer.
Cas 2 : le logiciel neuf au bilan qui est déjà un passif
Inverse exact. Une application livrée il y a dix-huit mois, encore largement non amortie, dont la VNC reste proche du coût d'entrée. Sur le papier, c'est un actif frais. Dans le code : un framework déjà en fin de vie, aucun test automatisé, des dépendances non mises à jour depuis la livraison, un prestataire injoignable et une architecture qui rend chaque évolution plus coûteuse que la précédente.
Cet actif ne produit pas de valeur. Il en consomme. Chaque nouvelle fonctionnalité exige de contourner les défauts de la précédente. La remise à niveau coûtera plus cher que ce qu'indique la ligne du bilan. Comptablement, c'est une immobilisation. Économiquement, c'est une dette.
La dette technique : la dépréciation que le bilan ne voit pas
La comptabilité connaît pourtant le concept de perte de valeur. Lorsqu'il existe un indice qu'un actif a perdu de la valeur, l'entreprise doit comparer sa valeur comptable à sa valeur actuelle (la plus élevée de sa valeur vénale et de sa valeur d'usage) et, si nécessaire, constater une dépréciation. Le mécanisme existe. Le problème, c'est qu'il ne se déclenche quasiment jamais pour un logiciel.
Pourquoi ? Le Plan Comptable Général cite pourtant des indices internes (obsolescence, dégradation, performances inférieures aux prévisions) à côté des indices externes (baisse du marché, évolution réglementaire, fin de support d'une technologie). Mais ces indices ne sont repérés que s'ils remontent jusqu'à la direction, et la perte de valeur d'un logiciel est presque toujours silencieuse : elle ne se voit qu'en ouvrant le code. Elle s'appelle la dette technique.
Qu'est-ce que la dette technique, vue par un DAF ?
La dette technique, c'est l'écart entre l'état réel du code et l'état qu'il devrait avoir pour être maintenu et étendu à coût raisonnable. Chaque raccourci pris pour livrer plus vite, chaque dépendance non mise à jour, chaque fonction écrite sans test, vient grossir cet écart. Nous l'avons détaillée dans notre guide complet sur la dette technique, avec ses causes, ses signaux et ses remèdes.
Pour un financier, la métaphore est exacte : c'est un emprunt contracté sans contrat. Il porte intérêt (chaque évolution coûte plus cher), il peut être appelé à tout moment (une faille de sécurité, une fin de support) et il n'apparaît dans aucun état financier.
L'ampleur du phénomène est documentée. Selon l'étude The Developer Coefficient publiée par Stripe, les développeurs consacrent en moyenne plus de treize heures par semaine à traiter de la dette technique. Ce temps est payé en salaires, comptabilisé en charges, et jamais rattaché à l'actif qu'il sert à maintenir à flot.
Les signaux d'une dépréciation cachée
Vous n'avez pas besoin de lire du code pour repérer qu'un actif logiciel se déprécie. Les signaux remontent dans la gestion :
- 1.Le coût des évolutions augmente d'année en année pour des demandes de complexité comparable
- 2.Les délais de livraison s'allongent sans augmentation du périmètre
- 3.Les incidents en production se multiplient, et leur résolution dépend d'une ou deux personnes
- 4.Les mises à jour de sécurité sont repoussées parce qu'elles « risquent de tout casser »
- 5.Le prestataire ou l'équipe interne refuse de s'engager sur un chiffrage ferme
- 6.Personne ne peut expliquer le fonctionnement d'un module critique
Trois de ces signaux réunis suffisent à justifier un audit de code. Pas pour satisfaire une obligation comptable : pour savoir ce que vous possédez réellement, avant qu'un acquéreur, un investisseur ou une panne ne le découvre à votre place.
À lire aussi : Combien coûte un site internet en 2026 ? Prix et tarifs réels : les fourchettes concrètes pour estimer ce que coûterait aujourd'hui la reconstruction de votre outil.
Comment lire la vraie valeur d'un actif logiciel
Il existe trois lectures de la valeur d'un logiciel. Elles répondent à trois questions différentes et ne se substituent pas l'une à l'autre.
| Lecture | Qui la produit | Question posée | Angle mort |
|---|---|---|---|
| Comptable | L'expert-comptable | Combien du coût historique reste-t-il à amortir ? | L'état réel et l'utilité du code |
| Financière | Le banquier, l'investisseur | Quel multiple appliquer au chiffre d'affaires ou à l'EBITDA ? | Le risque technique qui menace ces revenus |
| Technique | L'auditeur de code | Que vaut ce code une fois le risque déduit ? | Le contexte de marché |
Ce que la lecture technique change concrètement
Pour un DAF, elle permet d'arbitrer entre maintenir, refondre ou remplacer sur une base factuelle, et non sur la seule VNC. Pour un dirigeant qui prépare une cession ou une levée, elle permet d'anticiper les objections d'un acquéreur et de corriger ce qui peut l'être avant la négociation. Pour un acquéreur, elle transforme un prix de façade en prix réel.
C'est précisément l'objet d'une due diligence technique : traduire chaque constat sur le code en conséquence sur le prix, qu'il s'agisse d'une décote, d'une garantie de passif, d'un séquestre ou d'une condition suspensive. Là où l'amortissement répartit un coût passé, la due diligence technique mesure une valeur présente et un risque futur.
FAQ : amortissement et valeur réelle d'un logiciel
Un logiciel métier sur-mesure conçu avec des tests, une documentation vivante et des dépendances suivies reste un actif exploitable et cessible bien après la fin de son amortissement comptable.
Un logiciel est-il toujours une immobilisation incorporelle ?
Quelle durée d'amortissement pour un logiciel ?
La valeur nette comptable d'un logiciel reflète-t-elle sa valeur réelle ?
La dette technique peut-elle justifier une dépréciation comptable ?
Quelle différence entre un audit de code et une due diligence technique ?
Le bilan répartit un coût, le code porte la valeur
L'amortissement logiciel fait son travail : il étale un coût d'acquisition ou de développement sur une durée d'utilisation estimée, et il le fait selon des règles qu'il faut respecter avec votre expert-comptable. Mais il ne vous dira jamais si votre logiciel est un actif ou un passif. Un code amorti à zéro peut porter toute l'entreprise ; un code neuf au bilan peut déjà la freiner.
La seule façon de le savoir, c'est de regarder le code. C'est ce que nous faisons chez ONDEV, en audit comme en due diligence technique : donner à la direction financière une lecture de la valeur que ni le tableau d'amortissement ni le multiple de chiffre d'affaires ne peuvent fournir.
Vous voulez savoir ce que vaut réellement votre logiciel, au-delà de sa valeur nette comptable ? Parlons de votre actif : un premier échange suffit pour cadrer la bonne approche.
