Retour

Portfolio

Health North – Application web médicale (BTS SIO SLAM E6)

Contexte & problématique

Health North est le projet principal de l'épreuve E6 du BTS SIO SLAM (Studi). Il s'agit d'une application web de réservation de rendez-vous médicaux en ligne, développée pour simuler la refonte du système d'information d'un groupe médical européen : 12 000 employés, 300 cliniques, 5 000 médecins, 8 millions d'analyses par an.

Problématique métier : les systèmes existants sont hétérogènes, difficiles à maintenir, peu sécurisés (API en accès libre, mots de passe sans politique de sécurité) et incapables de répondre aux exigences d'un marché concurrentiel à déclaration ARS obligatoire.

Objectif : concevoir une solution web complète — inscription, connexion, prise de rendez-vous guidée, suivi patient, administration back-end — déployée en production sur une infrastructure cloud réelle.

Architecture technique

                Navigateur patient (Bootstrap 5.3 + Bootstrap Icons)

                ↓

                Django 5 — Views · URLs · Templates · ORM

                ↓

                API REST interne (JSON — appels AJAX dynamiques)

                ↓

                PostgreSQL (Supabase — eu-west-3 Paris)

                ↓

                Render.com (hébergement production — déploiement auto GitHub)

                ↑

                GitHub (versionning · CI/CD · 10 Issues fermées)

Applications Django :
• accounts — modèle User (AbstractUser étendu : phone, address, date_of_birth)
• appointments — modèles Specialty, ExamType, Clinic, Specialist, Appointment, Document

Pourquoi ces technologies ? — Justification des choix

Pourquoi Django ?
Django intègre nativement l'authentification, la gestion des sessions, l'ORM et l'interface d'administration. Pour un projet médical avec gestion d'utilisateurs, de données sensibles et d'un back-office admin, c'est le framework le plus adapté en Python — pas besoin de réassembler des briques indépendantes.

Pourquoi PostgreSQL / Supabase ?
PostgreSQL est la base de données relationnelle la plus robuste en open source, avec un support complet des contraintes d'intégrité (clés étrangères, index, transactions). Supabase offre un hébergement managé en région Paris (eu-west-3), conforme aux exigences de proximité des données médicales, avec une interface d'administration claire.

Pourquoi Bruno plutôt que Postman ?
Bruno stocke les collections en fichiers texte brut (format Bru) directement versionnables dans Git. Chaque test API fait partie du dépôt GitHub, visible dans l'historique des commits. C'est une décision délibérée pour démontrer une démarche professionnelle de versioning — Postman stocke les collections dans le cloud Postman, invisible dans Git.

Pourquoi Bootstrap 5.3 ?
L'énoncé cible un projet médical professionnel avec un délai de formation contraint. Bootstrap permet un rendu responsive immédiat, des composants accessibles, et une maintenance facile sans dépendance à un build system complexe.

Pourquoi Render.com ?
Render propose un déploiement automatique sur push GitHub (CI/CD natif), une configuration des variables d'environnement sécurisée, et un plan gratuit suffisant pour un déploiement de démonstration. Alternative à Heroku avec une interface plus moderne et un déploiement plus simple.

Fonctionnalités réalisées — 5 missions

Mission 1 — Inscription & connexion
Création de compte patient, authentification Django (@login_required), gestion des sessions, redirections sécurisées post-connexion.

Mission 2 — Modification du profil
Mise à jour des informations personnelles (email, nom, prénom, adresse, téléphone) et changement de mot de passe sécurisé avec validation côté serveur.

Mission 3 — Parcours de prise de rendez-vous
Parcours guidé dynamique : région → ville → clinique → spécialiste → type d'examen → créneau. Chaque étape alimente la suivante via des appels AJAX à l'API REST interne. Dépôt de documents (ordonnance, certificat médical). Synthèse et confirmation.

Mission 4 — Liste des rendez-vous
Consultation du suivi patient : RDV passés et à venir, modification, annulation, téléchargement des documents déposés.

Mission 5 — Backend d'administration
Interface Django Admin configurée pour la gestion des spécialités, types d'examens, cliniques, spécialistes et rendez-vous.

API REST — 6 endpoints :
GET /api/cities/<region>/ · GET /api/clinics/<city>/ · GET /api/specialists/<clinic_id>/ · GET /api/exam-types/<specialist_id>/ · GET|POST /api/appointments/ · GET|PUT|DELETE /api/appointments/<id>/

