Réponse courte
Une intégration SIRH et IA est un échange contrôlé au service d’un travail défini. Commencez par les champs strictement nécessaires, leurs propriétaires, les permissions et les événements qui les modifient. Testez les erreurs avec des dossiers fictifs, rapprochez chaque transfert, puis choisissez l’architecture seulement après démonstration des connexions réellement disponibles.
Ce guide traite du contrat minimal d’échange de données. Il complète le guide d’implémentation IA RH, qui couvre la charte, le pilote et la décision d’extension. Un pilote peut être utile sans intégration automatisée ; une intégration techniquement réussie peut rester inutile si la décision de travail n’est pas claire.
Écrire une phrase de contrat avant de choisir un connecteur
« Brancher l’IA au SIRH » peut désigner le chargement d’une population éligible, l’authentification d’utilisateurs, l’ajout d’attributs de groupe, le retour d’un statut de livraison ou l’écriture d’un résultat revu. Ces travaux n’ont ni les mêmes champs ni les mêmes risques.
Écrivez une phrase qui nomme la source, la destination, le but et la frontière d’écriture :
Pour le pilote fictif de conversation d’onboarding, l’équipe opérations RH fournit une liste approuvée de participants actifs et leurs attributs de groupe nécessaires. Le système destinataire renvoie un statut de livraison au relecteur RH autorisé. Aucun texte de conversation, thème ou score individuel n’est écrit dans le SIRH.
Cette phrase ne choisit pas l’architecture. Elle permet de rejeter les champs, droits et sorties qui ne servent pas le travail.
Comparer les modes d’échange sans présumer la solution
| Mode | Quand l’examiner | Contrôle à exiger | Limite à consigner |
|---|---|---|---|
| Fichier manuel approuvé | Population fixe et pilote ciblé | Exportateur nommé, transfert protégé, validation et date de suppression | Les changements n’arrivent pas automatiquement |
| Fichier planifié | Mises à jour groupées à intervalle défini | Calendrier, manifeste, doublons et rapprochement | Une modification reste ancienne jusqu’au prochain passage |
| API en lecture seule | Besoin de lire des champs approuvés plus actuels | Identité de service, périmètre étroit, limites, logs et réponse aux erreurs | La disponibilité de la source affecte le flux |
| Événement ou webhook | Besoin justifié de traiter rapidement une arrivée, mobilité ou sortie | Validation, ordre, répétition, surveillance et reprise | Doublons et événements désordonnés doivent être testés |
| Écriture contrôlée | Résultat revu attendu dans un champ SIRH précis | Propriétaire du champ, schéma, approbation, idempotence, audit et retour arrière | Une mauvaise écriture altère le système de référence |
Demandez au fournisseur de qualifier chaque option : disponible pour tous, dépendante du compte, personnalisée, simulée ou indisponible. Un logo SIRH dans une présentation et une documentation d’API ne démontrent pas que le compte, les droits et le flux sont prêts.
Construire la fiche champ par champ
L’ICO indique que la protection des données par défaut limite l’utilisation des informations personnelles à ce qui est nécessaire pour chaque finalité. Ses recommandations actuelles demandent de considérer le volume collecté, l’étendue du traitement, la durée de conservation et l’accessibilité. Cette règle vise le cadre UK GDPR ; chaque organisation doit déterminer les exigences applicables à son traitement.
Pour chaque champ proposé, complétez cette fiche :
| Champ de contrôle | Exemple fictif |
|---|---|
| Finalité | Inviter les nouvelles recrues éligibles à une conversation d’onboarding |
| Système source et propriétaire | Registre SIRH, propriétaire opérations RH |
| Champ source | Identifiant de travail |
| Usage dans la destination | Rapprocher une invitation, sans créer de score salarié |
| Valeurs et format | Format documenté, sans signification affichée |
| Transformation | Clé de campagne créée pour l’échange |
| Date d’effet | Valeur appliquée seulement à partir de la date SIRH validée |
| Accès | Service d’échange et relecteur opérations RH autorisé |
| Conservation | Durée et événement de suppression approuvés pour ce flux |
| Valeur absente ou invalide | Rejet vers une file contrôlée, sans valeur devinée |
| Correction | Propriétaire nommé et nouvelle tentative traçable |
Répétez la fiche pour l’adresse ou le canal de livraison, le groupe organisationnel, la langue et les dates seulement si chacun est nécessaire. La présence d’un champ de paie, santé, absence, performance ou démographie dans le SIRH ne justifie pas son transfert.
Séparer identité, accès et analyse
Une identité utile pour livrer une invitation ne crée pas automatiquement un droit d’analyse individuelle. Définissez les autorisations par rôle et par action.
| Rôle ou service | Lire depuis le SIRH | Écrire dans la destination | Lire la sortie | Écrire dans le SIRH |
|---|---|---|---|---|
| Service d’échange | Champs de liste approuvés | Liste validée | Statut technique | Aucun, sauf approbation séparée |
| Opérations RH | Source et file d’exception | Corrections selon un processus dont le responsable est désigné | Livraison et rapprochement | Champs opérationnels approuvés seulement |
| Relecteur RH | Contexte de groupe pertinent | Décision de revue | Sortie autorisée et contexte permis | Aucune écriture automatique |
| Manager | Aucun identifiant d’intégration | Aucune | Brief d’action lorsqu’il est autorisé | Aucune par ce flux |
| Support fournisseur | Aucun accès permanent présumé | Aucun par défaut | Accès temporaire seulement s’il est approuvé | Aucun |
Le National Cyber Security Centre britannique distingue l’authentification, qui vérifie l’identité, de l’autorisation, qui limite les actions. Ses recommandations sur les API préconisent le moindre privilège, le refus par défaut et la validation des permissions à chaque requête. Utilisez ces principes comme exigences à faire démontrer par les équipes compétentes.
Définir arrivées, mobilités, sorties et corrections
Une carte des champs décrit un état. Un tableau de cycle de vie décrit le changement.
| Événement | Comportement attendu | Échec à tester |
|---|---|---|
| Une personne devient éligible | Créer une seule entrée après la condition convenue | Même événement reçu deux fois |
| Une personne change d’équipe | Appliquer le nouveau groupe à sa date d’effet | Ancien et nouveau groupes actifs ensemble |
| Le manager change | Mettre à jour le routage sans exposer de contenu antérieur non autorisé | Événement tardif ou désordonné |
| Une personne quitte l’organisation | Arrêter les invitations futures et appliquer la règle de conservation | Statut encore actif après un traitement incomplet |
| La source est corrigée | Remplacer le champ opérationnel erroné et rapprocher les états | Ancienne valeur conservée silencieusement |
| Le choix de participation change | Appliquer la réponse documentée du flux | Chargement suivant qui écrase ce choix |
Si deux règles se contredisent, ne devinez pas l’état final. Placez le dossier en exception, rendez le conflit visible et demandez une décision au propriétaire.
Rapprocher chaque échange
Pour chaque passage, enregistrez :
- le fichier source ou la fenêtre d’événements ;
- les dossiers proposés, acceptés, rejetés et inchangés ;
- les créations, modifications, désactivations et mises en exception ;
- les doublons, événements tardifs et erreurs de validation ;
- l’heure de début et de fin ;
- l’identité ou le point d’accès utilisé ;
- la personne qui traite les écarts non résolus.
Le NIST SP 800-228 mis à jour en mars 2026 couvre les risques et contrôles avant et pendant l’exécution des API. Un acheteur n’a pas à prescrire toute l’architecture du fournisseur, mais il doit obtenir assez d’éléments pour distinguer un passage complet, un échec partiel et une requête non autorisée.
« Le traitement est terminé » n’est pas un résultat de rapprochement si des dossiers ont disparu sans motif visible.
Exemple fictif : une mobilité appliquée trop tôt
Une entreprise de services fictive possède des équipes à Leeds et Boston. Elle teste un fichier planifié avec 80 dossiers fictifs : identifiant, éligibilité, adresse de travail, code équipe, langue et date d’effet.
La validation accepte 78 dossiers et en rejette deux : l’un sans date d’éligibilité, l’autre avec un code équipe inconnu. Le taux d’acceptation technique est 78 / 80 = 97,5 %. Au rapprochement, 77 des 78 états acceptés correspondent à la règle attendue. Le dernier dossier concerne une mobilité de Leeds A vers Leeds B prévue lundi, mais le fichier du vendredi contient déjà le nouveau groupe. Le système l’a appliqué trop tôt.
Un taux d’acceptation de 97,5 % aurait masqué cette erreur de sens. L’équipe modifie le contrat : la destination peut enregistrer le changement futur, mais ne l’applique qu’à l’heure d’effet validée. Elle rejoue ensuite les 80 dossiers, un doublon du mouvement et une ancienne mise à jour reçue après lundi. L’état final attendu reste Leeds B ; le doublon et l’événement ancien doivent apparaître dans le rapprochement.
Cet essai ne démontre pas que toute l’intégration est fiable ou sûre. Il vérifie une règle de cycle de vie et la capacité du propriétaire à repérer un écart avant un petit pilote réel.
Un jeu de tests réutilisable
Préparez des dossiers fictifs pour les chemins suivants :
- personne éligible avec valeurs valides ;
- canal de livraison absent ;
- identifiant dupliqué ;
- code site ou équipe inconnu ;
- changement dont la date d’effet est future ;
- sortie reçue après le chargement de la liste ;
- même événement reçu deux fois ;
- ancienne mise à jour reçue après la nouvelle ;
- demande d’un champ ou d’un rôle non autorisé ;
- destination indisponible pendant un passage.
Pour chaque cas, notez l’état final, le message visible, le log attendu et la personne qui intervient. Rejouez le lot complet après toute modification du mapping, du format, des permissions ou de la méthode d’échange.
Où Lontra intervient
L’approche produit de Lontra accompagne des conversations ciblées avec des collaborateurs invités. Les managers reçoivent des briefs orientés action, jamais les réponses brutes, puis des personnes autorisées vérifient le contexte et décident de la suite. Lontra n’est pas présenté ici comme un SIRH, un moteur de score individuel ou une source qui décide d’un emploi.
Ce guide ne confirme aucun connecteur, API, import, export, SSO, synchronisation d’identité ou write-back Lontra. Demandez une démonstration des options exactes disponibles pour le compte et l’architecture envisagés. Le contrat reste utile qu’un pilote utilise une saisie approuvée, un fichier contrôlé ou une connexion vérifiée.
L’essai de la plateforme couvre une campagne, jusqu’à 30 invitations et 60 jours, sans carte bancaire. Il permet de cadrer une boucle conversation, brief et action ; il ne démontre pas à lui seul une intégration SIRH. Pour relier ensuite une mesure de groupe à une décision, utilisez la fiche people analytics.
Questions fréquentes
Que doit contenir un contrat d’échange entre un SIRH et un outil IA ?
Il doit définir la finalité, les champs minimaux, les systèmes source et destination, les propriétaires, les formats, les permissions, la fréquence, les règles de validation, le rapprochement, les événements de cycle de vie et la réponse aux incidents.
Un outil IA RH doit-il écrire dans le SIRH ?
Non. Un fichier approuvé ou un échange en lecture seule peut suffire selon le pilote. Toute écriture exige un champ de destination, un propriétaire, une validation, une journalisation et une méthode de retour arrière explicites.
Comment tester une intégration SIRH sans données réelles ?
Utilisez des dossiers fictifs couvrant valeurs manquantes, doublons, codes invalides, changement d’équipe, départ, mise à jour tardive et demande non autorisée. Rapprochez chaque dossier accepté, rejeté ou modifié.
Ce guide confirme-t-il l’existence de connecteurs Lontra ?
Non. Il ne confirme aucun connecteur, API, import, export, SSO ou write-back. L’acheteur doit faire démontrer les options exactes disponibles pour son compte, son architecture et son déploiement.
