Ce que Deel sait de vos salariés, et ce que le connecteur en retient
Deel est l’outil où une entreprise gère la paie et l’administration des personnes qu’elle emploie. La fiche d’une personne y porte donc son intitulé de poste et son service, et aussi sa rémunération, sa date de naissance, son adresse e-mail personnelle, ses numéros de téléphone et sa pièce d’identité.
Le connecteur en retient quatre champs et s’arrête là. Le nom complet, l’intitulé de poste, le service tel qu’il est inscrit sur la fiche, et le nom du responsable direct. Ces quatre champs suffisent à ce qu’une IA sache qui fait quoi et qui rend compte à qui, ce qui est exactement la question à laquelle un organigramme répond.
Une IA branchée sur votre Kastel peut donc dire qui s’occupe des achats, à qui remonte une validation, quel service porte tel sujet. Elle ne peut rien dire d’un salaire, parce que le champ n’a jamais été lu. Les autres sources que votre Kastel sait lire sont réunies dans le catalogue des connecteurs.
L’API de Deel renvoie la fiche entière, et le connecteur en jette la plus grande partie
L’interface de Deel ne sait pas renvoyer une partie d’une fiche. Quand le connecteur demande l’annuaire, il reçoit les fiches complètes, rémunération comprise. Certains outils RH acceptent qu’on leur demande seulement quelques champs, et Lucca en fait partie ; la liste des personnes de Deel ne le propose pas.
La décision se prend donc à l’écriture. Le connecteur relève sur la fiche reçue les quatre champs qu’il a nommés, écrit ce texte, et laisse tomber le reste. La fiche complète renvoyée par Deel n’est écrite nulle part, ni dans votre Kastel, ni dans une copie de travail.
Cette mécanique tient encore quand Deel évolue. Si l’éditeur ajoute demain un champ sensible à la fiche d’un salarié, ce champ arrivera dans la réponse et repartira sans avoir été écrit, parce que le connecteur ne lit jamais autre chose que ses quatre champs. Une fiche d’une forme inattendue produit une note plus courte, jamais une note plus large.
Un annuaire de personnel ne se diffuse pas au reste de l’entreprise
Deel ne pose aucun droit de lecture au niveau d’une personne. La clé d’organisation voit l’annuaire entier, et c’est la même clé pour toutes les fiches. Il n’y a donc aucune permission d’origine à reprendre, contrairement à un canal de discussion ou à un fichier partagé.
Le connecteur range alors tout l’annuaire dans un seul service, et seulement si trois conditions sont réunies. Un administrateur doit avoir désigné le service qui gère les ressources humaines, ce nom doit être un identifiant valide, et ce service doit exister réellement dans votre organisation. Si l’une des trois manque, l’annuaire reste en attente et personne ne le lit.
Un choix mérite d’être nommé, parce que l’inverse aurait été plus simple à écrire. Le connecteur ne range jamais la fiche d’une personne dans le service où cette personne travaille. Ce serait le réflexe naturel, et le résultat serait un annuaire de personnel éparpillé dans tous les services, chacun lisant les fiches de ses propres membres. Sur des données de personnel, le connecteur préfère l’attente à ce résultat.
Cette façon de décider qui lit quoi ne concerne pas seulement Deel. C’est la manière dont votre Kastel gouverne tout son contenu, source par source.
Les champs qui entrent, et ceux qui restent dehors
Un annuaire se juge sur les champs, alors voici les deux listes exactes que le connecteur applique à chaque fiche.
Ces exclusions ne sont pas des réglages qu’une console pourrait rouvrir. Elles tiennent au fait que le connecteur ne lit que les quatre champs de la première liste, et un champ qui n’est pas lu ne peut pas être écrit.
Les questions que pose une direction des ressources humaines
Une IA peut-elle atteindre un salaire par ce connecteur ?
Non. Le connecteur nomme les quatre champs qu’il écrit, et la rémunération n’en fait pas partie. Le champ n’est jamais lu, donc il n’y a pas de filtre à contourner. Il en va de même pour la date de naissance, l’adresse e-mail personnelle, les numéros de téléphone, la pièce d’identité et les informations complémentaires de la fiche.
Qui peut interroger l’annuaire une fois qu’il est en place ?
Les personnes du service qu’un administrateur a désigné, et personne d’autre. Une IA qui travaille pour quelqu’un d’un autre service n’atteint pas ces fiches. Tant qu’aucun service n’est désigné, l’annuaire attend, et aucune IA ne le lit quel que soit le compte utilisé.
Que devient la fiche d’une personne qui quitte l’entreprise ?
Deel garde les personnes sorties dans son annuaire, avec un indicateur de statut. Pour le connecteur, un départ est donc une modification de la fiche plutôt qu’une disparition, et la fiche est relue telle qu’elle est devenue. Quand une personne est réellement retirée de l’annuaire de Deel, sa fiche est signalée dans votre Kastel comme disparue à la source et conservée, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur décide de l’effacer.
Est-ce que Kastel lit la liste des services de votre compte Deel ?
Non. Le service d’une personne est lu sur sa propre fiche, tel que Deel l’écrit. Le connecteur n’interroge pas la liste des services de votre compte et ne cherche pas à reconstituer votre organigramme officiel ailleurs que dans les fiches elles-mêmes.
Ce que ce connecteur ne fait pas
Il ne remplace pas votre outil RH. Il ne gère aucun congé, ne prépare aucune paie, ne suit aucun contrat et n’écrit rien dans Deel. L’autorisation demandée est une autorisation de lecture, il n’existe aucun chemin d’écriture vers votre compte, et le connecteur ne dialogue qu’avec le domaine de l’API de Deel.
L’organigramme qu’il donne à une IA vaut exactement ce que vaut votre annuaire Deel. Si le service d’une personne n’est pas renseigné, ou si son responsable a changé sans que la fiche suive, votre Kastel reprend l’erreur telle quelle. Le connecteur ne corrige rien et n’invente aucun rattachement.
Il n’y a sur cette source aucun tri du contenu ligne à ligne, comme il en existe sur une messagerie. La protection tient entièrement aux quatre champs lus et au service unique dans lequel l’annuaire se range. Un nom de personne reste une donnée personnelle, et le connecteur en écrit un par fiche, ce qui est la raison même pour laquelle rien n’est lisible avant qu’un service ait été désigné.
Chaque passage relit l’annuaire en entier, parce que Deel ne sait pas dire quelles fiches ont changé depuis la dernière fois. Une embauche apparaît donc au passage suivant plutôt qu’à la minute où la fiche est créée. Et quand une page de résultats annonce une suite sans donner le moyen de l’atteindre, le passage échoue bruyamment, plutôt que de conclure à tort que les fiches non lues ont disparu.
Avant de brancher votre annuaire de personnel, parlons-en.
Un annuaire RH se discute mieux à deux qu’à travers une page web. Dites-nous quelles questions vous voulez qu’une IA sache traiter sur votre organisation, et nous vous dirons ce que ce connecteur lit, ce qu’il laisse dehors, et là où il s’arrête.
Nous écrire
