People analytics et engagement collaborateurs : passez plus vite la revue IT

Dans son livre Privacy Is Power, Carissa Véliz explique que la collecte de données a toujours un coût, même quand elle part des meilleures intentions. Une fois collectées, les données personnelles peuvent servir à de nouveaux usages, auxquels personne n’a consenti.

Les plateformes d’engagement doivent en tenir compte. Les équipes RH oublient souvent de réfléchir aux conséquences possibles des données qu’elles comptent extraire du flux SIRH, ou du type de reporting qu’elles veulent construire à partir des données d’enquête.

Quand on utilise la people analytics pour renforcer l’engagement collaborateurs, l’objectif est assez clair : repérer rapidement les problèmes d’engagement, donner aux managers des informations exploitables, et agir avant de perdre de bons collaborateurs.

Vous connaissez la marche à suivre : vous choisissez votre prestataire, vous fixez une date pour votre enquête d’engagement, puis vous demandez à votre service informatique de vous aider à connecter l’enquête au SIRH de l’entreprise.

Et là, votre projet reste bloqué en revue de sécurité pendant une éternité.

Votre équipe IT ne cherche pas à vous mettre des bâtons dans les roues : elle fait simplement son travail. Le problème, c’est que les RH ont lancé la revue après avoir choisi leur prestataire, et sans document décrivant les spécifications des données. Faute d’éléments concrets à examiner, l’IT doit partir du pire : une exportation complète du SIRH, une synchronisation en temps réel, des droits d’administration étendus et une conservation des données sans limite de durée.

On comprend que vous vouliez lancer votre projet d’analytics de l’engagement au plus vite, pour que les résultats restent d’actualité. Côté entreprise, c’est un besoin légitime. Mais votre service informatique a aussi raison de vous rappeler que des réponses à l’enquête, même correctement anonymisées, peuvent permettre de remonter jusqu’à certains collaborateurs si on y associe des données démographiques ou hiérarchiques suffisamment détaillées.

Rédigez les spécifications des données avant la démonstration du prestataire, et non après la signature du contrat.

Au moment de la revue de sécurité des données, vous faciliterez grandement les choses en fournissant à votre équipe IT un document qui liste les champs dont vous avez besoin et pourquoi, un schéma des flux de données, et des règles précisant qui peut accéder à quoi, le tout à partir d’une source clairement identifiée.

Dans cet article

1. Pourquoi les équipes informatiques freinent les projets d’engagement collaborateurs
2. Vous n’avez sans doute pas besoin d’autant de données que vous le pensez
3. Avant de parler intégrations, déterminez les données à collecter et à conserver absolument
4. Déterminez avec qui les données seront partagées, et si elles doivent rester anonymes
5. Donnez à vos équipes confidentialité et juridique suffisamment d’éléments pour vérifier la conformité
6. Organisez une revue interne pour recueillir l’avis des services concernés sur le logiciel d’engagement collaborateurs envisagé
7. Prenez des décisions éclairées grâce à la configuration logicielle approuvée
8. Présentez une configuration logicielle approuvée à votre service informatique

Pourquoi l’IT freine-t-elle les projets d’engagement ?

Pourquoi votre équipe informatique bloque-t-elle votre projet d’engagement ?

Parce qu’elle a déjà eu affaire, par le passé, à des demandes mal cadrées.

Un exemple :

Vous essayez de lancer votre plateforme d’engagement collaborateurs. Votre fournisseur vous demande de lui envoyer une population de départ, le temps de mettre en place un flux API ou SFTP. Quelqu’un dans votre équipe se dit que cette exportation ne doit pas être bien compliquée.

Après tout, ce n’est qu’une fois.

Ce qu’on oublie souvent, c’est que ce fichier Excel peut traîner des années dans une boîte mail partagée, dans un dossier d’intégration chez le fournisseur, ou dans le dossier Téléchargements de quelqu’un.

C’est exactement ce genre de scénario qui inquiète votre équipe informatique quand elle parle de shadow IT, de données personnelles ou de connecteurs laissés à l’abandon.

Alors, comment répondre à ces inquiétudes sur la sécurité des données ?

