Analytique RH et engagement des employés : passez plus vite la revue TI

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

Les plateformes d’engagement doivent en tenir compte. Or, les équipes RH pensent rarement aux retombées possibles des données qu’elles comptent extraire du flux SIRH, ou aux rapports qu’elles veulent produire à partir des données de sondage.

Quand on mise sur l’analytique RH pour renforcer l’engagement des employés, l’objectif est assez clair : repérer rapidement les problèmes d’engagement, donner aux gestionnaires des informations utiles et agir avant de perdre de bons employés.

Vous connaissez la suite : vous choisissez votre fournisseur, vous fixez une date pour votre sondage d’engagement, puis vous demandez à votre département informatique de vous aider à relier le sondage au SIRH de votre entreprise.

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

Votre équipe TI 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 un fournisseur, sans aucun document décrivant les spécifications des données. Faute d’informations concrètes à examiner, les TI doivent envisager le pire : le lien avec le sondage pourrait exiger 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 ayez hâte de lancer votre projet d’analytique de l’engagement, pour que les résultats ne soient pas déjà dépassés à leur arrivée. C’est un besoin tout à fait légitime pour l’entreprise. Mais votre département informatique a raison de vous rappeler une chose : même si les réponses au sondage sont correctement anonymisées, des données démographiques ou hiérarchiques suffisamment détaillées, chargées en même temps que les réponses, peuvent quand même exposer des renseignements sur les employés.

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

Quand viendra le moment de la revue de sécurité, vous faciliterez grandement les choses en remettant à votre équipe TI un document qui précise les champs dont vous avez besoin et pourquoi, un schéma des flux de données et des règles indiquant qui peut accéder aux données, le tout à partir d’une source clairement identifiée.

Dans cet article

1. Pourquoi les équipes informatiques s’opposent aux projets d’engagement des employés
2. Vous n’avez sans doute pas besoin d’autant de données que vous le croyez
3. Avant de parler d’intégrations, déterminez quelles données il faut absolument recueillir et conserver
4. Déterminez avec qui les données seront partagées et si elles doivent rester anonymes
5. Donnez à vos équipes de la confidentialité et du juridique assez d’information pour vérifier la conformité
6. Organisez une revue à l’interne pour recueillir la rétroaction des départements concernés sur le logiciel d’engagement des employés que vous proposez
7. Prenez des décisions éclairées grâce à la configuration logicielle approuvée
8. Présentez une configuration logicielle approuvée à votre département informatique

Pourquoi les TI freinent-elles les projets d’engagement ?

Pourquoi votre équipe informatique met-elle des freins à votre projet d’engagement ?

Tout simplement parce qu’elle s’est déjà fait prendre par le passé avec des demandes mal ficelées.

Un exemple :

Vous voulez lancer votre plateforme d’engagement des employés. En attendant que le flux API ou SFTP soit en place, votre fournisseur vous demande de lui envoyer une population de départ. Quelqu’un dans votre équipe se dit que cette exportation ne devrait 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 pendant des années dans une boîte de courriel partagée, dans un dossier d’intégration du 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 d’informatique fantôme, 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 ?

Précisez clairement que le premier transfert de données passera par le même canal contrôlé que la synchronisation régulière. Autrement dit, il n’y aura aucune exportation ponctuelle.

Si vous ne pouvez pas mettre le flux en place avant le premier sondage, reportez ce sondage jusqu’à ce que vous soyez en mesure de vous engager sur la mise en place du flux.

Pourquoi ? Parce que, selon le rapport annuel de Verizon sur les enquêtes de violations de données, la plupart des violations comportent un facteur humain, comme une erreur, un mauvais usage ou de l’ingénierie sociale. Bref, ce sont souvent des personnes qui sont à l’origine des failles de sécurité.

Une autre raison peut expliquer les réticences de votre équipe informatique : la responsabilité du projet d’engagement est partagée. Les RH en sont « responsables », puisque c’est leur équipe qui cherchera à comprendre le « pourquoi » et décidera de la marche à suivre une fois les données recueillies.

L’équipe informatique, elle, « s’occupe » du projet, puisque c’est elle qui met en place les contrôles techniques.

Et les autres équipes ? Il serait logique d’associer aussi les équipes SIRH aux projets d’engagement des employés, non ?

