Coûts de développement logiciel : comment les immobiliser ou les passer en charges en 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Les coûts de développement logiciel correspondent à l’argent dépensé en personnel, prestataires, outils et infrastructure pour concevoir, développer et tester un logiciel – et en 2026, la question la plus délicate n’est plus seulement leur montant, mais leur place dans vos états financiers. Les mêmes 500 000 $ peuvent peser sur le résultat d’exploitation d’une seule année ou devenir un actif réparti sur trois à cinq ans, selon ce qui a été financé, à quel moment et selon quelle norme comptable.

La comptabilisation des coûts de développement logiciel devient généralement urgente à un moment prévisible : le premier audit, une levée de fonds ou la première grosse facture d’une équipe externe. Les entreprises qui achètent des services de product engineering pour éditeurs de logiciels rencontrent souvent la question lorsque l’auditeur leur demande de ventiler les factures mensuelles du prestataire entre recherche, nouvelles fonctionnalités et maintenance – alors que personne n’avait prévu cette ventilation à la signature du contrat.

Deux changements font de 2026 une bonne année pour revoir votre politique comptable. Aux États-Unis, l’ASU 2025-06 du FASB réécrit les règles applicables aux logiciels à usage interne pour la première fois depuis des décennies, et le One Big Beautiful Bill Act a rétabli, avec la nouvelle Section 174A, la déduction fiscale immédiate des dépenses de recherche et d’expérimentation engagées aux États-Unis. Ce guide explique les deux, ainsi que les règles IFRS appliquées par de nombreuses entreprises européennes. Il s’agit d’une information générale et non d’un conseil fiscal ou d’audit : validez votre politique avec votre commissaire aux comptes et votre conseiller fiscal.

Que sont les coûts de développement logiciel ?

Les coûts de développement logiciel sont tous les coûts directement attribuables à la création d’un logiciel : personnel interne, honoraires de prestataires et d’agences, licences et outils, environnements cloud et travaux sur les données pendant le développement. Les coûts indirects comme le loyer des bureaux ou la direction générale font partie du coût de fonctionnement de l’entreprise, mais les normes comptables permettent rarement de les intégrer à la valeur du logiciel.

En comptabilité, il est utile de classer les coûts d’abord par nature, puis par activité. La nature indique ce qui a été payé ; l’activité, traitée dans la section suivante, détermine si le coût peut être immobilisé. Le tableau résume les composantes habituelles et leur traitement courant selon les US GAAP pour un logiciel à usage interne.

Cet article traite de la manière d’enregistrer ces coûts, pas de leur niveau souhaitable. Pour des fourchettes de prix par type de projet, taille d’équipe et région, consultez nos benchmarks des coûts de développement logiciel pour 2026.

Faut-il immobiliser ou passer en charges les coûts de développement logiciel ?

Les coûts de développement logiciel sont immobilisés lorsqu’ils créent un logiciel porteur d’avantages futurs ou lui ajoutent des fonctionnalités, et que le seuil comptable applicable est atteint ; tout le reste est passé en charges dès qu’il est engagé. En pratique, la recherche, la planification, la maintenance, la formation et les frais généraux vont au compte de résultat, tandis que la conception, le codage et les tests de nouvelles fonctionnalités peuvent devenir un actif.

La décision se prend activité par activité, pas facture par facture. Un seul sprint peut contenir du travail immobilisable sur un nouveau module, des corrections de bugs sur un ancien module (charge) et des explorations techniques (charge). Le tableau montre le résultat habituel pour un logiciel à usage interne selon les US GAAP ; les IFRS aboutissent à des résultats proches pour la plupart des lignes, mais par un autre test, expliqué plus loin.

Le test décisif pour les travaux postérieurs au lancement est simple à formuler et difficile à appliquer : le logiciel acquiert-il une capacité qu’il n’avait pas auparavant ? Un nouveau module de reporting passe le test ; un refactoring de performance ou une correction de défaut, en général non. Formalisez la règle par écrit, ajoutez des exemples et appliquez-la de la même façon chaque mois.

Comment fonctionne aujourd’hui l’ASC 350-40 pour les logiciels à usage interne ?

