Peaufinage et préparation à la mise en ligne

Transformer du code qui marche en produit fini

⏱ Estim. ~9 min

01 · Lire

Ton jeu marche. Deux joueurs peuvent se trouver, jouer au tic-tac-toe en temps réel, gérer les déconnexions proprement. Mais ça marche et c'est fini, ce sont deux choses différentes.

Un projet fini a une UI propre, un README qui explique ce que c'est, pas de log de debug oubliés dans le code, un historique git correct. C'est la différence entre un side project et une pièce de portfolio — un truc que tu montrerais vraiment à un autre dev ou à un recruteur.

Cette leçon, c'est les derniers 10 % qui font briller les 90 % d'effort précédents.

Points clés

Du code qui marche et du code fini, ce n'est pas la même chose
Peaufiner, ça veut dire : UI propre, README, pas de log de debug, git correct
Le README est la première chose que quelqu'un voit en arrivant sur ton projet
C'est ce qui distingue un side project d'une pièce de portfolio

02 · Modèle de prompt

Demande à Claude d'améliorer le rendu visuel du jeu. Donne-lui un feedback précis sur ce qui paraît brut.

Améliore l'UI du tic-tac-toe. Exigences précises : (1) Ajoute une transition fluide quand un symbole apparaît dans une case. (2) Quand quelqu'un gagne, highlight les trois cases gagnantes avec une couleur de fond différente. (3) Ajoute un indicateur visuel pour savoir à qui c'est le tour — par exemple un effet de pulsation sur le texte de statut, ou la couleur du symbole du joueur courant. (4) Pendant la recherche d'adversaire, désactive le bouton Find Game et affiche un spinner de loading ou une animation. (5) Assure-toi que le jeu rend bien sur mobile — le plateau doit se redimensionner sur petit écran.

03 · Modèle de prompt

Tout projet a besoin d'un README. Demande à Claude d'en écrire un qui explique ce que c'est, comment le lancer, quelle techno est utilisée.

Aide-moi à créer un README.md pour mon projet tic-tac-toe. Il doit contenir : (1) Un titre et une intro en une phrase. (2) Une section 'How to Play' qui explique le déroulement (trouver un adversaire, jouer à tour de rôle, victoire / nul). (3) Une section 'Tech Stack' qui liste Node.js, Express, Socket.io, et HTML/CSS/JS pur. (4) Une section 'Run Locally' avec les étapes : clone, npm install, node server.js, ouvrir localhost:3000. (5) Une section 'How It Works' qui décrit brièvement l'architecture client-serveur et la communication WebSocket. Reste concis — personne ne lit un README de 500 lignes.

04 · Liste de vérification

Passe en revue cette checklist de préparation à la mise en ligne. Chaque point distingue un projet amateur d'un projet pro.

Tous les console.log de debug sont retirés (garde uniquement les log de connexion/déconnexion dans server.js)
L'UI du jeu a l'air propre — pas d'éléments qui se chevauchent, pas de mise en page cassée, pas de texte placeholder
Le README explique ce qu'est le projet et comment le lancer
Créé un fichier .gitignore qui exclut node_modules/
Pas d'URL localhost en dur dans le code — utilise des chemins relatifs pour que ça marche aussi en déploiement
Joué une partie complète après tous les changements de peaufinage

05 · Pratique réelle

Initialise un repository git, fais un premier commit, push sur GitHub. C'est le flow que tu as appris au Level 4.

06 · Quiz

Pourquoi faut-il retirer les console.log de debug avant la mise en ligne ?

Ils ralentissent significativement le serveur
Ils exposent l'état interne à quiconque ouvre DevTools, encombrent les logs du serveur et rendent les vrais problèmes plus durs à trouver
JavaScript interdit console.log en production
Socket.io entre en conflit avec console.log

07 · Compléter

Le fichier _____ explique aux autres devs ce qu'est ton projet, comment l'installer et comment le lancer.

Autres leçons de ce chapitre

⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.

※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.