Un fondateur à qui j’ai parlé récemment lance un deuxième produit. Nouvel acheteur, nouveaux concurrents, un ICP différent de celui dans lequel le cœur de métier vend depuis des années. L’équipe go-to-market dédiée, c’est deux personnes : un account executive et un go-to-market engineer. Pas de SDR, pas de field marketing, personne pour tenir un stand. Et la première question sur la table n’était pas « comment construire du pipeline », c’était « avons-nous même besoin de SDR, ou peut-on simplement lancer des agents IA là-dessus ? » C’est le bon instinct accroché à la mauvaise première question.
La question est partout cette année, et pour de bonnes raisons. L’économie du sales development par cadence a basculé. SaaStr soutient désormais que la plupart des SDR seront des AI SDR en 2026 et au-delà, et la version la plus citée de l’histoire, c’est Jason Lemkin remplaçant une équipe commerciale d’environ dix personnes par vingt agents IA pilotés par à peine plus d’une personne. Quand on est fondateur et qu’on observe cela, la tentation est évidente : sauter l’embauche de SDR et acheter les agents à la place.
Mais il y a une phrase dans le conseil même de SaaStr qui compte plus que le titre. Un AI SDR, notent-ils, est un force multiplier pour une motion qui marche déjà, pas un remède pour une qui ne marche pas. Cette seule distinction est tout le problème d’un lancement de nouveau produit, et c’est pourquoi « AI SDR contre human SDR » est le mauvais point de départ.
Quand je dis outbound engine, je veux dire quatre choses, et aucune n’est une personne. La première est une liste de comptes fondée sur un vrai ICP pour ce produit, pas héritée de l’entreprise qui l’a construit. La deuxième est une raison de contacter maintenant : un trigger event, une technologie installée, un schéma de recrutement, quelque chose qui justifie le timing. La troisième est une séquence et une offre qui valent une réponse, écrites et testées plutôt que supposées. La quatrième est la plomberie de données en dessous : le modèle d’objets CRM, l’enrichment, le routing, le reporting, pour que la motion soit mesurable dès le premier envoi.
Voilà l’engine. Le SDR, humain ou IA, est la main-d’œuvre qui le fait tourner. La main-d’œuvre n’est pas l’engine. Et voici la partie que les fondateurs sautent : s’il n’y a pas d’engine, automatiser la main-d’œuvre n’automatise rien. Vous avez acheté une façon plus rapide d’envoyer une hypothèse.
Un AI SDR est réellement un force multiplier. Si l’outbound marche déjà avec des humains, les agents le rendent moins cher, plus rapide et plus régulier, et l’argument en leur faveur est solide. Le problème, c’est le mot « déjà ». Une motion qui marche, c’est une liste définie, calée sur un vrai signal, passée par une séquence testée, qui produit des réponses et réserve des rendez-vous. Quand cela existe, multiplier est intelligent.
Quand le produit a été lancé le mois dernier et que personne n’a fait tourner une seule séquence, il n’y a pas de motion à multiplier. Vous pointez un multiplicateur sur zéro. Les agents enverront docilement mille e-mails bâtis sur un ICP que personne n’a validé, contre une liste que personne n’a défendue, avec une offre que personne n’a testée, et ils le feront à une échelle qui rend l’erreur plus difficile à voir, pas plus facile. La version honnête de « dois-je acheter un AI SDR pour mon nouveau produit » est « non, parce que vous n’avez pas encore la chose qu’il est censé multiplier ».
L’autre moitié, c’est le go-to-market engineer, et je veux rendre justice au rôle, car il est réel et utile. La couche d’exécution d’un outbound engine moderne, c’est aujourd’hui vraiment de l’ingénierie : Clay, enrichment waterfalls, Apollo, outillage scriptable avec Claude, tout le stack. Quelqu’un doit construire et faire tourner cela. C’est le GTM engineer, et vous en voulez un.
Ce que je ne ferais pas, c’est confondre cette personne avec celle qui conçoit l’engine. Beaucoup d’opérateurs qui se présentent comme GTM engineers sont certifiés Clay, ont construit quelques séquences, et n’ont jamais vécu un vrai cycle de vente. C’est une compétence d’exécution, pas de stratégie. La personne qui décide l’ICP, le signal et l’offre doit avoir vu des deals gagnés et perdus, parce que l’engine ne vaut que ces décisions. Construire contre concevoir, voilà la distinction, et une équipe lean a besoin des deux, même quand ce sont deux personnes avec quatre casquettes.
Nous avons cadré exactement cela récemment avec une entreprise d’infrastructure de données qui montait une deuxième ligne de produit en parallèle de son cœur de métier. Le fondateur avait déjà automatisé sa propre fonction de sourcing de recrutement, sans aucun sourceur restant sur la masse salariale, et demandait raisonnablement pourquoi le sales development serait différent. Question légitime, et la réponse est instructive.
Le sourcing a été automatisé parce qu’il avait d’abord une motion qui marchait : un profil de candidat défini, un canal qui produisait des réponses, une séquence qui réservait des appels. Ils ont automatisé quelque chose qui marchait déjà. Le nouveau produit n’avait rien de tout cela. Pas d’ICP écrit, pas de liste de comptes, pas de signal pour caler l’outreach, et aucune séquence testée par qui que ce soit. Automatiser la fonction SDR là n’aurait pas automatisé une motion. Cela aurait automatisé une hypothèse, en volume, avant que quiconque vérifie si elle était vraie.
- Écrivez l’ICP et la buying persona pour le nouveau produit. Nouveau produit, nouvel acheteur. N’héritez pas du profil de la maison mère simplement parce que c’est le même logo sur le deck.
- Construisez une liste de comptes que vous pouvez défendre, fondée sur un vrai signal : un trigger event, une technologie installée, un schéma de levée ou de recrutement. Une liste sans raison de contacter maintenant n’est qu’une base de données.
- Écrivez et testez une séquence et une offre à la main. Obtenez dix vraies réponses avant d’automatiser le moindre envoi. Bon marché, falsifiable, et cela vous dit si l’engine a la moindre traction.
- Montez la plomberie de données. Le modèle d’objets CRM, l’enrichment, le routing et le reporting, pour que la motion soit instrumentée dès le premier jour plutôt que reconstruite après coup.
- Seulement maintenant, décidez de la main-d’œuvre. L’engine construit et prouvé à petite échelle, un seul opérateur plus l’automatisation fait tourner ce qui demandait une équipe, et l’AI SDR devient enfin le force multiplier qu’on vous a vendu plutôt qu’une façon coûteuse de passer une hypothèse à l’échelle.
Vous finirez probablement avec moins de SDR qu’il y a deux ans. Cette partie de la prédiction est exacte, et je ne la conteste pas. Mais vous y arrivez en construisant d’abord l’engine et en automatisant une motion qui marche déjà, pas en achetant des agents en espérant qu’une motion apparaisse derrière eux. Si vous lancez de l’outbound pour un nouveau produit et voulez une deuxième paire de mains sur l’engine avant de décider de la main-d’œuvre, c’est précisément le travail que nous faisons en programmatic outbound et en stratégie GTM, alors dites-nous ce que vous lancez.
- SaaStr. « Dear SaaStr: Should I Use an AI SDR Before I Have a Working Human SDR Motion? » 2026. saastr.com
- SaaStr. « Why Most SDRs Will Be AI SDRs In 2026+. » 2026. saastr.com
- Lenny’s Newsletter. « We Replaced Our Sales Team With 20 AI Agents, Here’s What Happened Next. » Janvier 2026. lennysnewsletter.com