Comment Trinta surveille des centaines de sources chaque jour : au cœur de l'architecture
27 juillet 2026 · 7 min de lecture
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 :
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 :
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.
Questions fréquentes
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.
Partager cet article
Reference
Articles similaires
Appels d'offres DNCP au Paraguay : le guide du fournisseur pour les marchés publics
4 min de lecture
Appels d'offres SICOP au Costa Rica : comment le leader numérique d'Amérique centrale achète
5 min de lecture
Les marchés publics dans le Golfe : l'Etimad saoudien, les Émirats arabes unis et le Qatar, et comment se qualifier
10 min de lecture
Comment l'IA note un appel d'offres par rapport à votre catalogue produits
8 min de lecture
L'IA dans la commande publique : comment le machine learning transforme l'intelligence des appels d'offres
9 min de lecture