Agents de polling dans les assistants IA : 11 modèles d'implémentation

Les agents de sondage (polling agents) font partie des éléments les moins glorieux de l’architecture des assistants IA, mais ils sont aussi parmi les plus utiles.

Un assistant de chat classique attend que l’utilisateur pose une question. Un agent de sondage surveille en continu. Il vérifie une source, note les changements, décide s’il y a lieu d’agir, puis agit. Cette action peut être une notification, un résumé, un brouillon, un appel d’outil ou un workflow complet.

C’est ainsi qu’un assistant passe de « réponds à ma question » à « garde un œil sur ceci pour moi ». Au lieu d’être réactif, il devient un processus en arrière-plan qui remarque les événements au nom de l’utilisateur et agit lorsque les conditions sont remplies.

Le point de conception important est simple : ne pas rendre le modèle de langage responsable du temps, de l’état, des tentatives de reprise (retries) ou du verrouillage. Utilisez l’infrastructure backend classique pour cela. Utilisez le modèle là où il apporte de la valeur : interpréter un contexte complexe, prendre des jugements sémantiques et produire un langage utile.

Qu’est-ce qu’un agent de sondage ?

Un agent de sondage est un processus en arrière-plan qui vérifie régulièrement une source et déclenche une action de l’assistant lorsqu’une condition est remplie. Dans la stack plus large des Systèmes IA — où l’assistant combine un LLM, la mémoire, les outils, le routage et l’observabilité — la couche de sondage est ce qui rend l’assistant proactif plutôt que purement réactif. Pour voir le tableau complet des cinq couches, consultez Architecture des assistants IA : LLM, Mémoire, Outils, Routage, Observabilité.

Exemples :

• Vérifier une boîte de réception chaque matin et résumer les messages importants.
• Surveiller une liste de tâches Notion et exécuter l’élément « à faire » suivant.
• Surveiller une issue GitHub jusqu’à ce qu’elle change de statut.
• Sonder un travail IA longue durée jusqu’à ce que le résultat soit prêt.
• Vérifier la disponibilité d’un créneau de réservation jusqu’à ce qu’un créneau se libère.
• Surveiller un portail fournisseur jusqu’à ce qu’un document apparaisse.
• Scanner de nouveaux articles de recherche une fois par semaine et résumer ceux qui sont pertinents.

Un agent de sondage pratique a cinq responsabilités :

1. Se réveiller au bon moment.
2. Lire depuis la source.
3. Se souvenir de ce qu’il a déjà vu.
4. Décider si le nouvel état est important.
5. Agir une fois, en toute sécurité, sans se répéter.

Un flux de production typique ressemble à ceci :

planificateur (scheduler)
  -> travailleur de sondage (polling worker)
  -> système source
  -> stockage d'état (state store)
  -> filtres déterministes
  -> évaluation LLM optionnelle
  -> action de l'assistant

Cette structure est ennuyeuse de la meilleure manière possible. Les systèmes ennuyeux sont plus faciles à déboguer à 2 heures du matin.

L’état dont chaque agent de sondage a besoin

Les agents de sondage ont besoin d’un état durable. L’historique de la conversation ne suffit pas. L’assistant peut se souvenir de la conversation, mais le système a besoin d’un enregistrement opérationnel fiable.

Un bon enregistrement d’état de sondage contient généralement :

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "prendre une tâche en état Todo et l'exécuter",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "curseur_ou_timestamp",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

Le schéma exact dépend de la source, mais la plupart des systèmes ont besoin de ces concepts.

Définition du sondage

Cela décrit ce que l’agent surveille et pourquoi.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Par exemple :

source_type: notion
source_ref: base de données Tâches
condition_text: Trouver une tâche Todo, la prendre en charge, l'exécuter, la marquer comme Terminée.

Planification (Schedule)

Cela décrit quand l’agent doit s’exécuter.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Pour un agent Hermes qui vérifie Notion toutes les 10 minutes :

interval_seconds: 600
timezone: Australia/Melbourne

Curseur ou Snapshot

Cela aide l’agent à éviter de retraiter les mêmes données.

Selon la source, cela peut être :

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Pour une file d’attente de tâches Notion, le curseur peut être moins important que le statut de la tâche et les champs de prise en charge (claim). Pour Gmail, GitHub ou une API de synchronisation, le curseur est généralement critique.

Réclamation ou Bail (Claim or Lease)

Cela empêche deux travailleurs de prendre le même travail.

claimed_by
claimed_at
claim_expires_at
run_id

