Claude Code a choisi Resend dans 64 cas sur 102 : comment concevoir un produit pour les agents

Imaginez : vous demandez à Claude Code d'« ajouter l'envoi d'e-mails », vous acceptez le patch, et un fournisseur précis est déjà installé dans votre dépôt. Ce n'est pas vous qui l'avez choisi. C'est l'agent. C'est précisément ce moment que décortique Zeno Rocha, cofondateur et CEO de Resend, dans le podcast Latent Space. Le point de départ : une énigme posée par les animateurs, à savoir pourquoi les agents recommandent Resend plutôt que Cloudflare Email, alors que Cloudflare dispose à la fois d'un avantage « à domicile » et d'une taille supérieure.

Le premier recommandé a gagné

Dans l'une des études AEO (answer engine optimization, optimisation pour les réponses de l'IA), Claude Code a cité Resend en premier dans 64 des 102 recommandations extraites. SendGrid n'a été premier que sept fois, mais a été mentionné 55 fois comme alternative. La logique est simple : si le développeur a accepté le patch, on n'en vient presque jamais à la deuxième option.

Une réserve importante : une étude plus récente et plus large s'est révélée plus concurrentielle, et Postmark arrivait en tête pour la plupart des modèles. La position n'est donc pas éternelle et dépend du modèle et de sa version. Au moment de l'enregistrement, selon Rocha, Resend comptait 4,3 millions d'utilisateurs et 120 000 clients payants.

Un produit que l'agent sait lire

Le premier canal de distribution de Resend n'a pas été l'API, mais React Email, une bibliothèque pour la mise en page des e-mails. Elle peut aussi s'utiliser avec SendGrid, et l'équipe a même décrit comment. Résultat : quand le développeur a eu besoin d'un autre fournisseur, une partie du code de Resend se trouvait déjà dans son dépôt.

Regardons maintenant avec les yeux de l'agent. Sur la page des prix de Resend, il y a un curseur : l'humain le déplace jusqu'au volume voulu et voit le montant. Pour l'agent, c'est de peu d'utilité. La solution est modeste : ajouter .md à l'adresse de la page et obtenir un simple tableau, lisible en une seule requête. Un bon autotest : ouvrez votre page des prix et vérifiez si un modèle peut y trouver la réponse à la question d'un client.

80 outils ou deux

Le serveur MCP de Resend est passé d'environ 20 outils à plus de 80. L'objectif de Rocha est de pouvoir faire depuis le chat tout ce qui est disponible dans le tableau de bord : envoyer un e-mail, inviter un collègue, vérifier la consommation, gérer la facturation. L'envoi d'un e-mail sert à la démo, mais le vrai travail se compose d'une « longue traîne » de telles opérations.

Cloudflare adopte l'approche inverse : Code Mode expose toute l'API via deux outils, search() et execute(). Mais le nombre d'outils ne règle pas tout. Rocha déplie les appels repliés dans ses propres sessions et regarde ce que l'agent a réellement fait. Dans un cas, le résultat ne tenait tout simplement pas dans le contexte, et réduire le nombre d'outils n'aurait rien corrigé.

Une expérience peu coûteuse à reproduire : dépliez la réponse d'un appel que vous faites chaque jour et regardez la part dont le modèle a réellement besoin. Anthropic, dans son article sur l'écriture d'outils pour agents, recommande aussi de renvoyer moins de données lorsque le résultat sature la fenêtre de contexte.

Après le choix, la livraison commence

Convaincre l'agent d'adopter votre SDK ne fait que la moitié du travail : il reste à livrer l'e-mail. Exemple : le suivi des clics. Le fournisseur peut réécrire les liens via un domaine partagé pour comptabiliser les clics. Si un client utilise ce domaine pour du phishing et qu'il est placé sur une liste de blocage, les e-mails légitimes des autres clients en pâtissent aussi. C'est pourquoi Resend a introduit des domaines de suivi dédiés.

Rocha explique aussi pourquoi il tient à conserver l'offre gratuite, bien que des spammeurs puissent s'y inscrire. L'entreprise limite ce risque par des processus anti-abus et par une garantie de sécurité d'un tiers, annoncée à 3 M$.

Que faire de tout cela

Les limites sont évidentes. Les études AEO mesurent des modèles précis à un moment précis, et le podcast est le récit d'un fondateur, non un audit indépendant. Les résultats de Resend ne peuvent pas être transposés mécaniquement à n'importe quel produit.

Mais les conclusions pratiques tiennent :

1. Créez des versions markdown de votre documentation et de votre page des prix, pour que l'agent les lise sans interactivité.
2. Vérifiez si les réponses de votre serveur MCP ne sont pas trop volumineuses : le problème vient souvent non du nombre d'outils, mais de la taille du résultat.
3. Offrez au développeur un artefact utile avant le choix du fournisseur, comme l'a fait React Email.
4. Ne créez pas de ressources partagées où un seul mauvais client ruine la réputation de tous.

L'idée centrale : votre premier utilisateur est désormais souvent un modèle, et le produit doit être conçu pour que sa décision soit simple et juste.