Transformer une veille de marchés publics en système opérationnel, traçable et résilient

Surveiller les marchés publics paraît simple tant que l’on raisonne en termes de recherche : interroger quelques sources, repérer des mots-clés et transmettre les résultats.

En production, le problème est très différent.

Les mêmes consultations peuvent apparaître sur plusieurs canaux. Les avis évoluent, sont rectifiés ou republient des informations déjà vues. Certaines données arrivent par API, d’autres par e-mail. Les pièces du DCE peuvent être volumineuses, incomplètes ou difficiles à exploiter. Une analyse par IA peut échouer en cours de traitement. Et surtout, un faux positif envoyé chaque jour finit par rendre la veille inutilisable.

CagedMonster a conçu une architecture de veille qui ne cherche donc pas simplement à « trouver des appels d’offres ». Elle cherche à produire un signal métier fiable, à partir de plusieurs sources, avec des mécanismes explicites de dédoublonnage, de reprise sur erreur, de persistance et de contrôle.

L’objectif n’était pas de multiplier les outils d’IA. Il était de restituer aux équipes une sélection exploitable, tout en gardant la provenance des faits, le contrôle des décisions et la possibilité de diagnostiquer chaque étape.

---

Le contexte

Le système surveille des opportunités de marchés publics pour une entreprise dont le cœur de métier couvre notamment la maçonnerie traditionnelle, la pierre, les enduits à la chaux, la restauration du patrimoine, la consolidation de structures existantes, la réparation du béton, la terre crue, l’humidité du bâti et certains travaux de gros œuvre.

Le périmètre géographique opérationnel couvre quatre départements :

• Calvados ;
• Manche ;
• Orne ;
• Ille-et-Vilaine.

La veille doit agréger plusieurs canaux, analyser la pertinence réelle des consultations et envoyer une restitution directement exploitable par les équipes.

Le workflow final est orchestré dans n8n, avec PostgreSQL comme couche d’état durable et un LLM local servi via LM Studio pour l’analyse métier.

---

Le problème à résoudre

Trop de sources, trop de formats

La veille combine plusieurs origines :

• BOAMP ;
• TED / JOUE ;
• Marchés Online ;
• alertes MAPA reçues par e-mail ;
• liens et documents associés aux consultations.

Ces sources ne décrivent pas toujours un marché de la même manière. Une même consultation peut comporter des références différentes, des URLs différentes ou des informations complémentaires selon le canal.

Une simple concaténation produirait donc rapidement des doublons.

Les mots-clés ne suffisent pas

Un bâtiment classé, une église ou un ouvrage ancien n’implique pas automatiquement une prestation correspondant au métier de l’entreprise.

Inversement, un marché dont le titre paraît générique peut contenir un lot très pertinent dans sa description ou son DCE.

Le système doit distinguer :

• le contexte du projet ;
• la prestation réellement demandée ;
• les lots pertinents ;
• les simples mentions sans valeur métier.

Le système doit survivre aux erreurs

Une veille quotidienne ne peut pas supposer que tous les services seront toujours disponibles.

Il faut gérer notamment :

• les erreurs HTTP ;
• les timeouts ;
• les doublons IMAP ;
• un redémarrage de n8n ;
• une réponse IA invalide ;
• une indisponibilité temporaire du modèle ;
• un PDF inaccessible ;
• un échec d’envoi d’e-mail ;
• deux exécutions qui tenteraient de démarrer simultanément.

C’est cette contrainte qui a fait évoluer le projet d’un workflow d’automatisation classique vers une petite architecture transactionnelle.

---

La solution conçue

Le système suit une chaîne de traitement structurée :

Déclenchement
    ↓
Réservation de l’exécution
    ↓
Collecte multi-source
    ↓
Normalisation
    ↓
Fusion et dédoublonnage
    ↓
Historique et gestion des versions
    ↓
Préanalyse métier
    ↓
Enrichissement DCE lorsque nécessaire
    ↓
Fragmentation documentaire
    ↓
Analyse par IA locale
    ↓
Validation stricte
    ↓
Agrégation et scoring
    ↓
E-mail opérationnel
    ↓
Historisation
    ↓
Feedback utilisateur

Chaque couche répond à un problème différent. L’IA n’est qu’une composante de l’architecture.

---

1. Collecter sans dépendre d’une seule source

Le workflow interroge directement les sources accessibles par HTTP et intègre en parallèle les alertes reçues par e-mail.

