Réfléchir avant de coder avec l'IA : la règle des 55 minutes

Si vous avez une heure pour résoudre un problème, passez 55 minutes à réfléchir et 5 à coder. C'est une règle de style guide qui a des dizaines d'années, et l'IA vient de la rendre plus vraie, pas moins. Les 5 minutes de code sont devenues 30 secondes. Les 55 minutes de réflexion n'ont pas bougé d'une seconde, parce que ce sont les seules décisions que Claude ne peut pas prendre à votre place.

Le problème, quand la partie coûteuse devient gratuite, c'est que le ratio se casse tout seul. Avant, écrire du code prenait assez de temps pour vous forcer à réfléchir en amont. Personne n'attaquait un refacto de trois jours sans y penser deux fois. Aujourd'hui vous décrivez l'intention, vous obtenez l'implémentation, et rien dans la boucle ne vous oblige à vous arrêter. La friction qui jouait le rôle de garde-fou a disparu.

Ce que les 55 minutes contiennent vraiment

Ce n'est pas de la contemplation. C'est une liste courte de questions dont les réponses déterminent tout ce que l'IA va produire ensuite.

Quel est le vrai problème. Pas la feature demandée, le problème derrière. « Ajoute un filtre par statut » et « les utilisateurs n'arrivent pas à retrouver leurs dossiers en cours » n'appellent pas la même solution. La première est une instruction, la seconde est un problème. Vous obtenez de bien meilleurs résultats en donnant la seconde à Claude.

Quelle est la version simple. La solution la plus simple qui marche, pas la plus élégante. Un « good enough » à 80 % livré cette semaine bat un parfait livré un jour. Cette règle existait avant l'IA, mais elle compte plus maintenant : demandez une architecture, et l'IA vous livre des microservices pour zéro utilisateur, avec enthousiasme et sans jamais vous demander si c'était nécessaire.

Qu'est-ce que ça touche. Est-ce que le changement approche le modèle de données, la couche d'authentification, un contrat d'API que d'autres services consomment ? C'est exactement ce que sert le registre d'Expandable Core : savoir avant de prompter si vous êtes dans du code jetable ou dans du code sur lequel tout le reste va s'appuyer. La réponse change le niveau d'exigence, pas la vitesse.

Comment on saura que c'est fini. Un critère observable, écrit avant. Sans ça, la revue devient une discussion d'opinion et l'IA a toujours le dernier mot, parce qu'elle produit plus vite que vous ne relisez.

Quatre questions, rarement plus de vingt minutes en pratique sur une feature normale. Les 55 minutes sont une proportion, pas un chronomètre.

Simple ne veut pas dire bâclé

C'est la confusion qui coûte le plus cher. Le code bâclé crée de la dette et fait perdre la confiance de l'équipe. Le code simple reste propre, lisible, maintenable, et il est plus difficile à écrire que le code compliqué. C'est précisément à ça que servent les 55 minutes : trouver la version simple demande de comprendre le problème, alors que la version compliquée sort naturellement d'une compréhension partielle.

Un exemple concret côté React. useState et useEffect couvrent 95 % des besoins réels. Un state manager global, un contexte à trois niveaux, un hook custom qui abstrait quatre cas d'usage dont un seul existe : chacun de ces choix se justifie très bien dans le prompt qui l'a produit, et aucun ne se justifie six mois plus tard quand personne ne sait plus par où passe la donnée. Si un développeur junior fuit en lisant votre composant, le problème n'est pas le junior.

Où ça se matérialise dans un repo

Dans notre méthode, les 55 minutes ne sont pas un conseil moral, elles ont un endroit. Le sprint se planifie en début de semaine, 3 à 5 items, chacun taggé standard ou arch-review. Le tag est justement le résultat de la réflexion : vous avez déjà décidé si l'item touche le core avant d'écrire une ligne. Ensuite le call hebdo de 60 à 90 minutes sert aux arbitrages qui ne rentrent pas dans un ticket, et la revue de PR attrape ce qui est passé entre les mailles.

L'ordre compte. Réfléchir après avoir codé, c'est de la relecture, et la relecture ne rattrape jamais une mauvaise décision de départ. Elle la documente.

Le signe que le ratio s'est inversé

Il est facile à repérer dans une codebase. Quand on ouvre un repo où le code a été écrit plus vite qu'il n'a été pensé, on voit toujours les mêmes traces : plusieurs solutions au même problème coexistent parce que chacune est née d'un prompt différent, des abstractions dont un seul cas d'usage existe, et des fichiers dont personne ne sait dire pourquoi ils ont cette forme. Rien de tout ça ne casse. C'est du coût, pas des bugs, et c'est pour cette raison que ça survit longtemps.

Le correctif n'est pas de coder moins vite. C'est de remettre les 55 minutes devant les 30 secondes.

---

Vous voulez savoir ce que votre codebase a construit plus vite qu'elle ne l'a pensé ? On fait un Bunker Test gratuit : accès au repo, audit écrit, retour sous cinq jours ouvrés. Sans engagement.

Demander le Bunker Test