Expliquez clairement que le premier transfert passera par le même canal contrôlé que la synchronisation régulière. Autrement dit, il n’y aura pas d’exportation ponctuelle.

Si le flux ne peut pas être prêt avant la première enquête, reportez cette enquête jusqu’à ce que vous puissiez vous engager sur sa mise en place.

Pourquoi ? Parce que, d’après le rapport annuel de Verizon sur les violations de données (Data Breach Investigations Report), la plupart des violations impliquent un facteur humain : erreur, mauvais usage ou ingénierie sociale. En clair, ce sont souvent des personnes qui sont à l’origine des failles.

Autre point qui peut faire tiquer votre équipe informatique : la répartition des rôles. Les RH sont « propriétaires » du projet, puisque ce sont elles qui chercheront à comprendre le « pourquoi » et décideront de la suite une fois les données collectées.

L’équipe informatique, elle, le « fait tourner », puisque c’est elle qui met en place les contrôles techniques.

Et les autres équipes ? Il serait logique d’associer les équipes SIRH aux projets d’engagement collaborateurs, non ?

Pourquoi ? Parce qu’une réorganisation peut casser le flux de données entre la hiérarchie et le reste de l’organisation. Même si la hiérarchie est censée se mettre à jour automatiquement, il faut une équipe capable d’intervenir pour réparer le flux. D’où l’importance de désigner une personne ou une équipe responsable du sujet.

Avec un délai d’intervention défini.

Avant de démarrer un nouveau projet d’engagement ou d’enquête, mettez-vous d’accord sur la personne à contacter et sur le délai dans lequel elle pourra intervenir.

Il est aussi important de fixer les « règles du jeu » avant l’enquête d’engagement.

Une pratique courante dans le secteur, par exemple, consiste à figer la hiérarchie le jour du lancement de l’enquête et à rattacher tous les résultats à cette version.

Ainsi, les changements organisationnels qui surviennent pendant l’enquête ne sont pris en compte qu’au cycle suivant.

Pourquoi ? Parce que les équipes RH et informatique n’ont pas à jongler avec deux organigrammes pour un seul rapport d’enquête.

La question à se poser pour trancher le débat ?

De quelles informations sur un collaborateur ma plateforme d’engagement a-t-elle besoin pour fournir à son responsable des résultats utiles sur son équipe ?

Collectez moins de données que vous ne le pensez

Tout au long de votre projet de people analytics, résistez à la tentation d’élargir peu à peu le périmètre. Votre équipe voudra peut-être ajouter aux flux de données d’enquête des évaluations de performance, des informations de paie ou des métadonnées de collaboration. Ce sont des choses qui peuvent sembler « bonnes à avoir », ou qui donneraient une « vue plus complète » sur un tableau de bord.

Mais chaque donnée ajoutée multiplie le nombre de combinaisons possibles. Prenez service × genre × ancienneté × lieu de travail : vous vous retrouvez vite avec des dizaines de groupes de trois ou quatre personnes seulement.

Et plus on découpe les données, plus le risque de réidentification augmente.

Avant de demander un champ, faites quelques calculs rapides. Servez-vous de votre SIRH pour savoir combien de personnes composent actuellement certains groupes. Si possible, rendez une dimension moins détaillée (par exemple trois tranches d’ancienneté au lieu de six) ou choisissez une autre option (collecter les données par région plutôt que par site) pour limiter les risques de réidentification.

Vérifier que le champ demandé s’inscrit dans le système de classification des données déjà en place dans votre organisation (plutôt que d’inventer une règle ad hoc pour ce projet) facilitera aussi l’identification et la réduction des risques par la suite. Demandez également à vos équipes IT et confidentialité de passer en revue les risques liés à la collecte : vous serez sûr de faire les choses correctement. Elles pourront notamment vous aider à déterminer si votre organisation doit revoir la collecte de données sur l’origine ethnique (une catégorie particulière de données au sens du RGPD).

Peut-être n’aurez-vous même pas besoin d’extraire ces données de votre SIRH, et pourrez-vous plutôt les recueillir dans le cadre de l’enquête. Vous pouvez aussi laisser aux collaborateurs la possibilité de ne pas répondre à cette question : c’est alors un choix consenti, plutôt que des suppositions faites par votre équipe RH.

