MCP et recrutement : ce que le protocole ne règle pas

Il règle un problème de branchement, et c’est déjà beaucoup : au lieu d’écrire une intégration par outil et par modèle, on en écrit une par outil. Ce que MCP ne règle pas, en revanche, est le problème principal d’un cabinet de recrutement ou d’une ESN, qui est que la moitié des systèmes où se trouve l’information ne lui appartiennent pas.

Cet article suppose que vous savez déjà ce qu’est le protocole. Si ce n’est pas le cas, le guide complet publié par Cobalt fait ce travail mieux que je ne le referais ici, avec la définition, le fonctionnement et les cas d’usage côté ATS. Ce qui suit part de l’étape d’après : vous avez compris, votre éditeur annonce un serveur MCP, et vous vous demandez ce que cela change concrètement lundi matin.

Ce que le protocole règle vraiment

Il faut commencer par là, sinon la suite ressemble à un dénigrement, et ce serait faux.

Avant MCP, brancher un outil sur un modèle demandait d’écrire du code spécifique à la fois à l’outil et au modèle. Changer de modèle obligeait à recommencer, et nous avons montré ailleurs que le modèle sur lequel tourne un agent est retiré tous les douze à dix-huit mois. Une intégration qu’il fallait réécrire à chaque génération était une intégration qu’on n’écrivait pas.

Le second gain est moins commenté et compte davantage pour un cabinet : le protocole a rendu respectable, pour un éditeur d’ATS, l’idée que ses données doivent être atteignables par des tiers. Pendant vingt ans, la stratégie dominante du secteur consistait à rendre la sortie difficile. Un éditeur qui publie un serveur MCP a pris une décision commerciale, pas seulement technique, et c’est cette décision-là qui vous intéresse.

Le troisième est le plus concret. Un serveur MCP oblige à décrire ce que chaque outil fait, en français lisible, dans un fichier que quelqu’un doit écrire. C’est la première fois que beaucoup d’éditeurs documentent réellement ce que leur logiciel permet de faire de l’extérieur, et cette documentation vaut souvent plus que le protocole qui l’a provoquée.

Le problème d’un cabinet n’est pas son ATS, c’est celui de son client

C’est le décalage le plus coûteux entre la manière dont le sujet est présenté et la manière dont ce métier fonctionne.

Presque toute la littérature sur MCP part du principe que vous branchez vos propres outils : votre ATS, votre CRM, votre messagerie. Pour une entreprise qui recrute pour elle-même, c’est exact. Pour un cabinet qui travaille en délégation ou une ESN placée chez plusieurs grands comptes, une part importante du travail se passe ailleurs : le portail fournisseur du client, son outil de suivi des candidatures, le tableau partagé où il indique ses retours, parfois simplement sa boîte aux lettres.

Aucun protocole ne décide à la place d’un client de vous ouvrir un accès. La partie longue n’a jamais été technique : elle est contractuelle, elle passe par une direction des systèmes d’information qui ne vous connaît pas, et elle se compte en semaines quand elle aboutit. MCP rend le branchement trivial une fois l’accord obtenu, ce qui déplace le goulot d’étranglement sans le supprimer, et il vaut mieux le savoir avant de bâtir un plan dessus.

La conséquence pratique est qu’un cabinet a intérêt à séparer les deux mondes dans sa réflexion. Ce qu’il possède se branche vite et se travaille en profondeur. Ce qui appartient au client se négocie, se limite en général à la lecture, et se traite souvent par des moyens plus rustiques qu’un protocole : un export périodique, une adresse dédiée, un fichier déposé. Ce n’est pas élégant et cela fonctionne depuis vingt ans.

Brancher ne donne aucun droit que vous n’aviez pas

Cela paraît évident écrit ainsi, et c’est pourtant l’attente implicite la plus répandue.

