Décote de productivité IA et coût de reproduction : logiciels, SaaS, CRM

Introduction : la méthode du coût de reproduction face aux outils d'intelligence artificielle

Un développeur équipé de Claude ou de GitHub Copilot va-t-il réellement coûter moins cher à faire travailler qu'un développeur sans assistance ? La question paraît anodine, mais elle fragilise aujourd'hui l'une des trois approches classiques de l'évaluation d'actifs incorporels : le coût de reproduction, qui consiste à estimer la valeur d'un logiciel, d'un SaaS ou d'un CRM par le coût qu'il faudrait engager aujourd'hui pour le recréer à l'identique. Selon la norme IVS 210 de l'International Valuation Standards Council, cette approche par les coûts demeure l'une des trois familles méthodologiques reconnues en évaluation d'actifs incorporels, aux côtés de l'approche par le marché et de l'approche par le revenu.

« Un ajustement d'obsolescence doit être appliqué au coût de reproduction ou de remplacement lorsque l'actif présente une obsolescence fonctionnelle, technologique ou économique. », International Valuation Standards Council, IVS 210.

Or en 2026, trois facteurs convergent pour rendre cet ajustement d'obsolescence technologique plus difficile à documenter qu'auparavant. Premièrement, les études de productivité publiées depuis 2023 donnent des résultats contradictoires selon le contexte observé, d'un gain de vitesse de plus de 50 % sur une tâche de laboratoire à un ralentissement mesuré chez des développeurs expérimentés sur du code mature. Deuxièmement, la littérature technique documente un risque de dette technique différée qui peut partiellement annuler le gain de vitesse apparent. Troisièmement, aucune doctrine d'évaluation publiée, que ce soit l'IVSC, l'AICPA ou l'American Society of Appraisers, ne propose à ce jour de grille chiffrée pour ajuster le coût de reproduction logiciel à l'ère de l'intelligence artificielle générative, ce qui expose les évaluateurs à des décotes arbitraires, non défendables en cas de contrôle ou de contentieux.

Cet article propose une grille de référence construite exclusivement à partir d'études empiriques vérifiables, qui distingue plusieurs contextes de développement plutôt que de retenir un chiffre unique. Il présente la définition et l'origine de la méthode du coût de reproduction, les raisons et les étapes de son ajustement, les situations où y recourir, deux cas pratiques chiffrés, une foire aux questions et une synthèse opérationnelle.

Sécurisez l'évaluation de vos actifs logiciels

Avant de retenir une décote sur le coût de reproduction d'un logiciel, d'un SaaS ou d'un CRM, un échange de 30 minutes avec Hectelion permet de qualifier le contexte réel de votre codebase, d'identifier les études pertinentes pour votre cas et de construire une estimation défendable devant un investisseur, un commissaire aux comptes ou une administration fiscale.

Acontos : estimez gratuitement la valeur de votre entreprise en ligne

Avant d'entrer dans le détail, sachez qu'Hectelion a développé Acontos, un outil en ligne d'audit, de due diligence et d'évaluation d'entreprise, propulsé par l'intelligence artificielle Claude Sonnet 5 d'Anthropic et calibré par la méthodologie d'Hectelion. À partir de vos comptes, il produit en quelques minutes une première estimation de la valeur de vos titres, gratuitement et sans conserver aucun document. Lancez le simulateur de valorisation pour obtenir un ordre de grandeur, puis poursuivez votre lecture pour en comprendre les ressorts.

Définition : qu'est-ce que la décote de productivité IA sur le coût de reproduction ?

La décote de productivité IA est l'ajustement appliqué au coût brut de reconstitution d'un actif logiciel pour refléter l'effet, positif ou négatif, des outils d'intelligence artificielle générative sur le temps et le coût de développement. Elle s'inscrit dans la logique classique de l'obsolescence technologique, qui impose de corriger le coût de reproduction ou de remplacement dès lors qu'une technologie plus performante ou moins coûteuse rend l'actif évalué prématurément dépassé.