Pourquoi ? Lors d’une réorganisation, la nouvelle structure hiérarchique peut perturber le flux de données entre la hiérarchie et le reste de l’organisation. Même si la hiérarchie est configurée pour se mettre à jour automatiquement, il faut qu’une équipe puisse intervenir pour rétablir le flux. D’où l’importance de désigner une personne ou une équipe responsable de la question.

Et de fixer un délai d’intervention.

Avant de démarrer un nouveau projet d’engagement ou de sondage, entendez-vous sur la personne à joindre et sur le délai dans lequel elle pourra intervenir.

Il est aussi important de fixer les « règles du jeu » avant le sondage d’engagement.

Par exemple, une pratique courante dans le secteur consiste à figer la hiérarchie le jour du lancement du sondage et à rattacher tous les résultats à cette version.

Ainsi, les changements organisationnels survenus pendant le sondage ne seront pris en compte qu’au cycle suivant.

Pourquoi ? Parce que les équipes RH et informatique n’ont pas à jongler avec deux organigrammes différents pour un seul rapport de sondage.

Quelle question poser pour trancher le débat ?

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

Recueillez moins de données que vous ne le pensez

Pendant votre projet d’analytique RH, méfiez-vous de la tentation d’élargir peu à peu le périmètre. Votre équipe voudra peut-être greffer aux flux de données du sondage des évaluations de rendement, des données de paie ou des métadonnées de collaboration, parce que ce serait « intéressant à avoir » ou que ça donnerait une « meilleure vue d’ensemble » dans un tableau de bord.

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

Ce genre de découpage augmente le risque de réidentification.

Avant de demander un champ en particulier, faites quelques calculs rapides. Servez-vous de votre SIRH pour savoir combien de personnes se trouvent actuellement dans certains groupes. Si possible, rendez une dimension moins détaillée (par exemple trois tranches d’ancienneté au lieu de six) ou optez pour une autre solution (par exemple recueillir les données par région plutôt que par site) afin de réduire les risques de réidentification.

Vérifier que le champ demandé cadre avec le système de classification des données déjà en place dans votre organisation, plutôt que d’inventer une règle sur mesure pour ce projet, peut aussi vous aider plus tard à repérer et à réduire les risques. Demandez également à vos équipes TI et de la confidentialité de passer en revue les risques liés à la collecte; vous aurez ainsi l’assurance 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 directement dans le sondage. Vous pouvez aussi permettre aux employés de ne pas répondre à cette question : leur réponse vaudra alors consentement à l’utilisation de ces données, ce qui est préférable à des suppositions de la part de votre équipe RH.

Autre façon d’éviter de demander trop de données : gardez en tête la question précise à laquelle vous voulez répondre. Si vous cherchez à comprendre le niveau d’engagement d’un groupe dans les différents départements, il vous faudra savoir qui fait partie de ce groupe, dans quel département ces personnes travaillent, qui est leur gestionnaire et quel est leur statut d’emploi.

N’oubliez pas que les données sur les liens hiérarchiques peuvent être inexactes, surtout dans une organisation « matricielle », où les données du SIRH à ce sujet sont parfois erronées ou floues. Si vous comptez vous en servir pour restreindre l’accès à certains rapports, vous avez un problème de sécurité, et pas seulement un problème de qualité des données.

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 distincte et justifiée.

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

Même si les données sont « triées » par la suite, chaque champ intégré au départ devra être protégé, sécurisé, pris en compte dans les demandes d’accès des personnes concernées et supprimé au bout d’un certain temps.

Cela dit, il ne faut pas non plus tomber dans l’excès inverse : une collecte trop « légère » risque de ne pas vous donner les informations dont vous avez besoin. Si vous voulez savoir si la première année d’un employé diffère des suivantes, une demande de données sur l’ancienneté se justifie facilement. Vous évitez ainsi de demander la date d’embauche exacte, qui pourrait faciliter la réidentification de personnes récemment embauchées dans de très petites équipes spécialisées.

Depuis des années, les études de Gallup sur le monde du travail montrent que seule une minorité de travailleurs se disent engagés.

Montrez à l’équipe TI comment circulent les données dans votre organisation

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

Un bon exercice consiste à préparer un schéma récapitulatif d’une page, plutôt que d’obliger votre équipe à éplucher une liste de fonctionnalités.

À gauche du schéma, indiquez la source des informations du SIRH, les champs qu’il envoie, la fréquence d’envoi et, si les mises à jour sont horodatées, leur date d’entrée en vigueur.