Aperçu de l'application

Page d'accueil

Prise de rendez-vous

Liste des rendez-vous

Profil

Sécurité — mesures mises en place

Authentification & contrôle d'accès
Toutes les vues sensibles sont protégées par le décorateur @login_required de Django. Un utilisateur non connecté est automatiquement redirigé vers la page de connexion. Les rendez-vous sont filtrés par utilisateur côté serveur — un patient ne peut jamais accéder aux données d'un autre.

Protection CSRF
Django active la protection CSRF par défaut sur tous les formulaires POST. Chaque requête de modification inclut un token CSRF vérifié côté serveur, empêchant les attaques cross-site request forgery.

Variables d'environnement
La clé secrète Django (SECRET_KEY), les credentials PostgreSQL et les paramètres de connexion Supabase sont stockés exclusivement en variables d'environnement sur Render — jamais dans le code source ni dans Git.

Validation serveur
Toutes les entrées utilisateur sont validées côté serveur via les formulaires Django (ModelForm avec validation de champs). La validation côté client (HTML5) est un complément, jamais la seule barrière.

Mots de passe
Django utilise PBKDF2 avec SHA256 pour le hachage des mots de passe — standard recommandé. Les mots de passe ne sont jamais stockés en clair.

Scénario de modification — analyse d'impact

Exemple : ajout d'un système de notifications email de rappel avant les rendez-vous.

1. Base de données impactée ?

Ajout d'un champ booléen reminder_sent sur le modèle Appointment + migration Django.

2. Backend impacté ?

Création d'une commande Django management (send_reminders) qui interroge les RDV du lendemain et envoie un email via SendGrid ou SMTP Django. Planification via cron job ou Celery Beat.

3. API impactée ?

Non — la logique de rappel est interne, elle n'expose pas de nouvel endpoint public.

4. Frontend impacté ?

Ajout optionnel d'une case à cocher "Recevoir un rappel" dans le formulaire de confirmation de RDV (Mission 3).

5. Variables d'environnement impactées ?

Ajout de SENDGRID_API_KEY ou configuration SMTP dans les variables Render — jamais dans le code.

6. Tests à refaire ?

Test unitaire de la commande management + test d'intégration end-to-end (déclencher un RDV → vérifier l'email reçu en environnement de test).

Modélisation & documentation

• MCD — 7 entités modélisées (User, Specialty, ExamType, Clinic, Specialist, Appointment, Document)
• Diagramme de classes — représentation orientée objet de l'architecture
• Maquettes IHM — 7 écrans web + 4 écrans mobile + 3 écrans application lourde
• Script SQL PostgreSQL — 8 tables, contraintes, index, données de test
• Protocole de tests Bruno — 16 assertions, 100 % PASS en production

MCD — 7 entités

Diagramme de classes

Difficultés rencontrées

Authentification API avec Bruno — les endpoints sont protégés par @login_required, retournant du HTML au lieu de JSON sans session active. Résolu en configurant un flux d'authentification en pré-requête dans la collection Bruno (gestion du token CSRF + cookie de session sessionid).

Cold start Render (plan gratuit) — l'instance s'endort après 15 minutes d'inactivité, entraînant un délai de 30 à 60 secondes à la première requête. Documenté et communiqué, sans impact fonctionnel sur le projet d'examen.

Méthodes dynamiques Django ORM — les attributs générés dynamiquement (ex. appointment_set) déclenchaient des avertissements Pylint. Résolu avec des directives # pylint: disable=no-member ciblées et documentées.

Persistance des fichiers sur Render — Render ne persiste pas le système de fichiers entre déploiements. Les documents uploadés (ordonnances) sont perdus à chaque redéploiement. Point d'évolution identifié : migration vers Supabase Storage ou AWS S3.

Évolutions possibles

• Envoi automatique d'un email de confirmation et rappel SMS (SendGrid / Twilio)
• Stockage persistant des documents sur Supabase Storage
• API RESTful complète avec authentification JWT (Django REST Framework) pour une future app mobile
• Tableau de bord admin avec statistiques (taux d'occupation clinique, RDV par spécialité)
• Synchronisation agenda médecin en temps réel

Accéder au projet

🔗 Application en production 💻 Code source GitHub

Identifiants démo : patient1 / NewPass456!