Deux précisions s'imposent d'emblée. D'une part, la décote ne porte pas sur la valeur finale du logiciel, mais uniquement sur le coût de sa reconstitution hypothétique, ce qui en fait un paramètre de l'approche par les coûts et non de l'approche par le revenu. D'autre part, contrairement à une intuition répandue, l'ajustement n'est pas toujours une décote : dans certains contextes de code mature maintenu par des équipes très spécialisées, les études disponibles observent un effet inverse, qui justifierait plutôt une majoration du coût de reproduction. La section suivante retrace l'origine de cette question et explique pourquoi elle ne peut être tranchée par un chiffre unique.

Origine : du modèle COCOMO à la productivité augmentée par l'IA générative

L'idée que le coût de reproduction d'un logiciel ne se résume pas à une addition linéaire d'heures de travail est ancienne. Dès 1995, le modèle paramétrique COCOMO II, développé par Barry Boehm à l'University of Southern California, intègre des facteurs multiplicatifs d'ajustement pour la réutilisation et la réingénierie de code existant, combinant la compréhension du code, la familiarité du programmeur et la structure de la base existante. Ce précédent méthodologique établit, bien avant l'intelligence artificielle générative, qu'un ajustement du coût de développement doit reposer sur plusieurs facteurs de contexte et non sur un pourcentage unique.

La question de la productivité augmentée par l'IA générative émerge pour sa part à partir de 2022, avec la diffusion commerciale de GitHub Copilot puis des grands modèles de langage conversationnels. Une première étude randomisée, menée par des chercheurs de Microsoft, GitHub et du MIT en 2023 sur un échantillon de développeurs freelances, mesure un gain de vitesse de 55,8 % sur une tâche de programmation standardisée. Ce résultat, largement médiatisé, a alimenté l'idée d'une décote uniforme applicable à tout développement logiciel. Les études publiées depuis 2024 par Microsoft, Google et l'organisme de recherche METR nuancent sensiblement ce premier résultat, ce qui constitue le cœur de la problématique traitée dans cet article.

Cas particulier : un logiciel généré majoritairement par l'IA reste-t-il protégé par le droit d'auteur ?

La norme IVS 210 exige qu'un actif incorporel soit identifiable et contrôlé par l'entreprise pour pouvoir être évalué séparément, ce qui suppose une titularité juridique stable. Or en droit français, l'article L112-2 du Code de la propriété intellectuelle protège le logiciel au titre du droit d'auteur, une protection qui suppose traditionnellement une œuvre originale résultant d'un apport intellectuel humain. En droit suisse, l'article 2 alinéa 3 de la Loi fédérale sur le droit d'auteur retient le même principe pour les programmes d'ordinateur. Lorsqu'une part substantielle du code est générée par un outil d'intelligence artificielle sans supervision ni retouche humaine significative, la qualification d'œuvre originale devient incertaine dans les deux ordres juridiques, ce qui fragilise la chaîne de titularité et, par ricochet, la pertinence même d'une évaluation par le coût de reproduction.

Cette incertitude n'est pas purement théorique pour l'évaluateur. Un logiciel dont la titularité des droits est contestable voit sa valeur réduite indépendamment de tout ajustement de productivité, et ce risque doit être documenté séparément de la décote de productivité IA traitée dans cet article. En pratique, la jurisprudence et la doctrine sur ce point précis restent naissantes au moment de la rédaction de cet article, ce qui impose à l'évaluateur une vigilance particulière sur la documentation du processus de développement, notamment la trace des contributions humaines de conception, de relecture et de validation du code généré.

Pourquoi ajuster le coût de reproduction logiciel à l'ère de l'intelligence artificielle

