Cinq fonctionnalités de création livrées entre le 2 et le 16 avril 2026. Zéro fonctionnalité de maintenance. Ce ratio te dit tout sur la position réelle du marché du coding IA — et sur ce qu'il refuse d'admettre publiquement.

Cursor 3 (2 avril) a lancé les Agent Tabs parallèles — plusieurs agents IA qui écrivent du code simultanément sur des branches séparées. GitHub Copilot (4 avril) a ajouté le mode Autopilot — des agents qui approuvent leurs propres appels d'outils sans te demander ton avis. Windsurf 2.0 (10 avril) a livré un Agent Command Center. Claude Code (14 avril) a introduit les Routines — des agents d'arrière-plan planifiés qui génèrent du code sur déclencheur. Le Codex d'OpenAI (16 avril) a reçu des workflows multi-agents. Pas une seule annonce ne traite de ce qui arrive au code après sa mise en production.

Ce n'est pas un oubli. C'est une stratégie produit.

Les 60 % que personne ne vend

Barry Boehm a établi en 1976 que la maintenance consomme 60 à 80 % du coût total du cycle de vie d'un logiciel. IBM l'a confirmé à maintes reprises au fil des décennies. Rien en cinquante ans de génie logiciel n'a renversé ce ratio.

L'IA semble l'aggraver.

Une étude publiée sur arXiv le 8 avril 2026 a analysé dix gros projets générés par Cursor, chacun comptant en moyenne 17 000 lignes de code. Correction fonctionnelle : 91 % — le code marchait. CodeScene, un outil d'analyse de la santé du code, a relevé 1 305 problèmes de conception sur l'ensemble de ces projets : 28,4 % de code dupliqué, des méthodes de 171 lignes en moyenne (les bonnes pratiques plafonnent à 20–30), et une complexité cyclomatique — le nombre de chemins de branchement à travers une fonction — de 17 en moyenne, soit presque le double du plafond recommandé.

La démo est livrée. La codebase est structurellement hostile à quiconque y touche ensuite — y compris l'IA qui l'a écrite.

Tous les grands benchmarks de coding IA renforcent cet angle mort. SWE-bench teste la correction de bugs. HumanEval teste la génération de fonctions. Aucun benchmark ne pose la question : « ce modèle peut-il ajouter une fonctionnalité sans danger à la codebase emmêlée qu'il a générée il y a trois mois, sans documentation de conception ? » Sans ce benchmark, les éditeurs n'ont strictement aucune incitation commerciale à optimiser ce qui coûte réellement de l'argent.

Pourquoi l'IA est structurellement incapable de maintenir ce qu'elle crée

La maintenance exige trois capacités que la création n'exige pas : des décisions de conception cohérentes d'une session à l'autre, la compréhension du pourquoi le code existe (pas seulement de ce qu'il fait), et la discipline de refactorer plutôt que de dupliquer.

Les outils IA actuels échouent sur les trois fronts.

Chaque nouvelle session démarre avec zéro mémoire des choix de conception antérieurs. Le modèle génère le pattern qui correspond au prompt en cours, pas celui qu'il a utilisé mardi dernier. C'est pour ça que l'étude arXiv a trouvé 28,4 % de duplication — l'IA résout le même problème différemment à chaque fois parce qu'elle ne se souvient pas de l'avoir déjà résolu.

L'essai contrôlé randomisé de METR — publié en juillet 2025, toujours la seule étude contrôlée du genre — a quantifié l'écart entre perception et réalité : 16 développeurs expérimentés sur leurs propres dépôts travaillaient 19 % plus lentement avec les outils IA, tout en se croyant 20 % plus rapides. Un delta de 39 points de pourcentage entre ce que les développeurs pensent qu'il se passe et ce qui se passe réellement. Sur des codebases familières. Sur du code IA qu'on ne connaît pas, personne ne l'a mesuré, parce que personne n'a construit le benchmark.

