Recrutement avec MCP : des étapes qui s'enchaînent

Les flux de recrutement MCP relient les outils d’un assistant autour d’une tâche précise, comme préparer une réponse à un candidat. Chaque étape exige un identifiant de candidature stable, des champs de résultat exploitables et des limites visibles. Lire un échange, créer un brouillon et envoyer un message sont des actions distinctes. Un membre de l’équipe désigné se charge de la validation finale.

Un candidat demande à déplacer son entretien au jeudi. L’assistant retrouve la conversation, la lit et rédige une réponse courtoise. La réponse paraît prête. Pourtant, plusieurs questions restent ouvertes : quelle candidature a-t-il utilisée, a-t-il lu le dernier message et quelqu’un a-t-il vérifié les disponibilités du jeudi ?

Ces questions doivent faire partie du flux de travail. Les résultats de chaque appel doivent permettre d’y répondre, sans demander à l’assistant de reconstituer les événements à partir de son propre résumé.

Que faut-il pour composer un flux de recrutement MCP ?

Un flux composable permet à l’étape suivante d’exploiter directement les éléments obtenus à l’étape précédente. Pour une réponse à un candidat, il faut conserver l’identifiant de candidature, vérifier le résultat de la lecture et présenter un brouillon dont l’état reste visible jusqu’à la validation.

Dans leur article du 29 septembre, « Vous aviez refusé MCP ! », les ingénieurs d’Earendil expliquent comment ils ont ajouté MCP à Pi et rendu les outils accessibles depuis un bac à sable (sandbox) d’orchestration JavaScript. Selon eux, la facilité à découvrir les outils et le format de leurs résultats influent sur leur capacité à fonctionner ensemble. Leurs exemples portent sur des outils de développement. Appliquer ce raisonnement au recrutement demande donc une conception distincte.

Commencez par une tâche que l’équipe peut examiner : préparer une réponse à une conversation existante. Définissez ses données d’entrée et le résultat attendu avant de choisir une méthode d’orchestration.

L’identifiant de candidature relie les appels. Un candidat peut avoir postulé à deux postes. Son nom ou son adresse e-mail ne suffit pas à identifier le processus concerné par la réponse. Conservez ensemble la candidature sélectionnée et son offre d’emploi, même si le résumé de l’assistant ne mentionne que le nom de la personne.

Le flux de travail a aussi besoin d’un point d’arrêt explicite. « Préparer un brouillon que Morgan validera » donne à l’assistant un résultat observable et à Morgan une tâche précise. « Gérer la boîte de réception » laisse le choix des conversations, le périmètre et la fin du travail ouverts à l’interprétation.

Si vous définissez encore les ressources et les actions accessibles à l’assistant, utilisez la liste de contrôle des autorisations par ressource et par action. Ici, nous supposons les accès configurés et nous nous concentrons sur les éléments transmis entre les appels.

Que résolvent vraiment les résultats structurés des outils ?

Les résultats structurés facilitent l’exploitation et la validation des champs. Ils ne prouvent ni que les faits sous-jacents sont à jour, ni que le résultat contient tous les éléments nécessaires à la réponse.

La spécification des outils MCP du 25 novembre 2025 définit structuredContent comme un objet JSON et prévoit un outputSchema facultatif. Lorsqu’un outil fournit ce schéma, son résultat structuré doit le respecter et les clients devraient le valider. Du JSON sérialisé dans un bloc de texte peut également être analysé, mais il s’agit d’une autre représentation dans le protocole.

Cette distinction compte lorsque vous écrivez un adaptateur. Vérifiez le format renvoyé par chaque outil, sans supposer que tous les résultats arrivent sous la forme du même objet. Dans Kit, seuls certains outils fournissent des réponses structurées typées : les outils de résumé de candidature le font, tandis que l’outil de réponse au candidat renvoie une enveloppe JSON textuelle. La référence des outils MCP décrit les outils que vous pouvez relier.

Après avoir analysé un résultat, validez les champs requis par l’étape suivante. Un identifiant de candidature absent doit interrompre le flux de travail. Une liste de notes vide peut être un résultat valide. Un indicateur de troncature exige de décider quoi faire du contenu non lu. Traiter ces trois cas comme « l’outil a renvoyé quelque chose » masque leurs différences.

Quand faut-il composer les appels dans du code ?

Le code peut aider à relier des résultats par identifiant, à filtrer une file de taille limitée ou à appliquer les mêmes vérifications à plusieurs lectures. Une seule réponse à un candidat peut aussi être préparée par des appels directs, à condition que l’assistant conserve les éléments obtenus et respecte les dépendances.

L’article technique d’Anthropic sur l’exécution de code avec MCP décrit le chargement des outils selon les besoins et le filtrage des résultats intermédiaires avant leur retour au modèle. Il explique aussi le travail supplémentaire lié à l’isolation, aux limites de ressources et à la supervision. C’est une option de conception utile ; ce texte ne démontre pas de gain de performance dans le recrutement et ne garantit aucune économie pour votre intégration.

