Un agent qui examine les appels d’offres chaque jour et indique lesquels méritent une candidature

Le client et ses difficultés

Cette entreprise de construction répond à des appels d’offres publics et rencontrait un problème récurrent. Chaque jour, quelqu’un devait consulter les portails d’appels d’offres, parcourir les listes, ouvrir une douzaine d’annonces et vérifier si l’une d’elles méritait une candidature. Cette tâche prenait une bonne partie de la journée, était répétitive et facilitait les oublis, surtout le lundi matin, après l’accumulation des annonces du week-end.

Les délais de dépôt sont courts. Une annonce repérée trois jours après sa publication est souvent déjà inaccessible, car réunir les documents nécessaires prend du temps. La valeur ne réside donc pas seulement dans la découverte d’un appel d’offres, mais dans sa découverte rapide.

Le principal problème restait toutefois le bruit. La grande majorité des annonces concernait des fournitures ou des travaux hors du profil de l’entreprise. Tout examiner pour en rejeter plus de quatre-vingt-dix pour cent faisait perdre du temps à la personne qui devrait préparer les devis. Autre point facile à oublier : le véritable critère de décision n’est pas le montant du marché, mais les conditions de participation. Les références exigées et la garantie de soumission peuvent écarter l’entreprise d’un appel d’offres pourtant intéressant financièrement. Il faut donc lire ces conditions avant de commencer à préparer une offre.

Ce que nous avons mis en place

Nous avons créé un agent qui effectue chaque jour tout le parcours, de la collecte des annonces jusqu’à la recommandation.

La collecte utilise Python et les API publiques des bases d’appels d’offres. L’agent consulte une source européenne et une source nationale afin que l’entreprise n’ait pas à surveiller deux portails. Une tâche cron le lance à heure fixe pour que les nouvelles annonces soient examinées au plus tard le lendemain matin.

Le premier filtre est peu coûteux et déterministe. Un score heuristique trie les avis par codes sectoriels, mots-clés et type de marché, en distinguant notamment les travaux de construction des fournitures. Il élimine l’essentiel du bruit sans solliciter de modèle ni générer de coût associé.

Les annonces qui franchissent ce filtre sont transmises au modèle chargé de l’évaluation. Celui-ci reçoit le texte de l’avis, les conditions de participation et le profil de l’entreprise, puis renvoie un verdict — oui, peut-être ou non — toujours accompagné d’une justification. Cette explication était plus importante qu’il n’y paraît : un verdict sans motif ne sert à rien, car personne ne risquerait de renoncer à un appel d’offres sur la seule base d’un non automatisé.

Le résultat est affiché dans un tableau de décision basé sur Supabase. Chaque annonce comporte un verdict, une justification et un statut que l’entreprise définit elle-même : candidature déposée ou rejetée. Le tableau sert ainsi à la fois de file de contrôle et d’historique des décisions.

Fonctionnement actuel

Chaque jour, l’agent récupère les nouvelles annonces des deux sources, les soumet au score et au modèle, puis met à jour le tableau. Le responsable des appels d’offres ouvre une seule vue le matin et examine quelques entrées avec leur verdict, au lieu de parcourir les portails. Les annonces rejetées restent dans le tableau avec leur justification : l’équipe peut les vérifier et revenir sur sa décision à tout moment.

Les statuts « candidature déposée » et « rejetée » sont mis à jour manuellement, et c’est intentionnel. Cette décision doit rester humaine, car seule une personne sait si l’entreprise dispose de la capacité nécessaire à ce moment-là. La mise en place a pris environ une semaine.

Résultats

Les bases sont examinées automatiquement une fois par jour, sans intervention humaine. L’agent surveille simultanément deux sources d’appels d’offres, l’une européenne et l’autre nationale. Chaque annonce qui franchit le premier filtre reçoit du modèle un verdict oui, peut-être ou non. Les marchés hors du profil de l’entreprise sont automatiquement écartés, et il ne reste qu’une fraction du volume initial à examiner.

Ce que nous ferions autrement

Au départ, nous avons trop compté sur le modèle. La première version lui envoyait presque tout ce que renvoyait l’API, ce qui rendait le processus plus coûteux et plus lent que nécessaire. L’ajout d’un filtre heuristique peu coûteux avant le modèle a rendu l’approche viable ; c’est ainsi que nous commencerons la prochaine fois.

Deuxième leçon : les conditions de participation. Nous avons intégré les références et la garantie de soumission à l’évaluation tardivement, alors qu’elles sont souvent déterminantes. En commençant par ces critères, nous aurions obtenu des premiers verdicts plus pertinents et gagné plus vite la confiance de l’entreprise.