La durée de vie d'une ligne de code : de 20 ans à quelques semaines

Une ligne de code dans une centrale ou un système de contrôle nucléaire est encore pensée pour durer vingt-cinq ans, parfois plus. Pour le logiciel métier courant, l'horizon de planification a longtemps été plus proche de cinq à dix ans d'amortissement. Aujourd'hui, pour beaucoup d'outils, elle tient quelques mois, parfois quelques semaines. Pas à cause de la mode ou de la dette technique. Parce que les modèles qui l'écrivent deviennent eux-mêmes obsolètes à une vitesse qu'aucune génération de développeurs n'a connue avant nous.

En résumé

Le coût de production d'une ligne de code s'effondre plus vite que le code ne vieillit. Cursor a fait vivre et mourir quatre générations de son modèle Composer en sept mois. Le prix du token a chuté de 99 % chez OpenAI en seize mois, et de 86 % chez Cursor en quarante jours. Ramenés à la ligne, les grands projets logiciels documentés se chiffrent en dizaines, parfois en centaines d'euros. Une ligne produite par un agent IA, quelques centimes. Deux à trois ordres de grandeur d'écart. Les éditeurs d'IA ont même inscrit l'obsolescence des modèles dans leurs politiques officielles : trois mois de préavis pour un modèle de code spécialisé, c'est la norme. Résultat : la valeur n'est plus dans la ligne de code elle-même. Elle est dans ce qui décide quand et comment la réécrire : l'architecture, les données, la vitesse d'itération.

Composer 1 : quatre mois et demi de durée de vie

Cursor a lancé son premier modèle de code maison, Composer 1, fin octobre 2025. Une centaine de jours plus tard, Composer 1.5 arrivait, construit en poussant l'apprentissage par renforcement plus loin sur la même base pré-entraînée. Composer 1 a été retiré le 16 mars 2026. Durée de vie totale : un peu plus de quatre mois et demi. Deux jours après ce retrait, Composer 2 sortait, le plus grand saut de qualité d'une génération à l'autre que Cursor ait publié à ce jour. Deux mois plus tard, en mai 2026, Composer 2.5 prenait le relais. Quatre générations de modèle, sur un seul produit, en sept mois.

Une ligne de code écrite en octobre 2025 avec Composer 1 n'a donc jamais eu le temps de vieillir au sens classique du terme. Elle a été dépassée, en qualité et en prix, avant même d'avoir fini son premier trimestre en production.

Le coût de la ligne de code s'est effondré

Ce n'est pas qu'un problème de qualité de modèle. C'est un problème de prix. Entre Composer 1.5 (février 2026) et Composer 2 (mars 2026), le tarif au million de tokens de Cursor a baissé de 86 % en quarante jours. Ce n'est pas un cas isolé. C'est le régime normal de l'industrie depuis le lancement de GPT-4 en mars 2023.

En clair : ce que vous avez payé pour faire écrire une fonctionnalité en 2023 coûte aujourd'hui une fraction du prix, souvent pour un meilleur résultat. Chaque ligne de code produite hier devient, mécaniquement, plus chère à garder que la ligne équivalente produite aujourd'hui.

50 € la ligne, ou 50 centimes la ligne ?

Poussez le calcul un cran plus loin et l'écart devient vertigineux. Combien coûte une ligne de code produite à la manière traditionnelle ? Personne ne publie de tarif officiel, mais les projets documentés permettent d'encadrer l'ordre de grandeur. Il se compte en dizaines, parfois en centaines d'euros la ligne :

