Réinventer la roue en programmation : le meilleur exercice

« Ne réinvente pas la roue. » C'est probablement le conseil le plus répété du métier, et le moins nuancé. Réinventer la roue en programmation est une erreur en production, et l'un des exercices les plus rentables qui existent pour apprendre.

La nuance tient en une question : tu codes pour livrer, ou tu codes pour comprendre ? Ce n'est pas le même objectif, donc pas les mêmes règles. Et avec l'IA disponible comme prof particulier, l'exercice n'a jamais coûté aussi peu cher en temps.

« What I cannot create, I do not understand. » — Richard Feynman

Pourquoi la règle existe (et pourquoi elle est valide en prod)

Sur un projet pro, recoder une lib existante est presque toujours une mauvaise décision. Pas par principe, par arithmétique.

Une lib mature comme date-fns ou zod, c'est des années d'edge cases absorbés : fuseaux horaires, années bissextiles, encodages exotiques, inputs malveillants. Ta version maison couvrira le happy path et explosera sur le reste, en général un vendredi.

À ça s'ajoutent trois coûts invisibles :

• La maintenance : la lib est patchée par une communauté, ta roue maison est patchée par toi, à vie.
• La sécurité : recoder de la crypto ou de l'auth soi-même, c'est le exemple canonique de ce qu'il ne faut jamais faire en prod.
• Le bus factor : le dev qui reprend ton projet connaît pinia, il ne connaît pas ton state manager artisanal de 400 lignes.

Donc oui, sur Hadalia ou n'importe quel produit qui a des clients, la règle s'applique sans discussion. Le débat n'est pas là.

Réinventer la roue pour apprendre : pourquoi ça marche

Le problème du conseil "ne réinvente pas la roue", c'est qu'appliqué partout, il fabrique des devs qui assemblent des boîtes noires sans savoir ce qu'il y a dedans. Ça marche, jusqu'au jour où ça ne marche plus.

Joel Spolsky appelait ça la loi des abstractions qui fuient : toute abstraction non triviale finit par laisser passer un détail de l'étage du dessous. Ton ORM génère une requête catastrophique, ton framework de reactivity ne détecte pas une mutation, ton client HTTP retry silencieusement. Ce jour-là, soit tu comprends la couche du dessous, soit tu copies-colles des issues GitHub en priant.

Recoder la roue, c'est exactement ça : descendre d'un étage volontairement, un week-end, pour que la fuite ne te surprenne plus.

Concrètement, l'exercice t'apprend trois choses qu'aucun tuto ne donne :

1. Les décisions de design. En recodant un routeur HTTP, tu découvres pourquoi l'ordre des routes compte, pourquoi les params dynamiques sont matchés après les routes statiques, pourquoi le trailing slash est un débat sans fin. Tu ne lis pas la décision, tu la prends.
2. Le vrai coût des features. Ajouter le support des wildcards à ton routeur te prend une soirée. Tu comprends soudain pourquoi la lib que tu utilises a refusé cette feature pendant trois ans dans les issues.
3. Le vocabulaire du domaine. Après avoir écrit un parseur JSON, les mots tokenizer, lexer, AST ne sont plus du jargon, ce sont des morceaux de ton code.

Quoi recoder (et quoi laisser tranquille)

Toutes les roues ne se valent pas. Le bon candidat est un truc que tu utilises tous les jours sans savoir comment il marche, avec un cœur simple et des edge cases intéressants.

À l'inverse, certains sujets sont de mauvais exercices : trop gros pour un side project (un moteur de rendu navigateur), ou dangereux à mal comprendre (une lib de crypto, où même l'exercice pédagogique t'apprend surtout que tu ne dois pas le faire).

La règle de sélection : si tu peux décrire le cœur du truc en une phrase mais pas expliquer comment il tient debout, c'est un bon candidat.

L'IA change complètement l'économie de l'exercice

