Demandez à un responsable de l'ingénierie logicielle quand un projet a « démarré », il vous répondra par un numéro de sprint. Posez la même question à son contrôleur de gestion et, selon les règles comptables qui régissent les logiciels à usage interne depuis 1998, la réponse était censée provenir d'une liste de contrôle rigide en trois étapes, qui suppose que personne n'écrit de code tant que les exigences ne sont pas figées. Quiconque a livré du logiciel au cours de la dernière décennie sait que ce n'est plus ainsi que les choses fonctionnent — et en septembre 2025, le FASB l'a enfin reconnu lui aussi.
Mise à jour des normes comptables (ASU) 2025-06, Immobilisations incorporelles — Écart d'acquisition et autres — Logiciels à usage interne (sous-thème 350-40) : améliorations ciblées de la comptabilisation des logiciels à usage interne, élimine entièrement l'ancien test fondé sur les étapes et le remplace par une question unique, fondée sur le jugement : est-il probable que ce logiciel sera réellement achevé et remplira la fonction prévue ? Pour toute entreprise qui développe des logiciels en interne — et en particulier pour les équipes agiles pour lesquelles l'ancienne règle n'a jamais été conçue — cela change le moment où les coûts de développement passent du compte de résultat au bilan, et dans quelle proportion.
Le problème : un référentiel de 1998 pensé pour le développement en cascade
La norme que remplace l'ASU 2025-06, l'ASC 350-40 (à l'origine le SOP 98-1), a été rédigée à une époque où « développement logiciel » signifiait un processus linéaire en cascade. Elle divisait tout projet de logiciel à usage interne en trois étapes séquentielles :
- Étape préliminaire du projet — formulation conceptuelle, évaluation des alternatives, sélection des fournisseurs. Tout ce qui relève de cette étape est comptabilisé en charges au fur et à mesure.
- Étape de développement de l'application — codage proprement dit, configuration et tests. Les coûts de cette étape sont capitalisés.
- Étape post-implémentation — formation et maintenance. De nouveau comptabilisée en charges.
Ce cadre fonctionne bien si une équipe passe trois mois à rédiger un cahier des charges, obtient une validation, puis commence à construire. Il s'effondre dès qu'une équipe travaille en sprints de deux semaines, livre des versions incrémentales et révise son périmètre à chaque rétrospective. Dans un environnement agile, les étapes « préliminaire » et « développement de l'application » ne sont pas des phases séquentielles — elles s'entremêlent, parfois au sein d'un même sprint. Les entreprises et leurs auditeurs ont passé des années à se disputer sur l'étape à laquelle appartenait réellement tel ou tel sprint de deux semaines, et la réponse honnête était souvent « un peu des deux, on suppose ». Les consultations menées par le FASB lui-même ont révélé que les parties prenantes signalaient systématiquement ce point comme l'un des aspects les plus pénibles à appliquer de manière cohérente dans les US GAAP.
La solution : un seul test, pas trois étapes
L'ASU 2025-06 supprime toute référence aux anciennes étapes de projet. À leur place, elle instaure un seuil de comptabilisation unique, celui de « probabilité d'achèvement ». Selon la nouvelle norme, une entreprise capitalise les coûts des logiciels à usage interne dès que les deux conditions suivantes sont réunies simultanément :
- La direction a autorisé le projet et s'est engagée à le financer. Ce n'est pas un concept nouveau — il existait déjà dans l'ancienne norme — mais il joue désormais un rôle plus important en tant que l'une des deux seules conditions déterminantes, au lieu d'être noyé dans l'analyse par étapes.
- Il est probable que le projet sera mené à terme et que le logiciel sera utilisé pour remplir la fonction prévue. C'est véritablement l'élément nouveau, et c'est là que réside le jugement.
Ce second critère exige d'évaluer si une incertitude de développement significative subsiste encore. Le FASB identifie deux sources principales de cette incertitude :
- Une technologie non éprouvée ou une fonctionnalité inédite dont la faisabilité n'a pas encore été démontrée par un codage et des tests réels — pas un document de conception, pas un cahier des charges, mais une preuve fonctionnelle.
- Des exigences de performance non définies ou encore mouvantes — la norme les définit comme « ce qu'une entité a besoin que le logiciel fasse, par exemple des fonctions ou des fonctionnalités ». Si l'équipe débat encore sérieusement de ce que le produit doit faire, cette incertitude n'a pas été levée.
En pratique, cela signifie que le moment de la capitalisation suit désormais les preuves de faisabilité, et non plus une phase calendaire. Une équipe qui explore une fonctionnalité techniquement inédite pendant deux sprints (un « spike ») avant de s'engager à la construire sérieusement comptabiliserait ces sprints d'exploration en charges — l'incertitude quant à la possibilité même de la construire n'a pas encore été levée. Une fois que le spike a fait ses preuves et que la direction engage le budget pour la construction complète, le seuil de « probabilité d'achèvement » est atteint et les coûts de développement suivants sont capitalisés, quelles que soient les cérémonies agiles en jeu.
Pourquoi le FASB estime que la capitalisation changera peu — sauf pour le SaaS
Le FASB s'attend lui-même à ce que, pour la plupart des logiciels à usage interne sur site ou sous licence, les amendements ne modifient pas radicalement les résultats de capitalisation — les entreprises capitalisaient déjà une fois le codage réel entamé, et le nouveau test aboutit à peu près au même résultat, simplement sans l'exercice d'étiquetage par étapes.
Les logiciels développés pour être livrés via un dispositif SaaS ou cloud, c'est une autre histoire. Le FASB s'attend explicitement à une diminution de la capitalisation pour ces projets. La raison : les produits SaaS sont, par nature, construits et reconstruits en continu, avec une incertitude technique et produit importante qui persiste loin dans le calendrier de développement — parfois jusqu'à l'approche du lancement d'une fonctionnalité. Selon le test de probabilité d'achèvement, cette incertitude persistante signifie que de nombreux coûts de développement SaaS ne franchiront le seuil de capitalisation que bien plus tard dans le projet que ne l'aurait laissé entendre l'ancien modèle par étapes. L'effet net : une plus grande part de la masse salariale d'ingénierie d'un produit SaaS est comptabilisée en charge de R&D de la période courante plutôt qu'en actif amorti sur plusieurs années. Il s'agit d'un changement significatif pour l'EBITDA publié et la base d'actifs de toute entreprise SaaS, avant même qu'une seule ligne de code ne change réellement.
Un exemple concret : deux équipes, deux résultats
Supposons qu'une entreprise SaaS de 40 salariés décide de construire un module de prévision alimenté par l'IA pour son produit. Voici comment les anciennes et les nouvelles règles traiteraient différemment ce même projet de construction de huit mois.
Sous l'ancien modèle par étapes, l'équipe financière essaierait de tracer une ligne : les six premières semaines de collecte des exigences et d'évaluation des fournisseurs relevaient de l'étape « préliminaire » (comptabilisée en charges), et tout ce qui suivait la réunion de lancement relevait du « développement de l'application » (capitalisé) — même si l'équipe d'ingénierie a passé les deux mois suivants à mener des sprints exploratoires pour déterminer si l'approche de prévision retenue pouvait atteindre une précision acceptable aux volumes de données de production. À la lettre de l'ancienne règle, une fois l'« étape » basculée, ces sprints exploratoires étaient souvent capitalisés eux aussi, parce qu'ils avaient techniquement eu lieu après la réunion de lancement.
Sous l'ASU 2025-06, l'équipe financière se pose plutôt la question suivante : à quel moment est-il devenu probable que cette fonctionnalité serait achevée et fonctionnerait comme prévu ? Si l'approche en matière de précision restait non éprouvée pendant les deux premiers mois — l'équipe testait trois approches de modélisation différentes et ne savait pas laquelle atteindrait le seuil requis — toute cette période d'exploration est comptabilisée en charges, quelle que soit l'« étape » à laquelle elle correspondait sur un calendrier. La capitalisation ne commence qu'une fois que l'équipe a retenu une approche validée et que la direction engage le budget pour la construire, ce qui, dans cet exemple, pourrait être le troisième mois plutôt que le deuxième. Résultat : un actif capitalisé plus faible, une charge de R&D de la période courante plus élevée et — surtout — un chiffre que le directeur financier peut réellement défendre lors d'un audit, car il est rattaché à un point de décision précis et documenté plutôt qu'à une étiquette d'étape appliquée après coup.
C'est exactement le changement que le FASB attend dans l'ensemble du secteur SaaS : moins de « on l'a appelé développement de l'application parce que c'est ce qui suivait l'appel de lancement » et davantage de « nous pouvons désigner le sprint où le risque technique a été levé ».
Dates d'entrée en vigueur et transition
L'ASU 2025-06 entre en vigueur pour toutes les entités — cotées et non cotées — pour les périodes de reporting annuel ouvertes après le 15 décembre 2027, ainsi que pour les périodes intermédiaires comprises dans ces exercices. Une adoption anticipée est permise pour toute entité, lors de n'importe quelle période intermédiaire ou annuelle, dès la publication de la norme.
Les entités peuvent appliquer les amendements selon l'une des trois approches de transition suivantes : de manière prospective, aux seuls nouveaux coûts logiciels engagés après la date d'entrée en vigueur ; de manière prospective, aux coûts engagés à compter du début de l'exercice d'adoption ; ou de manière rétrospective, à toutes les périodes présentées. Cette flexibilité compte : une entreprise en pleine réécriture d'une plateforme majeure au moment où la règle entre en vigueur n'a pas à défaire des années d'historique de coûts capitalisés, sauf si elle choisit l'option rétrospective.
Ce que les éditeurs de logiciels de petite et moyenne taille devraient faire dès maintenant
Décembre 2027 peut sembler lointain, mais le travail de préparation pratique n'est pas une tâche à traiter au dernier trimestre, en particulier pour les entreprises dont l'équipe financière est réduite et qui ne disposent pas d'une fonction dédiée de comptabilité technique.
Commencez à documenter le jugement de « probabilité d'achèvement » en temps réel, pas rétrospectivement. L'ancien modèle par étapes était mécanique — on pouvait reconstituer, des mois plus tard, à quelle étape se trouvait un projet à partir des dates de sprint. Le nouveau test pose la question à quel moment avons-nous cessé d'être techniquement incertains, un jugement bien plus difficile à reconstituer après coup. Instaurez dès maintenant une habitude légère : lorsque la direction de l'ingénierie et la finance conviennent qu'une fonctionnalité a franchi son étape d'exploration technique et est engagée pour la construction, consignez cette date. Ce journal devient votre date de début de capitalisation et votre justificatif d'audit.
Séparez le travail d'« exploration » du travail de « construction engagée » dans votre suivi du temps ou vos codes projet, si ce n'est pas déjà le cas. Qu'il s'agisse d'un indicateur sur une épopée Jira, d'un code de centre de coûts distinct ou simplement d'une étiquette dans votre outil de suivi du temps, disposer d'une trace de données claire indiquant à quel moment une fonctionnalité est passée du stade d'exploration/prototype au développement engagé rendra l'application de la nouvelle norme nettement moins pénible que de tenter de la reconstituer de mémoire lors d'un audit.
Modélisez les deux options de transition avant d'en choisir une. Si votre entreprise a capitalisé de manière agressive les coûts de développement SaaS sous l'ancien cadre par étapes, l'application rétrospective pourrait entraîner une dépréciation ponctuelle des actifs précédemment capitalisés, ces coûts étant reclassés comme s'ils avaient été comptabilisés en charges depuis le début. Une approche prospective évite ce retraitement, mais signifie que votre compte de résultat ne reflétera la nouvelle méthodologie qu'à partir des nouveaux projets lancés après l'adoption. Faites tourner les chiffres selon les deux approches avant que votre comité d'audit n'ait à le faire.
Parlez à votre auditeur tôt, surtout si vous êtes une entreprise SaaS. Compte tenu de l'attente du FASB lui-même d'une baisse de la capitalisation pour le développement SaaS, les auditeurs sont susceptibles d'examiner les jugements de probabilité d'achèvement de plus près qu'ils n'examinaient les classifications par étapes sous l'ancienne règle — précisément parce que c'est plus subjectif. Une entreprise qui aborde son audit 2028 avec un cadre documenté et contemporain pour formuler ce jugement aura une conversation bien plus facile que celle qui doit le reconstituer après coup.
Une comptabilité propre facilite la défense des jugements comptables
Chaque jugement comptable — et la « probabilité d'achèvement » en est résolument un — n'est défendable qu'à hauteur des registres qui le sous-tendent. Si votre plan comptable sépare déjà les dépenses de R&D par projet, et que vos écritures comptables sont versionnées et vérifiables plutôt que dispersées dans des feuilles de calcul déconnectées, l'application d'une norme comme l'ASU 2025-06 devient une simple question d'étiquetage de données existantes plutôt qu'une reconstitution de l'historique à partir de fils Slack. La comptabilité en texte brut de Beancount.io vous offre par défaut ce type de grand livre transparent et versionné avec git — chaque écriture traçable, chaque modification vérifiable, sans dépendance à un fournisseur. Commencez gratuitement et construisez des comptes qui tiennent la route, que la question vienne d'un auditeur, d'un acquéreur ou de la prochaine mise à jour du FASB.