Selon l’ASC 350-40 actuel, le logiciel à usage interne suit un modèle en trois phases : les coûts de la phase préliminaire du projet sont passés en charges, ceux de la phase de développement de l’application sont immobilisés, et ceux de la phase post-implémentation et d’exploitation sont à nouveau passés en charges. Tant qu’une entreprise n’a pas adopté l’ASU 2025-06, c’est la règle applicable en US GAAP.

Un logiciel à usage interne est un logiciel acquis, développé ou modifié exclusivement pour les besoins internes de l’entreprise, sans projet substantiel de commercialisation externe. Cela couvre les adaptations d’ERP, les outils internes, les portails clients et, point important, la plupart des plateformes SaaS, comme expliqué plus bas.

Les trois phases

• Phase préliminaire du projet — formulation du concept, évaluation des alternatives, détermination de la technologie nécessaire et choix final. Tous les coûts sont passés en charges.
• Phase de développement de l’application — conception de la voie retenue, codage, installation du matériel et tests, y compris fonctionnement en parallèle. L’immobilisation commence lorsque la phase préliminaire est terminée, que la direction autorise le projet et s’engage à le financer, et qu’il est probable que le projet sera achevé et le logiciel utilisé comme prévu.
• Phase post-implémentation et d’exploitation — formation et maintenance. L’immobilisation s’arrête lorsque le logiciel est pour l’essentiel achevé et prêt pour l’usage prévu, en général après la fin de tous les tests significatifs.

Ce que vous pouvez immobiliser ou non

Sont immobilisables les coûts externes directs de matériels et de services consommés pour développer le logiciel, les salaires et charges liées des salariés directement affectés au projet à hauteur du temps qu’ils y consacrent, ainsi que les intérêts encourus pendant le développement selon l’ASC 835-20. Les frais généraux et administratifs, les frais indirects, la formation et la conversion des données sont passés en charges, même lorsqu’ils surviennent pendant la phase de développement de l’application.

Contrats de cloud computing : coûts de mise en œuvre d’un SaaS acheté

Lorsque votre entreprise est cliente d’un produit SaaS hébergé, les coûts de mise en œuvre suivent les mêmes règles par phases de l’ASC 350-40 en vertu de l’ASU 2018-15, même si vous ne possédez jamais le logiciel. Les coûts de paramétrage, d’intégration et de test de la solution hébergée pendant la phase de développement de l’application sont immobilisés, amortis sur la durée du contrat d’hébergement, renouvellements raisonnablement certains inclus, et présentés sur la même ligne du compte de résultat que les frais d’abonnement. L’abonnement lui-même reste une charge d’exploitation.

Pour les entreprises qui exploitent plusieurs systèmes, ces règles s’appliquent à chaque projet d’intégration. Nos équipes de développement logiciel sur mesure documentent le paramétrage et l’intégration séparément du support précisément pour cette raison.

Que change l’ASU 2025-06 ?

L’ASU 2025-06, publiée par le FASB le 18 septembre 2025, supprime les trois phases de projet de l’ASC 350-40 et les remplace par un seuil unique de comptabilisation : on immobilise dès que la direction a autorisé le projet et s’est engagée à le financer et qu’il est probable que le projet sera achevé et le logiciel utilisé pour remplir sa fonction. Des cabinets comme RSM la décrivent comme la plus importante révision de la comptabilisation des logiciels à usage interne depuis 1998, motivée en grande partie par le développement agile.

Le modèle par phases supposait un projet linéaire en cascade, où la planification s’achevait avant le début du codage. Les équipes agiles planifient, conçoivent, développent et testent à chaque sprint, si bien que les phases ne correspondaient jamais vraiment à leur travail. La nouvelle norme abandonne cette hypothèse et pose une question plus pratique sur l’incertitude.

Le seuil d’achèvement probable et l’incertitude de développement significative

Pour juger si l’achèvement est probable, l’entreprise doit examiner s’il existe une incertitude de développement significative. La norme en donne deux indicateurs :