Où les réponses au sondage sont-elles stockées ? Certaines données sont-elles exportées de la plateforme de sondage pour la production de rapports à l’interne ?

Quand votre plateforme de rétroaction des employés 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 rompue.

Que se passe-t-il si la synchronisation par API s’interrompt ? L’API continue-t-elle de fonctionner avec le dernier organigramme connu ? Les gestionnaires perdent-ils l’accès aux tableaux de bord tant que le problème de synchronisation n’est pas réglé ?

Si vos synchronisations SFTP suivent un calendrier fixe, demandez si les fichiers sont chiffrés au repos (par exemple avec PGP) et si le fournisseur les supprime après l’intégration ou les garde indéfiniment.

Que se passe-t-il si le fournisseur reçoit des données mal formatées ? Ou un fichier d’exportation tronqué qui laisse croire, par exemple, que « ces 400 personnes ont quitté l’entreprise », alors que la plateforme devait simplement mettre à jour les données de ces 400 personnes ?

Vous risquez alors des problèmes de production de rapports ou d’accès.

Le fournisseur peut-il rejeter des données en fonction d’un seuil de tolérance établi avec votre équipe ? Peut-il signaler le problème à quelqu’un de votre équipe ?

Votre organisation dispose-t-elle déjà d’une équipe responsable des intégrations qui utilise un intergiciel ? Si oui, continuer de l’utiliser simplifiera la maintenance au quotidien.

Votre équipe pourra en effet profiter des fonctions de surveillance et d’alerte déjà offertes par cet intergiciel.

Votre organisation doit cependant savoir que les données des employés transiteront aussi par cet intergiciel, et qu’il enregistre souvent les données reçues et envoyées.

Indiquez-le sur vos schémas pour que personne ne passe à côté.

Autre piège qui fait déraper bien des organisations sur le plan de la sécurité : envoyer par défaut toutes leurs 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 regrouper toutes les données au même endroit à des fins d’analyse, dans le cadre d’une gouvernance plus large.

Mais une fois vos données de sondage versées dans cet entrepôt, le seuil de production de rapports de votre plateforme de sondage ne s’applique peut-être plus.

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

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

Sinon, appliquez vous-même un seuil dans votre propre couche de production de rapports.

N’oubliez pas non plus d’indiquer le processus d’authentification.

Vérifiez si votre plateforme prend en charge l’authentification unique (SSO). Si la désactivation des accès passe par votre processus de gestion des identités, assurez-vous que votre plateforme le prend en charge. Informez-vous aussi pour savoir si votre organisation utilise SCIM.

Sachez que SCIM supprime les comptes utilisateurs, mais que ce qu’un gestionnaire 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 gestionnaire qui a changé de poste pourrait encore voir les résultats de ses anciennes équipes tant que l’organigramme n’est pas mis à jour.

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

Importer le fichier complet de vos employés dans un environnement de test « juste pour voir si la correspondance fonctionne », c’est recréer le problème des fichiers Excel qui se multiplient, mais ailleurs.

Pensez plutôt à un cas de test qui suit le parcours d’un employé : il arrive dans l’organisation, fait partie d’une équipe, reçoit un sondage, change de département pendant le cycle du sondage, puis finit par quitter 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 transmis, sont-ils rattachés à l’équipe au nom de laquelle l’employé a répondu, ou à son équipe actuelle ?

Faut-il distinguer l’accès à la plateforme de l’accès aux rapports ?

Quand vous définissez les autorisations de votre plateforme de sondage, posez-vous ces deux questions séparément :

• Qui a le droit de se connecter à la plateforme de sondage ?
• Qu’est-ce que chaque utilisateur peut consulter ou ouvrir sur la plateforme ?

Par exemple, les administrateurs de sondage doivent pouvoir créer des sondages et veiller au bon fonctionnement du système, mais cela ne veut pas dire qu’ils doivent automatiquement voir tous les rapports de l’organisation.

De la même façon, les gestionnaires peuvent avoir besoin des résultats agrégés de leur équipe, mais ils ne devraient pas avoir accès aux réponses individuelles.

Dans son livre Privacy in Context, Helen Nissenbaum explique que l’utilisation appropriée 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 employé remplit un sondage 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 gestionnaires peuvent voir les réponses qui leur sont liées, même indirectement, ces normes sont bafouées.

Bien 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, mais le chiffre idéal fait débat.

