Recevoir les marchés à examiner avec leurs éléments de preuve

Le besoin métier

Pour une entreprise qui intervient sur le bâti ancien, trouver une consultation intéressante ne consiste pas à repérer le mot « patrimoine » dans un titre. L'avis peut couvrir plusieurs lots, une prestation pertinente peut n'apparaître que dans les pièces jointes et une nouvelle publication peut modifier une date, un périmètre ou un document sans changer le libellé principal.

Les informations arrivent par plusieurs voies : BOAMP, TED, plateformes de marchés et alertes reçues par courriel. Une même consultation peut donc être signalée plusieurs fois, sous des références et des présentations différentes. L'équipe doit encore ouvrir les avis, rechercher le dossier de consultation, vérifier les lots, retrouver la date limite et déterminer si le travail demandé correspond réellement à ses compétences.

Le risque n'est pas seulement de perdre du temps. Un doublon peut mobiliser deux personnes ; une mise à jour peut être prise pour un nouvel avis ; une mention de restauration dans un contexte général peut masquer l'absence de prestation adaptée. Le besoin formulé était une veille qui explique pourquoi un dossier mérite une lecture humaine, avec ses sources, et qui reprend proprement après une interruption.

La solution et son périmètre

La chaîne rassemble les flux publics et les alertes de messagerie dans un même registre. Chaque avis est normalisé : référence, acheteur, objet, lots, codes CPV, échéance, liens et provenance sont conservés autant que la source les fournit. Cette provenance compte : elle permet de revenir à l'avis ou au document qui soutient une qualification.

Le registre distingue trois situations. Un avis inconnu entre dans la sélection à traiter. Une version déjà vue et inchangée réutilise l'analyse existante. Une version modifiée repart dans un circuit de vérification ciblée, notamment si les pièces ou la date ont changé. Un état durable dans PostgreSQL garde la progression du traitement ; n8n orchestre les étapes sans faire dépendre la fiabilité d'une seule exécution continue.

Un préfiltre déterministe écarte les éléments manifestement hors périmètre à partir des règles métier explicites. Les dossiers plausibles sont enrichis avec les pièces de consultation accessibles. L'IA locale examine alors les textes utiles et produit une qualification structurée. Le résultat reste une aide au tri : il ne décide ni de la capacité à répondre, ni du prix, ni du dépôt d'une offre.

Le parcours d'un avis

1. Une source publique ou une alerte par courriel signale la consultation et son origine est enregistrée.
2. La référence est rapprochée des avis connus ; une comparaison de version détermine s'il faut reprendre l'analyse.
3. Les critères métier explicites filtrent les dossiers sans rapport avant d'engager la lecture des pièces.
4. Le dossier de consultation accessible est collecté dans des limites de volume, de temps et de nombre de documents.
5. Les textes sont découpés en fragments repérables, puis analysés par le modèle local selon un format de réponse imposé.
6. Les réponses sont vérifiées et réunies en une synthèse liée à ses preuves ; l'équipe reçoit les dossiers à examiner.

Ce parcours a deux sorties utiles : une sélection argumentée et une trace de ce qui n'a pas pu être analysé. Un document absent, un lien expiré ou une extraction de texte impossible ne se transforme pas silencieusement en avis « non pertinent ».

Sources, versions et reprises

Les flux ne se comportent pas tous de la même façon. Une plateforme peut modifier le contenu sans changer l'identifiant visible ; un courriel peut arriver deux fois ; une récupération HTTP peut échouer alors que l'avis reste valable. La normalisation rapproche les références, mais conserve la source et la version qui ont effectivement été consultées.

Le suivi d'exécution réserve le travail à traiter pour éviter que deux passages concurrents qualifient le même avis en parallèle. Côté messagerie, les alertes ne sont marquées comme prises en charge qu'au stade prévu par le flux. En cas de coupure, le traitement peut repartir de l'état enregistré plutôt que de supposer que tout a réussi. Les erreurs de transport et les erreurs de contenu restent séparées : elles appellent des corrections différentes.

Cette distinction change l'exploitation quotidienne. Si une plateforme ne répond pas, le prochain passage doit tenter à nouveau la collecte. Si le document est bien arrivé mais que l'analyse structurée échoue, il faut relancer cette étape sans multiplier les avis. Si un courriel est déjà réservé par une exécution encore active, une autre exécution ne doit pas le déclarer terminé. PostgreSQL sert ici de mémoire partagée entre passages ; le journal d'une exécution n8n, à lui seul, ne suffit pas à représenter l'état métier.