Par exemple, une tâche Notion peut passer de :

Statut: Todo

à :

Statut: InProgress
ClaimedBy: hermes
ClaimedAt: 2026-06-19T01:00:00Z
ClaimExpiresAt: 2026-06-19T01:30:00Z
RunId: run_789

C’est la différence entre « j’espère qu’un seul travailleur la prendra » et « le système a un protocole de réclamation ».

Enregistrement d’exécution

Cela enregistre ce qui s’est passé pendant une exécution.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

L’enregistrement d’exécution doit vivre dans le backend de l’assistant, pas seulement dans Notion ou un autre outil externe. Notion est bon pour la visibilité humaine. Il n’est pas idéal comme seul journal d’exécution.

Enregistrement de déduplication

Cela empêche les notifications en double ou les actions répétées.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Par exemple :

user_456:poll_123:notion_page_999:execute:v1

Si la même action est essayée à nouveau, le système peut la supprimer.

Méthode 1 : Travailleur de sondage planifié

C’est le modèle le plus simple et le plus fiable.

Un planificateur se réveille à intervalles fixes et appelle un travailleur. Le travailleur lit la source, met à jour l’état et déclenche une action de l’assistant si nécessaire.

planificateur
  -> travailleur
  -> API source
  -> base de données
  -> action de l'assistant

Comment cela fonctionne

Le planificateur est responsable du temps. Il peut s’agir d’un cron, d’un planificateur cloud, d’un CronJob Kubernetes ou d’un petit planificateur interne.

À chaque intervalle, il démarre une exécution du travailleur. Le travailleur charge sa configuration, interroge la source cible, compare le résultat avec l’état stocké et agit si nécessaire.

Pour un assistant simple, cela est souvent suffisant. Un seul planificateur et un processus de travailleur léger peuvent gérer des dizaines de vérifications quotidiennes sans nécessiter de files d’attente, de baillis ou de coordination distribuée.

Modèle d’état

Le planificateur stocke très peu de données. Habituellement, il ne sait que quand déclencher un travail.

La base de données de l’application stocke l’état important :

définition du sondage
planification
curseur ou snapshot
heure de dernière exécution
compteur d'échecs
statut

Le travailleur doit être sans état (stateless). Il peut contenir des données temporaires pendant l’exécution, mais la vérité durable appartient à la base de données.

Exemple de flux

Toutes les 10 minutes:
  déclencher le travailleur de sondage Hermes

Travailleur:
  charger la configuration du sondage actif
  interroger la source
  comparer avec l'état précédent
  exécuter les vérifications déterministes
  appeler le LLM seulement si nécessaire
  mettre à jour l'état
  émettre un événement de l'assistant

Meilleure adéquation

Utilisez les travailleurs de sondage planifiés pour :

• Résumés quotidiens.
• Vérifications horaires.
• Petites automatisations internes.
• Tâches simples de « surveillance ».
• Travaux d’assistant à faible ou moyenne intensité.

Faiblesses

Le sondage planifié est facile à comprendre, mais il peut devenir fragile à grande échelle. Si de nombreux sondages s’exécutent simultanément, vous pouvez surcharger vos travailleurs ou atteindre les limites de taux des fournisseurs. Les tentatives de reprise peuvent également devenir désordonnées si le planificateur démarre directement le travail.

Méthode 2 : Travailleurs de sondage basés sur une file d’attente

Le sondage basé sur une file d’attente est généralement le meilleur choix par défaut pour les assistants IA en production.

Le planificateur n’exécute pas directement le sondage. Il met un travail dans une file d’attente. Les processus travailleurs consomment les travaux de la file d’attente.

planificateur
  -> file d'attente
  -> pool de travailleurs
  -> API source
  -> stockage d'état
  -> action de l'assistant

Comment cela fonctionne

Un planificateur scanne les sondages dus et met en file d’attente les travaux. Les travailleurs extraient les travaux lorsqu’ils ont de la capacité.

Cela vous donne une contre-pression (backpressure). Si le système est occupé, les travaux attendent dans la file d’attente au lieu de submerger l’API source ou le fournisseur LLM.

Modèle d’état

La base de données stocke l’état du sondage :

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Le message de la file d’attente doit rester petit :

{
  "poll_id": "poll_123",
  "scheduled_for": "2026-06-19T01:10:00Z",
  "attempt": 1
}

Le travailleur charge l’état complet depuis la base de données au démarrage.

Exemple de flux

Toutes les minutes:
  le planificateur trouve les sondages où next_run_at <= maintenant
  le planificateur met les travaux en file d'attente

