Planifier avant de construire
Découper un vrai projet en morceaux avant d'écrire une ligne de code
⏱ Estim. ~7 min
01 · Lire
La plus grosse erreur des débutants face à un nouveau projet : ils ouvrent le terminal et se mettent à coder.
Les pros font l'inverse. Ils planifient d'abord — même si le plan est brouillon et changera plus tard. Planifier, ça veut dire réfléchir à ce que tu construis avant de demander à Claude de le construire.
C'est encore plus important quand tu bosses avec une IA. Un plan clair produit un output Claude Code bien meilleur. « Construis-moi un jeu » te donne un truc générique. « Construis un serveur qui gère des salles de jeu, fait le matchmaking des joueurs en attente et valide les coups » te donne exactement ce que tu voulais.
Points clés
- Planifie avant de coder — même un plan brouillon aide
- Un plan clair produit du meilleur code généré par l'IA
- Découpe le projet en couches : serveur, client, communication
- Tu vas construire un tic-tac-toe multijoueur temps réel avec matchmaking en ligne
02 · Lire
Voici ce qu'on va construire : un tic-tac-toe multijoueur temps réel. Deux inconnus ouvrent la même URL, sont appariés, jouent en temps réel. Un joueur joue un coup, ça apparaît instantanément sur l'écran de l'autre.
Le jeu fini a trois couches : Serveur — l'autorité. Il gère le plateau, applique les règles, fait le matchmaking, détecte les victoires. Le serveur a toujours raison. Les joueurs ne peuvent pas tricher parce que le serveur valide chaque coup.
Client — l'interface. La page HTML que les joueurs voient dans le navigateur. Elle affiche le plateau, capte les clics, montre les updates du serveur.
Communication — le pont. Les événements WebSocket qui circulent entre le client et le serveur. Quand un joueur clique une case, le client envoie l'événement 'make-move'. Quand le serveur valide, il envoie 'move-made' aux deux joueurs.
Points clés
- Le serveur possède tout l'état du jeu — ne fais jamais confiance au client
- Le client affiche l'UI et capte les actions de l'utilisateur
- Les événements WebSocket sont la couche de communication entre les deux
- Le serveur valide chaque coup — anti-triche
03 · Étape par étape
Parcours les trois couches de toute app temps réel et ce que chacune fait dans notre tic-tac-toe.
1. Serveur : l'arbitre
Gère le plateau (grille 3x3), suit à qui le tour, valide les coups (case vide ? c'est ton tour ?), détecte victoires et matchs nuls, apparie les joueurs en attente dans des salles de jeu.
2. Client : l'écran
Affiche le plateau 3x3 sous forme de cases cliquables. Affiche les messages de statut ('En attente de l'adversaire...', 'À ton tour', 'Tu as gagné !'). Envoie des événements quand le joueur clique. Met à jour le plateau quand le serveur envoie des changements.
3. Communication : les événements
Le contrat entre client et serveur. Le joueur clique 'Find Game' — le client emit 'find-game'. Le serveur apparie deux joueurs — emit 'game-start' aux deux. Le joueur clique une case — le client emit 'make-move'. Le serveur valide — emit 'move-made' aux deux. La partie se termine — le serveur emit 'game-over'.
4. Matchmaking : le lobby
Une file d'attente côté serveur. Tu cliques 'Find Game', tu rejoins la file. Quand un deuxième joueur arrive, le serveur vous met en sale, attribue X et O au hasard, lance la partie.
5. Gestion des déconnexions : nettoyage propre
Si un joueur ferme son navigateur en pleine partie, le serveur détecte la déconnexion et prévient l'adversaire. S'il se déconnecte dans la file, le serveur le retire. Pas de parties zombies, pas de joueurs bloqués.
04 · Exemple de code
Voici le flux d'événements entre les deux joueurs et le serveur. Étudie-le — c'est le plan qu'on va implémenter dans les 7 leçons suivantes.
Flux d'événements : du matchmaking à la fin de partie
Player A Server Player B
| | |
|--- find-game ---->| |
|<--- waiting ------| |
| |<--- find-game -----|
|<-- game-start ----|--- game-start ---->|
| (you are X) | (you are O) |
| | |
|--- make-move ---->| | (A clicks cell 4)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| |<--- make-move -----| (B clicks cell 0)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| ...more moves... |
| | |
|<-- game-over -----|--- game-over ----->| (X wins!)
| (you won!) | (you lost) |
Remarque que chaque action passe par le serveur. Le joueur A ne parle jamais directement au joueur B. Le serveur reçoit le coup, le valide, diffuse le résultat aux deux joueurs. C'est l'architecture standard de tout jeu multijoueur.
05 · Liste de vérification
Avant de coder, vérifie que tu comprends le plan. Coche chaque concept quand tu es à l'aise avec.
- Le serveur détient tout l'état du jeu — plateau, à qui le tour, qui est X et qui est O
- Le client n'envoie que des événements (comme 'make-move') et affiche ce que le serveur lui dit
- Le matchmaking apparie deux joueurs en attente dans une salle de jeu
- Chaque coup est validé par le serveur avant d'être montré aux joueurs
- Si un joueur se déconnecte, le serveur nettoie et prévient l'adversaire
06 · Quiz
Pourquoi le serveur doit valider les coups au lieu de faire confiance au client ?
- La validation côté serveur est plus rapide que côté client
- Le client n'a pas accès à l'état du jeu
- Les joueurs peuvent modifier le code client pour tricher — le serveur est la seule autorité fiable
- WebSocket exige une validation côté serveur
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.