Autre moyen de ne pas demander trop de données : gardez en tête la question précise à laquelle vous cherchez à répondre. Si vous voulez comprendre le niveau d’engagement d’un groupe dans les différents services, il vous faudra savoir qui fait partie de ce groupe, dans quel service travaillent ces personnes, à quel manager elles sont rattachées, et quel est leur statut d’emploi.

Gardez à l’esprit que les données sur les liens hiérarchiques peuvent être inexactes. C’est particulièrement vrai dans une organisation matricielle, où les rattachements enregistrés dans le SIRH peuvent être faux ou flous. Si vous comptez vous en servir pour restreindre l’accès à certains rapports, ce n’est plus seulement un problème de qualité des données : c’est un problème de sécurité.

Demandez un « mini-jeu de données ». Une fois ce mini-jeu obtenu, toute donnée supplémentaire devra faire l’objet d’une demande séparée et justifiée.

Quand vous demandez des données pour votre projet de people analytics, pensez à définir un « mini-jeu de données » qui ne comprend que a) les informations permettant d’identifier une personne et b) les attributs qui permettent de la rattacher à la bonne équipe. Demander un énorme transfert, c’est-à-dire donner à une équipe l’accès à « toutes les données » pour faire le tri ensuite, pose des questions de confidentialité.

Même si les données sont filtrées après coup, tous les champs intégrés au départ devront être protégés, sécurisés, pris en compte dans les demandes d’accès des personnes concernées, et supprimés au bout d’un certain temps.

Attention cependant à ne pas tomber dans l’excès inverse : une collecte trop « légère » risque de ne pas vous apporter les informations dont vous avez besoin. Si vous voulez savoir si la première année d’un collaborateur se passe différemment des suivantes, une demande portant sur l’ancienneté se justifie facilement. Vous évitez ainsi de demander la date exacte d’embauche, qui pourrait créer des risques de réidentification si des collaborateurs viennent d’arriver dans des équipes très réduites et très spécifiques.

Cela fait des années que les études Gallup sur le monde du travail le montrent : seule une minorité de salariés se dit engagée.

Présentez à l’équipe IT une vue d’ensemble des flux de données au sein de votre organisation

Votre équipe informatique doit savoir d’où viennent les données, où elles vont, et s’il en existe plusieurs versions.

Un exercice utile : réaliser un schéma récapitulatif d’une page, pour que votre équipe n’ait pas à éplucher une liste de fonctionnalités.

Sur la partie gauche, indiquez la source des informations SIRH, les champs transmis, la fréquence d’envoi et, si les mises à jour sont horodatées, leur date d’effet.

Où sont stockées les réponses à l’enquête ? Certaines données sont-elles exportées depuis la plateforme d’enquête pour le reporting interne ?

Quand votre plateforme de feedback collaborateurs récupère les mises à jour de votre flux SIRH, passe-t-elle par une API ou par SFTP ?

S’il s’agit d’une API native, votre équipe voudra s’assurer que les autorisations sont correctes, limitées au strict nécessaire et en lecture seule. Elle voudra aussi savoir ce qui se passe si la connexion est interrompue.

Que se passe-t-il si la synchronisation via l’API s’arrête ? La plateforme continue-t-elle à fonctionner avec le dernier organigramme connu ? Les managers sont-ils privés d’accès à leurs tableaux de bord tant que le problème n’est pas résolu ?

Si vos synchronisations SFTP suivent un calendrier défini, vérifiez que les fichiers sont chiffrés au repos (par exemple avec PGP), et que le prestataire les supprime après intégration au lieu de les conserver indéfiniment.

Et si le prestataire reçoit des données mal formatées ? Ou un export tronqué qui laisse croire que « ces 400 personnes ont quitté l’entreprise », alors que la plateforme aurait dû y voir une simple mise à jour de leurs données ?

Vous risquez ensuite des problèmes de reporting ou d’accès.

