Réserver un appel
Sitgesmorzart · 2026

Un système marchand fonctionnel, monté en binôme avec l'IA

Comment j'ai conçu et déployé une chaîne réservation-paiement en 3 à 4 jours pour un artisan, en travaillant en binôme avec Claude comme partenaire de développement.

Réserver un appel découverte 30 min, gratuit, sans engagement.
Le système, vu d'en haut

Cinq étapes. Une chaîne.

Du choix de la formule au paiement, l'utilisateur traverse cinq composants indépendants. Chacun a un rôle unique.

La chaîne de réservation et de paiement se compose de cinq étapes. Première étape : la page des tarifs, où le client choisit une formule. Deuxième étape : Cal.com, où le client choisit son créneau. La capacité est limitée à dix personnes par session. Troisième étape : la page de jonction, qui oriente vers le bon lien de paiement selon le profil de réservation. Quatrième étape : Stripe, qui encaisse le paiement via l'un des dix liens correspondant au nombre de personnes. Cinquième étape : la page de confirmation, avec un message de remerciement et les informations pratiques.

Chaque composant est un logiciel en ligne (SaaS, pour Software as a Service) disponible sur le marché. Une fine page sur mesure les assemble au milieu, sans serveur dédié.

Contexte & problème

Un atelier physique, un studio loué, et zéro réservation par les canaux existants.

La situation

Guillaume est artiste et animateur d'ateliers créatifs. Il découpe et peint le bois. Il travaille avec des enfants et des adultes en Catalogne. Il fabrique aussi des objets sur commande. Son activité s'appelle Sitgesmorzart.

Son atelier est implanté dans une zone touristique où se croisent trois communautés linguistiques : hispanophones, francophones et anglophones. Un site monolingue aurait exclu une partie significative de sa clientèle potentielle.

Il est venu me voir avec un problème simple : un studio physique loué et équipé, un beau fond éditorial photo, zéro réservation entrante par ses canaux en ligne. Sa seule présence web était un compte Instagram, peu animé, sans système de réservation.

Les pièces qu'il fabrique sont magnifiques. Personne ne les voyait.

Guillaume connaît son atelier, ses clients et ses prix. Mon rôle était de lui fournir des outils adaptés à son besoin et à son mode de fonctionnement.

Le problème, reformulé en termes produit

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.

Contrainte 1

Délai court. On voulait être en ligne avant la haute saison touristique.

Contrainte 2

Budget opérationnel proche de zéro. On évite les logiciels en ligne (SaaS) facturés à la transaction ou par abonnement élevé.

Contrainte 3

Efficacité de conception. Partir de fondations visuelles existantes (tokens CSS, typographies) plutôt que repartir de zéro, et les affiner avec Guillaume pour coller à l'identité de son atelier.

Contrainte 4

Souveraineté pragmatique. EU autant que possible, compromis assumés sur le MVP.

Contrainte 5

Trilingue obligatoire. Le site devait fonctionner en espagnol, français et anglais pour couvrir les trois communautés linguistiques de la zone.

Hypothèses de départ

Trois hypothèses UX, posées avant de choisir la stack.

Hypothèse 1

Les plateformes tout-en-un type Shopify sont conçues pour la vente de produits physiques. Elles gèrent mal les activités mixtes (réservation d'ateliers + vente d'objets), les changements de créneaux saisonniers, et le multilingue de bout en bout. Elles produisent aussi des sites visuellement standardisés, peu adaptés à une activité artisanale où l'identité visuelle est un levier de conversion.

Hypothèse 2

Tout construire sur mesure est hors de portée d'un opérateur seul. Les évolutions courantes (modification de tarifs, changement de créneaux pour l'été, promotions saisonnières, ateliers spéciaux type anniversaire) doivent pouvoir être gérées par Guillaume sans intervention technique externe.

Hypothèse 3

Un assemblage de logiciels en ligne du marché, reliés par une fine couche sur mesure, peut couvrir l'ensemble des besoins à un coût opérationnel proche de zéro, en trois langues, tout en restant maintenable par le commanditaire seul au quotidien.

Si on assemble proprement trois logiciels en ligne du marché 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, fonctionne en trois langues, et reste opéré par une seule personne au quotidien.

Les trois hypothèses ont tenu. Les arbitrages qui suivent expliquent comment.

Arbitrages clés

Six arbitrages structurants.

Sur ce type de projet, les choix par défaut sont ce qui fait déraper les coûts et la maintenabilité. J'ai donc posé chaque arbitrage explicitement.

Arbitrage 1 Construire ou acheter