• le logiciel comporte des fonctions ou caractéristiques nouvelles, uniques ou non éprouvées, et l’incertitude à leur sujet n’a pas encore été levée par le codage et les tests ;
• les exigences de performance significatives n’ont pas été définies ou sont encore en cours de révision importante.

Tant que l’un des deux indicateurs est présent, le seuil n’est pas atteint et les coûts sont passés en charges. Cela peut retarder l’immobilisation pour des produits expérimentaux – une nouvelle fonctionnalité de machine learning, par exemple – tout en la faisant démarrer plus tôt et de manière plus prévisible pour des projets courants comme un portail client sur une technologie éprouvée.

Ancien modèle en trois phases et ASU 2025-06

Date d’entrée en vigueur et modalités de transition

L’ASU 2025-06 s’applique aux exercices annuels ouverts après le 15 décembre 2027 et aux périodes intermédiaires de ces exercices, soit l’exercice 2028 pour les entreprises clôturant en année civile. L’application anticipée est autorisée au début d’un exercice annuel. Trois modalités de transition sont possibles :

• Prospective — les nouvelles règles s’appliquent aux coûts engagés après l’adoption ;
• Transition modifiée — application aux projets encore en cours à la date d’adoption, avec un ajustement cumulé des résultats non distribués d’ouverture ;
• Rétrospective — retraitement des périodes antérieures présentées.

Faut-il adopter la norme par anticipation en 2026 ?

L’adoption anticipée est pertinente pour les entreprises dont le développement est majoritairement agile et courant, et moins pour celles qui mènent beaucoup de travaux expérimentaux ou dont les investisseurs comparent étroitement les périodes. Pesez ces points avec votre auditeur :

• Pour : moins de correspondance manuelle entre sprints et phases, et moins de jugements à documenter chaque trimestre.
• Pour : une politique qui reflète le fonctionnement réel des équipes agiles et produit, plus facile à expliquer à de nouveaux auditeurs et investisseurs.
• Pour : les coûts de développement de site web rejoignent le même modèle, si bien qu’une seule politique couvre le produit et le site marketing.
• Contre : politiques, contrôles et paramétrage des systèmes doivent être réécrits avant le début de l’exercice d’adoption.
• Contre : les projets comportant des fonctionnalités nouvelles peuvent être immobilisés plus tard qu’aujourd’hui, ce qui réduit à court terme l’actif et le résultat d’exploitation.
• Contre : la comparabilité avec les périodes antérieures souffre en méthode prospective, et le retraitement complet demande des efforts.
• Dans tous les cas : les nouvelles informations inspirées de l’ASC 360-10 exigent des données – tableaux de variation des actifs, durées d’utilité et dépréciations – que beaucoup d’entreprises ne collectent pas aujourd’hui.

Comment comptabiliser un logiciel que vous vendez ou concédez sous licence (ASC 985-20) ?

Le logiciel destiné à être vendu, loué ou commercialisé d’une autre manière relève de l’ASC 985-20 : tous les coûts sont passés en charges de recherche et développement jusqu’à ce que la faisabilité technologique soit établie, et seuls les coûts engagés ensuite et avant la mise sur le marché générale sont immobilisés. Comme la faisabilité arrive souvent tard dans le projet, la plupart des entreprises relevant de l’ASC 985-20 immobilisent très peu.

La faisabilité technologique est établie lorsque l’entreprise a achevé une conception détaillée du programme ou, à défaut, un modèle opérationnel du produit. Les équipes qui ne rédigent pas de conception détaillée en amont – le cas habituel en développement agile – atteignent un modèle opérationnel vers la fin du développement ; la fenêtre d’immobilisation peut alors se limiter à quelques semaines de tests finaux et à la production des masters du produit.

Les coûts immobilisés sont amortis produit par produit, selon le plus élevé de deux montants : le rapport entre le chiffre d’affaires brut de la période et le chiffre d’affaires total actuel et futur attendu, ou l’amortissement linéaire sur la durée de vie économique restante estimée du produit. À chaque date de clôture, la valeur nette non amortie est comparée à la valeur nette de réalisation et dépréciée si elle est supérieure. L’ASU 2025-06 ne change rien à cela.