• Ignorer l'effet positif en contexte favorable : ignorer l'effet de l'IA générative sur le coût de développement expose à une surestimation systématique du coût de reproduction dans les contextes où cet effet est réellement positif, notamment pour du code standard développé par des équipes juniors ou intermédiaires.
• Ignorer l'effet négatif en contexte legacy : à l'inverse, appliquer mécaniquement une décote uniforme expose à une sous-estimation dans les contextes où l'IA ralentit la production, notamment sur du code legacy complexe maintenu par des équipes très expérimentées, un résultat contre-intuitif mais documenté par une étude randomisée de l'organisme METR en 2025.
• Dette technique différée : la génération de code assisté par IA s'accompagne d'un risque de dette technique différée, documenté par une analyse de 211 millions de lignes de code publiée par GitClear en 2025, qui doit être pris en compte pour ne pas confondre un gain de vitesse brut avec un gain de productivité net.
• Exigence croissante de traçabilité : les administrations fiscales et les commissaires aux comptes examinent avec une attention croissante les hypothèses retenues dans les rapports d'évaluation d'actifs incorporels, ce qui impose de documenter toute décote par des sources vérifiables plutôt que par une estimation intuitive.
• Opportunité de structurer une doctrine : l'absence de doctrine établie sur ce sujet précis constitue, pour un cabinet d'évaluation, une opportunité de structurer une méthodologie rigoureuse avant que des pratiques de marché hétérogènes et peu documentées ne s'installent durablement.

Cette question n'est pas seulement académique. Hectelion a ainsi échangé, en octobre 2026, avec la direction d'une société éditrice de logiciels engagée dans une migration de ses produits du desktop vers le cloud, dont le management estime que l'intelligence artificielle permet de réduire d'environ 50 % le coût de développement d'un produit numérique. Ce chiffre, de l'ordre de grandeur de la borne haute de l'intervalle de confiance mesuré par Peng et ses coauteurs mais nettement supérieur au gain observé en conditions réelles d'entreprise par Cui et ses coauteurs, illustre précisément le risque évoqué plus haut : une estimation de terrain, aussi sincère soit-elle, ne constitue pas une décote documentée tant qu'elle n'est pas rattachée à un contexte précis de codebase et d'équipe et à une source empirique vérifiable.

Comment se construit la grille de décotes de productivité IA

La construction d'une décote défendable suit une séquence en six étapes, qui s'écarte délibérément de la pratique consistant à appliquer un pourcentage unique.

• Établir le coût de reproduction brut : selon la méthode classique de l'approche par les coûts, à partir d'un devis technique indépendant exprimé en heures de développement, de tests et de documentation, valorisées à un taux horaire chargé représentatif du marché local.
• Qualifier le contexte du logiciel évalué : selon deux axes croisés, le type de codebase (développement récent et standard ou système legacy complexe) et le niveau d'expérience de l'équipe de développement sur ce code précis, cette qualification pouvant être utilement complétée par le niveau de maturité technologique de l'actif, mesuré par exemple à l'aide d'une échelle de type Technology Readiness Level.
• Sélectionner l'intervalle dans la grille de référence : l'intervalle de décote ou de majoration brute correspondant à ce contexte, ancré sur l'étude empirique la plus représentative de la situation réelle plutôt que sur l'étude la plus favorable.
• Appliquer la retenue de dette technique : une retenue transversale de 10 à 15 points de pourcentage, destinée à capturer le risque de maintenance différée documenté par la littérature indépendamment du contexte retenu.
• Documenter le raisonnement : chaque hypothèse retenue, la source empirique mobilisée et le raisonnement de sélection du point précis dans l'intervalle, afin que le calcul résiste à un examen contradictoire.
• Soumettre à une revue indépendante : la décote retenue à un second évaluateur, en particulier lorsque le montant en jeu est significatif au regard de la valeur totale de l'actif.

Grille de référence construite à partir des études citées en sources. Les intervalles ne constituent pas une norme automatique mais un point d'ancrage à affiner selon le logiciel évalué.

Arbitrer entre l'approche par les coûts et l'approche par le revenu quand l'IA comprime le coût de reproduction

Certains commentateurs soutiennent que la baisse générale du coût de développement logiciel, facilitée par les outils d'intelligence artificielle générative, rendrait l'approche par les coûts de moins en moins pertinente pour les logiciels générant des revenus significatifs. Cet argument mérite d'être nuancé plutôt que rejeté. Lorsque le coût de reproduction brut tend à diminuer fortement, l'écart avec la valeur réelle du logiciel, mesurée par ses flux de trésorerie futurs, s'élargit mécaniquement, ce qui doit conduire l'évaluateur à privilégier l'approche par le revenu dès que des flux identifiables existent, et à ne retenir l'approche par les coûts qu'à titre de méthode de contrôle ou pour un logiciel récent dépourvu d'historique d'exploitation.

