L'ASC 350-40 — le sujet de codification que les chercheurs saisissent souvent comme 350/40 — est la règle du FASB pour les logiciels à usage interne : quand le coût de développement est passé en charges immédiatement par rapport à capitalisé en tant qu'actif incorporel et amorti ultérieurement. Sous l'ancien modèle en trois étapes (toujours appliqué par la plupart des déclarants jusqu'à la date obligatoire de l'ASU 2025-06), la réponse tient dans un tableau :
| Étape | Ce qui se passe | Capitaliser ou passer en charges ? |
|---|---|---|
| Projet préliminaire | Exigences, démos fournisseurs, faisabilité, build-vs-buy | Passer en charges au fur et à mesure |
| Développement de l'application | Codage, configuration, test, intégration après engagement de la direction | Capitaliser les coûts directs de construction |
| Post-mise en œuvre | Formation, maintenance, corrections de bugs après la mise en service | Passer en charges (les nouvelles fonctionnalités peuvent relancer la capitalisation) |
L'ASU 2025-06 (publié le 18 septembre 2025 ; obligatoire pour les exercices annuels commençant après le 15 décembre 2027) supprime ces libellés d'étapes au profit d'un seuil de probabilité d'achèvement et signale que davantage de coûts seront passés en charges. Les sections ci-dessous couvrent ce que comprend l'ASC 350-40, le détail des étapes, la mise à jour 2025, la liste de contrôle capitaliser/passer en charges, et l'impact du choix sur l'EBITDA et le bilan.
Ce que couvre l'ASC 350-40
L'ASC 350-40 est la norme du FASB pour les logiciels à usage interne — les logiciels que votre entreprise construit ou achète pour ses propres opérations plutôt que de les vendre aux clients comme produit principal. Les exemples incluent :
- Systèmes internes de CRM, ERP, RH ou comptabilité
- Outillage d'infrastructure cloud et plateformes DevOps
- Une plateforme SaaS que vous exploitez pour les clients (le client y accède comme un service, pas comme un logiciel sous licence qu'il installe)
- Pipelines de données internes, tableaux de bord et outils d'analyse
- Automatisation de flux de travail sur mesure ou de 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 a des règles différentes. La plupart des entreprises SaaS modernes relèvent de l'ASC 350-40 car les clients consomment le logiciel comme un service hébergé.
La question centrale à laquelle répond la norme : lorsque vous dépensez de l'argent pour construire 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 en trois étapes (pré-ASU 2025-06)
Pendant des décennies, l'ASC 350-40 a utilisé un cadre basé sur les étapes. Selon les directives héritées 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
C'est la phase d'exploration — définir les exigences, évaluer les technologies, obtenir des démos des fournisseurs, et décider de construire, acheter ou passer. Tous les coûts de cette étape sont passés en charges au fur et à mesure, similaires aux dépenses de recherche. Le raisonnement : jusqu'à ce que la direction s'engage, vous n'avez pas encore d'actif probable.
Les activités ici comprennent :
- Formulation conceptuelle et alternatives de conception
- Démos fournisseurs et évaluations technologiques
- Analyses coûts-bénéfices et études de faisabilité
- 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 un financement, et que l'achèvement est probable. Cette étape couvre la construction réelle — codage, test, configuration, intégration et installation.
Les coûts capitalisables de cette étape comprennent généralement :
- Salaires et avantages des développeurs, ingénieurs QA et chefs de projet (uniquement le temps directement attribuable au codage, aux tests et à la configuration du logiciel)
- Honoraires de conseil externes pour le travail de développement
- Licences de logiciels et outils utilisés pour construire l'application
- Coûts directs des matériaux et services consommés dans le développement
- Frais d'intérêt (dans des cas limités)
La capitalisation s'arrête lorsque le logiciel est substantiellement terminé et prêt pour son utilisation prévue — 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 post-mise en œuvre
Après la mise en service, les coûts continus reviennent à un traitement en charges. La formation, la maintenance, les corrections de bugs et le support de routine sont tous passés en charges. L'exception : les améliorations qui ajoutent de nouvelles fonctionnalités (pas seulement corriger ou maintenir les fonctionnalités existantes) peuvent être capitalisées en utilisant les mêmes critères que l'étape 2.
La grande mise à jour 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 adoption anticipée autorisée.
Le changement est structurel : le modèle en trois étapes a disparu. Le FASB a explicitement supprimé toutes les références aux étapes de projet car le cadre hérité ne correspondait pas aux pratiques modernes de développement agile et itératif, où les exigences évoluent et où les « étapes » se chevauchent ou s'exécutent en parallèle.
Le nouveau seuil basé sur les principes
Selon la norme révisée, vous capitalisez les coûts de logiciels uniquement lorsque ces deux conditions sont remplies :
- Autorisation de la direction : La direction a autorisé et s'est engagée à financer le projet.
- Seuil de probabilité d'achèvement : Il est probable que le projet sera achevé et que le logiciel remplira sa fonction prévue.
Ce deuxième test fait un vrai travail. Le FASB a introduit un concept appelé incertitude significative de développement pour évaluer si l'achèvement est probable. Vous devez évaluer :
- Si le logiciel comprend des fonctionnalités nouvelles ou non prouvées qui n'ont pas été validées par le codage ou les tests
- Si les exigences de performance sont encore indéterminées ou sujettes à des révisions substantielles
Si une incertitude significative existe, la capitalisation doit être différée jusqu'à ce que l'incertitude soit résolue. Le FASB a signalé qu'il s'attend à ce que la nouvelle règle entraîne davantage de coûts de logiciels passés en charges, en particulier dans les entreprises SaaS où les exigences itèrent en continu.
Ce que cela signifie en pratique
Pour une startup construisant quelque chose de véritablement nouveau — une plateforme d'agents IA, un moteur d'automatisation novateur — la nouvelle règle peut pousser plus de dépenses vers les charges d'exploitation plus tôt. Pour les entreprises matures améliorant des systèmes bien définis, l'impact pratique sera plus faible. Quoi qu'il en soit, le passage d'une vérification mécanique des étapes à 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 du projet.
Ce que vous pouvez et ne pouvez pas capitaliser : une liste de contrôle pratique
Que vous appliquiez le modèle d'étapes hérité ou le nouveau test basé sur les principes, la ligne entre les dépenses capitalisables et celles passées en charges est similaire dans l'esprit. Voici une liste de contrôle de travail.
Généralement capitalisable
- Coûts de main-d'œuvre directs pour les développeurs, concepteurs et QA pendant la phase de construction
- Taxes sur les salaires et avantages alloués pour ces employés
- Honoraires de conseil et d'entrepreneurs externes pour le travail de développement
- Logiciels, outils et coûts d'infrastructure cloud directement consommés dans le développement
- Coûts de développement de nouvelles fonctionnalités après le lancement (améliorations qui élargissent matériellement les capacités)
- Coûts de développement de logiciels de conversion (le logiciel qui migre les anciennes données vers le nouveau), par opposition à l'activité de conversion des 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 sur le nouveau système
- Nettoyage des données, rapprochement et migration des enregistrements
- Maintenance de routine, corrections de bugs et refactorisation mineure
- Coûts de logiciels encourus pendant les périodes d'incertitude significative de 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 après le lancement
Le problème du suivi du temps
Le plus grand défi pratique est l'allocation du temps d'ingénierie. Un ingénieur senior passant 40 heures par semaine est peu susceptible de faire 100 % de travail capitalisable — ils déboguent aussi la production, encadrent les coéquipiers, assistent aux réunions debout et revoient les pull requests pour les systèmes hérités. Sans une méthode défendable de suivi du temps (tickets d'ingénierie étiquetés par projet, logiciels de suivi du temps, ou enquêtes d'allocation formelles), les estimations de capitalisation échoueront à l'examen des audits.
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é ne touche pas le compte de résultat dans la période où il est dépensé. Au lieu de cela, il est amorti — généralement en ligne droite sur trois à cinq ans pour les logiciels à usage interne. Donc, 1 M$ de dépenses d'ingénierie capitalisées en année 1 pourrait créer seulement 200 K$ à 333 K$ de charge d'amortissement chaque année, laissant le résultat d'exploitation de l'année 1 matériellement plus élevé.
C'est pourquoi l'EBITDA est boosté par la capitalisation. L'amortissement est, par définition, exclu de l'EBITDA — donc capitaliser plus de coûts de développement déplace les dollars des charges d'exploitation (qui réduisent l'EBITDA) vers l'amortissement (qui ne le fait pas). Les investisseurs qui scrutent les métriques SaaS regardent souvent « l'EBITDA avant R&D capitalisée » ou les calculs de règle de 40 utilisant la R&D en espèces pour voir à travers cette dynamique.
Effet sur le bilan
Le logiciel capitalisé apparaît comme un actif incorporel à long terme, souvent étiqueté « Coûts de développement de logiciels capitalisés » ou similaire. Cela :
- Augmente le total des actifs et les capitaux propres
- Améliore le rendement des actifs (ROA) uniquement si les bénéfices augmentent plus vite que la base d'actifs
- Crée un actif qui doit être testé pour 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 par pertes — ce qui produit une perte soudaine, souvent matérielle. C'est une raison pour laquelle la nouvelle 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 (pas d'exploitation), ce qui rend le flux de trésorerie d'exploitation plus solide. Les investisseurs sophistiqués ajustent cela lors de la comparaison des entreprises — mais le chiffre principal en bénéficie toujours.
Erreurs courantes qui causent des problèmes aux entreprises
Les auditeurs et les acquéreurs voient les mêmes erreurs encore et encore.
Capitaliser des coûts pré-autorisation
L'erreur classique est de 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éunions, des approbations du conseil ou des signatures écrites qui établissent quand la direction s'est engagée.
Aucune 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 vers des dépenses générales d'ingénierie, vous perdrez. Vous avez besoin d'enregistrements 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, revoient 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 pourcentage survivent rarement à un audit.
Continuer à capitaliser après le lancement
Le moment où le logiciel est prêt pour son utilisation prévue, la capitalisation s'arrête. Les corrections de bugs, l'optimisation des performances et les améliorations mineures après ce point sont des charges d'exploitation. De nouvelles fonctionnalités, distinctement définies, peuvent démarrer une nouvelle période de capitalisation — mais le travail de routine post-lancement ne le peut pas.
Oublier les tests de dépréciation
Le logiciel capitalisé est un actif, et les actifs doivent être dépréciés si leur valeur diminue. Si vous mettez un produit au rancart, mettez fin à une fonctionnalité ou réécrivez fondamentalement le système, vous devez réévaluer et probablement passer par pertes le solde précédent.
Comment mettre en place un processus défendable
Si vous décidez que la capitalisation est la bonne approche pour votre entreprise, le processus compte autant que la politique.
-
Rédigez une politique de capitalisation des logiciels. Définissez quels projets sont admissibles, votre processus d'autorisation, votre estimation de durée de vie utile et comment vous allouerez le temps. Obtenez l'approbation de votre directeur financier ou du comité d'audit.
-
Suivez le temps d'ingénierie au niveau du projet. C'est l'intrant fondamental. Que vous utilisiez des étiquettes Jira, des tags personnalisés dans un gestionnaire de projet ou des feuilles de temps formelles, vous devez défendre « l'ingénieur X a passé Y % de son temps sur un travail capitalisable sur le projet Z ».
-
Documentez l'approbation de la direction. Chaque projet capitalisable a besoin d'une preuve d'autorisation — approbation écrite datée, procès-verbaux du conseil ou charte de projet signée par la direction.
-
Réévaluez régulièrement l'incertitude significative. Selon la nouvelle règle, vous devez surveiller si les fonctionnalités sont toujours nouvelles ou non prouvées et si les exigences se stabilisent. Des examens trimestriels avec la direction de l'ingénierie sont raisonnables.
-
Construisez des calendriers d'amortissement par projet. Chaque projet capitalisé commence à s'amortir lorsqu'il est prêt à être utilisé, et vous devez suivre la base de coût de cet actif, l'amortissement cumulé et la durée de vie restante.
-
Testez la dépréciation lorsque les projets changent. À chaque fois que vous abandonnez, réécrivez matériellement ou mettez fin à un travail capitalisé, effectuez une analyse de dépréciation et comptabilisez les dépréciations au besoin.
Pourquoi cela compte pour la tenue de livres
La capitalisation des logiciels est l'un de ces domaines où la discipline de la tenue de livres dès le premier jour porte ses fruits des années plus tard. Les investisseurs lors d'un tour de table de série B retireront votre balance de vérification ; les acquéreurs dans un processus de vente retraceront les transactions jusqu'aux écritures de journal ; l'IRS peut comparer votre traitement GAAP à votre traitement fiscal de R&D Section 174, qui a ses propres règles. Si vos livres ne séparent pas les projets capitalisés des charges d'exploitation, ne peuvent pas lier les charges de temps d'ingénierie à des projets spécifiques, ou ne maintiennent pas de calendriers d'amortissement propres, chaque cycle d'audit et de diligence devient douloureux.
La solution est simple en concept : maintenez une structure de compte 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épart é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 calendriers d'amortissement sur des dizaines de projets, des dossiers financiers propres sont la base. Beancount.io fournit une comptabilité en texte brut qui vous donne des livres transparents et versionnés — chaque écriture traçable, chaque compte auditable, chaque rapport 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.
