Comptabiliser un logiciel développé en interne : comment faire

Comptabiliser un logiciel interne, ça a l’air simple : on développe, on capitalise, on amortit.
Dans la réalité, c’est l’un des sujets les plus mal maîtrisés par les entreprises.

Parce qu’un logiciel interne, c’est un actif incorporel, pas un coût IT. Et si vous ne le comptabilisez pas correctement, vous faussez votre bilan, vous perdez des avantages fiscaux… ou vous prenez un risque en cas de contrôle.

Entre phase de recherche, phase de développement, conditions de capitalisation, amortissement, PCG, TVA, fiscalité… beaucoup d’équipes se retrouvent à naviguer à vue.

Chez Yield, on voit l’enjeu tous les jours : un logiciel mal comptabilisé = un pilotage produit biaisé et des budgets impossibles à défendre.

👉 Dans cet article, on fait le point, étape par étape : comment comptabiliser un logiciel développé en interne, ce qu’on peut capitaliser (ou pas), comment amortir, et comment sécuriser l’aspect comptable et fiscal.

Les étapes de la comptabilisation d’un logiciel développé en interne

Comptabiliser un logiciel interne, ce n’est pas activer tout ce qui ressemble à du développement. Le PCG impose un vrai parcours : on ne capitalise que lorsque le projet passe de l’idée à quelque chose de réalisable, développé, maîtrisé, et mis en service.

Autrement dit : toutes les dépenses ne se valent pas. Et ce tri, c’est votre premier garde-fou comptable.

1 - Phase de conception et faisabilité technique

La première étape, c’est la phase où on explore : cadrage, ateliers, proto, faisabilité technique, choix de la stack… Et rien n’est capitalisable à ce stade.

Pourquoi ? Parce qu’on est dans la recherche : impossible encore de garantir que le logiciel sera réalisable, rentable ou utilisable par l’entreprise.

Concrètement, cette phase inclut :

• l’étude de faisabilité du projet ;
• l’analyse des besoins ;
• les POC pour valider les choix techniques ;
• les arbitrages sur la solution finale ;
• la distinction entre ce qui relève du futur logiciel… et ce qui appartient au projet global (SI, ERP, refonte infra).

💡 Règle d’or

On ne capitalise pas tant que le projet n’a pas dépassé le “est-ce qu’on y va ?”.

Ce qui est développé dans le cadre d’un projet global (ex : un module noyé dans un SI complet) doit être identifié tôt : l’immobilisation suivra celle du projet principal, pas sa propre logique.

2 - Développement et capitalisation

C’est la bascule critique : on passe de la recherche au développement réel, celui qui crée un actif. À partir de ce moment, certaines dépenses peuvent être immobilisées - mais pas toutes.

Pour immobiliser des frais de développement, il faut prouver que :

• le projet est techniquement réalisable ;
• l’entreprise a l’intention de le mener à terme ;
• elle a les ressources pour y arriver ;
• le logiciel générera des avantages économiques futurs ;
• et les dépenses peuvent être mesurées de manière fiable.

Quand ces critères sont cochés → on peut activer.

✅ Ce qu’on peut capitaliser

• temps de développement (dev, QA, tech lead - uniquement sur les tâches de création du logiciel) ;
• documentation technique liée au développement ;
• conception détaillée, UX/UI finalisée (si directement rattachée au logiciel) ;
• coûts d’intégration nécessaires au fonctionnement du logiciel.

❌ Ce qu’on ne capitalise pas

• maintenance, bugfix, évolutions correctives ;
• support, exploitation, formation ;
• documentation fonctionnelle uniquement métier ;
• tout ce qui relève de la R&D exploratoire ;
• les évolutions qui allongent la durée de vie sans créer un nouvel actif.

👉 On capitalise la construction, pas l’entretien.

3 - Mise en service et amortissement

Une fois le logiciel mis en production et utilisé par l’entreprise, il devient une immobilisation incorporelle. C’est là que commence l’amortissement - pas avant.

