Quand je suis obligé de travailler gratuitement pendant mes vacances… pour ma femme 😄

Il y a des clients avec lesquels on négocie un devis, un planning et un périmètre. Et puis il y a les autres. Ceux qui savent exactement où vous habitez, qui connaissent votre emploi du temps et qui peuvent parfaitement vous expliquer, pendant vos congés, que « ce n’est qu’un petit site ». Dans mon cas, ce client particulièrement exigeant était ma femme. 😄

Pendant mes congés d’été, Eva voulait lancer un site pour développer ses activités de kinésithérapie et proposer des activités physiques adaptées en visioconférence. La demande initiale semblait presque reposante : quelques pages pour présenter son activité, un formulaire de contact et une page pour expliquer les cours en ligne.

Autrement dit : un petit site vitrine. Le genre de projet qu’un développeur accepte en se disant qu’il va y passer quelques soirées tranquilles entre deux journées de vacances.

Évidemment, cela ne s’est absolument pas passé comme ça.

01Le client le plus dangereux : celui qui habite avec vous

Je pensais pourtant qu’après toutes ces années Eva avait compris une chose fondamentale de mon métier : lorsque je demande une expression de besoin complète, ce n’est pas uniquement pour embêter le client avec des documents et des réunions.

Un besoin incomplet ne disparaît pas parce qu’on commence à coder. Il revient simplement plus tard, généralement au pire moment, lorsque les choix techniques ont déjà été faits et que chaque « petite fonctionnalité supplémentaire » commence à en déplacer trois autres.

Le scénario a donc été parfaitement classique : « il faudrait juste présenter mon activité », puis « ce serait bien que les personnes puissent réserver », puis « du coup, elles doivent pouvoir payer », puis « et il leur faut probablement un compte », puis « et moi, comment je gère les cours ? ».

Quelques itérations plus tard, le petit site vitrine avait tranquillement décidé de devenir une application.

02Du site vitrine à une véritable application métier

Au fur et à mesure du cadrage, le périmètre réel de Mumkine.fr est devenu beaucoup plus ambitieux.

Le projet comprend désormais plusieurs briques :

• Site public : présentation de l’activité, des accompagnements, des zones d’intervention et des activités en ligne.
• Formulaire de contact : pour permettre une prise de contact simple sur le parcours kinésithérapie.
• Espace utilisateur : authentification et accès aux informations nécessaires pour les activités proposées.
• Calendrier : publication et consultation des séances disponibles.
• Réservation en ligne : inscription à une séance avec gestion des places et du parcours utilisateur.
• Paiement : intégration de Stripe pour les activités concernées.
• Administration : gestion des séances, utilisateurs, contenus et opérations du quotidien.
• E-mails transactionnels : centralisés sur une infrastructure mailcow déjà maîtrisée.
• Blog : publication de contenus pratiques autour du projet et de l’activité.

Le site public distingue d’ailleurs clairement deux parcours : d’un côté la kinésithérapie périnatale dans les Yvelines, de l’autre les activités physiques adaptées accessibles en ligne.

Ce détail paraît anodin, mais il est important. Quand une application commence à gérer plusieurs activités, il faut éviter de construire un gigantesque tunnel identique pour tout le monde. Les règles métier, les paiements et les informations demandées ne sont pas forcément les mêmes.

03Le paradoxe : utiliser l’IA pour cadrer un projet développé avec l’IA

Là où le projet devient intéressant, c’est que nous avons utilisé de l’intelligence artificielle à deux niveaux totalement différents.

Le premier niveau n’est pas le développement. C’est le cadrage.

Avant de demander à une IA de produire des fichiers, des routes, une base de données ou une interface, encore faut-il savoir ce que l’on veut réellement construire.

C’est précisément le problème que je rencontre régulièrement avec le vibe coding : l’outil sait produire du code extrêmement vite, mais si vous changez constamment de direction, il produira aussi extrêmement vite plusieurs versions différentes d’une mauvaise architecture.

