Nommer précis, early returns, fonctions courtes, daily refactor, pair-programming et évaluation par projet : ce que neuf mois à former 18 apprenants m'ont appris sur mon propre code.
Neuf mois à enseigner le développement fullstack à des apprenants en reconversion. Ce que j'ai appris sur le clean code, la dette technique et la pédagogie réelle.
De juillet 2024 à mars 2025, j'ai formé une promotion de 18 apprenants à l'IAFP La Pyramide (institut de formation modulaire accrédité au Togo). Programme : fondamentaux algorithmiques, JavaScript, TypeScript, Dart, Next.js, Flutter, React Native, Git. Objectif : qu'ils soient capables de livrer des applications fullstack autonomes à la sortie.
Taux de certification final : 85 %. Mais ce n'est pas ce qui m'a marqué le plus. Ce qui m'a marqué, c'est ce que j'ai appris moi sur le code et la dette technique en regardant des débutants l'écrire pour la première fois.
Premier choc : ce que je croyais "instinctif" dans mon code ne l'est pas. Quand je nomme une fonction fetchUserPortfolio, je sais pourquoi je n'ai pas mis getData. Mais cette connaissance est implicite. Un apprenant écrit getData et ne voit pas le problème — parce que ça marche.
Le clean code n'est pas un ensemble de règles esthétiques. C'est un contrat de communication entre le code et le futur lecteur (qui sera vous dans 6 mois). Ce contrat n'est pas inné. Il s'apprend en regardant le code des autres se casser en production.
J'ai dû verbaliser des choses que je n'avais jamais expliquées : pourquoi un nom de variable de 3 lettres dans une fonction de 80 lignes est un drame, pourquoi un if imbriqué à 5 niveaux est une dette, pourquoi un commentaire qui paraphrase le code est du bruit.
Première chose que j'ai martelée : le code est lu 10 fois plus qu'il est écrit. Pas par marketing — par calcul mathématique.
Un projet vit 2 à 5 ans en production. Pendant ce temps, vous le relisez :
Si écrire une fonction prend 10 minutes mais la rendre lisible en prend 12, le surcoût initial est récupéré dès le premier débogage.
J'ai forcé cette discipline avec une règle pratique : chaque PR doit pouvoir être expliquée à voix haute en 2 minutes. Si l'apprenant n'arrivait pas, c'est que le code était trop dense, trop confus, ou faisait trop de choses. On refactorait avant de merger.
data, info, result, temp, val. Symptômes de "je sais pas comment l'appeler, mais ça marche".
Correction : toujours nommer par ce que c'est, pas par ce que c'est techniquement. Pas array, mais activeUsers. Pas fn, mais computeMonthlyRevenue.
| 1 | // ❌ Vague |
| 2 | function getData(id: string) { |
| 3 | const res = await fetch(`/api/users/${id}`); |
| 4 | const data = await res.json(); |
| 5 | return data; |
| 6 | } |
| 7 | |
| 8 | // ✅ Précis |
| 9 | async function fetchUserProfile(userId: string): Promise<UserProfile> { |
| 10 | const response = await fetch(`/api/users/${userId}`); |
| 11 | return response.json(); |
| 12 | } |
J'ai vu des fonctions de 200 lignes qui validaient, fetchaient, transformaient, enregistraient et notifiaient. Toutes en une seule.
Règle : une fonction = un verbe = une responsabilité. Si le nom contient un "et", c'est suspect. Si on doit faire défiler pour voir la fin, c'est cassé.
Limite pratique enseignée : 30 lignes pour une fonction, refactor obligatoire à 50. Pas une règle dogmatique, un signal d'alerte.
if qui pyramide| 1 | // ❌ Pyramide |
| 2 | function processOrder(order) { |
| 3 | if (order) { |
| 4 | if (order.items.length > 0) { |
| 5 | if (order.payment) { |
| 6 | if (order.payment.status === "valid") { |
| 7 | // ... 40 lignes de logique |
| 8 | } |
| 9 | } |
| 10 | } |
| 11 | } |
| 12 | } |
| 13 | |
| 14 | // ✅ Early returns |
| 15 | function processOrder(order: Order): OrderResult { |
| 16 | if (!order) return { ok: false, reason: "no_order" }; |
| 17 | if (order.items.length === 0) return { ok: false, reason: "empty_cart" }; |
| 18 | if (!order.payment) return { ok: false, reason: "no_payment" }; |
| 19 | if (order.payment.status !== "valid") return { ok: false, reason: "invalid_payment" }; |
| 20 | |
| 21 | // logique principale, à plat |
| 22 | } |
La pyramide de if est un sucre lent qui s'accumule. Les early returns sortent le code de la pyramide. Toujours rejeter d'abord, traiter ensuite.
| 1 | // ❌ Bruit |
| 2 | // On incrémente le compteur |
| 3 | counter += 1; |
| 4 | |
| 5 | // ❌ Faux ami : ce commentaire devient faux quand le code change |
| 6 | // Récupère les utilisateurs actifs des 30 derniers jours |
| 7 | const users = await User.findAll({ where: { lastSeen: { [Op.gt]: thirtyDaysAgo } } }); |
| 8 | |
| 9 | // ✅ Commente le pourquoi, pas le quoi |
| 10 | // Cache 5 min pour réduire la charge sur la base — voir incident 2025-01-14 |
| 11 | const users = await User.findAll({ ... }); |
La règle enseignée : le commentaire doit expliquer ce que le code ne peut pas dire. Pas paraphraser. Si le code est confus au point qu'il demande un commentaire pour être compris, refactor d'abord, commente ensuite.
| 1 | // ❌ Quel est ce true ? Et ce 30 ? |
| 2 | createUser("Alice", "alice@test.com", true, 30); |
| 3 | |
| 4 | // ✅ Objet avec champs explicites |
| 5 | createUser({ |
| 6 | name: "Alice", |
| 7 | email: "alice@test.com", |
| 8 | isAdmin: true, |
| 9 | ageYears: 30, |
| 10 | }); |
Règle pratique : 3 paramètres maximum, au-delà on prend un objet. Le call-site devient auto-documenté.
90 % des apprenants arrivaient avec un compte GitHub vide ou un seul commit "Initial commit". J'ai imposé tôt :
main directadd login form, pas added login form)Le but n'était pas la perfection git. Le but était d'ancrer la culture du code public. Une fois qu'ils ont compris que leur code serait lu, les habitudes ont basculé.
Une heure par jour de pair-programming forcé (driver/navigator). Au début, douloureux. Après 2 semaines, transformation visible :
C'est aussi le moment où j'ai vu naître les meilleurs développeurs : pas forcément ceux qui codaient le plus vite, mais ceux qui posaient les meilleures questions.
J'ai supprimé les QCM théoriques. À la place : un projet de fin de module, défendu à l'oral devant la promotion.
Critères :
Aucun bonus pour la "performance pure" ou les "techniques avancées". Juste la livrable et sa qualité de communication.
Ce barème a tué l'apprentissage par cœur et forcé la compréhension. Les meilleurs apprenants n'étaient pas ceux qui avaient retenu le plus de syntaxe, mais ceux qui livraient le code le plus clair.
Le plus étonnant : les débutants voient la dette technique mieux qu'on ne le croit. Ils ne savent juste pas la nommer.
Quand un apprenant arrive et dit "je comprends pas mon propre code d'hier", c'est qu'il a écrit de la dette. Quand il dit "ça marche mais je sais pas pourquoi", c'est un signal qu'il faut refactor avant de continuer.
J'ai institutionnalisé le "daily refactor" : tous les matins, 30 minutes, chaque apprenant relit le code de la veille et le rend meilleur. Cette pratique seule a changé le niveau moyen de la promotion en 6 semaines.
Trois choses que j'ai changées dans mon code après cette mission :
| Piège | Symptôme | Correction |
|---|---|---|
| Théorie sans pratique | Apprenants qui récitent sans comprendre | 70 % pratique minimum |
| Frameworks sans fondations | Bloqués dès que le framework change | Commencer par JS pur, ajouter ensuite |
| Évaluation théorique | Apprentissage par cœur | Évaluation par projet livré |
| Pas de Git tôt | Habitudes solo dangereuses | Branches dès le jour 3 |
| Tutos copiés sans compréhension | Bloqués hors du chemin balisé | Forcer à débugger seul avant aide |
| Pas de pair-programming | Solitude + dette accumulée | Sessions quotidiennes forcées |
Enseigner m'a rendu meilleur développeur, plus que n'importe quelle formation suivie. Verbaliser des choix tacites, expliquer pourquoi un nom est mauvais, regarder la dette se créer en temps réel — tout ça change la manière dont vous écrivez votre propre code.
Si vous avez l'occasion de former, prenez-la. Pas pour la rémunération (souvent faible), pas pour le statut (souvent ignoré). Pour ce que ça vous apprend sur votre propre métier.
Le clean code n'est pas une exigence du code. C'est une exigence du futur lecteur. Et le futur lecteur, c'est vous.
Si ce sujet ressemble à un problème réel dans votre produit, je peux intervenir sur le diagnostic, l'architecture, le backend, l'interface et les automatisations qui rendent une plateforme exploitable.
Réactions des lecteurs
Aucun commentaire pour l'instant
Soyez le premier à réagir à cet article.