Fin du « Clean Code » : le code illisible des IA (2026)

En 2026, on a franchi une petite ligne invisible. Une partie non négligeable du code en production est écrite, réécrite ou au moins transformée par des IA. Copilot, ChatGPT, des agents internes, des refactors automatiques, des « fixers » qui ouvrent des PR pendant la nuit. Ça va vite. Ça marche souvent. Et pourtant.

Tu ouvres un fichier. Tu lis trois fonctions. Tu comprends à peu près l’intention. Puis tu arrives sur un bloc. Ça compile. Les tests passent. Mais tu sens ce truc dans le ventre, le petit froid. Personne ne sait vraiment pourquoi c’est comme ça. Même l’équipe qui a mergé le code il y a deux semaines.

Et c’est là qu’on parle de « fin du clean code ». Pas parce que les gens sont devenus paresseux, ni parce qu’on a décidé collectivement que les noms de variables n’avaient plus d’importance. Mais parce que le rapport de force a changé. L’IA produit du code à une vitesse qui casse nos garde fous humains.

Je vais clarifier un truc tout de suite, parce que sinon on va se perdre dans un débat de puristes. « Clean » ne veut pas dire « joli ». Ça veut dire compréhensible, modifiable, testable. Un code clean c’est un code que quelqu’un d’autre peut reprendre à 2 h du matin, en incident, et réparer sans prier. Ou un code que tu peux refactorer sans trembler parce que les tests te protègent et que la structure te raconte l’histoire.

La tension actuelle est simple et brutale : optimisation locale contre compréhension globale.

• Optimisation locale : passer les tests, livrer vite, fermer le ticket.
• Compréhension globale : maintenir, déboguer, sécuriser, faire évoluer, auditer, migrer.

L’IA est excellente sur la première. La deuxième... c’est plus compliqué.

Promesse de cet article : comprendre pourquoi l’IA produit du code illisible, quand c’est acceptable, et comment reprendre le contrôle sans revenir à la bougie.

Pourquoi on parle soudain de la « fin du clean code » (et pourquoi ce n’est pas juste un débat de puristes)

Le sujet est devenu brûlant parce que le volume a changé. Avant, le code illisible existait, évidemment. Mais il demandait un effort. Il fallait le produire, volontairement ou par négligence, et ça prenait du temps. Aujourd’hui, tu peux générer 800 lignes en 20 secondes. Tu peux demander « ajoute la feature X » et obtenir un patch énorme qui semble sérieux, bien formaté, avec quelques commentaires, et même des tests.

Sauf que... le patch raconte rarement une histoire simple.

La conséquence, c’est qu’on se retrouve avec du code « en apparence professionnelle », mais don’t la logique interne n’est pas alignée avec le reste du produit, ni avec les contraintes réelles de l’équipe. Il y a des abstractions en trop, des couches sans nécessité, des dépendances ajoutées « parce que c’est pratique ». Et surtout, il manque souvent l’élément le plus important en maintenance : le pourquoi.

Et ce n’est pas un détail de style. En incident ou en audit, l’illisibilité devient un coût direct. Temps perdu, risques augmentés, décisions prises à l’aveugle.

Donc oui, on en parle soudainement. Parce que tout le monde le vit. Même ceux qui jurent ne pas utiliser d’IA.

Petit rappel : « clean code », c’était quoi exactement (et ce que ça n’a jamais garanti)

Si on revient à la version pratique du clean code, pas la version religieuse, on est sur des heuristiques simples :

• intention claire : quand je lis une fonction, je sais ce qu’elle fait et pourquoi elle existe
• noms explicites : variables, fonctions, modules, pas besoin de décodeur
• fonctions courtes, responsabilité unique, pas des monstres à 14 embranchements
• duplication maîtrisée : on duplique parfois pour la clarté, mais on évite la copie industrielle
• tests fiables : pas juste « ça passe », mais des tests qui verrouillent l’intention

Pourquoi ça marchait bien en équipe ? Parce que la lecture est plus importante que l’écriture. On lit toute la journée. On relit en revue de code. On relit quand quelqu’un part et qu’un autre reprend. On relit en onboarding. Et les équipes tournent. Les gens changent de projet, de contexte, de produit.

Clean code, dans ce cadre, c’était une sorte de politesse. Une manière de dire : je te laisse un endroit vivable.

Mais il faut être honnête. Clean code n’a jamais garanti que le système serait simple. Il n’a jamais garanti l’absence de bugs. Et il n’a jamais été applicable partout de la même façon.