Hectelion traite ailleurs la question complémentaire de l'obsolescence technologique appliquée à l'approche par le revenu, notamment à travers le taux d'attrition retenu pour modéliser la durée de vie économique d'un logiciel ou d'un SaaS face à l'accélération du rythme d'innovation porté par l'intelligence artificielle. Les deux grilles, celle du coût de reproduction présentée dans cet article et celle du taux d'attrition appliquée au revenu, doivent être mobilisées de manière cohérente lorsqu'une évaluation combine les deux approches à titre de recoupement.

Quand recourir à cette grille de décotes

Le recours à cette grille de décotes se justifie chaque fois qu'un rapport d'évaluation d'actifs incorporels mobilise l'approche par les coûts pour un logiciel, un SaaS ou un CRM dont le développement ou la maintenance s'appuie, même partiellement, sur des outils d'intelligence artificielle générative. C'est notamment le cas lors d'une évaluation à l'occasion d'une levée de fonds, d'un apport en nature d'un actif logiciel au capital d'une société, d'un test de dépréciation sous IAS 36 ou Swiss GAAP FER 27 lorsque le coût de reproduction sert de méthode de contrôle, ou encore d'un litige entre associés portant sur la valeur d'un actif technologique développé en interne.

La grille trouve également son utilité lors d'une négociation contractuelle entre un éditeur de logiciel et son cocontractant, lorsque le coût de reproduction sert de référence minimale pour fixer un prix de licence ou une redevance, ainsi que lors d'une due diligence technologique préalable à une acquisition, où l'acquéreur souhaite vérifier que le prix proposé pour un actif logiciel ne reflète pas un coût de développement historique devenu obsolète au regard des outils aujourd'hui disponibles.

À qui faire appel pour appliquer cette grille de décotes

L'application rigoureuse de cette grille suppose de réunir trois compétences rarement présentes chez un seul interlocuteur. La première est la maîtrise des normes d'évaluation d'actifs incorporels, notamment la norme IVS 210 de l'IVSC, qui encadre le choix et la mise en œuvre des approches par les coûts, le marché et le revenu. La deuxième est une compréhension technique suffisante du développement logiciel pour qualifier correctement le contexte d'une codebase, sa dette technique et le niveau réel de familiarité de l'équipe avec le code concerné. La troisième est la capacité à suivre une littérature empirique en évolution rapide, publiée en anglais par des organismes de recherche et des laboratoires technologiques, et à distinguer un résultat robuste d'un résultat préliminaire ou contesté.

Hectelion réunit ces trois compétences au sein de ses missions d'évaluation d'actifs incorporels, avec une double expertise franco-suisse et une indépendance économique vis-à-vis des intermédiaires financiers traditionnels. Le cabinet n'est pas agréé FINMA et n'intervient donc pas sur les opérations portant sur des sociétés cotées, un périmètre sans incidence sur les missions d'évaluation de logiciels et de SaaS non cotés, qui représentent l'essentiel des situations concernées par cette grille.

Avantages : rigueur méthodologique, défendabilité, actualité

• Une grille fondée sur des études randomisées publiées, plutôt que sur une estimation intuitive, qui résiste mieux à un examen contradictoire devant un tribunal, un commissaire aux comptes ou une administration fiscale.
• Une distinction explicite entre les contextes de développement, qui évite de pénaliser à tort un logiciel legacy complexe ou, à l'inverse, de sous-estimer la décote pertinente pour un développement standard récent.
• Une actualisation possible à mesure que la littérature sur la productivité des outils d'intelligence artificielle générative continue de s'enrichir, sans remettre en cause la structure générale de la méthode.
• Une cohérence avec la pratique établie en ingénierie logicielle depuis le modèle COCOMO, qui ancre la démarche dans un précédent reconnu plutôt que dans une innovation méthodologique isolée.

Limites : incertitude scientifique, hétérogénéité, absence de consensus

