Délivrabilité des cold emails avec l'IA : ce qui pose vraiment problème

Les cold emails personnalisés par l'IA échouent pour la même raison que les cold emails classiques : une infrastructure d'envoi défaillante, pas un texte insuffisant. Les fournisseurs de messagerie décident si votre message arrive en boîte de réception avant qu'un humain ait lu une seule ligne de votre accroche rédigée par l'IA — sur la base de l'authentification du domaine, de la réputation d'envoi et des patterns de volume. Commencez par corriger tout cela, puis laissez l'IA améliorer le texte.

Pourquoi la personnalisation seule ne règle pas la délivrabilité

Les fondateurs qui construisent ou achètent un système de cold email basé sur l'IA optimisent généralement la mauvaise couche en premier. Ils s'obsèdent sur la qualité des prompts, en personnalisant chaque ligne pour l'entreprise du prospect, et ignorent l'infrastructure technique qui détermine si Gmail et Outlook mettent le message en boîte de réception plutôt qu'en spam. Nous avons commis cette erreur avec notre propre moteur d'outreach avant même d'avoir regardé nos enregistrements DNS : la couche de personnalisation était déjà solide — les brouillons donnaient l'impression que quelqu'un avait réellement consulté le site du prospect — et rien de tout cela n'a amélioré les taux de réponse tant que l'authentification n'a pas été corrigée en dessous.

La personnalisation aide effectivement la délivrabilité, mais indirectement : moins de destinataires marquent un email pertinent comme spam, et le taux de signalement en spam est l'un des signaux de réputation les plus puissants que suivent les fournisseurs de messagerie. En revanche, elle ne remplace pas les vérifications d'authentification qui interviennent avant même que votre objet soit analysé.

La base technique : SPF, DKIM, DMARC

Tous les grands fournisseurs de messagerie imposent désormais l'authentification aux expéditeurs en volume. Les propres recommandations de Google à ce sujet sont explicites : elles exigent l'alignement SPF et DKIM ainsi qu'une politique DMARC pour quiconque envoie un volume significatif (recommandations de Google pour les expéditeurs en masse) :

• SPF indique aux serveurs destinataires quels serveurs de messagerie sont autorisés à envoyer au nom de votre domaine.
• DKIM signe cryptographiquement chaque message afin qu'il ne puisse pas être altéré en transit sans que cela soit détecté.
• DMARC relie les deux et indique aux destinataires quoi faire en cas d'échec — publiez une politique et vous ne dépendez plus de leur bonne volonté.

DMARC vous offre également une visibilité que vous n'aviez pas auparavant : les rapports agrégés montrent exactement qui envoie des emails en se réclamant de votre domaine, ce qui est important si vous faites tourner un agent IA qui envoie en votre nom (présentation de dmarc.org). Rien de tout cela n'est spécifique à l'IA. C'est la même checklist qu'un expéditeur de newsletters en masse, et l'ignorer est la raison la plus fréquente pour laquelle un agent d'outreach IA techniquement impressionnant atterrit en spam dès le premier jour.

Là où l'IA apporte vraiment de la valeur : le contenu, pas l'infrastructure

Une fois l'authentification solide, la vraie contribution de l'IA est de faire en sorte que chaque email donne l'impression d'avoir été rédigé par quelqu'un qui a passé cinq minutes sur le site du prospect — parce que dans notre cas, c'est exactement ce qui s'est passé. Nous faisons tourner notre propre moteur d'outreach qui scrape le site de chaque prospect avec une instance Firecrawl auto-hébergée et un LLM local, puis rédige un email personnalisé par entreprise en un seul appel plutôt qu'une chaîne en plusieurs étapes qui extrait les faits, planifie, puis rédige. Le pattern « extraire les faits et rédiger » en un seul appel a surpassé la version en plusieurs étapes, aussi bien en coût qu'en qualité de sortie — principalement parce que moins d'appels LLM signifiait moins d'endroits où le brouillon pouvait dériver de ce qui était réellement sur la page. Si vous choisissez entre ces deux approches pour votre propre agent, les compromis sont les mêmes que ceux abordés dans single-call vs. agent chains.

