HOPITEL

Le patient avance. L’information doit suivre.

Le parcours de soins ne se résume pas à une consultation. Il commence par la recherche d’un établissement ou d’un service, se poursuit avec la prise de rendez-vous, puis avec la consultation et l’accès aux résultats. À chaque étape, plusieurs personnes ont besoin d’informations différentes sur une même situation.

HOPITEL est né de cette fragmentation. L’objectif du projet est de relier patients, médecins et hôpitaux dans une plateforme web et mobile, afin de penser le parcours dans sa continuité. Ce problème a servi de point de départ à notre projet de soutenance de licence, réalisé en binôme.

Deux interfaces, une logique partagée.

L’application mobile est construite avec Flutter et l’interface web avec React. Elles communiquent avec un backend Django REST Framework, relié à une base PostgreSQL. Le backend occupe la place centrale : il expose les échanges nécessaires aux interfaces et organise les données communes.

Cette séparation est importante. Une interface présente une action à l’utilisateur ; l’API reçoit sa demande ; la logique applicative détermine ce qui est autorisé et ce qui doit être enregistré. Les données ne dépendent donc pas de l’écran qui les affiche.

Le parcours visé commence par la recherche d’un établissement ou d’un service, avec une géolocalisation évoquée dans le périmètre. Il relie ensuite le rendez-vous à la consultation puis à l’accès aux informations patient et aux résultats. Il s’agit du parcours décrit par le projet, pas d’une démonstration que chaque étape est entièrement livrée.

Construire la partie qui relie le reste.

Ma contribution était principalement le développement backend. Mon travail se situe au niveau du socle applicatif : la relation entre les données, les échanges avec les interfaces et la logique qui permet aux différents acteurs de travailler dans un même système.

HOPITEL reste une réalisation de binôme. Les interfaces mobile et web font partie de l’architecture collective du projet ; je ne m’attribue pas seul leur conception et leur développement. Cette collaboration implique de penser le backend comme un contrat compréhensible par les autres parties de l’application.

Les permissions font partie du produit.

Un patient, un médecin et un acteur hospitalier ne doivent pas avoir les mêmes possibilités d’action. Dans ce type de système, identifier une personne ne suffit pas : chaque opération doit aussi être liée à un rôle et à un périmètre de données. C’est ce qui rend les comptes et les permissions structurants pour le backend.

Django REST Framework porte l’API et PostgreSQL constitue le socle de données relationnelles. L’authentification JWT est prévue dans l’architecture décrite. Flutter et React séparent les usages mobile et web tout en s’appuyant sur le même backend. Cette organisation rend les responsabilités lisibles : présentation, règles applicatives et données.

La confidentialité des informations de santé impose de distinguer un prototype fonctionnel d’un système prêt à être exploité. Une architecture cohérente est une base de travail ; elle ne vaut ni audit de sécurité ni validation médicale.

Un prototype présenté en soutenance.

Le projet de soutenance, réalisé en binôme, a été présenté le 8 juillet 2026 dans le cadre de ma formation en informatique et télécommunications à l’INSTI de Lokossa.

Il matérialise un travail de développement collectif autour d’un besoin concret, avec une architecture web et mobile et une contribution principalement backend de ma part.

Un prototype académique, pas un service hospitalier.

HOPITEL n’a pas été validé sur le terrain dans un établissement de santé. Aucun établissement utilisateur, impact médical ou gain de temps mesuré n’est revendiqué. Un hébergement technique ne constitue pas une exploitation hospitalière.

Le périmètre décrit comprend des comptes pour les patients, médecins, administrateurs d’établissement, administrateur général et laborantins ; la recherche avec géolocalisation ; les rendez-vous et consultations ; le dossier patient ; les résultats PDF avec code ; la messagerie, les notifications et un assistant conversationnel pour lequel une approche RAG a été évoquée. Ces éléments décrivent le périmètre discuté, mais les documents disponibles ne permettent pas d’établir lesquels ont été intégralement implémentés et testés. Je ne les présente donc pas comme autant de modules livrés.