Travailleurs:
  extraire les travaux de la file d'attente
  verrouiller ou prendre bail sur le sondage
  interroger la source
  mettre à jour l'état
  émettre une action de l'assistant si nécessaire
  définir next_run_at

Meilleure adéquation

Utilisez le sondage basé sur une file d’attente pour :

• Assistants IA multi-utilisateurs.
• De nombreux sondages simultanés.
• Intégrations avec des limites de taux.
• Travaux en arrière-plan réessayables.
• Travaux qui peuvent prendre des durées différentes.
• Produits SaaS où la fiabilité est importante.

Faiblesses

Les files d’attente ajoutent de l’infrastructure. Vous avez besoin de la gestion des lettres mortes (dead letter), de l’idempotence, des délais de visibilité et des politiques de reprise. Cela en vaut la peine pour les systèmes de production, mais probablement excessif pour un petit prototype.

Méthode 3 : Outil externe comme file d’attente de tâches

C’est le modèle de l’exemple Notion plus Hermes.

L’outil externe n’est pas seulement une source de données. Il devient la file d’attente de tâches visible par l’humain. L’agent vérifie périodiquement l’outil, prend une tâche, l’exécute et met à jour le statut de la tâche.

planificateur
  -> travailleur Hermes
  -> base de données Notion
  -> prendre une tâche
  -> exécuter la tâche
  -> mettre à jour le statut Notion

Comment cela fonctionne

Toutes les 10 minutes, Hermes interroge la base de données Notion pour une tâche en état Todo. Il choisit la prochaine tâche, généralement par priorité et heure de création. Ensuite, il prend la tâche en charge en la passant à InProgress.

Après cela, Hermes exécute la tâche. Si l’exécution réussit, il marque la tâche comme Complete. Si l’exécution échoue, il marque la tâche comme Failed ou la retourne à Todo avec un compteur de reprise.

Modèle d’état

Notion stocke l’état de la tâche visible par l’humain :

Titre
Description
Statut: Todo | InProgress | Complete | Failed
Priorité
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Le backend Hermes stocke l’état d’exécution opérationnel :

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Cette séparation est importante. Notion est excellent pour la visibilité et l’édition manuelle. Le backend Hermes est meilleur pour les journaux, les reprises, la déduplication et l’historique d’audit.

Exemple de flux

Toutes les 10 minutes:
  Hermes se réveille

Hermes:
  interroger Notion pour une tâche où Statut = Todo
  trier par Priorité, CreatedAt
  mettre à jour la tâche sélectionnée à InProgress
  définir ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  exécuter la tâche
  écrire le journal d'exécution
  passer la tâche à Complete ou Failed

Meilleure adéquation

Utilisez ce modèle lorsque :

• Les humains gèrent déjà le travail dans Notion, Jira, Linear, Trello ou un autre outil.
• Vous voulez que l’assistant traite des tâches visibles.
• Le tableau de tâches est l’interface utilisateur.
• Vous avez besoin d’un modèle d’automatisation simple avec boucle humaine.

Faiblesses

Les outils externes sont rarement des files d’attente parfaites. Les réclamations atomiques peuvent être limitées. La cohérence des requêtes peut être en retard. Des limites de taux peuvent s’appliquer. Si l’agent peut s’exécuter sur plusieurs instances, vous avez besoin d’une stratégie de réclamation ou de bail soigneuse.

La recommandation pratique est d’utiliser Notion comme boîte de réception de tâches pour les humains tout en conservant tous les journaux d’exécution, les enregistrements de reprise, les traces et les clés d’idempotence dans Hermes. Notion donne aux utilisateurs de la visibilité ; Hermes maintient le système fiable. Pour les mécaniques de dispatcher et de concurrence qui se trouvent derrière ce modèle dans Hermes, consultez Kanban dans l’Agent Hermes pour les Workflows LLM Auto-Hébergés.

Méthode 4 : Boucle de travail longue durée

Une boucle longue durée est l’implémentation la plus simple.

while True:
    due_polls = db.find_due_polls()
    for poll in due_polls:
        run_poll(poll)
    sleep(30)

Ce modèle combine la planification et l’exécution dans un seul service, ce qui en fait le point de départ le plus simple possible pour le travail des agents en arrière-plan.

Comment cela fonctionne

Le processus travailleur s’exécute en continu. Toutes les quelques secondes ou minutes, il vérifie la base de données pour les sondages dus et les exécute. C’est facile à construire, facile à raisonner et rapide à itérer pendant le développement.