Une personnalisation authentique réduit également la détection de patterns utilisée par les filtres anti-spam. Un envoi de mille emails quasi-identiques avec simplement le prénom modifié est facile à regrouper et à signaler pour un filtre. Mille emails faisant référence au produit, à la stack technique ou à une annonce récente de chaque entreprise ressemblent, mécaniquement, à mille emails différents.

Montée en volume et cadence d'envoi

Les nouveaux domaines et les nouveaux sous-domaines n'ont encore aucune réputation, et les fournisseurs de messagerie traitent par défaut un volume soudain provenant d'un expéditeur inconnu comme un signal de spam. C'est précisément pourquoi nous limitons les envois au niveau de l'infrastructure pour notre propre moteur d'outreach plutôt que de faire confiance au modèle pour réguler lui-même le rythme — ce même système décrit ci-dessus qui rédige un email par entreprise en un seul appel LLM et pourrait autrement les envoyer tous en même temps. L'approche pratique :

• Commencez sur un sous-domaine d'envoi dédié, jamais votre domaine principal, afin qu'un problème de réputation ne touche jamais la facturation, le support ou les emails produit.
• Montez progressivement en volume — la plupart des expéditeurs démarrent autour de 20 à 30 emails par jour et augmentent sur plusieurs semaines plutôt que d'envoyer toute la liste dès le premier jour.
• Maintenez un faible taux de rebond et un faible taux de signalement en spam pendant la montée en charge ; les deux sont pondérés plus lourdement par les fournisseurs de messagerie que le taux d'ouverture ne l'a jamais été.
• Répartissez les envois sur la journée plutôt que de déclencher un batch job à 9h00 pile — les patterns en rafale paraissent automatisés parce qu'ils le sont.

Un agent IA aggrave les choses si vous le laissez faire, car il est tout à fait capable d'envoyer 5 000 emails personnalisés en une minute. La limitation du débit doit résider dans votre infrastructure d'envoi, pas dans le jugement du modèle.

Le CTA compte plus que l'objet

Une fois le message délivré, ce que vous demandez détermine s'il convertit. Dans notre propre outil de cold email, le fait de remplacer le call-to-action « réservez un appel » (un lien vers un calendrier) par un simple « répondez OUI » a régulièrement amélioré les taux de réponse. Planifier un rendez-vous depuis un cold email crée une friction qui décourage des prospects pourtant intéressés — ils avaient l'intention de cliquer plus tard et ne l'ont jamais fait. Une réponse, en revanche, demande un effort quasi nul et maintient la conversation dans le canal où se trouve déjà le prospect. C'est également un signal de délivrabilité plus fort : les réponses indiquent aux fournisseurs de messagerie que cet expéditeur produit du courrier souhaité — bien plus que les ouvertures ou les clics. Si vous concevez le call-to-action d'un agent d'outreach ou de vente piloté par l'IA, cela mérite d'être lu en parallèle de designing the CTA for an AI sales agent.

Construire ou acheter la couche d'envoi

Écrire la logique de personnalisation est la partie agréable. Mettre en place correctement le SPF, DKIM, DMARC, le warm-up de sous-domaine, la gestion des rebonds et les listes de suppression — c'est la partie ingrate qui détermine si tout le reste a un sens. Plusieurs fournisseurs gèrent l'infrastructure d'envoi pour vous permettre de concentrer la couche IA uniquement sur la recherche et la rédaction ; d'autres s'attendent à ce que vous possédiez l'ensemble de la stack. Nous détaillons les véritables compromis, et les cas où une couche d'envoi managée vaut la majoration tarifaire, dans AI cold email agent: build vs buy.

Si vous dimensionnez un système d'outreach piloté par l'IA et souhaitez un second avis sur où investir votre temps d'ingénierie, parlons-en.