Ce que signifie “mise en service” :

• le logiciel fonctionne ;
• il rend le service attendu ;
• il est utilisé en conditions réelles.

À partir de cette date, on applique un plan d’amortissement : linéaire (le plus courant) ou dégressif (cas spécifiques).

Pour les logiciels internes, la durée d’usage courante est de 1 à 3 ans, selon complexité, stack et stabilité du besoin.

📌 À retenir

Un logiciel développé en interne est amorti sur sa durée réelle d’utilisation.

Distinction des coûts : tout ne s’immobilise pas

Quand une entreprise développe un logiciel en interne, la question n’est pas “combien ça coûte ?”, mais “qu’est-ce que je peux immobiliser… et qu’est-ce qui doit partir en charge ?”.

C’est le point où 70 % se trompent : on capitalise trop (risque fiscal), ou pas assez (actif sous-évalué, budget IT impossible à piloter).

La clé, c’est de séparer clairement ce qui construit le logiciel… et ce qui gravite autour.

Coûts directs de développement

Les coûts directs sont les plus simples à identifier : ce sont les dépenses qui contribuent directement à la création du logiciel.

Ils sont immobilisables dès lors que les critères de capitalisation sont remplis.

🔍 Exemples de coûts directs :

• salaires et charges des développeurs, QA, tech lead ;
• conception technique indispensable (architecture, modélisation, spécifications fonctionnelles détaillées) ;
• intégration technique liée au logiciel (API, modules backend, automatisation nécessaire) ;
• documentation technique directement liée au fonctionnement ;
• tests unitaires et tests d’intégration nécessaires à la mise en service.

👉 Règle simple : si le logiciel ne peut pas fonctionner sans cette dépense → coût direct.

Coûts indirects et frais généraux

Les coûts indirects sont plus trompeurs : ils participent au projet… sans être uniquement liés au logiciel.

Ils peuvent être affectés au projet, mais ne sont généralement pas immobilisables, car ils ne créent pas la valeur du logiciel en tant que telle.

✅  Exemples de coûts indirects :

• management transverse ou pilotage non dédié ;
• temps des métiers (PO, direction, utilisateurs) ;
• formation des équipes ;
• support interne ;
• infrastructures mutualisées (serveurs, licences outils) ;
• coûts administratifs ou RH.

❌ Frais généraux à ne pas immobiliser :

• charges de structure (électricité, locaux, assurances) ;
• matériel non spécifique ;
• outils de productivité (Notion, Slack, Jira…).

👉 On immobilise l’effort de production du logiciel, jamais l’environnement qui l’entoure.

Les critères de capitalisation : ce qu’on peut activer… et ce qui doit rester en charge

Le PCG impose deux conditions incontournables. Et si l’une manque, les dépenses doivent passer en charge - même si le logiciel est livré, utilisé, ou critique pour l’entreprise.

Ces critères sont là pour une raison : éviter que les entreprises gonflent artificiellement leur actif. Et en pratique, ils forcent à prouver que le logiciel aura une vraie valeur économique, et que son coût est précisément mesuré.

Avantages économiques futurs : la valeur doit être démontrée, pas supposée

Pour capitaliser un logiciel, il faut démontrer qu’il va générer des avantages économiques futurs pour l’entreprise.

Ça ne veut pas dire du chiffre d’affaires direct. Ça veut dire : un gain mesurable, concret, exploitable.

🔍 Exemples d’avantages économiques futurs :

• gain de productivité (temps économisé, automatisation) ;
• réduction des coûts d’exploitation ;
• amélioration de la qualité ou réduction des erreurs ;
• avantage concurrentiel identifiable ;
• contribution au business model (ex : logiciel qui supporte un service vendu).

👉 Ce qui compte n’est pas “ça va servir”, mais ça va créer un gain identifiable et mesurable.

