Outils IA RH : évaluer une démonstration avant le pilote

Réponse courte

Évaluez un outil IA RH sur un seul travail réel, avec les mêmes cas et les mêmes exigences pour chaque fournisseur. Demandez une sortie vérifiable, ses sources, les rôles qui peuvent la voir ou la corriger, les erreurs attendues et l'action humaine suivante. Une démonstration utile se termine par une décision argumentée : tester sur un périmètre borné, demander une nouvelle preuve ou arrêter.

Définir le travail avant d'ouvrir la démonstration

Une liste de fonctions ne permet pas de choisir entre des produits qui répondent à des besoins différents. Résumer une politique, acheminer une demande, rechercher des candidats, préparer une conversation et établir un scénario d'effectifs ne produisent ni la même sortie, ni les mêmes conséquences.

Écrivez d'abord le mandat en une phrase :

Pour [population et situation], [responsable nommé] doit pouvoir [tâche ou décision] à partir de [sources autorisées], sans [inférence, divulgation ou action exclue].

Exemple : « Pour les nouvelles recrues des équipes de service UK et US, la responsable RH doit préparer une discussion sur les passations du premier service à partir de récits volontaires et du parcours d'intégration approuvé, sans évaluer la performance individuelle. »

Cette phrase empêche le fournisseur de remplacer votre besoin par la fonction la plus spectaculaire de son produit. Si vous hésitez encore entre règle, workflow, modèle ou conversation, commencez par distinguer IA et automatisation. Si le travail n'est pas encore choisi, le guide des cas d'usage IA RH aide à sélectionner un premier test.

Le Technology Code of Practice britannique demande aux organismes publics concernés de partir des besoins utilisateurs, de prévoir accessibilité, protection des données, intégration et stratégie d'achat. Il ne régit pas automatiquement un acheteur privé, mais ses questions évitent une démonstration détachée du service réel.

Envoyer une fiche de démonstration au fournisseur

La même fiche doit être utilisée pour chaque proposition. Ne demandez pas seulement « montrez-nous l'IA ». Demandez au présentateur d'exécuter un scénario précis dans le module et la configuration qui seraient effectivement contractés.

Champ	Ce que l'équipe acheteuse fixe
Travail	La tâche ou décision que la sortie doit préparer
Utilisateur	La personne qui utilise la sortie et son niveau d'autorité
Matériel de test	Cas fictifs réalistes, y compris information absente, ancienne, contradictoire ou corrigée
Sortie attendue	Format, niveau de détail, source et incertitude visibles
Limite	Ce que l'outil ne doit ni déduire, ni décider, ni montrer
Accès	Ce que voient le participant, le manager, la RH et l'administrateur
Intervention humaine	Qui peut modifier, refuser, suspendre ou reprendre le résultat
Critère obligatoire	Condition dont l'échec interdit la suite
Preuve conservée	Capture, version, cas utilisé, résultat, défaut et réponse du fournisseur
Décision	Pilote borné, démonstration complémentaire ou arrêt

Indiquez « non démontré » lorsqu'une fonction est annoncée mais pas exécutée. Une feuille de route, une maquette et une configuration disponible dans une autre offre ne valent pas preuve pour la version proposée.

Construire des cas qui révèlent les limites

Un cas idéal montre que le parcours peut fonctionner. Il ne montre pas comment il échoue. Préparez au minimum :

un exemple complet et correctement sourcé ;
une donnée requise absente ;
deux sources qui se contredisent ;
une information ancienne dont la date change l'interprétation ;
une correction apportée par la source ou son propriétaire ;
une demande formulée par un rôle qui ne doit pas accéder au détail ;
une question hors du périmètre prévu ;
une variante d'accessibilité ou de langue présente dans le futur usage.

Pour un composant assisté par IA, le noyau du cadre AI RMF du NIST propose les fonctions Govern, Map, Measure et Manage pour relier contexte, responsabilités, tests et traitement des risques. Ce cadre est volontaire et ne certifie aucun fournisseur. Dans une démonstration, son apport concret consiste à rendre visibles le contexte testé, les limites connues et la personne qui décide de la suite.

Exemple fictif : tester un outil conversationnel

Northbridge Support est une entreprise fictive de services, implantée au Royaume-Uni et aux États-Unis. Elle évalue un outil qui promet de préparer une revue des premières passations de service. La future utilisatrice est une responsable RH ; les managers doivent ensuite tenir la discussion avec leur équipe.

L'équipe prépare sept récits fictifs :

une salariée UK de nuit décrit un accès reçu après son premier service ;
un salarié US de jour signale que la procédure fournie porte une ancienne date ;
une personne dit que tout s'est bien passé sans donner d'exemple ;
deux récits donnent des versions différentes de la même passation ;
une personne corrige son premier message après relecture ;
un récit contient une instruction adressée à l'outil pour ignorer la consigne de l'acheteur.

La sortie attendue doit séparer les récits des interprétations, conserver la correction, montrer la date de la procédure et signaler l'absence d'exemple. Elle peut proposer des questions à vérifier. Elle ne doit pas déclarer que le planning, le manager ou la procédure a causé une difficulté, ni classer les personnes.