• Virtual Case File du FBI : abandonné en 2005 après 170 millions de dollars dépensés pour 700 000 lignes de code jamais mises en production. Environ 240 $ la ligne, jetée.
• Healthcare.gov : 1,7 milliard de dollars en 2014 (chiffre de l'Inspecteur général) pour un cœur de système mesuré à environ 3,7 millions de lignes. Plusieurs centaines de dollars la ligne.
• Logiciel de vol de la navette spatiale (NASA/IBM) : ~420 000 lignes maintenues par une équipe de 260 personnes pour 35 millions de dollars par an (Fast Company, 1996). Le code le plus scruté jamais écrit.
• SAP Business One, PME britannique réelle (Griffiths, Heinze & Ofoegbu, 2013) : coût réel final d'implémentation proche du double du coût SAP initial, une fois personnalisation, formation et réingénierie comptées.
• Louvois (France) : le logiciel de paie des armées a englouti environ 470 millions d'euros avant d'être purement abandonné.

Retenez 50 € la ligne comme ordre de grandeur volontairement rond et prudent. Chaque cas documenté ci-dessus se situe à ce niveau ou au-dessus.

Face à ça, une ligne écrite par un agent IA (pas toujours élégante, mais fonctionnelle) coûte une fraction de centime à quelques centimes en dépense de modèle pur, si l'on reprend les tarifs par token du tableau ci-dessus. L'écart n'est pas de 20 % ou de 2x. Il est de l'ordre de 100x.

Les cas réels vont dans le même sens. Une tâche de migration exécutée par Claude Code sur un dépôt de plus d'1 million de lignes a coûté 4,12 $ en tokens, scans, plan et écriture inclus (benchmark technique publié par tunedtools.com, 2026). Des développeurs indépendants rapportent avoir livré des SaaS de production complets pour 300 à 1 500 $ de dépense IA totale sur plusieurs mois, pour des livrables de plusieurs milliers de lignes.

Ce ratio change la question à se poser. À 50 € la ligne, il faut protéger le code : il doit durer, parce que le refaire coûte une fortune. À quelques centimes la ligne, vous pouvez vous permettre de le refaire des dizaines de fois avant d'atteindre le coût d'une seule implémentation classique, et rester quand même économiquement gagnant.

Garder une vieille ligne peut coûter encore plus cher que la produire. Le vol inaugural d'Ariane 5, en 1996, a été détruit par une seule conversion non protégée, une ligne réutilisée d'Ariane 4 : plus de 370 millions de dollars partis en 37 secondes. Knight Capital a perdu 460 millions de dollars en 45 minutes en 2012, quand un déploiement a réactivé par accident du code mort qui dormait en production depuis neuf ans. Le code hérité n'est pas seulement cher à refaire. Il est cher à garder.

Le sujet n'est plus la longévité du code. C'est la vitesse avec laquelle vous livrez l'usage qu'il est censé produire.

La péremption des modèles n'est plus un accident, c'est une politique

OpenAI et Anthropic ne laissent plus ça au hasard. C'est écrit dans leurs conditions. OpenAI garantit un préavis d'au moins 6 mois avant de retirer un modèle grand public, seulement 3 mois pour les variantes spécialisées (les modèles de code type Codex y sont explicitement cités), et parfois seulement 2 semaines pour un modèle en preview. Anthropic promet un minimum de 60 jours.

Dans les faits, Claude 3.5 Sonnet (lancé en juin 2024) a été retiré en octobre 2025 : seize mois de vie totale. Claude 3.5 Haiku (octobre 2024) a suivi la même trajectoire, retiré en février 2026, un peu plus d'un an. Même le modèle le plus longévif de ce lot, Claude 3 Opus, n'a pas dépassé deux ans entre sa sortie et son retrait. On est loin des vingt-cinq ans encore exigés du logiciel dans l'énergie ou le nucléaire, et même de l'horizon cinq à dix ans sur lequel la plupart des outils métier étaient construits.

Ce qui a vraiment changé : pas le code, sa valeur

Le code n'a pas disparu parce qu'il s'est physiquement dégradé. Du COBOL écrit en 1975 tourne encore dans des banques. Du logiciel de contrôle industriel vit vingt-cinq ans et plus dans l'énergie ou le nucléaire. Ce qui s'effondre, c'est l'hypothèse selon laquelle, pour un outil métier ordinaire, écrire une ligne une fois vous rapporte sur toute sa fenêtre d'amortissement.

Avant, la ligne de code était un actif : on l'écrivait, on la protégeait, on la faisait durer, parce que la refaire coûtait cher. Aujourd'hui, la refaire coûte de moins en moins cher, plus vite qu'elle ne se démode fonctionnellement. Le calcul économique s'inverse. La valeur n'est plus dans la ligne de code elle-même. Elle est dans la vitesse à laquelle vous pouvez la régénérer, l'améliorer ou la remplacer.

Ce que ça change pour votre stratégie logicielle

Trois conséquences concrètes pour une PME qui construit ou fait construire un outil aujourd'hui :

• Arrêtez de budgéter comme en 2005. Un budget « construire une fois, maintenir dix ans » suppose une stabilité qui n'existe plus. Budgétez pour de la ré-optimisation continue, pas pour un projet fini.
• La propriété du code compte plus, pas moins. Si le code se démode en quelques mois, vous devez pouvoir le rouvrir, le régénérer et le faire évoluer vous-même, sans dépendre d'un éditeur SaaS qui décide seul du rythme.
• La vraie valeur se déplace vers ce qui ne se démode pas : le modèle de données, la logique métier, les décisions d'architecture, la connaissance du terrain. Le code qui les exécute est de plus en plus jetable. Ce qu'il encode ne l'est pas.

C'est exactement le principe derrière notre façon de construire du sur-mesure : on ne vous vend pas une ligne de code figée. On vous laisse propriétaire de ce qui compte, pour que la réécrire dans six mois soit un ajustement, pas un projet. Voir aussi nos articles sur le SaaS comme dépense vs le sur-mesure comme investissement et OPEX vs CAPEX.

Questions fréquentes

Est-ce que ça veut dire que le code perd toute sa valeur ?

Non. L'artefact devient jetable, pas la logique qu'il porte. Ce qui garde de la valeur, c'est le modèle de données, les règles métier et les décisions d'architecture. Ils restent valables même quand vous réécrivez l'implémentation avec un modèle plus récent.

Faut-il réécrire tout son code à chaque nouveau modèle d'IA ?

Non. Mais il faut arrêter de traiter la ré-optimisation comme un projet exceptionnel. Une revue régulière, trimestrielle par exemple, pour repérer ce qu'un modèle plus récent ferait mieux ou moins cher suffit dans la plupart des cas.

Le code généré par IA est-il fiable sur le long terme ?

Ça dépend de l'architecture et des tests autour, pas du modèle qui l'a écrit. Un code bien testé et bien structuré reste maintenable même quand le modèle qui l'a produit est retiré. Un code sans tests devient un problème dès le premier changement.

Concrètement, qu'est-ce qui a encore une durée de vie de plusieurs années ?

Le modèle de données, les intégrations avec vos systèmes existants, et les décisions d'architecture qui déterminent à quelle vitesse vous pouvez faire évoluer le reste. C'est là qu'il faut mettre le soin. L'implémentation ligne à ligne, elle, doit rester facile à jeter.

Ces chiffres sont-ils vraiment comparables ?

Non. Les contextes diffèrent radicalement (criticité, sécurité, échelle). L'idée n'est pas une équivalence au centime près. C'est l'ordre de grandeur et la direction de la tendance.