Groupe B

Rapport de Mini
projet UML
UML & METHODES AGILES

Rafat DJOBO,chaimae Hachad,Nabile Lahmer

11/06/2025
Projet :Application Web de Gestion d’un Cabinet
Medical

Responsables Module:
Mme Mouhim Sanaa

Menbre de Groupe (Groupe B):

Rafat DJOBO

Chaimae Hachad

Nabil Lahmer

1
Présentation du Projet

Ce document détaille la conception d'une plateforme web dédiée à la gestion

optimisée d'un cabinet médical. L'objectif est de proposer un outil numérique
performant, simplifiant à la fois les tâches administratives et le suivi médical.

L'application a été pensée pour fluidifier les échanges entre les différents intervenants
: médecins, secrétaires, patients et administrateurs. Elle couvre l'intégralité des
processus clés, de la planification des consultations au suivi des traitements, en
passant par la gestion financière.
Pour assurer une modélisation précise, ce rapport s'appuie sur le langage UML
(Unified Modeling Language), offrant une vision structurée et cohérente de
l'architecture logicielle.

2.1 Vue Globale du Système

Cette solution digitale a été développée pour moderniser et automatiser les

opérations courantes d'un cabinet médical. Grâce à une interface web intuitive, elle
centralise de manière sécurisée les données médicales et administratives.

2.2 Fonctionnalités Clés

Les principales fonctionnalités répondent aux besoins suivants :

2.2.1 Gestion des Patients

— Création et mise à jour des profils patients

— Consultation et modification des données personnelles
— Archivage des dossiers inactifs
— Stockage des documents médicaux (examens, imagerie, etc.)
— Visualisation de l'historique de santé

2.2.2 Organisation des Consultations

— Réservation en temps réel selon les créneaux disponibles

— Modification ou annulation de rendez-vous
— Consultation des plannings par praticien ou par jour

2
— Envoi automatisé de notifications (SMS/email)
— Suivi des absences

2.2.3 Suivi Clinique

— Saisie des comptes-rendus de consultation

— Enregistrement des diagnostics
— Édition d'ordonnances numériques
— Historique complet des consultations
— Ajout d'annotations médicales

2.2.4 Administration Générale

— Édition et suivi des factures

— Gestion des encaissements
— Paramétrage des utilisateurs
— Configuration des préférences du cabinet
— Production de statistiques et rapports d'activité

2.3 Rôles et Interactions

2.3.1 Secrétariat

Acteur pivot de l'organisation, le secrétariat assure :

— La tenue des dossiers patients
— La coordination des rendez-vous
— L'émission des factures
— L'accueil et l'orientation des patients
— La gestion des relances et confirmations

2.3.2 Médecin

Le praticien utilise le système pour :

— Accéder aux dossiers médicaux
— Rédiger des comptes-rendus
— Établir des diagnostics

3
— Prescrire des traitements
— Consulter son emploi du temps
— Analyser des indicateurs cliniques

2.3.3 Patient

L'interface patient permet :

— La visualisation des informations personnelles
— L'accès à son parcours de soins
— La prise de rendez-vous en autonomie
— La consultation des prescriptions
— Le téléchargement de documents

2.3.4 Administrateur

Responsable de la maintenance, l'administrateur gère :

— Les comptes utilisateurs
— Les paramètres système
— La sécurité des données
— Les sauvegardes
— Les droits d'accès

3.1 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation presente une vue globale des interactions entre les
acteurs et le syst`eme.

4
3.2 Diagramme de classes
Le diagramme de classes represente la structure statique du syst`eme et les relations
entre les differentes entites.
Personne
- id : int
- nom : string
- prenom : string
- dateNaissance : date
- adresse : string
- telephone : string

5
 - email : string

+ ajouterAllergie() : void + authentifier() : boolean + getCreneauxLibres() :

+ () : + changerMotConsultation*..1-
getDossierMedical
-
DossierMedical1..
1 - : date *..1-+date :

6
3.3 Diagrammes de sequence
3.3.1 Authentification d’un utilisateur

Figure 3.3 – Diagramme de sequence - Authentification

3.3.2 Creation d’un rendez-vous

Figure 3.4 – Diagramme de sequence - Creation d’un rendez-vous

7
 11
3.4 Diagrammes d’activites
3.4.1 Processus de consultation medicale

9
3.5 Diagrammes d’etats
3.5.1 Etats d’un rendez-vous

Figure 3.6 – Diagramme d’etats - Cycle de vie d’un rendez-vous

Architecture Logicielle

4.1 Architecture choisie