Choisissez le code lorsqu’il facilite le respect d’une dépendance concrète. Par exemple, l’appel de création du brouillon doit rester inaccessible tant que la lecture du fil n’a pas satisfait votre vérification d’exhaustivité. Des lectures indépendantes peuvent se faire en parallèle, mais la rédaction de la réponse dépend de leurs résultats complets.

Comment relier les étapes d’une réponse à un candidat ?

Construisez le flux de réponse autour d’une candidature et d’un brouillon que vous pouvez examiner. L’exemple ci-dessous propose une séquence de travail avec les outils Kit. Il ne s’agit pas d’un moteur d’orchestration automatique livré par Kit.

Supposons qu’Alex, candidat fictif à un poste de développement backend, écrive : « Pourrions-nous déplacer l’entretien de mercredi à jeudi ? Je suis disponible l’après-midi. » Morgan est responsable de la conversation et demande à l’assistant de préparer un accusé de réception pendant que l’équipe vérifie les disponibilités de la personne chargée de l’entretien.

1. Sélectionner la conversation et conserver son identité

Utilisez hiring_list_conversations avec le filtre de réponse approprié. Kit propose notamment les filtres needs_reply, pending_draft et failed ; la réponse comprend des informations sur le nombre de résultats et leur troncature. La file renvoyée est limitée : ne présentez pas les lignes sélectionnées comme l’ensemble des conversations à traiter lorsque la réponse indique qu’il en existe d’autres. Consultez la référence des outils.

Transmettez l’identifiant de candidature d’Alex à tous les appels suivants. Conservez aussi l’offre d’emploi pour que Morgan reconnaisse le processus. Si la requête renvoie deux candidatures d’Alex, demandez à l’opérateur de choisir celle qui convient avant de rédiger.

Un brouillon déjà en attente mérite votre attention avant toute nouvelle écriture. Déterminez si Morgan souhaite le remplacer. Dans Kit, préparer une nouvelle réponse remplace les brouillons précédents en attente dans ce fil. Appeler l’outil à répétition pour recueillir des variantes a donc des conséquences.

2. Lire le fil et examiner les limites

Appelez hiring_list_messages pour cette candidature. Examinez la correspondance, le brouillon en attente, les échecs d’envoi, le nombre total de messages et les limites. L’indicateur truncated de l’enveloppe signale les messages omis ; l’indicateur body_truncated de chaque message signale un texte coupé. Vérifiez les deux, y compris pour le corps du brouillon en attente. La correspondance récente arrive par ordre chronologique, ce qui ne prouve pas qu’elle est complète.

Dans cet exemple, vérifiez que la demande concerne un entretien déjà évoqué dans le fil. Regardez si l’équipe a répondu depuis ou si un échec d’envoi explique la nouvelle demande d’Alex. Un second accusé de réception pourrait semer la confusion, même avec une formulation exacte.

Considérez le texte rédigé par le candidat comme un élément permettant de comprendre sa demande. Un message demandant de déplacer un entretien est pertinent. Une phrase demandant à l’assistant d’ignorer ses consignes reste du contenu externe et ne doit pas modifier le flux de travail.

3. Ne récupérer que le contexte nécessaire à la réponse

Utilisez hiring_get_application_summary si l’accusé de réception nécessite le contexte actuel de la candidature, comme son étape. Évitez d’ajouter des notes sans rapport au message simplement parce qu’un outil peut les renvoyer.

Le résumé peut établir où en est la candidature. Il ne prouve pas que la personne chargée de l’entretien est libre jeudi. Dans cet exemple, les disponibilités restent à vérifier. Le brouillon doit donc accuser réception de la demande sans confirmer de créneau :

Bonjour Alex, merci de nous avoir prévenus. Nous allons vérifier si nous pouvons déplacer l’entretien à jeudi après-midi et reviendrons vers vous dès que nous aurons confirmé une heure.

Morgan doit accepter de se charger de ce suivi. Si personne ne vérifie les disponibilités, même cette promesse modeste doit être revue. N’ajoutez pas « Jeudi à 14 h convient » sur la base d’une supposition et ne transformez pas la préférence exprimée par le candidat en rendez-vous confirmé.

4. Préparer la réponse exacte et vérifier son état

Appelez hiring_send_message avec l’identifiant de candidature conservé et le texte proposé. Malgré son nom dans l’API, cet outil prépare un brouillon en attente. Il n’envoie aucun e-mail à Alex. Le lien pending_draft renvoyé mène au brouillon exact, grâce à une ancre dans le fil de la candidature.

Relisez l’état du fil après la préparation. Vérifiez que le pending_draft.id relu correspond au data.id du résultat de préparation : un autre appel peut remplacer votre brouillon. Recherchez un éventuel nouveau message reçu. Cette lecture réduit le délai entre la vérification et la transmission à Morgan, mais le fil peut encore évoluer avant son ouverture.