C'est le point qui rend le sujet actuel. Avant, réinventer la roue en solo, c'était des heures bloqué sur Stack Overflow à chercher pourquoi ton implémentation diverge. Beaucoup abandonnaient là.

Avec Claude Code ou Cursor à côté, l'exercice devient un cours particulier :

• Tu bloques sur le dependency tracking de ta reactivity ? Tu demandes pourquoi Vue utilise des WeakMap et pas des Map, et tu as une explication contextualisée sur ton propre code.
• Tu veux vérifier ta compréhension ? Tu demandes à l'IA de te poser des questions sur ton implémentation au lieu de lui demander des réponses.
• Tu as fini ? Tu lui demandes de comparer ton code avec la vraie implémentation de la lib et de lister ce que tu as raté. C'est un code review gratuit contre l'état de l'art.

Le point clé : l'IA lit le source des vraies libs avec toi. Ouvrir le repo de @vue/reactivity seul, c'est intimidant. Le faire avec un agent qui t'explique fichier par fichier pourquoi ce code existe, c'est un autre sport.

Le piège : laisser l'IA écrire la roue à ta place

Attention quand même, il y a une façon de rater complètement l'exercice : prompter "code-moi un parseur JSON" et regarder le résultat défiler. Tu obtiens une roue, tu n'obtiens aucune compréhension. C'est le pire des deux mondes, du code que tu n'utiliseras pas et que tu n'as pas compris.

La bonne configuration, c'est l'inverse du workflow de prod. En prod, l'IA code et tu review. En apprentissage, tu codes et l'IA review. Si tu inverses les rôles, tu as juste regardé quelqu'un d'autre faire tes gammes.

Concrètement, tu en fais quoi

Un protocole simple pour un week-end :

1. Choisis une roue dans le tableau au-dessus, une seule.
2. Écris d'abord, sans IA, ce que tu penses savoir de son fonctionnement. Dix lignes dans un fichier NOTES.md. C'est ta baseline.
3. Code sans dépendances externes. Zéro npm install, c'est la contrainte qui force la compréhension.
4. Utilise l'IA uniquement en mode question : "pourquoi", "compare", "qu'est-ce que je rate". Jamais "écris".
5. À la fin, confronte ton code au source de la vraie lib, avec l'IA comme guide de lecture.
6. Relis ton NOTES.md du début. L'écart entre les deux versions, c'est exactement ce que tu as appris.

Pour cadrer l'IA en mode tuteur plutôt qu'en mode autocomplete, un system prompt du genre :

Tu es mon tuteur sur ce projet d'apprentissage.
Règles :
- Ne me donne jamais de code complet.
- Réponds à mes questions par des explications et des contre-questions.
- Si mon approche a un problème, dis-moi où chercher, pas quoi écrire.

Timeboxe à un week-end. L'objectif n'est pas de finir une lib publiable, c'est de comprendre. Une roue à moitié terminée mais comprise vaut plus qu'une roue complète générée.

FAQ

Faut-il réinventer la roue en programmation ?

En production, non : les libs matures ont absorbé des années d'edge cases et de patchs de sécurité que ta version maison n'aura jamais. En apprentissage, oui : recoder un outil que tu utilises est le moyen le plus direct de comprendre ses abstractions et ses limites.

Quel projet coder from scratch pour progresser ?

Un parseur JSON, un routeur HTTP, un mini système de reactivity ou un rate limiter sont des classiques : le cœur tient en un week-end et les edge cases sont formateurs. Évite ce qui est trop gros (moteur de rendu) ou dangereux à mal comprendre (crypto).

L'IA rend-elle l'exercice inutile ?

Non, elle le rend plus rentable, à condition d'inverser les rôles : tu codes, l'IA explique et review. Si tu laisses l'agent générer la roue, tu n'apprends rien, tu as juste regardé.

La roue existe déjà, c'est vrai. Mais personne n'a jamais compris un moteur en lisant la fiche technique.