“Un logiciel interne doit prouver sa valeur dès le cadrage. Sans ça, l’immobilisation est bancale, et les comptes aussi.”
— Camille, Product Strategist @ Yield Studio

Capacité à mesurer la dépense de manière fiable : sans traçabilité, pas de capitalisation

Deuxième critère : il faut pouvoir mesurer précisément les coûts engagés.

Et dans la vraie vie, c’est là que ça coince - surtout dans les équipes qui n’ont pas l’habitude de suivre leurs temps ou leurs coûts par lot de fonctionnalités.

Pour que les dépenses soient capitalisables, il faut que les coûts soient :

• identifiables ;
• traçables ;
• affectés au logiciel sans ambiguïté ;
• mesurables par nature (temps passé, factures, prestations).

❌ Exemples de dépenses non capitalisables faute de mesure fiable :

• du temps “au feeling” ;
• une équipe qui travaille sur trois sujets sans ventilation claire ;
• des coûts techniques mélangés à de la maintenance ou du support ;
• une prestation facturée globalement sans séparation des lots.

👉 Pas de mesure fiable = pas de capitalisation. Sans discussion.

Calcul de l’amortissement du logiciel : poser la bonne durée

Une fois le logiciel mis en service, l’entreprise doit définir comment il va être amorti.

Deux étapes clés :

1. déterminer sa durée d’utilisation ;
2. choisir le plan d’amortissement.

Déterminer la durée d’utilisation : la vraie question

La durée d’amortissement d’un logiciel n’est pas fixe, ni imposée par la loi. Elle dépend de votre usage et de votre rythme d’évolution.

Pour un logiciel interne, on observe généralement :

• 1 à 3 ans pour des outils métier évolutifs ;
• 3 à 5 ans pour des systèmes plus stables ou critiques ;
• davantage uniquement si l’architecture est robuste et peu soumise à obsolescence.

Les critères qui guident la durée :

• vitesse d’évolution du métier ;
• dépendances techniques (frameworks, API, librairies) ;
• fréquence des montées de version ;
• stabilité de l’architecture ;
• dette technique anticipée ;
• stratégie produit (refonte prévue ? montée en charge nécessaire ?).

👉 La bonne durée est celle qui reflète la façon dont le logiciel va vieillir techniquement ET servir le business.

“Amortir un logiciel sur 5 ans alors que la stack en tiendra 2 ? C’est la recette parfaite pour bloquer une refonte urgente.”

— Hugo, Engineering Manager @ Yield Studio

Plan d’amortissement : linéaire ou dégressif ?

En pratique, 99 % des logiciels internes sont amortis en linéaire. Mais dans certains cas, le dégressif peut mieux refléter la réalité technique.

Amortissement linéaire : adapté à la majorité des logiciels internes

On répartit le coût du logiciel de façon identique chaque année.

Exemples :

• amortissement sur 3 ans → 33 % par an ;
• amortissement sur 2 ans → 50 % par an.

C’est la norme parce que les logiciels internes évoluent progressivement et que leur valeur d’usage est régulière. Le modèle est plus lisible et plus défendable en cas de contrôle.

Amortissement dégressif : quand le logiciel perd de la valeur très vite

Certains logiciels deviennent obsolètes dès les premières années (stack fragile ou volatile, dépendances critiques, techno coeur de produit…)

Dans ces cas, le dégressif permet de refléter une dépréciation accélérée : amortir plus vite au début, moins ensuite.

⚠️ Attention

Le dégressif doit être cohérent avec l’obsolescence réelle du logiciel.
Et fiscalement, il n’est admis que dans certains cas précis.

Impact comptable et fiscal : ce que votre logiciel change vraiment dans vos comptes

Un logiciel développé en interne n’est pas qu’un chantier produit : c’est un actif qui va peser dans vos comptes pendant plusieurs années.

👉 Bien comptabilisé, il renforce votre bilan et clarifie vos budgets.
👉 Mal comptabilisé… il devient une bombe à retardement lors d’un contrôle fiscal.