Les données sont ramenées vers une représentation commune contenant notamment :

• la référence de l’avis ;
• l’acheteur ;
• l’objet ;
• les dates ;
• le département ;
• le lieu d’exécution ;
• les lots ;
• les codes CPV ;
• les liens vers l’avis ;
• les liens vers le DCE ;
• la provenance des champs.

Cette normalisation est essentielle : les traitements suivants ne doivent pas connaître toutes les particularités de chaque fournisseur de données.

Pourquoi c’est important

Ajouter une source supplémentaire devient un problème d’adaptation vers un contrat de données commun, plutôt qu’une réécriture de toute la logique métier.

---

2. Fusionner les avis sans perdre leur provenance

Le workflow ne se contente pas de supprimer les doublons.

Il rapproche les avis provenant de plusieurs canaux puis conserve :

• leurs références ;
• les sources ayant contribué à l’avis ;
• les URLs disponibles ;
• les éventuels conflits entre champs ;
• la provenance de certaines informations.

Le résultat n’est donc pas simplement « un avis unique », mais un avis consolidé.

Cette distinction est importante dans les systèmes multi-sources : la déduplication ne doit pas détruire l’information qui permet ensuite d’expliquer d’où vient une donnée.

---

3. Suivre les versions plutôt que simplement mémoriser les références

Un avis déjà rencontré n’est pas forcément un avis à ignorer.

Il peut avoir évolué.

Le workflow construit une représentation versionnée de la consultation et utilise PostgreSQL pour différencier :

• un avis réellement nouveau ;
• un avis inchangé déjà traité ;
• une nouvelle version d’un avis existant ;
• une version déjà analysée avec la même logique métier.

L’historique durable est consulté avant l’analyse IA, afin de ne pas consommer inutilement du calcul sur des contenus déjà traités.

L’inscription définitive dans l’historique intervient après le traitement opérationnel attendu, afin d’éviter de considérer trop tôt un avis comme terminé.

---

4. Réserver l’exécution avant de travailler

Un déclenchement planifié peut survenir alors qu’une exécution précédente est encore active.

Pour éviter deux traitements concurrents incompatibles, le workflow s’appuie sur PostgreSQL pour acquérir une réservation associée :

• au workflow ;
• à l’identifiant d’exécution ;
• à l’état de progression.

Si la réservation n’est pas obtenue, l’exécution ne doit pas poursuivre la collecte comme si elle était seule.

Pourquoi ne pas se contenter de la mémoire de n8n ?

Parce qu’un état critique uniquement conservé en mémoire disparaît avec le processus.

PostgreSQL sert ici de source d’état durable pour les mécanismes où une reprise après incident doit rester possible.

---

5. Préfiltrer avant d’appeler le modèle

Le LLM n’est pas utilisé comme premier filtre universel.

Une préanalyse déterministe élimine d’abord les cas manifestement incompatibles et signale les dossiers qui doivent être examinés.

Cette étape tient compte de plusieurs éléments, parmi lesquels :

• la nature de l’avis ;
• son état d’ouverture ;
• sa localisation ;
• des indices de périmètre métier ;
• des exclusions explicites ;
• des cas nécessitant malgré tout un examen.

Cette approche réduit le bruit et réserve l’IA aux cas pour lesquels son interprétation apporte réellement de la valeur.

---

6. Enrichir avec le DCE de manière bornée

Quand les informations de l’avis ne suffisent pas, le workflow peut enrichir certains dossiers avec leur Dossier de Consultation des Entreprises.

Mais le téléchargement documentaire n’est jamais laissé sans limite.

Le système borne :

• le nombre de consultations enrichies ;
• la taille des ressources ;
• le nombre de documents examinés ;
• le volume de texte transmis à l’analyse ;
• le traitement des archives et des PDF.

Cette discipline protège le workflow contre un cas fréquent en automatisation documentaire : une pièce exceptionnelle qui consomme à elle seule la mémoire ou le temps de traitement de toute l’exécution.

---

7. Fragmenter les données avant l’analyse IA

Un avis et son DCE peuvent dépasser largement la taille raisonnable d’un appel au modèle.

Le système découpe donc les informations en fragments identifiés.

Chaque fragment possède :

• un identifiant ;
• un index ;
• un type de contenu ;
• la référence de l’avis auquel il appartient ;
• un schéma de réponse attendu.

