Dette technique et immobilisation logicielle : comment comptabiliser une refonte SaaS ?

La dette technique est une métaphore empruntée à la finance : tout comme une dette financière génère des intérêts qui s'accumulent avec le temps, une dette technique crée un coût croissant de maintenance et de ralentissement du développement. Un choix d'architecture rapide mais sous-optimal en 2021 coûte de plus en plus cher à maintenir en 2024 et peut bloquer des évolutions fonctionnelles importantes en 2026.

À un moment dans la vie de tout SaaS en croissance, la refonte technique devient inévitable. Et quand ce moment arrive, une question comptable que beaucoup de fondateurs n'ont pas anticipée se pose avec une acuité immédiate : les centaines de milliers d'euros investis dans cette refonte sont-ils des charges qui pèsent sur le résultat de l'exercice, ou des actifs que vous pouvez amortir sur plusieurs années ?

La réponse a un impact direct et significatif sur votre résultat fiscal et sur la présentation de vos comptes pour les investisseurs ou les acquéreurs potentiels. Une refonte de 300 000 euros passée intégralement en charges réduit votre résultat imposable de 300 000 euros cette année (avantage fiscal immédiat, résultat comptable amputé. La même refonte immobilisée et amortie sur 3 ans réduit votre résultat de seulement 100 000 euros par an) avantage fiscal étalé, bilan plus capitalisé.

La règle fondamentale : charges versus actifs incorporels

En comptabilité française (PCG - Plan Comptable Général), les coûts de développement informatique se répartissent en deux catégories avec des traitements radicalement différents.

Les charges d'exploitation

Les dépenses qui maintiennent le logiciel à son niveau de performance actuel sans créer de capacité nouvelle sont des charges d'exploitation de l'exercice. Elles réduisent votre résultat de l'année où elles sont engagées et sont immédiatement déductibles fiscalement.

Entrent dans cette catégorie : la correction de bugs (quel que soit leur nombre et leur gravité), les mises à jour de sécurité et les patchs, les adaptations réglementaires (mise en conformité RGPD, nouvelles règles comptables, modifications d'APIs bancaires qui changent mais n'étendent pas vos fonctionnalités), les améliorations de performance sans ajout de fonctionnalités (optimisation des temps de chargement, refactoring du code sans modification des capacités), la migration de données vers une nouvelle architecture quand les données restent identiques, la formation des équipes à la nouvelle architecture.

Les actifs incorporels immobilisables

Les dépenses qui créent une capacité nouvelle, étendent significativement les fonctionnalités existantes ou construisent un actif dont les avantages économiques s'étendront sur plusieurs exercices peuvent être immobilisées en actifs incorporels. Elles sont alors amorties sur leur durée d'utilité et ne pèsent sur le résultat que progressivement.

