Le mal est fait, Pourquoi je laisse mes erreurs en vie

J’ai un réflexe quand je vois du code qui ne correspond pas à ce que j’avais en tête : corriger. Immédiatement. L’IA renomme une classe, choisit un design pattern différent, ou structure un fichier d’une façon que je n’aurais pas choisie. Et bam, mes doigts filent vers le prompt pour remettre les choses “en ordre”.

Sauf que depuis quelques mois, j’ai arrêté. Le mal est fait. Et c’est devenu ma méthode d’apprentissage la plus efficace.

L’erreur qui n’en était pas une

Je bosse tous les jours avec des agents IA. Ils génèrent du code, refactorisent, créent des features. Et régulièrement, ils font des choix différents des miens. Pas des bugs. Des choix. Une nomenclature que je n’utilise pas. Un pattern que je n’aurais pas sélectionné. Une structure de dossier légèrement différente.

Mon reflex naturel : corriger. Remettre mon standard. Rétablir l’ordre.

Mais un jour, je me suis arrêté. J’ai regardé le code en me disant : et si l’IA avait raison ? Ou plus subtil : et si son choix, même “faux” selon mes critères, ouvrait une porte que je n’aurais jamais envisagée ?

Le code fonctionne. Les tests passent. L’utilisateur ne voit rien. Qu’est-ce que je corrige exactement ?

La règle du prochain passage

Alors j’ai instauré une règle simple. Le mal est fait. Au lieu de corriger immédiatement, je vis avec. Jusqu’à la prochaine fois que je repasse par là, pour améliorer la feature, ajouter un truc, corriger un bug. Et là, j’en profite pour refacto.

Et trois choses se produisent :

Je comprends. En revenant sur le code avec du recul, je réalise que le choix de l’IA avait une logique que je n’avais pas captée. C’était une autre école de pensée, pas une erreur. J’aurais passé 30 min à “corriger” quelque chose qui n’avait pas besoin de l’être.

Ça m’inspire. Le pattern ou la nomenclature me fait découvrir une approche que je ne connaissais pas. L’erreur devient un cours gratuit.

Ou alors, et c’est ma situation préférée : le truc disparaît de lui-même. Je reviens sur la feature, je la modifie, et le code “bizarre” que j’aurais passé 30 min à corriger n’existe plus. J’ai refait la feature, le choix de l’IA a été remplacé naturellement. J’ai corrigé sans corriger. Zéro minute perdue.

Le ratio ? Une bonne partie se corrige toute seule au prochain passage. Le reste m’a appris quelque chose. Et si un truc me gêne toujours quand j’y retourne, je refacto à ce moment-là. Ça prend le même temps qu’avant, sauf que maintenant c’est au moment opportun, pas en mode panic.

Le coût caché du perfectionnisme

Mais il y a un argument encore plus fort que l’apprentissage. Le coût d’opportunité.

Quand je passe 1 heure à “corriger” un choix qui fonctionne, renommer des classes, restructurer des dossiers, aligner un pattern, cette heure est perdue. Le code fonctionnait déjà. L’utilisateur ne voit aucune différence. J’ai échangé 60 minutes de progression contre du confort esthétique.

Chaque minute passée à corriger un “mal” qui n’en est pas un, c’est une minute volée à quelque chose qui avance vraiment. Le mal est fait ? Tant mieux. Je passe à la suite.

Le perfectionnisme, c’est le luxe de ceux qui n’ont pas de deadline. Et en indie dev, on en a tous.

Ce que l’Islam m’a appris sur l’erreur

Ce mindset n’est pas venu de nulle part. En Islam, il y a ce principe : les épreuves et les erreurs ne sont pas que des punitions. Elles sont des mécanismes de croissance.

Le Quran dit :

“Il se peut que vous détestiez une chose alors qu’elle est un bien pour vous. Et il se peut que vous aimiez une chose alors qu’elle est mauvaise pour vous. Allah sait, et vous ne savez pas.” (Quran 2:216)

Ce n’est pas une punition à subir. C’est un mécanisme : la chose que tu rejettes instinctivement porte en elle quelque chose que tu ne vois pas encore. Ton aversion immédiate n’est pas un jugement fiable.

Quand l’IA fait un choix qui me dérange, mon aversion est instinctive. Mais je ne sais pas ce que ce choix va m’apprendre si je lui donne le temps de vivre. Laisser l’erreur en vie jusqu’au prochain passage, c’est exactement ça : accepter que mon jugement immédiat n’est pas complet.

Le parallèle entrepreneurial

Ce principe s’applique bien au-delà du code.

Combien de founders passent des semaines à polir un produit avant de le lancer ? La landing page n’est pas assez belle. Le copy n’est pas parfait. L’onboarding manque d’une animation. Alors ils attendent. Et pendant ce temps, le marché passe.

Shipper imparfait, c’est la même philosophie. Le mal est fait, la version 1.0 a des défauts. Mais elle est dans les mains des utilisateurs. Et les utilisateurs, contrairement à ton inner perfectionnist, te disent ce qui compte vraiment.

	Perfectionniste	Le mal est fait
Réaction	Corriger immédiatement	Observer jusqu’au prochain passage
Temps investi	30-60 min par “erreur”	0 min (ou refacto opportun)
Apprentissage	Confirme ce qu’on sait déjà	Découvre ce qu’on ignorait
Progression	Bloquée sur le détail	Avance sur l’essentiel
Résultat	Code “propre”	Vision élargie + temps gagné

En entrepreneurship comme en code, l’imperfection délibérée est un outil. Pas de la négligence, de la stratégie. Tu choisis tes batailles. Et celles que tu ignores t’apprennent plus que celles que tu gagnes.

Quand même corriger

Évidemment, cette règle a des limites. Je l’applique sur des petits changements : un style de nomenclature inhabituel, un design pattern alternatif, une structure de fichier différente, un naming de variable créatif.

Je ne l’applique pas sur des bugs qui impactent l’utilisateur, des failles de sécurité, des choix d’architecture majeurs, tout ce qui casse les tests.

Le “mal” que j’accepte de vivre est cosmétique ou philosophique. Pas structurel. Si la fondation craque, tu ne regardes pas la fissure jusqu’au prochain passage. Tu repares immédiatement.

Ce que j’en tire, à chaque fois

Chaque fois que j’ai laissé le “mal” vivre, j’en ai tiré quelque chose. Un nouveau pattern découvert. Une convention remise en question. Un angle que je n’aurais jamais exploré en mode “contrôle”.

L’IA n’est pas qu’un exécutant. C’est aussi un générateur de perspectives. Ses “erreurs” sont des suggestions déguisées. Et si tu corriges tout de suite, tu fermes la porte avant même de savoir ce qu’il y avait derrière.

Le mal est fait. Avance.

Et si au prochain passage, ça te gêne toujours ? Tu refacto à ce moment-là. Opportun, pas compulsif.

Si ce mindset te parle, abonne-toi à la newsletter. Je partage chaque semaine mes apprentissages de dev, d’IA et d’entrepreneuriat.