L’analyse IA est ainsi réalisée sur des unités contrôlées, puis les résultats sont regroupés au niveau de la consultation.

Cette architecture permet également de savoir précisément quel fragment a réussi ou échoué.

---

8. Utiliser une IA locale dans un cadre strict

Le modèle est exposé localement via une API compatible avec le format OpenAI.

L’appel est volontairement contraint :

• température nulle ;
• réponse attendue en JSON ;
• schéma JSON strict ;
• enums métier ;
• bornes sur les scores ;
• structure obligatoire pour les preuves, les lots et les points de vigilance.

Le modèle ne reçoit pas la consigne vague de « dire si ce marché est intéressant ».

Il doit produire des éléments structurés tels que :

• une décision sur le fragment ;
• un score ;
• un niveau de confiance ;
• des preuves textuelles ;
• des capabilities métier ;
• une analyse par lot ;
• des informations manquantes ;
• des points de vigilance.

Une règle centrale : le contexte ne vaut pas preuve

Le prompt impose par exemple qu’une mention de patrimoine, d’église, de château ou d’ouvrage d’art ne suffise pas à rendre un dossier pertinent.

La pertinence doit reposer sur une prestation métier démontrée.

Cette règle réduit un biais fréquent des analyses automatiques : surinterpréter le contexte au lieu d’identifier le travail réellement demandé.

---

9. Exiger des preuves factuelles

Les réponses du modèle sont exploitées à partir de preuves textuelles directes.

Le système distingue notamment des capabilities comme :

• taille de pierre ;
• maçonnerie ancienne ;
• chaux et façades ;
• restauration du patrimoine ;
• consolidation de l’existant ;
• réparation du béton ;
• terre crue ;
• humidité et drainage ;
• isolation adaptée au bâti ancien ;
• gros œuvre et maçonnerie.

Lors de l’agrégation, les preuves directes sont privilégiées et les éléments purement contextuels ne suffisent pas à promouvoir artificiellement un avis.

Le scoring devient ainsi plus explicable : une note n’est pas seulement le résultat opaque d’un LLM, elle est reliée à des preuves métier identifiables.

---

10. Valider la réponse IA avant de la laisser entrer dans le système

Le fait qu’un serveur LLM retourne HTTP 200 ne signifie pas que le résultat est utilisable.

Chaque fragment traverse donc une phase de validation qui vérifie notamment :

• la présence d’un JSON exploitable ;
• la conformité à la structure attendue ;
• la cohérence de l’identifiant de fragment ;
• les valeurs autorisées ;
• les champs obligatoires.

Une tentative de réparation peut être déclenchée pour une réponse structurée mais non conforme.

Si un fragment reste invalide, le workflow ne fabrique pas silencieusement une conclusion.

L’avis concerné est reporté afin d’être retraité ultérieurement.

---

11. Mettre en cache sans figer une ancienne logique

Le cache IA ne repose pas uniquement sur la référence du marché.

L’empreinte tient compte du contexte de l’analyse, notamment de la requête envoyée au modèle.

Cela permet d’éviter un piège classique :

réutiliser une ancienne réponse alors que le prompt, le modèle ou le schéma attendu a changé.

Une réponse retrouvée dans le cache est également revalidée avant réutilisation.

Le cache accélère donc les traitements répétitifs sans devenir une source de réponses obsolètes incontrôlées.

---

12. Synchroniser les fragments avant l’agrégation

L’un des points les plus sensibles du workflow concerne la synchronisation.

Pour chaque département, le système suit l’état de traitement des fragments et interdit certaines opérations tant que la couverture attendue n’est pas atteinte.

Autrement dit :

• l’agrégation ne doit pas démarrer trop tôt ;
• l’e-mail ne doit pas partir alors que des fragments sont encore en cours ;
• une exécution ne doit pas réutiliser l’état d’une autre ;
• une étape finalisée ne doit pas recevoir de nouveaux résultats tardifs comme si elle était encore ouverte.

Cette logique transforme une série d’appels IA asynchrones en un traitement déterministe au niveau métier.

---

13. Rendre l’IMAP transactionnel

Les alertes e-mail introduisent un autre problème : un même message peut être présenté plusieurs fois au workflow, notamment après une interruption ou une reconnexion.

Chaque message reçoit donc une identité stable.

PostgreSQL maintient ensuite son état avec une réservation temporaire.

Le traitement distingue trois confirmations :

• direct_mapa ;
• direct_mol ;
• aggregate.