L’application adopte une architecture moderne basee sur le mod`ele MVC (Model-
ViewController) etendu avec une approche en couches et orientee services. Cette
architecture garantit une separation claire des responsabilites et facilite la maintenance
et l’evolution du syst`eme.

4.1.1 Architecture en couches

L’architecture se decompose en plusieurs couches distinctes :
10
 1. Couche Presentation : Interface utilisateur web responsive
2. Couche API : Services REST pour la communication
3. Couche Metier : Logique metier et r`egles de gestion
4. Couche Persistance : Acc`es et gestion des donnees
5. Couche Infrastructure : Services transverses (securite, logs, cache)

4.1.2 Principes architecturaux

— Separation des preoccupations : Chaque couche a une responsabilite unique
— Faible couplage : Les couches communiquent via des interfaces
— Reutilisabilite : Les services metier sont independants de la presentation
— Scalabilite : Architecture permettant la montee en charge
— Securite : Authentification et autorisation a` tous les niveaux

4.2 Description des modules

4.2.1 Module Frontend
— Technologie : Angular 17 ou React 18 —
Responsabilites :
— Affichage des interfaces utilisateur
— Gestion des interactions utilisateur
— Validation cˆote client
— Communication avec l’API REST
— Composants principaux :
— Composants d’authentification
— Tableaux de bord par rˆole
— Formulaires de gestion
— Composants de visualisation

4.2.2 Module Backend API

— Technologie : Spring Boot 3.x (Java 17) —
Responsabilites :
— Exposition des endpoints REST
— Validation des donnees
— Gestion des transactions
— Orchestration des services —
Endpoints principaux :
— /api/auth : Authentification
— /api/patients : Gestion des patients
— /api/appointments : Gestion des rendez-vous
— /api/consultations : Consultations medicales

11
 — /api/invoices : Facturation

4.2.3 Module Services Metier

— Services principaux :
— PatientService : Gestion compl`ete des patients
— AppointmentService : Logique des rendez-vous
— MedicalService : Consultations et prescriptions
— BillingService : Facturation et paiements
— NotificationService : Envoi de notifications
— StatisticsService : Generation de statistiques

4.2.4 Module Securite

— Technologie : Spring Security + JWT —
Fonctionnalites :
— Authentification par JWT
— Autorisation basee sur les rˆoles
— Chiffrement des donnees sensibles
— Audit et journalisation
— Protection CSRF et XSS

4.2.5 Module Persistance

— Technologie : JPA/Hibernate —
Base de donnees : PostgreSQL 15 —
Fonctionnalites :
— Mapping objet-relationnel
— Gestion des transactions
— Cache de second niveau
— Migrations avec Liquibase

4.3 Technologies envisagees

4.3.1 Stack technique
Categorie Technologie Justification
Frontend Angular/React Frameworks modernes et
performants
Backend Spring Boot Framework Java mature et robuste
Base de donnees PostgreSQL SGBD relationnel open source fiable
Cache Redis Performance et scalabilite
Messagerie RabbitMQ Communication asynchrone fiable
Stockage fichiers MinIO Compatible S3, auto-hebergeable
12
Conteneurisation Docker Deploiement standardise
Orchestration Kubernetes Gestion des conteneurs en
production
CI/CD GitLab CI Integration continue compl`ete
Monitoring Prometheus + Grafana Surveillance temps reel
Table 4.1 – Stack technique de l’application

13
 Chapitre 5

Mod`ele de Donnees

5.1 Schema de base de donnees relationnelle