Certains domaines produisent naturellement du code « moins lisible » : bas niveau, optimisation perf, méta programmation, et évidemment code généré. Tu ne lis pas le code protobuf pour le plaisir. Tu le régénères.

Point clé : clean code est une heuristique humaine, pas une loi physique. Et les heuristiques se cassent quand le contexte change trop vite.

Ce qui a changé avec l’IA : on ne « code » plus, on « pilote » (et ça casse les garde fous)

Le workflow moderne ressemble souvent à ça :

prompt → génération → patch → tests → itérations rapides → merge.

Et je ne dis pas ça comme une caricature. C’est littéralement la routine de beaucoup d’équipes. On pilote un assistant. On obtient un diff. On ajuste. On rerun. On merge.

Le problème n’est pas la génération en soi. Le problème, c’est l’effet « copier coller à l’échelle ».

Avant, écrire 500 lignes demandait du temps. Ce temps était aussi du temps de lecture implicite. Tu écris, tu relis, tu réécris. Avec l’IA, tu peux produire un gros volume sans avoir vécu le code. Tu n’as pas eu le temps de le sentir, de le modeler. Tu l’as accepté.

Asymétrie fondamentale : l’IA écrit en secondes. La revue humaine reste coûteuse. Et donc la revue se compresse. Elle devient une vérification de surface : lint ok, tests verts, pas de trucs trop bizarres, on avance.

Sauf que les modèles optimisent la plausibilité et la réussite apparente. Compiler, passer des tests, respecter le style local. Pas la compréhension future. Pas la maintenabilité dans 3 mois. Pas l’élégance de la séparation des responsabilités.

Résultat : plus de code jetable. Et le code jetable finit quand même en production, parce que « on verra plus tard ». Et plus tard, c’est rarement un moment calme.

Pourquoi les machines écrivent du code que personne ne comprend (même quand ça « marche »)

Il y a plusieurs raisons, et elles s’additionnent.

Compression d’intention

Une IA reconstruit une solution plausible à partir de patterns vus ailleurs. Elle ne vit pas ton contexte métier. Elle ne sait pas ce qui est sacré chez vous, ce qui ne doit jamais arriver, ce qui a déjà cassé en prod l’an dernier. Elle peut imiter une forme, mais elle n’expose pas naturellement les invariants. Et les invariants, c’est la vraie colonne vertébrale d’un système.

Tu te retrouves avec un code qui fait quelque chose, mais qui ne dit pas ce qu’il promet.

Sur abstraction ou sous abstraction

Parfois, l’IA sur abstrait. Elle crée des couches inutiles. Des helpers génériques « au cas où ». Des interfaces pour une seule implémentation. Ça a l’air propre sur le moment, mais ça dilue l’intention.

Et parfois, elle fait l’inverse. Elle tasse tout dans une fonction. Parce que « faire court », c’est un signal de qualité superficielle. Donc elle compacte. Elle enchaîne les ternaires, les map/filter/reduce, les regex cryptiques. Ça impressionne. Mais ça ne se maintient pas.

« Happy path driven »

Le code est souvent optimisé pour le cas nominal. Les bords sont mal traités. Les erreurs sont masquées. Les retours sont trop génériques. Tu vois des try/catch qui avalent l’exception et renvoient un booléen. Ou des fallback silencieux qui « arrangent » les entrées.

Ça marche en démo. Puis ça génère des incidents bizarres.

Style hybride

L’IA mélange. Elle peut introduire un pattern de codebase A dans un codebase B. Elle peut nommer des choses avec une convention différente. Elle peut adopter un style « framework first » alors que votre repo est « domaine first ». Tu te retrouves avec un patch qui parle une autre langue.

Et le pire, c’est que c’est souvent subtil. Ce n’est pas « moche ». C’est juste… pas cohérent.

Optimisations non justifiées

C’est un classique. Micro perf sans benchmark. Bit tricks. Structures de données plus complexes que nécessaire. Mémoïsation partout. Concurrence sans raison. Regex qui remplace une boucle claire.

L’IA a vu beaucoup de code « intelligent ». Elle le reproduit. Mais l’intelligence sans justification, c’est de l’opacité.

Le vrai problème n’est pas l’IA : c’est l’absence de « contrat de lisibilité » dans les équipes

Ça pique un peu, mais c’est vrai. Beaucoup de projets n’ont pas de définition partagée de « lisible ». Pas de critères de sortie. Pas de « ce qu’on accepte » et « ce qu’on refuse ».

Donc les revues de code deviennent des checks superficiels :