Un agent qui parle MCP à votre ATS voit exactement ce que voit le compte utilisé pour la connexion. S’il s’agit d’un compte technique créé à la va-vite avec des droits d’administrateur, il hérite de droits d’administrateur, et l’agent devient un chemin qui contourne toutes vos habilitations. Le protocole n’est pour rien dans ce résultat : il transporte, il n’arbitre pas.

C’est la raison pour laquelle nous insistons ailleurs sur le fait qu’un agent doit agir avec les droits de la personne qui lui parle, et que la capacité de votre ATS à répondre à la question « qu’a le droit de voir cette personne-là » compte davantage que la présence d’un serveur MCP. C’est l’une des cinq propriétés qui déterminent ce qu’un agent peut faire dans votre ATS, et celle qui disqualifie le plus de logiciels.

Le protocole ne dit rien de ce qu’il transporte

Il transporte fidèlement des données contradictoires, et c’est peut-être le point le plus utile de cet article.

Un cabinet qui branche son ATS, son CRM et un tableur partagé sur un même agent obtient un agent qui lit les trois. Il n’obtient pas un agent qui sait lequel a raison. Face à deux statuts différents pour le même candidat, il en choisit un et rédige une réponse cohérente, argumentée et fausse, plus vite qu’un humain ne l’aurait fait. Le branchement a accéléré la production d’une erreur qui existait déjà.

La question à régler avant de brancher tient donc en une phrase, et elle n’a rien à voir avec le protocole : pour les trois ou quatre faits que l’agent va manipuler, quel système fait foi. C’est une décision d’une réunion, elle profite à l’entreprise même sans agent, et elle conditionne la valeur de tout ce qui vient après.

Un serveur MCP reste un fournisseur

Il détient des identifiants sur vos systèmes et il fournit au modèle du texte que celui-ci lit comme une instruction, ce qui en fait un sous-traitant plutôt qu’une extension.

Nous avons développé ce point ailleurs, avec les mesures de sécurité de 2026 et les trois questions à poser avant de brancher : un serveur MCP est un fournisseur, pas un connecteur. Je ne le refais pas ici, je le rappelle parce que la facilité de branchement produit exactement le comportement contre lequel il faut se prémunir. On en ajoute cinq en un trimestre, personne ne tient la liste, et cette liste est précisément ce qu’un incident vous demande de produire dans l’heure.

Pour un cabinet, un point mérite d’être ajouté : quand vous branchez un serveur MCP sur les données d’un client, vous engagez la relation avec ce client, pas seulement la vôtre. La question « que se passe-t-il si ce fournisseur est compromis » cesse d’être interne dès qu’un tiers vous a confié un accès.

Alors, faut-il en faire un critère d’achat ?

Un signal, oui ; un critère unique, non, et nous avons écrit ailleurs pourquoi exiger le protocole ne suffit pas à choisir un agent.

La formulation qui sert vraiment en salle de démonstration est plus terre à terre. Ne demandez pas « parlez-vous MCP », qui appelle un oui. Demandez quels objets sont exposés en écriture, si vos champs personnalisés en font partie, comment les droits d’une personne précise sont respectés, et s’il existe un moyen de relire tout ce qui a changé depuis une date. Un éditeur qui répond précisément à ces quatre questions a fait le travail, qu’il expose un serveur MCP ou une API classique.

De notre côté, Balt consomme des serveurs MCP plutôt que d’exposer leurs outils au modèle, pour une raison d’économie que nous assumons : chaque outil visible se paie à chaque tour de conversation, dans chaque conversation, chez chaque client. Le modèle n’en voit donc qu’un seul, et il écrit du code pour appeler tout le reste. Ce n’est pas le sujet de cet article, mais c’est la raison pour laquelle nous regardons d’abord ce qu’un serveur permet de faire, jamais le nombre d’outils qu’il annonce.

Reste ce qui arrive quand tout est branché et que rien ne se passe, qui est le cas le plus fréquent : le protocole était le problème le plus simple, et ce qui empêche un projet d’aboutir se trouve presque toujours ailleurs.