• Les études disponibles portent sur des échantillons réduits, de 16 à 95 développeurs selon les cas, et une réplication menée par METR en 2026 montre que l'intervalle de confiance de certains résultats contient zéro, ce qui impose une grande prudence sur la précision du chiffre retenu.
• Aucune norme d'évaluation publiée, qu'il s'agisse de l'IVSC, de l'AICPA ou de l'American Society of Appraisers, ne propose à ce jour de grille chiffrée officielle sur ce sujet précis, ce qui signifie que toute décote retenue relève du jugement professionnel de l'évaluateur et non de l'application mécanique d'un standard.
• Les résultats disponibles concernent majoritairement des environnements anglo-saxons et des langages de programmation grand public, ce qui limite leur transposition directe à des logiciels développés dans des technologies ou des contextes linguistiques différents.
• La littérature évolue rapidement, ce qui impose de revoir périodiquement la grille retenue plutôt que de la considérer comme définitivement figée.

Les 5 erreurs à éviter dans la décote de productivité IA

Erreur 1 : retenir un chiffre unique applicable à tout contexte

Appliquer une décote forfaitaire de 20 % ou 30 % à tout logiciel, quel que soit son contexte, ignore la dispersion considérable des résultats empiriques selon le type de codebase et le niveau d'expérience de l'équipe. Cette simplification expose à une estimation non défendable dès qu'un contradicteur cite une étude contraire.

Erreur 2 : confondre gain de vitesse brut et gain de productivité net

Un gain de vitesse mesuré sur la production de lignes de code ne se traduit pas automatiquement en gain de productivité net, dès lors qu'une partie de ce code devra être retravaillée ultérieurement. L'analyse de 211 millions de lignes publiée par GitClear en 2025 documente une hausse marquée du code dupliqué et une baisse du volume de code refactorisé, ce qui doit réduire la décote brute appliquée.

Erreur 3 : ignorer l'effet inverse sur le code legacy complexe

Présumer que l'intelligence artificielle accélère systématiquement le développement conduit à ignorer le résultat le plus contre-intuitif de la littérature récente : une étude randomisée de METR observe en 2025 un ralentissement de 19 % chez des développeurs expérimentés intervenant sur des dépôts matures qu'ils connaissent bien, notamment parce que l'assistant ne dispose pas de la connaissance tacite du code accumulée par l'équipe.

Erreur 4 : extrapoler un résultat de laboratoire à un contexte de production réelle

Le résultat le plus spectaculaire, un gain de vitesse de 55,8 % mesuré par Peng et ses coauteurs en 2023, provient d'une tâche de programmation standardisée réalisée par des développeurs freelances, et non d'un contexte de production réelle en entreprise. Une étude ultérieure menée en conditions réelles chez Microsoft, Accenture et un groupe du classement Fortune 100 mesure un gain nettement inférieur, de 26,08 %, ce qui doit orienter le choix de l'ancrage retenu dans la grille.

Erreur 5 : ne pas documenter la décote retenue

Une décote non sourcée, même raisonnable dans son principe, ne résiste pas à un contrôle fiscal ou à un contentieux entre associés. Chaque décote retenue doit être accompagnée de la source empirique mobilisée, du raisonnement de sélection dans l'intervalle et, le cas échéant, de l'avis d'un second évaluateur.

Cas 1 : CRM SaaS développé par une équipe mixte junior et confirmée

Une société édite un CRM vertical destiné aux PME du secteur du transport, développé en 18 mois par une équipe de 4 développeurs, deux confirmés et deux juniors, dans le cadre d'un apport en nature envisagé au capital d'une société holding.

• Volume estimé : 10 800 heures de développement, de tests et de documentation, soit 150 heures mensuelles par développeur sur 18 mois.
• Taux horaire chargé retenu : 115 CHF, représentatif du marché suisse romand pour ce profil d'équipe.
• Coût de reproduction brut : 10 800 heures multipliées par 115 CHF, soit CHF 1 242 000.
• Contexte retenu dans la grille : développement récent et standard, équipe mixte junior et confirmée, ancré sur l'étude menée en conditions réelles d'entreprise plutôt que sur la tâche de laboratoire.