• style
• lint
• tests verts
• pas de grosse régression visible

Mais pas de compréhension.

Or la compréhension, c’est une propriété. Ça se travaille. Ça se vérifie. Et ça se protège.

Le coût de l’illisibilité est différé. Tu le paies plus tard, au pire moment :

• un incident sur une zone obscure
• un pivot produit qui demande une modification transversale
• une migration de dépendance
• un audit sécurité
• une montée de version majeure

C’est littéralement de la dette technique. Et l’IA peut l’accélérer si l’équipe n’impose pas des standards d’intention.

Idée directrice : instaurer un contrat plutôt que blâmer l’outil. Standards, tests, docs minimales, ownership. L’IA ne comprend pas vos normes si elles n’existent pas, et si elles ne sont pas appliquées.

Quand du code « illisible » est acceptable (et même souhaitable)

Oui, il y a des cas où l’illisibilité est tolérable. Mais uniquement si elle est encadrée.

Cas 1 : code généré et non édité à la main

Clients API, protobuf, ORM, codegen OpenAPI. Le contrat est clair : on ne touche pas, on régénère. Tu peux avoir du code moche, long, répétitif. Ce n’est pas grave parce que l’humain n’est pas censé y intervenir.

Encore faut il que ce soit explicitement marqué. Et isolé.

Cas 2 : hot paths perf

Parfois tu as besoin d’un code plus bas niveau, plus compact, plus « méchant ». Ok. Mais il faut une justification, un benchmark, et un commentaire d’intention. Pas un commentaire décoratif. Un commentaire qui dit : pourquoi c’est comme ça, et quel invariant ça protège.

Cas 3 : scripts temporaires et outillage interne

Un script de migration, un outil one shot, un hack pour une deadline. Ça arrive. Mais il faut l’étiqueter comme tel. Et si ça devient permanent, il faut le reconnaître et le transformer.

Condition obligatoire dans tous les cas : frontières claires. Où c’est illisible, pourquoi, et comment on le remplace ou le régénère.

Règle simple : si un humain doit le maintenir, un humain doit pouvoir le comprendre.

Les signaux d’alerte : reconnaître le « code IA illisible » avant qu’il ne s’enracine

En PR, certains symptômes reviennent.

• ajout massif de code pour un petit changement
• logique dupliquée avec de légères variations, le fameux copier coller « intelligent »
• helpers non réutilisés, créés juste pour rendre le patch plus long et plus structuré
• fichiers couteau suisse, où on a ajouté une méthode de plus « parce que c’était pratique »
• processDatahandleRequest

Et puis il y a le piège des commentaires.

// convertit la liste en maptoMap()

Autre alerte : dépendances ajoutées sans raison forte. Une lib entière pour faire un truc simple. Ou une dépendance réseau pour une feature qui devait rester locale.

Et enfin, observabilité oubliée. Pas de logs, pas de métriques, pas de traces là où le comportement n’est pas évident. L’IA peut produire du code correct, mais elle n’a pas l’instinct « on va devoir débugger ça en prod ».

Ce qu’il faut exiger en 2026 : « intention driven code » plutôt que « clean code »

Si je devais résumer la nouvelle boussole, ce serait ça : le code doit rendre l’intention vérifiable.

Pas juste lisible au sens esthétique. Vérifiable.

• invariants exprimés
• pré conditions et post conditions claires
• contraintes métier visibles
• erreurs explicites, pas masquées
• comportements limites testés

Ça pousse naturellement vers des abstractions alignées domaine. Un DDD léger, sans cérémonie. Pas des patterns génériques plaqués. Des mots qui correspondent au produit.

Standardiser les points de vérité :

• fonctions pures quand c’est possible
• modules cohérents
• frontières API stables
• responsabilités nettes

Et mesurer la qualité là où ça compte, sans dogme :

• couverture utile, pas des tests pour faire monter un pourcentage
• mutation testing ou contract tests selon le contexte
• SLOs et budgets d’erreur si vous avez une prod sérieuse

Principe simple : si l’IA écrit, l’humain impose le cadre narratif.

Un process simple qui marche (même si vous utilisez Copilot/ChatGPT tous les jours)

Je vois beaucoup d’équipes chercher un process « parfait ». Ça n’existe pas. Mais un process minimal, oui.

Étape 1 : design d’abord en 10 lignes

Avant de générer quoi que ce soit, écris 10 lignes. Pas un doc de 6 pages. Juste :

• objectif
• entrées / sorties
• invariants
• cas limites
• stratégie d’erreur

