Délivrabilité email : la méthode pour construire un outil unique sur le marché

Baptiste Guerre est Deliverability Expert chez Batch. En quelques semaines, il a construit de zéro le Deliverability Cockpit, l’outil dont les équipes CSM, Delivery Managers et Solution Engineers avaient besoin pour le meilleur niveau de suivi client.

Pourquoi cet outil ? Qu’est-ce qu'il manquait ?

Dans le monde de l’emailing, chaque point de délivrabilité gagné se traduit directement en revenus. C’est des millions d’euros qui sont en jeu. Nos clients nous font confiance sur ce sujet et on voulait le meilleur outillage.

Les données existaient. SparkPost, Microsoft SNDS, Postmaster Tools, Signal Spam : toutes ces sources exposent des APIs. Mais elles sont accessibles chacune dans leur propre interface, pensées pour des spécialistes. Un CSM qui gère de nombreux clients en parallèle ne peut pas passer sa matinée à croiser ces sources manuellement pour construire un diagnostic.

Et côté outils du marché, Validity Everest reste la référence. Il est puissant, bien conçu, mais pensé pour des entreprises qui gèrent leur propre délivrabilité. Leur contexte, c’est une équipe interne, quelques domaines d’envoi, un usage centré sur leurs propres campagnes. Chez Batch, c’est fondamentalement différent : on accompagne des centaines de clients, chacun avec leurs domaines, leurs sous-domaines, leurs pools d’IPs, leurs pratiques et leurs enjeux. On a aussi besoin d’analyser en interne, mais aussi d’exposer certaines analyses directement aux clients. Aucun outil du marché n’est calibré pour cet enjeu propre aux éditeurs de CEP.

L’idée était donc simple : construire ce qui correspond à nos besoins. Pas adapter quelque chose d’existant.

Et tu l’as construit comment, concrètement ?

La première chose que j’ai faite avant d’ouvrir Claude Code, c’est d’ouvrir Figma. J’ai dessiné à la main ce que je voulais voir : une vue par domaine, un score de santé, des alertes, l’idée étant de donner un wireframe très large à l’IA pour qu’elle ne parte pas dans tous les sens dès le départ.

Ensuite, j’ai rédigé un fichier Markdown de trois à quatre pages. Pas une spécification au sens strict, mais plutôt une expression des besoins :

• le nom de l’outil, ce qu’il fait, pour qui ;

• la cible principale : des CSM qui n’ont pas de formation délivrabilité et qui ont besoin d’avoir toutes les informations importantes de façon simple ;

• Puis le mapping des données : telle métrique vient de SparkPost, telle autre de Postmaster Tools, etc.

J’ai ensuite passé ce fichier à Claude en mode conversationnel d’abord, avant de passer à Claude Code, pour qu’il m’aide à optimiser le prompt. Claude a posé des questions. “Quand tu parles d’historique, c’est sur combien de temps ?” Des précisions que je n’aurais pas nécessairement anticipées seul. À la fin, j’avais un document de specs vraiment solide.

Et le premier run ?

J’ai construit un prompt final en couches : les specs complètes, un skill frontend-design (des fichiers d’instructions qui contraignent Claude Code sur le style, les couleurs, les règles d’interface) que j’ai customisé avec les principes de design Batch, et les contraintes de sécurité. J’ai demandé à Claude de tout lire avant de commencer, de poser des questions si quelque chose n’était pas clair.

Un point important sur les skills : j’en ai testé beaucoup au début. Et j’ai vite compris que des skills mal configurés ne servent à rien, ils ralentissent plus qu'ils n’aident. Au final je travaille avec trois, bien paramétrés :

• Frontend-design pour cadrer l’interface ;

• Impeccable pour les audits de qualité ;

• Superpower pour décomposer les grosses demandes en agents et faire valider les maquettes avant de coder.

Trois skills maîtrisés valent mieux que dix sous-utilisés.

