Un développeur ouvre le noyau d'un agent de prospection dans les appels d'offres, avec 726 tests

Une entreprise a publié un appel d'offres pour des serveurs : le vendeur tient donc un prétexte pour engager la conversation. Mais entre la notification de l'appel d'offres et un appel utile, il y a un travail manuel : ouvrir le cahier des charges techniques, comprendre les équipements, consulter les comptes du client et trouver une personne à joindre. L'auteur d'AI Tender Radar raconte comment il a confié cette préparation à un agent d'IA et publié sur GitHub le noyau de recherche du projet.

Le résultat est une fiche dans Telegram : ce dont le client a besoin, ses indicateurs financiers, qui appeler et par quelles questions commencer. Selon l'auteur, le système fonctionne en production et a traité les appels d'offres de centaines d'entreprises. L'article ne fournit aucune mesure du temps gagné ni de la précision de la recherche ; il convient donc d'évaluer ce cas avant tout d'après l'architecture du système.

Du cahier des charges à la fiche avant l'appel

Le programme collecte les appels d'offres publics et commerciaux portant sur des serveurs, des systèmes de stockage de données et des composants, télécharge les documents et en extrait le texte. Les formats pris en charge sont PDF, DOCX, DOC, XLSX, TXT, ainsi que les archives ZIP et 7z. Les scans sans couche de texte, les RAR et les anciens XLS restent pour l'instant des lacunes dans les données.

Supposons que le titre de l'appel d'offres indique seulement « fourniture d'équipements ». Cela ne suffit pas au commercial. L'agent doit ouvrir les annexes, déterminer la composition de la fourniture, les quantités et les délais, puis trouver le contact du client. Les données sur le chiffre d'affaires, le bénéfice et les capitaux propres proviennent des derniers comptes publiés auprès du fisc russe (FNS). Cela aide à préparer la conversation, mais ne dit pas, en soi, si l'entreprise paiera une livraison donnée.

La fiche comporte les boutons « Je prends » et « Non merci », et l'on peut y ajouter une note. Les leads sont exportés vers Excel. L'agent ne contacte pas lui-même le client et ne promet aucune condition de livraison : il ne connaît ni les prix ni les capacités du vendeur.

L'agent choisit l'itinéraire, le code vérifie les contacts

La première version était une suite d'étapes prédéfinies. Le contact était cherché dans les documents, puis sur le site, puis dans les autres branches prévues. Chaque nouvel appel d'offres exigeait de nouvelles exceptions, et le programme se compliquait.

Dans la deuxième version, le modèle a reçu des outils de lecture de documents, de recherche web, d'ouverture de pages et de récupération des comptes annuels. L'instruction fixe la priorité des sources, et l'agent choisit lui-même quoi ouvrir ensuite. Chaque recherche est soumise à des limites sur le nombre d'étapes et sur les dépenses liées au modèle.

Le détail d'ingénierie le plus utile se trouve après la recherche. Avant d'enregistrer la fiche, un code ordinaire confronte les contacts proposés aux textes que l'agent a réellement lus. Pour un téléphone, on cherche le noyau à dix chiffres du numéro ; pour un nom, ses éléments en tenant compte des terminaisons ; pour une adresse e-mail, une correspondance littérale sans distinction de casse. Les informations non confirmées sont supprimées.

Le système attribue ensuite à la fiche une catégorie : A — une personne avec un téléphone a été trouvée ; B — un téléphone sans nom, ou un contact issu d'un annuaire tiers ; C — pas de téléphone. Seules les deux premières catégories sont envoyées au commercial. Si l'agent n'a pas trouvé de personne avec un numéro, l'appel d'offres est transmis à un modèle de secours.

Mais la correspondance avec une source a des limites nettes. Elle ne prouve pas que le téléphone appartient à la personne indiquée ni qu'il reste à jour. L'auteur reconnaît aussi la possibilité d'une coïncidence fortuite entre des nombres voisins ; le numéro de poste n'est pas vérifié. Il est donc raisonnable de voir dans ce contrôle un filtre contre les contacts inventés, et non une garantie d'avoir le bon destinataire.

Ce que l'on peut reprendre dans son propre produit

D'après l'auteur, le noyau ouvert comprend l'agent, les outils, la vérification des contacts, le journal, l'envoi via Telegram, les notes et l'export. Il annonce 726 tests automatisés sur des données synthétiques et une licence AGPL-3.0. Les connecteurs vers les plateformes d'achats, l'instruction de travail et les paramètres serveur restent fermés. Pour un lancement autonome, il faudra préparer ces éléments séparément.

L'intérêt pratique du cas tient à la répartition des responsabilités. Le modèle analyse des documents hétérogènes et choisit l'itinéraire de recherche, tandis que le programme limite les dépenses et vérifie les informations avant l'envoi. Les doublons, l'attente des documents et les réponses ambiguës de Telegram sont traités à part : ce sont précisément ces détails qui déterminent le confort d'usage au quotidien.

Un développeur gagnera ici à étudier la vérification des résultats et la gestion des défaillances. Un product manager, à mesurer sur ses propres appels d'offres la part de fiches utiles, le temps de préparation et le coût d'un lead. Sans ces indicateurs, le récit montre une approche qui fonctionne, mais ne démontre pas encore son effet économique.