Le gain de vitesse brut retenu est de 26 %, ancré sur l'étude de Cui et ses coauteurs menée en conditions réelles chez Microsoft, Accenture et un groupe du classement Fortune 100, jugée plus représentative de ce contexte de production qu'une tâche de laboratoire. Une retenue de dette technique de 12 points, au milieu de l'intervalle de 10 à 15 points documenté par GitClear, est déduite pour tenir compte du risque de code dupliqué non refactorisé. La décote nette retenue s'établit donc à 26 % moins 12 points, soit 14 %. Le coût de reproduction ajusté ressort à CHF 1 242 000 multiplié par 0,86, soit CHF 1 068 120, contre un coût brut non ajusté de CHF 1 242 000 qui aurait surestimé la valeur de l'actif de CHF 173 880.

Cas 2 : ERP industriel legacy maintenu par une équipe senior très expérimentée

Un groupe industriel détient un ERP interne de gestion de production, comptant 420 000 lignes de code et développé il y a 11 ans, maintenu depuis l'origine par une équipe de 3 développeurs seniors dont l'ancienneté moyenne sur ce code atteint 9 ans. Le contexte intervient dans le cadre d'un test de dépréciation sous IAS 36.

• Volume estimé pour une reconstitution hypothétique : 13 500 heures, soit 150 heures mensuelles par développeur sur 30 mois, un horizon plus long que le cas 1 compte tenu de la complexité du système.
• Taux horaire chargé retenu : 130 CHF, représentatif d'un profil senior spécialisé en systèmes industriels.
• Coût de reproduction brut : 13 500 heures multipliées par 130 CHF, soit CHF 1 755 000.
• Contexte retenu dans la grille : codebase legacy complexe, équipe senior très familière du code, le contexte exact de l'étude randomisée publiée par METR en 2025.

Cette étude observe, dans ce contexte précis, un ralentissement de 19 % de la production des développeurs assistés par IA, attribué notamment à un taux d'acceptation des suggestions inférieur à 44 % et à l'absence de connaissance tacite du code chez l'assistant. Aucune décote n'est donc appliquée ; une majoration de 15 %, au milieu de l'intervalle de 10 à 20 % documenté pour ce contexte, est au contraire retenue pour refléter le temps de relecture et de correction supplémentaire généré par un usage mal calibré des outils d'IA sur ce type de système. Le coût de reproduction ajusté ressort à CHF 1 755 000 multiplié par 1,15, soit CHF 2 018 250. Ce résultat illustre pourquoi une décote uniforme aurait conduit, dans ce cas précis, à sous-estimer la valeur de l'actif de plus de CHF 450 000 par rapport à l'ajustement documenté.

Mot du dirigeant

« Depuis deux ans, je vois circuler l'idée que l'intelligence artificielle rendrait mécaniquement le développement logiciel moins coûteux, et donc tout actif logiciel moins cher à reconstituer. Cette idée n'est pas fausse, mais elle est incomplète, et c'est précisément son incomplétude qui pose problème dans un rapport d'évaluation destiné à résister à un examen contradictoire. »

« Les études publiées depuis 2023 racontent une histoire plus nuancée qu'un simple gain de productivité généralisé. Un gain de vitesse spectaculaire mesuré en laboratoire devient beaucoup plus modeste en conditions réelles d'entreprise, et devient même un ralentissement documenté chez des développeurs expérimentés intervenant sur du code mature qu'ils connaissent intimement. Ignorer cette dispersion, au profit d'un chiffre unique commode, revient à sacrifier la rigueur de l'évaluation à la simplicité de la présentation. »

« J'ai construit cette grille pour donner à nos clients, et plus largement à la profession, un point de départ documenté plutôt qu'une estimation intuitive. Elle n'a pas vocation à remplacer le jugement professionnel de l'évaluateur, mais à l'ancrer sur des sources vérifiables, actualisables à mesure que la recherche progresse. Chez Hectelion, nous considérons qu'une méthode d'évaluation ne vaut que par la solidité des sources qui la sous-tendent, en particulier sur un sujet aussi récent et évolutif que l'impact de l'intelligence artificielle générative sur le coût du développement logiciel. »

FAQ : les 10 questions essentielles sur la décote de productivité IA

Introduction : ce qu'il faut retenir avant les questions

Les questions ci-dessous reviennent systématiquement lors des missions d'évaluation de logiciels, de SaaS et de CRM intégrant un ajustement lié à la productivité des outils d'intelligence artificielle, et clarifient les points les plus souvent mal compris sur ce sujet récent.