Modèle d’état

La base de données stocke toujours l’état durable :

configuration du sondage
next_run_at
cursor
dernier résultat
compteur d'échecs
statut

La mémoire du processus ne doit contenir que l’état temporaire :

batch actuel
cache éphémère
exécution en cours

Ne stockez jamais le progrès important uniquement en mémoire. Si le processus plante, tout état qui n’a pas été écrit dans le stockage durable est perdu, et la prochaine exécution n’aura aucun moyen de savoir où les choses avaient été laissées.

Meilleure adéquation

Utilisez les boucles longues durées pour :

• Prototypes.
• Développement local.
• Outils internes.
• Systèmes mono-locataire.
• Agents à faible volume.

Faiblesses

Ce modèle devient risqué avec plusieurs réplicas. Sans baillis, deux travailleurs peuvent exécuter le même sondage. Il manque également les fonctionnalités opérationnelles d’une vraie file d’attente ou d’un moteur de workflow.

Une boucle longue durée n’est pas fausse comme point de départ, mais ce n’est pas un planificateur distribué et ne doit pas être traité comme tel. Dès que vous avez besoin de plusieurs réplicas ou de garanties de fiabilité plus fortes, vous devrez passer à l’un des modèles plus structurés ci-dessus.

Méthode 5 : Webhook en premier avec rebond sur sondage

Si la source prend en charge les webhooks, utilisez-les. Le sondage devrait souvent être la sauvegarde, pas le mécanisme principal.

système externe
  -> point de terminaison webhook
  -> stockage d'événements
  -> action de l'assistant

sondage de réconciliation
  -> API source
  -> comparer avec le stockage d'événements
  -> réparer les événements manqués

Comment cela fonctionne

Le système externe envoie des événements à votre point de terminaison webhook lorsque quelque chose change. Votre système stocke l’événement et le traite de manière asynchrone.

Un sondage de réconciliation plus lent s’exécute toutes les quelques heures ou une fois par jour. Il vérifie si des événements ont été manqués.

Modèle d’état

Le stockage d’événements enregistre les webhooks entrants :

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Le sondage de réconciliation stocke :

last_reconciliation_at
last_seen_cursor
last_seen_version

La table des objets source stocke le dernier état connu :

external_id
current_status
external_updated_at
last_processed_event_id

Meilleure adéquation

Utilisez l’architecture webhook en premier pour :

• Événements GitHub.
• Événements Stripe.
• Événements Slack.
• Mises à jour CRM.
• Notifications de déploiement.
• Systèmes de ticketing.

Faiblesses

Les webhooks nécessitent un point de terminaison public, une validation de signature, une protection contre les rejeux et la déduplication d’événements. Certains fournisseurs envoient également des événements incomplets, vous devrez peut-être toujours récupérer l’objet complet.

Même ainsi, si de bons webhooks existent, sonder chaque minute est généralement un gaspillage.

Méthode 6 : Sondage des travaux en arrière-plan côté fournisseur

Parfois, ce qui est sondé est le travail IA lui-même.

L’application démarre un travail longue durée du fournisseur, stocke l’ID du travail et vérifie plus tard s’il est terminé.

app
  -> démarrer le travail IA en arrière-plan
  -> stocker l'ID du travail fournisseur
  -> sonder le statut
  -> récupérer le résultat
  -> notifier l'utilisateur

Comment cela fonctionne

L’assistant démarre un travail avec le fournisseur. Le fournisseur retourne un ID. Votre backend stocke cet ID et vérifie son statut jusqu’à ce que le travail réussisse, échoue, expire ou dépasse le délai d’attente.

Modèle d’état

Votre backend stocke :

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Le fournisseur stocke l’état temporaire du travail et la sortie.

Si la sortie est importante, copiez-la dans votre propre stockage durable dès que le travail est terminé. Le stockage des résultats côté fournisseur a des fenêtres de rétention courtes et ne remplace pas une archive appropriée dans votre propre système.

Meilleure adéquation

Utilisez le sondage des travaux en arrière-plan côté fournisseur pour :

• Tâches de recherche IA longues.
• Traitement de grands documents.
• Analyse de codebase.
• Génération de rapports.
• Travaux d’extraction de données.
• Tâches qui dépassent les délais d’attente HTTP normaux.

Faiblesses

Ce modèle résout un problème : attendre un travail longue durée du fournisseur. Il ne remplace pas votre moteur de workflow, planificateur, file d’attente ou magasin d’état métier.

Méthode 7 : Moteur de workflow durable

