Un SIRH en sait bien plus que le poste de chacun
Factorial suit les congés, les absences, les notes de frais, la rémunération et les entretiens. Un responsable RH qui hésite à brancher une IA dessus attend une réponse précise sur ce qui en sortira, champ par champ. Cette page donne cette liste.
Le connecteur Factorial de Kastel ne s’intéresse qu’à l’organisation. Il lit deux listes, les salariés et les équipes. De chaque salarié il retient quatre informations, le nom, le poste, l’équipe et le manager. Chaque équipe devient de son côté une fiche qui porte son nom, ce qui donne à votre IA la structure de l’entreprise sans rien lui dire de la vie de vos salariés.
Quatre champs de l’organigramme, rien du dossier
Le périmètre se décrit ici en champs, parce qu’un SIRH mélange dans la même fiche l’organisation de l’entreprise et la vie privée d’une personne.
Ces exclusions passent par le chemin le plus simple à vérifier. Le connecteur ne demande pas ces informations à Factorial. Deux adresses sont appelées, aucune des deux ne contient un congé, un montant ou une donnée de santé.
Deux listes appelées, et aucune autre adresse
L’interface de Factorial renvoie des fiches entières, sans permettre de demander seulement quelques champs. Le connecteur applique donc deux barrières au lieu d’une, et la première tient sur le réseau.
Le lecteur Factorial du moteur ne connaît que deux adresses, la liste des salariés et la liste des équipes. Les parties de Factorial qui contiennent la rémunération, les coordonnées bancaires, les coordonnées personnelles et la date de naissance ne sont jamais appelées. Aucune de ces adresses n’existe dans le code, donc un congé ou un montant de paie n’a aucun chemin pour arriver jusqu’à votre Kastel.
La seconde barrière est au moment de l’écriture. Le connecteur nomme les champs qu’il écrit et n’écrit que ceux-là. La fiche renvoyée par Factorial n’est jamais conservée, et un champ arrivant sous une forme inattendue est omis plutôt que recopié tel quel. Une fiche imprévue produit un enregistrement plus court.
Le connecteur n’écrit rien dans Factorial. Le code n’a qu’un verbe de lecture, aucune méthode d’écriture n’y figure, et l’adresse de base est figée sur une version datée de l’interface pour qu’un changement chez l’éditeur ne passe jamais sans revue. La même prudence habille le connecteur PayFit, avec une mécanique différente, parce que la paie et le SIRH n’exposent pas les mêmes objets.
Un organigramme qui préfère un trou à une supposition
Factorial n’écrit pas le nom du manager dans la fiche d’un salarié. Il y écrit l’identifiant d’un autre salarié. Le connecteur reconstitue donc la ligne hiérarchique lui-même, en énumérant tout l’annuaire à chaque passage pour associer chaque identifiant au nom qui lui correspond.
Quand un identifiant de manager ne correspond à personne dans l’annuaire énuméré, la ligne du manager est omise. Aucun identifiant brut n’est écrit à sa place. La même règle vaut pour le service, que Factorial exprime par un rattachement à une équipe. Si ce rattachement ne se résout pas dans la liste des équipes lue au même passage, la ligne du service est absente, et l’équipe reste lue de son côté comme fiche à part entière.
La conséquence est à connaître avant de brancher. L’organigramme que votre IA lit peut être moins complet que celui que Factorial vous affiche. Il ne contient rien qui n’ait été résolu, ce qui vaut mieux qu’un rattachement deviné dont personne ne saurait qu’il est faux.
Les questions que les responsables RH nous posent sur ce connecteur
Est-ce qu’une IA pourra voir les congés et les absences de mes salariés ?
Non. Les congés, les absences et les arrêts vivent dans des parties de Factorial que le connecteur n’appelle jamais, et il n’appelle que la liste des salariés et la liste des équipes. Il n’y a donc pas de réglage à surveiller sur ce point, l’adresse n’existe pas dans le code.
Que devient la fiche d’un salarié qui a quitté l’entreprise ?
Factorial garde un salarié parti dans sa liste, avec une date de fin. Le connecteur ne lit pas cette date, donc la fiche reste dans votre Kastel avec son nom, son poste et son manager, et rien n’y signale le départ. Si la fiche disparaît vraiment de Factorial, elle est alors marquée comme disparue à la source et conservée jusqu’à l’effacement décidé par un administrateur. Une sortie d’entreprise se répercute par un geste d’administrateur, jamais toute seule.
Pourquoi le service de certains salariés n’apparaît-il pas ?
Parce que leur rattachement d’équipe ne s’est pas résolu dans la liste des équipes lue au même passage. Le connecteur laisse alors la ligne vide au lieu de deviner un service. Corriger le rattachement dans Factorial suffit, et la fiche se met à jour au passage suivant.
Qui peut lire cet annuaire dans mon entreprise ?
Le service que votre administrateur a désigné, et personne d’autre. Factorial ne pose aucun droit de lecture au niveau d’un salarié, la clé voit tout l’annuaire, donc le connecteur refuse de le distribuer service par service et ne range jamais une fiche dans le service du salarié concerné. Sans désignation explicite, l’annuaire n’est rangé dans aucun service et attend une décision. Ce que Kastel protège, et comment.
Une IA peut-elle modifier une fiche dans Factorial ?
Non, aucun chemin d’écriture n’existe. Le lecteur Factorial du moteur n’expose qu’une opération de lecture, et la clé demandée ne sert qu’à cela. La question est fermée au niveau du code plutôt qu’au niveau d’un réglage.
Ce que ce connecteur ne fait pas
Il ne gère rien. Il ne pose aucun congé, ne valide aucune absence, ne prépare aucune paie, et n’écrit jamais dans Factorial. Il donne à une IA la structure de votre entreprise, et s’arrête là.
L’organigramme peut être incomplet. Un manager dont l’identifiant ne se retrouve pas dans l’annuaire lu est omis, un rattachement d’équipe qui ne se résout pas laisse la ligne du service vide, et les noms de champs de l’interface Factorial ne sont pas tous confirmés par un accès réel de notre côté. Le connecteur est écrit pour rendre une fiche plus courte plutôt qu’une fiche inventée, donc ce que votre IA lit peut être moins complet que ce que vous voyez dans Factorial.
Le départ d’un salarié n’est pas visible. Factorial le garde dans sa liste avec une date de fin, et cette date n’est pas lue. Sa fiche continue donc d’exister dans votre Kastel, avec son nom, son poste et son manager, comme celle d’une personne en poste. C’est un administrateur qui décide de l’effacer, et cela vaut aussi pour une fiche qui aurait vraiment disparu de Factorial, laquelle est marquée comme disparue à la source et conservée en attendant.
Un nom associé à un poste, à une équipe et à un manager reste une donnée personnelle, sans qu’aucun chiffre de paie soit en jeu. Et l’annuaire se lit d’un bloc. Factorial ne posant aucun droit au niveau d’un salarié, il n’existe aucun moyen d’ouvrir une partie de cet annuaire à un service et le reste à un autre.
Dites-nous ce que votre direction RH accepte de rendre lisible.
Un annuaire de salariés est le genre de sujet où une conversation vaut mieux qu’une page web. Nous vous dirons quels champs entrent, lesquels ne sont jamais demandés, et ce qu’un administrateur doit décider avant le premier passage.
Nous écrire
