Quand les dirigeants RH deviennent des bâtisseurs
Enseignement de l’expérience: Les projets collaboratifs d’IA ont apporté des éclairages profonds sur les capacités des RH, au-delà du simple développement d’outils.
Cibler le problème: Le passage de l’analyse des sentiments à la cartographie des compétences a mis en évidence l’importance de définir des objectifs clairs et atteignables.
Scepticisme envers l’IA: Les professionnels des RH rencontrent d’importantes difficultés en matière de responsabilité et de transparence avec les plateformes d’IA existantes.
Structure de l’outil: L’outil d’évaluation par IA a mis l’accent sur la collaboration, en permettant aux utilisateurs de confirmer ou de remettre en question les commentaires générés par l’IA.
Tests contradictoires: La création réussie d’un outil nécessite des tests rigoureux avec des données d’entrée variées afin de traiter efficacement les cas limites.
Les réunions étaient prévues pour durer une heure. Elles se prolongeaient presque toujours.
Ce n’est pas inhabituel lorsqu’un groupe de professionnels des RH se réunit pour parler d’IA. Ce qui était inhabituel, c’était ce qu’on leur demandait de faire de cette conversation. Il ne s’agissait pas de l’analyser ni de publier un article de réflexion à son sujet, mais de construire véritablement quelque chose.
À l’automne 2025, j’ai constitué ce que j’appelais des cohortes de bâtisseurs : un petit groupe de professionnels des RH et des opérations liées au personnel que j’avais identifiés comme étant déjà à l’œuvre, réfléchissant déjà aux limites de ce que la profession RH pouvait faire avec l’IA.
Continuez à lire—et continuez à diriger plus intelligemment
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de leaders tournés vers l'avenir exploitant outils, guides pratiques et perspectives pour prospérer à l'ère de l'IA.
Have an account? Log In
L’hypothèse était simple. Les personnes les plus proches des problèmes sont les mieux placées pour construire les solutions. La question était de savoir si elles en seraient capables.
Au total, je constituerais quatre cohortes et je réaliserais en chemin qu’il est plus facile de définir les objectifs de ces sessions qu’on ne le pense. Au final, la plupart des cohortes se sont essoufflées, peinant à concrétiser la vision initiale ou à se fixer un objectif unique. Les agendas, les charges de travail et les exigences de nos véritables emplois ont souvent donné lieu à des conversations qui ont produit d’excellentes idées sans jamais les mener à bien.
Mais une cohorte s’est véritablement constituée et est allée aussi loin qu’elle le pouvait. Le fait est que plus on s’engage dans le projet de construire soi-même, plus il devient difficile de respecter une vision commune et de relever le défi technique.
Cette histoire rend compte de ce qui est issu de ces sessions et je vous la propose comme étude de cas pour construire vos propres solutions.
La cohorte
Ce n’étaient pas des sceptiques de l’IA qu’il fallait convaincre. C’étaient des praticiens qui avaient déjà misé sur ce tournant. Ce que la cohorte leur offrait, c’était un espace structuré pour cesser de conseiller et commencer à créer.
La première conversation honnête
La première session a mis au jour quelque chose qui apparaît rarement dans les commentaires publiés sur les RH : le degré réel de frustration de ces professionnels à l’égard des outils qu’ils sont censés utiliser.
Turnmeyer a donné le ton. Elle avait essayé d’obtenir de la documentation technique sur le fonctionnement de l’analyse des sentiments dans BambooHR, Paycom et Gusto — non pas pour rejeter ces outils, mais parce que son équipe juridique devait les comprendre avant d’en approuver l’utilisation.
Ni les équipes commerciales ni les représentants juridiques n’ont pu répondre à ses questions. Les fonctionnalités d’IA existaient. La responsabilité de leur fonctionnement, elle, n’existait pas.
Gillies était confrontée à une tension similaire. Des voix en interne avaient exprimé des inquiétudes concernant l’impact environnemental de l’IA, et certains collègues voulaient simplement interdire l’utilisation de l’IA par les employés. Gillies s’y est opposée.
Interdire purement et simplement l’IA conduit à une utilisation clandestine et à une augmentation des risques. Adopter l’IA avec des garde-fous est une meilleure approche.
Melina Gillies · Directrice des ressources humaines, Flex Networks
Ce qui ressortait de cette première heure fut un diagnostic sur lequel le groupe pouvait s’accorder. Les fonctionnalités d’IA intégrées aux plateformes RH d’entreprise étaient, comme l’a formulé Gillies, « souvent basiques et dépourvues de fonctionnalités ».
Les outils qui fonctionnent réellement tendent à être conçus sur mesure : pour des problèmes précis, des contextes précis et des entreprises précises. Turnmeyer voulait moins d’outils, et non davantage, un refrain que j’entends souvent de la part des responsables des ressources humaines et des opérations. Elle pouvait imaginer un avenir où une IA performante, alimentée par les bons documents, rendrait un HRIS inutile.
Ils ont également abordé un sujet qui est rarement traité aussi directement : l’éthique du suivi comportemental. L’idée d’utiliser les taux de refus de réunions, les périodes sans connexion aux systèmes ou les horaires de travail inhabituels comme indicateurs indirects du désengagement est apparue très tôt.
Les limites de cette approche ont également été évoquées. Satterfield a nommé un risque auquel tout outil d’engagement finit par être confronté : la lassitude face à l’inaction. Si vous collectez des données sans agir de manière visible, les employés cessent de faire confiance au système. Les données deviennent du bruit et l’outil devient du théâtre de l’IA.
Ils n’étaient pas prêts à créer un outil d’analyse des sentiments. Le sujet était trop vaste, trop chargé de dilemmes éthiques et trop facile à traiter de manière catastrophiquement erronée. Ils ont donc changé de direction.
Trouver le bon problème
La deuxième session a commencé par l’aveu honnête que l’orientation initiale était trop ambitieuse et trop ambiguë.
« Je ne sais pas si cela mesure l’engagement, a déclaré Turnmeyer, ou si cela mesure simplement quelque chose qui nécessite une conversation. »
Cette distinction est plus importante qu’il n’y paraît. Beaucoup de technologies RH commettent l’erreur de traiter les données comme un substitut à la conversation. Le groupe cherchait à utiliser l’IA pour faire émerger les moments où une conversation doit avoir lieu, puis pour améliorer cette conversation.
Satterfield a introduit l’idée qui allait servir de point d’ancrage pour la suite du projet. Lors d’un gel des embauches chez un employeur précédent, elle avait créé une autoévaluation des compétences pour son équipe de recrutement : un moyen de cartographier ce que les personnes savaient faire par rapport à ce qu’elles voulaient réellement faire, en générant une carte thermique qui rendait les décisions de réaffectation plus humaines et plus stratégiques.
Ce n’était pas basé sur l’IA. C’était un formulaire Microsoft. Mais la logique sous-jacente était solide, le cas d’utilisation était réel et elle l’avait vu fonctionner.
« Les grands fournisseurs essaient de faire cela, mais personne ne le fait vraiment bien pour l’instant, et de nombreuses entreprises n’ont pas de budget prévu pour ce type de technologie en plus de leur HRIS principal », a-t-elle déclaré.
Le groupe a vu une possibilité. Et s’il construisait une version conçue nativement pour l’IA ? Une version conversationnelle plutôt que clinique, tournée vers l’avenir plutôt que dictée par la conformité, et proposée à un prix adapté aux responsables RH individuels plutôt que verrouillée derrière des contrats d’entreprise ?
La manière dont les RH parlent aux RH des RH est fondamentalement différente. Cela peut représenter une véritable valeur, et la plupart des outils passent complètement à côté.
Melina Gillies · Directrice des ressources humaines, Flex Networks
Fisher, qui écoutait le groupe explorer les différentes possibilités, a formulé une observation qui a redéfini le potentiel du projet. Il avait connu les deux extrêmes du spectre des RH : le modèle axé avant tout sur la conformité, les cadres et les transactions, et le praticien, plus rare, centré sur les personnes, qui lui parlait « comme quelqu’un qui avait vraiment l’impression d’être de mon côté ».
« Le langage du deuxième type, a-t-il dit, ne donnait jamais l’impression de sortir d’un cadre rédigé des décennies auparavant. Il était simplement agréable. »
Gillies s’est emparée de cette idée. Selon elle, le facteur de différenciation de leur outil résidait dans le ton et la structure. Et s’il pouvait reproduire la manière dont les professionnels des RH se parlent réellement lors d’une conférence, entre deux sessions, officieusement ? Et s’il comprenait que l’expression « politiquement avisé » n’était pas une simple case à cocher, mais une notion chargée, contestée et complexe selon les situations, dont les praticiens expérimentés débattent entre eux ?
La direction était prise : un outil d’évaluation pré-embauche conçu pour les responsables RH et du recrutement qui ont besoin d’une meilleure façon d’évaluer les candidats à des postes de recruteur avant de les embaucher. Ni un test de personnalité ni un filtrage de CV, mais un diagnostic structuré et conversationnel capable d’indiquer à un responsable du recrutement si la personne assise en face de lui savait réellement faire le travail. Un outil qui ressemble moins à une évaluation de performance qu’à une conversation avec quelqu’un qui comprend le recrutement de l’intérieur.
Le moment du déclic
À la troisième session, le groupe était plongé dans l’architecture de l’outil : quelles compétences évaluer, comment les structurer selon les niveaux et comment tenir compte de l’écart entre ce que les personnes disent savoir faire et ce qu’elles sont réellement capables de faire.
La critique des cadres existants est venue de Gillies, qui a décrit le modèle de compétences de la SHRM comme « très traditionnel et très tourné vers le passé à certains égards ». Dans ses mots, la profession était encore dans une « gueule de bois post-industrielle » : fondée sur la conformité et la hiérarchie, conçue pour un monde qui était déjà en train de disparaître.
Leur outil devait s’orienter vers autre chose : non pas ce que les responsables RH avaient besoin de savoir, mais ce qu’ils devaient être capables de faire.
Êtes-vous prêt à avoir une conversation avec le PDG au sujet de sa performance ? Si ce n’est pas le cas, vous n’êtes pas un expert des conversations difficiles.
Erin Turnmeyer · VP des opérations humaines
Turnmeyer avait un exemple particulièrement révélateur. Elle avait récemment passé l’examen SPHR. Les éléments qu’il lui demandait de connaître — lois, définitions procédurales, règles de classification — étaient des choses que tout professionnel RH compétent se contenterait de consulter.
Les compétences techniques ne correspondaient pas au contenu de la certification. Il s’agissait plutôt de choses comme : pouvez-vous vous asseoir en face d’un PDG et lui annoncer quelque chose qu’il ne veut pas entendre ? Pouvez-vous défendre un salarié lorsque l’argumentaire économique est ambigu ? Mémoriser le Code du travail ne répond pas à ces questions.
Fisher est allé plus loin. Il avait passé des années dans la conduite du changement et avait constaté que la variable la plus prédictive de la capacité d’une organisation à naviguer dans une transformation n’était pas une compétence spécifique. C’était le rapport d’une personne à l’ambiguïté.
Déterminer dans quelle mesure une personne est à l’aise face à l’inconfort — ou face au rythme du changement en général — est un indicateur essentiel de sa capacité à fonctionner dans ce nouveau monde.
Tim Fisher · Responsable de l’IA , Black and White Zebra
Vint ensuite ce que le groupe appellerait plus tard la recette secrète.
Gillies souleva une question. Et si l’outil intégrait une vérification croisée ? Si une personne s’évaluait comme experte en gestion des conflits, mais que, dans une réponse en langage naturel à une question de suivi, elle décrivait des situations qui semblaient relever de tout sauf de l’expertise, l’IA pourrait-elle le signaler ? Pourrait-elle indiquer avec tact qu’il y avait peut-être un écart à combler ?
« C’est le déclic », a déclaré Turnmeyer.
Satterfield a souligné que toute personne ayant travaillé avec des inventaires de compétences avait déjà constaté différentes versions du même problème. Les personnes s’évaluent souvent de manière très différente de ce que leur expérience réelle ou leur comportement laisserait supposer.
La valeur de l’outil ne viendrait pas du fait d’enregistrer ce que les personnes croyaient d’elles-mêmes. Elle viendrait de l’étalonnage — cette friction délicate, fondée sur les données, entre la perception de soi et les capacités démontrées.
L’évaluation ne serait pas simplement un miroir. Elle serait davantage un « miroir, mon beau miroir » que ce à quoi la plupart des gens sont habitués avec les évaluations professionnelles.
Les réalités de la construction
Rien de tout cela n’était facile. Et la cohorte le savait dès le départ.
Le défi le plus persistant n’était pas technique. Il concernait le périmètre. Chaque session faisait émerger dix nouvelles orientations, chacune réellement utile et chacune capable d’engloutir le projet tout entier. Turnmeyer l’a identifié très tôt et l’a rappelé souvent.
« Assurez-vous qu’il fasse correctement la première chose, afin de ne pas laisser le périmètre dériver au point de ne plus pouvoir le créer », a-t-elle déclaré.
Satterfield a proposé au groupe un principe directeur : la différence entre un produit minimum viable et un produit minimum utile. Un produit viable fonctionne. Un produit utile donne envie de revenir.
Sur un marché saturé d’outils d’évaluation, une interface qui n’apporte rien de significatif dès la première interaction n’aura pas de seconde chance de s’améliorer. Le critère n’est pas la fonctionnalité. C’est la valeur.
Si le produit n’offre pas suffisamment de valeur dès la première utilisation, il est probable que les utilisateurs ne reviennent pas plus tard pour voir s’il s’est amélioré.
Kelly Satterfield · Responsable RH et consultante
Il y avait également les contraintes pratiques que connaît bien toute personne ayant essayé de créer quelque chose en dehors d’une équipe de développement : déploiement, infrastructure de paiement, intégration aux systèmes existants, fenêtres de contexte qui se ferment en pleine session et effacent des heures de travail productif.
La première version reposait sur le flux central de l’outil. Un candidat à un poste de recruteur télécharge un CV, l’outil en déduit un profil de compétences préliminaire, puis le guide à travers une série de questions conversationnelles conçues pour étalonner cette première lecture et lui apporter du contexte et de la profondeur.
À la fin, un responsable du recrutement obtient une vision de la position réelle du candidat au regard d’un référentiel de compétences défini.
Fisher a mis en place l’environnement principal de développement dans Lovable — un générateur d’IA sans code qui crée des outils destinés au public par le biais d’une conversation, sans enfermer les utilisateurs dans un grand modèle de langage spécifique — afin que l’architecture technique puisse suivre le rythme de la réflexion du groupe sans devenir un goulot d’étranglement à part entière.
Du plan à la construction
À la quatrième session, le groupe ne concevait plus un outil abstrait. Il en construisait un et découvrait, comme toujours les concepteurs, que c’est précisément dans l’écart entre l’idée et son exécution que se produit le véritable apprentissage.
Fisher avait préparé un GPT personnalisé de base avant le début de l'appel, avec des instructions, un cadre de compétences préliminaire et les prémices de la logique conversationnelle qu'ils avaient définie lors des sessions précédentes. Le plan consistait à ce que chacun y accède, le sollicite de manière collaborative et commence à calibrer sa voix et son comportement en temps réel. Le plan s'est immédiatement heurté à la réalité.
Le lien partagé ne fonctionnait pour personne, sauf pour moi. Les autorisations de l'espace de travail, les particularités de la plateforme et la manière spécifique dont ChatGPT gère les accès externes ont absorbé le premier quart de la session.
C'était une petite frustration, précisément le genre de problème qui ne figurerait jamais dans une annonce produit, et elle s'est révélée instructive. Les outils que les professionnels utilisent réellement pour construire des choses ne se comportent pas comme dans les démonstrations.
Cette capture d'écran montre à quoi finirait par ressembler l'écran d'accueil de l'outil créé par le groupe, appelé Talent Scout.
Une fois que tout le monde regardait le même écran, quelque chose de plus intéressant s'est produit. Alors que le groupe discutait encore du format que devraient prendre les définitions des compétences, Gillies a ouvert Claude dans une fenêtre séparée et converti le tableau de notation en JSON structuré — en direct, pendant l'appel.
« J'utilise Claude parce qu'il est meilleur que ChatGPT pour ça », a-t-elle déclaré, sans cérémonie. Quelques minutes plus tard, elle a déposé le fichier mis en forme dans la discussion de groupe. Personne ne s'est arrêté pour le relever. Ils ont simplement poursuivi.
Ce type de résolution de problèmes en cours d'action — transformer un blocage en problème résolu sans en faire l'événement central de la réunion — distingue les professionnels qui ont véritablement intégré ces outils de ceux qui apprennent encore à les utiliser.
Qui a le dernier mot
Satterfield a soulevé une question qui aurait des implications importantes à la fois pour l'architecture de l'outil et pour la manière dont il serait finalement accueilli : est-ce l'IA qui produit la note finale, ou l'utilisateur qui la confirme ?
La distinction n'est pas cosmétique. Si l'outil rend un verdict tel que « D'après vos réponses, vous êtes au niveau 2 en matière d'orientation candidat », il positionne l'IA comme l'autorité. S'il présente plutôt une analyse provisoire et invite l'utilisateur à la contester, la dynamique change complètement. L'évaluation devient collaborative plutôt qu'évaluative. L'utilisateur participe au processus, il n'en est pas le sujet.
« Acceptez-vous ce retour ? », a dit Turnmeyer lorsque l'idée a fait son chemin. « J'adore un peu. »
Gillies a développé la logique. Si l'utilisateur n'accepte pas la note, l'outil demande ce qui lui semble incorrect — puis utilise la réponse soit pour recalibrer son analyse, soit pour la confirmer doucement, en passant en revue les éléments probants.
C'est cet échange conversationnel qui crée la sécurité psychologique dont l'outil a besoin pour être réellement utile. Les gens ne changent pas sur la base d'un retour auquel ils ne font pas confiance. Obtenir l'adhésion n'est pas une fonctionnalité secondaire, c'est le mécanisme.
Le premier vrai test
Ils ont décidé de tester le prototype en direct. Turnmeyer s'est portée volontaire pour donner une réponse volontairement peu étoffée à l'une des questions d'évaluation — le genre de réponse qu'un candidat désengagé ou un employé distrait pourrait fournir.
Elle a décrit une dispute avec son responsable au sujet d'un écart salarial, la perte du candidat et son incapacité à savoir quelle avait été l'issue. C'était l'équivalent RH d'une réponse comme « J'aime vraiment les gens » à la question de savoir pourquoi l'on veut travailler dans les RH.
L'outil l'a évaluée immédiatement. Il lui a attribué un niveau. C'était encourageant. C'était aussi erroné, non pas sur le plan factuel, mais parce que c'était prématuré. Il avait émis des suppositions sur ce que la réponse impliquait au lieu de demander le contexte supplémentaire dont il aurait eu besoin pour évaluer correctement.
Si vous allez attribuer à quelqu'un autre chose que « répond aux attentes », vous devez fournir des exemples détaillés. L'IA devrait s'imposer le même niveau d'exigence.
Erin Turnmeyer · Vice-présidente des opérations du personnel
Turnmeyer a établi directement le parallèle avec sa pratique des évaluations de performance. Elle exigeait depuis longtemps des responsables qu'ils fournissent des éléments concrets avant d'attribuer à quiconque une note supérieure ou inférieure à « répond aux attentes ».
La même discipline devrait s'appliquer à l'outil. Avant d'attribuer un niveau, il faut s'en donner le droit en posant les questions qui rendraient l'évaluation défendable. Une fois encore, c'était l'expertise RH présente dans la salle qui améliorait l'IA — et non l'inverse.
Satterfield a ajouté une complication que l'outil avait négligée. La réponse peu étoffée pouvait refléter la politique en vigueur plutôt que les compétences.
Si le responsable avait réellement fixé un plafond de rémunération, défendre davantage le dossier n'aurait pas changé l'issue. L'outil avait évalué la personne alors qu'il aurait dû s'interroger sur la situation. Les questions de clarification n'étaient pas un élément de finition. Elles constitueraient ce qui distinguerait une évaluation utile d'une évaluation présomptueuse.
Turnmeyer a pris la rédaction des instructions comme devoir : comment inciter un outil à poser des questions de clarification au bon moment sans donner à chaque interaction l'impression d'un interrogatoire ?
Cette capture d’écran montre un exemple de ce que ferait le produit final : poser des questions de clarification et pousser le candidat à approfondir davantage.
C’est un problème plus difficile qu’il n’y paraît, et elle était parfaitement consciente que le niveau d’exigence était exceptionnellement élevé.
« Il faut que ce soit meilleur qu’un humain », a-t-elle déclaré. « C’est la norme. »
Les tests comme discipline
La session a également fait émerger l’un des enseignements méthodologiques les plus utiles sur le plan pratique de toute la cohorte. Lorsque Satterfield a demandé comment le groupe testait habituellement des outils de ce type, Turnmeyer et Gillies ont toutes deux répondu d’une manière qui a révélé quelque chose d’important sur ce à quoi ressemblent réellement des tests rigoureux dans la pratique.
Pour son outil de recommandation d’avantages sociaux, qui devait déterminer avec précision si certains médicaments étaient couverts par le régime d’assurance santé de l’entreprise, Turnmeyer a spécifiquement testé les cas limites. Pas les médicaments évidents, ni les plus populaires que le modèle aurait rencontrés à maintes reprises pendant son entraînement. Elle a testé les médicaments obscurs, dans les catégories les plus susceptibles de produire une hallucination convaincante.
« Je suis allée tester les médicaments qui ne sont pas populaires », a-t-elle déclaré, « parce que Claude m’a montré ce qu’il faisait au fur et à mesure de sa construction. »
Ce niveau d’intentionnalité adversariale dans les tests est rare chez les créateurs venant d’un contexte extérieur à l’ingénierie. C’est aussi exactement ce qui distingue les outils qui gagnent la confiance de ceux qui sont discrètement abandonnés après un échec embarrassant.
Supprimer ce qui est déjà construit
Une session de regroupement juste avant les fêtes a commencé par une question plus difficile à poser qu’il n’y paraît : à quoi sert réellement la fonctionnalité de téléversement de CV ?
Gillies a soulevé la question. L’évaluation demandait aux utilisateurs de réfléchir attentivement à leurs propres capacités. Le CV apportait-il des informations que l’utilisateur ne pouvait pas fournir plus directement, en répondant simplement aux questions ? Personne dans le groupe n’était certain que ce soit le cas. L’intention initiale était de gagner du temps, comme avec un analyseur de CV, mais nous n’étions plus convaincus que cette fonctionnalité remplissait cet objectif.
Ils ont convenu de la supprimer.
C’est plus rare qu’il n’y paraît dans le développement de produits. Le groupe avait consacré beaucoup de temps à la fonctionnalité de téléversement : la construire, la tester, regarder le CV de Satterfield être analysé puis mal évalué. La supprimer exigeait de passer outre la logique des coûts irrécupérables qui pousse les équipes à continuer d’ajouter des éléments à des fonctionnalités dans lesquelles elles ont déjà investi.
Commencez en gardant le résultat final à l’esprit et définissez à quoi ressemble un bon résultat. Si vous ne pouvez pas expliquer à quoi sert une fonctionnalité, vous ne pouvez pas la défendre.
Turnmeyer a formulé un argument connexe sur la méthodologie. Avec le recul, elle pensait qu’elles auraient peut-être pu avancer plus vite en définissant entièrement le comportement de l’outil avant d’écrire un seul prompt. Elles avaient suivi quelque chose qui ressemblait à un modèle agile — construire, tester, ajuster — alors que la complexité de ce qu’elles construisaient aurait peut-être nécessité une approche davantage en cascade : définir correctement les spécifications d’abord, puis construire en fonction de celles-ci.
Elle disposait d’un document de conception de 130 pages issu d’un autre outil qu’elle avait construit, et qui lui avait appris cette leçon. Une spécification complète ne vous dit pas seulement quoi construire. Elle vous dit aussi ce que vous ne construisez pas, ce qui s’avère tout aussi utile.
Gillies a précisé le problème central du produit. Tout ce que l’outil affichait à l’écran devait aller plus loin. Une évaluation qui fait émerger des données n’est pas la même chose qu’un outil qui vous indique quoi en faire. C’est dans cet écart entre résultat et action que les outils de diagnostic cessent discrètement d’être utiles, et c’est un écart que la plupart d’entre eux ne comblent jamais.
Construire seule
En janvier, Satterfield assumait l’essentiel de la construction elle-même, tandis que le reste du groupe était trop accaparé par son travail de 9 h à 17 h, trop chronophage pour laisser la moindre place au projet. Après tout, personne n’était payé pour cela.
Elle avait supprimé le téléversement de CV, comme le groupe en avait convenu. Elle avait ajouté la saisie vocale : les utilisateurs pouvaient désormais répondre aux questions de l’évaluation en parlant plutôt qu’en tapant, ce qui ouvrait la voie à un style de réponse plus conversationnel et plus difficile à contourner qu’un champ de texte.
Elle utilisait ChatGPT pour générer des réponses de test synthétiques (« Je suis une recruteuse junior qui est forte dans ce domaine et faible dans celui-ci, donne-moi des réponses »), puis passait à Lovable pour intégrer ces réponses et observer la manière dont l’outil les évaluait.
Le tableau de bord destiné aux responsables constituait l'autre moitié de la logique de l'outil : la vue qu'un directeur de l'acquisition des talents ou un DRH utiliserait pour voir le score obtenu par un candidat, identifier les lacunes et comprendre comment ses capacités pourraient compléter les forces et les besoins d'une équipe existante.
Cela faisait de la structure organisationnelle un véritable problème, car l'outil devait savoir qui évaluait qui et qui était habilité à voir les résultats.
Satterfield avait essayé de gérer cela en demandant aux utilisateurs de saisir leur nom, leur intitulé de poste et le nom de leur responsable (en l'absence d'une intégration de données). Mais cette logique ne fonctionnait pas dans un scénario courant : celui d'un directeur de l'acquisition des talents qui souhaitait envoyer l'évaluation à une organisation de recrutement plus large comprenant à la fois des relations hiérarchiques directes et indirectes. La logique de cartographie de l'organisation n'était pas suffisamment nuancée pour tenir compte de cette structure.
En théorie, ces informations permettraient à l'outil de mieux comprendre le rôle de la personne évaluée, mais la collecte de données supplémentaires compliquait les choses.
Turnmeyer avait déjà résolu une version de ce problème dans un autre contexte. L'outil de gestion de la performance qu'elle avait conçu pour sa propre entreprise fonctionnait avec Google Sheets, Slack et Claude. Google Sheets stockait les données. Slack était l'interface avec laquelle les employés interagissaient. Claude s'occupait de l'analyse et de la génération des commentaires.
L'architecture était plus simple qu'il n'y paraissait : une feuille de calcul avec le nom, l'adresse e-mail, le niveau de poste et l'intitulé de poste. Un onglet distinct faisant correspondre les niveaux de poste aux compétences.
"La sécurité de mon entreprise voulait examiner mon outil", a-t-elle expliqué au groupe. "J'ai dit qu'il était stocké dans Google Docs. Ils ont répondu : « Oh, c'est aussi simple que ça. »"
Simple, mais Turnmeyer ne l'avait compris qu'en construisant. Ce qu'elle ignorait encore trois semaines plus tôt, c'est que la journalisation existait : une fonction qui enregistre la progression d'un utilisateur afin que l'outil ne soit pas réinitialisé lorsque quelqu'un s'en éloigne puis revient.
"Je jurais contre Claude", a-t-elle dit, "jusqu'à ce qu'il m'apprenne que la journalisation existait.
Voilà ce que l'on apprend réellement en construisant. Non pas ce que l'on avait prévu d'apprendre, mais ce dont on ignorait avoir besoin.
More Articles
La question sous-jacente
À un moment de la session de janvier, la conversation est arrivée à la question autour de laquelle elle tournait depuis des mois.
Le groupe continuait à discuter d'architecture, d'autorisations, de stockage et de tableaux de bord — autant de problèmes bien réels. Mais derrière eux se cachait une question plus fondamentale. Qu'essayaient-ils réellement de construire, et pour qui ?
L'outil, tel qu'il avait été conçu à l'origine, était un outil de diagnostic de sélection : quelque chose qu'un responsable de l'acquisition des talents pouvait envoyer à un candidat ou à un employé interne afin d'évaluer si ses capacités réelles correspondaient à ce qui figurait sur son CV, et de faire émerger cette vision avant qu'une décision de sélection ne soit prise.
Ce que vous voyez ici est une sélection de captures d'écran du type de rapport produit par l'outil pour la personne interrogée. Pour l'évaluateur, un tableau de bord présentant les forces actuelles de l'équipe l'aide à se concentrer sur les points à évaluer chez la personne interrogée afin de voir si elle répond aux faiblesses de l'équipe TA.
Ce principe fondamental n'avait pas changé. Mais chaque décision pratique qu'ils prenaient — ajouter un tableau de bord destiné aux responsables, réfléchir aux modèles d'abonnement, définir un parcours de connexion — les poussait vers quelque chose de plus complexe.
Les tableaux de bord en temps réel impliquaient un accès continu, ce qui entraînait des frais d'abonnement et les rapprochait du type d'outils d'entreprise que de nombreuses organisations ont du mal à s'offrir ou à déployer efficacement.
"Nous n'essayons pas de devenir un fournisseur de SIRH", a déclaré Satterfield.
Turnmeyer a été honnête quant à sa position.
"Mon intention était simplement d'apprendre quelque chose de nouveau."
Il ne s'agissait pas d'un désengagement du projet. C'était un compte rendu fidèle de ce que l'expérience lui avait déjà apporté. Elle avait appris certaines choses nouvelles et travaillait déjà à la construction d'un nouvel outil de gestion de la performance, en appliquant les enseignements tirés de la cohorte.
Elle n'avait pas besoin de transformer l'outil du groupe en produit pour en avoir tiré une réelle valeur.
À ce stade, mon propre intérêt était avant tout éditorial. Je voulais avoir une histoire à raconter et quelque chose que les gens puissent consulter, non pas un produit par abonnement, mais une démonstration permettant aux professionnels des RH d'y réfléchir et peut-être d'en construire un similaire.
La rédaction de cet article en faisait partie. Pourrais-je créer un guide téléchargeable ? Puis, à terme, un événement en direct au cours duquel le groupe pourrait discuter de ce qu'il avait réalisé, permettre à un public d'interagir avec l'outil et enregistrer la conversation sous forme de podcast ? J'avais beaucoup d'idées, mais le temps disponible pour les concrétiser, alors que les objectifs de la nouvelle année s'accumulaient devant nous tous, se réduisait.
L'intérêt de Satterfield était le plus orienté vers la commercialisation, et elle l'affirmait clairement. Elle souhaitait éventuellement transformer l'outil en produit. Elle n'allait pas le faire seule. Mais elle était prête à continuer à construire quelque chose qui pourrait un jour être vendu.
Cette divergence tripartite des intentions — apprendre, raconter, produire — est probablement inhérente à tout groupe de ce type. La conversation franche à ce sujet, en janvier, a été plus utile que de prétendre que tout le monde avait toujours voulu la même chose.
La démonstration comme réponse
La question de savoir comment permettre aux gens d'essayer l'outil était restée sans réponse depuis la mise en ligne du téléversement de CV. Tester avec de vrais utilisateurs est précieux, mais cela crée ses propres problèmes. L'outil doit fonctionner de manière constante, les utilisateurs doivent disposer de suffisamment de contexte pour savoir ce qu'ils font, et il est difficile de se remettre d'une mauvaise première expérience.
Turnmeyer a proposé la résolution la plus simple envisagée par le groupe.
Elle regardait des enregistrements de démonstrations — de courtes présentations, d'une ou deux minutes, montrant le fonctionnement d'un outil sans exiger que le spectateur l'utilise réellement. Elle a suggéré que cela pourrait suffire. Les gens pourraient voir l'outil en action, comprendre ce qu'il faisait et pourquoi, et repartir avec le sentiment que c'était possible.
Ils n'auraient pas besoin de se connecter, de fournir un organigramme ou de rester bloqués lorsqu'une question d'évaluation ne correspondrait pas à leur situation.
Les retours que je reçois de nombreux articles de blog que j'écris, c'est que les gens ne veulent pas vraiment copier-coller exactement la même chose. Ils veulent simplement savoir qu'ils sont capables de le faire.
Erin Turnmeyer · Vice-présidente des opérations liées au personnel
Cette observation met en lumière quelque chose de réel dans la façon dont les professionnels des RH abordent actuellement les outils d'IA. Le fossé que beaucoup d'entre eux doivent franchir ne se situe pas entre le fait de savoir que quelque chose existe et celui de l'utiliser. Il se situe entre la conviction qu'ils sont capables de faire une telle chose et le fait de ne pas le croire.
Une démonstration montrant des professionnels en train de créer leur propre outil répond à une question différente de celle à laquelle répond un produit fini — non pas « cet outil est-il bon ? », mais « quelqu'un comme moi aurait-il pu le créer ? »
L'idée a été bien accueillie. Elle répondait aux préoccupations liées aux tests, réduisait la complexité du partage de quelque chose qui n'était pas prêt pour la production et maintenait l'accent là où le groupe l'avait toujours voulu : sur le processus et la réflexion, et pas seulement sur le résultat.
Ce que l'expérience nous a appris : un guide pour les créateurs d'outils RH
- Commencez par le problème, pas par la technologie. L'enthousiasme initial du groupe pour l'analyse des sentiments était sincère, et l'a éloigné d'un problème plus facile à traiter et plus utile. Le changement de cap vers la cartographie des compétences a fonctionné parce qu'il partait d'un cas d'usage réel qui avait déjà été testé sur le terrain.
- Le sur-mesure l'emporte sur le générique. Chaque participant avait été confronté aux limites des plateformes RH d'entreprise. Les outils conçus pour des contextes précis — le recommandateur d'avantages sociaux de Turnmeyer, la carte thermique de Satterfield — ont surpassé les solutions prêtes à l'emploi. Les arguments en faveur de la création de son propre outil n'ont jamais été aussi solides, et les obstacles n'ont jamais été aussi faibles.
- La vérification croisée est l'essentiel. Les autoévaluations ne valent que ce que vaut la connaissance que les gens ont d'eux-mêmes, laquelle est notoirement peu fiable. La véritable valeur d'un outil réside dans sa capacité à sonder, à remettre en question et à recalibrer avec tact — et non pas simplement à enregistrer ce que les gens pensent d'eux-mêmes.
- Minimum utile, pas minimum viable. Si la première version ne fournit pas quelque chose qui donne envie à l'utilisateur de revenir, la feuille de route n'a aucune importance. Concevez la première impression, pas la cinquième.
- L'adhésion est structurelle, pas secondaire. La question de savoir si l'IA produit la note finale ou si l'utilisateur la confirme n'est pas un détail d'expérience utilisateur. Elle détermine si l'outil est une autorité ou un collaborateur, et cette distinction façonne tout ce qui concerne la manière dont il est accueilli et utilisé.
- Supprimez les fonctionnalités que vous avez déjà créées. Le raisonnement fondé sur les coûts irrécupérables pousse les équipes à ajouter des éléments à des projets dans lesquels elles ont investi, longtemps après que ces éléments ont cessé de mériter leur place. Si vous ne pouvez pas expliquer à quoi sert une fonctionnalité, vous avez votre réponse. La supprimer relève de la discipline produit, pas de l'échec.
- Testez de manière contradictoire, et tôt. Trouvez des personnes qui vous diront que l'outil est mauvais. Donnez-lui la pire entrée raisonnable que vous puissiez imaginer et observez ce qu'il fait. Intégrez les cas limites avant de peaufiner les cas habituels. La crédibilité de l'outil dépend de la manière dont il gère les situations pour lesquelles il n'a pas été conçu.
- L'outil doit mériter le droit d'évaluer. Attribuer une note avant d'avoir posé suffisamment de questions relève de la présomption, pas de l'efficacité. Les questions de clarification sont ce qui rend l'évaluation défendable, et c'est cette capacité à être défendue qui permet aux retours d'être pris en compte.
- Soyez honnêtes sur les raisons de la présence de chacun. Les intentions divergentes au sein d'un groupe ne sont pas un problème à gérer : ce sont des informations. Les mettre sur la table rapidement évite à tout le monde de construire autour d'un objectif que seule une partie du groupe partage réellement.
- Les conversations les plus difficiles sont les plus importantes. Le groupe a créé un outil pour évaluer les compétences RH et, ce faisant, a eu l'une des conversations les plus honnêtes sur les limites des RH dont chacun pouvait se souvenir. Cette conversation — sur les cadres tournés vers le passé, sur l'écart entre les connaissances d'examen et le jugement situationnel — constituait le produit tout autant que l'outil.
Les séances qui avaient commencé par un engagement de quatre appels se sont prolongées pendant l'hiver, puis jusqu'à la nouvelle année. Le prototype continuait d'évoluer. Les intentions des personnes qui l'avaient créé s'étaient précisées d'une manière qui ne se résolvait pas facilement.
Satterfield continuait de construire. Turnmeyer avait pris ce qu'elle avait appris et l'avait appliqué ailleurs. Gillies avait poussé le groupe à être plus rigoureux quant à ce que l'outil était réellement censé faire. J'écrivais l'histoire de tout cela.
Turnmeyer avait dit quelque chose au début du processus qui était resté vrai : elle construisait non pas parce qu'on le lui avait demandé, mais parce qu'elle avait besoin de comprendre.
Cette compréhension de ce que font réellement les outils d'IA, de ce qu'ils font mal et de ce qu'il faut pour les rendre utiles, n'était disponible dans aucune conférence ni démonstration de fournisseur. Elle venait des décisions prises par le groupe, des fonctionnalités qu'il avait supprimées et des moments où l'outil évaluait incorrectement quelqu'un et où ses membres devaient comprendre pourquoi.
Les éléments les plus utiles produits par le groupe ne se trouvaient pas dans le prototype. Ils résidaient dans le raisonnement qui le sous-tendait.