Un moteur de workflow durable gère l’exécution longue durée, les minuteries, les reprises et la récupération. Temporal est le choix le plus courant pour les backends d’assistants basés sur Go et Python ; pour un guide d’implémentation complet, consultez Implémentation d’applications de workflow avec Temporal en Go.

Au lieu de câbler manuellement chaque attente et reprise, vous modélisez le processus comme un workflow.

moteur de workflow
  -> activité: vérifier la source
  -> minuterie: attendre
  -> activité: évaluer le résultat
  -> activité: notifier l'utilisateur

Comment cela fonctionne

Le workflow démarre une fois et contrôle ensuite ses propres attentes. Il peut dormir pendant des minutes, des jours ou des semaines. Si le processus travailleur plante, le moteur de workflow peut reprendre à partir de l’état enregistré.

Modèle d’état

Le moteur de workflow stocke :

workflow_id
historique d'exécution
état de la minuterie
tentatives d'activité
politique de reprise
état actuel du workflow

Votre base de données d’application stocke :

définition du sondage visible par l'utilisateur
références d'autorisation
enregistrements métier
enregistrements de notification

Le moteur de workflow possède l’état du processus — historique d’exécution, minuteries, reprises et tentatives d’activité. Votre base de données possède l’état métier — configurations utilisateur, enregistrements d’autorisation, notifications et journaux d’audit. Garder ces deux éléments séparés empêche chaque couche de devenir un hybride confus des deux.

Meilleure adéquation

Utilisez les workflows durables pour :

• Processus métier multi-étapes.
• Automatisations longues durées.
• Flux d’approbation humaine.
• Reprises fiables.
• Travail en arrière-plan auditable.
• Processus qui doivent reprendre après un échec.

Faiblesses

Les moteurs de workflow ajoutent des concepts et de l’infrastructure. Ils sont excellents lorsque le processus est important, mais lourds pour des vérifications horaires simples.

Méthode 8 : Runtime d’agent persistant

Certains frameworks d’agents peuvent persister l’état de l’agent, faire des points de contrôle d’exécution et reprendre plus tard.

C’est utile lorsque l’agent lui-même a un processus de raisonnement multi-étapes.

planificateur ou workflow
  -> runtime de l'agent
  -> charger le point de contrôle
  -> appeler les outils
  -> sauvegarder le point de contrôle
  -> reprendre plus tard

Comment cela fonctionne

Un planificateur externe ou un workflow démarre l’agent. Le runtime de l’agent charge l’état précédent, exécute la prochaine étape, appelle les outils si nécessaire et écrit un point de contrôle.

Le runtime de l’agent ne doit pas être votre seul planificateur. Il est mieux traité comme la couche de raisonnement à l’intérieur d’une architecture backend plus large.

Modèle d’état

Le stockage des points de contrôle de l’agent contient :

nœud actuel
messages
sorties d'outils
état de raisonnement intermédiaire
action en attente

La mémoire à long terme contient :

préférences stables de l'utilisateur
faits
contexte du projet
références de source

L’état opérationnel appartient toujours ailleurs :

planification du sondage
curseur
statut
compteur de reprise
enregistrements de déduplication

Une règle utile : la mémoire n’est pas un curseur, et un point de contrôle n’est pas une file d’attente. La mémoire de l’agent stocke ce que le modèle sait ; l’état opérationnel suit où se trouve le processus et ce qu’il a fait. Confondre les deux conduit à des bogues subtils qui n’apparaissent qu’en cas de concurrence ou après un redémarrage. L’espace de conception complet pour la mémoire de travail, l’état durable et les couches de récupération est couvert dans Systèmes de mémoire dans les assistants IA.

Meilleure adéquation

Utilisez le runtime d’agent persistant pour :

• Recherche multi-étapes.
• Agents qui mettent en pause et reprennent.
• Travail avec boucle humaine.
• Raisonnement lourd en outils.
• Tâches où le contexte s’accumule au fil du temps.

Faiblesses

La persistance de l’agent n’est pas la même chose que la fiabilité opérationnelle. Vous avez toujours besoin de planification, de verrouillage, de reprises, de limites de taux et de journaux d’audit.

Méthode 9 : Synchronisation de base de données plus évaluation des changements

Dans ce modèle, le sondage est utilisé pour synchroniser les données externes dans votre propre base de données. L’assistant réagit ensuite aux changements locaux de la base de données plutôt que d’interroger les API externes directement à chaque cycle d’évaluation.

