Pourquoi l'échec des SDR IA commence en amont du bouton d'envoi
Au cours de l'année écoulée, les éditeurs de SDR IA autonomes ont été publiquement critiqués pour un ARR gonflé et du churn client. Je ne vais pas instruire le procès d'un éditeur en particulier, notamment parce que je n'ai pas accès à leurs comptes. En revanche, je peux parler du schéma qui se répète, car nous observons la même chose côté acheteur.
Les agents envoient. Ils envoient beaucoup, vite, et dans une prose correcte. L'envoi n'a jamais été la partie difficile. L'échec des SDR IA se produit dans la couche opérationnelle : les définitions du pipeline, les boucles de rétroaction du CRM et la logique de disqualification qui indiquent à un agent ce qu'est un bon résultat. Sans elles, l'agent optimise la seule chose qu'il voit, à savoir l'activité.
L'idée de cet article est donc de nommer ces trois composantes, de donner un exemple de défaillance pour chacune et d'indiquer ce que je ferais. Un niveau stratégique, pas un tutoriel. La mise en œuvre est l'étape où il vaut mieux avoir quelqu'un d'intégré à vos côtés.
Qu'est-ce que la couche opérationnelle d'un SDR IA ?
La couche opérationnelle est l'ensemble des règles et des données, construites par des humains, qui déterminent ce qu'est un lead, ce qu'est un rendez-vous et ce qu'est une impasse. Je l'appellerai le socle. Un agent SDR repose dessus.
Elle comprend trois parties :
- Les définitions du pipeline : ce qui compte comme un rendez-vous qualifié, une opportunité, un changement d'étape.
- La boucle de rétroaction du CRM : la manière dont les résultats remontent pour que l'agent apprenne ce qui a fonctionné.
- La logique de disqualification : les règles qui déterminent qui n'est jamais contacté, ou qui est retiré dès le premier signal.
Un SDR humain peut se contenter d'un socle mince, car un humain comble les manques lors des points d'équipe, des revues de deals, dans les couloirs. Un agent n'a pas de couloir.
Définitions du pipeline : l'agent atteint le chiffre que vous lui avez donné
Imaginons qu'une équipe SaaS B2B demande à son agent de prendre des rendez-vous. Personne n'a écrit ce qu'est un rendez-vous. Un appel de 15 minutes avec un stagiaire compte-t-il ? Un rendez-vous manqué puis reprogrammé compte-t-il deux fois ?
L'agent obtient 120 rendez-vous en un mois. Le tableau de bord est superbe. Les AE les prennent, et un tiers se déroule avec des personnes sans pouvoir budgétaire et sans problème actif. L'éditeur annonce un succès, car la métrique du contrat était le nombre de rendez-vous. L'acheteur résilie deux trimestres plus tard parce que le pipeline n'a pas bougé.
J'ai le sentiment que c'est ainsi que commencent beaucoup d'échecs de SDR IA, et que naissent certaines des affaires publiques de chiffres gonflés. Personne n'a besoin de mentir. Le chiffre a été défini au mauvais niveau.
La solution est sans éclat. Écrivez la définition, stockez-la dans le CRM sous la forme d'un champ à valeurs contrôlées, et mesurez l'agent sur l'étape en aval, pas sur la prise de rendez-vous. Dans HubSpot, il s'agit d'une propriété avec des options définies, et non d'une note en texte libre.
La boucle de rétroaction du CRM : sans résultats, pas d'apprentissage
Un agent ne peut progresser que si les résultats lui reviennent. La plupart des CRM, pour le meilleur et pour le pire, regorgent d'étapes périmées et de champs à moitié remplis. Les acheteurs avec qui nous échangeons décrivent des SDR qui commettent des erreurs manuelles en mettant à jour les relations compte-contact dans Salesforce. Si les humains se trompent, un agent qui lit les mêmes enregistrements apprend à partir du bruit.
Voici un exemple. Un agent écrit à un contact qui a quitté l'entreprise il y a six mois, parce que la relation n'a jamais été mise à jour. L'e-mail rebondit ou reçoit une réponse vague. Rien n'est réécrit dans la fiche. La semaine suivante, l'agent réessaie. Cette boucle est l'échec des SDR IA en miniature : une activité assurée, zéro apprentissage.
Le déficit se retrouve aussi du côté des AE. Un client nous a confié que ses account executives se concentrent sur le calendrier de signature et le budget, sans creuser assez les facteurs de douleur. Les raisons de gain et de perte restent maigres, si bien que rien n'indique au système quelles douleurs annonçaient une vente. On ne peut pas entraîner un ciblage sur des données que personne n'a saisies.
Ce que je ferais : auditer le chemin de réécriture avant d'acheter quoi que ce soit. Quels résultats arrivent dans le CRM, dans quels champs, saisis par qui, et sous quel délai ? Si la réponse est « cela dépend du commercial », vous tenez votre premier projet, et ce n'est pas un projet d'agent.
La logique de disqualification : les règles de qui ne pas contacter
C'est la partie que je vois le plus souvent négligée. Les équipes définissent leur ICP et oublient les exclusions : clients existants, opportunités ouvertes, concurrents, régions que l'équipe ne peut pas suivre, entreprises trop petites pour payer.
Un client nous a dit que la prospection EMEA est difficile pour lui et que la personne qui la couvre est mal à l'aise au téléphone. Un autre craignait que ses SDR n'exécutent pas les tâches téléphoniques intégrées aux workflows de campagne. Placez un agent dans ce tableau sans logique de disqualification : il tire sur des comptes EMEA que l'équipe ne peut pas traiter, puis planifie des rappels que personne n'effectuera. Le volume monte, la conversion baisse, et tout le monde accuse l'agent.
Les règles empiriques ne coûtent presque rien ici : pour chaque critère d'ICP que vous écrivez, écrivez une exclusion à côté. Cinq inclusions et aucune exclusion, c'est un agent qui travaille avec la moitié d'un brief, et cette moitié de brief est une cause fréquente de l'échec des SDR IA.
Comment séquencer un déploiement pour éviter l'échec des SDR IA ?
Trois phases, et l'ordre est essentiel :
- D'abord les définitions. Étapes du pipeline, critères de rendez-vous et exclusions, rédigés puis encodés dans le CRM. Deux à trois semaines dans un projet allégé.
- Ensuite la rétroaction. Champs de résultats, réécritures obligatoires et vérification hebdomadaire que les raisons de perte sont réelles.
- Enfin l'agent, sur un segment étroit, mesuré sur les opportunités créées et non sur les envois.
Nous procédons ainsi pour que, plus tard, lorsque quelqu'un demande pourquoi l'agent a agi de telle manière, vous puissiez remonter à une règle écrite par un humain. Sans cela, impossible de déboguer. On ne peut que l'éteindre.
C'est aussi la raison pour laquelle il s'agit d'un problème RevOps et non d'un problème d'outillage. Si vous faites du RevOps au quotidien, vous êtes un chef de projet avec une spécialité, et ceci est un projet : s'accorder sur les définitions, les encoder, instrumenter les résultats. Le choix de l'éditeur vient après, et un CRM comme Salesforce ou HubSpot peut tout contenir.
Ce que j'ignore sur l'échec des SDR IA
Je n'ai pas de réponse satisfaisante à la question de savoir si les agents autonomes finiront par déduire ces règles seuls. Peut-être. Les éditeurs l'affirment, et les modèles ne cessent de progresser. D'après mon expérience, même une excellente recrue a besoin de définitions, et un agent est une recrue rapide sans manager.
Je ne peux pas non plus auditer le chiffre d'affaires d'un éditeur, alors considérez mon analyse comme un schéma, non comme un verdict. Ce que je peux dire, c'est que l'échec des SDR IA apparaît partout où le socle est absent, et que cela se vérifie en un après-midi.
Si vous hésitez aujourd'hui à adopter un agent, je vous recommande de poser trois questions à votre propre équipe avant la démonstration : qu'est-ce qui compte comme un rendez-vous, où les résultats sont-ils réécrits, et qui n'est jamais contacté. Si ces réponses prennent plus d'une minute, commencez par là. Vous en saurez plus sur notre approche de ce type de travail dans notre bibliothèque d'analyses.