# Comment Trinta surveille des centaines de sources chaque jour : au cœur de l'architecture > Au cœur de l'architecture de surveillance des appels d'offres de Trinta : connecteurs écrits à la main, scans programmés quotidiens, enrichissement documentaire et agents d'audit qui ne diffusent jamais de données inventées. Source: https://trinta.ai/fr/blog/inside-trinta-architecture-382-sources · Published: 2026-07-27 · Category: Technology · 7 min read Keywords: tender monitoring, public procurement, tender connectors, e-procurement portals, bid intelligence, TED PNCP scanning Un responsable des offres exportant des équipements à travers l'Afrique de l'Ouest, le Golfe et l'Amérique latine a, sur le papier, une seule mission : ne jamais manquer un appel d'offres pertinent. En pratique, cette mission est quasiment impossible à la main. Les avis vivent dans plus de 380 endroits différents : le TED de l'UE, le PNCP brésilien, le SECOP colombien, le DNCP paraguayen, la Banque mondiale et l'UNGM, plus des dizaines de portails nationaux de marchés publics, des centrales d'achat médicales (NUPCO, KEMSA, CENAME, SALAMA), des réseaux hospitaliers de sécurité sociale (IMSS, EsSalud, CCSS), et des hôpitaux de référence ponctuels qui publient un seul PDF et passent à autre chose. Chacun utilise une langue, une mise en page, un format d'échéance et une politique de connexion différents. Vérifier ne serait-ce que trente d'entre eux chaque matin est un poste à temps plein, et celui que vous sautez le mardi est celui qui s'est clôturé le vendredi. Ce problème de surveillance est exactement ce que l'architecture de Trinta existe pour résoudre. Voici comment cela fonctionne réellement sous le capot. ## Des centaines de connecteurs écrits à la main, pas un scraper magique Le raccourci tentant, quand vous devez lire des centaines de sources, est de construire un unique scraper universel astucieux et de le pointer partout. Nous avons essayé cette approche et l'avons délibérément jetée. Chaque portail a ses propres particularités : schémas de pagination, poignées de main anti-falsification (CSRF), fichiers en masse open-contracting (OCDS) livrés sous forme d'archives ZIP mensuelles, sessions invité en deux étapes qui vous remettent un cookie de visiteur avant de vous montrer quoi que ce soit. Un unique moteur générique gère tout cela mal. Alors Trinta fonctionne sur des **connecteurs déterministes écrits à la main** : un petit composant sur mesure par source, chacun réglé sur le comportement réel de ce portail. La flotte est passée d'environ 15 connecteurs à près de 200, et ça continue. Un connecteur pour une API structurée comme TED ou PNCP est simple. Un connecteur pour un portail qui affiche un bouton « Se connecter » mais sert discrètement sa liste d'appels d'offres depuis un point d'accès public sans authentification demande un travail de détective : nous rendons la page une fois, observons quel appel d'API renvoie réellement les données, puis appelons ce point d'accès directement. Cette seule technique a débloqué des dizaines de portails qui semblaient murés de l'extérieur. Quelques principes gardent la flotte honnête : - **Sources officielles uniquement.** Nous remontons les agrégateurs (les sites revendeurs de « global tenders ») jusqu'à l'avis d'origine et ne stockons que l'URL officielle. Un lien d'agrégateur ne compte jamais comme source. - **Ne jamais inventer une échéance.** Si la date de clôture ne vit qu'à l'intérieur d'un PDF, le connecteur la laisse vide plutôt que de deviner, et une étape ultérieure la vérifie. - **Un fichier, un portail.** Chaque connecteur est isolé, de sorte qu'un portail qui change de mise en page ne casse que son propre connecteur, jamais tout le scan. ## Un scan programmé qui tourne sans personne pour le surveiller Les connecteurs sont inutiles s'il faut qu'un humain appuie sur démarrer. Tout le pipeline tourne sur une **tâche cloud programmée** (un cron quotidien sur GitHub Actions) qui ne requiert aucun ordinateur portable ouvert ni personne éveillée. Chaque exécution suit la même séquence disciplinée : 1. **Récolte.** Tous les connecteurs tournent en parallèle, avec un délai d'expiration strict par source pour qu'un portail lent ou cassé ne puisse jamais bloquer ni faire échouer tout le scan. 2. **Ingestion et tri.** Les nouveaux avis sont fusionnés dans le stock, les périmés sont écartés, et le bruit évident est filtré. 3. **Enrichissement, audit, publication.** Les documents sont récupérés, chaque appel d'offres est examiné, et les résultats sont déployés vers le flux en direct. Deux filtres font le gros du travail pendant la récolte. Une **porte de pertinence** compare chaque avis à un profil de mots-clés multilingue (anglais, français, espagnol, portugais, arabe, hébreu), afin qu'un avis turc ou brésilien soit jugé dans sa propre langue, et non dans une traduction approximative. Et un **filtre de périmètre** écarte ce qui a l'air bon mais ne l'est pas : pour un acheteur de systèmes, un avis de pur réapprovisionnement de consommables ou de location d'équipement est exclu, et le filtre connaît le vocabulaire de la location en cinq langues, de sorte que « locacao », « alquiler » et « location » le déclenchent tous. ## Enrichissement documentaire : la liste de fichiers, pas seulement le lien Trouver un appel d'offres n'est que la moitié du travail. L'autre moitié est de le lire, et c'est là que les équipes perdent des heures : ouvrir le portail, chercher le dossier, télécharger chaque annexe. La **couche d'enrichissement documentaire** de Trinta fait cela automatiquement. Un répartiteur oriente chaque avis vers le bon extracteur : - Les avis **TED** sont analysés à partir de leurs données structurées eForms pour trouver le lien vers les documents officiels, qui est ensuite suivi jusqu'au portail de l'acheteur pour lister les fichiers. - Le dossier du **PNCP brésilien** est lu via son API propre de liste de fichiers plutôt que gratté sur la page. - **Tout le reste** passe par un extracteur générique qui lit la page de l'avis et liste les fichiers téléchargeables par type, tout en excluant les liens de navigation, d'aide et de mentions légales pour que la liste reste précise. Cette étape est entièrement déterministe et ne nécessite aucun modèle d'IA, elle tourne donc à bas coût à chaque scan. Le résultat est qu'un appel d'offres arrive souvent avec son lien de dossier et une liste d'annexes déjà jointes, de sorte que l'équipe des offres commence à lire au lieu de chercher. ## Un agent d'audit qui note chaque appel d'offres, et échoue bruyamment La dernière étape est celle que la plupart des outils de surveillance sautent. Après la récolte et l'enrichissement, un **agent d'audit** examine chaque appel d'offres qui n'a pas encore été examiné. Il ouvre les documents accessibles, lit le périmètre, mappe les exigences à ce que le client fournit réellement, et attribue un score d'adéquation avec un bref argumentaire. Ce score, et non un décompte grossier de mots-clés, est ce qui pilote le classement dans le flux, de sorte qu'un lead au score élevé est un lead dont une personne a déjà vérifié les exigences. Une règle de sécurité délibérée est ancrée dans le code, pas seulement dans la documentation : **chaque appel d'offres doit être audité avant d'être diffusé.** Si l'étape d'audit ne peut pas s'exécuter (par exemple, une clé d'API manquante) ou n'audite rien, tout le scan échoue bruyamment et s'arrête. Rien de non examiné n'atteint le flux en direct. Nous préférons ne montrer aucune mise à jour plutôt qu'une mauvaise. ## Jamais de fausses données Sous tout cela se trouve une règle qui façonne chaque choix de conception : **nous ne fabriquons jamais de données pour combler un vide.** Si une valeur n'est pas publique, et les valeurs des marchés le sont réellement sous scellés étonnamment souvent (budgets brésiliens sous certaines lois, avis de travaux allemands, chiffres de conseils du Golfe derrière une connexion), le flux affiche « Non divulgué » avec la raison, jamais un chiffre inventé. Des frais de dossier ne sont pas la valeur du contrat, et nous ne laissons jamais l'un se faire passer pour l'autre. Les avis périmés sont élagués sur une fenêtre de récence. Les avis d'attribution et de résultat, qui n'ont pas de vraie échéance, sont filtrés pour qu'ils ne puissent pas apparaître comme des opportunités en cours. Le bénéfice pour le dirigeant de PME, l'exportateur ou le consultant est simple. Au lieu de patrouiller plus de 1 000 portails et d'espérer que vous les avez tous couverts, vous ouvrez un seul flux quotidien d'appels d'offres appariés, déjà notés pour l'adéquation, portant déjà leurs documents, déjà nettoyés du bruit, des contrats de réapprovisionnement et des avis périmés. Le problème de surveillance ne disparaît pas ; il cesse simplement d'être le vôtre. C'est tout l'intérêt d'un flux quotidien noté et apparié : les centaines de sources continuent de changer chaque nuit, et vous ne voyez jamais que la poignée qui compte pour vous. ## Frequently asked questions **How does TRINTA monitor hundreds of procurement sources?** Through a fleet of hand-written connectors rather than one generic scraper: each connector targets one portal and pulls dated rows from it without a login. A scheduled scan runs daily without supervision, document enrichment retrieves the file list attached to each notice, and an audit agent scores every tender and fails loudly rather than silently. **Why not use a single generic scraper for all portals?** Because government portals have nothing in common structurally. They differ in markup, navigation, session handling, registration walls and publication format, and several publish tenders only as PDFs inside navigation. A generic scraper handles the easy ones and silently misses the rest, which is worse than not covering them at all. **How does TRINTA avoid publishing invented data?** An audit agent scores every tender and is designed to fail loudly rather than degrade quietly, so a source that stops returning real rows surfaces as an error rather than as an empty result that looks like a quiet week. The operating rule is that no fabricated record is preferable to a plausible one. --- All guides: https://trinta.ai/blog · Site index for agents: https://trinta.ai/llms.txt