Le prompt a tourné environ une demi-heure. Ce qui est sorti : un Deliverability Cockpit fonctionnel sur desktop et mobile pour diagnostiquer les urgences, avec les flux de données connectés. En une session.

Il y a forcément eu des problèmes.

Plusieurs. Le premier : un manque de finesse dans l’interprétation des KPIs. Le volume minimum pour qualifier un taux de rebond, par exemple. Si tu as envoyé deux emails et qu’un bounce, afficher “50 % de taux de rebond” c’est du bruit, pas de l’information.

Certaines données arrivent aussi avec plusieurs jours de retard, comme celles de Google Postmaster Tools. Il faut les attribuer correctement dans les graphiques pour éviter de déclencher des alertes pour des problèmes qui se sont produits dans le passé. Au début tout ça était en dur dans le code. Chaque modification passait par Claude, consommait des crédits, et avec les itérations j’avais six seuils différents éparpillés dans le projet.

La solution : une page de settings centralisée avec tous les thresholds. Tout se règle à un seul endroit, sans toucher au code.

Le deuxième problème, c’est le naming. J’avais pas défini de conventions de nommage au départ. À mi-projet, j’avais des variables qui s’appelaient qualified sur une page et isQualified sur une autre. Code complètement chaotique. J’ai dû tout arrêter pour faire un refactoring majeur. Maintenant c’est dans le CLAUDE.md dès le début : où se trouve comment on nomme les choses.

Un troisième point : quand j’ai intégré Stitch (un outil de maquettage qui génère aussi du code exportable) pour les interfaces mobile, l’IA a parfois donné plus de priorité aux valeurs codées dans le design qu’aux specs. J’ai passé une matinée à débugger des indicateurs qui affichaient des données statiques. Au bout de trois heures de débogage, Claude m’a dit qu’il avait pris les valeurs dans le design Stitch plutôt que dans les specs. L’IA n’avait pas compris la différence entre le fond et la forme.

Comment tu as géré la qualité du code sans être développeur ?

Je lis ce qu’il fait. Pas ligne par ligne systématiquement, mais quand il enlève quarante lignes et en rajoute deux pour une modification mineure, je sais que quelque chose cloche. Et quand je ne suis pas sûr, je lui demande d’expliquer ce qu’il a changé.

Deux réflexes que j’applique systématiquement. Je lui demande trois fois de suite s’il trouve des bugs. La première fois : “C’est bon, pas de bug.” Deuxième : “Tu es sûr ?” Toujours pas. Troisième : il en trouve trois ou quatre. Il faut insister.

Et avant chaque grosse feature, je lance /security-audit et /code-review dans Claude Code. Dans le fond, il y a peu de risques sur un outil interne qui n’utilise aucune donnée personnelle, protégé derrière un SSO, et développé sur la base de contraintes techniques et de sécurité strictes. Malgré tout, nous maintenons un standard élevé de sécurité sur l’ensemble des projets internes, quelle qu’en soit la nature. On ne prend pas de risques.

C’est quoi le CLAUDE.md dont tu parles ?

C’est le point de repère de Claude pour le projet entre les sessions. Architecture, règles de design, principes de sécurité, où se trouve quoi dans le code, conventions de nommage, etc. Sans lui, chaque nouvelle session repart de zéro et l’IA réinvente des choses qu’elle avait peut-être déjà construites. Avec lui, elle sait dans quelle direction aller dès le premier prompt.

Avoir un CLAUDE.md structuré et efficace, c’est bien, mais ça doit s’accompagner d’une bonne hygiène de contexte. L’IA a une mémoire de travail limitée. Plus la conversation s’allonge, plus elle perd le fil de ce qui a été dit au début, et elle ne le signale pas. Elle continue de répondre avec confiance, mais elle reconstitue ce qu’elle a oublié du contexte. C’est le “context rot” : non pas un silence, mais une invention silencieuse. Cela donne des résultats parfois incomplets, du travail à refaire et gâche vos tokens Claude.

