Intégration SIRH

Gardez vos systèmes RH. Unifiez l’expérience.

OGRH se place au-dessus du paysage SIRH du client : une source peut être native, externe ou désactivée, sans changer l’expérience côté collaborateur et manager.

Parler d’un pilote Documentation complète

Un point d’entrée, plusieurs outils derrière

Le paysage RH est rarement monolithique. OGRH peut présenter une expérience commune devant un SIRH historique, une paie opérée séparément et un outil de gestion des temps spécialisé.

SIRH & Core HR

TeamsRH, Lucca, Cegid HR ou un Core HR métier

Dossier collaborateur, contrat, organisation et données de référence.

Paie

Silae, Sage, ADP ou un moteur de paie interne

Matricules, variables, bulletins et contrôles de cohérence.

GTA & temps

Chronotime, Kelio, Horoquartz ou une GTA métier

Soldes, absences, présences, planning et validation des temps.

Ces noms illustrent les familles de systèmes visées. Un raccordement est qualifié selon les API, droits et données réellement ouverts par chaque éditeur.

Du fournisseur au modèle canonique OGRH

Les API RH utilisent des noms de champs, statuts, codes et modes de pagination différents. OGRH isole cette complexité dans une couche de mapping : les données externes sont validées puis traduites avant d’entrer dans les services métier.

API fournisseur

Salariés, contrats, soldes et demandes dans le modèle propre à l’éditeur.

ACL / mapping

Validation de schéma, conversion des statuts, crosswalk des codes et pagination bornée.

DTO OGRH

Modèle stable utilisé par le portail, les workflows, Teams et les futurs canaux.

Les capabilities évitent les connecteurs « tout ou rien »

Un système peut savoir lire un salarié sans savoir le modifier, ou lire un solde sans permettre une demande. OGRH formalise ces écarts et refuse une opération non supportée avant l’appel au système externe.

employee.read

Lire un salarié

employment.read

Lire le contrat

team.read

Lire l’équipe

leave.balance.read

Lire les soldes

absence.create

Créer une absence

absence.approve

Valider une absence

Une base pensée pour les intégrateurs

Le socle connecteurs réunit un client HTTP commun, des erreurs normalisées, des tests de conformité, un SIRH de référence et une console des capabilities. L’objectif est de permettre à un partenaire de développer un adaptateur sans modifier le cœur métier OGRH.

Les adaptateurs sont qualifiés connecteur par connecteur. Silae Paie documente aujourd’hui un exemple pilote concret ; la même architecture accueille d’autres SIRH, solutions de paie et GTA selon leurs API.

Assistants connectés par des autorisations limitées

Le serveur MCP d’OGRH expose des outils de consultation protégés par OAuth. La découverte OAuth annonce quatre portées : ogrh:self:read, ogrh:team:read, ogrh:company:read et ogrh:cabinet:read. Pour les outils du cabinet, ogrh:firm:read est aussi accepté comme alias de ogrh:cabinet:read. Chaque outil vérifie ensuite sa portée, les permissions OGRH et, pour le cabinet, l’attribution active de la société. La découverte n’accorde pas ces droits. Cette connexion ne valide ni ne modifie une opération RH.

Consulter la documentation technique et les limites d’accès →

Questions fréquentes

Peut-on connecter plusieurs logiciels RH à OGRH ?

Oui. L’architecture permet de router les fonctions vers différents modules ou systèmes externes selon le domaine.

Un connecteur doit-il couvrir tout le SIRH ?

Non. Un connecteur peut être partiel et déclarer précisément les capabilities qu’il fournit.

Comment gérer des modèles de données différents ?

Une couche anti-corruption valide et traduit le modèle fournisseur vers les DTO canoniques OGRH.

Les écritures API sont-elles rejouées automatiquement ?

Non par défaut. Les retries automatiques sont réservés aux lectures idempotentes afin d’éviter les doublons métier.

Quels accès le serveur MCP propose-t-il ?

La découverte OAuth annonce quatre portées : ogrh:self:read, ogrh:team:read, ogrh:company:read et ogrh:cabinet:read. Pour les outils du cabinet, ogrh:firm:read est aussi accepté comme alias de ogrh:cabinet:read. Chaque outil exige les permissions OGRH et le périmètre métier correspondant. Le serveur reste en lecture seule : il ne valide ni ne modifie une opération.