Q1 : existe-t-il une décote IA standard reconnue par les normes IVS ou AICPA pour le coût de reproduction logiciel ?

Non. Ni l'IVSC, ni l'AICPA, ni l'American Society of Appraisers ne publient à ce jour de grille chiffrée officielle sur ce sujet précis. La norme IVS 210 impose seulement le principe d'un ajustement d'obsolescence technologique, sans en préciser le niveau pour ce cas d'usage spécifique.

Q2 : pourquoi les études sur la productivité des développeurs avec l'IA donnent-elles des résultats si différents ?

Parce qu'elles mesurent des contextes différents. Une tâche de programmation standardisée réalisée par des développeurs freelances sur un projet neuf ne reproduit pas les conditions d'un développeur expérimenté intervenant sur un système mature qu'il connaît depuis des années, ce qui explique l'écart entre un gain de 55,8 % en laboratoire et un ralentissement de 19 % en conditions réelles complexes.

Q3 : un logiciel legacy peut-il voir son coût de reproduction augmenter à cause de l'intelligence artificielle ?

Oui, dans certains contextes documentés. L'étude randomisée de METR publiée en 2025 mesure un ralentissement de la production chez des développeurs expérimentés intervenant sur du code mature et complexe, ce qui justifie, dans ce cas précis, une majoration plutôt qu'une décote du coût de reproduction.

Q4 : comment la dette technique liée au code généré par IA affecte-t-elle la décote ?

Une analyse de 211 millions de lignes de code publiée par GitClear en 2025 documente une hausse marquée du volume de code dupliqué et une baisse du volume de code refactorisé entre 2021 et 2024. Ce risque de maintenance différée justifie une retenue de 10 à 15 points appliquée sur toute décote calculée à partir du seul gain de vitesse observé.

Q5 : faut-il appliquer la même décote à un ERP interne et à un SaaS commercial ?

Non. La grille distingue le contexte selon le type de codebase et le niveau d'expérience de l'équipe plutôt que selon la destination commerciale ou interne du logiciel. Un ERP interne récent développé par une équipe junior suit la même logique d'ajustement qu'un SaaS commercial dans les mêmes conditions.

Q6 : quelle est la différence entre coût de reproduction et coût de remplacement ?

Le coût de reproduction vise une réplique à l'identique de l'actif, même architecture et mêmes fonctionnalités, tandis que le coût de remplacement vise une utilité équivalente obtenue par les moyens technologiques actuels, potentiellement différents. La décote de productivité IA s'applique aux deux variantes, mais son interprétation diffère légèrement selon la variante retenue.

Q7 : la décote IA remplace-t-elle l'obsolescence technologique classique ou s'y ajoute-t-elle ?

Elle s'y ajoute. L'obsolescence technologique classique couvre tout risque qu'une technologie plus performante rende l'actif dépassé ; la décote de productivité IA en constitue une composante spécifique et récente, liée précisément aux outils de développement assisté par intelligence artificielle générative.

Q8 : comment documenter la décote retenue pour résister à un contrôle fiscal ou un contentieux ?

Chaque décote doit être accompagnée de la source empirique précise mobilisée, du raisonnement ayant conduit à sélectionner un point donné dans l'intervalle documenté, et idéalement de l'avis d'un second évaluateur lorsque le montant en jeu est significatif au regard de la valeur totale de l'actif évalué.

Q9 : la grille de décotes doit-elle être révisée régulièrement ?

Oui. La littérature sur la productivité des outils d'intelligence artificielle générative évolue rapidement, comme l'illustre la réplication publiée par METR en 2026, qui nuance sensiblement le résultat initial de 2025. Une révision annuelle de la grille retenue est recommandée.

Q10 : quelle méthode privilégier si le coût de reproduction n'est pas pertinent pour ce logiciel ?

Lorsque le logiciel génère des flux de trésorerie identifiables et significatifs, l'approche par le revenu, notamment par actualisation des flux futurs ou par la méthode des redevances, constitue généralement une base plus robuste que l'approche par les coûts, qui reste mieux adaptée à un logiciel récent ou dépourvu d'historique d'exploitation suffisant.

Estimez la valeur de votre entreprise avec Acontos, le simulateur en ligne d'Hectelion

