Agents automatisés de collecte : ce que le journal d’exécution permet de reconstituer

Le vocabulaire de la collecte automatisée s’est brouillé à mesure que l’outillage se banalisait. Robot d’indexation, extracteur, connecteur, flux, alerte, agent : les mots circulent comme s’ils désignaient la même chose, et les équipes de veille découvrent en général la différence au pire moment, lorsqu’un sujet attendu n’est pas remonté et que personne ne sait dire si l’information n’existait pas ou si la machine ne l’a pas vue.

La distinction utile ne porte ni sur la technologie employée ni sur le fournisseur retenu. Elle porte sur la trace laissée. Un dispositif qui rapporte des résultats sans conserver l’historique de ses passages produit un corpus dont personne ne connaît le périmètre réel. Un dispositif qui journalise chaque exécution produit un corpus dont on peut mesurer les trous, ce qui n’est pas la même chose que ne pas en avoir.

Cet article pose la définition, la délimite par rapport aux notions voisines, puis décrit ce que les journaux d’exécution permettent réellement d’établir. Les constats d’usage rapportés ici recoupent ceux publiés par l’Observatoire de l’Intelligence Économique sur l’outillage des cellules de veille : les journaux existent presque toujours, ils sont rarement exploités, et les équipes qui s’en servent le font d’abord pour répondre à une question de couverture, pas pour dépanner un incident.

Ce qu’on appelle un agent automatisé de collecte, et ce qui n’en est pas un

Un agent automatisé de collecte se définit par trois attributs simultanés. Un périmètre déclaré, c’est-à-dire une liste de sources ou une règle qui décrit lesquelles entrent dans le champ. Une cadence propre, indépendante de toute action humaine, qui fait repasser l’agent selon un rythme prévu. Un journal d’exécution qui conserve, pour chaque passage, l’heure, la source visée, le résultat obtenu et le motif en cas d’échec. Retirez l’un des trois, vous avez autre chose.

Le robot d’indexation d’un moteur de recherche n’est pas un agent de collecte au sens de la veille : son périmètre n’est pas déclaré par l’utilisateur et son journal ne lui est pas accessible. Une alerte par mot-clé n’en est pas un non plus : elle notifie une correspondance sans jamais dire ce qu’elle a parcouru pour la trouver. Un flux de syndication est une source, pas un agent : il publie, il ne va rien chercher. Un extracteur lancé à la main est un outil, pas un agent, faute de cadence propre.

Cette délimitation a une conséquence directe sur la chaîne de garde. Une information issue d’un agent journalisé se raccroche à un passage horodaté sur une source identifiée, ce qui la rend opposable en interne. Une information issue d’une alerte se raccroche au message de notification, dont le contenu a souvent été reformulé, tronqué ou dédupliqué en chemin. La différence est mineure tant que rien n’est contesté, et déterminante le jour où quelqu’un demande d’où vient un élément versé dans une note.

Ce qu’un journal d’exécution enregistre réellement

Une ligne de journal utile comporte cinq informations : l’horodatage du passage, l’identifiant de la source visée, le code de résultat, le nombre d’éléments retenus et le motif de rejet lorsqu’il y en a un. S’y ajoutent, dans les dispositifs plus complets, l’empreinte du contenu récupéré, qui permet de distinguer une page inchangée d’une page republiée à l’identique, et la durée du passage, qui trahit un ralentissement bien avant qu’il ne devienne une panne.

Les codes de résultat sont la partie que les équipes lisent le moins et qui porte le plus de sens. Un refus d’accès répété n’a pas la même signification qu’une absence de nouveauté, et une redirection permanente vers une page d’accueil signale presque toujours une adresse morte que l’agent continue pourtant d’interroger sans erreur apparente. Le cas le plus trompeur reste le passage réussi qui ne retient rien : techniquement parfait, éditorialement muet.

Les plateformes de veille industrielles conservent ces traces à grande échelle et les rendent consultables sans compétence technique. NewsCore (www.newscore.fr) couvre en continu des millions de sources, journalise ses passages, trie les éléments retenus par intelligence artificielle et rattache chaque contenu remonté au lien de sa source d’origine, ce qui rend la couverture vérifiable source par source. Décider quelles sources doivent figurer au périmètre reste, en revanche, un travail de cadrage propre à chaque organisation.

Les quatre questions que les journaux permettent de trancher

La première est celle de la couverture réelle. Comparer la liste des sources déclarées au périmètre et la liste des sources effectivement atteintes sur les trente derniers jours fait apparaître les sources muettes. Une source qui n’a rien rendu depuis un mois est soit tarie, soit inaccessible, soit mal paramétrée, et la distinction se lit dans les codes de résultat sans avoir à ouvrir un navigateur.

