ekyde : construire une place de marché équestre, règle après règle

La plateforme ekyde est une place de marché française de l’équitation. Les cavaliers y cherchent un hébergement pour leur cheval, à la nuit ou en pension, y compris près d’un concours, ainsi que des cours, des stages et des événements. Les établissements équestres et les coachs indépendants y publient leur offre et gèrent leurs demandes. J’ai défini le produit, tranché les règles, validé les écrans et piloté la construction, avec un assistant de programmation IA qui écrit le code, jusqu’à la mise en ligne.

Le premier arbitrage n’est pas technique. ekyde ne prend aucune commission et n’encaisse rien du cavalier : l’établissement ou le coach perçoit lui-même le prix de ses nuits, de ses cours et de ses stages, selon ses conditions. ekyde ne facture que son abonnement, un prix fixe par établissement ou par page de coach, quel que soit le nombre de cavaliers. À la date de cette étude, il est de 20 € HT par mois.

Ce choix a allégé le produit. Le modèle de départ prévoyait que le cavalier paie en ligne, qu’ekyde garde les fonds jusqu’après le séjour, rembourse si besoin, puis reverse l’établissement. Tout cela a été supprimé, ni désactivé ni mis en commentaire, et un test automatique refuse désormais d’en retrouver les traces dans le code de l’application. Encaisser pour le compte de tiers demande aussi des vérifications juridiques et bancaires dont le produit n’a plus besoin.

La promesse d’une place de marché d’hébergement tient en une phrase : une place affichée libre doit l’être. Chaque offre déclare donc une capacité pour chaque nuit, et un plafond commun peut s’y ajouter quand plusieurs offres puisent dans les mêmes places. Le restant d’une nuit est la capacité moins les places retenues par une demande en attente et celles qui sont déjà confirmées.

Ce calcul ne repose pas sur l’interface. La base de données refuse elle-même toute nuit dont les places retenues et confirmées dépasseraient la capacité déclarée, et tout groupe de places qui dépasserait son plafond. Cela vaut même quand deux demandes arrivent au même instant, ou quand une commande du serveur se trompe : la survente est rendue impossible en base, pas seulement improbable. La règle du restant est écrite une seule fois en SQL, reprise à l’identique en TypeScript, et un même jeu d’exemples vérifie les deux versions.

Accueillir un cheval une nuit avant un concours et l’accueillir en pension pour plusieurs mois ne relèvent pas de la même transaction. La nuit suit un parcours court : le cavalier envoie une demande, l’établissement accepte ou refuse, la réservation est confirmée, et la demande retient les places jusqu’à la réponse. La pension et les séjours de saison restent des demandes, le contrat et les mensualités se réglant entre l’établissement et le propriétaire, hors d’ekyde.

Les deux partagent l’inventaire des places, mais jamais la logique de réservation : les mélanger aurait fait porter à l’une les règles de l’autre. Cette séparation se décide au départ, parce qu’elle commande la forme des données comme celle des écrans.

Une plateforme qui facilite des réservations doit tenir compte très tôt d’obligations qui imposent des champs et des statuts en base : la déclaration des revenus des vendeurs aux services fiscaux (DAC7), la répartition des responsabilités sur les données personnelles entre la plateforme et les établissements (RGPD), les points de contact et la motivation des décisions de modération du règlement sur les services numériques (DSA). Les rattraper après coup coûte cher.

J’ai donc consigné ces décisions dans un document d’architecture avant d’écrire le schéma, qui prévoit ces champs dès le départ. Les migrations contiennent par exemple les périodes de déclaration des vendeurs et leurs exports annuels. Il s’agit d’une démarche de conception, pas d’une attestation : cette étude ne revendique ni certification ni validation juridique.

Le socle est Next.js, React et TypeScript en mode strict, avec PostgreSQL pour les données. Le code est rangé en zones : le métier, les cas d’usage du serveur, les adaptateurs vers les fournisseurs (base de données, courriel, abonnements) et l’interface. Les dépendances ne vont que dans un sens : le métier n’importe rien d’autre que lui-même, et l’interface ne touche jamais directement les adaptateurs.

Ces règles ne reposent pas sur la discipline. Des tests d’architecture échouent si une dépendance interdite apparaît, et des tests propres à la base de données vérifient ce que la base garantit seule, comme le refus de la survente. Un produit qui grossit chaque semaine garde ainsi la forme qu’on lui a donnée.

Avant chaque lot de développement, la règle du métier est écrite : un cahier des charges détaillé, une décision numérotée quand il y a un arbitrage et, si une règle change, une demande de changement consignée dans un registre plutôt qu’un réglage discret dans le code. La spécification de départ est gelée : elle ne se modifie pas, elle se complète par ces demandes. Les écrans sont d’abord présentés sous forme de planches que je valide avant qu’ils soient codés.

Je construis avec un assistant de programmation IA, qui écrit le code sous ma direction. Les cahiers sont rédigés pour qu’il puisse développer sans reposer de question, et une décision qui manque y est marquée comme question ouverte plutôt qu’inventée. Les tests automatiques vérifient ensuite le résultat.

Le dépôt de code compte son premier commit le 9 septembre 2026, et le site est en ligne depuis le 12 octobre : moins de cinq semaines. Ce délai tient à la méthode et à l’assistant, et il décrit un produit dont je suis la seule décisionnaire. Pour un projet client, les validations ajoutent du temps : ce n’est pas un engagement de délai.

ekyde est accessible sur ekyde.com et démarre par les Pays de la Loire. Les établissements et les coachs préparent leur fiche gratuitement ; la publication demande l’abonnement et, pour un coach, une carte professionnelle vérifiée. Le lancement est récent : aucun chiffre d’usage, ni nombre d’établissements, ni nombre de réservations, ni revenus, n’est avancé ici.

Les décisions de fond de ce projet sont reprises sous forme de guide dans créer un SaaS : les cinq décisions à prendre avant de coder. Pour voir mes autres produits, consultez mes réalisations et les études de cas Equio, VetSafe et Ellyo. Si vous portez une plateforme ou un outil métier à construire, décrivez-moi votre besoin.