Un SaaS de santé complet, livré en un seul Sprint Fondateur

Mon client n'est pas développeur. C'est un soignant devenu, au fil des années, l'un des meilleurs experts français d'un sujet réglementaire pointu : la traçabilité des actes médicaux que des professionnels de santé se délèguent entre eux. Le genre de chose qui, aujourd'hui encore, se pilote dans des fichiers Excel partagés. Il a une conviction produit claire et une fenêtre de marché qui se referme. Ce qu'il n'a pas, c'est une équipe technique.

Fin avril, il publie un appel d'offre. Deux jours plus tard, il a une proposition structurée et chiffrée sur la table. Deux mois plus tard, il a un SaaS de santé multi-tenant, multi-plateforme, conforme à l'hébergement de données de santé (HDS), qu'il montre déjà à ses prospects.

Les chiffres bruts : 130+ écrans, 191 endpoints d'API, 6 langues, un design system maison de 173 composants, 3 000+ tests automatisés. Le tout livré par une seule personne, dans l'enveloppe d'un Sprint Fondateur.

La question que tout le monde pose en découvrant ce volume est toujours la même : comment est-ce possible ? Cet article y répond honnêtement. Et la réponse n'est pas « l'IA écrit le code toute seule » — c'est une méthode de travail dont le code n'est qu'une des sorties.

Le « pourquoi maintenant » : une fenêtre réglementaire qui se referme

Un bon cas client commence toujours par l'urgence du client, pas par la prouesse du prestataire. Ici, l'urgence est réglementaire.

Le secteur fait évoluer son cadre : de nouvelles obligations de traçabilité et de déclaration s'imposent progressivement aux établissements de santé, avec une première échéance qui approche. Traduction business : des milliers d'établissements vont devoir, d'ici là, structurer et tracer ce qu'ils géraient jusqu'ici à la main. La fenêtre pour s'imposer comme l'outil de référence est étroite — il faut un produit crédible avant les concurrents, et avant la première campagne de déclaration. Quand le fondateur m'a contacté via une relation commune, le calendrier n'était pas négociable : le produit devait exister, vite, et être assez solide pour être montré à de vrais établissements de santé.

C'est exactement le type de situation où un fondateur non-technique se retrouve coincé entre trois mauvaises options : recruter un CTO (trois à six mois rien que pour le trouver), confier le projet à une agence (un prototype à jeter, zéro transfert de connaissance), ou bricoler en no-code (fragile, impossible à présenter sérieusement en santé). Le Sprint Fondateur est la quatrième voie.

Ce qui a été livré : toute la chaîne, pas seulement le code

Voilà le vrai cœur de l'histoire. Un fondateur non-technique n'a pas besoin que de code. Il a besoin de tout ce qui entoure le code — et c'est précisément ce qu'une équipe classique facture en plusieurs prestations séparées, étalées sur des mois. Sur ce projet, un seul interlocuteur a couvert l'intégralité de cette chaîne.

Avant la première ligne de code, il a fallu comprendre un domaine réglementaire dense et le documenter, écrire un business plan complet — analyse de marché, concurrence, modèle économique, go-to-market — et travailler la marque avec un expert marketing : naming, architecture de langage, ton de voix, personnalité. Puis cadrer le périmètre du MVP dans un document signé par le client, qui devient la référence contractuelle du projet.

Le produit lui-même est un SaaS de santé sérieux, pas un site vitrine. Une seule base de code — en Expo / React Native — se déploie sur cinq cibles : web desktop, web mobile (PWA), iOS, Android et même une application desktop. Côté serveur, une API en Symfony 8 expose 191 endpoints documentés, avec une architecture multi-tenant stricte : une base de données par établissement de santé. Le design system a été construit de zéro — typographies, palette, 173 composants, vitrine Storybook navigable — un produit dans le produit, souvent sous-estimé.

Autour du produit, il y a tout ce qu'on oublie de compter : l'internationalisation en six langues (près de 23 000 chaînes traduites), 84 emails transactionnels localisés, l'opérationnel IT du fondateur (gestion des DNS, migration de la messagerie de l'équipe vers Google Workspace), une plateforme de staging publique en ligne avec des données de démonstration — pour montrer le produit à des prospects — et la formation de l'équipe naissante.

Et sous le produit, l'infrastructure. Le produit est hébergé sur un cluster Kubernetes bare-metal, sur trois machines opérées par Talos OS, avec une base MongoDB en réplication, un moteur de recherche, un bus de messages, le tout piloté en GitOps avec ArgoCD. Observabilité complète (métriques, logs, alertes), sauvegardes chiffrées résistantes à la double panne, et des runbooks d'exploitation rédigés à l'avance : que faire si deux nœuds tombent, comment restaurer la base, comment faire tourner les clés. Ce n'est pas une démo posée sur un Heroku — c'est une infrastructure de production conçue pour la santé. J'ai détaillé l'anatomie exacte de ce type de cluster dans un article technique dédié.

Le périmètre en chiffres

Quelques repères du périmètre livré, donnés avec leur point de comparaison — parce qu'un chiffre seul ne dit rien à un dirigeant.

La ligne la plus importante n'est pas le nombre d'écrans. C'est le ratio test / code. Cinquante-cinq mille lignes de test pour soixante-seize mille lignes de back, ce n'est pas du « vibe coding » jeté après démo — c'est une base testée, maintenable, reprenable par une équipe technique sans réécriture à zéro. Pour un fondateur qui devra un jour recruter ou lever des fonds, c'est la différence entre un actif et une dette. Le sujet n'est pas neuf : j'avais documenté ce même harnais de tests sur un autre projet livré à 0 régression.

