Capitalisation des logiciels selon l'ASC 350-40 : Guide pratique pour la décision de capitalisation ou de comptabilisation en charges

Une enquête Gartner de 2024 a révélé que 63 % des fondateurs de SaaS en phase de démarrage classent mal les coûts de développement de logiciels. Cette erreur leur coûte sur deux fronts : les investisseurs dévalorisent leurs indicateurs financiers lorsque les classifications semblent approximatives, et les auditeurs signalent le problème lors de l'audit préalable (due diligence), ce qui peut retarder les levées de fonds ou les processus de vente de plusieurs mois.

La capitalisation des logiciels n'est pas qu'une simple technicité comptable. Elle affecte directement l'EBITDA, le bilan et la perception de votre entreprise par les prêteurs, les investisseurs et les acheteurs. Les règles de la norme ASC 350-40 — et une mise à jour majeure prévue pour 2025 — déterminent quels coûts sont portés immédiatement au compte de résultat et lesquels sont étalés sur plusieurs années.

Ce guide détaille les exigences de la norme, la récente refonte issue de l'ASU 2025-06, les coûts que vous pouvez capitaliser, ceux que vous ne pouvez pas, et les conséquences financières d'une application correcte.

Ce que couvre l'ASC 350-40

L'ASC 350-40 est la norme du FASB pour les logiciels à usage interne — des logiciels que votre entreprise développe ou achète pour ses propres opérations plutôt que pour les vendre à des clients comme produit principal. Les exemples incluent :

• Les systèmes internes de CRM, ERP, RH ou de comptabilité
• Les outils d'infrastructure cloud et les plateformes DevOps
• Une plateforme SaaS que vous exploitez pour vos clients (le client y accède en tant que service, et non comme un logiciel sous licence qu'il installe)
• Les pipelines de données internes, les tableaux de bord et les outils d'analyse
• L'automatisation personnalisée des flux de travail ou du back-office

Si vous vendez des logiciels sous licence que les clients installent sur leurs propres machines, cela relève de l'ASC 985-20 (logiciels destinés à la vente externe), qui comporte des règles différentes. La plupart des entreprises SaaS modernes relèvent de l'ASC 350-40 parce que les clients consomment le logiciel sous forme de service hébergé.

La question centrale à laquelle la norme répond est la suivante : lorsque vous dépensez de l'argent pour créer un logiciel, ce coût doit-il être passé en charges immédiatement ou capitalisé en tant qu'actif incorporel et amorti sur les périodes futures ?

L'ancien modèle à trois étapes (avant l'ASU 2025-06)

Pendant des décennies, l'ASC 350-40 a utilisé un cadre basé sur des étapes. Selon les anciennes directives toujours en vigueur pour la plupart des déclarants jusqu'en 2027, le développement de logiciels se divise en trois phases distinctes.

Étape 1 : Étape préliminaire du projet

Il s'agit de la phase exploratoire : définition des besoins, évaluation des technologies, démonstrations de fournisseurs et décision de construire, d'acheter ou de renoncer. Tous les coûts de cette étape sont comptabilisés en charges lors de leur engagement, à l'instar des frais de recherche. Le raisonnement est le suivant : tant que la direction ne s'est pas engagée, vous n'avez pas encore d'actif probable.

Les activités ici incluent :

• La formulation conceptuelle et les alternatives de conception
• Les démonstrations de fournisseurs et les évaluations technologiques
• Les analyses coûts-avantages et les études de faisabilité
• La sélection finale d'une approche ou d'un fournisseur

Étape 2 : Étape de développement de l'application

La capitalisation commence lorsque la direction autorise le projet, engage les fonds et que l'achèvement est probable. Cette étape couvre la construction proprement dite : codage, tests, configuration, intégration et installation.

Les coûts capitalisables à cette étape incluent généralement :

• Les salaires et avantages sociaux des développeurs, ingénieurs QA et chefs de projet (uniquement le temps directement attribuable au codage, aux tests et à la configuration du logiciel)
• Les honoraires de consultants externes pour les travaux de développement
• Les licences de logiciels et les outils utilisés pour construire l'application
• Les coûts directs des matériaux et services consommés lors du développement
• Les frais financiers (dans des cas limités)

