Réponse courte
L’implémentation de l’IA RH commence après le choix d’un cas d’usage. Elle transforme une idée en flux de travail vérifiable : une décision précise, une population, des données autorisées, des rôles, une revue humaine et des conditions d’arrêt. Un pilote utile teste le service complet dans son contexte réel. Il ne cherche pas à prouver que « l’IA fonctionne » en général.
Cette page traite le passage du cas retenu au pilote, puis à une décision d’arrêt, de correction ou d’extension. Si le travail n’est pas encore choisi, commencez par la grille des cas d’usage IA RH. Si un fournisseur doit encore démontrer son outil, utilisez d’abord la fiche d’évaluation des outils IA RH pour structurer cette étape.
Commencer par une charte d’une page
Une bonne charte permet aux RH, aux opérations, à la sécurité, aux équipes juridiques ou protection des données et aux représentants concernés de contester le même projet. Elle doit rester courte et concrète.
| Champ | Réponse attendue |
|---|---|
| Décision de travail | Ce qu’une personne nommée préparera ou décidera différemment |
| Processus actuel | Les étapes, délais, erreurs et protections qui existent déjà |
| Population | Les personnes éligibles, exclues et affectées par le résultat |
| Tâche du système | Recueillir, retrouver, classer, résumer ou préparer un brouillon |
| Autorité humaine | La personne qui vérifie la sortie et décide de la suite |
| Données permises | Les champs et sources minimaux nécessaires à ce but |
| Usages interdits | Ce qui ne peut être déduit, noté ou décidé à partir du résultat |
| Preuves attendues | Les mesures de livraison, qualité, utilisation et travail |
| Conditions d’arrêt | Les erreurs, dommages, accès ou charges qui suspendent le pilote |
« Utiliser l’IA pour améliorer la rétention » n’est pas une charte. « Aider une équipe RH à préparer une revue des difficultés d’intégration décrites par des collaborateurs de deux sites, sans évaluer une personne ni décider de son emploi » peut être testé.
Le noyau de l’AI Risk Management Framework du NIST relie contexte d’usage, responsabilités, limites de connaissance, contrôle humain, tests et suivi. Ce cadre américain est volontaire et non sectoriel : il ne certifie pas le projet. Il fournit ici une structure pour rendre le travail et les décisions visibles.
Cartographier le vrai service, pas seulement le modèle
Dessinez le parcours depuis l’entrée jusqu’à l’action. Une sortie correcte peut encore produire un mauvais service si l’invitation arrive au mauvais moment, si la personne chargée de la revue ne voit pas la source ou si personne ne traite l’exception.
Utilisez quatre lignes :
- Participant : ce que la personne reçoit, comprend, choisit, corrige ou refuse ;
- Système : ce qui entre, est transformé, conservé, affiché ou transmis ;
- Reviewer : les éléments qu’il examine, les corrections qu’il peut faire et les cas qu’il doit escalader ;
- Responsable de la décision : l’action qu’il peut approuver, différer, refuser ou renvoyer pour preuve complémentaire.
Ajoutez les autres voies. Une conversation automatisée ne doit pas devenir l’unique moyen de signaler une urgence, un problème de sécurité, une demande d’aménagement ou une situation exigeant une procédure compétente. La charte doit indiquer le bon canal et la personne qui reprend le sujet.
Pour un service britannique, l’ICO demande de considérer la protection des données dès la conception et pendant tout le cycle de vie, et de limiter par défaut l’usage des informations personnelles à ce qui est nécessaire pour chaque finalité. L’organisation doit qualifier les règles applicables à son traitement. La carte du flux facilite cette revue ; elle ne constitue pas à elle seule une conclusion de conformité.
Organiser le pilote en quatre portes de décision
Porte 1 : préparation
Validez la charte, les rôles, les informations données aux participants, la source de chaque entrée et le traitement de chaque sortie. Définissez une valeur de référence du processus actuel. Par exemple : nombre d’invitations délivrées, dossiers correctement préparés, corrections nécessaires et actions effectivement attribuées.
Une moyenne isolée masque les absences. Gardez les dénominateurs, les périodes et les populations. « Quatorze personnes ont terminé » ne dit pas si quatorze ou cent quarante personnes étaient éligibles.
Porte 2 : essais fictifs
Avant toute donnée réelle, testez au minimum :
- une réponse normale et une réponse ambiguë ;
- un refus, une interruption et une correction ;
- deux faits qui ne doivent pas être fusionnés ;
- une source absente ou périmée ;
- une demande hors du rôle de l’utilisateur ;
- un sujet qui doit rejoindre une autre procédure ;
- une indisponibilité du système et une reprise sans doublon.
Consignez le cas, la sortie attendue, la sortie observée, la gravité, le responsable et la décision. Une correction de consigne ne clôt pas l’incident tant que les cas voisins n’ont pas été rejoués.
Porte 3 : pilote ciblé
Choisissez une population dont le contexte est connu et dont le responsable peut agir. Testez l’ensemble du service, y compris le texte d’invitation, l’accès sur les appareils utilisés, la revue, l’escalade et le retour aux participants. Le Service Standard du gouvernement britannique vise les services publics ; sa consigne de tester fréquemment avec de vrais utilisateurs et de couvrir les parties en ligne et hors ligne constitue une discipline utile, pas une obligation générale pour toute entreprise.
Pendant le pilote, tenez trois journaux distincts :
| Journal | Éléments à noter |
|---|---|
| Livraison | Éligibles, invités, délivrés, commencés, terminés et abandons |
| Qualité | Sorties relues, erreurs par type, corrections, sources manquantes |
| Travail | Décisions préparées, actions attribuées, dépendances et dates de revue |
Porte 4 : revue
Comparez les observations à la charte. Demandez si le service a atteint la bonne population, si les sorties restent fidèles au contexte disponible, si les accès correspondent aux rôles, si la charge humaine est tenable et si la décision prévue a réellement eu lieu.
La conclusion doit être l’une de ces quatre options : arrêter, corriger, répéter ou étendre. Une extension peut porter sur un seul élément, par exemple un autre site, sans valider une autre langue, une intégration ou un nouveau cas d’usage.
Exemple fictif : intégration de nouveaux responsables de magasin
Une enseigne fictive possède un site à Birmingham au Royaume-Uni et un autre à Columbus aux États-Unis. Elle a déjà choisi son cas d’usage : permettre à de nouveaux responsables de décrire une difficulté récente de passage de consignes, afin que l’équipe opérations décide si la fiche de relève doit être revue.
La population pilote compte 24 personnes éligibles, invitées une seule fois chacune. Les envois sont délivrés à 21 personnes uniques ; 16 personnes uniques commencent et 14 terminent. Les taux décrivent des étapes différentes : livraison 21 / 24 = 87,5 %, démarrage parmi les invitations délivrées 16 / 21 = 76,2 %, et complétion parmi les personnes ayant commencé 14 / 16 = 87,5 %. Aucun de ces taux ne mesure la qualité de l’écoute, la maîtrise du poste ou un effet sur la rétention.
Les personnes chargées de la revue examinent les 14 sorties. Deux réunissent à tort un manque d’information sur le stock et une difficulté de planning. Le taux d’erreur observé pour ce cas précis est 2 / 14 = 14,3 %. L’équipe suspend la restitution, modifie la consigne et rejoue le jeu fictif, y compris des cas proches, avant de reprendre. Ce petit échantillon ne permet pas d’estimer la fréquence future de l’erreur ; il montre que la règle d’arrêt fonctionne.
Les autres sorties permettent au responsable opérations de proposer un changement de la fiche de relève. La prochaine cohorte vérifiera si le nouveau champ est compris et utilisé. Le pilote n’a pas démontré que l’IA améliore l’onboarding. Il a montré qu’un flux borné pouvait révéler une erreur, la corriger et produire une action humaine à réexaminer.
Une grille de décision avant toute extension
Pour chaque ligne, inscrivez « démontré », « partiellement démontré », « non démontré » ou « non applicable », avec un lien vers la preuve.
| Condition | Preuve à demander |
|---|---|
| Finalité | Charte actuelle et usages interdits |
| Compréhension | Test de l’invitation auprès de la population visée |
| Fidélité | Relecture source-sortie sur cas ordinaires et difficiles |
| Contrôle humain | Relecteur, charge, pouvoir de corriger et escalade |
| Accès | Rôles testés, journalisation et responsable des identifiants |
| Suivi | Actions, propriétaires, dépendances et échéances |
| Couverture | Limites connues par site, rôle, langue, horaire ou appareil |
| Arrêt | Personne autorisée à suspendre et méthode de retour arrière |
Un projet n’est pas prêt parce que toutes les cases sont vertes dans une présentation. Il l’est lorsque les personnes responsables peuvent retrouver les preuves, expliquer les limites et agir si le service dévie de son usage prévu.
Où Lontra intervient dans ce parcours
L’approche produit de Lontra accompagne des conversations ciblées avec des collaborateurs invités. Le manager reçoit un brief pour préparer une action humaine, jamais les réponses brutes. Lorsque l’organisation l’autorise, Living Memory peut conserver un contexte daté entre les campagnes ; ce contexte reste soumis aux rôles, permissions et à l’interprétation humaine.
L’essai couvre une campagne, jusqu’à 30 invitations et 60 jours, sans carte bancaire. Avant de le lancer, définissez la question de travail, la population, la personne chargée de la revue, la sortie attendue et la date de décision. Les intégrations, imports, exports, identités et autres exigences techniques doivent être vérifiés pour le compte et le déploiement envisagés ; ce guide ne suppose aucun connecteur.
Studio est un abonnement payant distinct, activé avec accompagnement après l’essai de la plateforme. Il peut être évalué séparément lorsqu’un projet demande de préparer des contenus dans des formats convenus à partir de sources approuvées, avec validation humaine. Il n’est pas requis pour tester la boucle conversation, brief et action.
Questions fréquentes
Comment commencer l’implémentation d’une IA RH ?
Commencez par une décision de travail, une population éligible et une personne responsable. Définissez les données, les usages interdits, la revue humaine, les mesures et les critères d’arrêt avant de configurer le pilote.
Combien de temps doit durer un pilote IA RH ?
Il n’existe pas de durée universelle. Choisissez une période qui couvre assez de situations réelles pour examiner l’accès, les erreurs, la charge de revue et le suivi. La durée seule ne rend pas un pilote représentatif.
Que faut-il mesurer pendant un pilote IA RH ?
Mesurez séparément la livraison du flux, la fidélité des sorties aux sources, la charge de revue humaine, le traitement des erreurs et la décision de travail obtenue. La participation ne prouve pas un effet humain ou commercial.
Quand une IA RH est-elle prête à être déployée plus largement ?
Élargissez seulement lorsque l’usage prévu, les rôles d’accès, l’information des participants, la revue humaine, la gestion des erreurs et le responsable opérationnel ont fonctionné dans des conditions proches du terrain.
