PULSE - Gestion d'incidents pour les équipes
opérationnelles

8 min - aoû. 2026

Contexte

Problème

Process

Solution

Résultats & apprentissages

Conception d'une interface permettant aux responsables d'exploitation de qualifier et assigner rapidement les incidents, pour réduire le temps entre le signalement et la prise en charge.

Projet réalisé pour une entreprise fictive, NOVA Facilities, projet indépendant.

CONTEXTE

NOVA Facilities accompagne des entreprises possédant plusieurs bâtiments (bureaux, commerces, entrepôts, sites industriels) et assure pour leur compte la maintenance, la sécurité, le nettoyage, les interventions techniques et la gestion des incidents.

Aujourd'hui, les incidents sont signalés via quatre canaux différents (téléphone, email, Teams, formulaire interne), puis suivis manuellement par les responsables d'exploitation à l'aide de plusieurs fichiers Excel. Résultat : un incident peut être mal priorisé, assigné à la mauvaise personne, ou tout simplement oublié.

Objectif du projet : concevoir PULSE, une interface permettant de centraliser, qualifier et assigner les incidents rapidement.

PROBLÈME

En partant du persona Léa Martin, 38 ans, responsable d'exploitation (5 ans d'ancienneté chez NOVA, 5 sites gérés, environ 80 incidents traités par semaine, principalement sur ordinateur), j'ai identifié les frictions à résoudre :

Une information dispersée : Les incidents arrivent par quatre canaux distincts, sans vue centralisée,
Une surcharge informationnelle : Léa doit trier trop d'informations pour identifier ce qui nécessite réellement son attention immédiate,
Un manque de visibilité sur les ressources : Elle a du mal à connaître la disponibilité de ses techniciens au moment d'assigner une intervention,
Un risque d'oubli : La peur de laisser passer une intervention urgente est une charge mentale constante.

Le besoin central de Léa : savoir immédiatement ce qui nécessite son attention.

PROCESS

Analyse du besoin métier et du persona : J'ai formalisé les objectifs et frustrations de Léa pour en tirer des priorités de conception : centraliser l'information, rendre visible ce qui nécessite son attention,
Définition des statuts du cycle de vie d'un incident : J'ai modélisé le parcours complet d'une demande : à assigner → en cours → en attente (de confirmation de la résolution) → résolu, pour structurer l'ensemble de l'interface autour de cette logique,
Conception du dashboard : J'ai priorisé les informations selon le besoin de Léa : indicateurs clés en un coup d'œil, interventions du jour, disponibilité de l'équipe, et répartition des demandes par type,
Conception du parcours d'assignation : J'ai imaginé un flux permettant d'assigner un technicien sans quitter le contexte de la demande, via un panneau latéral,
Construction d'un design system : Pour garantir la cohérence des composants (statuts, badges de priorité, cartes de demande, boutons d'action) sur l'ensemble de l'outil,
Ajout de motion sur le dashboard : Pour accompagner les changements d'état (KPI qui se met à jour, demande qui change de statut) et rendre ces transitions perceptibles sans surcharger l'attention de Léa.

dashboard du projet pulse

SOLUTION

Le dashboard, pensé comme le point d'entrée unique de Léa, réunit :

Des KPI : demandes ouvertes, à assigner, en attente, interventions en cours,
Les interventions du jour, en cours ou résolues,
Le planning de l'équipe de techniciens, pour visualiser leur disponibilité,
La répartition des demandes ouvertes par type (nettoyage, plomberie, électricité, espaces verts, CVC, sécurité), en pourcentage,
une section dédiée aux demandes à traiter par Léa (à assigner, ou en attente de résolution).

Le parcours d'assignation d'un technicien : depuis la page d'une demande, Léa ouvre un panneau latéral, sélectionne le technicien et le créneau, sans quitter le contexte de la demande. La page de demande centralise elle-même toute l'information nécessaire à la décision : description, personne à l'origine du signalement, photos, localisation, pièces jointes, zone de commentaires, et historique complet (création, auteur, horodatage).

Le cycle de vie de la demande structure toute l'expérience :

une fois assignée, la demande passe en « en cours »,
lorsque le technicien confirme l'intervention traitée, elle passe en « en attente », et son rapport est automatiquement ajouté aux pièces jointes,
Léa résout alors l'incident via un bouton dédié, confirmé par une modale,
la demande passe en « résolu », un état final où commentaires et pièces jointes ne sont plus modifiables, pour garantir la fiabilité de l'historique.

Un code couleur par statut, pour permettre à Léa de repérer l'état d'une demande sans avoir à lire l'étiquette : rose pour « à assigner », bleu pour « en cours », jaune pour « en attente », vert pour « résolu ». Cette couleur est reprise à trois niveaux pour rester cohérente sur tout le parcours : sur les KPI du dashboard, sur le tag de statut de chaque demande, et sur la ligne d'historique correspondante dans la fiche de la demande, de sorte que le statut reste identifiable d'un simple coup d'œil, quel que soit l'écran.

RÉSULTATS & APPRENTISSAGES

Ce projet m'a permis de travailler la conception d'un outil métier complexe à partir d'un persona et de frustrations concrètes, en gardant un fil conducteur simple : réduire la charge mentale de Léa en rendant visible, en un coup d'œil, ce qui nécessite son attention.

Modéliser le cycle de vie complet d'une demande (à assigner → en cours → en attente → résolu) en amont m'a permis de construire une interface cohérente plutôt que des écrans isolés, chaque statut avait une conséquence directe sur les actions disponibles et les composants à afficher.

Le code couleur par statut, répété sur les KPI, les tags et l'historique, m'a aussi appris l'importance de la cohérence d'un design system : une même signification (« en attente », « résolu »...) doit être portée par le même signal visuel partout dans l'outil, pour ne jamais faire réfléchir Léa deux fois sur ce qu'elle voit.