Des agents qui poussent l'info, pas du chat

Chaque matin à neuf heures, un message Slack atterrit dans les canaux de nos utilisateurs : les créations publicitaires les plus performantes de la veille, avec miniatures, une bande de métriques, et un lien direct vers le dashboard. Personne n'a tapé de prompt. Personne n'a ouvert un chat. C'est la fonctionnalité agent dont les utilisateurs parlent le plus, et elle n'a pas de zone de chat.

Détails produit anonymisés. Patterns d'ingénierie réels.

Je pense que c'est là que vont les agents, et la plupart des équipes sur-investissent encore dans la conversation.

Le chat a un problème de démarrage à froid

Le chat fait porter l'initiative à l'utilisateur. Il doit se souvenir que l'agent existe, l'ouvrir, formuler une question. Ça fonctionne pour les demandes nouvelles, exploratoires. Ça échoue complètement pour l'information dont les gens ont besoin en rythme : comment les campagnes ont performé hier, ce qui a changé cette semaine, quelle création est en train de mourir en silence.

L'information rythmique ne devrait pas dépendre de quelqu'un qui se souvient de demander. L'assistant qui donne vraiment l'impression d'être un assistant, c'est celui qui se présente de lui-même. Le push inverse la relation : l'agent vient à vous, à votre heure, dans l'outil que vous avez déjà ouvert.

Une routine est une surface produit, pas un cron job

Notre première implémentation était la plus évidente : un cron job dédié et un objet de configuration. Elle a été tuée en review, et le reviewer avait raison.

On l'a reconstruite comme une tâche d'agent : une exécution d'agent planifiée, visible dans le produit à côté des autres routines de l'utilisateur, avec un bouton "Lancer maintenant" et des instructions que l'utilisateur peut éditer en langage naturel. La différence n'est pas cosmétique. Un cron job, c'est de l'infrastructure invisible que seuls les développeurs peuvent changer. Une routine, c'est quelque chose que les utilisateurs possèdent : ils peuvent la voir, la mettre en pause, la reprogrammer, ou lui dire "inclus le week-end dans le digest du lundi" sans ouvrir un ticket.

Ça a aussi changé notre économie. Comme la routine passe par le même scheduler et la même infrastructure de session d'agent que tout le reste, la prochaine notification planifiée est un nouveau tool, pas un nouveau système.

Décidez ce que l'agent n'a pas le droit de faire

Voici le problème de design dont personne ne vous prévient : un message poussé n'a pas d'humain dans la boucle au moment de la lecture. Dans un chat, un chiffre faux se fait contester au message suivant. Dans un canal Slack que le CFO lit avec son café, un montant de dépenses halluciné ne se fait pas contester. Il se fait capturer en screenshot, et votre fonctionnalité meurt.

L'architecture sépare donc les responsabilités de façon tranchée :

L'agent ne relaie jamais une métrique. Le tool qui poste re-récupère tout côté serveur au moment de l'envoi, et construit le message avec la même logique que celle qui affiche les cartes du dashboard. On appelle ça la garantie "Slack égale dashboard" : tout chiffre dans le message est, par construction, celui que l'utilisateur verrait dans le produit.

La liberté créative de l'agent est cantonnée à un seul endroit : une courte phrase d'intro, alimentée par un tool de lecture seule séparé. Il peut dire "journée difficile pour les créations vidéo" ; il ne peut physiquement pas inventer les chiffres en dessous. La même leçon que dans mon article MCP, poussée plus loin : un tool est une interface pour un moteur de raisonnement, et parfois le travail de l'interface, c'est de retirer le stylo.

Une dernière frontière qui mérite d'être volée : le canal Slack est injecté par le système depuis la configuration du workspace. Ce n'est pas un paramètre du tool. Un agent qui ne peut pas choisir sa destination est un agent qu'aucune injection de prompt ne peut détourner.

Les surfaces de push ne pardonnent pas

Les échecs du chat sont conversationnels : l'utilisateur voit l'erreur et réessaie. Les échecs du push sont silencieux, ou pire, dupliqués. Deux règles en ont découlé :

Ne réessayer que si rien n'est parti. Une exécution planifiée qui plante en plein envoi ne doit pas réessayer aveuglément, sinon le canal reçoit le digest deux fois. Le flux d'envoi n'est sûr à réessayer que jusqu'au premier message délivré ; au-delà, les échecs se loggent et s'arrêtent.

Pas de digest vaut mieux qu'un digest faux. Si la plateforme publicitaire est déconnectée, ou si la donnée n'a jamais fini de se synchroniser, l'exécution passe son tour et logge. Elle ne poste pas un message à moitié vide à 9 heures en laissant les utilisateurs deviner si c'est le produit qui est cassé ou leurs campagnes.

Le digest de 9 heures qui arrivait à 11 heures

La war story. Un utilisateur configure "tous les jours à 9h00" et reçoit le message à 11h00. Cause racine : l'expression cron était parsée en UTC, point final. Le libellé de timezone dans l'interface était cosmétique ; jamais persisté, jamais appliqué. Pour un utilisateur en UTC+2, 9h00 devenait 11h00.

Le correctif était sans gloire : stocker une timezone IANA sur chaque tâche, parser le cron avec, capturer la timezone du navigateur quand l'utilisateur enregistre l'horaire. La partie intéressante, c'est la coupe de périmètre assumée : le jour du rapport ("hier") reste en UTC, parce qu'il doit correspondre à la convention de dates du dashboard. L'heure d'envoi est locale ; la fenêtre de données ne l'est pas. Déplacer l'un sans l'autre casserait en silence la garantie que le message correspond au produit.

Les agents planifiés héritent de tous les bugs ennuyeux que les systèmes cron ont jamais eus, plus quelques nouveaux. Vos utilisateurs les découvriront à neuf heures plus deux.

Le chat devient la télécommande

Rien de tout ça ne rend le chat obsolète. Ça le rétrograde. Le chat, c'est là où les routines se créent et s'éditent ("envoie-moi ça chaque matin, trié par dépenses"), et il y excelle. La livraison se passe ailleurs, à heure fixe, avec les chiffres garantis.

Si vous construisez des fonctionnalités agent, voici l'exercice : trouvez le dashboard que vos utilisateurs consultent chaque matin, et livrez-le-leur à la place. Puis dépensez votre effort de design là où ça compte, sur tout ce que l'agent n'a pas le droit de faire.