Merge a automatisé la planification de ses dîners : de dizaines d’heures à 30 minutes par événement

Les études de cas du type « nous utilisons l’IA pour tout » sont généralement creuses. Celle-ci contient néanmoins quelques détails concrets qui méritent l’attention : le fonctionnement du bot chargé d’organiser les événements et ce que l’entreprise affirme au sujet de la fiabilité des appels d’outils. Précisons d’emblée qu’il s’agit d’un témoignage client publié sur le blog d’OpenAI, donc d’un contenu fourni par un prestataire, et que ses chiffres ne peuvent pas être vérifiés de manière indépendante.

Ce que fait le bot destiné aux dîners

Merge commercialise une infrastructure pour les produits d’IA : synchronisation des données clients, accès sécurisé des agents aux outils, routage des modèles et contrôle des coûts. L’entreprise utilise une partie de ses propres produits pour ses activités internes.

Les dîners privés destinés aux clients et prospects en sont un exemple. Pour un dîner à Dallas, l’équipe a défini la ville et le profil des invités. Le bot a ensuite extrait des candidats du CRM et d’Apollo, vérifié les invitations et réponses antérieures, puis préparé une campagne d’e-mails au nom de la CEO, Shensi Ding. Il tient également à jour le tableau des participants, propose un plan de table et crée des notes dans le calendrier, où les équipes commerciales et customer success ajoutent du contexte sur chaque invité.

La répartition des rôles est simple : le modèle raisonne et rédige les brouillons, tandis que les connecteurs de Merge donnent accès à Salesforce, Gong, Google Sheets et Gmail. Ding vérifie le résultat, réécrit les formulations qui sonnent faux et établit elle-même la liste des invités, car le bot ne connaît pas le contexte des relations personnelles.

Selon l’entreprise, la préparation des listes et des e-mails ainsi que la tenue du tableau mobilisaient auparavant des dizaines d’heures pour l’ensemble de l’équipe ; il faut désormais environ 30 minutes par événement. La comparaison porte sur les mêmes tâches pendant une période de trois mois. Parallèlement, le nombre de dîners est passé de 8 au Q2 à 16 au Q3, et plus de 30 sont prévus au Q4.

Ce qui peut être utile aux développeurs

Le principal enseignement concerne la fiabilité. Merge affirme que les appels d’outils passant par sa couche réussissent dans 99,9 % des cas, contre environ 60 % lorsqu’ils transitent par des serveurs MCP publics. L’entreprise ne dévoile pas sa méthode de comparaison et commercialise précisément la couche censée résoudre ce problème. Mais tous ceux qui ont conçu des agents connaissent la difficulté : le modèle peut être performant tandis que la chaîne échoue au niveau de l’autorisation, des schémas ou des délais d’expiration de l’intégration.

Deuxième détail : l’utilisation de Codex pour la revue de code. Ding a montré comment il avait contribué à un nouvel onglet de configuration de l’accès aux outils : l’équipe cherchait notamment à rendre le bouton « Add tool pack » plus compréhensible. Les décisions restaient prises par des humains, et les ingénieurs étaient responsables de la vérification et de la mise en production. Le dispositif est honnête : le relecteur formule des suggestions, mais la responsabilité reste celle de l’équipe.

Troisième point : les workflows destinés aux non-ingénieurs. Le responsable commercial a créé des scénarios réutilisables pour l’approbation des transactions, la mise à jour des prévisions et les actions à mener après les appels de renouvellement. Il n’a plus à reconstituer le contexte à chaque fois : il reçoit un dossier préparé et prend lui-même la décision.

Limites

Premièrement, il s’agit d’un format promotionnel. Les durées « avant et après » ont été mesurées par l’entreprise elle-même et n’incluent pas les coûts de développement ni de maintenance du bot. Deuxièmement, le bot envoie des e-mails au nom de la CEO : une erreur de destinataire ou de ton peut donc nuire à sa réputation. C’est pourquoi un humain reste dans la boucle et relit tout avant l’envoi. Troisièmement, l’augmentation du nombre de dîners ne prouve pas celle du chiffre d’affaires : la publication ne présente que des retours positifs et des possibilités de démonstration.

Les éloges concernant le « caractère » du modèle et sa capacité à comprendre les non-dits doivent être considérés comme des impressions d’utilisateurs, et non comme des mesures.

Conclusion pratique

Si vous construisez des agents, mesurez le taux de réussite des appels d’outils séparément de la qualité du modèle : c’est souvent à ce niveau que la fiabilité se dégrade. Pour l’automatisation interne, choisissez un processus étroit et répétitif, comme la préparation de listes et de campagnes d’e-mails, tout en laissant à un humain la vérification finale et l’envoi. Et commencez par tester l’ensemble sur un nouveau produit qui n’a pas encore de clients, comme le conseille Ding elle-même.