Le prestataire peut-il rejeter les données au-delà d’un seuil de tolérance défini avec votre équipe ? Peut-il alerter quelqu’un chez vous ?

Votre organisation dispose-t-elle déjà d’une équipe chargée des intégrations qui utilise un middleware ? Si oui, continuer à passer par ce middleware simplifiera la maintenance au quotidien.

Votre équipe pourra en effet s’appuyer sur ses fonctionnalités de monitoring et d’alerte.

En revanche, votre organisation doit bien avoir conscience que les données des collaborateurs transiteront aussi par ce middleware, qui enregistre souvent les données reçues et envoyées.

Pensez à le faire figurer sur vos schémas, pour que personne ne passe à côté.

Autre écueil fréquent en matière de sécurité : envoyer par défaut toutes les données vers l’entrepôt de données central.

Les entrepôts de données (data warehouses) et les lacs de données (data lakes) sont très pratiques pour rassembler toutes les données au même endroit et les analyser, dans le cadre d’une gouvernance plus large.

Mais une fois vos données d’enquête stockées dans cet entrepôt, elles ne sont peut-être plus soumises au seuil de reporting de votre plateforme d’enquête.

N’importe quel analyste ayant accès à l’entrepôt pourrait alors faire des jointures sur les données de l’enquête.

Essayez donc de n’envoyer vers l’entrepôt ou le lac de données central que des résultats agrégés, une fois les seuils de reporting appliqués.

Autre option : appliquer vous-même un seuil de reporting dans votre propre couche de reporting.

Pensez aussi à décrire le processus d’authentification.

Vérifiez que votre plateforme prend en charge le SSO. Si la révocation des accès passe par votre processus de gestion des identités, assurez-vous que la plateforme le permet. Vérifiez également si votre organisation utilise SCIM.

Sachez que SCIM supprime les comptes utilisateurs, mais que ce qu’un manager peut voir dépend du flux de données de l’organigramme hiérarchique.

Même si l’informatique désactive un identifiant de connexion, un manager qui a changé de poste peut continuer à voir les résultats de ses anciennes équipes tant que l’organigramme n’a pas été mis à jour.

Enfin, pour vos tests, utilisez des données synthétiques ou masquées.

Importer le fichier complet de vos collaborateurs dans un environnement de test « juste pour vérifier que le mapping fonctionne », c’est recréer le problème des fichiers Excel qui prolifèrent, simplement ailleurs.

Vous pouvez par exemple bâtir un cas de test qui suit le parcours d’un collaborateur : il arrive dans l’organisation, intègre une équipe, reçoit une enquête, change de service en plein cycle d’enquête, puis quitte l’organisation.

Quelles données changent dans les autres systèmes à la suite de ces événements ?

Quand les résultats sont générés et remontés, sont-ils rattachés à l’équipe au titre de laquelle le collaborateur a répondu, ou à son équipe actuelle ?

Faut-il séparer l’accès à la connexion de l’accès à la consultation ?

Quand vous définissez les autorisations de votre plateforme d’enquête, traitez ces deux questions séparément :

• Qui a le droit de se connecter à la plateforme d’enquête ?
• Que peut consulter ou ouvrir chaque utilisateur sur la plateforme ?

Les administrateurs d’enquête, par exemple, doivent pouvoir créer des enquêtes et veiller au bon fonctionnement du système, mais cela ne veut pas dire qu’ils doivent avoir automatiquement accès à tous les rapports de l’organisation.

De même, les managers peuvent avoir besoin des résultats agrégés de leur équipe, mais ils ne devraient pas pouvoir consulter les réponses individuelles.

Dans son livre Privacy in Context, Helen Nissenbaum explique que ce qui constitue un usage approprié des données dépend des normes du contexte dans lequel elles ont été communiquées au départ. C’est ce qu’elle appelle l’« intégrité contextuelle ».

Quand un collaborateur remplit une enquête d’engagement dans son organisation, il s’attend à ce que ses réponses soient traitées selon les normes sociales d’un canal confidentiel.

Si les managers peuvent accéder aux réponses qui les concernent, même indirectement, ces normes sont bafouées.