La capitalisation s'arrête lorsque le logiciel est achevé en substance et prêt à l'usage prévu — généralement lorsque les tests sont terminés et que le système est déployé en production, même si le déploiement est progressif.

Étape 3 : Étape de post-mise en œuvre

Après la mise en service, les coûts récurrents redeviennent des charges. La formation, la maintenance, les corrections de bogues et le support de routine sont tous passés en charges. L'exception : les améliorations qui ajoutent de nouvelles fonctionnalités (et ne se contentent pas de corriger ou de maintenir des fonctionnalités existantes) peuvent être capitalisées en utilisant les mêmes critères que pour l'étape 2.

La mise à jour majeure de 2025 : ASU 2025-06

Le 18 septembre 2025, le FASB a publié l'ASU 2025-06, qui modernise considérablement l'ASC 350-40. La mise à jour est obligatoire pour les exercices annuels commençant après le 15 décembre 2027, avec une adoption anticipée autorisée.

Le changement est structurel : le modèle à trois étapes disparaît. Le FASB a explicitement supprimé toutes les références aux étapes du projet car le cadre hérité ne correspondait pas aux pratiques de développement agiles et itératives modernes, où les exigences évoluent et les « étapes » se chevauchent ou se déroulent en parallèle.

Le nouveau seuil fondé sur des principes

Selon la norme révisée, vous ne capitalisez les coûts de logiciels que lorsque ces deux conditions sont remplies :

1. Autorisation de la direction : La direction a autorisé le projet et s'est engagée à le financer.
2. Seuil de probabilité d'achèvement : Il est probable que le projet sera achevé et que le logiciel remplira sa fonction prévue.

Ce second test est crucial. Le FASB a introduit un concept appelé incertitude significative liée au développement pour évaluer si l'achèvement est probable. Vous devez évaluer :

• Si le logiciel inclut des fonctionnalités inédites ou non prouvées qui n'ont pas encore été validées par le codage ou les tests
• Si les exigences de performance sont encore indéterminées ou sujettes à une révision substantielle

En cas d'incertitude significative, la capitalisation doit être différée jusqu'à ce que l'incertitude soit levée. Le FASB a indiqué qu'il s'attend à ce que la nouvelle règle entraîne la passation en charges d'une plus grande partie des coûts logiciels, en particulier chez les entreprises SaaS où les exigences font l'objet d'itérations continues.

Ce que cela signifie en pratique

Pour une startup qui construit quelque chose de véritablement nouveau — une plateforme d'agents IA, un moteur d'automatisation novateur — la nouvelle règle peut pousser davantage de dépenses vers les charges d'exploitation plus tôt. Pour les entreprises matures qui améliorent des systèmes bien définis, l'impact pratique sera plus faible. Quoi qu'il en soit, le passage d'une vérification d'étape mécanique à un seuil basé sur le jugement signifie que les entreprises ont besoin d'une documentation plus claire des décisions de gestion, de la faisabilité technique et de l'état d'avancement des projets.

Ce que vous pouvez et ne pouvez pas capitaliser : une liste de contrôle pratique

Que vous appliquiez le modèle hérité par étapes ou les nouveaux tests basés sur des principes, la frontière entre les dépenses capitalisables et celles passées en charges reste similaire dans l'esprit. Voici une liste de contrôle opérationnelle.

Généralement capitalisable

• Coûts de main-d'œuvre directe pour les développeurs, les designers et l'assurance qualité (QA) pendant la phase de construction
• Charges sociales et avantages sociaux affectés pour ces employés
• Frais de consultants externes et de prestataires pour les travaux de développement
• Coûts des logiciels, des outils et de l'infrastructure cloud directement consommés lors du développement
• Coûts de développement de nouvelles fonctionnalités après le lancement (améliorations qui étendent matériellement les capacités)
• Coûts de développement de logiciels de conversion (le logiciel qui migre les anciennes données vers les nouvelles), par opposition à l'activité de conversion de données elle-même

Généralement passé en charges

• Recherche préliminaire, sélection des fournisseurs et analyse de faisabilité
• Formation des employés au nouveau système
• Nettoyage, rapprochement et migration des données
• Maintenance de routine, corrections de bugs et refactorisation mineure
• Coûts logiciels engagés pendant des périodes d'incertitude significative quant au développement
• Frais généraux administratifs non directement liés au développement
• Activités de marketing, de support et de réussite client (customer success) après le lancement

