Une fonction bien typée. Un fichier découpé. Un linter qui passe au vert. Et pourtant : impossible de comprendre ce que ça fait. Difficile à tester. Inutile côté usage.
👉 Ce n’est pas rare. On croit écrire du clean code. Mais on produit juste du code joli, complexe, ou hors sol.
Aujourd’hui, le vrai sujet, ce n’est pas “est-ce que ce code est élégant ?” C’est : est-ce qu’on peut le reprendre dans 6 mois ? Est-ce qu’un dev comprend ce qu’il fait sans relire 4 fichiers ? Est-ce qu’on peut le tester sans douleur ? Est-ce qu’il raconte ce que le produit fait dans la vraie vie ?
Et ce n’est pas qu’un sujet de confort : 42 % du temps de développement est perdu à cause de dette technique évitable — du code pas clair, pas aligné, trop complexe. Autrement dit : du faux clean code.
Chez Yield, studio de développement, on travaille sur des produits qui vivent : MVP à faire évoluer, app métier en run, code repris par d’autres équipes. Ce qu’on cherche, ce n’est pas un style. C’est une base de code sobre, lisible, testable, utile — même quand l’équipe tourne, même quand la deadline presse.
Dans cet article, pas de dogme. Juste ce qu’on a retenu après des dizaines de projets, et ce qu’on applique (ou pas) quand on veut écrire du code propre qui tourne.
Clean Code : de quoi on parle vraiment ? (et ce que ça n’est pas)
Le Clean Code, ce n’est pas une “forme idéale” du code. Ce n’est pas “ce que dit Uncle Bob”. Ce n’est pas un débat sur les tabs ou les espaces. Et surtout : ce n’est pas un label que vous posez une fois le projet terminé.
👉 Ce qu’on appelle “code propre”, chez Yield, c’est un code :
- Lisible : un·e dev peut comprendre sans effort ce que ça fait — et pourquoi.
- Prévisible : pas de side effects planqués, pas de logique implicite.
- Sobre : pas de feature inutile, pas de surcouche décorative.
- Facile à tester : isolable, sans dépendances non maîtrisées.
- Ancré dans le métier : les noms, les structures, les cas reflètent la réalité produit.
Autrement dit : du code que l’on comprend, que l’on teste, que l’on fait évoluer — sans douleur.
Ce que ce n’est pas :
- Un code “joli” qui ne tourne pas.
- Une règle de style copiée-collée d’un blog US.
- Un fichier “bien organisé” mais incompréhensible.
- Une suringénierie pour appliquer un pattern à la mode.
💡Un bon Clean Code, ce n’est pas celui qui respecte toutes les règles. C’est celui qu’on peut faire évoluer sans trembler — et sans re-réexplorer tout le projet.
Nos 6 règles de Clean Code (et pourquoi on les applique — ou pas)
Selon McKinsey, 40 % du budget IT part chaque année en dette technique — souvent causée par du code sale laissé “temporairement”.
Nos règles ? Elles viennent du terrain. Parce qu’elles évitent les bugs, la dette, et les tickets qu’on ne veut pas relire à S+12.
Voici celles qu’on applique systématiquement — sauf quand on a une bonne raison de ne pas le faire.
1. Un fichier = une responsabilité claire
Pas de “utils.js” fourre-tout. Pas de “UserService” qui gère 12 use cases.
Chaque fichier a un rôle net. Et son nom l’explique sans commentaire.
Pourquoi ? Pour que n’importe quel dev puisse naviguer dans l’archi… sans poser 15 questions.
💡Un code propre contient jusqu’à 15x moins de bugs. Et corriger une erreur dans un fichier bien structuré prend 124 % de temps en moins.
2. Des noms qui disent ce que ça fait (vraiment)
parseData() ? Trop flou. parseOrderLinesFromCSV() ? Là, on comprend.
On nomme pour le prochain dev — pas pour le clavier.
Et quand on nomme bien, on commente moins.
Une bonne variable, c’est un mini brief à elle seule.
3. La logique métier, isolée et testable
Pas de logique métier dans un controller, un resolver, ou une vue React.
Ce qui concerne le produit est dans un use case. Point.
Et ce use case peut être testé sans contexte, sans setup tordu.
Sinon, vous testez du glue code — pas votre produit.
4. Le code doit lire comme une phrase, pas un puzzle
On vise du code “narratif” : facile à suivre, indentation légère, blocs courts.
Un fichier trop long ? Il planque sûrement deux intentions.
Un if imbriqué dans un switch dans un map ? Refacto immédiat.
Un bon code, c’est celui qu’un·e dev lit sans scroller frénétiquement.
5. Les cas d’erreur sont gérés dès le départ
Pas d’if (!user) return null planqué en bas.
On gère l’erreur en haut du fichier, explicitement.
On loggue ce qui compte. Et on ne laisse pas une exception planter une feature silencieusement.
Les apps qui plantent à cause d’un undefined, on a donné. Plus jamais.
6. Le code mort ou “temporaire” est supprimé (vraiment)
Un TODO vieux de 3 mois n’est pas temporaire.
Une branche non mergée depuis 6 semaines est un risque.
On supprime, on archive, ou on documente — mais on ne laisse pas traîner.
Du code mort, c’est une dette silencieuse. Jusqu’au jour où quelqu’un le fait tourner sans le vouloir.
Retour d’XP — dette technique subie, vélocité perdue
“Sur un projet SaaS relancé par Yield, l’équipe précédente avait empilé du JS sans règles claires. Chaque évolution cassait l’existant.
On a posé une convention stricte, des revues de code et un vrai plan de refacto. Résultat : vélocité multipliée par 1,6 dès le 3ᵉ sprint.”
— Clément, Lead Dev @Yield
💡 Et surtout : on n’applique jamais une règle “par principe”.
- Si un naming plus flou est plus rapide et lisible pour tous ? On le garde.
- Si un fichier un peu long rend la logique plus claire ? Tant mieux.
Clean Code, oui. Clean dogme, non.
4. Les dérives classiques qu’on voit encore
Le Clean Code, sur le papier, c’est carré. Mais dans la vraie vie de projet ?
Entre pression delivery, turnover, specs mouvantes… on a vu (et fait) des choses qu’on ne referait plus.
Voici 4 dérives fréquentes — à éviter si on veut un code qui tient la route à S+6.
Le Clean Code dogmatique (et lent)
"On ne merge pas tant que tout n’est pas parfait."
Résultat : des PR bloquées 10 jours, des refactos sans fin, et un projet qui stagne.
💥 Vu en audit : 5 features “presque finies”… mais aucune en prod. Parce qu’on optimisait pour l’élégance, pas pour l’usage.
👉 Un code clean qui n’est pas livré ne sert à personne.
Le Clean Code jeté à la poubelle au premier rush
Tout est propre… jusqu’à ce que le client dise “on doit livrer demain”.
Et là, plus de tests, plus d’abstractions, plus de lisibilité.
Une “urgence temporaire” qui devient le nouveau standard.
👉 Le piège : croire qu’on pourra “repasser derrière”. On ne repasse jamais.
Et à force de laisser la dette s’accumuler, on use les équipes : 58 % des développeurs prêts à quitter leur poste citent un code base “trop legacy” comme principal facteur de lassitude.
Le “refacto permanent” comme excuse
“Je reprends tout, c’est pas clean.”
En réalité : on évite de livrer, de se confronter à l’usage.
Refactorer sans objectif, c’est coder pour soi. Pas pour le produit.
👉 La bonne question : est-ce que ça améliore l’impact ou la maintenabilité ? Sinon, on ship.
L’archi overkill “pour être clean”
Des layers, des patterns, des dossiers… mais une feature qui met 8 fichiers à modifier.
Vu sur une app simple : CQRS, event sourcing, DDD — pour une todo-list interne.
👎 Résultat : ramp-up trop long, bugs planqués, devs juniors perdus.
👉 Clean = simple à lire, pas complexe à expliquer.
Ce qu’on retient : un bon Clean Code, c’est pas un trophée — c’est un accélérateur.
Une grille simple pour juger la propreté d’un code
Un code “clean”, ce n’est pas juste “joli”. C’est un code qu’un autre dev peut lire, modifier, tester — sans le casser.
Chez Yield, on ne parle pas de “code parfait”. On pose une grille simple, en 5 questions. Si vous répondez “non” à plus de 2… le code n’est pas propre.
✅ Est-ce que je comprends ce que fait ce fichier en 30 secondes ?
Pas besoin de lire tout le code ligne à ligne.
Une structure claire, un nom explicite, une logique apparente — c’est le minimum.
✅ Est-ce que je peux modifier un comportement métier… sans tout casser ?
Un code clean isole les responsabilités.
Je touche une règle RH ? Je ne dois pas aller bidouiller les appels API ou la base.
✅ Est-ce qu’un test pète quand je fais une bêtise ?
Un bon code s’appuie sur des tests simples, ciblés, rapides.
Pas 200 tests E2E. Juste de quoi couvrir les cas critiques… et éviter les surprises.
✅ Est-ce que j’ai confiance pour shipper ?
Si on croise les doigts à chaque mise en prod, ce n’est pas clean.
Un code propre permet de livrer sans sueur froide. Parce qu’on sait ce qu’on modifie.
✅ Est-ce qu’un dev qui débarque peut reprendre la main en 2 jours ?
Pas besoin de tuto YouTube ou de session de 4h.
Si le code est clair, testé, découpé : l’onboarding est rapide, et le projet respire.
💡 Cette grille, on l’utilise en audit, en peer review, en refacto. Pas pour juger. Pour savoir si le code est une aide… ou un futur frein.
Conclusion — Un bon Clean Code, c’est du code qui se rend invisible
Le vrai Clean Code, ce n’est pas un dogme. Ce n’est pas une religion d’espaces vs. tabulations, ni un concours de purisme.
C’est du code qui ne ralentit pas l’équipe. Un code qu’on lit sans effort, qu’on modifie sans crainte, qu’on fait évoluer sans dette cachée.
👉 Ce qu’on voit chez Yield : les projets qui tiennent, ce ne sont pas ceux avec “le plus beau code”. Ce sont ceux où le code aide le produit à avancer — pas l’inverse.
Alors oui, parfois on contourne. Parfois on coupe les coins ronds. Mais quand on le fait, on sait pourquoi. Et surtout : on sait revenir dessus.
Un bon Clean Code, ce n’est pas celui qu’on remarque. C’est celui qui laisse la place… au produit, à l’équipe, à l’impact.
