Agents de sondage dans les assistants IA : 11 modèles de mise en œuvre

Les agents de sondage (polling agents) font partie des aspects les moins glamour 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 reste vigilant. Il vérifie une source, détecte les changements, décide s’il y a quelque chose d’important, 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 » à « surveille cela pour moi ». Au lieu d’être réactif, il devient un processus en arrière-plan qui remarque les choses 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 ou du verrouillage. Utilisez l’infrastructure backend normale 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 pile 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 une vue complète de ces 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 la prochaine tâche à faire.
• Surveiller un problème GitHub jusqu’à ce qu’il change de statut.
• Sonder un travail IA de longue durée jusqu’à ce que le résultat soit prêt.
• Vérifier un créneau de réservation jusqu’à ce qu’un créneau soit disponible.
• Surveiller un portail fournisseur jusqu’à ce qu’un document apparaisse.
• Scanner de nouveaux articles de recherche chaque 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
  -> travailleur de sondage
  -> système source
  -> magasin d'état
  -> 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 registre 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": "actif"
}

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
priorité
statut

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

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

interval_seconds
expression_cron
fuseau_horaire
last_run_at
next_run_at
jitter

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

interval_seconds: 600
fuseau_horaire: Australia/Melbourne

Curseur ou instantané

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. Pour Gmail, GitHub ou une API de synchronisation, le curseur est généralement critique.

Réclamation ou bail

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 être modifiée 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 le prend » 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
statut
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 excellent pour la visibilité humaine. Ce 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 tenté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 il s’exécute

Le planificateur est responsable du temps. Cela peut être cron, un planificateur cloud, un CronJob Kubernetes ou un petit planificateur interne.

À chaque intervalle, il démarre une exécution de 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 suffit souvent. 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 baux ou de coordination distribuée.

Modèle d’état

Le planificateur stocke très peu. En général, 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 instantané
dernière heure d'exécution
compteur d'échecs
statut

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

Flux d’exemple

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

Meilleur usage

Utilisez les travailleurs de sondage planifiés pour :

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

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 du fournisseur. Les tentatives 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 de production.

Le planificateur n’exécute pas le sondage directement. 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
  -> magasin d'état
  -> action de l'assistant

Comment il s’exécute

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

Cela vous donne une contre-pression. 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
curseur
statut
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 lorsqu’il démarre.

Flux d’exemple

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

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

Meilleur usage

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 gestion des lettres mortes, d’idempotence, de délais de visibilité et de politiques de réessai. Cela 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 il s’exécute

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 réessai.

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
trace LLM
détails de l'erreur
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 réessais, la déduplication et l’historique d’audit.

Flux d’exemple

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
  définir la tâche à Complete ou Failed

Meilleur usage

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 intervention 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 visible par l’humain tout en conservant tous les journaux d’exécution, les enregistrements de réessai, les traces et les clés d’idempotence dans Hermes. Notion donne aux utilisateurs une visibilité ; Hermes maintient le système fiable. Pour le répartiteur et les mécaniques 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

Une boucle longue 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 d’agent en arrière-plan.

Comment il s’exécute

Le processus travailleur s’exécute continuellement. Toutes les quelques secondes ou minutes, il vérifie la base de données pour les sondages échéants 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 un état durable :

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

La mémoire du processus ne doit contenir que des états temporaires :

lot actuel
cache court terme
exécution en cours

Ne stockez jamais un 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 l’exécution suivante n’aura aucun moyen de savoir où les choses se sont arrêtées.

Meilleur usage

Utilisez les boucles longues pour :

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

Faiblesses

Ce modèle devient risqué avec plusieurs réplicas. Sans baux, 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 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 d’abord avec sondage de secours

Si la source prend en charge les webhooks, utilisez-les. Le sondage devrait souvent être le mécanisme de secours, pas le mécanisme principal. La même séparation apparaît dans la conception du protocole d’agent : les notifications push A2A réveillent un gestionnaire client, qui sonde ensuite GetTask pour l’état complet, comme décrit dans Streaming A2A et tâches asynchrones pour les workflows d’agents de longue durée.

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

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

Comment il s’exécute

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 magasin 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

Le tableau d’objets source stocke le dernier état connu :

external_id
current_status
external_updated_at
last_processed_event_id

Meilleur usage

Utilisez l’architecture webhook d’abord 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 rejoueurs et une déduplication d’événements. Certains fournisseurs envoient également des événements incomplets, vous devrez donc peut-être toujours récupérer l’objet complet.

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

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

Parfois, la chose sondée est le travail IA lui-même.

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

application
  -> démarrer un 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 il s’exécute

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.

Modèle d’état

Votre backend stocke :

assistant_task_id
provider_job_id
user_id
statut
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.

Meilleur usage

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

• Tâches de recherche IA de longue durée.
• Traitement de gros documents.
• Analyse de base de code.
• Génération de rapports.
• Travaux d’extraction de données.
• Tâches qui dépassent les délais de requête HTTP normaux.

Faiblesses

Ce modèle résout un problème : attendre un travail fournisseur long. 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 de longue durée, les minuteries, les réessais 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 réessai, 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 il s’exécute

Le workflow démarre une fois et contrôle ensuite son propre temps d’attente. 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 réessai
état actuel du workflow

Votre base de données d’application stocke :

définition de 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, réessais 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 éléments séparés empêche chaque couche de devenir un hybride confus des deux.

Meilleur usage

Utilisez des workflows durables pour :