Certaines organisations fixent des seuils plus élevés pour certains groupes démographiques ou pour l’affichage des commentaires, car ceux-ci contiennent souvent des détails qui permettent facilement d’en identifier l’auteur.

Il faut donc s’attendre à ce que les résultats des petites équipes ne soient pas toujours consultables.

Selon la taille de vos équipes, cela peut poser problème. Si la plupart des équipes sur le terrain comptent de 6 à 8 employés et que le seuil est fixé à 7, vos gestionnaires ne pourront probablement pas voir les résultats de la majorité de leurs équipes.

Il pourrait alors être judicieux de prévoir deux seuils distincts : un plus bas pour les scores du sondage et un plus élevé pour l’affichage des commentaires.

Gardez aussi en tête qu’un seuil minimal n’empêche pas complètement de faire des déductions. Par exemple, un gestionnaire qui sait qu’une seule nouvelle personne s’est jointe à son équipe pourra comprendre ce qui a changé en comparant les résultats d’un cycle de sondage à l’autre.

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

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

En soustrayant 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 compte moins de personnes que le seuil exigé pour afficher les données, l’utilisateur a contourné votre règle de seuil.

Pour repérer ces failles, faites vos tests de différenciation à partir de la hiérarchie réelle de votre organisation.

Les commentaires comportent aussi des risques particuliers : la façon d’écrire, le style ou les événements évoqués peuvent trahir leur auteur. Décidez donc bien à l’avance qui peut lire les commentaires bruts, si les gestionnaires les voient tels quels ou seulement 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 signalant les 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) et le chiffrement des données en transit et au repos sont évidemment utiles.

Mais elles ne règlent pas la question de savoir qui peut consulter tel ou tel rapport.

À noter : au sens du RGPD, les données pseudonymisées restent des données à caractère personnel.

Tout cela a une incidence sur ce que vous annoncez à vos employés. Si des identifiants permettent de relier les réponses à des personnes identifiables, il est plus juste de parler de sondage « confidentiel » que de sondage « anonyme ».

Sinon, vous risquez de perdre la confiance de vos employés ou de vous attirer des problèmes de conformité avec vos équipes de la confidentialité.

Justement, côté conformité, demandez à votre fournisseur quels changements d’autorisations ou quelles exportations de données sont consignés dans le journal d’audit.

Votre département informatique a-t-il accès à ce journal ? Si les changements d’autorisations ou les exportations ne sont pas consignés ou 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 faire des audits 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 de la confidentialité et du juridique du concret à examiner

Dire « Nous respectons le RGPD » ne suffit pas aux équipes de la confidentialité, aux responsables des politiques internes ni aux équipes juridiques.

Elles ont besoin de détails sur le sondage : 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 demanderez le consentement des employés ou si vous vous appuierez sur une autre base légale pour traiter leurs données personnelles.

Il vaut souvent mieux éviter de miser sur le consentement, car celui des employés est fragile en raison du déséquilibre de pouvoir inhérent entre l’entreprise et son personnel.

Pour mener des sondages 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 bien documentée).

Ensuite, les règles de codétermination varient énormément d’une juridiction à l’autre.

En Allemagne, par exemple, les comités d’entreprise ont un droit de codétermination sur les systèmes techniques capables de surveiller le comportement ou le rendement des employés.

Une plateforme d’engagement alimentée par des données du SIRH pourrait tomber dans cette catégorie.

Communiquez avec votre comité d’entreprise avant de fixer la date de lancement du sondage : vous pourriez devoir respecter certaines étapes de consultation assorties de délais précis.

Vous pouvez aussi voir votre comité d’entreprise comme un partenaire dans la conception du sondage, et pas seulement comme une instance qui l’approuve.

S’il participe, par exemple, aux décisions sur le seuil de production de rapports ou sur le traitement des commentaires, il sera sans doute plus enclin à appuyer le sondage auprès des employés.

À l’inverse, si on lui présente une configuration déjà arrêtée, il pourrait vouloir retourner à la table des négociations.

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

Le cas échéant, mieux vaut la réaliser au moment où vous commencez à concevoir le flux des données personnelles utilisées pour le sondage.

Si vous décidez de retirer un champ avant le lancement, vous n’aurez pas à rouvrir la discussion plus tard, après avoir bâti des rapports de tendance à partir de ce champ.

Il faudra également bien comprendre les durées de conservation propres au flux de données entre le SIRH et le sondage, aux données du sondage elles-mêmes et, s’il y a lieu, aux données agrégées.

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