J'ai évalué les solutions tout-en-un disponibles. Aucune ne couvrait l'ensemble des besoins sans compromis significatif. Les outils de réservation type Bookly ou Setmore peuvent vite coûter cher. Les constructeurs type Wix ou Squarespace dépassent les 30€/mois et contraignent fortement les choix visuels.

Les plateformes type Airbnb Experiences prélèvent une commission significative et imposent leur environnement visuel et éditorial.

→ Construire (assembler), assumé
Arbitrage 2 Cal.com vs Calendly vs sur mesure

Cal.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 gratuit
Arbitrage 3 Un seul type de créneau, ou plusieurs ?

Première intuition : plusieurs types de créneaux Cal.com selon la taille de groupe. En posant l'architecture à plat, j'ai identifié un piège structurel de capacité qui aurait provoqué du surbooking. L'encadré suivant détaille le diagnostic.

→ 1 seul type de créneau, capacité 10
Arbitrage 4 Liens de paiement statiques vs API dynamique

Stripe Checkout via API permet de générer dynamiquement un montant à partir de paramètres URL : fiable et adaptable. Mais cela implique un point d'entrée sans serveur (endpoint), 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 statiques
Arbitrage 5 Rapprochement manuel vs automatisation

Le 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 tard
Page de jonction du site Sitgesmorzart en français. Après la réservation Cal.com, le client choisit entre payer en ligne via Stripe ou payer en espèces le jour de l'atelier.
La page de jonction : branchement entre paiement en ligne et paiement en espèces
Stack & architecture

Sept composants assemblés. Une stack ultra-légère.

Cette modularité a été déterminante pendant la phase de test : chaque composant peut être remplacé ou reconfiguré indépendamment des autres.

Front
HTML/CSS/JS vanilla
Une page principale ~2400 lignes. Aucune dépendance externe.
Hébergement
Vercel
Déploiement automatique sur push GitHub.
Réservation
Cal.com · plan gratuit
1 type de créneau, capacité limitée par session, questionnaire personnalisé.
Paiement
Stripe · structure activée
Liens de paiement statiques, un par taille de groupe. Libellé bancaire dédié.
Design system
foundations.css
Fondations visuelles existantes affinées avec Guillaume. Tokens CSS, typographies, palette chromatique.
Photos
JPEG q78 + WebP
12 photos × 2 formats. 1200px max. Pas de CDN externe.
Multilingue
Toggle data-lang
ES (source) · EN · FR. Bascule côté navigateur. Sans système de gestion de contenu (CMS).
Page d'accueil du site Sitgesmorzart en version espagnole. Hero bicolonne avec titre, description et photo d'atelier. Navigation trilingue ES/FR/EN visible.
La vitrine : hero trilingue, galeries, navigation

Pages du site

Type de page Rôle Statut
Vitrine principale Galeries, calculateur 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 trilingues En ligne
CGV Conditions générales de vente En ligne
Confidentialité Politique de confidentialité (Règlement général sur la protection des données, RGPD) En ligne
Interface Cal.com avec le calendrier de juillet 2026 ouvert. Le vendredi 3 est sélectionné, deux créneaux disponibles : 10h30 et 17h00, chacun avec 10 places disponibles.
Un seul type de créneau, capacité 10 sièges par session
Phases & rythme

Cinq phases séquentielles, sur trois à quatre jours intenses.

Principe tenu : une étape à la fois, validée par Guillaume avant de passer à la suivante. Pour éviter les retours coûteux et garder le bon cap.

0
Cadrage avec Guillaume
Positionnement, photos, tarifs, créneaux. Benchmark concurrents locaux.
1
Site éditorial
Build de l'index complet : galeries, FAQ, calculateur, sections horaires, accessibilité.
2
Cal.com + Stripe
Paramétrage Cal.com et Stripe. Vérification d'identité. 10 liens de paiement.
3
Pages de jonction + test
Code des pages techniques de jonction. Test bout-en-bout avec une réservation fictive.
4
Mise en ligne
Diffusion sur Instagram et par messages ciblés auprès des premiers contacts.
Apprentissages durs & premiers signaux

Le projet a été fluide grâce au défrichage préalable.

Quelques apprentissages spécifiques et les premiers signaux après la mise en ligne.

Sur Stripe et la configuration initiale
  • Le libellé bancaire (statement descriptor) : à configurer systématiquement. Par défaut, Stripe affiche le nom légal de la société sur les relevés bancaires des clients. Un libellé générique crée une confusion si la marque de l'activité diffère du nom légal de la structure. Libellé personnalisé sur Stripe : le bon nom apparaît immédiatement sur les transactions test.
  • Description du compte Stripe pour la vérification d'identité (KYC, pour Know Your Customer). La vérification d'identité Stripe pose des questions plus ou moins répétitives selon la précision du business_profile.product_description. Renseigner ce champ avec précision avant de soumettre le dossier évite les re-saisies lors du processus de vérification.