04Léopold pour transformer les idées en besoins exploitables

Pour remettre un peu d’ordre dans les idées d’Eva — et accessoirement sauver ce qu’il restait de mes vacances — elle s’est appuyée sur Léopold.

Léopold est un assistant AMOA que je développe en partenariat avec Jean-Francis Ochs. Son objectif est précisément de partir d’un besoin parfois encore flou, de poser les questions nécessaires, de conserver les décisions et de produire des livrables exploitables.

Ce qui m’intéressait ici n’était pas d’obtenir un énorme cahier des charges que personne ne lirait. Je voulais récupérer suffisamment d’informations structurées pour répondre rapidement à des questions concrètes : acteurs, parcours, authentification, données à persister, administration, paiements, e-mails, annulations et règles métier.

Léopold peut produire des synthèses de cadrage, des cahiers des charges, des études détaillées, des modèles de données, des propositions UX et une base de contrat OpenAPI. Grâce aux exports, j’ai pu reprendre le résultat et le donner comme contexte au développement.

Et c’est probablement la partie la plus importante de cette histoire : l’IA n’a pas supprimé l’AMOA. Elle l’a rendue encore plus utile.

05Une architecture volontairement simple à déployer

Une fois le besoin suffisamment stabilisé, j’ai fait un choix simple : je voulais que la mise en production soit presque ennuyeuse.

Pas quinze composants à installer à la main. Pas une documentation de déploiement interminable. Pas une machine sur laquelle il faut se souvenir qu’un fichier a été modifié manuellement six mois plus tôt.

L’application est donc pensée autour d’un déploiement Docker compact, avec la persistance nécessaire dans un volume afin de rendre les sauvegardes, les mises à jour et les redéploiements beaucoup plus prévisibles.

Ce choix n’élimine pas les sujets classiques : variables d’environnement, secrets, sauvegardes, migrations, logs, supervision et retour arrière restent nécessaires. Mais pour un projet de cette taille, je préfère maîtriser une unité de déploiement cohérente plutôt que multiplier les dépendances externes sans raison.

06Ne pas oublier les e-mails

Il y a une fonctionnalité que l’on sous-estime presque toujours dans un projet web : l’e-mail.

Création de compte, réservation, confirmation, information pratique, annulation, récupération de mot de passe, messages administratifs… le « petit site » commence très vite à envoyer beaucoup de messages.

J’ai donc réutilisé mon infrastructure mailcow. mailcow est une suite de messagerie open source basée sur Docker qui regroupe notamment Postfix, Dovecot, Rspamd et SOGo.

L’intérêt, pour moi, est surtout de ne pas recréer une stratégie e-mail différente à chaque nouveau projet. Quand une brique est déjà connue, monitorée et sauvegardée, la réutiliser est souvent beaucoup plus raisonnable que réinventer une infrastructure complète.

07Stripe, MCP et un énorme gain de temps

La partie paiement est probablement celle qui illustre le mieux le changement de productivité apporté par les outils actuels.

Nous avons choisi Stripe.

Je précise un point important concernant la TVA : le sujet dépend de la nature exacte de la prestation. Les soins réalisés par un masseur-kinésithérapeute dans le cadre réglementé de sa profession peuvent relever d’une exonération, mais cela ne signifie pas automatiquement que toute activité proposée par un kinésithérapeute bénéficie du même traitement fiscal. Ce point doit donc rester traité activité par activité.

Ce qui m’a surtout intéressé techniquement avec Stripe est l’existence de son serveur MCP officiel. Le MCP — Model Context Protocol — permet à un agent ou à un environnement compatible d’accéder à des outils explicitement exposés par un service.

Stripe fournit aujourd’hui un serveur MCP permettant notamment de rechercher dans sa documentation et d’interagir avec une grande partie de son API. Dans mon cas, je l’ai relié à mon environnement Codex.