Le plus souvent, vous voudrez que les résultats ne soient visibles qu’à partir d’un nombre minimal de réponses. Le seuil par défaut est généralement de 5, même si le bon chiffre fait débat.

Certaines organisations fixent des seuils plus élevés pour certains groupes démographiques ou pour l’affichage des commentaires, qui contiennent souvent des détails permettant d’identifier facilement leur auteur.

Résultat : les résultats des petites équipes risquent de ne pas être consultables.

Selon la taille des équipes dans votre organisation, cela peut poser problème. Si la plupart des équipes de terrain comptent 6 à 8 collaborateurs et que le seuil est fixé à 7 personnes, la majorité des managers ne pourront sans doute pas voir les résultats de leur équipe.

Il peut alors être judicieux de prévoir deux seuils : un plus bas pour les scores d’enquête, un plus élevé pour l’affichage des commentaires.

Gardez aussi à l’esprit qu’un seuil minimal n’empêche pas toute déduction. Un manager qui sait qu’une seule personne a rejoint son équipe pourra comprendre ce qui a changé en comparant les scores d’un cycle d’enquête à l’autre.

Pour limiter ce risque, vous pouvez mettre en place des tests de différenciation. Prenons le scénario suivant :

1. Vue département : l’utilisateur voit les 12 personnes du département
2. Vue sous-équipe : l’utilisateur voit une sous-équipe de 7 de ces personnes

En retirant les réponses de la sous-équipe de celles du département, l’utilisateur obtient les réponses des 5 autres personnes du département.

Si ce groupe restant est inférieur au seuil d’affichage, l’utilisateur a contourné votre règle.

Pour détecter ces failles éventuelles, faites ces tests de différenciation sur la hiérarchie réelle de votre organisation.

Les commentaires présentent aussi des risques particuliers. Le style d’écriture, ou les événements précis qui y sont évoqués, peuvent trahir leur auteur. Il faut donc décider bien à l’avance qui peut lire les commentaires bruts, si les managers les voient tels quels ou regroupés par thèmes, et comment traiter les commentaires qui signalent du harcèlement ou des problèmes de sécurité.

Vous ne voulez pas compromettre la confidentialité, mais vous devez aussi protéger votre organisation en faisant remonter ces problèmes.

Des fonctionnalités comme les identifiants pseudonymisés (qui remplacent les noms d’utilisateur lors des échanges entre systèmes tout en permettant de relier des enregistrements distincts) ou le chiffrement des données en transit et au repos sont bien sûr utiles.

Mais elles ne règlent pas la question de qui peut accéder à quel rapport.

Notez aussi que les données pseudonymisées restent des données à caractère personnel au sens du RGPD.

Tout cela a des conséquences sur ce que vous annoncez à vos collaborateurs. Si des identifiants permettent de relier les réponses à des personnes identifiables, mieux vaut parler d’enquête « confidentielle » que d’enquête « anonyme ».

Sans quoi vous risquez de perdre la confiance de vos collaborateurs, ou de vous retrouver en difficulté avec vos équipes chargées de la confidentialité.

Puisqu’on parle de conformité, demandez à votre prestataire quels changements d’autorisations et quels exports de données sont consignés dans le journal d’audit.

Votre service informatique a-t-il accès à ce journal ? Si ces changements ou ces exports ne sont ni enregistrés ni consultables, c’est un problème.

Et si vous exportez les résultats pour les stocker dans votre propre environnement ? Assurez-vous de pouvoir y mener des audits, là aussi.

Pourquoi ? Parce que, selon l’étude annuelle d’IBM sur les violations de données, une seule violation peut coûter des millions à une organisation.

Donnez à vos équipes en charge de la confidentialité et du juridique des éléments concrets à examiner

Affirmer « Nous respectons le RGPD » ne suffit pas aux équipes chargées de la confidentialité, aux responsables des politiques internes ou aux juristes.

Il leur faut des détails sur l’enquête : son objectif, sa base légale, les champs utilisés, les destinataires, les sous-traitants ultérieurs, les durées de conservation, etc.

