Formation gratuite
Le cahier des charges, les demandes exactes, le code, la base de données, l'écran patron et l'e-mail. Tu suis dans l'ordre, et à la fin tu as une vraie application qui tourne sur ta machine — celle de la vidéo, pas une maquette.
| Quoi | Pourquoi | Prix |
|---|---|---|
| Claude Code | l'outil qui écrit le code. Tu diriges, il produit. | ~20 €/mois |
| Node.js | fait tourner l'application sur ta machine. Version 22 ou plus récente — prends la « LTS » sur nodejs.org. | gratuit |
| Un éditeur | pour regarder les fichiers. VS Code fait l'affaire. | gratuit |
| Hébergement | pour le volume d'un salon, sur Cloudflare. | 0 € |
Pas de compte à créer pour cette étape : tout tourne en local. L'hébergement et le nom de domaine arrivent à la mise en ligne, et c'est l'objet de la vidéo suivante.
Il tient en quatre parties, et aucune n'est décorative : ce que tu veux obtenir, ce qu'il doit savoir pour ne pas deviner, ce que tu t'interdis, et dans quel ordre on avance. Ouvre Claude Code dans un dossier vide et donne-lui ce texte, tel quel.
Je veux construire une application de prise de rendez-vous pour un salon de coiffure qui s'appelle Lumière. Voici le cahier des charges complet. Lis-le en entier avant d'écrire quoi que ce soit.
Ce que je veux obtenir — six règles.
Ce que tu dois savoir pour ne pas deviner.
Ce que je m'interdis.
Dans quel ordre on avance. Une règle à la fois, dans l'ordre, et je vérifie entre chaque. Commence par la règle 1 seule : la structure du projet et la page de réservation. Ne touche pas encore à la base de données. Quand tu as fini, dis-moi comment lancer le projet pour voir le résultat.
Remarque ce que fait la dernière ligne : elle l'empêche de tout construire d'un coup. C'est délibéré. Une application qui arrive en une fois est une application que tu ne peux pas vérifier — et donc pas corriger.
Étape 1 — règle 1
Tu n'as rien à demander de plus : le cahier des charges contient déjà la demande. Regarde l'ordre dans lequel il travaille — la structure du projet, la page, la logique des créneaux — puis lance ce qu'il te donne.
Étape 2
Un logiciel loué au mois, tu le reconnais tout de suite : c'est le même pour le salon, pour le garage d'en face et pour le cabinet dentaire du coin. Ici, on part de la marque. Cette étape ne sert pas qu'à faire joli — c'est elle qui fait qu'une cliente termine sa réservation au lieu de l'abandonner.
Maintenant, l'identité. Le salon s'appelle Lumière : cuivre et crème, une typographie sérif, quelque chose qui respire le soin plutôt que le logiciel. Pas de bleu, pas d'allure « application d'entreprise ».
Refais le parcours complet en quatre étapes : la prestation, le jour, l'heure, les coordonnées. Trois choses comptent :
À la fin, affiche une référence de réservation lisible, du type LUM-8F3K.
Étape 3 — règle 3
La partie qu'on ne voit pas, et c'est elle qui décide si tu as une application ou une vitrine. Les rendez-vous doivent exister ailleurs que dans l'écran.
Passe à la règle 3. Les rendez-vous doivent être enregistrés dans une vraie base de données — Cloudflare D1, en local pour l'instant.
Crée le fichier de schéma, et une table rendez_vous qui contient : une
référence, la prestation (identifiant, nom, prix, durée), la date, l'heure, le nom,
l'e-mail, le téléphone, la note de la cliente, et la date de création.
Ajoute les routes serveur : une pour enregistrer une réservation, une pour connaître les heures déjà prises un jour donné. La page publique doit demander au serveur quels créneaux sont pris, et les afficher barrés.
Explique-moi ensuite la commande exacte pour lancer le projet avec la base.
La commande, chez nous, est celle-ci — elle lance le serveur et la base d'un seul coup :
npx wrangler pages dev public --d1 DB --port 8790Étape 4 — règle 2
Imagine deux clientes qui ouvrent ta page en même temps, un samedi matin, et qui cliquent toutes les deux sur onze heures. Dans une maquette, les deux réservations passent. Tu as deux personnes dans ton fauteuil à onze heures, et c'est toi qui expliques.
La demande ci-dessous contient la phrase qui fait toute la différence. Ne la reformule pas.
Règle 2 maintenant : il doit être impossible de réserver deux fois le même créneau.
Ne vérifie pas depuis la page avant d'enregistrer — ça laisse toujours une fenêtre d'une fraction de seconde entre la vérification et l'écriture. Interdis le doublon dans la base elle-même : une date et une heure ne peuvent exister qu'une seule fois dans la table.
Quand la base refuse l'écriture, le serveur doit répondre un code 409 et le message : « Ce créneau vient d'être réservé. Choisissez-en un autre. » La page doit afficher ce message et rafraîchir les créneaux.
Voilà ce que ça donne dans le schéma. Une ligne, la dernière :
CREATE TABLE IF NOT EXISTS rendez_vous (
id INTEGER PRIMARY KEY AUTOINCREMENT,
reference TEXT NOT NULL UNIQUE,
date TEXT NOT NULL, -- AAAA-MM-JJ
heure TEXT NOT NULL, -- HH:MM
...
UNIQUE (date, heure)
);Le jour où deux demandes arrivent ensemble, c'est la base qui tranche, pas le hasard. Une règle écrite dans la base est tenue même quand le code se trompe ; l'inverse n'est jamais vrai. C'est la seule ligne de tout ce projet qu'il faut vraiment comprendre.
Étape 5 — règle 4
La cliente réserve. Mais le salon, lui, voit ça où ? Sur son propre écran.
Règle 4 : un espace réservé au patron, à l'adresse /admin.
En haut, trois chiffres : combien de rendez-vous aujourd'hui, combien à venir, et ce que ça représente en chiffre d'affaires.
En dessous, la journée heure par heure : le nom, le téléphone, l'e-mail, la prestation, et la note laissée par la cliente. La note doit se voir immédiatement — c'est là qu'on lit « allergie à l'ammoniaque », et on veut le savoir avant de commencer, pas après.
Ce n'est pas un tableau de bord d'ingénieur, c'est une feuille de route : lisible en trois secondes, le matin, sur un téléphone.
Cet écran affiche des données personnelles. Rappelle-moi, à la fin, qu'il devra être protégé par mot de passe avant toute mise en ligne.
Étape 6 — règle 5
Une réservation sans confirmation, c'est une réservation qu'on oublie. Et un rendez-vous oublié, c'est une place vide dans la journée du salon.
Règle 5 : un e-mail de confirmation qui part tout seul dès la réservation.
Aux couleurs du salon, avec la prestation, la date, l'heure, le prix, la référence et
l'adresse. Joins un fichier agenda .ics pour que la cliente pose le
rendez-vous dans son téléphone en un clic.
Deux exigences, et elles ne sont pas négociables :
/api/apercu-email qui affiche le
rendu de l'e-mail dans le navigateur, avec un rendez-vous d'exemple.Utilise l'envoi d'e-mail natif de Cloudflare, sans aucune clé API à souscrire, et laisse-le désactivé tant qu'on n'est pas en ligne.
localhost:8790/api/apercu-email affiche un e-mail
aux couleurs du salon. Et une réservation passe toujours, même si l'envoi ne fonctionne
pas — c'est exactement ce qu'on veut.
Le code exact de la vidéo : la page de réservation, la base, l'anti-doublon, l'écran
patron, l'e-mail et le fichier agenda. 21 fichiers, rien à installer d'autre que Node.
Le mode d'emploi est dans LIS-MOI.md, à la racine.
Décompresse, ouvre un terminal dans le dossier, et
lance npx wrangler pages dev public --d1 DB --port 8790.
L'application est sur localhost:8790.
Sers-t'en comme d'une référence, pas comme d'un raccourci. Ce qui a de la valeur, ce n'est pas le code — c'est le cahier des charges et l'ordre dans lequel tu avances. Le code, tu peux le régénérer demain sur un autre métier ; la méthode, non.
| Poste | Pour le volume d'un salon |
|---|---|
| Hébergement | 0 €. Pas « à partir de » — zéro. Le niveau gratuit de Cloudflare Pages couvre très largement ce trafic. |
| Base de données | 0 €. Idem, incluse. |
| E-mails | 0 € avec l'envoi natif de Cloudflare. |
| Nom de domaine | environ 10 € par an, si le salon en veut un à lui. |
| Claude Code | environ 20 € par mois — et avec le même abonnement, tu construis autant d'applications que tu veux. |
En face : un devis à quatre chiffres, souvent cinq, ou deux à trois cents euros par mois pour un logiciel qui ne t'appartient pas et que tu ne peux pas modifier.
Deux choses, et elles vont ensemble :
Abonne-toi à la chaîne pour ne pas rater la suite — c'est là qu'on branche l'e-mail pour de vrai, qu'on protège l'écran patron et qu'on met tout ça à une vraie adresse.
C'est notre métier. Nous sommes un studio de développement : nous concevons des applications sur mesure en nous appuyant sur ces outils et sur les technologies les plus avancées. Le diagnostic est gratuit, et on vous dit franchement si votre projet mérite un développement ou pas.
Parlons de ton projet →