sondeur de synchronisation
  -> API externe
  -> base de données locale
  -> évaluateur de changement
  -> action de l'assistant

Cela sépare la synchronisation des données de l’intelligence de l’assistant. Le travailleur de synchronisation est responsable du maintien des enregistrements locaux à jour ; l’évaluateur est responsable de décider quoi faire face aux changements. Chaque couche peut être testée, surveillée et mise à l’échelle indépendamment.

Comment cela fonctionne

Le travailleur de synchronisation récupère périodiquement les changements externes et écrit des enregistrements normalisés dans votre base de données. Un second travailleur ou un flux de changements détecte les lignes mises à jour et décide si l’assistant doit agir.

Modèle d’état

La table de synchronisation stocke :

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

L’état de synchronisation stocke :

source_cursor
last_sync_at
rate_limit_status
failure_count

La table d’évaluation de l’assistant stocke :

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Meilleure adéquation

Utilisez ce modèle pour :

• Synchronisation CRM.
• Systèmes de ticketing.
• Documents comptables.
• Inventaire de produits.
• Revue de conformité.
• Indexation de recherche.
• Tableaux de bord internes.

Faiblesses

Synchroniser tout peut être coûteux et inutile. Cela peut également créer des obligations de confidentialité et de rétention. Utilisez ce modèle lorsque les données locales ont une valeur au-delà d’une seule action de l’assistant.

Méthode 10 : Sondage adaptatif

Le sondage adaptatif change de fréquence en fonction de l’état, de l’urgence ou de l’activité récente.

objet actif: sonder toutes les 1 minute
objet en attente: sonder toutes les 1 heure
objet périmé: sonder une fois par jour
objet terminé: arrêter le sondage

Comment cela fonctionne

Après chaque exécution, le travailleur décide quand la prochaine exécution doit avoir lieu.

Si l’objet a changé récemment, sondez plus tôt. Si rien n’a changé depuis longtemps, ralentissez. Si la tâche est terminée, arrêtez.

Modèle d’état

L’état du sondage inclut :

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Le snapshot de la source inclut :

status
updated_at
activity_level
expected_next_change

Meilleure adéquation

Utilisez le sondage adaptatif pour :

• Statut de déploiement.
• Suivi de livraison.
• Disponibilité des créneaux de calendrier.
• Surveillance des prix.
• Travaux de build.
• Tâches longue durée des fournisseurs.
• Toute source avec des mises à jour par rafales.

Faiblesses

Le sondage adaptatif peut être plus difficile à raisonner. Si une tâche doit s’exécuter à une heure stricte, gardez-la stricte. Ne rendez pas les tâches de conformité « intelligentes ».

Méthode 11 : Sondage sémantique avec un évaluateur LLM

Le sondage sémantique est utilisé lorsque la condition est floue.

Le code peut répondre :

Le statut est-il égal à Terminé ?
Le prix est-il inférieur à 100 ?
Y a-t-il un nouveau message ?

Un LLM peut aider à répondre :

Cet e-mail semble-t-il urgent ?
Ce client est-il probablement mécontent ?
Cet article de recherche est-il pertinent ?
Ce changement nécessite-t-il mon attention ?

Comment cela fonctionne

Le travailleur applique d’abord des filtres déterministes bon marché. Seuls les éléments candidats vont au LLM.

nouvel élément ?
correspond aux filtres de source ?
pas déjà traité ?
pas visiblement non pertinent ?

Ensuite, le LLM évalue l’ensemble de candidats plus petit et retourne une sortie structurée.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Le client signale une panne de production."
}

Modèle d’état

La définition du sondage stocke :

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Le journal d’évaluation stocke :

input_reference
model
prompt_version
structured_output
confidence
cost
latency

L’état du sondage stocke :

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Meilleure adéquation

Utilisez le sondage sémantique pour :

• Détection des e-mails importants.
• Surveillance du sentiment client.
• Alertes de recherche.
• Détection des opportunités de vente.
• Triage de sécurité.
• Briefings exécutifs.

Faiblesses

Les appels LLM coûtent de l’argent et ajoutent de la latence. Ils peuvent également être incohérents si les invites et les schémas sont lâches. Utilisez des filtres déterministes en premier. Demandez au modèle uniquement lorsque le jugement est réellement nécessaire.

Tableau de décision : Choisir une méthode d’agent de sondage

Architecture par défaut recommandée

Pour la plupart des assistants IA de production, commencez par ceci :

table des sondages
  -> planificateur
  -> file d'attente
  -> travailleurs sans état
  -> filtres déterministes
  -> évaluateur LLM optionnel
  -> notification ou action de l'assistant