Où se situent les produits SaaS ?

La plupart des produits SaaS relèvent de l’ASC 350-40 en tant que logiciels à usage interne, et non de l’ASC 985-20. Si les clients n’accèdent au logiciel que via un contrat d’hébergement et n’ont aucun droit contractuel d’en prendre possession pour l’exploiter eux-mêmes, l’éditeur utilise le logiciel en interne pour fournir un service. Les fondateurs supposent souvent que « nous vendons un logiciel » signifie ASC 985-20, ce qui les conduit à passer en charges un développement qui aurait pu être immobilisé – ou à des politiques incohérentes dès qu’une version on-premise apparaît. Si vous concevez ou faites évoluer une plateforme SaaS, notre guide du développement de logiciels SaaS couvre le volet produit des mêmes décisions.

Comment les coûts de développement logiciel sont-ils traités selon les IFRS (IAS 38) ?

Selon les IFRS, l’IAS 38 Immobilisations incorporelles divise tout projet interne en une phase de recherche, toujours passée en charges, et une phase de développement, qui doit être immobilisée dès que l’entreprise peut démontrer les six critères du paragraphe 57. Contrairement aux US GAAP, les IFRS appliquent le même modèle, que le logiciel soit utilisé en interne ou vendu.

Les six critères de l’IAS 38 imposent à l’entreprise de démontrer :

1. la faisabilité technique de l’achèvement du logiciel en vue de sa mise en service ou de sa vente ;
2. son intention d’achever le logiciel et de l’utiliser ou de le vendre ;
3. sa capacité à utiliser ou à vendre le logiciel ;
4. la façon dont le logiciel générera des avantages économiques futurs probables, par exemple l’existence d’un marché ou son utilité en interne ;
5. la disponibilité de ressources techniques, financières et autres appropriées pour achever le développement et utiliser ou vendre le logiciel ;
6. sa capacité à évaluer de façon fiable les dépenses attribuables au logiciel au cours de son développement.

Lorsque les six critères sont remplis, l’immobilisation est obligatoire et non optionnelle. Si l’entreprise ne peut pas distinguer la phase de recherche de la phase de développement, l’IAS 38 traite l’ensemble du projet comme de la recherche et le passe en charges. Le logiciel immobilisé est amorti sur sa durée d’utilité et soumis à un test de dépréciation selon l’IAS 36 ; un logiciel pas encore prêt à être utilisé doit être testé au moins une fois par an. Le modèle de réévaluation n’est autorisé qu’en présence d’un marché actif, ce qui n’est pratiquement jamais le cas pour un logiciel sur mesure.

Pour un SaaS acheté plutôt que développé, les IFRS s’écartent de l’ASU 2018-15. Selon les décisions de l’IFRS Interpretations Committee de 2019 et 2021, les coûts de paramétrage et de personnalisation d’un service cloud que le client ne contrôle pas sont en général passés en charges, sauf s’ils créent un actif distinct contrôlé par le client, comme du code spécifique.

US GAAP et IFRS en un coup d’œil

Les groupes qui publient selon les deux référentiels – une société mère européenne avec une filiale américaine, par exemple – devraient suivre les coûts au niveau de détail exigé par le référentiel le plus strict et dériver les deux résultats des mêmes données.

Comment amortir un logiciel immobilisé ?

L’amortissement d’un logiciel à usage interne commence lorsqu’il est prêt pour l’usage prévu et suit généralement la méthode linéaire sur la durée d’utilité estimée. Beaucoup d’entreprises retiennent trois à cinq ans, mais il s’agit d’une pratique courante et non d’une règle : la durée doit refléter le temps pendant lequel le logiciel apportera réellement de la valeur avant d’être remplacé ou reconstruit.

