Un ATS, un CRM et un tableur : lequel dit la vérité ?

Aucun des trois, et c’est exactement le problème. La question utile n’est pas de savoir combien de logiciels vous payez, c’est de savoir combien d’endroits contiennent le même fait. Chaque copie vieillit à sa vitesse, aucune ne prévient quand elle se met à mentir, et celui qui découvre l’écart est presque toujours un client.

Nous défendons la même idée à propos des agents : le bon critère n’est pas leur nombre, c’est le nombre d’endroits où votre contexte est recopié. Le problème est plus ancien que l’IA et il concerne d’abord vos logiciels, avec cette différence que la divergence entre un ATS et un tableur, elle, dure depuis des années sans que personne ne l’ait jamais appelée un incident.

Combien d’outils avez-vous vraiment ?

Plus que vous ne le croyez, et beaucoup moins que vous n’en utilisez, ce qui est la partie intéressante.

Les mesures disponibles situent autour d’une quinzaine le nombre d’applications RH et de recrutement qu’une organisation fait tourner, avec environ neuf applications par entreprise dans les relevés du cabinet Sapient Insights. Une analyse d’entretiens menée par un éditeur auprès de plus de huit cents cabinets donne un chiffre plus élevé encore, une vingtaine d’outils cités, pour quatre à six réellement ouverts chaque jour. Le chiffre vient d’un fournisseur et je le donne avec cette réserve, mais l’écart qu’il décrit est celui que tout le monde reconnaît sur le terrain.

Cet écart est le sujet. Les outils que plus personne n’ouvre ne disparaissent pas, ils continuent de contenir des adresses, des statuts et des notes que quelqu’un finira par consulter et par croire. Un tableur partagé qui servait à suivre trois missions en 2023 est encore ouvert par un nouveau collaborateur en 2026, précisément parce qu’il est plus rapide que l’ATS.

À cela s’ajoute le constat le plus large : 76 % des organisations déclarent souffrir de silos de données et 68 % travaillent sur des plateformes non connectées. Autrement dit, la divergence n’est pas un accident de mise en œuvre, c’est l’état normal d’une organisation qui n’a pas décidé le contraire.

Le vrai coût n’est pas la licence

Il est dans la recopie, et il se paie en temps de gens dont l’heure est chère.

Un éditeur avance quatre-vingt-dix minutes par recruteur et par jour passées à recopier des fiches candidats, des notes clients et des informations de facturation d’un système à l’autre. Le chiffre est intéressé et je ne le prends pas pour argent comptant ; ce qui est vérifiable chez vous, en revanche, c’est le nombre de fois où la même information est saisie deux fois, et il suffit de regarder une journée de travail d’une personne pour l’établir.

Le coût visible s’arrête là. Le coût invisible est ailleurs, et il se manifeste par des incidents qui ne ressemblent jamais à un problème de données. Un candidat présenté deux fois au même client par deux consultants qui ne voyaient pas la même fiche. Une propriété de compte contestée en interne parce que deux systèmes désignent deux propriétaires. Une date de disponibilité fausse qui fait promettre un démarrage impossible. Chacun de ces événements est traité comme une erreur humaine, et chacun était une divergence entre deux copies.

La règle qui tranche : un fait, un propriétaire

Chaque fait a un système propriétaire, toutes les autres copies sont en lecture seule, et la synchronisation va dans un seul sens. C’est court, c’est ennuyeux, et je ne connais rien d’autre qui tienne.

Nous appliquons exactement cette règle à notre propre code, où elle est écrite en toutes lettres et vérifiée à chaque relecture : toute information existe à un seul endroit, tout le reste y fait référence. La raison est la même dans les deux mondes. Un fait qui a deux représentations est un fait qui peut se contredire lui-même, et la contradiction est toujours découverte par un utilisateur plutôt que par un contrôle.

Ce que cela demande concrètement tient en trois décisions, prises une fois et écrites quelque part que les nouveaux arrivants lisent. Quel système détient le statut d’un candidat dans un processus. Quel système détient la relation client et son propriétaire commercial. Quel système détient la disponibilité et la date de fin de mission d’un consultant. Le choix lui-même compte moins qu’on ne le croit ; ce qui casse une organisation, c’est que la moitié des équipes mette à jour l’un et l’autre moitié l’autre.

