Une ingénieure senior dans une entreprise de services financiers du Fortune 500 a récemment décrit un moment qui l’a stoppée net. Elle examinait une pull request d’un collègue junior — trois cents lignes de code Go parfaitement fonctionnel qui gérait la réconciliation des paiements. La logique était propre, les tests passaient et la documentation était complète. Mais le code n’avait pas d’historique. Pas de commits itératifs montrant comment le développeur avait travaillé sur les cas limites. Pas d’expériences commentées. Aucun signe de lutte humaine. Le développeur junior avait généré l’intégralité du module avec un [assistant de codage IA](ai-coding-assistants-fr), l’avait testé et soumis. Quand elle lui a demandé d’expliquer l’algorithme de réconciliation, il pouvait décrire ce qu’il faisait mais pas pourquoi il était conçu de cette manière.
Cette scène se joue dans des milliers d’organisations d’ingénierie. Alors que le code généré par l’IA représente désormais 30 à 41 % du nouveau code dans les grandes entreprises technologiques, la question n’est plus de savoir si l’IA va écrire nos logiciels. La question est de savoir ce qu’il advient de l’art de les maintenir — et si la maintenance elle-même est en train de devenir obsolète.
La dette technique change de définition
Pendant des décennies, la dette technique a été la métaphore dominante de l’industrie pour le coût des raccourcis. Ward Cunningham a inventé le terme en 1992 pour décrire ce qui se passe quand les équipes livrent du code qu’elles savent imparfait, avec l’intention de le corriger plus tard. La dette se compose : les correctifs rapides deviennent des problèmes structurels, la documentation prend du retard, et finalement les équipes passent plus de temps à gérer l’ancien code qu’à construire de nouvelles fonctionnalités. McKinsey estimait en 2020 que la dette technique consommait 20 à 40 % de la valeur totale du patrimoine technologique des grandes entreprises.
Le code généré par l’IA inverse cette équation. Quand un module peut être régénéré à partir d’une spécification en langage naturel en quelques minutes plutôt que refactorisé pendant des semaines, le calcul de la dette change fondamentalement. Au lieu de rembourser la dette par un refactoring minutieux, les équipes peuvent déclarer faillite — abandonner l’ancienne implémentation et en générer une nouvelle.
Le concept de « bases de code régénératives » — où certains composants non critiques sont périodiquement régénérés à partir de spécifications plutôt que maintenus par des correctifs incrémentaux — émerge dans les discussions de l’industrie. L’approche traite les spécifications comme l’artefact durable et le code comme une sortie éphémère. Si la spécification est correcte et les tests complets, l’implémentation devient interchangeable.
Mais cela crée une nouvelle forme de dette qui n’a pas encore de nom établi. Appelons-la dette de spécification : l’écart entre ce qu’une spécification en langage naturel décrit et ce que le système doit réellement faire. Quand un humain écrit du code de manière itérative, les cas limites émergent par l’acte d’implémentation. Quand l’IA génère du code à partir d’une spécification, les cas limites non découverts se cachent derrière une sortie d’apparence confiante.
La revue de code à l’ère de la génération
La revue de code traditionnelle suppose un modèle mental partagé. Un réviseur lit le code d’un collègue et évalue non seulement la justesse mais l’intention, la maintenabilité et l’alignement avec l’architecture du système. Le réviseur peut demander : pourquoi avez-vous choisi cette structure de données ? Que se passe-t-il à l’échelle ? Comment cela interagit-il avec le module de facturation ?
Quand le code est généré par l’IA, ces questions se heurtent à un mur. Le développeur qui a soumis le code peut comprendre l’exigence métier mais pas les choix d’implémentation que le modèle a faits. Le réviseur fait face à un nouveau défi : évaluer du code dont la logique n’existe nulle part ailleurs que dans les poids d’un réseau de neurones.
Certaines organisations s’adaptent. L’équipe d’ingénierie de Stripe a construit des systèmes comme ses agents IA « minions » et des « blueprints » internes qui codifient les standards d’ingénierie, déplaçant l’attention de la revue de la sortie générée vers les spécifications et contraintes qui guident la génération. Si le blueprint est solide et la suite de tests complète, les détails d’implémentation importent moins. L’attention se déplace de « ce code est-il bien écrit ? » vers « cette spécification capture-t-elle toutes les exigences ? ».
D’autres équipes misent sur la vérification automatisée. Des entreprises comme Anthropic et OpenAI ont investi massivement dans des frameworks de tests alimentés par l’IA qui génèrent des cas de test en même temps que le code, créant une couche de vérification qui ne dépend pas de la revue humaine de chaque détail d’implémentation. Le schéma émergent est clair : quand le code est bon marché, les tests deviennent le vrai produit.
Publicité
Stratégies de test pour le code jetable
La pyramide des tests — tests unitaires à la base, tests d’intégration au milieu, tests de bout en bout au sommet — a été conçue pour un monde où le code persistait. On écrivait des tests pour détecter les régressions dans du code qu’on s’attendait à maintenir pendant des années. Quand le code est jetable, la pyramide s’inverse.
Les tests comportementaux de bout en bout deviennent primordiaux. Si un module va être régénéré périodiquement, les tests unitaires liés à des détails d’implémentation spécifiques cassent à chaque régénération. Les contrats comportementaux — des tests qui vérifient ce que le système fait plutôt que comment il le fait — survivent à travers les implémentations. Les tests basés sur les propriétés, qui vérifient des invariants plutôt que des paires entrée-sortie spécifiques, deviennent essentiels plutôt qu’optionnels.
Les tests de contrat entre services gagnent aussi en urgence. Quand des composants individuels peuvent être régénérés indépendamment, les interfaces entre eux doivent être solides comme le roc. Les frameworks de tests de contrat comme Pact connaissent une adoption croissante dans les organisations à forte génération de code IA, les équipes reconnaissant que la stabilité des interfaces compte plus que la stabilité de l’implémentation quand les composants sont régulièrement régénérés.
Ce changement a des conséquences en aval pour l’intégration continue. Les pipelines de build conçus pour exécuter des milliers de tests unitaires en quelques minutes doivent être repensés autour de tests d’intégration et de contrat plus lents mais plus significatifs. Les organisations qui ont effectué cette transition rapportent des temps de build plus longs mais moins d’incidents en production — un compromis que la plupart des responsables d’ingénierie acceptent volontiers.
La gouvernance quand personne ne possède le code
La gouvernance logicielle repose traditionnellement sur la propriété. Une équipe possède un service, maintient ses dépendances, répond quand il tombe en panne et décide quand il doit être réécrit. La propriété crée la responsabilité.
Le code jetable remet en question ce modèle. Si un module a été généré par une IA, régénéré trois fois au cours du dernier trimestre et pourrait être régénéré à nouveau demain, qui en est propriétaire ? Le développeur qui a écrit la spécification ? L’équipe qui maintient la suite de tests ? L’équipe plateforme qui gère l’infrastructure de codage IA ?
Les grandes entreprises technologiques expérimentent des réponses. Certaines équipes ont adopté le concept de « propriétaires de spécifications » — des ingénieurs qui sont responsables non pas du code mais de la spécification comportementale et des contrats de test qui définissent les responsabilités d’un composant. D’autres ont commencé à tester des « politiques de génération » qui spécifient quels modèles IA peuvent être utilisés pour quels types de code, avec une gouvernance plus stricte pour les composants critiques en matière de sécurité.
La dimension réglementaire arrive également. Le EU AI Act, dont l’application progressive a débuté en février 2025 avec les interdictions de certaines pratiques d’IA prenant effet en premier, exige des organisations qu’elles maintiennent une documentation sur les sorties générées par l’IA dans les applications à haut risque. Les entreprises de services financiers soumises à DORA (Digital Operational Resilience Act) doivent démontrer l’auditabilité de leurs systèmes technologiques — une exigence qui se complexifie lorsque le code sous-jacent change à chaque cycle de régénération.
Les limites de la jetabilité
Tout le code ne peut pas être traité comme jetable. Les systèmes qui gèrent l’état — bases de données, files de messages, sessions utilisateur — résistent à la régénération parce que leur comportement est inséparable des données qu’ils contiennent. Les systèmes temps réel avec des exigences strictes de latence nécessitent des optimisations qui émergent d’un profilage minutieux, pas de spécifications en langage naturel. Le code critique en matière de sécurité exige une vérification formelle et des pistes d’audit que les patterns jetables ne permettent pas.
Le consensus émergent parmi les leaders de l’ingénierie est une architecture à deux niveaux. La logique métier sans état, les gestionnaires d’API, les transformations de données et les modules de reporting sont des candidats à la régénération. L’infrastructure avec état, les frontières de sécurité et les chemins critiques en performance restent maintenus de manière traditionnelle. La frontière entre ces deux niveaux devient elle-même une décision de conception critique — une décision qui nécessite le type de pensée systémique que l’IA n’a pas encore reproduit.
Ce qui est clair, c’est que les outils avancent plus vite que les cadres de gouvernance. Les organisations qui traitent le code généré par l’IA simplement comme du « code écrit plus vite » passent à côté du changement structurel. Le logiciel change. La question est de savoir si les pratiques, les politiques et les modèles organisationnels changent avec lui — ou prennent du retard jusqu’à ce que la prochaine panne force la conversation.
Questions Fréquemment Posées
Qu’est-ce que disposable software ?
Cet article couvre les aspects essentiels de ce sujet, en examinant les tendances actuelles, les acteurs clés et les implications pratiques pour les professionnels et les organisations en 2026.
Pourquoi disposable software est-il important ?
Ce sujet est important car il a un impact direct sur la façon dont les organisations planifient leur stratégie technologique, allouent leurs ressources et se positionnent dans un paysage en évolution rapide.
Quels sont les points clés à retenir de cet article ?
L’article analyse les mécanismes clés, les cadres de référence et les exemples concrets qui permettent de comprendre le fonctionnement de ce domaine, en s’appuyant sur des données actuelles et des études de cas.