Sur le plan juridique, par exemple, elles voudront savoir si vous comptez demander leur consentement aux collaborateurs, ou vous appuyer sur une autre base légale pour traiter leurs données personnelles.

Mieux vaut sans doute éviter le consentement : vu le déséquilibre de pouvoir inhérent entre l’entreprise et ses collaborateurs, il est considéré comme peu fiable.

Pour mener des enquêtes d’engagement utiles, on s’appuie plus souvent sur l’intérêt légitime (à justifier par une mise en balance des intérêts documentée).

Par ailleurs, les règles de cogestion varient énormément d’un pays à l’autre.

En Allemagne, par exemple, les comités d’entreprise disposent d’un droit de cogestion sur les systèmes techniques susceptibles de surveiller le comportement ou les performances des collaborateurs.

Une plateforme d’engagement collaborateurs alimentée par des données issues d’un SIRH pourrait entrer dans ce cadre.

Contactez votre comité d’entreprise avant de fixer une date de lancement : vous aurez peut-être des étapes de consultation à respecter, avec des délais précis.

Vous pouvez aussi faire de votre comité d’entreprise un partenaire dans la conception de l’enquête, et pas seulement une instance qui l’approuve.

S’il participe aux décisions sur le seuil de reporting ou sur les règles de traitement des commentaires, il sera sans doute plus enclin à soutenir l’enquête.

À l’inverse, s’il découvre une configuration déjà bouclée, il risque de vouloir tout renégocier.

Vous devrez aussi savoir si une analyse d’impact relative à la protection des données (AIPD) est nécessaire.

Si c’est le cas, mieux vaut la mener en même temps que vous commencez à concevoir le flux des données personnelles utilisées pour l’enquête.

Si vous décidez de retirer un champ avant le lancement, vous n’aurez pas à rouvrir la discussion plus tard (une fois que des rapports de tendance auront été construits sur ce champ).

Il vous faudra également définir les durées de conservation propres au flux de données entre le SIRH et l’enquête d’engagement, aux données d’enquête elles-mêmes et, le cas échéant, aux données agrégées.

Sans oublier ce qui se passe quand une personne quitte l’entreprise, arrive en fin de contrat ou demande l’effacement de ses données.

Si vous ne comptez garder que des données anonymisées ou agrégées pour faire des comparaisons d’une année sur l’autre, insistez bien sur cette distinction et mettez-vous d’accord avec les équipes confidentialité et juridique. Il serait dommage de promettre des tendances sur trois ans pour vous apercevoir ensuite que vous ne pouvez pas les produire.

De même, convenez que si un collaborateur demande l’effacement de ses données, ses réponses individuelles seront supprimées, mais pas les données déjà intégrées à des résultats agrégés.

Que faut-il apporter à votre première réunion avec l’IT et l’équipe confidentialité ?

• La question à laquelle l’enquête doit répondre, les champs nécessaires pour y répondre, et la raison d’être de chacun d’eux
• Un schéma indiquant où les données seront transférées et stockées, avec les éventuels middlewares ou exports supplémentaires
• Les données auxquelles auront accès les RH, les administrateurs et les managers, et la source de données qui détermine ces règles d’accès
• Le seuil de reporting, la façon dont vous comptez traiter les commentaires, et une stratégie de tests de différenciation pour les petits groupes
• Les durées de conservation envisagées, et la documentation de sécurité du prestataire

Évaluer les prestataires : ne fuyez pas les questions difficiles

Un certificat de sécurité aide votre service informatique à comprendre comment le prestataire pilote son programme de sécurité, mais il ne dit rien du niveau de vulnérabilité de votre propre configuration.

Demandez aux prestataires les attestations dont ils disposent (certification ISO 27001 ou rapport SOC 2 Type II, par exemple). Elles ne sont pas interchangeables, et un bon prestataire n’aura pas forcément les deux. Pour l’ISO 27001, demandez le périmètre de certification : couvre-t-il uniquement l’informatique interne de l’entreprise, ou aussi le produit et l’environnement d’hébergement ?

Si la gestion de la confidentialité fait partie de vos critères, demandez également si le prestataire est certifié ISO 27701.