Pour prolonger cette lecture par un chiffrage concret, Hectelion met à disposition Acontos, son outil en ligne d'audit, de due diligence et d'évaluation d'entreprise. Propulsé par l'intelligence artificielle Claude Sonnet 5 d'Anthropic et calibré par la méthodologie d'Hectelion, il lit vos comptes, normalise l'EBITDA, applique des multiples sectoriels réels et reconstitue un pont de dette nette pour estimer la valeur de vos titres en quelques minutes. Lancez gratuitement le simulateur de valorisation : l'outil est confidentiel, ne conserve aucun document et ne remplace pas une évaluation formelle, mais il donne un premier ordre de grandeur fiable avant d'en discuter avec nos équipes.

Conclusion : une grille plutôt qu'un chiffre unique

La question de savoir si l'intelligence artificielle justifie une décote sur le coût de reproduction d'un logiciel, d'un SaaS ou d'un CRM n'admet pas de réponse unique, et c'est précisément ce que démontre la littérature empirique disponible depuis 2023. Un gain de vitesse mesuré en laboratoire ne se retrouve que partiellement en conditions réelles d'entreprise, et peut même s'inverser lorsque des développeurs expérimentés interviennent sur du code mature qu'ils connaissent intimement.

Face à cette dispersion, la seule démarche défendable consiste à qualifier précisément le contexte de chaque logiciel évalué, à ancrer la décote retenue sur l'étude la plus représentative de ce contexte, à appliquer une retenue transversale au titre de la dette technique différée, et à documenter l'ensemble du raisonnement de manière à résister à un examen contradictoire. Cette approche, cohérente avec la pratique établie en ingénierie logicielle depuis le modèle COCOMO, transpose à l'intelligence artificielle générative un principe ancien : un ajustement de coût de développement repose sur plusieurs facteurs de contexte, jamais sur un pourcentage unique appliqué sans discernement.

Synthèse de l'article

Le coût de reproduction demeure une approche reconnue par la norme IVS 210 pour évaluer un logiciel, un SaaS ou un CRM, mais son application exige en 2026 un ajustement d'obsolescence technologique spécifique à l'intelligence artificielle générative. Les études disponibles montrent des résultats très dispersés selon le contexte : un gain de vitesse de 55,8 % en laboratoire, un gain de 26,08 % en conditions réelles d'entreprise, et un ralentissement de 19 % chez des développeurs expérimentés intervenant sur du code legacy complexe.

Cette dispersion interdit de retenir un chiffre unique. La grille proposée dans cet article distingue le contexte selon le type de codebase et le niveau d'expérience de l'équipe, applique une retenue transversale de 10 à 15 points au titre de la dette technique documentée par GitClear, et prévoit explicitement un scénario de majoration plutôt que de décote pour les systèmes legacy maintenus par des équipes très spécialisées.

Les deux cas pratiques illustrent l'écart concret que produit cette approche contextualisée : une décote nette de 14 % pour un CRM SaaS développé par une équipe mixte, contre une majoration de 15 % pour un ERP industriel legacy maintenu par une équipe senior, deux ajustements opposés qu'un chiffre unique n'aurait jamais pu capturer correctement.

Faute de doctrine publiée sur ce sujet précis, la rigueur de la démarche et la traçabilité des sources mobilisées constituent la meilleure protection de l'évaluateur, de son client et, le cas échéant, de l'issue d'un contrôle ou d'un contentieux portant sur la valeur d'un actif logiciel.

Sources

• Cui, Demirer, Jaffe, Musolff, Peng et Salz, The Effects of Generative AI on High-Skilled Work : Evidence from Three Field Experiments with Software Developers, 2025
• GitClear, AI Copilot Code Quality, analyse de 211 millions de lignes de code, 2025
• Google Cloud, DORA, State of DevOps Report, 2024
• International Valuation Standards Council (IVSC), IVS 210, Intangible Assets
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025
• Peng, Kalliamvakou, Cihon et Demirer, The Impact of AI on Developer Productivity : Evidence from GitHub Copilot, 2023

Auteur

Aristide Ruot, Ph.D.
Fondateur | Directeur Général, Hectelion SA