Comment on a construit notre SDR IA : ce qui a cassé
Un journal de bord : les erreurs de la première version, pourquoi l'enrichissement passe avant la rédaction, et le garde-fou qui empêche un SDR autonome de griller le domaine.
Publié le 2026-03-06
La première version était fausse
Le premier SDR IA qu'on a construit écrivait d'excellents emails. Il ne servait à rien.
L'erreur, c'était de le construire autour de l'étape de rédaction, parce que c'est celle qui fait le plus d'effet en démo. En pratique, écrire est la partie facile et la plus petite. Ce qui détermine si l'outbound fonctionne, c'est la justesse de la liste et la réalité des relances — et aucun des deux n'est un problème de rédaction.
On l'a donc reconstruit dans l'ordre où le travail se déroule réellement.
Le pipeline
1. Qualifier avant d'enrichir. L'enrichissement coûte de l'argent par contact, donc filtrer en premier n'est pas une optimisation, c'est la différence entre une facture raisonnable et une facture absurde. L'ICP est écrit sous forme de règles explicites, exclusions comprises, et tout ce qui est ambigu est écarté plutôt que deviné.
2. Enrichir, puis vérifier. Un contact avec une adresse non vérifiée est pire que pas de contact du tout — il endommage le domaine d'envoi dont dépendent toutes les campagnes suivantes. Le risque de bounce est vérifié avant même qu'on écrive quoi que ce soit.
3. Écrire à partir de la fiche, pas d'un template. Une personnalisation qui se voit comme telle est pire que pas de personnalisation. L'employé écrit à partir de ce qu'il a réellement trouvé, et s'il n'a rien trouvé de précis, il envoie la version courte et générique plutôt que d'inventer un compliment sur une levée de fonds.
4. Séquencer avec une condition d'arrêt. Quatre touches, puis le contact passe sur une liste dormante. La condition d'arrêt compte plus que la cadence : un système autonome sans arrêt est une machine à agacer les gens à grande échelle.
5. Tout consigner au moment de l'action. Chaque touche écrite dans le CRM au moment où elle se produit. C'est l'étape que les humains sautent, et celle qui rend tout le canal mesurable.
Ce qui a cassé
Le coût de l'enrichissement. Le premier run enrichissait tout avant de filtrer. Réglé en changeant l'ordre — c'est toute la leçon.
La sur-personnalisation. Les premiers brouillons ouvraient systématiquement sur un détail précis tiré du site du prospect. Ça ressemblait à de la surveillance. Le détail n'est utilisé maintenant que quand il est vraiment pertinent, et sauté quand ce n'est que de la décoration.
Les échecs silencieux. Un connecteur qui expire en plein run était indiscernable de « pas de leads aujourd'hui ». Une étape en échec déclenche maintenant une alerte, pas un rapport vide — un dashboard qui affiche zéro doit toujours distinguer « rien à faire » de « rien n'a marché ».
Pas de plafond d'envoi. L'erreur évidente, apprise de la manière la plus banale. Il existe maintenant un plafond quotidien strict que l'employé ne peut pas relever de lui-même.
Le garde-fou le plus important
L'approbation des envois de la première semaine.
Chaque message attend un oui ou un non humain avant de partir. C'est fastidieux pendant cinq jours, et c'est ce qui rend le mois suivant autonome, parce que chaque rejet enseigne quelque chose qu'aucun fichier d'instructions n'aurait capturé — qu'une expression que vous utilisez en interne sonne mal à l'extérieur, qu'une affirmation qui vous semble anodine vous fait ressembler à tout le monde.
Après cette semaine, l'approbation se désactive pour les envois de routine et reste active pour tout ce qui implique un client nommé ou un chiffre. Ça, plus le journal d'audit, c'est toute l'histoire de la sécurité pour un émetteur autonome.
Ce qu'il fait aujourd'hui
Il qualifie l'inbound et l'outbound selon les règles écrites de l'ICP. Il enrichit et vérifie. Il écrit à partir de la fiche. Il déroule une séquence de quatre touches avec condition d'arrêt. Il réserve directement dans le calendrier quand une réponse est chaude. Il consigne chaque action.
Il ne prend pas l'appel. Ça n'a jamais été l'objectif — la répartition entre ce qu'un SDR doit automatiser et ce qu'il ne doit pas automatiser est la version guide d'achat de cet article.
Si vous construisez le vôtre
Construisez dans l'ordre du pipeline, pas dans l'ordre de la démo. Mettez la condition d'arrêt avant la cadence. Rendez les échecs bruyants. Approuvez la première semaine à la main.
Et écrivez les exclusions de l'ICP. Presque tous les problèmes d'outbound qu'on a débogués depuis se sont révélés être des problèmes de liste déguisés en problèmes de rédaction.
Accédez à votre espace si vous préférez ne pas le construire vous-même.
Tous les articles du blog OpenLabor