AI Agents Case Study

Comment j'ai construit Courtlines : un SaaS de gestion de club, conçu avec Claude

Alejandro Rioja
Alejandro Rioja
10 min de lecture
TL;DR

Courtlines est le système d'exploitation des clubs et studios de sports de raquette — réservations, adhésions, coaching, point de vente et événements sous un même toit à la marque du club. Je l'ai construit en tant qu'opérateur solo, avec Claude comme partenaire d'ingénierie. La leçon : l'IA ne m'a pas seulement fait coder plus vite, elle a changé la taille de produit qu'une seule personne peut crédiblement livrer et exploiter.

Newsletter gratuite

Chaque mercredi. 28 400+ opérateurs. Zéro superflu.

Sommaire

Mis à jour en juillet 2026.

En bref : Courtlines est le système d’exploitation des clubs et studios de sports de raquette — réservations, adhésions, coaching, point de vente et événements sous un même toit à la marque du club. Je l’ai construit en tant qu’opérateur solo, avec Claude comme partenaire d’ingénierie. La leçon : l’IA ne m’a pas seulement fait coder plus vite, elle a changé la taille de produit qu’une seule personne peut crédiblement livrer et exploiter.

[Le regard de l’opérateur] J’exploite plus de 30 agents en production répartis entre une marque de conseil et Pickleland, l’établissement de pickleball que je gère dans la métropole d’Austin, au Texas. Gérer un vrai établissement m’a appris précisément à quel point les logiciels pour des clubs comme le mien sont mauvais — j’ai donc construit le logiciel que j’aurais aimé avoir. Voici l’histoire de Courtlines, ce qu’il fait, et comment m’appuyer sur Claude a permis à une seule personne de bâtir ce qui demande habituellement toute une équipe.

Pourquoi un club a besoin d’un système d’exploitation, pas d’une application

Si vous n’avez jamais géré un établissement sportif, le problème logiciel est invisible. De l’extérieur, cela ressemble à « des gens réservent des terrains ». De l’intérieur, un club est une petite entreprise brouillonne avec une dizaine de rouages qui doivent tous s’accorder entre eux.

Un membre réserve un terrain. Cette réservation doit savoir s’il est sur une formule d’adhésion, s’il a des crédits, si le terrain est déjà bloqué pour un stage, si un coach est assigné, et si l’accueil a modifié le prix. Quand il arrive, quelqu’un lui facture un tube de balles au comptoir — c’est du point de vente. Il inscrit son enfant à un programme junior — ce sont les événements et les comptes famille. Il achète un pack de 10 leçons — c’est un forfait de coaching avec sa propre logique de reversement au coach. Il parraine un ami — c’est un tunnel d’adhésion.

La plupart des clubs font tourner tout cela sur trois ou quatre outils déconnectés, plus un tableur, plus un groupe de messages. Le système de réservation ignore le point de vente. Le point de vente ignore les adhésions. Les chiffres de personne ne concordent à la fin du mois.

Courtlines est la réponse à « et si tout cela ne formait qu’un seul système ? » Ce n’est pas une application de réservation avec des fonctionnalités greffées dessus — c’est un système d’exploitation unique où le calendrier, les adhésions, la caisse, les reversements de coaching et les pages d’événements publiques reposent tous sur les mêmes données sous-jacentes. C’est là toute la thèse, et c’est le slogan du site : le système d’exploitation des clubs et studios.

Ce que Courtlines fait vraiment

Vu de haut, Courtlines offre à un club :

  • Une grille de terrains en glisser-déposer pour l’accueil — chaque réservation, stage et blocage sur un seul écran qu’un administrateur peut réorganiser en temps réel.
  • La réservation et le jeu libre pour les membres, y compris les cas limites gênants mais essentiels : réservations récurrentes, listes d’attente, fenêtres d’annulation et crédits.
  • Les adhésions et la facturation — formules, comptes famille, connexions juniors/enfants rattachées à un parent, et les relances qui empêchent le revenu de fuir en silence.
  • Le coaching — forfaits de leçons, planification et reversements automatisés aux coachs indépendants.
  • Le point de vente — une vraie caisse pour la boutique et le café, reliée à la même fiche client que tout le reste.
  • Les événements et pages publiques — stages, ligues et tournois avec des pages accessibles au public que les gens peuvent trouver et où ils peuvent s’inscrire.

L’objectif de conception est que la plateforme disparaisse. Un club appose sa propre marque par-dessus, et pour ses membres cela ressemble simplement à « l’appli de notre club », pas à « un SaaS qu’on paie ». C’est un contraste délibéré avec les acteurs établis de ce secteur — les CourtReserve et Skedda de ce monde — où le logiciel est la marque et le club n’est que le locataire.

