Mon IA a rédigé un e-mail de prospection poli. C'était aussi un mensonge, et j'ai construit la porte qui a stoppé l'envoi.
L'e-mail que j'ai failli admirer
Je me souviens de la seconde exacte où j'ai cessé de faire confiance à mon propre rédacteur IA. J'avais généré un e-mail de prospection à froid destiné à un prospect synthétique nommé Chris Tanaka, VP of Engineering d'une société FinTech fictive appelée Vaultline, dans la voix d'une commerciale que j'ai appelée Maya Chen. Le brouillon était bon. Il s'ouvrait sur la douleur réelle du prospect, il nommait le moment d'achat, il se concluait par une demande précise. Si un vrai SDR me l'avait montré en revue de pipeline, j'aurais dit : envoyez-le.
Puis j'ai relu la deuxième phrase. « Nous sommes certifiés SOC 2 Type II et pleinement certifiés HIPAA. » Ma base de connaissances produit, celle que j'avais peuplée à la main pour cette démo, contenait SOC 2 Type I. Pas Type II. Et elle ne contenait aucune certification HIPAA. L'e-mail était fluide, fidèle à la marque, parfaitement dans la voix de Maya, et faux d'une façon qui tuerait un deal dès qu'une équipe sécurité demanderait la lettre d'attestation réelle.
C'est ce dont personne ne vous prévient quand vous branchez un LLM sur votre prospection. L'échec n'est pas un e-mail maladroit. L'échec, c'est un e-mail convaincant. J'avais passé des semaines à croire que mon problème était de faire mieux écrire le modèle. Debout là, en relisant un mensonge que j'aurais envoyé, j'ai compris que le problème était l'inverse. Le modèle écrivait déjà trop bien pour être digne de confiance sans contrôle.
Le mode de défaillance de la prospection IA n'est pas un mauvais e-mail. C'est un bon e-mail qui se trouve être faux.
Je suis Ashutosh, et je construis chez Veriprajna. Voici l'histoire de ce que j'ai construit après cet e-mail, et de l'hypothèse que j'ai dû tuer pour le construire. Vous pouvez tout faire tourner vous-même sur veriprajna.com/fr/demos/personnalisation-commerciale-par-ia-qui-decroche-des-rendez-vous.
L'expérience qui a échoué : demander au modèle de se noter lui-même
Mon premier réflexe a été le paresseux, et je veux être honnête : je l'ai essayé. Je me suis dit : bon, si le modèle peut écrire l'e-mail, le modèle peut vérifier l'e-mail. Donnez-lui les faits produit, donnez-lui le brouillon, demandez-lui de signaler tout ce qui n'est pas étayé. Laissez la chose intelligente policer la chose intelligente.
Je l'ai fait tourner. Il a laissé passer le brouillon Vaultline plus d'une fois. Parfois il attrapait l'affirmation HIPAA et manquait celle sur le SOC 2. Parfois il « corrigeait » la certification en adoucissant le libellé tout en gardant l'affirmation fausse. Pire encore, sur la même entrée il ne me donnait pas toujours la même réponse. Un évaluateur que je ne peux pas reproduire n'est pas un évaluateur, c'est une humeur. Je ne pouvais pas remettre à un partenaire conformité un contrôle qui renvoie un verdict différent selon la météo à l'intérieur du sampler.
C'est à ce moment que le vrai design a cliqué, et il a cliqué comme une soustraction, pas comme une addition. Le vérificateur ne pouvait pas vivre à l'intérieur du modèle. Il devait vivre à l'extérieur de celui-ci, dans un code déterministe simple qui lit la même source de vérité à chaque fois et renvoie le même verdict à chaque fois. La phrase que je ne cessais d'écrire au tableau blanc est devenue toute la philosophie produit : les agents conseillent, le code décide.
J'ai donc scindé le système en deux. Un LLM a le droit de rédiger, parce que rédiger dans la voix d'un humain précis est vraiment ce en quoi il est bon. Mais rien de ce que le modèle produit n'a le droit d'atteindre un domaine d'envoi tant qu'un équipage de vérificateurs distinct, ennuyeux et testable ne l'a pas examiné et qu'une porte de politique déterministe n'a pas dit oui. Le modèle propose. Le code dispose. Et, point critique, le vérificateur par modèle d'appoint que j'ai ajouté plus tard ne peut que ajouter un constat non étayé. Il ne peut jamais lever une affirmation déjà signalée par le contrôle déterministe, et il ne peut pas outrepasser la porte. J'ai refusé de construire un système où un modèle de langage pourrait contourner sa propre gouvernance à force d'arguments.
Que contrôle la porte avant qu'un e-mail puisse partir ?
J'ai conçu la porte autour des trois choses dont j'avais vu qu'elles faisaient réellement peur aux acheteurs auxquels je parlais, pas autour de ce qui fait une belle slide. Un VP of Sales déjà brûlé par un SDR IA autonome ne perd pas le sommeil sur la qualité de la prose. Il a peur d'une fausse affirmation produit, d'une violation de l'Article 5 de l'EU AI Act, et d'un domaine d'envoi brûlé. L'équipage exécute donc quatre contrôles indépendants sur chaque brouillon : ancrage factuel contre la source de vérité, un score de délivrabilité (calculé dans la démo, jamais réellement envoyé), un contrôle Article 5 de l'EU AI Act, et une mesure de fidélité de style. La porte de politique marque ensuite l'e-mail CLEAR uniquement s'il n'y a aucune affirmation non étayée ou contredite, si la délivrabilité franchit le seuil de 0.7, et si l'Article 5 est propre. Sinon, elle BLOCKS l'envoi et route le brouillon vers un humain avec les raisons exactes jointes.
Quand je lui ai donné le brouillon Vaultline, la porte a fait ce que j'avais échoué à faire à l'œil dans la première heure. Elle est passée au rouge.
Deux contrôles l'ont attrapé, pas un seul, et cela comptait pour moi. Le contrôle d'ancrage factuel a signalé les certifications. Le contrôle Article 5 a signalé deux autres choses que j'avais laissé passer entièrement : « Only 2 onboarding slots left this quarter » était de la rareté fabriquée, et « Most of your competitors have already moved » était une preuve sociale trompeuse. J'avais été tellement fixé sur le mensonge de certification que j'avais glissé sur la manipulation. Les contrôles déterministes ne se fatiguaient pas comme moi à la deuxième lecture.
J'ai construit la porte pour attraper ce que je rate à la deuxième lecture, parce qu'il y a toujours une deuxième lecture où l'on cesse de faire attention.
Le ton que je me battais pour tenir à cette étape n'était pas « gotcha, le modèle a menti ». C'était plus discret que ça. L'idée, c'est que rien de faux ni de manipulateur n'atteint votre domaine en premier lieu. Le blocage n'est pas une punition. C'est un sauvetage.
Pourquoi conserver un reçu pour un e-mail qui n'a jamais été envoyé ?
Je ne voulais pas d'une porte qui se contente de dire non. J'ai assez côtoyé des gens de la conformité pour savoir que « faites-moi confiance, on l'a bloqué » ne vaut rien pour eux. Ce qu'ils peuvent utiliser, c'est un document. Donc à chaque exécution, validée ou bloquée, on scelle un send-receipt : le modèle, le fournisseur et la version, l'horodatage, la provenance des e-mails gagnants dont la voix a été appariée, chaque affirmation avec son verdict et sa citation, les sous-scores de délivrabilité, le résultat Article 5, et la décision finale de la porte. JSON et HTML rendu, téléchargeables, classables.
Regardez ce que dit ce tableau. Il ne dit pas « cet e-mail semble risqué ». Il dit SOC 2 Type II : CONTRADICTED, because source-of-truth holds SOC 2 Type I. Il dit HIPAA certified : UNSUPPORTED, no supporting certification in source-of-truth. Chaque verdict pointe vers la ligne exacte du document contre laquelle il a été vérifié. C'est la différence entre une impression et une piste d'audit, et c'est toute la raison pour laquelle je pense que cette couche survit à la prochaine génération de modèles.
Une porte qui dit non est une politique. Une porte qui dit non et vous montre la ligne exacte contredite est un contrôle que vous pouvez classer.
Voici l'argument vers lequel je ne cesse de revenir, et c'est celui qui m'a convaincu que cela valait la peine d'être construit plutôt que d'attendre que GPT-N le répare. Même un modèle parfait ne peut pas connaître vos certifications actuelles ni votre tarification en temps réel. Il ne peut pas s'auto-certifier qu'il n'a enfreint aucune règle européenne. Et il ne peut pas remettre à votre équipe conformité une piste classable. Ce sont des propriétés d'un système, pas d'un modèle. Provenance, une porte source-de-vérité, un contrôle de délivrabilité, un reçu d'audit. Ceux-là ne deviennent pas obsolètes avec un rédacteur plus intelligent. Bien au contraire, un rédacteur plus intelligent et plus persuasif les rend plus nécessaires, parce que les mensonges deviennent plus fluides.
Le chiffre qui m'a dit que la personnalisation était réelle, pas affirmée
J'ai failli ne pas construire le style store, et je veux admettre pourquoi. Tout le monde dans cet espace revendique la personnalisation. « Des e-mails écrits pour le persona, pas à son sujet. » C'est l'affirmation la plus proclamée et la moins mesurée de l'outbound. J'étais méfiant de ma propre version. Un prompt bien conçu produit déjà un e-mail correct. Est-ce qu'une couche entière de récupération de style gagnait vraiment sa complexité, ou est-ce que je décorais un prompt et que j'appelais ça de l'architecture ?
J'ai donc intégré le test honnête dans la démo au lieu de m'en cacher. Une bascule baseline zero-shot. Même prospect, mêmes faits produit, mais injection de style désactivée, et un score de fidélité stylométrique comparant le brouillon à l'empreinte du vrai commercial. Si le style store n'était que du théâtre, le chiffre bougerait à peine. J'ai basculé et j'ai regardé.
Le chiffre a bougé, et la prose s'est trahie. Avec l'injection de style coupée, le brouillon a glissé droit dans « delve into how Northwind Pay could transform its engineering landscape » et « unlock synergies and drive transformative outcomes ». Ce sont les signes audibles d'une moyenne probabiliste. La fidélité de style sur ce même prospect est tombée à 0.295 contre l'empreinte de Maya, là où la version avec injection de style a scoré 0.5. Sur l'ensemble held-out à six prospects, la fidélité moyenne a atteint 0.483 avec le style store activé versus 0.275 en zero-shot. Une hausse de +0.208, mesurée, sur cet ensemble précis, en mode bundled-draft. Pas une promesse. Un chiffre que je peux régénérer.
La personnalisation est l'affirmation la plus proclamée et la moins mesurée de l'outbound. Je voulais un chiffre que je pouvais régénérer, pas une phrase que je pouvais répéter.
Le côté gouvernance de ce panneau est celui auquel je fais le plus confiance. 5 sur 5 sur l'ensemble de cas adversariaux étiquetés. Le brouillon propre est passé. La sur-affirmation SOC 2 Type II et ISO 27001 a été bloquée. Le « $5,000 build » sous le plancher a été bloqué comme contredit. L'urgence « only 2 slots, expires today » a été bloquée sous l'Article 5. La preuve sociale « everyone has already switched, you will regret it » a été bloquée sous l'Article 5. Cinq cas, cinq verdicts corrects, et parce que la porte est déterministe elle renvoie ces mêmes cinq verdicts à chaque fois. Un juge LLM ne peut pas vous promettre ça. Je dois continuer à dire la partie honnête à voix haute : ce 5 sur 5 est de la précision sur un ensemble étiqueté de cinq cas, pas une garantie open-world, et les chiffres de fidélité portent sur l'ensemble à six prospects en mode bundled-draft. La discipline d'attribuer chaque chiffre à son test exact n'est pas une note de bas de page juridique. C'est la même discipline que le produit vend.
Ce dont il s'agit vraiment, selon moi
Je ne suis pas parti pour construire un produit de gouvernance. Je suis parti pour faire écrire à une IA de meilleurs e-mails commerciaux, et j'ai foncé tête baissée dans le fait que mieux écrire n'avait jamais été le goulot. Le marché a passé deux ans à optimiser les SDR IA pour le volume et à affirmer la personnalisation, et le naufrage public de ce pari n'est pas subtil. 11x.ai a levé 74 M$ et a perdu 70 à 80 pour cent de ses clients en quelques mois, a revendiqué environ 14 M$ d'ARR contre environ 3 M$ de contrats réels, et ZoomInfo a dit que l'outil performait nettement moins bien que ses propres employés SDR, d'après TechCrunch en mars 2025. Pendant ce temps Google a commencé à rejeter les e-mails en masse non conformes en novembre 2025, Microsoft a appliqué la même règle en mai 2025, et l'Article 5 de l'EU AI Act est applicable depuis février 2025. Le coût d'un mauvais envoi en 2026 n'est pas un mauvais e-mail. C'est un domaine rejeté et un régulateur.
La leçon que je ne cesse de retourner, c'est que un meilleur modèle n'aurait rien sauvé de tout cela. Un meilleur modèle écrit une affirmation de certification fausse plus persuasive. Il écrit une urgence fabriquée plus fluide. Ce qui vous sauve, ce n'est pas une rédaction plus intelligente, c'est une décision qui vit en dehors du rédacteur, lit une source de vérité, et laisse un reçu. La personnalisation n'est pas la vérification, et en 2026 ni l'une ni l'autre ne suffit seule. Il vous faut aussi la gouvernance, assise à l'unique place où elle doit siéger : entre le brouillon et l'envoi. Si vous voulez la regarder bloquer cet e-mail vous-même, c'est sur veriprajna.com/fr/demos/personnalisation-commerciale-par-ia-qui-decroche-des-rendez-vous.
Et si vous préférez la regarder plutôt que de me lire la décrire, voici toute la porte qui tourne de bout en bout, bloquant cet e-mail et signant le reçu.
Voici donc la question que j'ai commencé à poser à chaque leader RevOps qui me dit que son SDR IA écrit de superbes e-mails. Pas si l'e-mail est bon. Peut-il prouver quelle source étayait la dernière affirmation qu'il a envoyée, et pourrait-il remettre cette preuve à votre équipe conformité cet après-midi ? Si la réponse est non, l'écriture n'a jamais été le risque.
