ROC
Réunir quatre applications métier en un socle commun, en co-concevant chaque template avec les équipes
applications à réunir en un seul socle
ateliers de Design Thinking de deux heures
représentants métier autour de la table à chaque atelier
L'essentiel, avant le détail
- Le problème
- TotalEnergies gérait les contrats de son réseau de stations-service avec quatre applications distinctes, dont Optinet. Le projet ROC devait les réunir en un socle modulaire, performant et évolutif, sans perdre les usages de métiers aux attentes très différentes.
- Mon rôle
- J'ai co-animé les quatre ateliers de Design Thinking avec les équipes métier, puis conçu les templates de pages et itéré dessus d'un atelier à l'autre, jusqu'à leur validation.
- Le résultat
- Une vision produit partagée, quatre personas, une page d'accueil centrée sur les échéances et des templates réutilisables (formulaire, tableau, graphiques, notifications) validés par les utilisateurs.
Des outils denses, des métiers qui ne se parlent pas
Les contrats passent entre plusieurs mains : le chef de secteur initie le contrat de sa station, les optimiseurs contrôlent et valident les comptes de résultat prévisionnels (CRP), l'administrateur métier assure le support. Chacun travaillait dans des écrans pensés pour la saisie, pas pour le suivi.
Le projet était déjà lancé côté technique. Il fallait aligner vite des interlocuteurs aux visions divergentes, et produire des modèles de pages réutilisables plutôt qu'une suite d'écrans sur mesure.
Des ateliers aux templates validés
-
01
Partir des personas et des irritants
Le premier atelier a commencé par la relecture des trois personas existants, chef de secteur, optimiseur CODO et administrateur métier, puis la création du quatrième, l'optimiseur DODO, par les participants eux-mêmes. Les frustrations remontées étaient concrètes : aucune remontée des CRP à traiter ni des contrats arrivant à échéance, pas de notifications, des statuts difficiles à lire, des allers-retours entre applications pour trouver une information, et un workflow de saisie qui oblige à repasser par toutes les étapes.
Les quatre personas complétés en atelier : besoins, objectifs, frustrations et contraintes 
Le point de départ : Optinet, un outil de saisie dense, sans vision des échéances ni des statuts -
02
Converger sur une vision produit, puis prioriser
J'ai fait converger le groupe sur une vision commune : réunir quatre applications en une, faire gagner du temps, accélérer la mise sur le marché des évolutions, viser des pages chargées en moins de deux secondes et rajeunir l'interface. À partir des user flows, chaque profil a ensuite listé puis pondéré les contenus attendus sur sa page d'accueil. Le consensus a tranché en faveur d'une page d'accueil simple : ses échéances, ses contrats à traiter avec leur statut, une recherche, et un accès direct à la création de contrat.
-
03
Rendre visibles les échéances
Les participants voulaient voir d'un coup d'œil les contrats arrivant à échéance. J'ai soumis trois propositions de timeline au deuxième atelier, chacune triée par le groupe en trois colonnes : ce que l'on garde, ce qui n'est pas possible, ce qui pose question. La version retenue combine les meilleurs éléments des trois.
Atelier 2Timeline des échéances
Comment représenter des contrats de plusieurs années pour repérer immédiatement ce qui arrive à échéance ?
Ce que le groupe a retenu
- Une barre à la date du jour, pour situer chaque contrat dans le temps
- Un code couleur par type de contrat : renouvellement, avenant, création
- Le numéro de CRP et le code implant sur la barre, le détail complet au survol
- Le début du contrat affiché même lorsqu'il sort de la période visible
- Des couleurs plus contrastées pour les contrats à venir
Ce que j'ai intégré
Une timeline en tête de page d'accueil, filtrable par date d'échéance, SARL, secteur et région, suivie du tableau des CRP à traiter, avec des filtres rapides par statut et l'affichage optionnel des CRP refusés.
La page d'accueil finale : compteurs par statut, timeline des échéances, puis les CRP à traiter -
04
Concevoir des templates, pas des écrans
À partir des user flows, j'ai listé avec le groupe les modèles de pages nécessaires à toute l'application : édition de CRP avec menu, tableau de données, graphiques. Le formulaire découpe la saisie en rubriques avec un taux de complétion visible, signale les champs verrouillés par un cadenas et les champs particuliers par une infobulle. Le tableau regroupe les colonnes par thème, données caisse, comptables ou du chef de secteur, que l'on peut masquer ou réorganiser, et distingue les cellules modifiables des totaux calculés.
Le template d'édition de CRP : navigation par rubriques, taux de complétion, champs verrouillés et infobulles 
Le template de tableau : colonnes groupées par source de données, cellules modifiables mises en évidence 
Le graphique en courbes : deux séries paramétrables et le CRP proposé comme repère 
Le graphique en colonnes : besoins et disponibilités en heures de travail -
05
Valider en atelier, itérer entre deux
Les troisième et quatrième ateliers ont servi à valider chaque template : dix minutes de présentation, vingt minutes d'échange, puis le même tri entre ce que l'on garde, ce qui n'est pas possible et ce qui pose question. Entre deux sessions, j'intégrais les retours. Les notifications à chaque changement de statut sont ainsi devenues un centre de notifications assorti d'un écran de préférences, et la recherche s'est dotée d'un texte d'exemple explicite : code implant, nom de station.
Le centre de notifications, ouvert depuis la page d'accueil : changements de statut et refus 
Le gestionnaire de notifications, né d'une question soulevée en atelier
Ce que les ateliers ont permis d'établir
Une vision produit commune aux quatre applications, construite avec les équipes métier
Quatre personas, dont un créé en atelier par les participants
Une page d'accueil centrée sur les échéances et les CRP à traiter
Des templates de formulaire, de tableau, de graphiques et de notifications, validés en atelier
Les templates ont été validés par les représentants métier en atelier ; l'adoption et le gain de temps restaient à mesurer après le développement
Ce que je retiens
- Sur un outil métier complexe, les utilisateurs savent ce dont ils ont besoin, mais pas toujours ce qui est possible : la grille « garder, pas possible, questionnement » rend ces arbitrages explicites et partagés.
- Concevoir des templates plutôt que des écrans demande de penser en règles, champs verrouillés, groupes de colonnes, états, pour que le socle tienne quand de nouvelles applications le rejoignent.
- Animer à distance un groupe hétérogène exige un déroulé minuté et des règles posées dès l'ouverture : tout le monde participe, chacun reste synthétique, personne ne juge.
