Comment Digital Vantage a réuni trois API gouvernementales incompatibles en un seul flux de leads — 1 253 lignes, deux dépendances, deux jours
Un outil interne de Digital Vantage : un bot headless qui passe chaque jour au crible trois sources gouvernementales d’appels d’offres, élimine le bruit et ne transmet que les correspondances réelles, sur Discord et par e-mail. Le cas met en avant une compétence d’intégration — s’attaquer à une API publique mal conçue et en extraire un flux de données exploitable. Une réalisation de référence, pas encore utilisée en production.

En Pologne, les appels d’offres publics pour des travaux de développement existent, mais ils sont dispersés entre trois systèmes que personne n’a conçus pour être lus par une machine : les marchés publics nationaux, le registre des marchés au-dessus des seuils européens et les appels à propositions des projets financés par l’UE. Pour savoir ce que faisait le marché, il fallait ouvrir trois sites et parcourir des avis portant sur des livraisons de toner.
L’examen manuel échoue non pas parce qu’il est fastidieux, mais parce que la densité du signal est trop faible : sur une fenêtre de 72 heures, les trois sources ont produit 71 avis, dont seulement 6 correspondances réelles. Six résultats en trois jours, c’est trop peu pour justifier d’ouvrir trois portails chaque jour — et bien trop pour pouvoir se permettre d’en manquer. S’y ajoutent trois API sans contrat ni garantie de service, libres de changer la forme de leurs réponses n’importe quel jeudi.
Chacune des trois API est défaillante à sa manière, et chacune a demandé une réponse différente. La première filtre côté serveur : la précision est donc de 1:1 et la bande passante est économisée. La deuxième fait correspondre les codes de classification de façon beaucoup trop large (quatorze fois plus de bruit que de signal) ; nous avons donc ajouté un filtre local. La troisième n’a aucune liste publique — on peut seulement demander « l’avis numéro N existe-t-il ? » ; nous parcourons donc les identifiants dans l’ordre croissant, derrière un curseur persistant.
Tout converge vers un type de données unique, et le diable se cache dans la normalisation des formats de codes et de dates. La cadence des canaux est séparée sans second mécanisme : Discord reçoit une notification immédiate, l’e-mail est un récapitulatif envoyé à heures fixes. L’ensemble tient en 1 253 lignes de TypeScript et deux dépendances de production — car avec trois API susceptibles de changer sans préavis, le code le moins cher à maintenir est celui qui n’existe pas.
Trois sources incompatibles sont devenues un seul flux en deux jours — d’un répertoire vide à une exécution de bout en bout, avec des notifications sur deux canaux. Le radar mesure désormais un signal réel : 71 avis récupérés → 6 correspondances sur une fenêtre de 72 heures, avec une précision totale sur une source et un bruit de quatorze pour un filtré sur une autre.
C’est un résultat d’ingénierie, pas un résultat commercial, et nous le lisons comme tel. Le radar n’est pas encore en production : il n’y a donc ni chiffre de disponibilité ni nombre de leads par mois ; nous ne prétendons pas qu’il a accéléré quoi que ce soit, parce qu’il n’a encore rien accéléré. La valeur réside dans la compétence : la rédaction de cette étude de cas a mis au jour un véritable bug dans l’API d’un tiers (un endpoint qui ignore le numéro de page) — la preuve la plus honnête qui soit de notre thèse, à savoir qu’avec une API sans contrat, le plus difficile n’est pas d’écrire le client, mais de remarquer que le serveur ne fait pas ce qu’il a annoncé.
Trois API gouvernementales sans contrat réunies en un seul flux de correspondances (71 → 6 en 72 h), en 1 253 lignes et deux dépendances.

J’automatise la partie répétitive — de la surveillance des données jusqu’aux notifications, comme dans ce radar.