Je ne prétends évidemment pas que quatre jours de travail deviennent toujours deux heures. Cela dépend du projet. Mais sur cette intégration précise, le gain de temps a été spectaculaire.

Une grande partie du temps économisé correspond à ce que l’on perdait auparavant à naviguer dans la documentation, vérifier un nom de paramètre, retrouver une méthode, créer un objet de test ou comprendre une erreur d’API.

08Pourquoi ne pas simplement utiliser un CMS et des plugins ?

Soyons clairs : Mumkine aurait parfaitement pu être réalisé avec d’autres technologies.

WordPress, un constructeur de site, un outil de réservation spécialisé, un plugin de paiement et plusieurs services SaaS auraient certainement permis d’arriver à un résultat fonctionnel.

Je n’ai rien contre ces solutions. Elles sont souvent le meilleur choix lorsque le besoin colle précisément à leur fonctionnement.

Le problème apparaît lorsque les besoins commencent à diverger légèrement du chemin prévu par chacun des modules. On installe alors un plugin de réservation, puis un module de paiement, puis une extension pour modifier une règle, puis une autre pour connecter les comptes, puis un hook, puis un peu de CSS… et on finit avec une solution « sans développement » que personne ne comprend réellement dans son ensemble.

Avec le développement assisté par IA, l’équilibre économique change. Une fonctionnalité spécifique qui aurait autrefois demandé une journée peut parfois être produite bien plus vite. Cela rend à nouveau pertinent le sur-mesure pour certains petits projets, à condition de rester capable de maintenir ce que l’on construit.

09Ce que le vibe coding change réellement

Ce projet m’a surtout confirmé quelque chose : le vibe coding ne remplace pas vraiment le développeur. Il déplace une partie de son travail.

Le développeur n’est donc pas transformé en spectateur. Au contraire, plus l’IA code vite, plus les mauvaises décisions peuvent elles aussi être implémentées vite.

Quelqu’un doit toujours être capable de dire : non, cette logique ne doit pas être dupliquée ; non, on ne stocke pas cette clé dans Git ; non, un paiement réussi côté navigateur ne suffit pas ; et parfois simplement : non, on n’a pas besoin de cette fonctionnalité.

10Ce que l’IA ne fait toujours pas à votre place

C’est probablement le passage le moins sexy d’un article sur le vibe coding, mais il est indispensable.

Un agent peut vous aider à écrire une intégration Stripe. Il ne prend pas la responsabilité d’un paiement erroné.

Il peut générer un schéma de base de données. Il ne décide pas à votre place quelles données il est réellement légitime de conserver.

Il peut produire un Dockerfile. Il ne vérifie pas automatiquement que vos sauvegardes permettront réellement de redémarrer le service le jour où votre serveur disparaîtra.

Et il peut produire énormément de code propre autour d’une mauvaise décision fonctionnelle.

11Et mes vacances dans tout ça ?

Bon, si je reviens au titre de l’article, j’étais donc effectivement en congés.

Et j’ai effectivement travaillé.

Et oui, le client n’a toujours pas réglé la facture. 😄

Mais ce petit projet familial a finalement été un excellent laboratoire. Il m’a permis de tester concrètement jusqu’où l’on peut pousser aujourd’hui un développement assisté par agent lorsque le besoin est correctement cadré et que l’on garde une architecture cohérente.

La conclusion n’est pas que n’importe qui peut désormais créer en deux heures un logiciel métier complet simplement en expliquant vaguement son idée à une IA.

La conclusion est beaucoup plus intéressante : une personne qui connaît son métier, un bon cadrage fonctionnel et un développeur capable de piloter correctement des agents peuvent aujourd’hui transformer extrêmement vite une idée en un produit réellement exploitable.

Ce temps gagné ne signifie pas forcément travailler moins.

Dans mon cas, cela a surtout permis à ma femme d’ajouter beaucoup plus de fonctionnalités avant la fin de mes vacances. 😂