L’événement IMAP n’est considéré comme terminé que lorsque les branches attendues ont confirmé leur traitement.

En cas d’interruption, le mécanisme de lease permet de distinguer :

• un message encore réservé par une exécution active ;
• un doublon à ignorer temporairement ;
• un traitement incomplet devenu récupérable ;
• un message déjà complètement traité.

Ce que « transactionnel » signifie ici

Il ne s’agit pas d’une transaction SQL unique entourant tout le workflow.

Il s’agit d’une succession d’opérations atomiques et persistantes permettant au système de savoir ce qui a été réservé, confirmé, terminé ou doit être repris.

C’est souvent une approche plus réaliste pour un workflow distribué de longue durée.

---

14. Produire un e-mail utilisable, pas un rapport de modèle

La restitution finale présente les informations opérationnelles utiles :

• objet du marché ;
• acheteur ;
• localisation ;
• échéance ;
• score ;
• niveau de priorité ;
• lots retenus ;
• métiers concernés ;
• preuves factuelles ;
• points de vigilance ;
• lien vers l’avis ;
• lien vers le DCE lorsqu’il est disponible.

Les faits structurants — objet, acheteur, dates, lieu, montant ou liens — restent issus des sources collectées.

Le modèle intervient sur le jugement métier, pas pour réinventer les données de la consultation.

Cette séparation réduit le risque qu’une information factuelle affichée soit simplement une hallucination du LLM.

---

15. Ajouter une boucle de feedback sans « réentraîner l’IA »

Chaque sélection peut intégrer un lien de feedback.

L’utilisateur peut indiquer qu’un avis était :

• pertinent ;
• à écarter.

Le lien utilise un jeton temporaire à usage contrôlé.

Le feedback est ensuite transformé en pondérations bornées sur certains termes associés au titre de la consultation.

Il s’agit donc d’une boucle de réglage du système de sélection, pas d’un entraînement automatique du modèle.

Cette distinction est importante : apprendre d’un usage réel ne signifie pas nécessairement réentraîner un LLM.

---

Les choix d’architecture qui ont fait la différence

PostgreSQL comme mémoire durable

La base ne sert pas simplement à stocker des résultats.

Elle participe directement au comportement du système :

• anti-chevauchement ;
• progression ;
• historique ;
• versions ;
• cache ;
• état IMAP ;
• réservations et reprises.

Un LLM encadré par des contrats

L’IA intervient dans une architecture qui impose :

• un format ;
• un vocabulaire ;
• des preuves ;
• des identifiants ;
• des contrôles de cohérence.

Le modèle apporte une capacité d’interprétation sans devenir l’unique arbitre du workflow.

Des traitements bornés

Documents, fragments, appels et enrichissements sont volontairement limités.

En production, une limite explicite est souvent plus importante qu’une optimisation théorique.

Une validation avant chaque changement d’état important

Le système cherche à ne pas déclarer une étape terminée simplement parce qu’un nœud a été exécuté.

La finalisation dépend de conditions métier vérifiées.

---

Résultat opérationnel

Le résultat n’est pas un « chatbot marchés publics ».

C’est une chaîne de décision automatisée qui :

• surveille plusieurs sources ;
• rapproche les informations sur une même consultation ;
• écarte les versions déjà traitées ;
• limite les traitements inutiles ;
• analyse les cas pertinents avec un modèle local ;
• exige des preuves structurées ;
• attend la fin de tous les fragments ;
• classe les opportunités ;
• restitue les avis dans un format exploitable ;
• garde suffisamment d’état pour diagnostiquer ou reprendre une exécution.

Pour les équipes, l’interface principale peut rester extrêmement simple : un e-mail de veille priorisé.

La complexité est placée là où elle apporte de la valeur : dans l’orchestration, la fiabilité, la traçabilité et la qualité du filtrage.

---

Ce que cette étude de cas illustre

Ce projet montre plusieurs principes que CagedMonster applique aux automatisations intégrant de l’IA.

L’IA vient après l’architecture

Un modèle puissant ne compense pas :

• l’absence de dédoublonnage ;
• un historique fragile ;
• des données mal normalisées ;
• une synchronisation approximative ;
• une reprise sur erreur inexistante.

Une automatisation fiable doit savoir reprendre

La bonne question n’est pas seulement :

« Que se passe-t-il quand tout fonctionne ? »

Elle est aussi :