Tu peux le mettre dans la description du PR. Ou dans un commentaire en haut du fichier. Peu importe. Il faut que l’intention existe quelque part.

Étape 2 : générer petit

Demande à l’IA une fonction. Un module. Un composant. Pas une feature entière.

Plus le bloc est petit, plus la revue est possible. Plus l’intégration avec l’existant est maîtrisée. Et moins tu te retrouves avec une architecture fantôme.

Étape 3 : tests qui verrouillent l’intention

Je saute volontairement les étapes « évidentes » comme formatter et lint, parce que ça, tout le monde sait.

Ce qu’il faut en 2026, ce sont des tests qui racontent la règle. Table driven tests. Propriétés. Contrats. Et surtout, cas limites explicites. Trois cas limites valent parfois mieux que quinze tests superficiels.

Étape 4 : observabilité minimale

Si le comportement n’est pas évident, ajoute le minimum viable : logs structurés, un compteur, une trace. Pas pour faire joli. Pour que le futur toi puisse comprendre ce qui se passe sans ouvrir le cerveau de l’IA.

Livrable attendu : moins de lignes, plus de clarté, et un diff qui raconte une histoire.

Comment prompter une IA pour obtenir du code lisible (au lieu d’un patch opaque)

Le prompt est devenu une compétence. Pas parce qu’il faut être magicien. Parce qu’il faut donner le cadre.

Ce qui aide vraiment :

• contexte exact : conventions du repo, style de nommage, architecture, contraintes perf et sécu
• demander l’explication avant le code : plan en étapes, invariants, choix de design
• exiger des exemples : cas nominal + trois cas limites + stratégie de test
• demander une version simple d’abord, puis une version optimisée si nécessaire, avec benchmark

Un truc qui marche bien, c’est d’utiliser l’IA comme reviewer de ton propre code : tu lui colles ton patch et tu demandes : « qu’est ce qui est confus ici, et pourquoi ». Souvent, elle va pointer des zones que les humains n’osent pas critiquer en review parce que « on est pressés ».

Et oui, c’est un peu ironique. Mais ça marche.

Architecture : le meilleur antidote à l’illisibilité IA, c’est de réduire la surface de complexité

On peut parler de style pendant des heures. Mais l’architecture gagne toujours.

Si ton système permet à tout d’appeler tout, l’IA va générer des liens partout. Elle va prendre des raccourcis. Elle va importer ce qui marche. Elle va créer de la glue.

Donc il faut des frontières nettes :

• modules
• ports/adapters
• couches
• contrats d’interface

Limiter les zones grises. Encapsuler les parties sales, legacy, perf, intégrations, derrière des API stables.

Et documenter trois choses seulement, mais les documenter vraiment :

• un diagramme très simple
• les conventions
• les décisions clés, sous forme d’ADR courts

Résultat : même si l’IA génère du code, elle le fait dans des cases plus petites et contrôlées. Et quand une case est étrange, tu sais où regarder.

Mesurer l’illisibilité (sans tomber dans la religion des métriques)

Mesurer aide. Mesurer mal détruit tout. Donc on reste pragmatique.

Métriques utiles :

• complexité cyclomatique par module, pas juste par fonction
• churn, ce qui change tout le temps
• hotspots, les fichiers souvent modifiés
• taux d’incidents liés à une zone

Signaux humains :

• temps d’onboarding
• temps de review
• nombre de retours « je ne comprends pas »
• fréquence des rollbacks

Approche simple : cibler les hotspots, pas tout le codebase. Mettre un budget de complexité dans les zones critiques. Et surtout, boucle d’amélioration : chaque incident doit produire une simplification, pas seulement un correctif.

Sinon tu ajoutes des pansements sur une machine qui fuit.

Sécurité et conformité : quand l’illisibilité devient un risque (pas juste une gêne)

Code incompris = menaces non vues.

Injection. Auth mal gérée. Validation absente. Erreurs silencieuses. Et ça, l’IA peut en produire sans le vouloir, juste en recopiant des patterns moyens, ou en « simplifiant » des contrôles qui avaient une raison historique.

Autre danger : dépendances ajoutées par l’IA. Supply chain, surface d’attaque, licences, vulnérabilités. Une dépendance en plus, c’est rarement neutre.

Et puis il y a la traçabilité. En conformité, tu dois justifier des choix : crypto, stockage, données personnelles, rétention, consentement. Un patch opaque est un cauchemar d’audit.

Contrôles pratiques :