Ce qu'un outil axé maintenance nécessiterait vraiment

Si tu concevais un outil de coding IA pour les 60–80 % du travail qui coûtent réellement de l'argent, il ne ressemblerait à rien de ce qui existe aujourd'hui.

La justification de conception comme métadonnée. Pas seulement ce que le code fait — pourquoi il est structuré comme ça. Chaque fonction générée par IA devrait porter un historique des contraintes, des alternatives considérées et des décisions de conception qui l'ont produite. Le CLAUDE.md de Claude Code est l'approximation la plus proche : un contexte projet persistant d'une session à l'autre. Mais c'est un fichier texte que tu maintiens à la main, pas un registre architectural automatisé.

Garantie de cohérence inter-sessions. Un outil axé maintenance détecterait quand le modèle introduit un pattern qui contredit un pattern existant et bloquerait le conflit avant la génération du code — pas après qu'un humain l'ait revu. L'indexation de codebase de Cursor (jusqu'à 500 Mo, requêtes en moins d'une seconde) fournit la couche de recherche nécessaire. De la recherche sans application des règles, c'est une bibliothèque sans bibliothécaire.

Le refactoring comme mode par défaut. Les outils actuels optimisent pour le code nouveau. Un outil de maintenance privilégierait par défaut la modification du code existant — trouver le bon endroit pour ajouter de la logique plutôt que générer un nouveau fichier. Il mesurerait et minimiserait la duplication comme métrique primaire, au même titre que la correction fonctionnelle.

Des seuils de dégradation. Quand la complexité cyclomatique dépasse les seuils, quand les méthodes dépassent 30 lignes, quand le taux de duplication grimpe — l'outil refuse de commiter. Pas comme un plugin optionnel. Par défaut. Comme un vérificateur de types bloque du code invalide, un outil axé maintenance bloquerait du code impossible à maintenir.

L'étude longitudinale de JetBrains publiée le 14 avril 2026 a suivi 800 développeurs à travers 151,9 millions d'événements enregistrés et a mis en lumière un signal sur lequel aucun outil de coding n'agit aujourd'hui : les développeurs passent plus d'un tiers de leur temps à vérifier les suggestions de l'IA, et ils annulent environ une complétion acceptée sur cinq en supprimant le code après coup. Ce schéma de suppression est un signal d'entraînement gratuit — un corpus de « le modèle pensait que c'était correct, l'humain a prouvé le contraire » — qui dort dans la télémétrie de chaque IDE. Quelqu'un pourrait construire une boucle de feedback qui ingère ces annulations et apprend à générer du code maintenable dès le départ. Personne ne l'a fait, parce que les démos de création se vendent. Un screencast de 30 secondes d'un agent qui monte une app à partir d'un prompt fait des millions de vues. Un screencast d'un agent qui décompose soigneusement une méthode de 171 lignes en six fonctions propres fait un talk en conférence, au mieux.

La réalité des prix

Si tu as validé un projet construit par IA ce trimestre, voici ce qu'aucun éditeur ne te devisera : prévois trois fois le coût de création pour sa première année de maintenance. Si ton agent IA a écrit 17 000 lignes en une semaine, tes ingénieurs passeront trois semaines à démêler les problèmes de conception avant de pouvoir l'étendre en toute sécurité — puis le cycle recommence après chaque ajout de fonctionnalité.

L'approche la plus honnête : traite le code généré par IA comme un prototype jetable avec une durée de vie de six mois. Fais la démo, valide l'idée, puis reconstruis les parties qui ont prouvé leur valeur avec des ingénieurs qui comprennent l'architecture.

Chaque éditeur d'outils de coding IA en avril 2026 tarifie et commercialise la création comme le produit. Le vrai centre de coût du logiciel n'a jamais été la création. Tant qu'un éditeur ne construira pas — et ne facturera pas — un multiplicateur de maintenance, tu achètes la phase la moins chère du processus et tu paies le prix fort pour tout ce qui suit.