Si votre équipe IT dispose d’un questionnaire standard pour les prestataires (SIG Lite ou CAIQ, par exemple), envoyez-le dès le début de l’évaluation, et non une fois le prestataire choisi. Une fois les réponses reçues, vous pourrez signaler les points préoccupants ou poser des questions complémentaires : où les données seront stockées, si elles passeront par des sous-traitants ultérieurs (un prestataire d’IA ou d’analyse de texte pour traiter les commentaires, par exemple), comment vous serez prévenu en cas de violation, comment les données vous seront restituées puis supprimées en fin de contrat, et bien d’autres choses encore.

Côté IA, demandez aux prestataires si les commentaires collectés serviront à entraîner des modèles au-delà de votre environnement dédié. Si c’est le cas, ce n’est pas forcément rédhibitoire, mais il faudra bien signaler ce nouvel usage des données dans l’avis relatif à l’enquête.

Demandez aux prestataires de vous montrer concrètement comment ces contrôles fonctionnent dans le produit. Vous pouvez par exemple leur demander de déplacer un manager dans une autre équipe, puis de vous montrer ce qu’il peut voir ou non. Ou d’appliquer un filtre qui ferait apparaître un petit groupe (4 personnes, par exemple).

Vous verrez ainsi si leurs règles tiennent la route dans l’utilisation quotidienne de la plateforme.

Méfiez-vous d’un prestataire incapable de vous dire qui, chez lui, a accès aux réponses, qui reste vague sur la suppression des données, ou qui affirme que certaines protections sont « prévues » tout en vous réclamant votre fichier de collaborateurs.

Prenez de meilleures décisions grâce à la configuration approuvée

Si tout se passe bien, on pourrait être tenté de passer directement à la prédiction des départs au niveau individuel.

Résistez à la tentation ! En étudiant les tendances à l’échelle des groupes et en donnant aux managers des résultats sur lesquels ils peuvent agir, vous gagnerez davantage la confiance de tous et vous serez plus utile pendant votre première année.

Pourquoi respecter cet ordre ? Parce que vos rapports descriptifs (où l’engagement collaborateurs est-il faible ?) vont installer la confiance nécessaire pour passer ensuite aux rapports diagnostiques (pourquoi l’engagement est-il faible ici ?).

Et si vous construisez des modèles prédictifs avant d’avoir des rapports descriptifs et diagnostiques, vous n’aurez pas de données de référence fiables pour les tester.

Imaginons par exemple que l’engagement baisse dans un service après un changement d’horaires de travail. L’équipe RH pourrait alors creuser l’analyse pour voir si la baisse touche tout le service ou si elle se concentre sur une équipe particulièrement nombreuse.

Le responsable de cette équipe peut ensuite aborder le sujet de manière informelle avec ses collaborateurs et discuter du changement d’horaires avant de décider si une action s’impose (par exemple organiser des passations entre les équipes).

Bien sûr, il ne s’agit que d’un exemple fictif de conversation possible, pas d’une recommandation à utiliser les enquêtes d’engagement collaborateurs pour diagnostiquer les changements sur le lieu de travail.

Les enquêtes d’engagement sont plutôt un point de données parmi d’autres, qui vous aide à poser des questions et à lancer le dialogue. Et ce sont ces conversations qui vous donnent l’occasion d’apporter des changements sur le lieu de travail.

Gardez à l’esprit que, d’après les études de Gallup, 70 % des écarts d’engagement entre les équipes s’expliquent par le manager.

Les entreprises ont donc de bonnes raisons de comparer les niveaux et les tendances d’engagement d’une équipe à l’autre. En revanche, rien ne justifie d’intégrer les scores d’engagement aux évaluations de performance des managers.

C’est justement ce qui pousse les managers à « gérer les scores », et les collaborateurs le sentent bien.

Les avis divergent d’une organisation à l’autre sur ce point, mais la question mérite réflexion. Au minimum, il faudrait ajuster les scores d’engagement en fonction de variables comme la charge et les conditions de travail avant de tirer des conclusions sur un manager.

Gallup indique aussi qu’un engagement élevé va de pair avec un turnover plus faible. Pour vérifier si ce lien se retrouve dans vos propres données, commencez par analyser l’évolution des tendances par groupe dans le temps.

