Brancher un agent de développement sur ses outils métier via MCP transforme la prospection en travail scriptable : on décrit une intention en une phrase, l'agent enchaîne les appels, sourcing, enrichissement, mise en file, et rend un résultat vérifiable. Ce que ça change n'est pas la qualité des messages, mais la vitesse d'itération sur la méthode.

Nous procédons ainsi sur une partie de notre propre prospection. Voici ce que ça donne, et ce qui casse.

Le montage, en une phrase

Un agent de développement, celui qui lit votre code et lance vos commandes, se connecte à un serveur MCP qui expose vos outils métier. Il ne code plus : il appelle vos outils, comme un opérateur.

Chez nous, ce serveur expose 643 outils en production au 18 août 2026, dont 21 pour la prospection et 21 pour les contacts. L'agent voit uniquement le périmètre nécessaire à la tâche, pas le catalogue entier, c'est ce qui rend un grand catalogue exploitable.

Ce que ça change vraiment

L'itération sur la méthode devient rapide. « Reprends les profils de la liste A qui ont publié cette semaine, écarte ceux déjà contactés, et prépare des brouillons » se formule en une phrase et s'exécute en quelques minutes. Tester une variante de ciblage ne demande plus de développement.

Les données croisées deviennent accessibles. Croiser une liste de prospects avec l'historique du CRM, les réponses passées et une liste d'exclusion est un travail de jointure, pénible à la main, immédiat pour un agent qui a les deux outils.

Le travail est journalisé. Chaque appel d'outil est tracé côté serveur. On sait ce qui a été fait, avec quels arguments, et dans quel ordre.

Ce que ça ne change pas : la qualité des messages. L'agent prépare, il ne remplace pas la ligne qui prouve la lecture, et c'est cette ligne qui déclenche les réponses.

Les quatre pièges, tous rencontrés

1. L'agent enchaîne trop vite. Un enchaînement qui semble logique, « je liste, j'enrichis, je mets en file », peut consommer un budget d'enrichissement en une exécution. Le garde-fou : un plafond de coût par exécution, et une confirmation avant toute action facturée à l'unité.

2. Le catalogue est trop large. Exposer 643 outils à un agent dégrade nettement ses choix. Le garde-fou : ne rendre visible que le domaine concerné par la tâche.

3. Le rejeu silencieux. Une erreur transitoire, une reprise, et le message part deux fois. Le garde-fou : une clé d'idempotence sur toute action externe. Sans elle, ce montage est dangereux, pas fragile, dangereux.

4. La perte silencieuse d'un argument. Un schéma permissif supprime les clés inconnues et renvoie un succès. L'agent croit avoir transmis une valeur qui a disparu. Le garde-fou : refuser bruyamment les clés inconnues, y compris à l'intérieur des tableaux d'objets. Nous avons appris celle-ci en production, en perdant un identifiant de cluster passé par mot-clé dans un appel groupé.

Les garde-fous non négociables

L'approbation humaine avant tout envoi. Les brouillons sont générés, la mise en file est automatique, l'envoi est validé par une personne. Un agent de développement branché sur des outils d'envoi sans cette barrière est une très mauvaise idée.

Des plafonds que l'agent ne peut pas relever. 20 invitations, 30 messages et 80 actions d'engagement par jour et par compte, avec montée en charge sur sept jours. L'augmentation exige un humain administrateur et ne prend effet que le lendemain.

Un cloisonnement par organisation explicite. L'identifiant d'espace de travail est toujours passé explicitement, jamais deviné. C'est la règle qui évite qu'une tâche déborde sur les données d'un autre client.

Un journal de la décision. Savoir qu'une action a eu lieu ne suffit pas ; il faut savoir pourquoi l'agent l'a choisie. Sans cela, un incident est inanalysable.

Pour qui c'est adapté, et pour qui ça ne l'est pas

C'est adapté si vous avez déjà une méthode de prospection éprouvée à la main, des outils exposés proprement, et quelqu'un capable de lire un journal d'exécution.

Ce n'est pas adapté si vous cherchez à automatiser une méthode que vous n'avez jamais pratiquée. Un agent accélère ce que vous savez faire ; il n'invente pas une méthode que vous n'avez pas. Commencez par la routine hebdomadaire pendant un mois.

Ce n'est pas non plus un raccourci vers le volume. Nos plafonds n'ont pas bougé parce que nous pilotons par agent. Ce qui a changé, c'est la vitesse à laquelle nous testons des variantes de ciblage, pas le nombre de messages envoyés.

Ce que nous n'avons pas mesuré

Nous n'avons pas de comparaison chiffrée rigoureuse entre ce montage et notre méthode précédente : les deux périodes n'ont ni la même liste ni la même offre, et une comparaison serait malhonnête.

Ce que nous constatons qualitativement : le temps entre « j'ai une idée de segment » et « j'ai des brouillons prêts à relire » est passé de quelques heures à quelques minutes. C'est un ressenti d'équipe, présenté comme tel, pas une mesure.

Questions fréquentes

Faut-il savoir programmer ? Pour brancher le serveur MCP et exposer les outils, oui. Pour l'utiliser ensuite, non : on décrit une intention en langage naturel.

Est-ce que ça respecte les conditions d'utilisation de LinkedIn ? Le montage lui-même est neutre, ce sont les actions qui comptent. Les conditions de LinkedIn interdisent les logiciels tiers automatisant l'usage de la plateforme, et le risque est porté par votre compte. C'est une raison de plus de rester à des volumes bas.

Quel protocole utiliser ? Le MCP s'est imposé comme standard de fait pour connecter des outils à un agent. Nous détaillons nos leçons de production dans MCP : le protocole qui donne des mains aux agents.

Combien de temps pour monter ça ? Quelques heures si vos outils sont déjà exposés proprement. Des semaines s'il faut d'abord les exposer, et c'est ce travail-là qui a la valeur durable, pas le branchement.

---

Nos outils, nos plafonds et nos journaux sont dans CodAgents. Pour en discuter, écrivez-nous.