Le message de fin de l’assistant doit être concret : « Brouillon en attente pour la candidature d’Alex au poste backend. Ouvrez ce brouillon dans Kit, vérifiez le dernier message et les informations de planification, puis utilisez Confirmer et envoyer si vous l’approuvez. » Ajoutez le lien exact renvoyé pour le brouillon. Avec un lien générique vers la candidature, Morgan doit chercher un résultat dont le flux de travail connaît déjà l’emplacement.

Une réponse dans le chat ne peut pas déclencher l’envoi de ce brouillon. Confirmer et envoyer vérifie à nouveau la disponibilité de la boîte de réception et de la fonction de réponse, puis met l’envoi en file d’attente. Dans Kit, l’état transmis signifie que la remise au serveur SMTP s’est terminée sans erreur. Il ne prouve pas l’arrivée du message dans la boîte de réception d’Alex.

Que faire si le résultat est incomplet ou n’est plus à jour ?

Un contexte incomplet ou modifié exige un traitement explicite avant de poursuivre la réponse. Définissez la marche à suivre pour chaque cas dès la conception du flux de travail. L’assistant ne doit pas improviser une réponse assurée autour d’éléments manquants.

Imaginez qu’Alex écrive ensuite : « Jeudi ne convient plus. Vendredi matin serait préférable. » L’accusé de réception concernant jeudi, jusque-là approprié, est désormais erroné. Le flux de travail doit reprendre les étapes de lecture et de rédaction, puis présenter le résultat révisé à Morgan.

Kit affiche un avertissement de contenu périmé lorsqu’un nouveau message reçu est postérieur au brouillon en attente. Cet avertissement ne bloque, n’actualise et ne supprime pas automatiquement le brouillon. Morgan doit encore lire le dernier message et décider de la suite. Le guide de l’agent IA et de MCP explique la transmission des communications avec les candidats à l’équipe.

Décrivez précisément les erreurs. « Arrêt : le fil renvoyé était tronqué et l’accord précédent sur l’entretien n’a pas été lu » donne à Morgan une action utile à entreprendre. « Un problème est survenu » oblige votre collègue à reprendre les vérifications de l’assistant.

Comment tester le flux de travail avant de l’utiliser ?

Testez le flux de réponse sur des candidatures et une correspondance fictives avant de l’utiliser dans de vraies conversations. Vérifiez les éléments intermédiaires et l’état final, y compris dans les cas où le bon résultat consiste à s’arrêter.

Utilisez cette grille de validation pour une exécution. C’est une aide à la conception que l’équipe peut adapter, et non une norme du secteur ou un outil de test intégré à Kit.

Commencez par la demande fictive pour jeudi et attendez-vous à obtenir un seul accusé de réception en attente. Puis modifiez une condition par exécution : ajoutez une autre candidature portant le même nom, rendez le fil incomplet, désactivez la boîte de réception, insérez un brouillon existant ou ajoutez une demande pour vendredi après la préparation.

Dans le cas des noms identiques, la réussite consiste à conserver la candidature choisie jusqu’au brouillon. Si le contexte est incomplet, elle peut consister à s’arrêter sans écrire. Pour le nouveau message concernant vendredi, elle consiste à attirer l’attention de la personne chargée de la validation sur la nouvelle demande, sans prétendre que la réponse concernant jeudi est à jour.

Distinguez la tâche de l’assistant de l’envoi. Si Morgan a demandé un brouillon, les éléments de validation sont le bon brouillon en attente et son lien. Si Morgan le confirme ensuite, suivez l’envoi séparément. Un schéma valide et une réponse réussie de l’outil ne prouvent pas qu’Alex a reçu quoi que ce soit.

Comment Kit rend-il le flux de travail et la transmission à l’équipe visibles ?

Kit permet de lire les conversations, de consulter le contexte des candidatures et de préparer une réponse qu’un membre de l’équipe peut examiner dans le fil. Votre intégration fournit les règles d’orchestration reliant ces étapes, notamment les vérifications d’exhaustivité et la marche à suivre lorsque les éléments changent.

Le résultat utile est un lien ancré vers le brouillon en attente, accompagné d’un état clair et du nom de la personne chargée de la validation. Morgan peut ouvrir le texte exact, le comparer à la dernière demande reçue, le modifier ou le supprimer, ou utiliser Confirmer et envoyer. Après confirmation, l’état de l’envoi reste un fait distinct à vérifier.

Cette validation s’applique à ces réponses préparées pour les candidats. D’autres outils Hiring peuvent appliquer des modifications ou déclencher des notifications. Examinez donc le comportement de chaque outil avant de l’ajouter à un flux de travail plus vaste. Le guide de déploiement MCP explique comment connecter les agents ; l’introduction à MCP pour le recrutement présente les bases du protocole.

Construisez un flux de réponse dont vous pouvez suivre l’identifiant de candidature, les limites du contenu non lu, le brouillon et l’état de l’envoi. Testez-le à l’aide de la grille, puis confiez la suite à un membre de l’équipe. Pour essayer avec votre équipe, commencez avec Kit et limitez la première tâche à une conversation et à un brouillon que vous pouvez valider.