Non, ce n'est pas « juste du CRUD »

L'objection naturelle, en voyant ces chiffres, c'est : « d'accord, mais c'est peut-être simple ». Ça ne l'est pas, et c'est ce qui rend le volume d'autant plus parlant. Quelques exemples concrets de complexité métier réelle :

• Un modèle de droits à cinq rôles imbriqués, avec des affectations fines par périmètre et des dérivations de rôles — la matrice de qui peut faire quoi, à quel niveau, est tout sauf triviale.
• Une signature électronique cryptographique : pas un simple PDF tamponné, mais une signature Ed25519 sur la donnée elle-même, horodatée selon un standard reconnu, avec une page publique de vérification. Les attestations PDF sont régénérées à la volée depuis la donnée signée, si bien qu'un changement de charte graphique ne casse aucune signature passée.
• Un workflow de signalement à trois étages (déclaration, investigation, acquittement), avec suspension automatique du processus pour les cas graves.
• Un export réglementaire qui génère le dossier de déclaration annuelle attendu par l'autorité de santé, les indicateurs requis injectés automatiquement.
• Une authentification multi-voies (passkey, code temporaire, lien magique) configurable établissement par établissement, et un journal d'audit infalsifiable.

Décision structurante prise avec le délégué à la protection des données : aucune donnée patient n'est stockée. L'acte tracé n'est jamais relié à un patient identifiable. C'est le genre d'arbitrage qui ne se code pas — il se décide, en comprenant à la fois le métier, le droit et le risque. C'est précisément ce qu'un fondateur non-technique ne peut pas attendre d'une agence au forfait.

La vraie réponse à « comment c'est possible » : la méthode

On y arrive. Ce débit n'est pas le fruit d'un copier-coller d'IA. Il vient d'une manière de travailler qui transforme l'IA en force de production fiable plutôt qu'en générateur de dette. Cinq piliers.

Une mémoire de projet persistante. Chaque décision, chaque persona, chaque contrainte réglementaire est écrite dans une mémoire structurée, versionnée dans le dépôt, que les agents rechargent à chaque session de travail. Résultat : zéro contexte reperdu entre deux journées. C'est le socle, et je l'ai décrit en détail dans Le monorepo-mémoire. Pour le client, c'est un bénéfice direct : toute la pensée du projet — pas seulement le code — lui est transmise et reste interrogeable.

L'orchestration d'agents en parallèle. Les lots de travail indépendants sont confiés à des sous-agents lancés simultanément, puis recomposés. C'est ce qui multiplie le débit sans multiplier les erreurs — à condition de savoir découper le travail, ce qui relève de l'expérience, pas de l'outil.

Un harnais de qualité automatique. La qualité n'est pas une affaire de discipline, elle est dans le tuyau : à chaque commit, le code est vérifié (typage, accessibilité, suite de tests complète), le contrat d'API typé est régénéré automatiquement du back vers le front, et rien n'est déployé si un test casse. C'est ce qui permet de garder 3 000+ tests verts pendant qu'on avance vite.

Un regard externe à chaque phase. À la fin de chaque étape, un agent indépendant — sans le contexte de la session — audite le travail cumulé et rend un rapport. Sept revues de ce type ont été produites sur ce projet. C'est l'équivalent, en solo, de la revue de code d'un pair : un garde-fou contre l'angle mort de celui qui a la tête dans le guidon.

La documentation comme livrable de première classe. Vingt décisions d'architecture tracées et datées, 116 pages versionnées, une page d'avancement publique pour le client. Pour un produit qui vise une trajectoire de certification en santé, cette traçabilité décisionnelle n'est pas un luxe : c'est un actif de confiance, pour un audit comme pour un investisseur.

Le fil conducteur, si je devais le résumer en une phrase : un fondateur non-technique n'a pas besoin d'une équipe de six personnes pendant six mois. Il a besoin d'un partenaire qui couvre toute la chaîne — du business plan au cluster Kubernetes — et d'une méthode qui transforme l'IA en force de production fiable. Cette conviction, je l'ai développée ailleurs : l'IA n'invente pas l'expertise, elle l'amplifie. Sans vingt ans de terrain pour trancher les choix structurants, ce même volume aurait produit une montagne de dette.

Le résultat

En deux mois, le fondateur est passé d'un appel d'offre à un produit qu'il met entre les mains de ses prospects. Il n'a pas eu à recruter, à arbitrer entre cinq prestataires, ni à apprendre Kubernetes. Il a gardé la propriété de son code dès le premier jour, sa maîtrise stratégique du produit, et il dispose d'un monorepo qui contient toute la mémoire de sa jeune entreprise — code, business, décisions, infrastructure.

Pourquoi ce cas est anonyme — pour l'instant

Vous l'avez remarqué : pas de nom, pas de captures d'écran, pas de démo dans cet article. C'est volontaire. Le produit n'est pas encore lancé publiquement — son éditeur le dévoilera à la rentrée, en septembre. D'ici là, la discrétion fait partie du métier : quand un client me confie son projet, je protège son avantage concurrentiel autant que son code.

En revanche, la méthode, elle, se partage. Si vous voulez une démo privée de la méthode — pour juger sur pièces avant de vous décider — écrivez-moi sans hésiter. On regarde votre projet ensemble, sans engagement.