Formation · ta première application
Réparer en production sans tout casser.
Le site est en production (le site tel que tes visiteurs le voient, en ligne) , c'est-à-dire en ligne et devant de vrais visiteurs. Il y a un bug. Le réflexe est d'aller corriger directement sur le serveur. C'est le réflexe qui a mis un site hors ligne une minute trente et perdu sept fiches clients. Voilà l'ordre qui évite ça.
Reproduire chez toi avant de toucher au serveur, sauvegarder ce qui vit, une correction égale un enregistrement, déployer puis vérifier sur l'adresse publique et revenir en arrière quand ça empire.
Avant cette leçon Tu arrives ici directement ? Ces leçons préparent ce qu'elle suppose (le dossier, les outils installés) :
Ce que tu vas faire
Reproduire chez toi, avec le journal Sauvegarder ce qui vit, avant de toucher à quoi que ce soit Une correction, un enregistrement, puis déployer Vérifier sur l'adresse publique, pas dans ta tête Revenir en arrière quand ça empire
La leçon d'avant Les six endroits où ça casse, puis quoi taper quand ça casse →
Avant tout : le serveur n'est pas un endroit où l'on travaille
On travaille sur sa machine, dans le repo (le dossier d'un projet avec tout son historique, gardé par git. Il peut être privé ou public) . Le serveur reçoit le résultat. Le jour où tu modifies un fichier directement sur le serveur, tu as deux versions de ton application et la prochaine mise en ligne écrase la correction sans prévenir.
Reproduire chez toi Sauvegarder ce qui vit Corriger, enregistrer Déployer, vérifier Quatre temps, dans cet ordre. Le troisième est le seul qui touche au code. « C'est une petite correction, je la fais sur le serveur. » C'est toujours une petite correction. Sur Level Up, une a été faite comme ça le 31/08, jamais enregistrée et la mise en ligne suivante l'a effacée.
01
Reproduire chez toi, avec le journal
Récupère les lignes du journal au moment du bug, comme à la leçon précédente , puis reproduis le problème sur ta machine, avec l'application lancée en local. Tant que tu ne l'as pas vu chez toi, tu ne sais pas ce que tu corriges.
À écrire dans Claude Code Copier
Voilà les vingt dernières lignes du journal du serveur et ce que
l'utilisateur faisait. Trouve la cause dans le code, montre-moi la
ligne et reproduis le problème ici avant de proposer quoi que ce
soit. Ne corrige rien tant que tu ne l'as pas reproduit.
Bon à savoir
« Ne corrige rien tant que tu ne l'as pas reproduit » est la ligne qui évite les corrections au hasard. Une correction qui ne repose pas sur une reproduction en appelle une autre. Corriger le symptôme ne suffit pas : le 02/09 sur Build, un guide s'affichait sans porte de sortie, le symptôme était dans la page, la cause dans la façon de servir le fichier. La correction dans la page aurait tenu jusqu'à la prochaine génération.
Premium
La suite est dans la formation.
Tu viens de lire la première partie. Il en reste 4, avec les commandes exactes et les pièges à chaque étape :
Sauvegarder ce qui vit, avant de toucher à quoi que ce soit Une correction, un enregistrement, puis déployer Vérifier sur l'adresse publique, pas dans ta tête Revenir en arrière quand ça empire 29 € une seule fois, accès à vie. 29 € pour les 50 premiers membres, il en reste 35. Ensuite 49 €.
Prendre l'accès à vie