Entrent dans cette catégorie : le développement de nouvelles fonctionnalités qui n'existaient pas auparavant, la création d'une nouvelle architecture qui ouvre des capacités inédites (scalabilité vers de nouveaux marchés, nouvelles intégrations techniques, nouvelle performance qui rend faisable des cas d'usage impossibles précédemment), le développement d'APIs nouvelles qui permettent des intégrations tierces non disponibles auparavant, la construction d'une nouvelle interface utilisateur qui transforme l'expérience produit (pas une simple amélioration ergonomique).

Les six conditions d'immobilisation des coûts de développement

La possibilité d'immobiliser des coûts de développement informatique en droit comptable français n'est pas automatique. Six conditions doivent être simultanément satisfaites pour que l'immobilisation soit possible.

Condition 1 : faisabilité technique démontrée

Vous devez pouvoir démontrer que l'achèvement du développement est techniquement faisable. Pour une refonte d'architecture, cela signifie que les choix techniques ont été validés (choix du langage, du framework, de l'infrastructure) et que des preuves de concept ont démontré la viabilité de l'approche.

Condition 2 : intention d'achever et d'utiliser

L'intention de la direction d'achever le projet et d'utiliser ou de vendre le logiciel résultant doit être documentée. Un projet annulé après avoir commencé l'immobilisation doit faire l'objet d'une dépréciation immédiate de l'actif partiel constitué.

Condition 3 : capacité à utiliser ou vendre

Vous devez être capable d'utiliser le logiciel une fois développé (vous avez les ressources pour le déployer et le maintenir) ou de le vendre (vous avez un marché pour le commercialiser).

Condition 4 : avantages économiques futurs probables

Le logiciel développé devra probablement générer des avantages économiques futurs : soit directement (revenus supplémentaires grâce aux nouvelles fonctionnalités), soit indirectement (économies de coûts, fidélisation clients, compétitivité améliorée).

Condition 5 : ressources disponibles

Les ressources techniques, financières et humaines nécessaires pour achever le développement sont disponibles ou seront disponibles. Un projet ambitieux sans financement sécurisé au-delà des 6 prochains mois peut ne pas satisfaire cette condition.

Condition 6 : évaluation fiable des dépenses

Vous devez être capable d'évaluer de façon fiable les dépenses de développement attribuables à ce projet. C'est la condition qui impose le time tracking précis, sans suivi du temps passé par chaque développeur sur ce projet, vous ne pouvez pas évaluer de façon fiable le montant à immobiliser.

Ces six conditions sont cumulatives. Si l'une n'est pas satisfaite, l'ensemble des coûts de développement doit être passé en charges.

La complication réelle d'une refonte : la séparation entre travaux immobilisables et non-immobilisables

Dans la réalité d'un projet de refonte SaaS, les travaux immobilisables et non-immobilisables sont entremêlés et souvent réalisés par les mêmes développeurs dans les mêmes sprints. Un sprint de 2 semaines peut inclure simultanément de la correction de bugs legacy (charge), de la réécriture d'un module existant en équivalent fonctionnel (charge : même fonctionnalité, nouvelle implémentation), du développement d'une nouvelle API d'intégration (actif immobilisable), et de la migration de données (charge).

La séparation comptable de ces travaux requiert un dispositif de time tracking structuré qui distingue, pour chaque développeur et chaque unité de temps, à quelle catégorie de travaux correspond le temps passé.

La méthode de suivi recommandée

Créez dans votre outil de gestion de projet (Linear, Jira, GitHub Issues) des catégories qui correspondent aux traitements comptables. Par exemple : "Maintenance et correction" (charges) / "Nouvelles fonctionnalités" (actifs potentiellement immobilisables) / "Migration et transition" (charges) / "Architecture et infrastructure nouvelles" (actifs potentiellement immobilisables).

Chaque ticket ou issue est catégorisé à sa création dans l'une de ces catégories. Chaque développeur logue son temps par catégorie (et pas seulement par ticket s'il travaille sur plusieurs catégories dans la même journée).

À chaque fin de sprint, exportez le temps total par catégorie et par développeur. Valorisez ce temps au coût horaire chargé de chaque développeur (salaire brut + charges patronales + quote-part des avantages en nature et des outils). La somme des heures "nouvelles fonctionnalités" et "architecture nouvelle" valorisées constitue le montant potentiellement immobilisable de la période.

La granularité requise

La question n'est pas de suivre le temps à la minute près mais d'avoir une décomposition qui soit défendable en cas de contrôle fiscal. Une décomposition à la demi-journée est généralement suffisante. Un suivi par semaine est trop grossier et crée des ambiguïtés dans les décisions de catégorisation.

Le traitement comptable de l'immobilisation

L'écriture lors de la création de l'actif

Pendant la période de développement immobilisable, les coûts engagés sont portés dans un compte d'actif en cours : compte 232 (Immobilisations incorporelles en cours) pour les travaux en cours de développement. A chaque fin de mois, vous débitez le compte 232 et créditez le compte de charges correspondant (621 pour les salaires des développeurs affectés au projet immobilisable, ou les comptes de prestations externes si vous faites appel à des prestataires).

La mise en service et le passage en immobilisation définitive

Quand le développement est achevé et le logiciel mis en production, l'actif en cours est transféré vers un compte d'immobilisation définitif : compte 205 (Logiciels et concessions). L'écriture est : débit 205 - Logiciels, crédit 232 - Immobilisations en cours.

L'amortissement

L'amortissement commence à la date de mise en service du logiciel (pas à la date de début des développements). La durée d'amortissement retenue doit correspondre à la durée d'utilité estimée du logiciel : en pratique, entre 3 ans (pour des composants technologiques à évolution rapide) et 5 ans (pour des modules plus stables).

L'amortissement est linéaire : un logiciel immobilisé à 200 000 euros avec une durée d'utilité de 4 ans génère une dotation aux amortissements de 50 000 euros par an pendant 4 ans.

Un exemple chiffré complet d’immobilisation pour refonte technique d’un SaaS

Votre équipe de 4 développeurs passe 6 mois sur une refonte. Voici la décomposition des travaux :

40% du temps : correction de bugs legacy et réécriture fonctionnellement équivalente (charges). 25% du temps : développement de nouvelles intégrations et APIs (actifs immobilisables). 35% du temps : migration de données et infrastructure (charges).

Coût total des 6 mois de développement (salaires chargés) : 300 000 euros.

Part immobilisable (25%) : 75 000 euros. Part passée en charges (75%) : 225 000 euros.

Au bilan, vous activez 75 000 euros en immobilisations incorporelles (compte 205). Ces 75 000 euros sont amortis sur 3 ans, soit 25 000 euros d'amortissement par an.

En résultat, les 225 000 euros de charges réduisent votre résultat de l'exercice. La dotation aux amortissements des 3 années suivantes (25 000 euros par an) réduit votre résultat de chaque exercice.

La dette technique dans les états financiers et les due diligences

La dette technique en elle-même n'est pas un élément qui figure dans les états financiers au sens strict. Ce n'est pas un passif (pas de créancier), pas une provision (l'obligation future de refonte n'est pas suffisamment précise et certaine pour être provisionnée selon les critères comptables) et pas un actif négatif.

Cependant, lors d'une due diligence investisseur ou d'une cession, la dette technique est un sujet systématiquement abordé et souvent le plus sensible de l'audit technique.

Les acquéreurs et investisseurs expérimentés commandent un audit de code pour évaluer la qualité de l'architecture et estimer le coût de résorbement de la dette technique. Ce coût estimé peut faire l'objet d'un ajustement de valorisation : si la due diligence révèle 500 000 euros de travaux nécessaires pour moderniser l'architecture, l'acquéreur déduira tout ou partie de ce montant du prix de cession.

Avoir une documentation précise de l'état de votre dette technique, de votre plan de résorbement et des coûts associés (correctement qualifiés entre charges et immobilisations futures) renforce considérablement votre crédibilité lors d'une levée de fonds ou d'une cession.

La question fiscale : déduire maintenant ou étaler dans le temps ?

Du point de vue de l'optimisation fiscale pure, passer les coûts de développement en charges est toujours plus avantageux à court terme : vous déduisez 300 000 euros cette année plutôt que 75 000 euros sur 4 ans. Si vous êtes en situation bénéficiaire et imposé à l'IS, la déduction immédiate génère une économie d'IS de 300 000 × 25% = 75 000 euros cette année.

L'immobilisation est plus avantageuse dans plusieurs situations : quand vous êtes déficitaire (les charges n'ont aucun avantage fiscal si vous n'avez pas de résultat positif), quand vous préparez une cession et voulez maximiser votre bilan (les actifs au bilan sont perçus positivement par les acquéreurs), quand vous préparez une levée de fonds et voulez que votre résultat reflète votre potentiel plutôt que vos investissements.

La décision d'immobiliser ou de passer en charges doit tenir compte de votre situation fiscale actuelle, de votre trajectoire de résultat prévisionnelle et de vos objectifs à court et moyen terme.

Excilio, l’expert-comptable compétent pour les éditeurs SaaS

Excilio accompagne les éditeurs SaaS sur la comptabilisation de leurs développements logiciels, la mise en place du time tracking comptable qui permet l'immobilisation, l'optimisation fiscale de la décision charges/actifs et la préparation des états financiers pour les due diligences.