Application de gestion des équipements et de la maintenance pour un hôpital de district au Rwanda

Contexte

Projet tutoré d’école d’ingénieurs (ISIS, 2025–2026) commandé par l’hôpital de district de Kabutare, au Rwanda. L’application est le module 1 d’un système plus large de gestion hospitalière 
les équipements et leur maintenance. Après la soutenance d’avril 2026, j’ai poursuivi le travail sur place, à l’hôpital, pendant un stage de 10 semaines (mai–juillet 2026).

Problème

Les équipements informatiques, biomédicaux et d’infrastructure étaient suivis sur papier dans les différents services de l’hôpital. Rien ne permettait de signaler une panne de façon structurée, de suivre une réparation de la demande à la clôture, ni de planifier la maintenance préventive et les remplacements.

Mon rôle, l’équipe et la part de l’IA

Équipe de 4 étudiants. J’étais le développeur principal 
le rapport final du projet m’attribue le modèle de données, les fonctionnalités clés et la chaîne CI/CD. Une partie du code a été écrite avec Claude Code 
les conventions de code et un journal de vérification des fonctionnalités sont conservés dans le dépôt.

Contraintes

• Milieu hospitalier 
  plusieurs profils (personnel qui signale, superviseurs, techniciens spécialisés, administrateurs) aux droits différents.
• Interface bilingue 
  français et anglais.
• Déploiement local 
  l’application devait tourner sur un serveur de l’hôpital, en HTTPS, et s’installer sur les téléphones du personnel.
• Traçabilité 
  chaque intervention et chaque étape de la vie d’un équipement doivent rester visibles.

Solution et architecture

• Client 
  application Flutter, installable en PWA web et en APK Android, avec une interface français/anglais.
• Services 
  deux services Node.js/Express. auth-service gère les comptes via l’API d’administration de Keycloak et stocke les permissions applicatives 
  db-service gère équipements, signalements, sessions et rapports d’intervention, protocoles de maintenance préventive, inventaire et journal d’audit, sur SQLite.
• Identité 
  connexion par Keycloak 
  les services vérifient les jetons RS256 avec les clés publiées (JWKS), sans secret partagé. 17 permissions applicatives sont associées aux rôles.
• Parcours de signalement 
  choix de la catégorie d’abord, jusqu’à 5 photos par signalement, 10 statuts et 4 niveaux d’urgence 
  une réparation peut compter plusieurs sessions d’intervention et se termine par un rapport d’intervention en PDF.
• Cycle de vie des équipements 
  listes de contrôle de maintenance préventive, criticité ABC, plan de remplacement calculé à partir de la durée de vie prévue, et procédure de réforme qui conserve l’historique. L’inventaire physique est importé depuis un tableur.
• Notifications 
  e-mails transactionnels, notifications push web et rapport mensuel d’indicateurs.
• Déploiement 
  Docker Compose derrière nginx 
  un script de provisionnement installe une autorité de certification interne, le HTTPS, une page d’installation de la PWA avec affiche QR imprimable, les sauvegardes et les mises à jour.

Stack

Flutter et Dart, Node.js et Express, SQLite, Keycloak sur PostgreSQL, Docker Compose, nginx, Jenkins, Jest, push web.

Qualité et vérification

• 26 fichiers de tests Jest (droits par rôle, rapports d’intervention, sauvegardes, import CSV, cycle de vie des équipements, pagination) et 7 fichiers de tests Flutter.
• Un pipeline Jenkins en 10 étapes 
  analyse et tests de l’application Flutter, builds, publication des images, déploiement des environnements de production et de développement, contrôle de santé.
• Une auto-évaluation au regard des Rwanda Hospital Accreditation Standards (11 standards passés en revue, avec preuves dans le code et actions rapides), ainsi que des audits de l’interface, des traductions et de la connexion.

Résultats et statut

Le projet tutoré a été soutenu en avril 2026, puis le développement s’est poursuivi pendant le stage à l’hôpital (mai–juillet 2026). Aucun chiffre d’usage à l’hôpital n’est publié ici.

Ce que je ferais autrement

• Exclure du dépôt les fichiers générés et les dépendances dès le premier commit.
• Lancer les suites de tests automatiquement à chaque modification, et pas seulement dans le pipeline de déploiement.
• Séparer plus tôt les modèles de données des deux services, pour faire évoluer indépendamment les modules signalements et inventaire.

Liens

• Code source 
  une copie publique nettoyée est en préparation.
• Captures d’écran 
  à venir, sur des données de démonstration.