D'un appel d'offre à un SaaS de santé conforme HDS, livré par une seule personne

Le contexte

Paulin Giraud n'est pas développeur. C'est un soignant (manipulateur en électroradiologie médicale dans un CHU) devenu l'un des meilleurs experts français d'un sujet réglementaire pointu : les Protocoles de Coopération entre professionnels de santé, qui permettent à des soignants de se déléguer des actes dans un cadre juridique précis. Aujourd'hui encore, ils se pilotent dans des fichiers Excel partagés.

Un décret de septembre 2025 a changé la donne : il rend obligatoire la déclaration annuelle de quatre indicateurs à la Haute Autorité de Santé, transmise à l'Agence Régionale de Santé, avec une première vague attendue début 2027. Des milliers d'établissements vont devoir structurer et tracer ce qu'ils géraient à la main. La fenêtre pour s'imposer comme l'outil de référence est étroite.

début 2027première campagne de déclaration des indicateurs HAS : le produit devait exister avant

Paulin avait la conviction produit et la connaissance du terrain. Il lui manquait une équipe technique.

Le défi

Un fondateur non-technique dans cette situation a 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, et impossible à présenter sérieusement en santé).

Et le produit attendu n'avait rien d'un site vitrine :

• Un SaaS de santé, avec une architecture multi-tenant stricte et une trajectoire d'hébergement de données de santé (HDS).
• Une complexité métier réelle : cinq rôles aux droits imbriqués, signature électronique, événements indésirables, export réglementaire vers l'ARS.
• Tout ce qui entoure le code : business plan, marque, design, traductions, infrastructure de production.

Le 25 avril, Paulin publie un appel d'offre. Deux jours plus tard, il a une proposition structurée et chiffrée sur la table.

Mon approche

01

Cadrer avant de coder

Comprendre et documenter le domaine réglementaire (Protocoles de Coopération, indicateurs HAS, déclaration ARS), écrire un business plan complet (marché, concurrence, modèle économique, go-to-market), travailler la marque avec un expert marketing, puis figer le périmètre du MVP dans un document signé par le client, qui devient la référence contractuelle du projet.

02

Un produit, cinq cibles

Une seule base de code (Expo / React Native) déployée sur web desktop, web mobile (PWA), iOS, Android et desktop. Une API Symfony 8 de 191 endpoints documentés, avec une base de données par établissement de santé. Un design system construit de zéro : 173 composants et leur vitrine Storybook.

03

La complexité métier, sans raccourci

Une signature électronique cryptographique sur la donnée elle-même, horodatée, avec une page publique de vérification. Un workflow d'événements indésirables à trois étages, avec suspension automatique du protocole pour les cas graves. Un export réglementaire qui produit le dossier attendu par l'ARS. Et une décision structurante prise avec le délégué à la protection des données : aucune donnée patient n'est stockée.

04

Une infrastructure de production, pas une démo

Un cluster Kubernetes bare-metal opéré par Talos, une base MongoDB répliquée, du GitOps avec ArgoCD, une observabilité complète, des sauvegardes chiffrées et des runbooks d'exploitation écrits à l'avance. Autour : six langues (~23 000 chaînes), 84 emails transactionnels, un staging public avec des données de démonstration pour les prospects.

Les résultats

En deux mois, Paulin est passé d'un appel d'offre à un produit qu'il met entre les mains de ses prospects, et qu'il a depuis lancé publiquement. Le voici, de la connexion à l'export réglementaire :

~72 %ratio test / code côté back : une base reprenable par une équipe, pas un prototype à jeter

• 3 000+ tests automatisés (back, parcours utilisateur, non-régression visuelle).
• 116 pages de documentation, dont 20 décisions d'architecture tracées et datées.
• 6 demandes sur 7 de la direction produit du client absorbées sans avenant.
• Un seul intervenant, du business plan au cluster Kubernetes.

Paulin n'a eu ni à recruter, ni à arbitrer entre cinq prestataires, ni à apprendre Kubernetes. Il a gardé la propriété de son code dès le premier jour, et il dispose d'un dépôt qui contient toute la mémoire de sa jeune entreprise : code, business, décisions, infrastructure.

Et après

Coopo est désormais commercialisé, et sa version suivante (plus d'une centaine de stories) est en cours. La méthode qui rend ce volume possible (mémoire de projet persistante, agents en parallèle, harnais de qualité automatique, revues externes à chaque phase) est détaillée dans l'article Cas client Coopo : un SaaS de santé complet livré en un seul Sprint Fondateur.

Pour aller plus loin : Sprint Fondateur.