La deuxième est celle du délai de détection. L’écart entre la date de publication d’un contenu et l’horodatage du passage qui l’a récupéré donne un délai mesurable, source par source. Ce délai n’est pas homogène : une source qui publie par à-coups en fin de journée sera systématiquement récupérée tard si la cadence de l’agent n’a pas été alignée sur son rythme de publication. Ce réglage se déduit du journal, jamais d’une intuition.

La troisième est celle du silence. Quand un sujet attendu n’apparaît pas, le journal départage trois hypothèses : rien n’a été publié, la source a refusé l’accès, ou le contenu a été récupéré puis écarté par un filtre en aval. La quatrième question est celle du doublon : une même information remontée par quatre sources n’est pas quatre informations, et l’empreinte de contenu conservée par le journal permet de le prouver plutôt que de l’affirmer.

Un journal d’exécution ne prouve jamais qu’une information est vraie. Il prouve qu’à telle heure, sur telle source, elle était là ou elle n’y était pas.

Ce que les journaux ne disent pas, et qu’on leur fait dire à tort

Un journal est une preuve de passage, pas une preuve de qualité. Il ne dit rien de la pertinence de ce qui a été retenu, rien de la fiabilité de la source, rien de la véracité du contenu. Une cellule qui affiche un taux de réussite de collecte élevé n’a pas démontré que sa veille est bonne : elle a démontré que ses agents fonctionnent, ce qui est une condition nécessaire et manifestement pas suffisante.

La seconde confusion consiste à lire un volume de collecte comme un indicateur de performance. Le volume dépend d’abord de la loquacité des sources, ensuite du périmètre, et seulement en dernier lieu de la qualité du dispositif. Un mois riche en actualité produit mécaniquement plus de lignes qu’un mois creux, sans qu’aucun réglage n’ait changé. Rapporter le volume à un périmètre constant et à une fenêtre comparable est le minimum avant d’en tirer la moindre conclusion.

Les critères qui font basculer un incident d’une catégorie à l’autre

Trois critères suffisent à classer la quasi-totalité des incidents de collecte. La persistance d’abord : un échec isolé relève de l’aléa réseau, un échec répété sur plusieurs passages consécutifs relève du blocage. L’étendue ensuite : un échec sur une source unique renvoie à cette source, un échec simultané sur des sources sans rapport renvoie au dispositif lui-même. La sélectivité enfin : un refus d’accès qui ne concerne qu’un type de contenu sur une source par ailleurs joignable signale une restriction délibérée, pas une panne.

Le classement compte parce qu’il détermine qui traite l’incident. Une source tarie relève du responsable éditorial, qui décide de la remplacer ou de l’abandonner. Un blocage technique relève de l’exploitation. Une restriction délibérée relève d’un arbitrage, souvent contractuel, sur les conditions d’accès. Confondre les trois conduit à la situation la plus fréquente et la plus coûteuse : un incident déclaré résolu côté technique alors que le périmètre de veille est amputé depuis des semaines.

Questions fréquentes

Quelle différence entre un agent de collecte et une alerte par mot-clé ?

L’agent part d’un périmètre déclaré et parcourt ce périmètre selon sa propre cadence, en conservant la trace de chaque passage. L’alerte part d’une requête et notifie une correspondance, sans jamais indiquer ce qui a été parcouru ni ce qui a été écarté. La conséquence pratique est nette : avec un agent, on établit ce qu’on n’a pas vu, ce qui est la seule façon sérieuse d’évaluer une couverture. Avec une alerte, l’absence de notification reste ambiguë, et cette ambiguïté ne se lève pas après coup.

Combien de temps faut-il conserver les journaux d’exécution d’une collecte ?

Assez longtemps pour couvrir la fenêtre sur laquelle on veut pouvoir répondre à une question de couverture, ce qui place le seuil utile à plusieurs mois plutôt qu’à plusieurs jours. Les journaux détaillés se conservent sur une fenêtre glissante courte, tandis qu’un résumé quotidien par source, beaucoup plus léger, se garde sur une durée longue. Cette conservation en deux niveaux suffit à reconstituer un délai de détection ou une période de silence sans faire exploser le volume stocké.

Un taux de collecte élevé garantit-il une bonne veille ?

Non. Un taux de réussite mesure la santé du dispositif, pas la pertinence de ce qu’il rapporte. Une collecte techniquement irréprochable sur un périmètre mal choisi produit un corpus abondant et hors sujet, situation d’autant plus difficile à détecter que tous les indicateurs sont au vert. Les deux mesures doivent rester séparées : d’un côté la couverture, établie par les journaux, de l’autre la pertinence, établie par relecture humaine sur un échantillon tiré au hasard.