« Que reste-t-il vrai après un timeout, un redémarrage ou un doublon ? »

La décision doit rester explicable

Lorsque l’IA intervient dans un processus opérationnel, une note seule est rarement suffisante.

Les preuves, la provenance, les lots concernés et les points de vigilance rendent le résultat réellement exploitable.

Le bon niveau d’autonomie dépend du risque

Ici, l’automatisation collecte, consolide, filtre, analyse et priorise.

Elle prépare la décision.

Elle ne remplace pas la responsabilité humaine sur la réponse à un marché.

---

Architecture technique

---

Pourquoi une IA locale ?

Le choix d’un modèle local répond ici à plusieurs objectifs :

• maîtriser l’environnement d’exécution ;
• éviter de faire dépendre chaque analyse d’une API externe ;
• contrôler plus finement le modèle et ses paramètres ;
• permettre une intégration étroite avec le pipeline documentaire ;
• garder la possibilité de faire évoluer le modèle indépendamment du reste de l’architecture.

Le workflow a été conçu pour que le modèle reste remplaçable : son nom, son endpoint, ses paramètres, ses prompts, son budget de contexte et son empreinte de cache sont des éléments identifiés du système.

---

Un workflow n8n peut devenir un véritable système logiciel

Cette étude de cas montre aussi la limite de l’opposition entre « no-code » et « développement logiciel ».

À partir d’un certain niveau de criticité, un workflow n8n peut contenir :

• des contrats de données ;
• des machines d’état ;
• du code métier ;
• de la persistance ;
• des verrous ;
• des mécanismes d’idempotence ;
• des stratégies de reprise ;
• des interfaces avec plusieurs systèmes externes.

Il doit alors être conçu et maintenu avec les mêmes exigences qu’un logiciel de production.

---

Vous avez un processus similaire ?

La même approche peut s’appliquer à de nombreux processus où des équipes doivent surveiller, qualifier et exploiter un volume important d’informations :

• appels d’offres ;
• appels à projets ;
• veille réglementaire ;
• dossiers fournisseurs ;
• demandes entrantes ;
• veille documentaire ;
• qualification commerciale ;
• traitement d’e-mails métier ;
• analyse de pièces contractuelles.

L’enjeu n’est pas d’ajouter de l’IA partout.

Il est d’identifier où l’automatisation déterministe suffit, où l’IA apporte une capacité d’interprétation, et où l’humain doit garder la décision.

Parler de votre projet avec CagedMonster →

---

FAQ

Pourquoi utiliser n8n pour une veille de marchés publics ?

n8n permet d’orchestrer dans un même environnement les appels HTTP, les e-mails, PostgreSQL, les traitements JavaScript, les documents et les appels à un modèle local. Sur un projet complexe, la valeur vient surtout de la capacité à rendre visibles les différentes étapes du pipeline tout en conservant la possibilité d’implémenter une logique avancée.

L’IA décide-t-elle seule quels marchés doivent recevoir une réponse ?

Non. Le système prépare et priorise les opportunités. Il utilise l’IA pour qualifier des preuves métier et des lots, mais la décision commerciale et opérationnelle reste humaine.

Comment les doublons sont-ils gérés ?

Le système combine plusieurs identifiants et un historique versionné. Il cherche à distinguer une consultation réellement nouvelle d’une consultation déjà traitée ou modifiée, plutôt qu’à éliminer les doublons uniquement sur le titre.

Que se passe-t-il si le modèle local est indisponible ?

L’architecture distingue les erreurs de transport des réponses invalides. Elle évite de transformer silencieusement une panne du modèle en décision métier et conserve les cas non finalisés pour un traitement ultérieur.

Pourquoi PostgreSQL est-il nécessaire alors que n8n possède déjà son propre état ?

Parce que certains états doivent survivre aux redémarrages et être accessibles de manière atomique : réservation d’exécution, historique, version d’un avis, cache ou traitement d’un événement IMAP. PostgreSQL sert donc de couche durable pour les garanties qui dépassent une simple exécution de workflow.

Le feedback des utilisateurs réentraîne-t-il le modèle ?

Non. Dans cette architecture, le feedback ajuste des pondérations utilisées par le système de sélection. Il ne déclenche pas un réentraînement automatique du LLM.

---

Cette étude de cas décrit l’architecture et les mécanismes réellement implémentés dans le workflow étudié. Les identifiants techniques, adresses internes, credentials et autres informations sensibles ont volontairement été omis.