Comment j'ai monté un site marchand avec réservation et paiement en 3 à 4 jours, pour l'atelier bois de Guillaume à Sitges, avec une IA comme co-équipière de dev.
Du choix de la formule au paiement, l'utilisateur traverse cinq composants indépendants. Chacun a un rôle unique.
La chaîne, vue d'en haut
Chaque composant est un logiciel en ligne (SaaS) du marché. Une fine page sur mesure les assemble au milieu, sans serveur dédié.
Ce projet est aussi une étude de cas que je garde dans mon Labo. Il valide une thèse que je défends en consulting et en formation : un produit minimum viable (MVP) marchand bien cadré peut tenir avec trois logiciels en ligne assemblés et un peu de code sur mesure au milieu.
Ce qu'il demande : de la rigueur d'architecture en amont, des arbitrages économiques explicites, et une bonne division du travail entre les humains et les outils, IA comprise.
Plus bas, je raconte la démarche, les arbitrages, la stack. Surtout, je détaille comment le travail s'est réparti à trois entre Guillaume (porteur métier), moi (designer/dev/ops) et Claude. Cette répartition est le cœur méthodologique du projet.
Guillaume anime à Sitges, en Catalogne, un atelier créatif de découpe et peinture sur bois. Pour enfants et adultes. Il fabrique aussi des objets en bois sur commande. L'activité s'appelle Sitgesmorzart.
Avant ce projet, sa seule présence en ligne était un compte Instagram, peu animé. Sans système de réservation. Résultat : zéro réservation entrante par ce canal, malgré un studio physique loué et équipé, et un beau fond éditorial photo.
Les pièces qu'il fabrique sont magnifiques. Personne ne les voyait.
Comment monter, en quelques jours et avec un budget proche de zéro, un site marchand qui gère la disponibilité de créneaux, la capacité par session, des tarifs dégressifs selon la taille du groupe, et un paiement en ligne ?
Le tout opérable par Guillaume seul au quotidien, et sans serveur dédié.
C'est un problème classique d'assemblage de logiciels en ligne : il existe des briques, il faut les choisir, les configurer, les coller proprement.
Délai court. On voulait être en ligne avant la haute saison touristique de Sitges.
Budget opérationnel proche de zéro. On évite les logiciels en ligne (SaaS) facturés à la place.
Cohérence avec la stack que je construis pour Life and Learning. Réutiliser DS et fontes.
Souveraineté pragmatique. EU autant que possible, compromis assumés sur le MVP.
L'hypothèse centrale, posée dès le démarrage :
Si on assemble proprement trois logiciels en ligne du marché (un calendrier de réservation, un processeur de paiement, un hébergeur statique) avec une fine page de jonction sur mesure, on peut livrer un système marchand qui respecte la capacité, gère les tarifs dégressifs, et reste opéré par une seule personne (Guillaume) au quotidien.
Trois sous-hypothèses se cachent dans cet énoncé :
Au démarrage, un rapprochement manuel entre Cal.com et Stripe suffit largement.
La capacité se gère côté Cal.com en standard, à condition de bien designer la structure.
Un site statique sur Vercel suffit pour une vitrine éditoriale et 2-3 pages de jonction transactionnelle.
Les trois ont tenu, avec quelques nuances que j'expose plus bas.
Sur ce type de projet, ce qui plombe les coûts et la maintenabilité, ce sont les choix par défaut. J'ai donc posé chaque arbitrage explicitement.
J'ai cherché des solutions tout-en-un. Toutes laissaient des trous. Les outils de réservation type Bookly ou Acuity coûtent vite cher. Les constructeurs Wix ou Squarespace dépassent les 30€/mois et bridaient le design.
Les plateformes type Airbnb Experiences prennent une commission importante et imposent leur cadre.
→ Construire (assembler), assumé
Une première tentation : utiliser ma propre infrastructure Wagtail/Django,
en construction pour Life and Learning, avec des modèles
Booking, Purchase, PaymentSplit.
Mécaniquement, ce serait l'outil « fait pour ça ».
J'ai écarté pour trois raisons : l'infra Wagtail restait à finaliser sur la partie front, la sur-ingénierie aurait ralenti le démarrage, et tester sur Sitgesmorzart une stack ultra-légère me servirait pour calibrer l'effort réel sur Wagtail ensuite.
→ Stack légère, Wagtail pour plus tardCal.com a été retenu : open-source, hébergement cloud en Europe, et capacité par type de créneau (Event Type) gérée nativement. Dix personnes par session, sans une ligne de code.
Calendly demande un plan payant pour les mêmes fonctionnalités. Un développement sur mesure aurait pris plusieurs jours pour reproduire ce que Cal.com offre en 30 minutes de configuration.
→ Cal.com, plan gratuitPremière intuition : plusieurs types de créneaux Cal.com selon la taille de groupe (« Solo », « Petit groupe 2-4 », « Grand groupe 5-10 »). Logique apparente cohérente.
J'ai vu le défaut avant de coder, en posant l'archi à plat. Voir l'encadré qui suit.
→ 1 seul type de créneau, capacité 10Stripe Checkout via API permet de générer dynamiquement un montant à partir de paramètres URL : propre et flexible. Mais ça implique un endpoint sans serveur, une clé d'API Stripe à protéger, une gestion d'état entre le client et le serveur. Pour 10 montants distincts (1 à 10 personnes), c'est de la sur-ingénierie.
Solution retenue : 10 liens de paiement (Payment Links) statiques, créés une fois pour toutes. Un par taille de groupe, prix pré-calculé. La page intermédiaire fait un routage interne vers le bon lien. Cette approche supprime le besoin de code serveur, de clé d'API à protéger, de déclencheur web (webhook) à déboguer.
→ 10 liens de paiement statiquesLe risque résiduel de l'archi : une réservation Cal.com sans paiement Stripe crée une « place fantôme ». Deux solutions possibles : un rapprochement régulier des flux côté opérateur, ou une automatisation Make qui recoupe les flux et annule les réservations non payées.
J'ai retenu le rapprochement manuel pour le démarrage. Au volume actuel, le coût d'apprentissage Make et de maintenance d'un scenario reste disproportionné. Si le volume monte, on bascule en automatisation.
→ Rapprochement manuel, automatisation plus tardCette modularité m'a sauvée plusieurs fois en debug. Chaque composant reste remplaçable indépendamment des autres.
Une vitrine éditoriale principale, deux pages techniques de jonction, et les obligations légales bilingues. Le tout déployé sur le domaine dédié.
| Type de page | Rôle | Statut |
|---|---|---|
| Vitrine principale | Galeries, calculator de tarifs, FAQ, sections horaires | En ligne |
| Page de réservation | Intégration Cal.com | En ligne |
| Page de jonction | Routage post-Cal.com vers Stripe | Page custom |
| Page de confirmation | Remerciement post-paiement, rappel pratique | En ligne |
| Mentions légales | Obligations légales bilingues | En ligne |
| CGV | Conditions générales de vente | En ligne |
| Confidentialité | Politique de confidentialité (RGPD) | En ligne |
Principe tenu : une étape à la fois, validation Guillaume avant de passer à la suivante. Pour éviter les retours coûteux et garder le bon cap.
Toutes les leçons préalables (Ionos, Wagtail) avaient déjà été digérées sur d'autres projets. Restent quelques apprentissages spécifiques à ce projet, et les premiers signaux après la mise en ligne.
business_profile.product_description.
Soigner ce champ en amont accélère le processus.
Au-delà du coup de pouce familial.
Le mot-clé du projet : soustraction. Chaque arbitrage (Wagtail écarté, API Stripe écartée, automatisation différée, serveur dédié évité) est un non qui dégage du temps et du coût. Les MVP réussis se définissent par ce qu'ils ont le courage d'écarter. Posture que je transpose en consulting : la première question d'un MVP est « qu'est-ce qu'on enlève ? », plutôt que « qu'est-ce qu'on ajoute ? ». La plupart des MVP qui dérapent dérapent par accumulation.
Sur Sitgesmorzart, j'ai principalement fait de l'architecture, du design, et de la gestion de produit. Le code généré reste à 90% du copier-coller : la valeur ajoutée est dans le choix de la stack, dans la décision de garder un seul type de créneau, dans la décision de liens de paiement statiques. Savoir prendre une décision d'architecture vaut 10× savoir écrire le code. Le code se rachète à n'importe qui, la décision d'archi se rachète mal.
Claude a été un excellent co-équipier de pair-programming sur ce projet, à condition de l'utiliser comme une dev junior très rapide qu'on instruit précisément, plutôt qu'une consultante senior à qui on déléguerait le cadrage. Avec « fais-moi un système de réservation », il aurait pu partir dans 50 directions ; avec « implémente cette archi-là, avec ces contraintes-là, en HTML statique », il a été remarquablement efficace. L'IA générative ne remplace pas l'architecture. Elle l'exécute. Et si l'architecture est mauvaise, elle l'exécute mal aussi, mais très vite.
Cette répartition est précisément ce qui détermine la qualité de ce qui sort.
Guillaume est le porteur métier. Il connaît son atelier, ses clients, ses prix, son secteur. Quand il dit « ça ne se vend pas comme ça à Sitges », j'écoute parce qu'il a 100% raison. Mon rôle est de lui livrer un système qui sert son métier, plutôt que de lui apprendre son métier. Cette distinction tient aussi dans mes prestations de consulting.
Claude oublie tout d'une session à l'autre. Au début de chaque session, je devais lui recoller le contexte. Pour ce projet, on a gardé un brief synthétique qui résume l'archi, les décisions, l'état des choses. Cette continuité humaine garde le système cohérent dans la durée.
Les décisions me reviennent toujours. Quand je pose une question d'arbitrage, Claude propose des options structurées avec leurs conséquences. La décision reste mienne, appuyée sur des contraintes qu'il ignore (mon temps, le temps de Guillaume, le coût de migration future). L'IA reste un excellent partenaire de réflexion, sans porter la responsabilité du choix.
Un exemple authentique par catégorie, extrait de nos sessions réelles.
Ma proposition initiale : plusieurs types de créneaux Cal.com par taille de groupe. Logique apparente cohérente.
Avant de demander à Claude d'implémenter, j'ai pris 10 minutes à plat pour vérifier que l'archi tenait sur trois cas d'usage. C'est là que j'ai vu le bug : capacités indépendantes, surbooking possible jusqu'à 30 personnes sur 10 places réelles.
J'ai porté le diagnostic à Claude en formulant ma question de façon contrainte : « Comment je gère trois tarifs avec Cal.com sans créer trois types de créneaux ? » La réponse a alors été directe : un seul type, avec capacité 10, et la taille de groupe gérée avant Cal.com par un mécanisme de pré-sélection côté front.
J'ai demandé à Claude la solution la plus propre pour gérer 10 montants distincts. Première réponse spontanée : Stripe Checkout via API, avec un endpoint sans serveur Vercel, génération dynamique de la session selon les paramètres URL.
Question que j'ai retournée : « Pour 10 montants statiques connus à l'avance, est-ce qu'on a vraiment besoin de génération dynamique ? »
Réponse révisée : non. 10 liens de paiement statiques sont équivalents fonctionnellement, sans demander d'endpoint serveur ni de clé d'API à protéger. La seule perte concerne la flexibilité tarifaire : si je change un prix, je recrée le lien correspondant (10 minutes).
Une fois la chaîne assemblée, on a découvert un cas particulier : certains profils de réservation devaient suivre un parcours différent. À ce stade, l'utilisateur arrivait sur une étape devenue inutile pour lui. Friction superflue.
Solution co-construite en quelques minutes : un branchement conditionnel léger en sortie de Cal.com aiguille le visiteur vers la bonne suite selon les données qu'il vient de fournir. Logique côté front, l'archi globale reste intacte.
Correctif JS minimaliste, déployé en quelques minutes. Test bout-en-bout pour les deux cas de figure.
Une démarche, plus qu'un produit.
Le système est taillé pour un atelier physique avec un seul opérateur métier, capacité par créneau, tarifs dégressifs simples. Reproduire la démarche demande des compétences techniques (HTML/CSS/JS, Cal.com avancé, Stripe, déploiement Vercel) ou un accompagnement. Si vous avez une activité similaire (atelier, coaching, retraite, événement payant à capacité limitée) et que vous voulez creuser une approche équivalente, je peux échanger sur la méthode et le cadrage. La réalisation dépend du contexte.
Réserver un appel