Si vous comptez garder seulement des données anonymisées ou agrégées pour comparer les années, insistez bien sur cette distinction et entendez-vous là-dessus avec les équipes de la confidentialité et du juridique. Vous ne voulez pas promettre des tendances sur trois ans pour vous rendre compte après coup que c’est impossible.

De la même façon, convenez qu’en cas de demande d’effacement, les réponses individuelles de l’employé seront supprimées, mais pas les données déjà intégrées à un ensemble agrégé.

Que faut-il apporter à votre première rencontre avec les TI et l’équipe de la confidentialité ?

• La question à laquelle le sondage doit répondre, les champs nécessaires pour y répondre et la raison d’être de chacun
• Un schéma indiquant où les données seront transférées et stockées, avec les intergiciels ou exportations supplémentaires, s’il y a lieu
• Les données auxquelles les RH, les administrateurs et les gestionnaires auront accès, ainsi que la source de données qui détermine ces règles d’accès
• Le seuil de production de rapports, la façon dont vous comptez traiter les commentaires et votre stratégie de tests de différenciation pour les petits groupes
• Les durées de conservation prévues et la documentation de sécurité du fournisseur

Évaluer les fournisseurs : n’ayez pas peur des questions difficiles

Un certificat de sécurité aide votre département informatique à comprendre comment le fournisseur gère son programme de sécurité, mais il ne vous dit rien sur les vulnérabilités de votre propre configuration.

Demandez aux fournisseurs les attestations dont ils disposent (par exemple une certification ISO 27001 ou un rapport SOC 2 Type II). Ces attestations ne sont pas interchangeables, et un bon fournisseur n’a pas forcément les deux. Pour l’ISO 27001, demandez le périmètre de la certification : couvre-t-elle seulement 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 votre évaluation, demandez aussi si le fournisseur est certifié ISO 27701.

Si votre équipe TI utilise un questionnaire standard pour les fournisseurs (comme SIG Lite ou CAIQ), envoyez-le dès le début de l’évaluation, pas une fois le fournisseur choisi. Quand les documents seront remplis, vous pourrez relever les points préoccupants ou poser d’autres questions. Vous voudrez par exemple savoir où les données seront stockées, si elles passeront par des sous-traitants ultérieurs (par exemple un fournisseur d’IA ou d’analyse de texte pour traiter les commentaires), comment vous serez avisé en cas de violation, comment les données vous seront remises puis supprimées à la fin du contrat, et bien plus encore.

Pour l’IA en particulier, demandez si des données tirées des commentaires serviront à entraîner des modèles au-delà de votre environnement dédié. Une réponse positive ne vous oblige pas nécessairement à écarter le fournisseur, mais l’avis relatif au sondage devra clairement mentionner ce nouvel usage des données.

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

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

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

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

Si tout va bien, on pourrait être tenté de se lancer tout de suite dans la prédiction des départs à l’échelle individuelle.

Notre conseil : résistez à la tentation ! En étudiant les tendances par groupe et en donnant aux gestionnaires des résultats sur lesquels ils peuvent agir, vous inspirerez davantage confiance et vous serez plus utile pendant votre première année.

Pourquoi respecter cet ordre ? Parce que vos rapports descriptifs (par exemple : où l’engagement des employés est-il faible ?) bâtiront la confiance nécessaire pour passer ensuite aux rapports diagnostiques (pourquoi l’engagement est-il faible à cet endroit ?).

De plus, si vous construisez des modèles prédictifs avant d’avoir des rapports descriptifs et diagnostiques, vous n’aurez aucune donnée de référence fiable pour les tester.

Imaginons que l’engagement baisse dans un département après un changement d’horaires. L’équipe RH pourrait pousser l’analyse pour voir si la baisse touche tout le département ou si elle se concentre plutôt dans une équipe particulièrement grande.

Le gestionnaire de cette équipe peut alors aborder la question de façon informelle avec ses employés et discuter du changement d’horaires avant de décider si une mesure s’impose (par exemple, une meilleure passation des consignes entre les quarts de travail).

Évidemment, il ne s’agit que d’un exemple fictif de conversation possible, et non d’une marche à suivre : les sondages d’engagement ne servent pas à diagnostiquer les changements dans le milieu de travail.

Ils constituent plutôt une donnée parmi d’autres, qui vous aide à poser des questions et à amorcer le dialogue. Et ce sont ces conversations qui vous donnent l’occasion d’apporter des changements dans le milieu de travail.

