gPulse : automatiser la chaîne de rapports d’une plateforme d’écoute des salariés

Contexte

gPulse est la plateforme d’écoute des salariés de Greenworking : un produit d’enquête qui mesure le climat social dans les grandes organisations, de l’engagement à la charge de travail en passant par la qualité des relations managériales. Les entreprises y font tourner des baromètres annuels, des pulses réguliers et des enquêtes flash, et les équipes RH lisent les résultats comme des indicateurs sur lesquels agir.

La plateforme a été lancée en 2016 et comptait des clients du CAC40 bien avant mon arrivée. J’ai rejoint Greenworking comme développeur full-stack de 2023 à 2024 et j’ai travaillé sur gPulse. Je ne l’ai pas créée, et cette étude de cas ne couvre que ce sur quoi j’ai travaillé : la chaîne qui transforme les données d’enquête collectées en rapports remis aux clients, et les dashboards utilisés pour les explorer.

Problème

Le livrable d’une mission d’écoute des salariés est un rapport. Les données d’enquête arrivent, les analystes les interprètent, et les conclusions sont présentées au client sous forme de slides. Assembler ces slides était largement du travail manuel, répété à chaque mission.

C’est lent, ça ne passe pas à l’échelle quand le nombre de clients augmente, et ça occupe consultants et analystes à de la mise en forme plutôt qu’à de l’interprétation, qui est justement ce que le client paie.

Mon rôle

Développeur full-stack, en lien direct avec les consultants et analystes qui produisent les rapports. J’ai automatisé la chaîne de production des rapports, de la collecte de données jusqu’à la présentation finale, et construit des dashboards React de visualisation de données utilisés pour explorer ces mêmes données à l’écran.

[TODO : ajouter les autres parties de la plateforme sur lesquelles tu es intervenu, si tu veux les rendre publiques.]

Approche technique

Traiter le livrable comme une cible de rendu

L’idée qui a structuré le travail : un rapport n’est pas un document, c’est le rendu d’un jeu de données. Une fois modélisé ainsi, le pipeline redevient classique (collecter, normaliser, dériver, rendre) et le livrable devient un format de sortie plutôt qu’une chose que l’on assemble à la main.

Une sortie générée doit être juste sans surveillance

Un dashboard a un utilisateur devant lui, qui peut faire défiler, filtrer ou rafraîchir. Un livrable généré n’a personne. Il doit être correct du premier coup, avec de vraies données client, y compris les libellés à rallonge, les tailles de segments inégales et les réponses manquantes qui n’apparaissent jamais dans une démo. L’essentiel de l’effort d’ingénierie est parti dans les cas invisibles quand les données se tiennent bien.

Les données d’enquête ont leurs propres règles

Les données d’écoute des salariés ne sont pas de l’analytics ordinaire. Les réponses sont anonymes, les résultats sont ventilés par segments sociodémographiques, et ce qu’un graphique a le droit de montrer dépend du nombre de personnes derrière. Ces règles vivent dans la couche de données, pas dans la présentation, ce qui est une raison de plus pour générer le rapport à partir d’un jeu de données traité plutôt que de l’assembler à la main à chaque fois.

Construire avec ceux qui s’en servent

Travailler directement avec les consultants et les analystes a plus changé le produit que n’importe quelle décision technique. Ils savaient quelles slides comptaient, quels chiffres étaient challengés en réunion client, et quelles étapes manuelles ils n’étaient pas encore prêts à confier. Livrer par étapes, plutôt que remplacer toute la chaîne d’un coup, est ce qui a permis l’adoption.

Difficultés

La contrainte forte de ce type de reporting : la sortie est destinée au client, au tarif d’un cabinet de conseil, et elle porte des conclusions sur des personnes. Un bug de dashboard est un agacement ; un chiffre faux dans un rapport remis à un DRH est un problème de crédibilité. Cela pousse le travail vers la prudence et la traçabilité explicite de chaque chiffre, plutôt que vers l’astuce technique.

Résultat

La chaîne de production des rapports est passée d’un assemblage manuel à un pipeline automatisé, et les consultants disposaient de dashboards pour explorer les données d’enquête directement.

[ADD RESULT : temps gagné par rapport, ou nombre de rapports produits, une fois que tu pourras le partager et le vérifier.]