Amortir un logiciel, c’est typiquement un sujet qu’on repousse au lendemain.
Jusqu’au jour où ça bloque : un investissement logiciel qu’on ne peut pas passer en charge, un contrôle fiscal qui challenge la durée d’amortissement, un actif logiciel qui n’a plus aucune valeur… mais qui pèse encore en compta.
Le paradoxe ? Beaucoup d’entreprises amortissent leurs logiciels “par réflexe”, sans jamais aligner durée d’usage réelle, cycle de vie produit et réalité technique. Résultat ? Des amortissements qui n’ont rien à voir avec la façon dont le logiciel vit, s’use, ou doit évoluer.
Chez Yield, on construit et maintient des logiciels métier - et on voit l’impact qu’un mauvais amortissement peut avoir sur les décisions produit : refonte trop tardive, budget bloqué, dette technique qui gonfle en silence.
👉 Dans cet article, on clarifie à la fois l’aspect comptable (durées, règles, méthodes)… et ce que ça change concrètement pour votre produit.
Principes généraux de l’amortissement des logiciels
Amortir un logiciel : pourquoi ce n’est pas qu’une règle comptable
On parle d’amortissement logiciel comme d’une formalité comptable.
En réalité, c’est tout sauf accessoire : c’est ce qui permet de répartir le coût d’un logiciel sur sa durée d’utilisation réelle.
Un logiciel, même immatériel, est une immobilisation incorporelle : il perd de la valeur à mesure que votre usage évolue, que la stack vieillit, que les besoins changent.
👉 L’amortissement traduit ce vieillissement dans les comptes.
Pourquoi amortir ?
- pour lisser l’investissement sur plusieurs exercices ;
- pour refléter la durée de vie réelle du logiciel ;
- pour sécuriser la conformité comptable et fiscale ;
- pour anticiper la refonte ou la migration ;
- pour piloter un budget IT cohérent.
💡 À retenir :
La durée d’amortissement dépend exclusivement de sa durée d’utilisation, qu’il soit acquis ou créé en interne.
Comptable vs fiscal : deux visions à concilier
C’est là que beaucoup d’entreprises glissent : elles pensent que l’amortissement comptable et l’amortissement fiscal, c’est la même chose.
Pas tout à fait.
- L’amortissement comptable traduit la réalité économique : combien de temps le logiciel vous sera réellement utile ?
- L’amortissement fiscal, lui, répond à une logique d’administration : quelles durées et méthodes sont acceptées pour optimiser le résultat imposable ?
Les deux doivent cohabiter - et parfois divergent.
Une durée comptable trop longue peut figer un actif devenu obsolète ; une durée fiscale trop courte peut créer un écart à suivre dans vos amortissements dérogatoires.
Comptabilisation initiale et amortissement comptable
Logiciel acheté : simple en théorie… jusqu’au premier décalage
Sur le papier, acheter un logiciel, c’est simple : une facture, un passage en compte 205, et l’amortissement qui démarre le jour de l’achat. Pas le jour où vous l’utilisez. C’est la règle, et beaucoup d’entreprises l’oublient.
Le problème ? Dans la vraie vie, les projets logiciels ne suivent jamais un Gantt impeccable.
Si la mise en service prend trois mois de retard, l’amortissement, lui, tourne déjà.
Et ça peut plomber votre vision financière : un actif qui perd de la valeur… alors que personne ne s’en sert encore.
Durée classique : 1 à 3 ans pour un logiciel interne - sauf directive propre à l’entreprise.
⚠️ Un logiciel acheté = un bloc
Même si vous n’utilisez qu’un module sur quatre, c’est toute la licence qui part en immobilisation.
Logiciel développé en interne : l’amortissement qui suit votre maturité
Créer un logiciel en interne, ce n’est pas “juste” du développement : c’est un actif qu’on construit au fil des sprints.
Et comptablement, ça change tout : vous immobilisez un processus, pas une facture.
Le cycle côté compta ressemble à ça :
- on active les coûts de dev (pas la maintenance, pas les correctifs) ;
- on met en prod ;
- on immobilise ;
- puis on amortit.
Durée recommandée : souvent 3 ans pour un logiciel interne.
Mais dans les faits, la bonne durée dépend de votre rythme d’évolution et de la dette technique que vous accumulez (ou pas).
Mode et plan d’amortissement des logiciels
Amortissement linéaire : la méthode par défaut
L’amortissement linéaire, c’est le modèle le plus utilisé : le logiciel perd la même valeur chaque année. Simple, stable, prévisible.
C’est aussi la méthode qui colle le mieux au cycle de vie de la majorité des logiciels internes : une utilisation régulière, une évolution progressive, une usure “normale”.
Concrètement :
- logiciel amorti sur 3 ans → 33 % par an ;
- logiciel amorti sur 2 ans → 50 % par an.
Pas de surprise, pas de variation : un amortissement “plat”.
“Là où ça se complique, c’est quand le logiciel vieillit plus vite que prévu : stack obsolète, API abandonnée, dépendances trop anciennes… Dans ces cas-là, l’amortissement linéaire ne reflète plus la réalité : la valeur du logiciel chute bien plus vite que ce que montrent les comptes.”
— Hugo, Engineering Manager @ Yield Studio
Amortissement dégressif : pour les logiciels qui s’usent vite
Un logiciel peut perdre énormément de valeur dans ses premières années : nouvelle version de framework, obsolescence d’un plugin critique, montée en charge qui rend l’architecture insuffisante…
Dans ces cas-là, le modèle dégressif a du sens : on amortit plus vite au début, et moins ensuite.
C’est rare sur les logiciels internes, mais pertinent sur :
- un outil métier très lié à une stack fragile ;
- un logiciel dépendant de technologies volatiles ;
- un produit dont la valeur est maximale à court terme.
Mais attention : l’amortissement dégressif doit rester justifiable. On ne peut pas l’appliquer par confort budgétaire.
💡 À savoir
L’amortissement dégressif n’est admis fiscalement que dans certains cas : il doit être cohérent avec la rapidité d’obsolescence du logiciel.
Amortissement exceptionnel : pour les virages stratégiques
L’amortissement exceptionnel permet d’amortir un logiciel plus vite que prévu - parfois en un an.
C’est une mesure réservée à des situations précises :
- logiciel rapidement rendu obsolète par une refonte globale ;
- obligation réglementaire de migration ;
- changement de modèle économique,- ;
- intégration d’un nouveau système qui remplace tout l’existant.
Il permet de neutraliser comptablement une perte de valeur brutale.
Mais il a un impact fiscal : un amortissement exceptionnel réduit le résultat imposable, donc il doit être documenté, motivé, et défendable.
Impact fiscal de l’amortissement des logiciels
Limites fiscales et amortissements dérogatoires
Amortir un logiciel, ce n’est pas seulement choisir une durée : c’est aussi respecter les règles fiscales. Et c’est souvent ici que ça se complique.
Fiscalement, on dispose d’un cadre :
- des durées admises pour les logiciels ;
- des tolérances, notamment pour les petits montants ;
- et une possibilité d’écart entre comptable et fiscal : l’amortissement dérogatoire.
💡La règle clé
Un logiciel dont la valeur hors taxes est inférieure à 500 € peut être passé directement en charge, grâce à la tolérance administrative.
Au-dessus, on entre dans l’amortissement.
Quand votre durée comptable ne colle pas à la durée fiscale admise, on crée un amortissement dérogatoire :
- un écart volontaire ;
- suivi dans un compte dédié ;
- qui corrige le résultat imposable pour rester conforme.
Typiquement, vous amortissez comptablement sur 4 ans car usage long, mais le fisc admet 2 ans → dérogatoire.
⚠️ Attention
Un dérogatoire mal justifié = un contrôle fiscal qui pique.
On documente toujours pourquoi la durée comptable est différente.
Logiciel amorti… mais encore utilisé
Quand un logiciel est totalement amorti, il reste en compta sous forme d’actif à valeur nette nulle. Et là, beaucoup d’entreprises ne savent plus quoi en faire.
Trois questions à se poser :
- Le logiciel est-il encore utilisé ? Si oui, l’actif continue d’exister. On ne sort rien.
- Sa valeur réelle est-elle devenue nulle ? Si le logiciel ne sert plus ou n’a plus de valeur technique, on peut le sortir des immobilisations.
- Une refonte est-elle imminente ? Ça peut déclencher une nouvelle immobilisation (et un nouveau plan d’amortissement).
En pratique, la fin d’amortissement est un bon moment pour :
- réévaluer la dette technique ;
- décider d’une refonte, d’une migration ou d’un retrait du scope ;
- recalibrer la roadmap produit (budget compris).
👉 Ce n’est pas une fin. C’est un signal : “On fait quoi maintenant ?”.
Spécificités selon le type de logiciel
Logiciel à usage interne vs logiciel commercial
Un logiciel interne (outil métier, application RH, automatisation interne…) ne vit pas comme un logiciel commercial vendu à des clients.
Et l’amortissement doit refléter ce rythme de vie.
Logiciels internes - durée courte : 1 à 3 ans
Pourquoi ?
- Vos besoins évoluent vite.
- Le logiciel pivote au fil des sprints.
- La dette technique s’accumule plus rapidement.
- Son usage met une pression continue sur la roadmap.
👉 C’est un actif vivant : on l’amortit sur une période courte, fidèle à sa réalité.
Logiciels commerciaux - durée plus longue : 2 à 5 ans
Ici, la logique change :
- Le logiciel génère du revenu sur plusieurs années.
- Les évolutions sont planifiées.
- La stabilité est un enjeu business.
- La valeur se diffuse sur un cycle plus long.
👉 L’amortissement devient un outil stratégique : il impacte le pricing, le ROI, et la trajectoire produit.
Logiciels intégrés à un projet plus large
Quand un logiciel fait partie d’un projet global (ERP, refonte SI, plateforme complète…), on ne l’amortit pas seul.
En pratique :
- il est rattaché à l’immobilisation principale ;
- il suit la durée du projet global, pas sa propre durée logique ;
- la durée d’amortissement est tirée par “la brique la plus lente”.
🔍 Exemple
Un module métier intégré à un ERP déployé sur 5 ans → amorti sur 5 ans, même si ce module aurait pu être amorti sur 3 ans.
C’est souvent là que se glissent les plus gros écarts entre compta et réalité produit.
Logiciels indissociables du matériel
Certains logiciels font partie intégrante d’un matériel : firmware, logiciel embarqué, OS machine, pilotage industriel…
Une règle simple : si le logiciel ne peut pas exister sans le matériel → il suit la durée d’amortissement du matériel.
Aucun amortissement séparé.
🔍 Exemple
Un logiciel de pilotage intégré dans une machine amortie sur 7 ans → amorti sur 7 ans.
⚠️ L’erreur fréquente, c’est d’amortir séparément un logiciel embarqué - alors que la loi ne le permet pas.
Conclusion - Amortir un logiciel, c’est piloter son cycle de vie
On parle d’amortissement comme d’un sujet comptable. En réalité, c’est un sujet de pilotage produit : la durée, la méthode, le plan… tout ça influence vos arbitrages, votre budget, votre capacité à faire évoluer votre logiciel au bon moment.
Le bon amortissement, c’est celui qui colle :
- à la réalité technique (dette, stack, obsolescence),
- à la réalité business (gains, revenus, usage),
- et à la trajectoire produit (réécriture, roadmap, évolutions majeures).
Chez Yield, on voit l’impact direct d’un amortissement bien posé : des refontes planifiées, un budget IT réaliste, une roadmap crédible - donc un produit qui s’use moins vite et qui coûte moins cher à long terme.
👉 Vous construisez ou faites évoluer un logiciel métier et vous voulez sécuriser à la fois l’aspect produit et l’aspect comptable ? On peut vous aider à cadrer votre projet, votre budget… et l’amortissement qui va avec.