• SAST et DAST
• dependency scanning
• revues security focused sur les zones sensibles
• patterns interdits, clairement listés

Rappel utile, presque agressif : une IA ne porte pas l’astreinte. Votre équipe si.

Ce qui arrive ensuite : vers du code « post humain » et une nouvelle définition du métier

La tendance 2026 est claire : plus de code généré, plus de transformations automatiques, plus d’agents. On va avoir des systèmes où des parties entières sont reformatées, refactorées, ou migrées par des outils autonomes.

Donc le rôle humain se déplace.

Spécifier. Contraindre. Valider. Observer. Maintenir la cohérence du système.

La compétence clé devient design + debugging + architecture + tests. Plus que « taper du code ». Bien sûr, il faudra toujours savoir coder, sinon on ne sait pas juger. Mais la valeur n’est plus dans la vitesse de frappe.

Scénario réaliste : le code devient moins lisible localement, mais plus fiable globalement si les contrats sont solides. Types, invariants, tests, frontières, observabilité.

Position finale : le clean code n’est pas mort, il change de forme. Il devient un clean system. Un système compréhensible, pas juste des fonctions jolies.

Conclusion : garder le contrôle, l’IA doit accélérer la clarté, pas l’entropie

On peut résumer tout ça en trois idées.

1. L’IA optimise la production, pas la lisibilité.
2. La lisibilité est un contrat d’équipe, pas une préférence personnelle.
3. Architecture + intention + tests rendent le code maintenable, même si l’IA écrit la moitié.

Recommandation actionnable, simple, presque ennuyeuse : choisissez 2 ou 3 règles non négociables. Par exemple :

• design en 10 lignes avant génération
• fonctions petites et responsabilités nettes
• tests d’intention avec cas limites explicites

Et appliquez les dès le prochain PR. Pas « quand on aura le temps ».

Parce que la phrase qui devrait hanter toutes les équipes en 2026, c’est celle là : si personne ne peut relire, personne ne maîtrise. Et en prod, ce manque de maîtrise coûte toujours plus cher que quelques minutes de clarté en amont.

Questions fréquemment posées

Qu'est-ce que la "fin du clean code" évoquée en 2026 ?

La "fin du clean code" fait référence à un changement majeur où une part importante du code en production est générée ou modifiée par des intelligences artificielles (IA). Cela entraîne une production rapide de code qui fonctionne souvent, mais dont la compréhension globale et la clarté sont compromises, rendant le maintien et l'évolution plus difficiles.

Pourquoi le code produit par l'IA est-il souvent illisible malgré sa fonctionnalité ?

Le code généré par l'IA passe les tests et compile, mais il manque souvent d'une logique interne claire, d'une histoire cohérente et surtout du "pourquoi" derrière chaque décision. Cela crée des abstractions inutiles, des dépendances superflues et complique la maintenance car personne ne comprend vraiment les choix effectués.

Que signifie réellement "clean code" dans le contexte du développement logiciel ?

Le "clean code" désigne un code compréhensible, modifiable et testable. Il se caractérise par une intention claire, des noms explicites pour variables et fonctions, des fonctions courtes avec une responsabilité unique, une duplication maîtrisée et des tests fiables qui verrouillent l'intention. C'est un code que toute équipe peut reprendre aisément à tout moment.

Quel est le principal conflit entre optimisation locale et compréhension globale dans le développement actuel ?

L'optimisation locale vise à livrer rapidement un code qui passe les tests et ferme les tickets rapidement. En revanche, la compréhension globale concerne la maintenance, le débogage, la sécurisation et l'évolution du produit sur le long terme. L'IA excelle dans l'optimisation locale mais peine à garantir une compréhension globale solide.

Pourquoi le volume de code généré par IA change-t-il la donne pour le clean code ?

Le volume massif de code produit en quelques secondes par l'IA rend difficile le contrôle humain traditionnel de la qualité et de la lisibilité. Ce flux rapide engendre du code apparemment professionnel mais souvent incohérent avec les contraintes réelles de l'équipe, augmentant ainsi les risques lors des maintenances ou audits.

Comment maintenir un bon niveau de qualité dans un contexte où l'IA génère beaucoup de code ?

Il est crucial de comprendre pourquoi l'IA produit parfois du code illisible, d'accepter quand cela est acceptable et surtout d'adopter des pratiques permettant de reprendre le contrôle sans revenir aux méthodes archaïques. Cela inclut renforcer les revues humaines ciblées, améliorer les tests pour verrouiller l'intention et favoriser une documentation claire pour préserver la compréhension globale.