• Processus métier en plusieurs étapes.
• Automatisations de longue durée.
• Flux d’approbation humaine.
• Réessais fiables.
• Travaux en arrière-plan auditable.
• Processus qui doivent reprendre après une défaillance.

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’agent peuvent persister l’état de l’agent, faire un point de contrôle de l’exécution et reprendre plus tard.

Cela est utile lorsque l’agent lui-même a un processus de raisonnement en plusieurs é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 il s’exécute

Un planificateur externe ou un workflow démarre l’agent. Le runtime de l’agent charge l’état précédent, exécute l’étape suivante, 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'outil
état de raisonnement intermédiaire
action en attente

La mémoire à long terme contient :

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

L’état opérationnel appartient toujours ailleurs :

planification du sondage
curseur
statut
compteur de réessai
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 bugs 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.

Meilleur usage

Utilisez un runtime d’agent persistant pour :

• Recherche en plusieurs étapes.
• Agents qui se mettent en pause et reprennent.
• Travail avec intervention humaine.
• Raisonnement intensif en outils.
• Tâches où le contexte s’accumule avec le temps.

Faiblesses

La persistance de l’agent n’est pas la même que la fiabilité opérationnelle. Vous avez toujours besoin de planification, de verrouillage, de réessais, 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 des données externes dans votre propre base de données. L’assistant réagit ensuite aux changements de la base de données locale plutôt qu’à interroger directement les API externes à chaque cycle d’évaluation.

poller 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 la décision sur ce qu’il faut faire face aux changements. Chaque couche peut être testée, surveillée et mise à l’échelle indépendamment.

Comment il s’exécute

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 deuxième travailleur ou un flux de changements détecte les lignes mises à jour et décide si l’assistant doit agir.

Modèle d’état

Le tableau 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

Le tableau d’évaluation de l’assistant stocke :

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Meilleur usage

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 il s’exécute

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
priorité
stop_condition

L’instantané de la source inclut :

statut
updated_at
activity_level
expected_next_change

Meilleur usage

Utilisez le sondage adaptatif pour :

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

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 susceptible d'être mécontent ?
Cet article de recherche est-il pertinent ?
Ce changement nécessite-t-il mon attention ?

Comment il s’exécute

Le travailleur applique d’abord des filtres déterministes peu coûteux. Seuls les éléments candidats vont au LLM.

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

Ensuite, le LLM évalue l’ensemble candidat 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

Meilleur usage

Utilisez le sondage sémantique pour :

• Détection d’e-mails importants.
• Surveillance du sentiment client.
• Alertes de recherche.
• Détection d’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 d’abord des filtres déterministes. Demandez au modèle uniquement lorsque le jugement est vraiment 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 :

tableau 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 le 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 devrait 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 visible par l'humain

Propriétés des tâches Notion

La base de données Notion devrait 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 devrait également conserver son propre enregistrement d’exécution :

run_id
notion_page_id
started_at
finished_at
statut
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 qu’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 = court message d'erreur

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

Statut = Failed
LastError = explication claire

Pour plus de sécurité, Hermes devrait également utiliser une clé d’idempotence :

notion_page_id + task_version + action_type

Cela empêche la même tâche d’être exécutée deux fois si un réessai se produit au mauvais moment.

Pourquoi ce n’est pas juste du sondage

La partie sondage n’est que le mécanisme de réveil. La vraie 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 la faire.

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 en qui vous pouvez avoir 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 deuxième travailleur pouvait apparaître plus tard.

Erreur 2 : Aucune clé de déduplication

Toute 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 de tâches répétée et les appels d’outil répétés. Les principes plus larges derrière le scope, 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 du filtrage de base de données.

Mauvais :

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

Meilleur :

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 réessais, 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 le succès
arrêter après la date
arrêter après le nombre maximum de réessais
arrêter lorsque l'utilisateur le désactive
arrêter après une défaillance d'autorisation répétée

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

Erreur 6 : Aucune observabilité

Vous devriez 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 contrôle 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 InProgress
échecs récents
tâches avec nombre élevé de réessais
travaux de lettre morte
évaluations LLM coûteuses
intégrations désactivées

Les agents de sondage s’exécutent en arrière-plan, où les défaillances sont silencieuses et les problèmes peuvent s’accumuler avant que quelqu’un ne remarque. Les systèmes en arrière-plan ont besoin de visibilité intégrée dès le début, pas ajoutée a posteriori lorsque quelque chose va mal. Pour la pile d’observabilité complète pour les systèmes IA et LLM — métriques, traces, journaux structurés et SLO — voir Observabilité pour les systèmes LLM : Métriques, Traces, Journaux et Tests en production.

Recommandation finale

Les modèles de sondage gèrent la couche de planification proactive sous un système multi-agent. Une fois que vous avez plusieurs agents qui doivent se coordonner entre eux — et non pas juste sonder indépendamment — la prochaine décision de conception est la manière dont ils se coordonnent : étoile, pipeline, éventail ou essaim. Modèles d’orchestration multi-agents couvre ces topologies de coordination avec des modes de défaillance et un cadre de décision.

Pour un assistant IA sérieux, commencez par des travailleurs de sondage basés sur une file d’attente et un magasin d’état durable. Ajoutez des webhooks là où 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 de longue durée et en plusieurs étapes. Utilisez un runtime d’agent persistant lorsque l’agent doit raisonner sur une période donnée.

Pour l’exemple Hermes et Notion, la bonne architecture est :

Notion comme boîte de réception de tâches visible par l'humain
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 de la leaving du système dans un état que les humains et les exécutions futures peuvent tous comprendre.