Le mémo du praticien
Les checklists à rouvrir à chaque projet : avant, pendant, avant chaque mise en ligne.
Ce que vous allez apprendre
- Disposer d’une checklist pour chaque phase du projet
- Ancrer les réflexes vus dans la formation
- Savoir vérifier chaque point avant la mise en ligne
Vous voici au dernier module. Il ne contient pas de nouvelle théorie : il condense toute la formation en gestes concrets, sous forme de checklists à rouvrir à chaque projet. Gardez-les sous la main — en vibe coding, la discipline vaut plus que le talent.
Avant de commencer
- J’ai défini, par écrit, ce que fait le projet en une phrase.
- J’ai identifié qui va l’utiliser et les 3 à 5 fonctionnalités essentielles.
- J’ai choisi une stack adaptée (ni sous-, ni sur-dimensionnée) et documentée.
- J’ai initialisé Git dès le départ.
- J’ai créé un fichier CLAUDE.md (contexte, stack, conventions, règles, à éviter).
- J’ai défini une structure de dossiers claire.
- J’ai mis en place .gitignore (avec .env.local dedans) et .env.example.
- J’ai découpé le projet en étapes ordonnées, petites et vérifiables.
Pendant le développement
- Je demande une étape à la fois, jamais « tout le site ».
- Je donne du contexte précis à chaque demande (objectif, périmètre, existant à réutiliser).
- Je demande à l’IA d’expliquer son plan avant les modifications importantes.
- Je relis le diff de chaque changement avant de l’accepter.
- Je teste la nouveauté et ce qui n’était pas censé changer.
- Je commit après chaque étape qui fonctionne, avec un message clair.
- J’utilise une branche pour toute expérimentation risquée.
- Je vérifie les librairies inconnues (existent-elles vraiment ?).
- Je demande à l’IA de justifier ses choix sur les décisions importantes.
- Je garde CLAUDE.md et la documentation à jour.
Avant chaque commit
- J’ai relu la liste des changements (le diff) en entier.
- Aucun secret (clé API, mot de passe) ne s’y trouve.
- Le changement contient uniquement ce que j’ai demandé (pas de réécriture parasite).
- Le code fonctionne et je l’ai testé.
- Rien d’existant n’a été cassé (pas de régression).
- Le message de commit décrit ce qui a changé et pourquoi.
Avant chaque mise en production
- Le site est testé de bout en bout, y compris les cas d’erreur.
- Les variables d’environnement sont configurées côté hébergeur (Vercel…).
- Aucune variable secrète n’est exposée (attention au préfixe NEXT_PUBLIC_).
- Si base de données : le RLS / les accès sont configurés et vérifiés.
- Lighthouse est au vert (performance, accessibilité, bonnes pratiques, SEO).
- Le SEO de base est en place (titres, descriptions uniques, sitemap, robots).
- Le site est responsive (testé sur mobile et ordinateur).
- L’authentification (si présente) repose sur une solution éprouvée, pas maison.
- Un nom de domaine et le HTTPS sont prêts.
- Une sauvegarde des données est prévue.
Après la mise en ligne
- Je vérifie que le site fonctionne réellement en production (pas seulement en local).
- J’ai mis en place un monitoring minimal (le site est-il en ligne ? y a-t-il des erreurs ?).
- Les sauvegardes tournent automatiquement.
- Je planifie les mises à jour de dépendances (surtout de sécurité), testées sur une branche.
- Je développe chaque évolution à part (branche) avant de la mettre en ligne.
- Je surveille les retours réels des utilisateurs et les indicateurs (trafic, conversions).
- Je fais évoluer la documentation à mesure que le projet grandit.
Félicitations — et la suite
Vous avez terminé la formation. Récapitulons l’idée maîtresse : l’IA n’a pas rendu le développement facile, elle l’a rendu différent. Le code se produit en quelques secondes ; ce qui reste rare, c’est de cadrer, découper, juger la qualité, sécuriser et décider quoi construire. La compétence s’est déplacée de l’exécution vers la direction et la vérification — et vous savez désormais l’exercer.
Vous êtes maintenant capable de répondre à la question du Module 1 : « suis-je capable de vérifier que ce que l’IA produit est bon, sûr et durable ? »
Cette formation vous rend autonome sur l’essentiel. Elle vous a aussi montré, honnêtement, où se situent les limites de ce que l’on fait seul : l’architecture d’un projet sérieux, la sécurité d’une application qui manipule de vraies données, une stratégie SEO qui génère réellement des clients, un déploiement qui tient dans la durée. Ce sont des savoir-faire, pas des recettes.
À retenir
- La discipline vaut plus que le talent : les checklists la rendent systématique.
- Cocher une case suppose de savoir la vérifier.
- Un audit avant mise en production transforme l’espoir en certitude.
À vous de jouer
Créez votre checklist
- Reprenez les checklists du module et adaptez-les à votre projet.
- Gardez-les à portée de main pour chaque session de travail.
- Cochez « avant chaque commit » lors de votre prochaine modification.
Un projet à enjeux, ou un doute sur vos fondations ?
Cette formation vous rend autonome. Pour un audit, un cadrage ou un accompagnement sur mesure, l’équipe DJEZYS Digital peut prendre le relais.