Un schéma minimal :

CREATE TABLE polls (
    id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    source_type TEXT NOT NULL,
    source_ref TEXT NOT NULL,
    condition_text TEXT NOT NULL,
    schedule_type TEXT NOT NULL,
    interval_seconds INTEGER,
    timezone TEXT,
    next_run_at TIMESTAMP NOT NULL,
    last_run_at TIMESTAMP,
    cursor_value TEXT,
    last_hash TEXT,
    status TEXT NOT NULL,
    failure_count INTEGER NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE poll_runs (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    started_at TIMESTAMP NOT NULL,
    finished_at TIMESTAMP,
    status TEXT NOT NULL,
    items_checked INTEGER,
    items_matched INTEGER,
    decision_summary TEXT,
    error TEXT
);

CREATE TABLE notifications (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    user_id TEXT NOT NULL,
    dedupe_key TEXT NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    delivered_at TIMESTAMP,
    UNIQUE (dedupe_key)
);

Cela vous donne une séparation propre :

le planificateur possède le temps
la file d'attente possède la mise en tampon
le travailleur possède l'exécution
la base de données possède l'état
le LLM possède le jugement sémantique
l'assistant possède l'interaction utilisateur

Cette séparation est le cœur d’un agent de sondage fiable.

Exemple : Agent Hermes traitant des tâches Notion

Appliquons maintenant l’architecture à un cas concret.

Supposons qu’une base de données Notion contient des tâches. Hermes doit s’exécuter toutes les 10 minutes, prendre une tâche en état Todo, la passer à InProgress, l’exécuter, puis la marquer Complete.

Cela est mieux décrit comme :

outil externe comme file d'attente de tâches
+
travailleur de sondage planifié
+
exécution basée sur la réclamation ou le bail

Pour une version de production, cela devient :

sondage basé sur une file d'attente avec Notion comme boîte de réception de tâches pour les humains

Propriétés des tâches Notion

La base de données Notion doit contenir des champs comme :

Nom
Statut: Todo | InProgress | Complete | Failed
Priorité
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Les champs importants sont ClaimedAt, ClaimExpiresAt et RunId. Ils rendent la réclamation de la tâche visible et récupérable.

État d’exécution Hermes

Hermes doit également conserver son propre enregistrement d’exécution :

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Cela vous protège si Notion est modifié manuellement, si un appel API échoue, ou si vous devez auditer ce que Hermes a réellement fait.

Flux d’exécution

Toutes les 10 minutes:
  le planificateur Hermes crée une exécution

Travailleur Hermes:
  trouve une tâche Notion où Statut = Todo
  trie par Priorité et CreatedAt
  prend la tâche en charge en définissant Statut = InProgress
  écrit ClaimedBy, ClaimedAt, ClaimExpiresAt et RunId
  exécute la tâche
  écrit les journaux d'exécution dans le backend Hermes
  définit Statut Notion = Complete en cas de succès
  définit Statut Notion = Failed en cas d'échec

Si Hermes plante après avoir pris une tâche en charge, le bail peut expirer :

Statut = InProgress
ClaimExpiresAt < maintenant

Une exécution future peut alors récupérer la tâche ou la marquer comme échouée.

Gestion des erreurs

En cas de succès :

Statut = Complete
CompletedAt = maintenant
LastError = vide

En cas d’échec récupérable :

Statut = Todo
RetryCount = RetryCount + 1
LastError = message d'erreur court

En cas d’échec non récupérable :

Statut = Failed
LastError = explication claire

Pour la sécurité, Hermes doit également utiliser une clé d’idempotence :

notion_page_id + version_tâche + type_action

Cela empêche la même tâche d’être exécutée deux fois si une reprise a lieu au mauvais moment.

Pourquoi ce n’est pas juste du sondage

La partie sondage n’est que le mécanisme de réveil. La véritable architecture est la réclamation de tâches et l’exécution fiable.

Une implémentation naïve dit :

Toutes les 10 minutes, trouver une tâche Todo et l'exécuter.

Une implémentation fiable dit :

Toutes les 10 minutes, réclamer exactement une tâche éligible, enregistrer l'exécution, exécuter de manière idempotente et déplacer la tâche vers un état terminal.

C’est la différence entre une démo et un agent auquel vous pouvez faire confiance.

Erreurs courantes des agents de sondage

Erreur 1 : Aucun protocole de réclamation

Si deux travailleurs peuvent voir la même tâche, ils peuvent tous les deux l’exécuter.

Utilisez :

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Même si vous exécutez actuellement un seul travailleur, concevez comme si un second travailleur pouvait apparaître plus tard.

Erreur 2 : Aucune clé de déduplication

Chaque action externe doit avoir une clé de déduplication.

user_id + poll_id + source_object_id + action_type + condition_version

Cela empêche les notifications répétées, les e-mails répétés, l’exécution répétée de tâches et les appels d’outils répétés. Les principes plus larges derrière le périmètre, le stockage et le test de ces clés s’appliquent également ici — voir Idempotence dans les systèmes distribués qui fonctionne vraiment.

Erreur 3 : Appeler le LLM trop tôt

Ne demandez pas au modèle de faire le filtrage de base de données.

Mauvais :

Envoyer toutes les tâches au LLM et demander laquelle est Todo.

Mieux :

Utiliser le filtre de l'API Notion pour récupérer les tâches Todo.
Ensuite, utiliser le LLM uniquement si l'interprétation de la tâche est nécessaire.

Erreur 4 : Traiter Notion comme le seul backend

Notion est une bonne interface humaine. Ce n’est pas un backend d’exécution complet.

Conservez les journaux d’exécution, les reprises, les traces et les enregistrements d’idempotence dans Hermes.

Erreur 5 : Sondage infini

Chaque sondage doit avoir une condition d’arrêt.

Exemples :

arrêter après succès
arrêter après date
arrêter après nombre maximum de reprises
arrêter lorsque l'utilisateur le désactive
arrêter après échec d'autorisation répété

Un agent de sondage sans condition d’arrêt est une fuite de coûts silencieuse.

Erreur 6 : Aucune observabilité

Vous devez pouvoir répondre :

Que l'agent a-t-il exécuté ?
Pourquoi a-t-il exécuté ?
Qu'a-t-il lu ?
Qu'a-t-il changé ?
Pourquoi a-t-il échoué ?
A-t-il notifié l'utilisateur ?
A-t-il exécuté deux fois ?

Si vous ne pouvez pas répondre à ces questions, le système n’est pas prêt pour un travail important.

Liste de vérification d’observabilité

Suivez des métriques telles que :

polls_due
polls_started
polls_succeeded
polls_failed
tasks_claimed
tasks_completed
tasks_failed
claim_expired_count
duplicate_suppressed_count
llm_calls
llm_cost
rate_limit_count
average_run_duration

Journalisez des champs tels que :

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Construisez une vue administrateur pour :

sondages actifs
tâches bloquées en InProgress
échecs récents
tâches avec de nombreuses reprises
travaux de lettres mortes
évaluations LLM coûteuses
intégrations désactivées

Les agents de sondage s’exécutent en arrière-plan, où les échecs sont silencieux et les problèmes peuvent s’accumuler avant que quiconque ne les remarque. Les systèmes en arrière-plan ont besoin de visibilité intégrée dès le départ, pas ajoutée après coup lorsque quelque chose tourne mal. Pour la stack d’observabilité complète pour les systèmes IA et basés sur LLM — métriques, traces, journaux structurés et SLOs — consultez Observabilité pour les systèmes LLM : Métriques, Traces, Journaux et Tests en Production.

Recommandation finale

Pour un assistant IA sérieux, commencez par des travailleurs de sondage basés sur une file d’attente et un stockage d’état durable. Ajoutez des webhooks lorsque les fournisseurs les prennent en charge. Utilisez le sondage adaptatif lorsque les limites de taux sont importantes. Utilisez un moteur de workflow durable lorsque le processus est longue durée et multi-étapes. Utilisez le runtime d’agent persistant lorsque l’agent doit raisonner sur une période de temps.

Pour l’exemple Hermes et Notion, l’architecture correcte est :

Notion comme boîte de réception de tâches pour les humains
Planificateur Hermes toutes les 10 minutes
Travailleur Hermes avec logique de réclamation ou de bail
Backend Hermes pour les journaux d'exécution et l'idempotence
Mises à jour de statut Notion pour la visibilité

L’intervalle de sondage n’est pas la partie difficile. La partie difficile est de s’assurer que l’agent prend une tâche, l’exécute une fois, enregistre ce qui s’est passé et laisse le système dans un état que les humains peuvent comprendre.

C’est ce qui transforme un script de sondage en un assistant IA fiable — pas l’intervalle, pas le modèle, mais la discipline autour de la réclamation du travail, de son enregistrement et du maintien du système dans un état que les humains et les exécutions futures peuvent tous deux comprendre.