Pickleland est le tenant nº 1. Je ne peux pas me cacher derrière une démo ; le produit doit réellement faire tourner un établissement dont je suis personnellement responsable. Cette contrainte a été le meilleur chef de produit que j’aie jamais eu. Vous pouvez découvrir Pickleland ici — c’est le terrain d’épreuve réel, et chaque aspérité qu’un membre rencontre est un bug que je ressens le jour même.

Ce qui m’a surpris : ce qu’un seul opérateur peut désormais livrer

Voici la version honnête de l’histoire, et c’est la raison pour laquelle j’écris cet article plutôt que de lancer discrètement.

Un SaaS multi-tenant avec facturation, point de vente, accès basé sur les rôles, reversements de coaching et système d’événements publics n’est pas un projet de week-end. Il y a dix ans, c’était une équipe financée en amorçage de cinq à huit ingénieurs pendant un an. C’est le genre d’ampleur où l’on conseille gentiment à un fondateur solo de le réduire à une seule fonctionnalité et de lever des fonds.

Je l’ai construit tout seul, avec Claude comme partenaire d’ingénierie principal. Pas « j’ai parfois demandé un extrait à ChatGPT » — je veux dire que Claude a écrit la grande majorité du code de ce système, à partir de spécifications et de décisions produit dont je suis le propriétaire. Mon rôle est passé de taper l’implémentation à décider de ce qui est vrai : ce que doit être le modèle de données, ce qu’un rôle est autorisé à faire, ce que « terminé » signifie pour une fonctionnalité, et ce qu’il est sûr de livrer.

Le changement intéressant n’est pas la vitesse, même si c’est plus rapide. C’est l’ampleur. L’IA n’a pas fait de moi un développeur 2× sur un produit de la même taille. Elle a changé la taille du produit que je peux crédiblement construire et, tout aussi important, exploiter et maintenir seul. Une base de code écrite par un seul humain s’effondrerait sous son propre poids. Une base de code où un partenaire IA détient le détail de l’implémentation et où je détiens l’architecture et les garde-fous est une chose vraiment différente — et c’est la raison pour laquelle un opérateur solo peut désormais s’attaquer à une catégorie qui exigeait autrefois une entreprise.

Je ne publie délibérément pas ici mon plan de jeu opérationnel exact pour Courtlines — c’est la partie que je considère comme un avantage concurrentiel, et je préfère que mes concurrents continuent de croire que cela demande une grande équipe. Mais si vous voulez voir en détail les mécanismes de la façon dont je fais tourner Claude sur un vrai projet, j’ai tout consigné pour un build bien plus modeste : un jeu mobile que j’ai livré sur les app stores. Voyez comment j’ai construit Quads, un jeu de plateau mobile, avec Claude — même style de travail, rien à cacher, toutes les astuces sur la table.

Les principes sur lesquels je ne transigerai pas

Même en gardant le plan de jeu privé, quelques principes méritent d’être énoncés car ils s’appliquent à quiconque construit un logiciel sérieux avec l’IA :

L’humain tient les stylos dangereux. Il existe un petit nombre d’actions où une erreur coûte cher et est difficile à annuler — changements de schéma, déploiements, tout ce qui touche à l’argent ou aux données de production. Celles-là restent fermement de mon ressort. L’IA peut les proposer ; elle n’a pas le droit de les exécuter. Tracer cette ligne clairement est ce qui rend sûr de laisser beaucoup de latitude à l’IA partout ailleurs.

Des tests au vert sont nécessaires, mais pas suffisants. Un tunnel de réservation qui passe tous les tests unitaires peut quand même être visiblement cassé dans un vrai navigateur. La vérification la plus importante pour un produit doté d’une interface, c’est un humain — ou un processus supervisé — qui clique réellement à travers l’application avec des données réalistes. Les tests sont un gradient qui empêche les choses d’empirer ; ils ne sont pas la preuve qu’une fonctionnalité marche. J’ai appris celle-là à mes dépens, et cela a changé pour de bon ma façon de définir « terminé ».

Les spécifications sont la véritable interface. Le levier n’est pas dans un prompt astucieux — il est dans le maintien de documents clairs et à jour sur ce qu’est le système et ce que chaque partie est censée faire. Le temps passé à les garder précis se rembourse plusieurs fois sur chaque session future. Si vous voulez la version plus approfondie de cela, c’est la même discipline que je décris dans comment écrire des prompts système d’agents IA qui ne plantent pas en production.