• Point de départ — lorsque le logiciel, ou un module utilisable séparément, est pour l’essentiel achevé et prêt à l’emploi, même s’il n’a pas encore été déployé auprès de tous les utilisateurs.
• Méthode — linéaire, sauf si un autre rythme reflète mieux la consommation des avantages ; le logiciel relevant de l’ASC 985-20 utilise le plus élevé du montant fondé sur le chiffre d’affaires et du montant linéaire.
• Durée d’utilité — tenez compte de l’historique de vos versions, du rythme d’évolution de la technologie sous-jacente et de tout projet de remplacement de la plateforme.
• Revues — réexaminez les durées d’utilité au moins une fois par an et ajustez-les de manière prospective si les attentes changent.
• Indices de dépréciation — abandon du projet, changement majeur dans l’usage du logiciel, dépassements de coûts très supérieurs au budget ou décision de le remplacer plus tôt que prévu.
• Projets abandonnés — lorsque l’achèvement n’est plus probable, cessez d’immobiliser et dépréciez l’actif au lieu de le conserver au bilan.

Comment la fiscalité traite-t-elle les coûts de développement logiciel en 2026 (Section 174A) ?

Pour l’impôt fédéral américain, le One Big Beautiful Bill Act de juillet 2025 a créé la Section 174A, qui permet de déduire l’année même les dépenses de recherche et d’expérimentation réalisées aux États-Unis – y compris, explicitement, le développement logiciel – pour les exercices fiscaux ouverts après le 31 décembre 2024. La recherche réalisée hors des États-Unis doit toujours être immobilisée et amortie sur 15 ans selon la Section 174.

La règle étrangère concerne toute entreprise qui développe avec une équipe offshore ou nearshore. Le développement réalisé aux États-Unis est désormais déductible immédiatement, alors que le même travail effectué à l’étranger est étalé sur 15 ans. Cet écart doit figurer dans toute comparaison du coût total entre développement interne, onshore et offshore.

• Les petites entreprises dont le chiffre d’affaires brut annuel moyen ne dépasse pas 31 millions de dollars peuvent appliquer la déduction immédiate de façon rétroactive aux exercices ouverts après le 31 décembre 2021 en rectifiant leurs déclarations 2022–2024.
• Les autres contribuables peuvent déduire le solde non amorti des dépenses domestiques au titre de la Section 174 pour 2022–2024 en totalité en 2025 ou à parts égales sur 2025 et 2026.
• Procédure — l’IRS a précisé les options et changements de méthode dans la Rev. Proc. 2025-28.
• Comptabilité et fiscalité — elles ne vont plus de pair : un actif immobilisé dans les comptes avec une déduction fiscale immédiate crée un impôt différé passif qu’il faut suivre.

La Section 174A régit la déduction ; le crédit d’impôt recherche de la Section 41 est un avantage distinct, avec son propre test en quatre volets. Notre guide du crédit d’impôt R&D pour le développement logiciel détaille l’éligibilité et la documentation.

Comment suivre les coûts immobilisables dans une équipe agile ?

Pour suivre les coûts immobilisables dans une équipe agile, étiquetez le travail au niveau des epics et des tickets comme nouvelle fonctionnalité, maintenance ou recherche, enregistrez le temps par personne et par epic, et exigez des prestataires externes qu’ils facturent selon la même structure. L’immobilisation devient alors un rapport mensuel plutôt qu’une reconstitution en fin de trimestre.

1. Rédigez une politique d’immobilisation. Définissez les activités immobilisées, le seuil appliqué (par phases ou ASU 2025-06), une taille minimale de projet, les durées d’utilité par défaut et qui approuve les exceptions.
2. Étiquetez les epics et les tickets. Chaque epic reçoit une catégorie – nouvelle fonctionnalité, évolution, maintenance, recherche ou infrastructure – dont héritent les tickets. Les product owners posent l’étiquette, la finance la contrôle.
3. Enregistrez le temps par personne et par epic. Une répartition hebdomadaire légère par epic suffit ; des feuilles de temps à la minute ne sont pas nécessaires, mais les estimations doivent être raisonnables et cohérentes.
4. Fixez des règles pour les prestataires. Demandez aux prestataires de développement de facturer par epic ou par fonctionnalité avec les heures par rôle, afin de classer les coûts externes comme les salaires.
5. Clôturez chaque mois. Arrêtez les comptes en fin de mois, calculez les coûts de personnel et de prestataires immobilisables, passez les écritures et mettez en service les modules terminés pour que l’amortissement démarre à temps.
6. Conservez les justificatifs. Archivez les autorisations de financement, les roadmaps, les notes de version et le raisonnement derrière les jugements d’achèvement probable ; l’auditeur les demandera.
7. Faites une revue trimestrielle. Contrôlez la qualité de l’étiquetage, réexaminez les durées d’utilité et repérez les projets abandonnés ou à l’arrêt à déprécier.

