Plateforme de prise de rendez-vous pour professionnels de santé

Contexte

Un professionnel de santé veut proposer la prise de rendez-vous en ligne depuis son propre site, et gérer ses prestations, horaires, rendez-vous et patients depuis un back-office.

Problème et contraintes

• Des créneaux calculés à partir des horaires et des prestations, pas une grille figée.
• Aucune double réservation : un créneau choisi est retenu temporairement, puis confirmé.
• Un paiement en ligne optionnel, et un produit capable de servir plusieurs pays et organisations.

Décisions d'architecture et compromis

Douze décisions d'architecture sont documentées. Les principales :

• Monolithe modulaire à architecture hexagonale, conçu pour évoluer vers des services séparés si l'activité l'exige, sans en payer le coût dès le départ.
• PostgreSQL comme source de vérité des réservations : la cohérence transactionnelle prime sur un cache ou une file de messages pour cette donnée.
• Modèle de disponibilité dynamique : les créneaux sont dérivés des règles, pas stockés.
• API REST avec erreurs au format standard Problem Details, et événements transactionnels pour découpler les effets de bord (notifications) de l'écriture en base.
• Routage par organisation et par pays, et libellés configurables par organisation.

Sécurité et livraison

• Pipeline Jenkins : scan de secrets, analyse statique, tests backend, vérification du contrat OpenAPI, build du back-office, images, scan d'image, publication.
• Le merge vers la branche principale est une étape du pipeline : rien n'y arrive sans passer les contrôles.
• Livraison découpée en 13 phases documentées, chacune avec sa propre trace dans le dépôt.

Données

Le schéma évolue par migrations versionnées (24 fichiers de migration). L'accès d'un patient à ses rendez-vous fait l'objet d'une décision d'architecture dédiée.

Résultats et état actuel

• En production : API publique et back-office en ligne, version v1.0.0.
• 402 fichiers Java, 82 fichiers de tests et 12 décisions d'architecture dans le dépôt.