Le laboratoire Galaxy Swiss Bourdin (GSB) est issu de la fusion entre le géant américain Galaxy et le conglomérat européen Swiss Bourdin, lui-même déjà union de trois petits laboratoires.
Le laboratoire désire moderniser l’activité de visite médicale. Il souhaite mettre à disposition des visiteurs médicaux une application permettant notamment de centraliser les comptes-rendus de visite.
Le contexte en détail :
Pour télécharger le cahier des charges :
Logiciels utilisés :
-Phpmyadmin pour la gestion et la configuration de la base de données
-Github/Gitlab pour déposer / récupérer le code facilement
-Qt Designer qui permet de créer des interfaces pour Qt
Langages utilisés :
-Python avec le framework FastAPI pour la partie back
-Python avec le framework PyQt pour réaliser l'interface utilisateur
Diagramme d'utilisation d'Applifrais :
Schéma de la base de donnée :
Pour l'existant nous avions seulement une base de données sous Access :
Cette application est un client lourd qui communique avec une base de données via l'API.
Elle a été réalisé en mode projet.
Qu'est ce qu'une API ?
Une API (application programming interface ou « interface de programmation d'application ») est une interface logicielle qui permet de « connecter » un logiciel ou un service à un autre logiciel ou service afin d'échanger des données et des fonctionnalités.
Voici un schéma qui illustre bien le fonctionnement d'une API →
L'API
Pour faire le plein de connaissances sur ce nouveau framework que je ne connaissais pas qu'est FastAPI, j'ai suivi ce tutoriel sur Youtube qui comprenait
tous les savoirs de base pour que je puisse développer cet API 
J'utilise des "models" et des "schémas".
Les models sont le reflet des tables dans la base de données, ce sont des objets que je peux utiliser pour
me servir de la base de données.
Les schémas sont des "moules" qui vont permettrent de dire à la route ce qu'elle doit reçevoir/renvoyer.
Les images ci-dessus sont les exemples du "model" Medecin, qui représente donc la table "Medecins" de la base de données ainsi que le schéma "showMedecin" qui est utilisée dans les routes "/medecins" et "/medecin/id". Le schéma indique donc à l'API ce qu'elle doit retourner.
La première étape : l'authentification
On a besoin d'un login et d'un mot de passe qui proviennent de la table Visiteur dans les champs LOG_LOGIN et LOG_MDP si la combinaison du login et du mot de passe haché correspondent à un enregistrement dans la base de données alors la route qui est "/login" nous renvoie un token qui est de type JWT (JSON Web Token). Ce token permet d'être identifié par l'API et donc de pouvoir envoyer des requêtes et reçevoir des réponses. L'API est sécurisée par ce token c'est à dire que si un utilisateur essaie d'utiliser les routes de l'api sans être authentifier et en possession du token, l'API n'est pas accessible.
Ensuite, j'ai crée toutes les autres routes
en suivant le modèle CRUD (Create, Read, Update, Delete) pour la plupart des tables.
Les routes qui sont le plus utilisées sont :
- "medecins" et "medecin/id" pour récupérer les médecins
- Toutes les routes de la section de "Rapport de visite"
- "visiteur/id" et "visiteurgroup/id"
- Toutes les routes de la section "Echantillons"
- Et la route d'authentification pour le login
Les tests unitaires :
Qu'est ce qu'un test unitaire ?
Le test unitaire est une méthode de test de logiciels qui consiste à tester des éléments ou des unités d'un logiciel.
L'objectif du test unitaire est de valider que chaque unité du logiciel fonctionne comme prévu.
Voici les exemples de test réalisés pour l'application. →