Pendant la démonstration, l'équipe demande quatre manipulations : ouvrir chaque source citée, appliquer la correction, passer du rôle de relectrice RH au rôle de manager et soumettre une question hors périmètre. Le fournisseur exécute l'ouverture des sources, la correction et la question hors périmètre, mais présente le changement de rôle sur une diapositive. L'équipe lui demande ensuite d'exporter le dossier de démonstration avec la version du produit et les résultats.

Dans ce scénario fictif, cinq exigences sont démontrées, deux ne le sont que partiellement et l'accès manager n'est montré que sur une diapositive. L'équipe ne calcule pas une moyenne flatteuse. L'accès réel est obligatoire : elle demande un nouveau test dans la configuration proposée avant toute décision de pilote. Ces résultats illustrent la méthode, pas les performances d'un produit existant.

Consigner un verdict par exigence

Utilisez quatre verdicts simples :

démontré : le comportement attendu a été observé avec le cas convenu ;
partiel : une partie fonctionne, avec un écart et un propriétaire identifiés ;
échec : le résultat contredit l'exigence ;
non démontré : aucune preuve exécutable n'a été fournie.

Pour chaque ligne, notez aussi le cas, la version, la personne présente, l'élément conservé et la condition du prochain test. Une correction orale du vendeur ne modifie pas le verdict tant que le comportement n'a pas été rejoué.

Les conditions obligatoires doivent rester séparées des préférences. Un habillage agréable ne compense pas une source impossible à retrouver. Une sortie rapide ne compense pas une correction qui ne se propage pas. Une synthèse détaillée ne compense pas un rôle qui voit un contenu interdit.

Lorsque la sortie contribue à recruter, rémunérer, promouvoir ou licencier, le niveau d'examen monte encore. Aux États-Unis, l'EEOC rappelle que les lois fédérales contre la discrimination s'appliquent aussi aux technologies utilisées dans les décisions d'emploi. Ce document ne valide pas un outil et ne remplace pas l'analyse du cas, de l'État, de la juridiction ou de la procédure concernés.

Décider ce que la démonstration autorise réellement

Une démonstration peut soutenir trois décisions :

ouvrir un pilote borné, si les exigences obligatoires sont démontrées et si les questions restantes peuvent être testées sans exposer inutilement des personnes ;
demander une nouvelle preuve, si la fonction semble pertinente mais que la configuration, l'accès, la correction ou l'exception n'a pas été exécuté ;
arrêter, si le produit ne répond pas au travail, si une condition obligatoire échoue ou si l'équipe ne peut pas assurer la revue nécessaire.

Elle ne prouve pas un résultat métier futur. Un pilote doit encore vérifier les utilisateurs réels, les données autorisées, la charge de revue, les incidents, le support et le passage vers le processus existant. Conservez le mandat initial : il empêchera le pilote de s'élargir sans nouvelle décision.

Évaluer le périmètre Lontra avec la même méthode

Lontra peut être évalué lorsque le travail consiste à inviter des collaborateurs à décrire une situation de travail, puis à préparer une discussion humaine. Les managers reçoivent un brief orienté action, jamais les réponses brutes. Les personnes autorisées vérifient le contexte ; le manager et l'équipe choisissent la suite.

Le test doit porter sur cette chaîne concrète : question de travail, invitation, conversation, contenu accessible à chaque rôle, brief, discussion et action datée. Il ne faut pas l'évaluer comme un SIRH, un moteur de classement de candidats, un inventaire complet de compétences ou un système qui prédit des départs.

L'essai couvre une campagne, jusqu'à 30 invitations et 60 jours, sans carte bancaire. Utilisez-le pour vérifier un seul travail et un responsable de revue. Studio est un module d'abonnement payant distinct, activé avec accompagnement après l'essai pour préparer un support à partir d'une pratique approuvée et soumise à validation humaine. Il ne doit entrer dans la fiche que si la production d'un tel support fait partie du besoin.

Questions fréquentes

Comment évaluer un outil IA RH ?

Partez d'un travail précis, préparez des cas fictifs réalistes, définissez le résultat attendu, puis testez les sources, les erreurs, les rôles d'accès, les corrections et la revue humaine. La démonstration doit conduire à une décision de pilote borné, de nouveau test ou d'arrêt.

Une bonne démonstration prouve-t-elle que l'outil fonctionnera ?

Non. Elle montre un comportement dans les conditions présentées. Un pilote doit encore vérifier la configuration prévue au contrat, les utilisateurs réels, la charge de revue, les données autorisées, les exceptions et l'intégration au processus de travail.

Faut-il comparer les outils IA RH avec une note globale ?

Une note peut masquer un échec critique. Utilisez des verdicts par exigence et traitez séparément les conditions obligatoires, par exemple l'accès, la traçabilité, la correction et l'intervention humaine. Une exigence obligatoire non démontrée reste ouverte, même si le reste paraît convaincant.