Pour réduire l’apparition de ce phénomène :

• Je ne laisse pas la fenêtre de contexte se saturer. Dans Claude Code, la commande /compact permet de compresser la mémoire de la session en ne gardant que ce qui est utile pour la suite (ex : /compact keep only details related to bounce rates).

• Je fais des sessions courtes, centrées sur un bloc fonctionnel précis. Dans Claude Code, /resume permet de reprendre une session existante, et /rename de lui donner un nom pour s’y retrouver.

Qu’est-ce que l’outil permet concrètement aux équipes aujourd’hui ?

Un CSM qui suit un client en accompagnement délivrabilité ouvre le Deliverability Cockpit et voit l’état de santé de tous ses sous-domaines d’un coup : un score sur 100, les problèmes actifs confirmés dans les dernières 48h, et les recommandations directement formulées par IA si le score ne parle pas de lui-même. Il peut voir la performance par fournisseur (Gmail, Outlook, Yahoo, Orange, etc.) et reçoit des alertes Slack en temps réel si quelque chose déraille sur plus de 15 points de contrôle (volumes anormaux, rebonds, authentification cassée, pics de spam, etc.).

Il y a aussi un module d’audit de templates : avant d’envoyer une campagne critique, on peut scorer un email sur 100. Analyse du HTML, de la cohérence entre le fond et la forme, du rendu mobile, accessibilité, conformité, et une couche d’IA qui priorise les corrections à faire.

Ce qui prenait une heure de collecte et d’analyse manuelle prend maintenant cinq minutes. Et ça ne nécessite pas d’expertise délivrabilité approfondie pour interpréter. C’est ce qui permet à toute l’équipe CSM d’être au niveau, pas seulement les profils les plus techniques.

Chez Batch, la délivrabilité c’est un sujet qui dépasse l’outil interne, non ?

Dès le début, on a voulu se différencier sur ce point. Être meilleur que les autres CEP du marché, pas juste sur les features, mais sur le niveau de suivi, la réactivité, la finesse du diagnostic. Ce n’est pas une posture : les résultats sont là, les clients gagnent en performance en passant chez Batch, et c’est mesurable.

Le Deliverability Cockpit est l’un des soubassements de cet accompagnement. Il encode l’expertise de l’équipe et la rend accessible à tous les profils.

Et la question de l’intégrer directement dans la CEP Batch est une discussion en cours. Certains pans du Deliverability Cockpit pourraient à terme être exposés directement dans la plateforme, côté client.

Un conseil pour quelqu’un qui voudrait faire la même chose ?

Commencer par dessiner le résultat avant de toucher au code. L’IA produit ce qu’on lui donne à voir. Sans wireframe, même grossier, elle invente.

Rédiger les specs avant le prompt. Pas pour l’IA, pour soi. Ça force à clarifier ce qu’on veut vraiment construire.

Travailler en sessions courtes, bloc par bloc. Quand on enchaîne trois heures de vibe coding, on ne voit plus rien passer, on ne comprend plus ce qui se passe, et il n’y a plus que des bugs. L’IA se dégrade, et le développeur aussi.

Éviter le role-playing (ex : “Tu es un expert délivrabilité, analyse les résultats...”). Comme le montre une étude de Zheng et al. (2024), le role-playing dans les prompts n’est pas une bonne idée pour les tâches objectives avec les LLM : il n’améliore pas les performances, peut introduire des biais, et son effet est imprévisible. Une approche neutre et directe est donc préférable.

Accepter qu’il y a une vraie courbe d’apprentissage. Avec le temps, on commence à connaître son Claude, à anticiper ce qu’il va bien faire et ce qu’il va rater. Ce n’est pas un outil qu’on maîtrise du premier coup. Mais une fois qu’on a ses réflexes, on va beaucoup plus vite.