Influence sur le bilan comptable : un actif, pas une “ligne IT”

Quand vous immobilisez un logiciel interne, il apparaît à l’actif du bilan. Ce n’est plus une dépense ponctuelle : c’est un investissement que vous amortissez dans le temps.

Ce que ça change :

• votre bilan se renforce (plus d’actifs) ;
• votre résultat est lissé (la charge est étalée) ;
• vous gagnez en visibilité budgétaire.

Mais à une condition : que la valeur immobilisée soit juste.

⚠️ Les deux erreurs typiques

• Sous-évaluer le logiciel → vous bridez artificiellement vos capacités d’investissement.
• Surévaluer → vous traînez un actif “gonflé” pendant des années, impossible à justifier.

Considérations fiscales : le cadre à ne pas ignorer

Dès qu’un logiciel est immobilisé, l’administration fiscale a un œil dessus.
Trois points font (presque) toujours débat :

1. La durée d’amortissement

Le fisc accepte généralement 1 à 3 ans pour les logiciels internes. Plus long ? Possible. Mais à justifier techniquement.

Si votre durée diffère de la durée “admise”, vous créez un amortissement dérogatoire.

2. Le seuil des 500 €

Un logiciel dont le coût est < 500 € HT peut être passé directement en charge.
C’est pratique… mais rare pour un développement interne.

3. Les crédits d’impôt (CIR / CII)

Selon la nature du projet, une partie des coûts peut être éligible :

• incertitudes techniques,
• développement d’une fonctionnalité réellement nouvelle,
• travail de R&D démontré.

👉 Rien n’est automatique. Le fisc veut des preuves du travail technique : prototypes, tests, obstacles rencontrés.

Documentation et suivi : ce qui évite les mauvaises surprises trois ans plus tard

Sans documentation ni suivi, impossible de justifier ce qui a été immobilisé, d’ajuster un amortissement ou de défendre un contrôle.

Si vous ne tracez pas, vous ne maîtrisez pas.

Importance de la documentation

Un logiciel interne sans documentation, c’est un actif impossible à défendre.

Pour l’administration comme pour votre audit interne, il faut pouvoir prouver ce qui a été immobilisé, quand, pourquoi, et sur quelle base.

Concrètement, on documente :

• les phases du projet (recherche → dev → mise en service) ;
• les coûts activés vs ceux passés en charge ;
• la date de mise en service (clé pour l’amortissement) ;
• la justification du choix de durée.

⚠️ Pas de doc = pas de traçabilité = risque fiscal.

Suivi et actualisation des amortissements

Un amortissement logiciel n’est jamais “fire and forget”.
Le logiciel évolue, la dette technique change, certaines fonctionnalités deviennent obsolètes : le plan d’amortissement doit suivre.

En pratique, on revoit chaque année :

• si la durée reste cohérente avec l’usage réel ;
• si une refonte ou un pivot modifie la valeur du logiciel ;
• si une mise à jour majeure doit déclencher une nouvelle immobilisation.

👉 Le suivi, c’est ce qui évite un actif fantôme… ou un logiciel amorti qui vit encore 10 ans dans le bilan.

Conclusion - Comptabiliser un logiciel interne, c’est piloter son cycle de vie

Comptabiliser un logiciel interne, c’est piloter un actif qui vit, évolue et s’use au rythme de votre produit.

• Bien capitaliser, c’est éviter les immobilisations gonflées, les durées absurdes et les surprises fiscales.
• Bien amortir, c’est anticiper la refonte, lisser les investissements et garder une roadmap réaliste.

Chez Yield, on voit la différence entre un logiciel “compté” et un logiciel “piloté” : le premier coûte cher, le second crée de la valeur.

👉 Vous développez ou faites évoluer un logiciel interne et vous voulez sécuriser à la fois la partie produit et la partie compta ? Parlons-en : on vous aide à cadrer, arbitrer… et éviter les pièges qui coûtent cher.

‍