Dashboard central
Vue temps réel des demandes entrantes, missions du jour, urgences, remplacements, alertes critiques, taux de couverture et satisfaction.
- Tour de contrôle opérationnelle
- Widgets KPI live
- Priorisation des actions critiques
Cette page sert de blueprint produit pour l’équipe IT chargée de concevoir le progiciel de gestion opérationnelle AngelCare. Objectif : centraliser les demandes, le matching, la planification, les incidents, la qualité, la facturation et les reportings dans une seule web app scalable.
Le système doit couvrir l’ensemble du moteur opérationnel décrit dans le brief : dashboard central, familles, intervenantes, matching intelligent, missions, planning, incidents, qualité, communication, packs, RH et reporting. fileciteturn0file0
Vue temps réel des demandes entrantes, missions du jour, urgences, remplacements, alertes critiques, taux de couverture et satisfaction.
Fiche parent complète avec enfants, besoins, créneaux, historiques, préférences, incidents passés, paiement et tags de sensibilité.
Base profils ultra détaillée : zones, transport, disponibilités, compétences, certifications, documents, scoring, retards, no-show et statut RH.
Proposition automatique des meilleures intervenantes selon zone, disponibilité, compétence, expérience, historique qualité et urgence. fileciteturn0file0
Cycle complet d’une demande vers une mission exécutable, avec statuts, consignes, superviseur, check-in/out et rapport post-mission.
Dispatch board visuel en vue jour / semaine / mois / ville / famille / intervenante, avec glisser-déposer et détection de conflits. fileciteturn0file0
Module vital pour absorber annulations, retards et changements de dernière minute, avec recherche remplaçante et notifications multi-acteurs.
Contrôle de l’exécution terrain via validation horaire, géolocalisation approximative, photo optionnelle, code famille ou signature parent.
Compte rendu post-mission : déroulé, humeur de l’enfant, activités, repas, sieste, hygiène, incidents, recommandations et retour parent.
Collecte automatisée du feedback, notes basses transformées en ticket qualité, suivi des réclamations, fidélisation et score par intervenante. fileciteturn0file0
Centre d’envoi rapide WhatsApp, email, notifications internes et modèles de messages pour confirmations, changements, relances et feedback.
Suivi des abonnements, heures achetées, consommées, restantes, paiements familles, montants dus aux intervenantes, bonus et pénalités.
Le brief recommande une V1 en web app backoffice avec dashboard, missions, planning, matching, qualité, incidents, familles et intervenantes, avant l’ouverture vers une app mobile intervenante et un portail parent. fileciteturn0file0
Cœur transactionnel centralisant les workflows, le moteur de matching, les règles métier, les états mission, la qualité et les automatisations.
Le système doit être pensé autour d’objets fortement liés pour garantir la traçabilité de bout en bout : demande → matching → mission → exécution → qualité → facturation. fileciteturn0file0
Le dashboard doit permettre à la responsable des opérations de voir immédiatement les missions du jour, le taux de couverture, les alertes critiques, les retards, les remplacements en attente et les familles actives. fileciteturn0file0
Le brief décrit deux scénarios structurants : cas normal et cas incident. Le système doit permettre d’orchestrer ces deux parcours sans friction. fileciteturn0file0
Demande parent créée via backoffice, téléphone, formulaire ou canal commercial.
Validation du besoin, des horaires, de la zone, des enfants, des contraintes et du niveau d’urgence.
Top profils proposés automatiquement avec score, proximité, compétences et historique.
Sélection opérateur, notification des parties, mise à jour planning et verrouillage du créneau.
Mission réalisée avec check-in, consignes, rapport terrain et éventuels incidents.
Feedback parent, scoring qualité, consommation du pack, reporting et actions de suivi.
Structure pensée pour guider les développeurs front et back sur la navigation, les blocs de données à exposer et les actions prioritaires dans chaque écran.
Le vrai gain du progiciel vient des automatisations : création dossier, suggestions de profils, messages automatiques, tickets qualité et alertes commerciales ou RH. fileciteturn0file0
Le brief définit sept rôles utilisateurs : responsable opérations, coordinatrice, qualité/support, RH, finance/admin, intervenante et famille/parent. fileciteturn0file0
Accès total. Pilotage global, dispatch, urgences, arbitrages, supervision KPI.
Accès missions, planning, matching, communication et gestion quotidienne.
Accès incidents, satisfaction, feedback, réclamations, tickets qualité.
Accès profils, onboarding, documents, formations, évaluations.
Accès paiements, factures, heures validées, règlements et pénalités.
Accès limité mobile : planning, consignes, navigation, check-in/out, rapport.
Portail simplifié : historique, missions, paiements, feedback, suivi pack.
Permissions fines par domaine, par action et par niveau de sensibilité des données.
Approche par phases pour sécuriser la valeur métier d’abord, puis enrichir avec applications périphériques, scoring avancé et intelligence opérationnelle.
Domain model, UX maps, permissions, states, glossary métier, composants UI communs.
Dashboard, familles, intervenantes, demandes, missions, planning, matching simple, incidents, qualité basique.
Notifications, feedback auto, packs, consommation, relances, alertes RH et commerciales.
App mobile intervenante, portail parent, moteur de matching enrichi, analytics poussés, centre qualité complet.
La réussite dépendra autant de la qualité UX opérationnelle que de la robustesse des états, des permissions et de la traçabilité des actions.
| Risque | Impact | Réponse recommandée |
|---|---|---|
| Explosion des cas métier | Complexité non maîtrisée, bugs sur les statuts mission | Définir très tôt une state machine claire pour demandes, missions, incidents, paiements. |
| UX trop lourde pour les ops | Adoption faible, contournements manuels | Concevoir autour d’actions rapides, vues “Aujourd’hui” et “À risque”, filtres forts, 3 clics max. |
| Matching opaque | Perte de confiance de l’équipe opérationnelle | Afficher les sous-scores et permettre l’override humain avec justification. |
| Données non traçables | Litiges qualité, difficulté d’audit | Historiser actions critiques, messages, check-in/out, changements d’affectation et incidents. |
| Notifications défaillantes | Retards de réaction et parents mal informés | Prévoir queue, retry, statuts d’envoi, fallback et centre d’alertes interne. |
Ci-dessous, une lecture orientée développement pour structurer les tables principales, les clés utiles et les liens métier les plus importants. L’objectif est de rendre le système traçable, modulaire et extensible.
Une API modulaire par domaines métier permettra de faire évoluer le backoffice, le mobile intervenante et le portail parent sans casser le noyau central.
Pour une expérience premium, l’interface doit ressembler à un vrai SaaS de pilotage avec sidebar, topbar, vues synthétiques et panneaux de détails actionnables.
Le brief mentionne explicitement une app mobile intervenante en version avancée. Elle doit rester simple, ultra claire et centrée exécution.
Le portail doit rassurer, simplifier la relation et donner de la visibilité sans exposer la complexité backoffice.
Historique, prochaines prestations, intervenante affectée, statut de confirmation.
Profils enfants, routines, besoins spécifiques, consignes à jour.
Notation de la mission, commentaire, suivi si insatisfaction.
Heures achetées, consommées, restantes, date de renouvellement suggérée.
Factures, paiements reçus, reste à payer, historique.
Messagerie structurée, demandes d’assistance, contact rapide.
Pour exécuter vite et proprement, le build peut être réparti par streams fonctionnels et techniques.
Wireframes, user flows, design system, tests avec ops team.
Backoffice UI, dashboard, tables, calendrier, drawers, formulaires complexes.
Domain services, API, auth RBAC, queues, events, intégrations.
Tests des workflows critiques, monitoring, déploiement, observabilité, sécurité.
Cette version transforme le brief écran par écran en une expérience beaucoup plus proche d’un vrai SaaS : navigation latérale, cockpit opérationnel, vues interactives, backlog de build, quiz de validation et conclusion de cadrage. Le système reste aligné avec la structure fonctionnelle du document source. fileciteturn1file0
Vue synthétique inspirée du brief : missions aujourd’hui, demandes non traitées, incidents ouverts, paiements en attente, satisfaction moyenne et alertes critiques. fileciteturn1file0
| Type | Mission | Ville | Statut |
|---|---|---|---|
| Mission non couverte | #M-1024 | Casa | Urgent |
| Retard intervenante | #M-1031 | Rabat | En suivi |
| Paiement bloqué | Famille N. | Casa | À relancer |
| Feedback négatif | #M-0998 | Kénitra | Ticket qualité |
Ouverture dashboard, vérification des alertes.
Qualification des nouvelles demandes prioritaires.
Lancement du matching et validation planning.
Suivi exécution, gestion des urgences et remplacements.
Contrôle qualité, heures validées, reporting du jour. fileciteturn1file0
Résumé des écrans les plus critiques pour le build quotidien : demandes, familles, intervenantes, matching, missions, planning, incidents, qualité et finance. fileciteturn1file0
| ID | Parent | Ville | Urgence |
|---|---|---|---|
| D-201 | Famille El M. | Rabat | Haute |
| D-202 | Famille B. | Casa | Moyenne |
| D-203 | Famille S. | Kénitra | Haute |
Qualifier, convertir en mission, lancer matching, programmer suivi, taguer VIP / sensible / urgent.
Objectif : centraliser toutes les nouvelles demandesLecture simplifiée des couches à construire pour supporter le backoffice, l’app intervenante, le portail parent et les automatisations.
App shell, dashboard, tables, console matching, mission detail, planning, incident desk, qualité, finance, RH.
Auth & rôles, familles, intervenantes, leads, matching engine, mission engine, planning, incidents, finance, notifications.
PostgreSQL, audit logs, documents, agrégations dashboard, historique complet des changements sensibles.
Demande : Nouveau → Qualifiée → Convertie / Archivée. Mission : Matching → Assignée → Confirmée → En cours → Terminée / Incident / Annulée. Incident : Ouvert → Assigné → Résolu → Clôturé. fileciteturn1file0
Nouvelle demande → tâche de qualification. Mission modifiée → notifications. Fin mission → demande d’avis. Note basse → ticket qualité. Fin de pack → alerte commerciale.
Découpage buildable pour lancer le produit sans ambiguïté.
Auth, rôles, app shell, composants de base, routing, glossary métier, statuts unifiés.
Dashboard, alert center, agrégations, KPI, règles urgences.
Demandes, qualification, familles, historique de communication.
Intervenantes, disponibilités, scoring, matching console.
Missions, calendrier, conflits, réassignation, check-in/out.
Incidents, qualité, packs, paiements, RH, communications, reporting.
Écran branché à de vraies données, permissions respectées, filtres fonctionnels, cas d’erreur gérés, logs présents, QA critique validée.
Permettre à une équipe product + design + dev de basculer du cadrage à l’exécution. Le résultat attendu est un logiciel simple, ultra opérationnel, orienté réactivité et capable de scaler. fileciteturn1file0
Validation rapide de la compréhension produit par les développeurs.
Cette page sert de document de mobilisation, d’alignement et de démarrage de mission pour l’équipe technique AngelCare. L’objectif est de livrer un MVP complet, utilisable par l’équipe opérations, avec dashboard, demandes, missions, matching, planning, incidents, qualité, paiements et rôles utilisateurs.
Pour réussir une mission de 30 jours, l’équipe doit être légère, rapide et disciplinée. Chaque membre doit avoir un rôle clair et un objectif orienté livraison.
Porte la vision métier, tranche vite, priorise, valide les écrans et garde l’équipe alignée sur les besoins réels d’AngelCare.
Définit l’architecture, arbitre les choix techniques, répartit le travail et sécurise la qualité du build.
Construit le backoffice web, les composants UI, les tables, le planning, les dashboards et l’expérience SaaS.
Le backend construit les APIs, la base, les rôles et la logique métier. Le QA/Ops teste les vrais flux chaque semaine.
L’application web doit être suffisamment complète pour piloter réellement les opérations au quotidien, sans dépendre d’outils dispersés.
Le bon rythme est un découpage en 4 semaines, avec démonstration interne et test terrain à la fin de chaque cycle.
Setup technique, auth, rôles, base de données, layout global, login, routing, structure de l’application.
Construire le cœur métier : familles, demandes, intervenantes, conversion lead → mission, matching simple, assignation.
Traiter l’exécution terrain : dashboard cockpit, planning, statuts missions, incidents, alertes et check-in/out.
Finaliser la couche business : feedback, score intervenante, paiements manuels, rapports simples, stabilisation produit.
Le projet doit avancer en parallèle sur le frontend, le backend et les tests ops. Ce visuel aide l’équipe à comprendre le tempo global.
L’application doit accélérer la transformation d’une demande en mission assignée.
Le dashboard doit rendre les incidents et missions non couvertes évidents.
Lead → mission → assignation → exécution → feedback → paiement.
Ces checklists servent de discipline d’exécution. Elles doivent être relues chaque semaine pendant la mission.
Ce mini quiz permet de vérifier que l’équipe a bien compris les priorités de la mission avant de démarrer le développement.