La mise en cache de résultats accélère une nouvelle consultation d'un contenu identique, mais une entrée réutilisée doit encore respecter le format et les règles courantes. Une modification réelle des pièces, du filtrage ou de la réponse invalide la réutilisation automatique. Cette discipline évite qu'un résultat ancien paraisse à jour parce qu'il était simplement disponible.

Lecture des pièces et qualification

Un dossier de consultation peut être volumineux. Le système borne le téléchargement et l'extraction, sélectionne les pièces exploitables et associe un identifiant à chaque fragment de texte. Ce repère permet de rattacher une conclusion à un passage précis plutôt qu'à une impression générale sur le dossier.

L'analyse locale renvoie un objet structuré : intérêt estimé, lots concernés, éléments favorables, réserves, données manquantes et degré de confiance. Une réponse qui ne respecte pas le schéma attendu est rejetée. Une affirmation non reliée à une pièce ne devient pas une preuve. Ainsi, la présence de « monument historique » dans la présentation de l'acheteur ne suffit pas à conclure que le marché comporte des travaux de restauration adaptés.

La synthèse transmise à l'équipe met l'objet, l'acheteur, la date limite, les lots possibles, les extraits utiles et les liens sources au même endroit. Elle peut indiquer qu'un DCE est incomplet ou inaccessible. La décision de lire, de demander une précision ou de préparer une réponse reste au chargé d'affaires.

L'agrégation attend que les fragments nécessaires aient reçu un résultat ou une erreur explicite. Un premier fragment très pertinent ne doit pas masquer une réserve majeure présente plus loin ; à l'inverse, l'indisponibilité d'une pièce ne doit pas laisser une synthèse suspendue indéfiniment. Le message final privilégie la décision pratique : pourquoi regarder ce dossier, où se trouve l'information et qu'est-ce qui reste à vérifier. Il ne copie pas simplement une longue réponse du modèle.

Ce que l’IA apporte réellement

Le modèle intervient dans la lecture et la qualification de documents hétérogènes, là où des mots-clés deviennent trop pauvres : descriptions de lots, contraintes techniques, mentions dispersées dans les pièces. Il fonctionne localement et reçoit des fragments de taille maîtrisée. Il ne remplace pas les règles explicites de collecte, de dédoublonnage, de versionnement ou de validation.

Les retours humains peuvent ajuster de manière bornée le poids de certains termes dans le filtrage. Il ne s'agit pas d'un réentraînement automatique du modèle, encore moins d'une garantie que les prochains avis seront tous correctement classés. Une correction doit rester compréhensible : quel avis a été jugé utile, pour quelle raison et quelle règle doit être affinée ?

Un retour négatif est aussi informatif qu'un retour positif. Si plusieurs avis sont classés trop haut à cause d'un terme présent dans le contexte général, ce terme peut perdre du poids dans le préfiltre. La qualification documentaire reste examinée séparément, avec ses preuves. Cette séparation évite qu'une préférence exprimée sur un dossier modifie sans contrôle toutes les décisions suivantes.

Ce qui change pour l'équipe

Le bénéfice recherché est un tri plus rapide et plus défendable. Les documents fournis ne démontrent pas un gain de temps mesuré, un taux de détection exhaustif ni un chiffre d'affaires attribuable à l'outil. Ces résultats demanderaient un suivi réel : temps consacré au tri, avis jugés pertinents après lecture humaine, doublons évités et dossiers manqués lors d'un contrôle par échantillon.

Les limites à prévoir

La qualité dépend des plateformes, des droits d'accès, des pièces disponibles et de l'extraction des PDF. Un dossier scanné ou un lien protégé peut limiter fortement la qualification. Le modèle peut aussi donner une réponse plausible mais non étayée : les validations de structure et de preuves réduisent ce risque sans l'annuler.

Une échéance, un lot et un critère de sélection doivent toujours être revérifiés dans les documents officiels avant d'engager une réponse. Le système facilite l'attention de l'équipe ; il ne garantit pas la conformité d'une candidature. La bonne suite du projet serait de confronter régulièrement la sélection automatique aux décisions humaines, d'examiner les faux positifs et les omissions, puis d'ajuster les règles sur des cas documentés.

Repères techniques

n8nPostgreSQLIA localePDF / DCE

Ces choix décrivent le périmètre présenté. Une reprise dans un autre contexte commence par la validation des usages, des données et des accès.