Sur Cal.com et l'expérience client
  • Questions personnalisées Cal.com : l'ordre compte. Cal.com place les questions personnalisées après le choix du créneau et avant le bouton de confirmation. Bien posées dans le bon ordre, elles permettent d'aiguiller le visiteur vers la bonne suite de parcours dès la sortie de Cal.com. Le branchement reste propre et fluide.
    Formulaire de réservation Cal.com en version française. Les champs sont libellés en trois langues : espagnol, français et anglais. On voit les questions personnalisées : nombre de personnes, langues comprises, âges des participants, allergies éventuelles.
    Formulaire trilingue avec questions personnalisées
Sur l'effet du calculateur de tarifs
  • Le calculateur de tarifs : un outil de conversion imprévu. Le client sélectionne le nombre de personnes et voit instantanément le tarif total. Plusieurs clients ont écrit en premier message qu'ils trouvaient le système clair et rassurant. Pour un atelier où le prix dégressif demande un peu d'explication, le calculateur porte une partie du discours commercial.
Sur les premiers signaux post-mise en ligne
  • Une vingtaine de réservations depuis la mise en ligne, uniquement via le site, sans travail de diffusion active. Zéro réservation générée via le compte Instagram seul sur la même période, pourtant en place depuis des mois. Signal modeste en valeur absolue, significatif en proportion : la chaîne fonctionne, les clients comprennent le parcours, et la friction du paiement en ligne reste acceptable.
  • Ce qui reste à construire. Automatisation pour rapprocher les réservations Cal.com et les paiements Stripe, à activer si le volume monte. Tableau de bord pour le suivi opérationnel des réservations.
Apports professionnels

Trois compétences professionnelles que ce projet illustre.

01

Sur le cadrage produit

Le mot-clé du projet : soustraction. Chaque arbitrage (API Stripe écartée, automatisation différée, serveur dédié évité) est un non qui dégage du temps et du coût. La première question d'un produit minimum viable (MVP) est « qu'est-ce qu'on enlève ? », plutôt que « qu'est-ce qu'on ajoute ? ». La plupart des MVP échouent par accumulation.

02

Sur le rôle d'architecte sans coder

Sur ce projet, j'ai principalement fait de l'architecture, du design et de la gestion de produit. 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. Ce sont ces décisions qui déterminent la qualité du résultat final, bien avant la première ligne de code.

03

Sur l'IA comme partenaire de développement

Claude a été un excellent partenaire de développement en binôme sur ce projet, à condition de l'utiliser comme un exécutant rapide qu'on guide précisément, plutôt que comme un expert à 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 exécute l'architecture. Si elle est mauvaise, elle l'exécute mal, mais très vite.

Sur ce projet, j'ai structuré le contexte de travail sous forme de briefs synthétiques mis à jour à chaque session : architecture en cours, décisions prises, état du projet. Cette discipline de documentation est ce qui maintient la cohérence du système dans la durée, quelle que soit la durée du projet.

Variantes

Ce que je ferais autrement.

Variante 1

Organiser les contenus dès le démarrage

Sur ce projet, photos, textes et tarifs ont été rassemblés au fil du travail. Gérable, mais générateur d'allers-retours. Sur un projet similaire, je construirais une bibliothèque de contenus structurée dès le cadrage, dans les outils du commanditaire pour qu'il puisse la maintenir seul :

  • Figma pour les composants et tokens visuels
  • Notion pour les contenus éditoriaux et les données métier (tarifs, créneaux, descriptions)
  • Git ou Drive pour les ressources et documents de référence

Une nomenclature cohérente sur les trois environnements accélère les mises à jour, les évolutions saisonnières et les productions assistées par IA.

Variante 2

Structurer le suivi du travail avec l'IA

La gestion du contexte entre les sessions Claude était manuelle sur ce projet. Sur un projet similaire, je mettrais en place dès le démarrage un système léger :

  • Journal des décisions et état du projet maintenu en continu
  • Briefs standardisés pour chaque session de travail
  • Suivi de la consommation de tokens, coût réel à piloter pour le prestataire comme pour le client

Les outils dépendent du contexte et du budget (Notion, Make, projets Claude avec mémoire structurée), mais le principe reste le même : automatiser la maintenance du contexte sans alourdir le flux de travail.

Si vous pensez à un projet similaire

On en parle ?

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, configuration Cal.com et 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, nous pouvons échanger sur la méthode, le cadrage et l'estimation de l'effort. Réservez un appel pour en discuter.

Réserver un appel