Relier les réponses à l’enquête à des données individuelles ou à des données de départ va à l’encontre de la promesse faite aux collaborateurs. Veillez donc à :

• En discuter avec vos équipes IT et confidentialité.
• Mettre à jour l’avis relatif à l’enquête pour mentionner cette possibilité.

Lors de l’enquête suivante, bouclez la boucle du feedback en demandant aux collaborateurs ce qui a changé, selon eux, depuis la précédente.

La façon dont vous bouclez la boucle peut avoir un impact considérable sur les taux de réponse des enquêtes suivantes.

Surveillez de près toute baisse des taux de réponse dans le temps. Si une seule équipe est concernée alors que les autres restent stables, c’est un signal : il y a peut-être un manque de confiance dans cette équipe.

Comment Sparkbay peut vous aider à respecter les règles de reporting sur l’engagement

Avec Sparkbay, vous envoyez facilement des enquêtes régulières et vous suivez les résultats grâce à un score d’engagement sur 10. Une fois votre flux SIRH approuvé, il sert pour toutes vos enquêtes Pulse. Les RH peuvent ainsi suivre l’évolution dans le temps sans avoir à redemander des données au service informatique à chaque cycle.

Vous pouvez comparer les résultats entre différents groupes (services, managers, etc.) pour voir où se concentre une tendance avant de décider des mesures à prendre. Chaque manager ne voit que les rapports de ses propres équipes, puisque les droits d’accès sont automatiquement calqués sur la hiérarchie de l’organisation. D’où l’importance d’un flux de données hiérarchiques exact.

Vous pouvez aussi personnaliser les libellés de l’enquête et du tableau de bord, ainsi que son contenu, pour que ce que voient les managers respecte les règles d’accès et de diffusion convenues avec les équipes informatique et confidentialité. Vous pouvez même présenter l’enquête comme « confidentielle » si c’est le terme qui correspond à votre configuration.

Les petits groupes vous inquiètent ? Rien de plus simple à gérer. Sparkbay masque les résultats quand le nombre de réponses est inférieur à un seuil minimal, personnalisable et fixé à 5 par défaut.

Vous pouvez choisir un chiffre adapté à la taille de vos équipes et aux découpages que vous voulez afficher, puis le tester sur des groupes qui se recoupent pour vérifier que ça tient. Nous vous conseillons aussi d’informer les collaborateurs de cette règle avant le lancement de l’enquête.

Si vous souhaitez découvrir comment Sparkbay peut aider vos managers à bâtir une équipe plus engagée, vous pouvez cliquer ici pour une démo.

Préparez votre réunion avec l’IT : apportez tous les éléments nécessaires

Quand vous rencontrerez votre équipe IT, venez avec tous les éléments dont vous pourriez avoir besoin.

À savoir : votre liste de champs (et la justification de chacun), votre schéma de flux de données, les règles d’accès que vous proposez et la source de données sur laquelle elles reposent.

Ayez aussi sous la main les réponses de votre prestataire sur le lieu de stockage des données, les sous-traitants ultérieurs, les mesures de sécurité en place et la manière dont les données seront supprimées.

N’oubliez pas votre vérification des effectifs par cellule. Elle montrera à votre équipe IT que vous avez déjà fait un pas vers elle (en supprimant certains champs, par exemple, ou en élargissant les tranches d’ancienneté) pour tenir compte de ses préoccupations.

Pendant la réunion, demandez de quel accompagnement cette configuration aura besoin de la part de l’IT dans la durée, et qui, selon eux, devra s’en charger une fois la solution en place.

Identifiez aussi ensemble les questions à régler avant de lancer un pilote, et celles qui peuvent attendre la fin de ce pilote.

Si votre première version répond à une vraie question sur l’engagement collaborateurs tout en limitant l’exposition des données, vous aurez un point de départ solide à défendre, et une revue bien plus rapide.

Si vous souhaitez découvrir comment Sparkbay peut aider vos managers à bâtir une équipe plus engagée, vous pouvez cliquer ici pour une démo.