La problématique du suivi du temps

Le plus grand défi pratique est l'allocation du temps d'ingénierie. Il est peu probable qu'un ingénieur senior passant 40 heures par semaine effectue un travail 100 % capitalisable — il débugue également la production, encadre des coéquipiers, assiste à des standups et examine des pull requests pour des systèmes hérités. Sans une méthode de suivi du temps défendable (tickets d'ingénierie étiquetés par projet, logiciel de suivi du temps ou enquêtes d'allocation formelles), les estimations de capitalisation ne résisteront pas à l'examen d'un audit.

L'impact sur les états financiers

Capitaliser versus passer en charges le même dollar produit des états financiers radicalement différents.

Effet sur le compte de résultat

Un coût capitalisé n'impacte pas le compte de résultat lors de la période de dépense. Au lieu de cela, il est amorti — généralement de manière linéaire sur trois à cinq ans pour les logiciels à usage interne. Ainsi, 1 million de dollars de dépenses d'ingénierie capitalisées en année 1 pourrait ne créer que 200 000 $à 333 000$ de dotations aux amortissements chaque année, laissant le résultat d'exploitation de l'année 1 matériellement plus élevé.

C'est pourquoi l'EBITDA bénéficie d'un coup de pouce grâce à la capitalisation. L'amortissement est, par définition, exclu de l'EBITDA — ainsi, capitaliser davantage de coûts de développement déplace des dollars des charges d'exploitation (qui réduisent l'EBITDA) vers l'amortissement (qui ne le réduit pas). Les investisseurs qui scrutent les indicateurs SaaS examinent souvent « l'EBITDA avant R&D capitalisée » ou les calculs de la « règle des 40 » utilisant la R&D décaissée pour percer cette dynamique à jour.

Effet sur le bilan

Le logiciel capitalisé apparaît comme un actif incorporel à long terme, souvent libellé « Coûts de développement de logiciels capitalisés » ou similaire. Ceci :

• Augmente le total des actifs et des capitaux propres
• Améliore la rentabilité des actifs (ROA) uniquement si les bénéfices augmentent plus rapidement que la base d'actifs
• Crée un actif qui doit faire l'objet d'un test de dépréciation si le projet est abandonné ou si sa valeur diminue

Si un projet est abandonné en plein développement, les coûts précédemment capitalisés doivent être passés en perte — ce qui produit une perte soudaine, souvent matérielle. C'est l'une des raisons pour lesquelles la nouvelle norme ASU 2025-06 met autant l'accent sur le seuil de « probabilité d'achèvement ».

Effet sur le tableau des flux de trésorerie

Les coûts de développement capitalisés sont généralement classés dans les activités d'investissement (et non opérationnelles), ce qui rend le flux de trésorerie opérationnel plus robuste. Les investisseurs avertis ajustent ce point lorsqu'ils comparent des entreprises — mais le chiffre principal en bénéficie tout de même.

Erreurs courantes qui mettent les entreprises en difficulté

Les auditeurs et les acquéreurs voient les mêmes erreurs se répéter.

Capitalisation des coûts pré-autorisation

L'erreur classique consiste à capitaliser le temps d'ingénierie passé avant que la direction n'ait formellement approuvé le projet. Sans une autorisation documentée et un engagement de financement, ces coûts auraient dû être passés en charges. Assurez-vous d'avoir des procès-verbaux de réunion, des approbations du conseil d'administration ou des signatures écrites établissant le moment où la direction s'est engagée.

Absence de documentation au niveau du projet

Si un régulateur ou un auditeur demande « montrez-moi les projets que vous avez capitalisés » et que vous ne pouvez pointer que des dépenses d'ingénierie générales, vous perdrez. Vous avez besoin de dossiers projet par projet : portée, date d'autorisation, budget, statut et temps facturé.

Traiter tout le temps d'ingénierie comme capitalisable

Les ingénieurs seniors corrigent des bugs, révisent du code, assistent à des réunions et répondent aux incidents. Rien de tout cela n'est capitalisable. Les entreprises qui multiplient simplement la masse salariale de l'équipe d'ingénierie par un certain pourcentage survivent rarement à un audit.

Continuer la capitalisation après le lancement

Dès que le logiciel est prêt pour l'usage prévu, la capitalisation s'arrête. Les corrections de bugs, l'optimisation des performances et les améliorations mineures après ce point sont des dépenses d'exploitation. De nouvelles fonctionnalités avec un périmètre distinct peuvent entamer une nouvelle période de capitalisation — mais les travaux de routine post-lancement ne le peuvent pas.

Oublier les tests de dépréciation

Un logiciel capitalisé est un actif, et les actifs doivent faire l'objet d'un test de dépréciation si leur valeur chute. Si vous mettez un produit en sommeil, abandonnez une fonctionnalité ou réécrivez fondamentalement le système, vous devez réévaluer et probablement sortir de l'actif le solde précédent.

Comment mettre en place un processus justifiable

Si vous décidez que la capitalisation convient à votre entreprise, le processus importe autant que la politique.

1. Rédigez une politique de capitalisation des logiciels. Définissez quels projets sont éligibles, votre processus d'autorisation, votre estimation de la durée d'utilité et la manière dont vous répartirez le temps. Obtenez la validation de votre CFO ou de votre comité d'audit.

2. Suivez le temps d'ingénierie au niveau du projet. C'est la donnée de base fondamentale. Que vous utilisiez des étiquettes Jira, des tags personnalisés dans un outil de suivi de projet ou des feuilles de temps formelles, vous devez être en mesure de justifier que « l'ingénieur X a passé Y % de son temps sur des travaux capitalisables pour le projet Z ».

3. Documentez l'approbation de la direction. Chaque projet capitalisable doit faire l'objet d'une preuve d'autorisation — approbation écrite datée, procès-verbaux de conseil d'administration ou une charte de projet signée par la direction.

4. Réévaluez régulièrement l'incertitude significative. Selon la nouvelle règle, vous devez surveiller si les fonctionnalités sont toujours inédites ou non prouvées et si les exigences se stabilisent. Des revues trimestrielles avec la direction technique sont raisonnables.

5. Établissez des tableaux d'amortissement par projet. Chaque projet capitalisé commence à s'amortir lorsqu'il est prêt à l'emploi, et vous devez suivre la base de coût de cet actif, les amortissements cumulés et la durée de vie résiduelle.

6. Testez la dépréciation lors des changements de projet. Chaque fois que vous abandonnez, réécrivez matériellement ou délaissez des travaux capitalisés, effectuez une analyse de dépréciation et enregistrez les réductions de valeur nécessaires.

Pourquoi cela compte pour la comptabilité

La capitalisation des logiciels est l'un de ces domaines où la discipline en tenue de livres dès le premier jour porte ses fruits des années plus tard. Les investisseurs lors d'une levée de fonds en Série B examineront votre balance de vérification ; les acquéreurs lors d'un processus de vente remonteront les transactions jusqu'aux écritures de journal ; l'IRS pourra comparer votre traitement GAAP à votre traitement fiscal R&D de la Section 174, qui possède ses propres règles. Si vos livres ne séparent pas les projets capitalisés des dépenses d'exploitation, ne peuvent pas lier les charges de temps d'ingénierie à des projets spécifiques ou ne maintiennent pas des tableaux d'amortissement clairs, chaque cycle d'audit et de diligence devient pénible.

La solution est simple sur le principe : maintenez une structure de comptes propre, suivez le temps au niveau du projet et documentez les décisions derrière chaque écriture de capitalisation. Faire cela dès le début évite des nettoyages coûteux plus tard.

Gardez votre comptabilité logicielle prête pour l'audit

Que vous capitalisiez votre première plateforme interne ou que vous gériez des tableaux d'amortissement sur des dizaines de projets, des registres financiers propres sont la base. Beancount.io propose une comptabilité en texte brut qui vous offre des livres transparents et contrôlés par version — chaque écriture est traçable, chaque compte est auditable, chaque rapport est reproductible. Pour les entreprises de logiciels qui suivent le développement capitalisé sur plusieurs projets, avoir des livres qui se lisent comme du code est un avantage sérieux. Commencez gratuitement et découvrez pourquoi les développeurs et les professionnels de la finance passent à la comptabilité en texte brut.