Quelles sont les erreurs les plus fréquentes en comptabilité du développement logiciel ?

Les erreurs les plus fréquentes en comptabilité du développement logiciel consistent à immobiliser un travail qui relève encore de la recherche, à immobiliser la maintenance, à choisir la mauvaise norme pour un SaaS et à ne pas documenter les jugements. Chacune apparaît généralement lors du premier audit approfondi, au moment où la corriger coûte le plus cher.

• Immobiliser la recherche et les prototypes — les preuves de concept et expérimentations antérieures à l’autorisation de financement sont des charges.
• Immobiliser la maintenance — corrections de bugs, refactoring et petits ajustements d’interface n’ajoutent pas de fonctionnalité, même s’ils occupent un sprint entier.
• Traiter un SaaS selon l’ASC 985-20 — les produits hébergés sans droit du client d’en prendre possession sont des logiciels à usage interne.
• Intégrer les frais généraux à l’actif — loyer, RH et direction générale sont des charges pour un logiciel à usage interne.
• Aucune preuve de l’achèvement probable — sans autorisations de financement ni roadmaps, l’auditeur peut repousser le début de l’immobilisation.
• Oublier la dépréciation — un module abandonné toujours inscrit au bilan surévalue l’actif.
• Traiter fiscalement le développement étranger comme domestique — le travail réalisé hors des États-Unis est amorti sur 15 ans et non déduit au titre de la Section 174A.

Exemple chiffré : un projet de 600 000 $, deux résultats comptables

Un même projet de 600 000 $ peut produire un actif de 480 000 $ ou de 40 000 $ selon le modèle US GAAP applicable. L’exemple ci-dessous est hypothétique, utilise des chiffres ronds et suppose que le projet remplit les conditions de financement et d’achèvement probable après la phase de cadrage ; il illustre la mécanique et ne concerne aucune entreprise réelle.

Le résultat A traite le produit comme un logiciel à usage interne ou une plateforme SaaS selon l’ASC 350-40. Le résultat B le traite comme un logiciel sous licence installé par les clients selon l’ASC 985-20, la faisabilité technologique étant établie par un modèle opérationnel tard dans la phase de test.

Dans le résultat A, l’amortissement linéaire de 480 000 $ sur quatre ans ajoute 120 000 $ d’amortissement par an. Si le logiciel est mis en production en début d’année, la charge de la première année au compte de résultat est de 240 000 $ (120 000 $ de charges plus 120 000 $ d’amortissement) au lieu de 600 000 $. Dans le résultat B, la quasi-totalité du projet réduit le résultat d’exploitation de l’année où il est dépensé.

L’ASU 2025-06 ajoute une troisième possibilité au résultat A. Si 150 000 $ du codage concernent une fonctionnalité nouvelle dont l’incertitude n’a été levée que tard dans le développement, ce montant est passé en charges selon les nouvelles règles. L’actif immobilisé tombe à 330 000 $ et l’amortissement annuel sur quatre ans à 82 500 $. Le calcul est simple ; c’est le jugement sur l’incertitude qui doit être documenté.

FAQ

Publié le 26 octobre 2026. Sources : texte intégral de l’ASU 2025-06 du FASB via PwC Viewpoint ; Deloitte DART Heads Up (2025) ; analyses de l’AICPA & CIMA, de RSM US et de Grant Thornton sur l’ASU 2025-06 ; IFRS Foundation, IAS 38 Immobilisations incorporelles ; Baker Newman Noyes et Kaufman Rossin sur la Section 174A et la Rev. Proc. 2025-28 ; The Tax Adviser (AICPA) sur la définition des coûts de développement logiciel. Cet article est une information générale et ne constitue pas un conseil comptable, d’audit ou fiscal.