Nouveau site internet pour une clinique de télémédecine avec compte personnel, inscription en ligne et intégrations Stripe + Twilio (orienté HIPAA)

Situation initiale : une petite clinique de télémédecine ne dispose actuellement que d'une landing page sur Tilda sans inscription ni paiement. L'inscription se fait manuellement par email ; après paiement, le patient reçoit un lien vers un appel vidéo. En raison d'opérations manuelles, les applications sont perdues et il n'y a pas d'analyse normale.

Domaine et objectif : créer un nouveau site Internet avec une partie publique et un compte personnel du patient, où l'on pourra choisir une prestation et un médecin, s'inscrire à du temps gratuit, payer une consultation et recevoir un lien vers une séance vidéo. L'administrateur doit gérer la planification et les annulations. Un travail minutieux avec les données personnelles, la journalisation des actions et la minimisation du stockage des informations sensibles sont nécessaires.

Environnement technique et limites :
- Déployer sur le compte AWS existant du client (EC2 ou ECS, vous pouvez suggérer la meilleure option), domaine dans Route53
- Stack : Next.js 14 (App Router) + TypeScript, PostgreSQL (RDS), Prisma, Docker, Terraform ou AWS CDK pour l'infrastructure (partiellement acceptable, mais le déploiement doit être reproductible)
- Authentification : NextAuth ou équivalent avec lien magique par e-mail, protection contre la force brute, limitation de débit
- Paiement : Stripe Checkout + webhooks, traitement correct des statuts de paiement et des événements répétés
- Notifications : email (SES) et SMS (Twilio) concernant l'inscription/transfert/annulation
- Communication vidéo : génération d'un lien sécurisé vers la session via Twilio Vidéo (sans stockage des enregistrements)
- Données : ne stockez pas les documents médicaux et les diagnostics, visitez uniquement les métadonnées (service, heure, médecin, statut, paiement). Nous n’appliquons aucune note du médecin
- Langues : RU/EN (minimum 6 pages de la partie publique + compte)
- Design : peut être basé sur un kit d'interface utilisateur prêt à l'emploi (par exemple, shadcn/ui) sans rendu unique, mais avec un style unique

Résultat spécifique :
- Site public : accueil, services, médecins, tarifs, FAQ, contacts, politique de confidentialité
- Compte personnel du patient : inscription/connexion, profil, liste des visites, création d'une inscription, annulation/transfert dans les règles
- Panneau d'administration (vous pouvez avoir une simple section protégée) : gestion des médecins, des services, des plannings (créneaux horaires), visualisation des visites et des statuts de paiement, annulation manuelle
- Intégrations : Stripe (paiement), SES (email), Twilio (SMS et Vidéo), webhooks, journal des événements
- CI/CD : Actions GitHub pour la construction et le déploiement, .env.example et instructions de lancement

Étapes d'exécution (obligatoires) :
1) Brève analyse technique et diagramme de données/flux (enregistrement-paiement-appel-notifications) avec fixation des hypothèses
2) Implémentation des fonctions d'inscription et de paiement MVP avec des webhooks et un compte de base
3) Ajout de notifications et intégration de sessions vidéo
4) Section d'administration, tests, stabilisation, déploiement et documentation

Critères d'acceptation (mesurables) :
- L'utilisateur peut créer une entrée pour un créneau gratuit, payer via Stripe, après un webhook réussi, le statut de la visite passe à payant en 30 secondes maximum
- Des SMS et des emails sont envoyés lors de la création d'un dossier, d'un paiement réussi, d'une annulation et d'un transfert (le journal des envois réussis et des erreurs est à la disposition de l'administrateur)
- Le lien vers Twilio Video est disponible uniquement pour rendre visite aux participants et est actif dans l'intervalle : 10 minutes avant le début jusqu'à 60 minutes après le début, puis indisponible
- Tout accès au compte sans session sera redirigé vers le login, toutes les routes API sont protégées
- Au moins 15 autotests (unitaires/intégration) pour les scénarios critiques : création d'une visite, traitement du webhook, droits d'accès
- Lighthouse pour les pages publiques : Performance non inférieure à 80 sur mobile pour les pages principales et de services (hors scripts Stripe externes au moment du paiement)
- Instructions dans README : lancement local dans Docker, application des migrations, paramétrage des variables d'environnement, déploiement

Ce que je fournirai de ma part : un accès aux clés AWS, Stripe/Twilio/SES, des textes de pages (brouillons) et une liste de services/médecins en CSV. Il n'y a pas de fichiers de conception, une mise en œuvre minutieuse sur des composants prêts à l'emploi est autorisée.

Important : le projet est complexe en raison de la combinaison des plannings, des paiements, des webhooks, des restrictions d'accès et des infrastructures. Préférence pour une solution qui peut être prise en charge davantage sans magie ni modifications manuelles sur le serveur.