Le mod`ele de donnees est con¸cu pour garantir l’integrite referentielle et optimiser
les performances. Voici la structure detaillee des principales tables.

5.1.1 Tables principales

CREATE TABLE personne ( id SERIAL PRIMARY KEY, nom VARCHAR(100) NOT

NULL, prenom VARCHAR(100) NOT NULL, date_naissance DATE NOT
NULL, adresse TEXT, telephone VARCHAR(20), email VARCHAR(150)
UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Listing 5.1 – Table Personne

1

CREATE TABLE utilisateur ( id SERIAL

PRIMARY KEY,
personne_id INTEGER REFERENCES personne(id), login VARCHAR(50)
UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL CHECK (role IN (’ADMIN’, ’MEDECIN’, ’
SECRETAIRE’)), actif BOOLEAN
DEFAULT true,
date_creation TIMESTAMP DEFAULT CURRENT_TIMESTAMP, derniere_connexion TIMESTAMP,
CONSTRAINT fk_personne FOREIGN KEY (personne_id) REFERENCES personne
(id)
);

Listing 5.2 – Table Utilisateur

CREATE TABLE patient ( id SERIAL

PRIMARY KEY,

14
 personne_id INTEGER REFERENCES personne(id), numero_securite_sociale
VARCHAR(15) UNIQUE, groupe_sanguin VARCHAR(5), allergies TEXT[],
antecedents TEXT[], medecin_traitant_id INTEGER REFERENCES medecin(id),
date_inscription DATE DEFAULT CURRENT_DATE, actif BOOLEAN DEFAULT true,
CONSTRAINT fk_personne_patient FOREIGN KEY (personne_id) REFERENCES personne(id)

);

Listing 5.3 – Table Patient

CREATE TABLE medecin ( id SERIAL PRIMARY KEY, utilisateur_id INTEGER

REFERENCES utilisateur(id), numero_ordre VARCHAR(50) UNIQUE NOT NULL,
specialite VARCHAR(100) NOT NULL, tarif_consultation DECIMAL(10,2)
DEFAULT 50.00, duree_consultation_minutes INTEGER DEFAULT 30,
CONSTRAINT fk_utilisateur_medecin FOREIGN KEY (utilisateur_id)
REFERENCES utilisateur(id)
);

Listing 5.4 – Table Medecin

CREATE TABLE rendez_vous ( id SERIAL PRIMARY KEY, patient_id

INTEGER REFERENCES patient(id), medecin_id INTEGER
REFERENCES medecin(id), date_heure TIMESTAMP NOT NULL,
duree_minutes INTEGER DEFAULT 30, motif TEXT,
statut VARCHAR(20) DEFAULT ’PLANIFIE’
CHECK (statut IN (’PLANIFIE’, ’CONFIRME’, ’EN_COURS’, ’TERMINE’,
’ANNULE’, ’MANQUE’)),
notes TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP
DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_patient_rdv FOREIGN KEY (patient_id) REFERENCES patient(id),
CONSTRAINT fk_medecin_rdv FOREIGN KEY (medecin_id) REFERENCES medecin(id),
CONSTRAINT uk_medecin_datetime UNIQUE (medecin_id, date_heure) );

Listing 5.5 – Table Rendez-vous

15
CREATE TABLE consultation ( id SERIAL PRIMARY KEY, rendez_vous_id INTEGER
REFERENCES rendez_vous(id), patient_id INTEGER REFERENCES patient(id),
medecin_id INTEGER REFERENCES medecin(id),
date_consultation TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
motif_consultation TEXT NOT NULL, symptomes TEXT, diagnostic TEXT,

Listing 5.6 – Table Consultation

observations TEXT, poids DECIMAL(5,2), taille

DECIMAL(5,2), tension_arterielle VARCHAR(20),
temperature DECIMAL(4,2),
CONSTRAINT fk_rdv_consultation FOREIGN KEY (rendez_vous_id) REFERENCES rendez_vous(id),
CONSTRAINT fk_patient_consultation FOREIGN KEY (patient_id) REFERENCES patient(id),
CONSTRAINT fk_medecin_consultation FOREIGN KEY (medecin_id)
REFERENCES medecin(id)

);

CREATE TABLE ordonnance ( id SERIAL PRIMARY KEY, consultation_id INTEGER

REFERENCES consultation(id), numero_ordonnance VARCHAR(50) UNIQUE NOT
NULL, date_prescription DATE DEFAULT CURRENT_DATE, validite_jours INTEGER
DEFAULT 30, instructions_generales TEXT,
CONSTRAINT fk_consultation_ordonnance FOREIGN KEY (consultation_id)
REFERENCES consultation(id)
);

Listing 5.7 – Table Ordonnance

CREATE TABLE ligne_ordonnance ( id SERIAL PRIMARY KEY, ordonnance_id

INTEGER REFERENCES ordonnance(id), medicament VARCHAR(200) NOT
NULL, dosage VARCHAR(100), frequence VARCHAR(100), duree
VARCHAR(100), instructions TEXT,
CONSTRAINT fk_ordonnance_ligne FOREIGN KEY (ordonnance_id)
REFERENCES ordonnance(id)
);

Listing 5.8 – Table Ligne Ordonnance

Listing 5.9 – Table Facture

16
CREATE TABLE facture ( id SERIAL PRIMARY KEY, consultation_id INTEGER REFERENCES
consultation(id), numero_facture VARCHAR(50) UNIQUE NOT NULL,
date_facture DATE DEFAULT CURRENT_DATE, montant_total DECIMAL(10,2)
NOT NULL, montant_paye DECIMAL(10,2) DEFAULT 0, statut VARCHAR(20)
DEFAULT ’EN_ATTENTE’
CHECK (statut IN (’EN_ATTENTE’, ’PAYEE’, ’PARTIELLE’, ’ANNULEE’)
), mode_paiement
VARCHAR(50), date_paiement DATE,
CONSTRAINT fk_consultation_facture FOREIGN KEY (consultation_id)
REFERENCES consultation(id)
);

5.1.2 Tables de support

CREATE TABLE document_medical ( id SERIAL PRIMARY KEY, patient_id INTEGER

REFERENCES patient(id), consultation_id INTEGER REFERENCES consultation(id),
type_document VARCHAR(50) NOT NULL, nom_fichier VARCHAR(255) NOT
NULL, chemin_fichier TEXT NOT NULL, taille_octets BIGINT, mime_type
VARCHAR(100), date_upload TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
uploaded_by INTEGER REFERENCES utilisateur(id),
CONSTRAINT fk_patient_doc FOREIGN KEY (patient_id) REFERENCES patient(id),
CONSTRAINT fk_consultation_doc FOREIGN KEY (consultation_id)
REFERENCES consultation(id)
);

Listing 5.10 – Table Document Medical

CREATE TABLE creneau_horaire ( id SERIAL PRIMARY KEY, medecin_id INTEGER REFERENCES

medecin(id), jour_semaine INTEGER CHECK (jour_semaine BETWEEN 1 AND 7),
heure_debut TIME NOT NULL, heure_fin TIME NOT NULL, actif BOOLEAN DEFAULT true,
CONSTRAINT fk_medecin_creneau FOREIGN KEY (medecin_id) REFERENCES medecin(id),
CONSTRAINT uk_medecin_jour_heure UNIQUE (medecin_id, jour_semaine, heure_debut)
);

Listing 5.11 – Table Creneaux Horaires

5.1.3 Tables d’audit et de securite
Listing 5.12 – Table Journal d’Audit

17
CREATE TABLE audit_log ( id SERIAL PRIMARY KEY, utilisateur_id INTEGER
REFERENCES utilisateur(id), action VARCHAR(100) NOT NULL, entite
VARCHAR(100) NOT NULL, entite_id INTEGER, anciennes_valeurs JSONB,
nouvelles_valeurs JSONB, ip_adresse INET, user_agent TEXT, timestamp
TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

5.2 Traduction des classes UML vers des tables SQL

La traduction du mod`ele objet vers le mod`ele relationnel suit les principes suivants :
5.2.1 Heritage
L’heritage entre les classes est gere par des relations de cles etrang`eres :
— La classe Personne est referencee par Patient et Utilisateur
— La classe Utilisateur est referencee par Medecin

