Clean Code à l'ère de l'IA : quels principes demeurent et lesquels se déplacent

Clean Code désigne un code source compréhensible à la lecture : des noms parlants, de petites unités, des responsabilités claires, peu de répétitions. Avec l'assistance de l'IA, cet objectif gagne en importance au lieu d'en perdre — car le code que personne ne lit parce qu'il a été généré est précisément celui qui doit être compréhensible dès que quelque chose tourne mal pour la première fois.

Qu'est-ce que le Clean Code ?

La notion a été popularisée par le livre éponyme de Robert C. Martin et décrit une attitude, pas une norme : le code est lu bien plus souvent qu'il n'est écrit, la lisibilité est donc la qualité la plus importante après l'exactitude.

Il en découle les règles connues — des noms explicites, de petites fonctions avec une seule tâche, pas de commentaires superflus, pas de répétition, traiter les erreurs au lieu de les avaler. Aucune n'est mesurable, et c'est l'objection habituelle. L'objection passe à côté de l'objet : ce sont des heuristiques pour une question à laquelle on ne peut répondre qu'en lisant.

Les règles du Clean Code s'appliquent-elles encore quand l'IA écrit le code ?

Elles s'appliquent davantage, parce que le destinataire a changé. Autrefois, on écrivait lisiblement pour le collègue. Aujourd'hui, on écrit lisiblement pour trois lecteurs, dont deux sont nouveaux.

• L'humain en revue de code. Il a moins de temps par ligne, parce que davantage de lignes arrivent. Un code peu clair n'est pas examiné plus longtemps, il est validé d'un geste.
• Le modèle lors de la prochaine modification. Un modèle de langage lit votre existant comme contexte et poursuit ce qu'il y trouve. Une structure claire et des noms univoques agissent donc doublement : sur l'humain et sur la prochaine génération.
• L'humain en cas d'incident. À trois heures du matin, sans accès à l'historique de chat dans lequel le code a été produit.

Quels principes gagnent en importance ?

Quatre, et les quatre répondent à des schémas documentés du code généré.

• Pas de répétition. Le principe le plus important du moment, car les doublons augmentent de façon mesurable depuis l'arrivée de l'assistance par IA (les chiffres à ce sujet). Là où l'on duplique sans que personne ne s'en aperçoive, la règle n'est plus une question de style.
• Explicite plutôt qu'implicite. Un modèle devine en cas d'ambiguïté. Des types univoques, des signatures claires et des constantes nommées réduisent ce sur quoi l'on peut deviner.
• Traiter les erreurs, ne pas les avaler. Le bloc catch vide est une infraction classique au Clean Code et, depuis 2025, une catégorie OWASP à part entière (A10).
• Petites unités vérifiables. Ce qui se lit d'un seul trait est réellement lu en revue. Une fonction de 400 lignes est survolée, indépendamment du soin du relecteur.

Quels principes se déplacent ?

Trois, pour lesquels l'ancienne justification ne tient plus — même si la règle demeure.

• Commentaires. L'ancienne règle disait : un bon code n'a pas besoin de commentaires. Cela reste vrai pour le quoi. Pour le pourquoi, le poids s'est déplacé : avec du code généré, la personne qui pourrait expliquer la décision fait défaut. Une phrase expliquant pourquoi cette solution a été choisie est aujourd'hui plus précieuse qu'avant.
• Fonctions utilitaires écrites soi-même. Autrefois : ne pas construire soi-même ce qui existe en bibliothèque. Aujourd'hui s'ajoute un arbitrage, car chaque dépendance supplémentaire est une décision de chaîne d'approvisionnement — depuis 2025 catégorie OWASP à part entière (A03). Intégrer un paquet pour vingt lignes n'est plus automatiquement le choix le plus économe.
• Généralisation prématurée. La règle « ne construisez pas pour des cas qui n'existent pas » reste juste, mais elle est plus souvent violée : les modèles intègrent volontiers des commutateurs de configuration et des couches d'abstraction par anticipation.

Comment faire appliquer le Clean Code quand beaucoup de code est généré ?

Pas par des formations, mais aux trois endroits où le code naît.

• Avant la génération : consigner les conventions du projet là où l'outil les lit. Schémas de nommage, arborescence, gestion des erreurs, fonctions utilitaires existantes. Un modèle respecte les conventions qu'il connaît.
• Après la génération : ce qui est vérifiable par machine est vérifié par machine — formatage, complexité, doublons, imports morts. Voir l'analyse statique de code.
• En revue : poser précisément les questions auxquelles aucun outil ne répond. Cela existe-t-il déjà ? Le nom est-il juste ? La décision est-elle compréhensible ? Voir la revue de code pour le code IA.

Questions fréquentes sur le Clean Code

Le Clean Code n'est-il pas une affaire de goût ?

Les règles concrètes en partie, oui — longueur de ligne, placement des accolades, conventions de nommage. Pas le fond : savoir si une fonction peut se décrire en une phrase sans « et » se détermine sans jugement de goût, et cette seule question couvre une grande partie des règles.

L'IA écrit-elle du code propre ?

Formellement souvent oui : nommage cohérent, structure conventionnelle, commentaires présents. Structurellement souvent non, car le modèle manque de vue d'ensemble — il duplique ce qu'il ne connaît pas et généralise ce que personne n'a demandé. Propre dans le détail, pas propre dans l'ensemble.

Le livre de Robert C. Martin vaut-il encore la peine ?

Comme école de pensée, oui ; certains exemples ont vieilli et certaines parties font l'objet de discussions techniques controversées. Si l'on ne devait retenir qu'une chose, ce devrait être la question de savoir combien de fois ce code sera lu.

Comment convaincre une équipe qui veut livrer vite ?

Pas par l'esthétique, mais par le temps de revue. Un code peu clair coûte du temps à nouveau à chaque revue, et avec un volume de code croissant, c'est cela qui devient le goulot d'étranglement — pas l'écriture.

Les conventions n'agissent que si l'outil les connaît avant d'écrire. Code Guardian fonctionne précisément ainsi : d'abord regarder ce qui existe déjà dans le projet, puis construire — et ensuite un audit qui nomme la redondance dans le diff.

Sources

• Robert C. Martin, Clean Code (origine de la notion et du recueil de règles).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.
• OWASP Top 10:2025, catégories A03 et A10.

Au 27 juillet 2026. Classement technique général.