Agents autonomes qui surveillent les portails de marchés publics

Les portails de marchés publics ont été conçus pour des humains cliquant à travers des pages, pas pour des logiciels les lisant. Chacun a sa propre mise en page, son propre formulaire de recherche, sa propre façon de lister les avis, et sa propre habitude de changer cette mise en page sans avertissement. Surveiller ne serait-ce qu'une poignée de ces portails de façon fiable, chaque jour, sans manquer un nouvel avis ni compter deux fois un ancien, est un problème plus difficile qu'il n'y paraît de l'extérieur. C'est ce que les agents de surveillance autonomes existent pour résoudre, et comprendre comment ils fonctionnent explique pourquoi certaines approches tiennent sur des mois d'exploitation continue et d'autres se cassent discrètement en quelques semaines.

Ce que fait réellement un agent de surveillance

Dans sa forme la plus simple, un agent de surveillance visite une source selon un calendrier, extrait tout nouveau contenu apparu, et le transforme en enregistrement structuré : un titre, un acheteur, une date limite, une catégorie, un lien vers l'avis original. Répété sur des centaines de sources et exécuté chaque jour, cela produit une vue continuellement mise à jour de ce qui est actuellement ouvert sur tout un marché, ce qu'aucune équipe ne pourrait maintenir à la main à un coût raisonnable.

La complexité n'est pas dans le concept. Elle réside dans la réalisation fiable de cette tâche face à des sources qui n'ont jamais été conçues pour être lues par des machines, qui changent de structure sans préavis, et qui parfois échouent, expirent ou renvoient des pages incomplètes pour des raisons sans rapport avec l'agent lui-même.

Connecteurs par portail : pourquoi une seule approche ne convient pas à tous

L'approche naïve traite chaque portail de marchés publics de la même manière : récupérer la page, chercher quelque chose qui ressemble à une liste d'appels d'offres, l'extraire. Cela fonctionne pour les sources les plus simples et les plus standardisées et échoue presque partout ailleurs. Une plateforme nationale d'e-procurement dotée d'une API documentée est un problème complètement différent d'une autorité régionale de santé publiant des avis PDF à l'intérieur d'une page web statique, qui est à nouveau différent d'un portail qui affiche ses listes via JavaScript après le chargement initial de la page.

L'approche la plus résiliente construit un connecteur dédié pour chaque source : un petit morceau de logique conçu sur mesure qui comprend exactement comment ce portail particulier structure ses données, où se trouve le champ de date limite, et comment distinguer un avis véritablement nouveau d'un avis simplement re-trié en haut d'une liste. Un connecteur pour un point de terminaison d'API structuré ne ressemble en rien à un connecteur pour un portail basé sur des PDF, et ni l'un ni l'autre ne ressemble à un connecteur construit pour un site qui exige une connexion avant que les résultats ne deviennent visibles. Traiter chaque source comme son propre problème bien compris, plutôt que de forcer un unique scraper générique à tout gérer, est ce qui fait tenir la surveillance sur des centaines de portails véritablement différents.

Détection de changements : savoir ce qui est réellement nouveau

Un portail annonce rarement qu'un avis est nouveau. Les agents doivent le déduire, généralement en tenant un registre de ce qui a déjà été vu, indexé sur une combinaison d'un identifiant de source, d'un numéro de référence et d'une date de publication, et en comparant chaque nouvelle extraction à ce registre. Faites-le mal dans un sens et le même appel d'offres remonte trois fois en une semaine. Faites-le mal dans l'autre sens et une opportunité véritablement nouvelle est silencieusement traitée comme un doublon et ne remonte jamais du tout, l'échec le plus coûteux puisqu'il reste invisible jusqu'à ce que quelqu'un remarque le manque.

La détection de changements doit aussi gérer les mises à jour d'avis qui existent déjà. Une prolongation de délai, une quantité corrigée, un avis annulé : ce sont des changements à un enregistrement déjà présent dans le système, et un agent doit distinguer un nouvel appel d'offres d'une modification à un appel d'offres déjà capturé.

Récupération après erreur : la partie ingrate qui compte le plus

Les sources tombent en panne. Les pages se chargent lentement et expirent. Le certificat d'un portail expire pendant une journée. Un changement de mise en page casse silencieusement le champ qui contenait auparavant la date limite. Rien de tout cela n'est exceptionnel ; sur des mois d'exploitation continue sur des centaines de sources, c'est le quotidien de base. Ce qui sépare une surveillance digne de confiance d'une surveillance qui pourrit discrètement, c'est la manière dont l'échec est géré.

Un agent bien construit n'échoue pas en silence. Lorsqu'une source ne peut être atteinte, ou que les données extraites semblent structurellement erronées (un champ de date limite vide, une liste renvoyant zéro résultat alors qu'elle en renvoie habituellement des dizaines), l'échec est signalé afin qu'un humain ou une vérification en aval puisse détecter un connecteur cassé avant qu'il ne produise des semaines de données manquantes. Un système qui échoue en silence est pire qu'une absence de surveillance, car il crée une fausse confiance qu'un marché est surveillé alors qu'il ne l'est pas.

Pourquoi le déterministe l'emporte sur le génératif pour la collecte

Il est tentant de pointer un modèle de langage généraliste vers un portail et de lui demander d'extraire tout ce qui ressemble à un appel d'offres. Pour une lecture ponctuelle, cela peut raisonnablement fonctionner. Comme moteur d'une surveillance quotidienne, sans supervision, sur des centaines de sources, c'est le mauvais outil. Un modèle génératif peut paraphraser une date limite, mal lire une devise ou produire une réponse plausible mais erronée sans aucun signal que quelque chose a mal tourné, et il le fait de manière incohérente, si bien que la même page peut être lue correctement un jour et incorrectement le lendemain.

L'extraction déterministe, un connecteur qui cherche toujours au même endroit le même champ dans la même structure, est ennuyeuse par comparaison. Elle est aussi prévisible, testable et, surtout, elle échoue de manières détectables plutôt que de manières qui corrompent discrètement les données. Les modèles génératifs ont toujours un rôle réel dans ce pipeline, en particulier pour lire un appel d'offres une fois qu'il a été collecté de façon fiable et juger s'il est pertinent pour une entreprise donnée. Collecter le fait brut d'un avis et sa date limite est une tâche étroite et répétitive où la logique déterministe est plus digne de confiance qu'un modèle devinant la structure.

Où cela s'insère dans un flux de travail d'appel d'offres

Rien de tout cela ne remplace le jugement sur les appels d'offres qui valent la peine d'être poursuivis. Cela remplace le travail manuel et répétitif de les trouver en premier lieu. TRINTA lit ce qu'une entreprise vend et fait remonter les appels d'offres correspondants depuis des sources officielles quotidiennement, en utilisant exactement ce type de couche de connecteurs surveillée en continu en dessous.