
e-Santé.net — Plateforme e-santé pour pharmacies et automatisation des tests
- Date : 2026
- Génie logiciel
- Terminé
Développement d’une application e-santé pour pharmacies (ASP.NET Core, Blazor), puis sa QA : tests UI Selenium + Pytest, tests API et sécurité xUnit, SonarQube — 67 cas de test.
Aperçu
e-Santé.net est une application web de e-santé orientée pharmacie, réalisée en binôme à l’IIT Sfax. Elle centralise patients, médecins, pharmaciens, pharmacies, médicaments, stock et ordonnances, des informations souvent dispersées dans une officine.
La plateforme repose sur une architecture en couches : interface Blazor Server, API REST ASP.NET Core sécurisée par jeton, couche métier et repositories Entity Framework Core sur SQL Server. Un tableau de bord pharmacien réalisé avec Radzen.Blazor présente l’activité, les ordonnances et l’état du stock.
Dans le module Test et Qualité logiciel, nous avons ensuite testé cette même application de bout en bout : automatisation de l’interface, tests d’intégration de l’API, tests de sécurité et de performance, et analyse statique, organisés en quatre sprints Scrum.
Chiffres clés
- cas de test traçables
- 67
- cas de test traçables
- modules fonctionnels couverts
- 9
- modules fonctionnels couverts
- ressources d’API testées
- 7
- ressources d’API testées
- défauts corrigés
- 5
- défauts corrigés
Technologies
Problème
Dans une officine, ordonnances, dossiers patients et stock sont souvent dispersés : leur historique est difficile à exploiter et le risque d’erreur augmente lors de la délivrance des médicaments.
Solution
Une plateforme web avec connexion sécurisée et accès par rôle, des pages CRUD pour chaque entité, des ordonnances vérifiées par rapport au stock de chaque pharmacie et un tableau de bord ; sa qualité a ensuite été vérifiée par des tests automatisés d’interface, d’API, de sécurité et statiques.
Ma contribution
En binôme : développement de la plateforme (pages Blazor, API REST, repositories, règles de stock), puis l’ensemble des tests — framework d’automatisation UI, suite de tests API, tests de sécurité et de performance xUnit, analyse SonarQube et documentation des tests.
Résultats
67 cas de test traçables sur 9 modules fonctionnels et 7 ressources d’API. Les tests de sécurité ont mis en évidence des erreurs 500 non gérées sur des requêtes non authentifiées ou malveillantes, et 5 défauts ont été corrigés.
Fonctionnalités
- Connexion et inscription avec authentification par jeton et accès selon le rôle (administrateur, pharmacien)
- CRUD des patients, médecins, pharmaciens, pharmacies, médicaments et stocks
- Ordonnances avec lignes de médicaments, quantité et posologie, vérifiées par rapport au stock de la pharmacie (erreur 400 explicite si le stock manque ou est insuffisant)
- Tableau de bord pharmacien avec graphiques et indicateurs Radzen.Blazor
- Framework d’automatisation UI Selenium + Pytest (Page Object Model) avec journalisation, marqueurs de priorité et captures d’écran en cas d’échec
- Tests d’intégration de l’API REST en Pytest avec une session authentifiée par JWT
- Tests de sécurité et de performance en C#/xUnit (contrôle d’accès, injection SQL, XSS, temps de réponse)
- Analyse statique SonarQube suivie de refactorisations ciblées
Captures d'écran
Création d’une ordonnance : patient, pharmacien, médecin et lignes de médicaments avec quantité et posologie, vérifiées par rapport au stock de la pharmacie.
Tableau de bord pharmacien réalisé avec Radzen.Blazor : chiffres clés, ordonnances et stock en un coup d’œil.
Détail d’une ordonnance : date, patient, médecin, pharmacien et médicaments délivrés.
Gestion des patients : les mêmes pages Liste / Création / Modification / Détail sont utilisées pour chaque entité.
Page de connexion : l’accès à l’application est protégé par une authentification par jeton.
Tests UI automatisés (Selenium + Pytest, Page Object Model) : résultats du module Patients, l’un des 9 modules couverts.
Documentation Swagger de l’API REST, référence des tests d’intégration Pytest.
Test de sécurité xUnit : une requête anonyme vers un endpoint protégé renvoyait une erreur 500 au lieu de 401/403, un défaut révélé par les tests.
Analyse statique SonarQube : anomalies de sévérité élevée, comme une complexité cognitive excessive, ensuite refactorisées.
