Public visé : administrateurs, superviseurs médicaux, agents des opérations et du support. Périmètre : modules de supervision temps réel du back-office — Live Operations, Parcours Patients et Présence Utilisateurs. Dernière mise à jour : 29 mai 2026.
Ce manuel décrit l'utilisation des modules de supervision opérationnelle de Dokta na Ndaku. Ces modules permettent aux équipes de :
- suivre en temps réel les missions médicales à domicile et les téléconsultations ;
- visualiser la position géographique des prestataires et des patients ;
- surveiller l'état du parcours de chaque patient (de la recherche d'un soignant jusqu'à la clôture) ;
- détecter automatiquement les situations à risque (retards, blocages, consultations abandonnées) ;
- intervenir directement (assignation manuelle, ré-affectation, annulation, clôture, gestion d'incidents).
Tous ces écrans s'actualisent automatiquement grâce à la synchronisation temps réel (Supabase Realtime) : aucune action de rafraîchissement manuel n'est nécessaire, même si un bouton « Actualiser » reste disponible.
Les modules sont accessibles depuis la barre latérale du back-office (/admin), dans le groupe Opérations :
| Menu | Module | Permissions requises |
|---|---|---|
| Live Operations | Console de supervision temps réel (2.1) | operations.live.read, operations.incidents.read/manage, ou admin.access |
| Parcours Patients | Suivi du parcours patient (2.2) | operations.live.read + patients.read |
| Présence Utilisateurs | Présence en ligne/hors ligne (2.2) | operations.live.read + users.read |
Si un menu n'apparaît pas, votre rôle ne dispose pas des permissions correspondantes. Contactez un Super Administrateur (module Rôles & permissions).
Menu : Opérations → Live Operations
La console Live Operations est la tour de contrôle des opérations. Elle agrège, sur un seul écran, les indicateurs clés, la carte temps réel, les missions actives, les prestataires sur le terrain, les téléconsultations et les incidents.
En haut de l'écran, une série de cartes affiche les compteurs opérationnels en direct : missions actives, prestataires disponibles, alertes opérationnelles, incidents ouverts, téléconsultations en cours, etc. Ces compteurs se mettent à jour instantanément à chaque changement de statut.
La carte (propulsée par Mapbox) affiche la localisation géographique des missions en cours et des prestataires sur le terrain.
- Marqueurs prestataires : colorés selon leur statut opérationnel (voir §5).
- Marqueurs missions : position du patient pour chaque mission active.
- En cliquant sur un marqueur, une infobulle présente les informations essentielles (nom, statut, etc.).
- La carte ajuste automatiquement son cadrage pour englober tous les points actifs.
Pré-requis technique : la carte nécessite la variable d'environnement
VITE_MAPBOX_TOKENet des coordonnées GPS renseignées sur les missions/prestataires. En l'absence de jeton, un message « Token Mapbox manquant » s'affiche à la place de la carte.
L'onglet missions liste toutes les missions actives (statuts : payment_pending, dispatching, assigned, accepted, in_transit, in_progress, report_pending, validation_pending). Pour chaque mission, sont affichés : le patient, le soignant assigné, le statut, le temps d'attente et les actions disponibles.
Le système calcule automatiquement des drapeaux d'alerte lorsqu'une mission dépasse un seuil de service (SLA). Une mission portant au moins un drapeau est signalée à risque.
| Drapeau | Condition de déclenchement |
|---|---|
| SLA prise en charge > 15 min | Mission en dispatching ou assigned depuis plus de 15 minutes |
| Paiement en attente prolongée | Mission en payment_pending depuis plus de 10 minutes |
| Aucun soignant après 3 tentatives | Aucun prestataire assigné et ≥ 3 tentatives de dispatch |
| Acte en cours anormalement long (> 2 h) | Mission in_progress depuis plus de 120 minutes (nouveau — voir §11) |
| Rapport non soumis (> 12 h) | Mission report_pending depuis plus de 12 heures (nouveau — voir §11) |
Important — articulation avec l'automatisation backend : un traitement automatique (
auto-cancel-missions, exécuté chaque minute) gère déjà les blocages précoces : annulation après 30 min endispatching, ré-affectation après 10 min sans acceptation (max 5 tentatives), annulation après 1 h sans arrivée du prestataire. Les drapeaux ci-dessus couvrent surtout les états que l'automatisation ne résout pas (acte en cours, rapport non soumis).
La console affiche les prestataires actifs et leur statut opérationnel, calculé en temps réel :
| Statut | Signification | Règle |
|---|---|---|
| Disponible (vert) | Prêt à recevoir une mission | KYC validé, disponible, signal récent (< 10 min) |
| En mission (violet) | Affecté à une mission active | A une mission en cours |
| Hors ligne (gris) | Inactif | Aucun signal depuis plus de 10 minutes |
| Indisponible (orange) | Non opérationnel | KYC non validé ou indisponibilité déclarée |
Un onglet dédié suit les sessions de téléconsultation, avec les compteurs actif / en attente, la durée des sessions et la possibilité de clôturer de force une session bloquée.
| Drapeau | Condition |
|---|---|
| Salle ouverte sans démarrage | Session pending depuis plus de 15 minutes |
| Session active anormalement longue (> 90 min) | Session active depuis plus de 90 minutes (nouveau — voir §11) |
La console intègre une liste d'incidents opérationnels. Chaque incident possède une catégorie, une sévérité et un statut.
- Catégories :
dispatch_timeout,no_provider_in_range,provider_delay,payment_failed,teleconsultation_failure,patient_complaint,gps_tracking_lost,other. - Sévérités : faible, moyenne, élevée, critique.
- Statuts : ouvert, en cours, résolu, annulé.
Certains incidents sont créés automatiquement (ex. timeout de dispatch après 3 tentatives, échec de paiement). Le durcissement complet du module incidents relève de la Phase 2.3.
Toutes les actions sont sécurisées côté serveur (permissions vérifiées) et journalisées (audit). Elles transitent par la fonction backend admin-live-operations.
| Action | Description |
|---|---|
Assignation manuelle (assign_mission) |
Affecter une mission à un prestataire précis. Motif obligatoire. |
Ré-affectation (redispatch_mission) |
Remettre la mission en dispatching et relancer la recherche. |
Annulation (cancel_mission) |
Annuler une mission avec motif administrateur (remboursement éventuel). |
Résolution d'incident (resolve_incident) |
Marquer un incident comme résolu avec notes. |
Escalade d'incident (escalate_incident) |
Escalader vers un rôle admin/médical. |
Clôture de téléconsultation (force_end_teleconsultation) |
Terminer de force une session bloquée. |
- Repérer une mission en attente d'assignation (
dispatching/assigned). - Choisir un prestataire (l'interface propose les prestataires proches).
- Cliquer sur Assigner, saisir un motif (obligatoire), puis confirmer.
- La mission passe en
assigned. L'action est tracée dans l'audit.
Menu : Opérations → Parcours Patients
Cet écran offre une vue synthétique du parcours de chaque patient, en consultation à domicile comme en téléconsultation, de la demande initiale jusqu'à la clôture.
Cinq cartes résument la situation en haut de l'écran :
| Carte | Contenu |
|---|---|
| Patients actifs | Nombre de patients distincts suivis + nombre en ligne |
| Missions actives | Missions en recherche / attente / consultation + nombre en consultation |
| Téléconsultations | Téléconsultations actives + nombre de sessions en cours |
| Temps d'attente moyen | Durée moyenne (missions terminées) |
| Consultations interrompues | Nombre de parcours détectés comme abandonnés/sans suite (nouveau) |
La carte Consultations interrompues passe en orange dès qu'au moins une consultation est détectée comme interrompue, pour attirer l'attention du superviseur.
Chaque parcours est classé dans l'un des états suivants, identifiable par un badge coloré :
| État | Badge | Signification |
|---|---|---|
| En recherche | bleu | Recherche d'un prestataire / paiement en attente |
| En attente | jaune | Prestataire assigné/accepté, en attente de prise en charge |
| En consultation | violet | Acte médical / téléconsultation en cours |
| Interrompue | orange |
Consultation abandonnée ou sans suite (nouveau — voir §11) |
| Terminée | vert | Consultation achevée |
| Annulée | rouge | Mission/rendez-vous annulé(e) |
| Inconnu | gris | État non déterminé |
Correspondance avec les statuts techniques :
- Missions :
payment_pending/dispatching→ recherche ;assigned/accepted→ attente ;in_transit/in_progress/report_pending→ consultation ;completed/validation_pending→ terminée ;cancelled→ annulée. - Téléconsultations :
pending→ recherche ;confirmed(salle en attente) → attente ; sessionactive→ consultation ;completed/sessionended→ terminée ;cancelled→ annulée.
Chaque fiche patient présente :
- Identité : nom, téléphone, ville ; statut de présence (en ligne / hors ligne avec dernière activité).
- Badges : état du parcours, type de service.
- Chronologie : heure de la demande, temps passé dans l'état actuel, prestataire assigné (+ spécialité), localisation et motif.
- Pied de fiche : statut technique de la mission et tarif.
Une fiche dont l'état est Interrompue est entourée d'un liseré orange pour la distinguer visuellement.
Une barre de filtres permet d'affiner l'affichage :
- Recherche : nom, téléphone, ville ou motif.
- État : filtre par état du parcours (la liste inclut automatiquement Interrompue).
- Service : consultation, injection, pansement, prélèvement.
- Période : dernière heure, 24 h, 7 jours, ou tout.
- Missions — liste des parcours « domicile » (avec compteur).
- Téléconsultations — liste des parcours « téléconsultation » (avec compteur).
- Analytics — répartition horaire de la demande (voir §10).
L'onglet Analytics présente les patterns de demande sur 7 jours : demandes totales, consultations terminées, temps d'attente moyen, et une répartition horaire détaillée par service. Utile pour anticiper les pics d'activité et dimensionner les prestataires disponibles.
Le système détecte automatiquement les consultations qui stagnent dans un état avancé sans aboutir. Cette détection est visuelle : elle met en évidence les cas à examiner, sans modifier les données ni déclencher d'action automatique (la persistance et la création automatique d'incidents sont prévues en Phase 2.3).
Un parcours bascule en état Interrompue lorsque :
| Cas | Condition |
|---|---|
| Mission — acte en cours | Statut in_progress depuis plus de 120 minutes |
| Mission — rapport non soumis | Statut report_pending depuis plus de 12 heures |
| Téléconsultation — session active trop longue | Session active depuis plus de 90 minutes |
| Téléconsultation — absence (no-show) | Rendez-vous confirmed, fin planifiée dépassée de plus de 30 minutes, aucune session démarrée |
Ces seuils sont complémentaires de l'automatisation backend, qui annule déjà les états précoces (dispatching, assigned, accepted). Ils ciblent volontairement les états « tardifs » qui, sinon, resteraient invisibles.
- Le parcours affiche le badge orange « Interrompue » et sa fiche reçoit un liseré orange.
- La carte « Consultations interrompues » s'incrémente et passe en orange.
- Le parcours sort du compteur « actives » (il n'est plus considéré comme un parcours nominal en cours).
- Il devient filtrable via l'état Interrompue.
Les mêmes seuils sont appliqués dans la console Live Operations : l'état interrupted y est désormais affiché, et des drapeaux d'alerte correspondants apparaissent (acte trop long, rapport non soumis, session active trop longue — voir §4.1 et §6). Les deux écrans présentent ainsi une lecture cohérente des situations à risque.
Menu : Opérations → Présence Utilisateurs
Cet écran suit la présence en ligne / hors ligne de tous les acteurs (patients, prestataires, partenaires, administrateurs).
- Statut : en ligne / hors ligne, avec dernière activité datée.
- Activité courante :
idle(inactif),browsing(navigation),in_consultation(en consultation),in_mission(en mission),waiting(en attente). - Détection automatique du hors-ligne : un utilisateur est marqué hors ligne après 5 minutes sans signal (la présence prestataire terrain utilise un seuil de 10 minutes dans Live Operations).
- Filtres : par statut (en ligne/hors ligne) et par onglet/type d'utilisateur ; recherche par nom.
- Commencer la journée par Live Operations pour repérer d'un coup d'œil les missions à risque et les incidents ouverts.
- Surveiller la carte « Consultations interrompues » dans Parcours Patients : tout passage à l'orange signale un cas à examiner (prestataire injoignable ? acte non clôturé ? no-show ?).
- Filtrer par état Interrompue pour traiter en lot les consultations bloquées.
- Toujours renseigner un motif lors d'une assignation manuelle ou d'une annulation — ces actions sont auditées.
- Croiser présence et parcours : un patient « en consultation » mais « hors ligne » depuis longtemps peut indiquer une session abandonnée.
- La détection des consultations interrompues est visuelle uniquement ; la persistance d'un statut, la création automatique d'incidents et les notifications/escalades associées sont prévues en Phase 2.3.
- La matrice de sévérité des alertes reste à affiner.
- Les dates/heures des rendez-vous sont interprétées en heure locale (sans fuseau) pour le calcul du no-show — suffisant pour la supervision, à préciser si une multi-zone stricte devient nécessaire.
- La carte dépend de la présence des coordonnées GPS et du jeton Mapbox.
| Domaine | Seuil | Effet |
|---|---|---|
| Dispatching sans prestataire | 30 min | Annulation auto (backend) |
| Assigné sans acceptation | 10 min | Ré-affectation auto, max 5 tentatives (backend) |
| Accepté/En route sans arrivée | 1 h | Annulation auto (backend) |
| Prise en charge (dispatching/assigned) | 15 min | Drapeau « SLA > 15 min » |
| Paiement en attente | 10 min | Drapeau « Paiement prolongé » |
| Salle téléconsultation sans démarrage | 15 min | Drapeau « Salle ouverte sans démarrage » |
Acte en cours (in_progress) |
120 min | État Interrompue + drapeau |
Rapport non soumis (report_pending) |
12 h | État Interrompue + drapeau |
| Session téléconsultation active | 90 min | État Interrompue + drapeau |
| No-show téléconsultation (après fin planifiée) | 30 min | État Interrompue |
| Présence utilisateur (hors ligne) | 5 min | Marquage hors ligne |
| Présence prestataire terrain (hors ligne) | 10 min | Statut « Hors ligne » |
| Module | Menu | Composant technique |
|---|---|---|
| Console Live Operations | Live Operations | AdminLiveOperations |
| Parcours Patients | Parcours Patients | AdminPatientJourney |
| Présence Utilisateurs | Présence Utilisateurs | AdminUserPresence |
| Actions opérationnelles (backend) | — | Edge function admin-live-operations |
| Annulation/ré-affectation auto (backend) | — | Edge function auto-cancel-missions (cron, chaque minute) |
Menu : Opérations → Incidents
Page dédiée à l'historique complet des incidents (contrairement à l'onglet Live Operations qui ne montre que les incidents non résolus).
- Cartes KPI : Ouverts · En cours · Escaladés · Résolus (7 jours).
- Filtres : statut (ouvert/en cours/résolu/annulé), catégorie (8 types), sévérité (4 niveaux), période (24h/7j/30j/tout) et recherche texte.
- Liste : chaque incident affiche catégorie, sévérité, statut, badge d'escalade, patient/prestataire/mission liés et notes de résolution.
- Actions (si permission
operations.incidents.manage) : Résoudre (notes obligatoires) et Escalader (vers un rôle N2/médical). Mêmes actions auditées que Live Operations.
Bouton « Nouvel incident » (visible avec operations.incidents.manage) → dialog : catégorie, sévérité, titre, description, et ID mission optionnel. L'incident est créé en statut ouvert, audité (live_ops.create_incident), et visible immédiatement dans la liste.
Menu : Opérations → Console Support
Vue unifiée d'un utilisateur pour le support client.
- Recherche par nom, téléphone ou ville.
- Une fois l'utilisateur sélectionné : en-tête (identité, présence) + compteurs (missions, incidents ouverts, transactions), puis onglets : Missions (statut, tarif, date), Incidents (catégorie, sévérité, statut), Transactions (montant, méthode, statut).
- Permet à un agent de comprendre tout le contexte d'un patient sans naviguer entre plusieurs écrans.
Dans le dialog d'assignation manuelle (Live Operations → mission en dispatching → « Manuelle »), les prestataires candidats sont désormais classés par score pondéré — identique à l'algorithme de dispatch automatique :
- Distance 50 % + Note 30 % + Expérience 20 % (score le plus bas = meilleur).
- Chaque candidat affiche distance, note (★) et statut ; le meilleur porte un badge « Recommandé ».
Le système crée automatiquement des incidents pour les consultations qui stagnent (en complément de la détection visuelle de la Phase 2.2). Exécuté à chaque cycle de auto-cancel-missions (chaque minute).
| Cas détecté | Incident créé | Sévérité |
|---|---|---|
Mission in_progress > 120 min |
provider_delay (Retard de prise en charge) |
Haute |
Mission report_pending > 12 h |
provider_delay |
Haute |
Téléconsultation active > 90 min |
teleconsultation_failure |
Moyenne |
| Téléconsultation no-show (> 30 min après fin planifiée) | teleconsultation_failure |
Moyenne |
- Anti-duplication : un nouvel incident n'est créé que s'il n'existe pas déjà un incident
ouvert/en courspour la même ressource et catégorie — pas de doublon même si la détection tourne chaque minute. - Une notification est envoyée au patient concerné.
- Ces incidents apparaissent automatiquement dans la page Incidents, dans l'onglet incidents de Live Operations, et incrémentent les compteurs.
Note de déploiement : la détection auto repose sur la migration
…_phase2_3_interrupted_incident_detection.sql. Tant qu'elle n'est pas appliquée à l'environnement, les incidents correspondants n'apparaissent pas (les écrans, eux, fonctionnent et listent les incidents existants).
Document de référence — Back-Office Dokta na Ndaku, Phases 2.1, 2.2 & 2.3. À compléter au fil des évolutions (matrice de sévérité, couverture d'audit support, notifications avancées).