Construisez la chose avec laquelle vous devrez vivre. La toute meilleure décision a été de faire tourner un établissement que je possède avec Courtlines. Il est facile de livrer une démo qui impressionne ; il est impossible de se cacher d’un logiciel dont vos propres membres dépendent. Si vous construisez avec l’IA, pointez-la vers un problème que vous ressentez personnellement — le retour au réel vaut plus que n’importe quelle suite de tests.

Où cela s’inscrit dans tout le reste de ce que je construis

Courtlines n’existe pas en vase clos. Il fait partie d’un petit écosystème de sports de raquette que je construis : The Court Scout est un annuaire vérifié de terrains de pickleball, conçu pour être réellement plus précis que les annuaires scrapés auxquels il fait concurrence, et Pickleland est l’établissement phare sur lequel tout est testé. L’annuaire aide les joueurs à trouver des terrains ; Courtlines aide les clubs derrière ces terrains à réellement fonctionner.

Le tissu conjonctif de tout cela, c’est le même modèle opérationnel : un opérateur solo amplifié par l’IA, gérant plus de surface qu’un opérateur solo ne l’aurait pu historiquement. Courtlines est l’expression la plus ambitieuse de ce modèle à ce jour — une plateforme SaaS complète que, il y a quelques années, je n’aurais tout simplement pas tenté d’entreprendre seul.

Si vous gérez un club ou un studio de sports de raquette et que vous en avez assez d’assembler quatre outils, jetez un œil à Courtlines. Et si vous êtes un bâtisseur qui se demande jusqu’où pousser l’IA sur un vrai produit, c’est tout le propos de cet article : plus loin que vous ne le pensez probablement.

FAQ

Qu’est-ce que Courtlines ?

Courtlines est un système d’exploitation multi-tenant pour les clubs et studios de sports de raquette — pickleball, tennis, padel et au-delà. Il réunit réservations, adhésions, coaching, point de vente et gestion d’événements sur une seule plateforme à la marque du club, pour qu’un club gère toute son activité depuis un système unique au lieu de quatre outils déconnectés. Vous pouvez le découvrir sur courtlines.com.

Claude a-t-il vraiment écrit la plupart du code ?

Oui. Claude a été mon partenaire d’ingénierie principal et a écrit la grande majorité de l’implémentation, à partir de spécifications, d’une architecture et de décisions produit dont je suis le propriétaire et que je contrôle. Je détiens le schéma, les déploiements et la définition de « terminé » ; l’IA détient le détail de l’implémentation. Cette répartition du travail est ce qui rend maintenable dans la durée un SaaS de cette ampleur construit en solo.

Une seule personne peut-elle vraiment construire et exploiter un SaaS aussi vaste avec l’IA ?

Le construire est désormais réellement faisable — c’est la partie surprenante. Le plus grand défi est de l’exploiter et de le maintenir, car une grande base de code a besoin de quelqu’un qui comprend l’architecture, même quand une IA a écrit les détails. La clé est de garder des spécifications claires et de rester ferme sur le petit nombre d’actions à haut risque qu’un humain doit détenir. Fait de cette façon, la surface maintenable pour un seul opérateur est bien plus vaste qu’auparavant.

Pourquoi construire votre propre logiciel de club plutôt que d’utiliser CourtReserve ou Skedda ?

Parce que gérer Pickleland m’a montré exactement où les outils existants sont défaillants : le système de réservation, la caisse et les adhésions ne partagent pas une seule source de vérité, si bien que rien ne se réconcilie proprement. Je voulais un système où tout repose sur les mêmes données sous-jacentes et où c’est la marque du club — pas celle de l’éditeur du logiciel — que voient les membres. C’est l’écart que Courtlines est conçu pour combler.

Où puis-je apprendre comment vous travaillez concrètement avec Claude au quotidien ?

Je garde le plan de jeu détaillé de Courtlines privé pour des raisons concurrentielles, mais j’ai documenté exactement le même style de travail sur un projet plus modeste et entièrement ouvert — un jeu de plateau mobile appelé Quads. Lisez comment j’ai construit Quads, un jeu de plateau mobile, avec Claude pour les mécanismes, ou comment je décide si une automatisation vaut la peine d’être construite pour le raisonnement de ROI derrière tout ce que je livre.

Continuer à lire

Articles liés

Continuer à lire

Recevez le guide IA dans votre boîte mail

Chaque mercredi. 28 400+ opérateurs. Zéro superflu.

↵ pour voir tous les résultats esc esc pour fermer