Quand une copie est vraiment nécessaire, et il y a de bons cas, elle se déclare comme telle. On dit lequel des deux fait foi, on la fait aller dans un seul sens, et on l’écrit à côté du champ. Une copie documentée est une conception ; une copie que personne n’a déclarée est un bug qui attend.

La même règle décide de ce que Balt écrit chez un client : il ne recopie pas un fait d’un système vers un autre, il va le lire là où il fait foi, au moment où on le lui demande. C’est plus lent qu’une synchronisation nocturne et cela évite de créer une copie de plus, ce qui est le seul progrès qui compte ici.

Pourquoi le tableur revient toujours

Parce qu’il gagne sur le seul critère qui compte au moment où quelqu’un l’ouvre : il est plus rapide que le logiciel officiel.

Un consultant qui doit suivre huit candidats sur une mission urgente choisit trente secondes de tableur plutôt que quatre écrans dans un ATS, et il a raison sur l’instant. Interdire l’outil ne change rien à ce calcul, cela le déplace simplement hors de la vue : c’est le même mécanisme que l’usage clandestin d’outils non autorisés, qui prouve surtout qu’aucun outil adapté n’a été fourni.

La réponse qui fonctionne est moins ambitieuse qu’une interdiction et plus efficace. On admet le tableur pour ce qu’il est, un brouillon de travail, on lui donne une durée de vie explicite, et on décide ce qui doit remonter dans le système propriétaire à la fin. Un brouillon assumé qui se vide ne fait de mal à personne ; un brouillon devenu permanent est une source de vérité que personne n’a déclarée.

Ce que change un agent branché là-dessus

Il ne réconcilie rien, et c’est ce qu’il faut avoir en tête avant de le brancher.

Face à deux versions d’un même fait, un agent en choisit une et rend une réponse cohérente, argumentée et fausse. C’est la formulation que nous défendons depuis longtemps : plus l’agent est bon, plus une mauvaise donnée coûte cher, parce qu’un humain se méfie d’une fiche datée alors qu’un agent raisonne dessus. Un tableur oublié devient soudain une source citée.

Le corollaire est plus encourageant qu’il n’y paraît. Vous n’avez pas à nettoyer toute votre base avant de commencer : vous avez à décider, pour les trois ou quatre faits que l’agent va toucher, lequel de vos systèmes fait foi. C’est un travail de décision plutôt qu’un chantier de données, il se fait en une réunion, et il produit un bénéfice immédiat même si vous ne branchez jamais aucun agent.

C’est aussi ce qui rend la question de l’accès secondaire mais réelle : encore faut-il que le système désigné comme propriétaire accepte de répondre, ce qui renvoie à ce qu’un agent exige d’un ATS.

Faut-il tout regrouper dans un seul outil ?

C’est la réponse la plus efficace au problème des copies, et elle a un prix qu’il faut dire.

Un système unique supprime la question par construction : il n’y a plus qu’un endroit où le statut d’un candidat est écrit. En échange, un outil qui couvre l’ATS, le CRM et la facturation est rarement le meilleur sur chacune des trois fonctions, et le changement de système est un projet lourd qui coûte des mois de productivité avant d’en rendre.

L’arbitrage honnête n’est donc pas « tout regrouper ou rien », il est de décider combien de copies vous acceptez de tenir et qui en répond. Deux systèmes avec une synchronisation à sens unique et un propriétaire nommé fonctionnent très bien. Cinq systèmes sans propriétaire ne fonctionnent jamais, quel que soit le budget d’intégration.

Si la question se pose chez vous parce que la pile est devenue ingérable, elle relève d’un travail de comparaison que ce blog ne fait pas. Nous éditons Cobalt, qui rassemble l’ATS et le CRM du métier, et son blog compare les logiciels de recrutement pour cabinets et ESN avec le sérieux que le sujet demande. Ce que Balt fait est différent et complémentaire, et la frontière entre les deux est décrite dans Cobalt et Balt.