N’oubliez pas que, selon les études de Gallup, 70 % des écarts d’engagement entre les équipes s’expliquent par le gestionnaire.

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 rendement des gestionnaires.

C’est justement ce qui pousse les gestionnaires à « gérer leurs scores », et les employés s’en rendent bien compte.

Les avis sur la question varient d’une organisation à l’autre, mais ça vaut la peine d’y réfléchir. À tout le moins, il faudrait ajuster les scores d’engagement en fonction de variables comme la charge de travail et les conditions de travail avant de tirer des conclusions sur un gestionnaire.

Gallup observe aussi une corrélation entre un engagement élevé et un roulement plus faible. Pour voir si ce lien se vérifie dans vos propres données, commencez par analyser l’évolution des tendances par groupe.

Relier les réponses au sondage aux données individuelles des employés ou aux données de départ va à l’encontre de la promesse faite aux employés. Si vous l’envisagez, assurez-vous de :

• En discuter avec vos équipes TI et de la confidentialité.
• Mettre à jour l’avis relatif au sondage pour mentionner cette possibilité.

Au prochain sondage, essayez de boucler la boucle de la rétroaction en demandant aux employés ce qu’ils ont remarqué depuis le sondage précédent.

La façon dont vous bouclez cette boucle peut avoir un effet considérable sur les taux de réponse des sondages suivants.

Si vos taux de réponse baissent avec le temps, soyez attentif. Si la baisse se limite à une seule équipe alors que les autres restent stables, c’est un signal à prendre au sérieux : il y a peut-être un manque de confiance dans cette équipe.

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

Sparkbay simplifie l’envoi de sondages réguliers et le suivi des résultats grâce à un score d’engagement sur 10. Une fois votre flux SIRH approuvé, vous pouvez le réutiliser pour chaque sondage pulse. Les départements RH suivent ainsi facilement l’évolution des résultats, sans devoir redemander des données au département informatique à chaque cycle.

Vous pouvez comparer les résultats de différents groupes (par exemple par département ou par gestionnaire) pour voir où se concentre une tendance avant de décider des mesures à prendre. Comme les droits d’accès sont automatiquement associés à la hiérarchie organisationnelle, les gestionnaires ne voient que les rapports de leurs propres équipes. D’où l’importance d’avoir un flux de données hiérarchiques exact.

Vous pouvez aussi configurer le libellé du sondage, le tableau de bord et son contenu, pour que ce que voient les gestionnaires respecte les règles d’accès et de divulgation convenues avec les équipes informatique et de la confidentialité. Vous pouvez même présenter le sondage comme « confidentiel » si c’est le terme qui correspond à votre configuration.

Les petits groupes vous inquiètent ? C’est facile à gérer : Sparkbay masque les résultats lorsque le nombre de réponses est inférieur à un seuil minimal. Ce seuil est 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 avec des groupes qui se recoupent pour vous assurer que tout tient. Nous vous recommandons aussi d’informer les employés de cette règle avant le lancement du sondage.

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

Préparez votre rencontre avec les TI : arrivez avec tous les éléments en main

Quand vous rencontrerez votre équipe TI, assurez-vous d’avoir sous la main tout ce dont vous pourriez avoir besoin.

Cela comprend votre liste de champs (et la raison d’être de chacun), votre schéma de flux de données, ainsi que les règles d’accès que vous proposez et la source de données qui les détermine.

Ayez aussi à portée de main les réponses de votre fournisseur sur le lieu de stockage des données, les sous-traitants ultérieurs, les mesures de sécurité en place et la façon dont les données seront supprimées.

N’oubliez pas votre vérification du nombre de cellules. Elle montrera à votre équipe TI que vous avez fait un pas vers elle (par exemple en retirant certains champs ou en regroupant davantage les tranches d’ancienneté) pour tenir compte de ses préoccupations.

Pendant la rencontre, demandez quel soutien continu cette configuration exigera de la part des TI et qui, selon elles, devrait s’en charger une fois la solution en place.

Déterminez aussi ensemble quels points doivent être réglés avant de lancer un projet pilote, et lesquels peuvent attendre la fin de celui-ci.

Si votre première version répond à une question utile sur l’engagement des employés tout en limitant l’exposition des données, vous partirez sur des bases solides et votre revue avancera beaucoup plus vite.

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