9 000 $/mois → 700 $/mois

Une recherche immobilière renvoyait de 50 à 500 acheteurs. L’ancien parcours générait un message de prospection pour chaque résultat avant que l’utilisateur ne choisisse une personne à contacter.

Le coût augmentait donc avec le nombre de résultats de recherche. Il aurait dû dépendre du nombre, bien plus faible, de personnes qui recevaient réellement un message.

SendFlow créait le premier brouillon avec jusqu’à trois nouvelles tentatives. Un Review Gate l’acceptait ou le rejetait, un Content Rewriter ajustait le ton et le niveau de détail, puis un Message Humanizer produisait deux ou trois variantes. Huit threads de traitement exécutaient cette chaîne en parallèle et stockaient le résultat dans la base de données avant tout clic sur Send.

Résultat de recherche
  -> SendFlow (jusqu’à trois nouvelles tentatives)
  -> Review Gate
  -> Content Rewriter
  -> Message Humanizer (2 à 3 variantes)
  -> stocker chaque résultat

La chaîne effectuait quatre à cinq appels au modèle par acheteur. Pour une recherche renvoyant 500 acheteurs, cela représentait environ 2 500 appels avant que l’utilisateur ne sélectionne un destinataire.

Dans cet exemple de 500 résultats, les utilisateurs contactaient environ 100 acheteurs. Près de 80 % des messages précalculés n’étaient jamais utilisés, soit environ 2 000 appels sans résultat visible pour l’utilisateur. L’ajustement des prompts pouvait réduire le coût de chaque appel, mais ne justifiait pas l’exécution des appels inutilisés.

La nouvelle recherche renvoyait les acheteurs sans générer de message. Une action explicite Regenerate with AI appelait un agent spécialisé pour le contact sélectionné. Le contexte de la requête comprenait le site, le téléphone, les prénoms de l’acheteur et de l’expéditeur, le marché, l’activité de l’acheteur, l’historique de conversation mis en forme et l’identifiant de l’acheteur. Le résultat restait modifiable avant l’envoi.

Recherche de 500 acheteurs -> générer 0 message
L’utilisateur sélectionne un acheteur -> assembler le contexte du contact et de la conversation
Regenerate with AI -> 1 appel au modèle
ProgressReporter -> mise à jour WebSocket toutes les deux secondes
Résultat modifiable -> l’utilisateur décide de l’envoi

L’implémentation a évolué. Un instantané du dépôt utilisait une requête REST directe à l’ouverture du panneau du contact sélectionné. Le parcours décrit ensuite dans l’article a fait dépendre l’action d’une intention explicite de l’utilisateur et diffusé la progression par WebSocket. Il s’agit d’étapes successives du produit, pas d’un seul chemin de code simultané.

Le produit disposait de plus de 25 configurations d’agents spécialisés sur gpt-4.1-nano. Une seule configuration était sélectionnée pour chaque requête. Il ne s’agissait pas d’une chaîne de 25 agents. ProgressReporter envoyait une mise à jour WebSocket toutes les deux secondes pendant la génération du message.

Déclencher la génération par un clic a rendu l’attente visible. J’ai conservé un résultat modifiable, affiché la progression et limité la génération au destinataire sélectionné par l’utilisateur.

Dans l’exemple documenté de 500 acheteurs, les appels sont passés d’environ 2 500 à environ 100, soit une réduction de 96 %. Les dépenses mensuelles liées aux modèles sont passées d’environ 9 000 $ à environ 700 $. Ces montants mensuels arrondis correspondent à une réduction annualisée des dépenses d’environ 100 000 $.

La modification a aussi supprimé 1 218 lignes, dont le processeur de lots de 640 lignes. La suppression de ce parcours a également retiré ses nouvelles tentatives, processus d’exécution, mécanismes de persistance et coordination multi-agents.

• Mesurez la part du contenu généré réellement utilisée.
• Ne déclenchez les traitements coûteux qu’au moment de l’événement produit qui en a besoin.
• Affichez la progression lorsque le traitement à la demande ne peut pas se terminer immédiatement.
• Supprimez l’architecture de traitement par lots lorsque le produit n’en dépend plus.