Mettre en œuvre
Les quatre intégrations qui font gagner du temps, celles qui n'en font pas gagner, et comment évaluer la qualité d'une API avant de signer.
Un ATS isolé résout le suivi des candidatures et crée un nouveau problème : les données du candidat recruté doivent maintenant exister ailleurs. Dans la paie, dans le SIRH, dans l'annuaire, dans les outils d'accueil. Sans raccordement, quelqu'un ressaisit. Ce chapitre explique comment évaluer la qualité réelle d'une intégration avant de signer.
ATS vers SIRH ou paie. Le plus important et le plus mal traité. Quand un candidat est recruté, ses données d'identité et son contrat doivent passer dans le système RH. C'est là que la double saisie coûte le plus cher, parce qu'elle porte sur des données réglementaires où l'erreur a des conséquences.
ATS vers messagerie et agenda. Créneaux d'entretien, invitations, échanges rattachés au dossier. Ce raccordement fonctionne généralement bien, via les connecteurs standard des deux grandes suites bureautiques. Vérifiez la synchronisation bidirectionnelle : un ATS qui écrit dans l'agenda sans lire les disponibilités fait proposer des créneaux déjà occupés.
ATS vers job boards. C'est la multidiffusion, traitée dans le chapitre sur les familles d'outils.
ATS vers outil de signature électronique. Utile si vous envoyez beaucoup de promesses d'embauche. Marginal sinon — ne laissez pas ce critère peser dans une comparaison.
Le connecteur natif. L'éditeur a développé et maintient l'intégration. C'est le meilleur cas : rien à construire, rien à maintenir. Trois questions à poser : quels champs circulent exactement, dans quel sens, et à quelle fréquence.
La plateforme d'automatisation. Un service tiers relie les deux outils sans développement. Rapide à mettre en place, mais elle introduit un troisième abonnement, une dépendance supplémentaire, et un point de défaillance silencieux : quand un scénario casse, personne ne le remarque avant plusieurs jours. Acceptable sur des flux peu critiques, risqué sur la paie.
Le développement spécifique. On écrit le raccordement entre les deux API. Plus cher au départ, mais c'est la seule option quand le connecteur n'existe pas, et la seule qui traite correctement les cas particuliers : quels champs, quelles règles de transformation, que faire en cas d'échec.
Si vous envisagez un développement ou une automatisation, la qualité de l'API de l'ATS détermine tout. Cinq critères, dans l'ordre :
La documentation est-elle publique ? Si vous devez signer un accord pour la lire, c'est un mauvais signe, et cela vous empêche de faire chiffrer le travail par un tiers.
Existe-t-il des webhooks ? Un webhook prévient votre système dès qu'un événement se produit. Sans webhook, il faut interroger l'API en boucle : c'est plus lent, plus coûteux, et cela consomme votre quota.
Quelles sont les limites de débit ? Une API plafonnée à quelques centaines d'appels par heure rend impossible toute synchronisation sérieuse d'une base de plusieurs milliers de dossiers.
L'API est-elle incluse dans votre palier ? Beaucoup d'éditeurs la réservent au haut de gamme, ou la facturent en supplément. Le coût du raccordement inclut alors une montée de palier.
L'API couvre-t-elle l'écriture ? Beaucoup d'API permettent de lire les données mais pas d'en créer. Si vous voulez faire entrer des candidats depuis un autre système, vérifiez-le nommément.
Avant de financer un raccordement, chiffrez le problème. La mesure est simple : le temps de ressaisie par recrutement, multiplié par le nombre de recrutements annuels, plus le coût des erreurs.
Comptez quinze à trente minutes par embauche pour une ressaisie complète dans la paie, vérifications comprises. À trente recrutements par an, c'est entre sept et quinze jours-personne annuels. À cinq recrutements par an, c'est deux jours : ne financez rien, la ressaisie est moins chère que l'intégration.
Le seuil de bascule se situe généralement entre vingt et trente recrutements annuels, plus tôt si les données ressaisies alimentent plusieurs systèmes.
Ajoutez la part invisible : une erreur de saisie sur un IBAN ou une date d'entrée coûte bien plus qu'une ressaisie correcte, et se découvre tard.
Les changements d'API. Un éditeur fait évoluer son API et une intégration développée il y a deux ans cesse de fonctionner. Demandez la politique de versionnement et le préavis de dépréciation avant de développer.
L'absence de supervision. Une synchronisation qui échoue silencieusement est pire qu'une absence de synchronisation, parce qu'on continue de lui faire confiance. Tout raccordement doit émettre une alerte en cas d'échec — c'est la première chose à spécifier, et la plus souvent oubliée.
Les correspondances de champs qui dérivent. Quelqu'un ajoute un état dans le pipeline, la règle de transformation ne le connaît pas. Documentez la table de correspondance, au même titre que pour une migration.
Le changement d'outil de l'autre côté. Si vous changez de paie, l'intégration est à refaire. Ce coût appartient au projet paie, mais il faut l'anticiper.
Il arrive que la valeur attendue d'un nouvel ATS vienne presque entièrement de son raccordement à un système existant — un ERP métier, un outil maison, une paie peu répandue. Dans ce cas, la sélection ne doit pas porter sur les fonctions de recrutement mais sur la capacité d'ouverture de l'outil.
Le critère de choix s'inverse : un ATS moyen avec une excellente API vaut mieux qu'un ATS excellent et fermé. C'est aussi la configuration où la « troisième voie » du chapitre acheter ou développer prend tout son sens — garder l'outil du marché pour le pipeline, développer uniquement la pièce qui relie.
Pas si vous recrutez peu. En dessous d'une vingtaine d'embauches par an, la ressaisie coûte moins cher que le raccordement et son entretien. Ce qui compte dès le départ, c'est de choisir un outil qui rendra l'intégration possible plus tard : une API documentée et accessible dans votre palier.
Pour des flux simples et non critiques — créer une tâche, envoyer une notification, alimenter un tableau de suivi — oui, et c'est une excellente option. Pour un flux qui alimente la paie, la fragilité et l'absence de supervision native posent un vrai problème. La règle : automatisation légère pour ce qui peut échouer sans conséquence, développement supervisé pour ce qui ne le peut pas.
Deux voies restent ouvertes. L'import par fichier : l'ATS produit un fichier au format attendu par la paie, déposé manuellement ou automatiquement. C'est moins élégant mais robuste, et largement suffisant pour un flux d'embauches. Sinon, la ressaisie assistée : un écran qui affiche les données prêtes à copier, ce qui réduit le temps et les erreurs sans rien intégrer.
Cela dépend du nombre de champs, des règles de transformation et de la qualité des deux API. L'ordre de grandeur utile : un connecteur unidirectionnel simple entre deux API correctes représente quelques jours de développement ; dès qu'il faut gérer la bidirectionnalité, les conflits et la reprise sur erreur, on change d'échelle. Demandez un chiffrage en deux lots — un flux minimal d'abord, les cas particuliers ensuite — plutôt qu'un forfait global sur un périmètre mal défini.
Demandez le nom d'un client qui l'utilise en production et la date de sa dernière mise à jour. Une intégration listée sur un site commercial peut être une preuve de concept ancienne ou une simple déclaration d'intention. La date de dernière mise à jour est l'indicateur le plus honnête.
La comparaison honnête entre un abonnement SaaS et un outil sur mesure : seuils de bascule, coûts complets, risques des deux côtés.
Ce qui s'exporte, ce qui ne s'exporte jamais, et la séquence de migration qui évite de perdre l'historique des candidatures.
Une méthode de sélection en six étapes, les critères qui comptent vraiment et ceux qui ne servent qu'à remplir les grilles comparatives.