5.2.2 Associations
Les associations sont traduites selon leur cardinalite :
— 1..1 : Cle etrang`ere NOT NULL avec contrainte UNIQUE
— 1..* : Cle etrang`ere NOT NULL
— *..* : Table de liaison (non utilisee dans ce mod`ele)

5.2.3 Optimisations
— Index sur les cles etrang`eres pour ameliorer les jointures
— Index sur les champs frequemment recherches (email, numero SS)
— Contraintes CHECK pour garantir l’integrite des donnees
— Triggers pour la mise `a jour automatique des timestamps

18
 Contraintes et Choix de Conception

6.1 Choix techniques

6.1.1 Architecture microservices vs monolithique
Nous avons opte pour une architecture monolithique modulaire pour les raisons
suivantes :
— Simplicite : Plus facile a` developper et deployer pour une equipe reduite
— Performance : Pas de latence reseau entre les modules
— Coherence : Transactions ACID garanties sur l’ensemble des donnees
— Evolutivite : La modularite permet une migration future vers des microservices

6.1.2 Base de donnees relationnelle

Le choix de PostgreSQL se justifie par :
— Integrite referentielle : Essentielle pour les donnees medicales
— Transactions ACID : Garantie de coherence des donnees
— Support JSON : Flexibilite pour les donnees semi-structurees
— Performance : Excellent pour les requˆetes complexes

6.1.3 API REST

L’utilisation d’une API REST offre :
— Standardisation : Protocole HTTP bien maˆıtrise
— Stateless : Scalabilite horizontale facilitee
— Compatibilite : Support natif dans tous les frameworks
— Documentation : Outils comme Swagger/OpenAPI

6.2 Contraintes de securite

6.2.1 Protection des donnees medicales
— Chiffrement des donnees sensibles en base
— Communications HTTPS obligatoires
— Authentification forte avec double facteur
— Journalisation compl`ete des acc`es
6.2.2 Conformite reglementaire
— Respect du RGPD pour les donnees personnelles
— Conformite aux normes de sante (HDS)
— Duree de conservation legale des donnees
— Droit a` l’oubli et portabilite

19
6.3 Contraintes de performance
6.3.1 Temps de reponse
— Page d’accueil : ¡ 2 secondes
— Recherche patient : ¡ 1 seconde
— Generation de rapports : ¡ 5 secondes
— Sauvegarde consultation : ¡ 500ms

6.3.2 Capacite
— Support de 1000 patients actifs minimum
— 50 utilisateurs simultanes
— Historique de 5 ans minimum
— Stockage de 10 GB de documents

6.4 Choix d’interface utilisateur

6.4.1 Responsive Design
— Utilisation sur desktop, tablette et mobile
— Framework CSS moderne (Bootstrap ou Material)
— Progressive Web App pour l’acc`es hors ligne

6.4.2 Accessibilite
— Conformite WCAG 2.1 niveau AA
— Support des lecteurs d’ecran
— Navigation au clavier compl`ete
— Contraste eleve et tailles adaptables

20
 Maquettes des Interfaces Graphiques

7.1 Page de connexion

Cabinet Medical - Connexion

Identifiant
Mot de passe
Se connecter
Mot de passe oublie?

Figure 7.1 – Maquette - Page de connexion

7.2 Tableau de bord Secretaire
Cabinet Medical Mme Dupont (Secretaire) Deconnexion
Menu Tableau de bord - Aujourd’hui
15 3
Rendez-vous du jour En salle d’attente

• Tableau de bord Heure Patient Medecin Statut

14 :00 M. Martin Dr. Dub ois Confirme
Prochains rendez-vous
14 :30 Mme Durand Dr. Dub ois En attente
15 :00 M. Bernard Dr. Mar tin Confirme
• Patients
• Rendez-vous
• Agenda
• Facturation
• Statistiques

Figure 7.2 – Maquette - Tableau de bord secretaire

21
7.3 Fiche patient
Fiche Patient - M. Jean MARTIN
Informations personnelles Informations medicales
Ne le : 15/03/1975 N° SS : 1 75 03 75 XXX XXX
Adresse : 12 rue de la Paix Groupe sanguin : O+
75001 Paris Allergies : Penicilline
Tel : [Link].89 Medecin traitant : Dr. Dubois
Email : [Link]@[Link]

Modifier Nouveau RDV Historique

Date Medecin Motif Actions

Derni`eres consultations 10/01/2025 Dr. Contrˆole Voir
Dubois
15/12/2024 Dr. Grippe Voir
Martin
Figure 7.3 – Maquette - Fiche patient
7.4 Interface de consultation (Medecin)
[Link] Date:18/06/2025
Motif Douleurs abdominales

Symptˆomes

Examen clinique

Diagnostic Gastrite aigu¨e

Omeprazole 20mg - 1/jour - 14 jours
Prescription Spasfon - Si douleurs - 7 jours
+ Ajouter

Imprimer
Enregistrer Annuler
ordonnance

Figure 7.4 – Maquette - Interface de consultation

22
7.5 Module de statistiques
Statistiques du Cabinet

Periode : Juin 2025 Type : Mensuel Actualiser

Indicateurs cles

Cons RDV Taux occupation Chiffre d’affaires

ultati annules
ons
245 12 87% 12,250€
(4.9%)

Repartition par medecin Evolution mensuelle

[Graphique camembert] [Graphique courbe]

Dr. Dubois : 45% Jan-Juin 2025
Dr. Martin : 35% Tendance : +15%
Dr. Bernard : 20%
Exporter Exporter
PDF Excel
Figure 7.5 – Maquette - Module de statistiques

Chapitre 8

Conclusion
Ce rapport de conception UML presente une vision compl`ete et detaillee de
l’application de gestion de cabinet medical. L’utilisation des differents diagrammes UML a
permis de modeliser tous les aspects du syst`eme, depuis les interactions utilisateurs
jusqu’a` l’architecture technique.

8.1 Points cles de la conception

— Architecture modulaire : Facilite la maintenance et l’evolution
— Securite renforcee : Protection des donnees medicales sensibles
— Interface intuitive : Adaptee aux differents profils d’utilisateurs
— Performance optimisee : Reponse aux besoins d’un cabinet moderne
— Conformite reglementaire : Respect des normes medicales et RGPD

8.2 Perspectives d’evolution

Le syst`eme est con¸cu pour evoluer avec les besoins futurs :

23
 — Integration de teleconsultation
— Module de prise de rendez-vous en ligne avance
— Intelligence artificielle pour l’aide au diagnostic
— Interconnexion avec d’autres syst`emes de sante
— Application mobile native
Cette conception servira de reference tout au long du developpement, garantissant que
l’application finale repondra parfaitement aux besoins exprimes tout en restant evolutive
et maintenable.

24