Repérer les missions pertinentes parmi plus de 8 000 annonces venues de 13 sources

Le contexte et le problème

Je cherche mes missions freelance sur de nombreux sites : places de marché freelance, sites carrière d’entreprises, marchés publics.

La même mission paraît souvent sur plusieurs sites, sous des identifiants différents. La plupart des annonces ne me concernent pas.

La collecte et le tri représentent l’essentiel du temps perdu dans une recherche de mission. L’objectif : ne lire que les annonces qui méritent une décision.

Le statut

Projet personnel d’Elytre, distinct des missions clients. Il est en service : deux collectes par jour alimentent la base, et je m’en sers pour ma propre recherche.

Relevé historique : plus de 8 000 annonces cumulées et 13 sources dans le périmètre documenté en septembre 2026. Le compteur est cumulé, pas quotidien.

Les dates et mon rôle

Le développement a commencé le 29 juillet 2026. Les marchés publics ont été ajoutés le 3 août, deux places de missions freelance le 2 septembre.

Conception, architecture, décisions et validation : Robin Lasserye. Le code est produit avec des assistants de programmation.

L’architecture et le flux

MCP (Model Context Protocol) est le protocole qui relie un assistant IA à un outil. Le flux tient en six étapes.

1. Collecter. Un connecteur par source lit les annonces : API publiques, flux XML de diffusion, données structurées des fiches.
2. Normaliser. Chaque annonce est ramenée au même schéma : entreprise, titre, contrat, lieu, montant journalier quand il est écrit.
3. Dédoublonner. Une empreinte est calculée sur l’entreprise et le titre normalisés. Un doublon enrichit l’annonce existante au lieu d’en créer une seconde.
4. Qualifier. Quatre conditions : contrat non salarié, score de mots-clés suffisant, montant journalier compatible, lieu compatible. Les critères vivent dans un seul fichier de configuration.
5. Stocker et notifier. Les annonces vont dans une base SQLite. Les annonces qualifiées sont publiées dans une messagerie d’équipe, où une réaction suffit à changer leur statut.
6. Exposer. Un serveur MCP déclare six outils : rechercher des missions, lire le détail d’une mission, changer son statut, obtenir une vue d’ensemble, lister les missions à traiter, lister les postes salariés qui peuvent s’aborder en prestation.

L’assistant IA interroge ainsi la base en langage courant, sans que j’écrive de requête.

Les choix et les compromis

Ne lire que ce qui est publié pour être lu par une machine : API publiques, flux de diffusion, exports. Un moteur de recherche qu’il faudrait paginer ne se lit pas. Un robots.txt qui dit non est un non.

Un montant journalier absent ne disqualifie pas une annonce : elle passe en revue manuelle. Rater une bonne mission coûte plus cher que lire une mauvaise annonce.

Le dédoublonnage porte sur une empreinte, pas sur l’identifiant de la source : la même mission porte un identifiant différent sur chaque site.

L’outil n’envoie aucune candidature ni aucun message. La machine trie, je décide.

La méthode de validation

La première collecte réelle a servi de test. Sur 652 annonces, le moteur en déclarait 447 qualifiées, dont des postes de commercial et de designer.

La cause : une recherche de mots-clés par simple sous-chaîne. « cto » était trouvé dans « director », « rag » dans « storage ».

Après correction, avec une recherche à frontières de mots, les mêmes 652 annonces donnent 64 annonces qualifiées.

Chaque défaut trouvé sur données réelles est devenu un test de non-régression. Un autre test lance le serveur MCP comme le ferait un assistant, et appelle réellement les six outils.

Les résultats et les limites

Résultat mesuré sur le tri : 447 puis 64 annonces qualifiées, sur les 652 mêmes annonces. Relevé historique : plus de 8 000 annonces cumulées et 13 sources dans le périmètre documenté en septembre 2026.

Première limite : le collecteur ne voit pas tout le marché. Plusieurs places de marché freelance interdisent la lecture automatique. Elles restent hors périmètre, par choix.

Le site d’où viennent la plupart de mes candidatures n’est donc pas lu. Le collecteur n’est pas mon canal principal de candidature : il sert à repérer, à recouper et à suivre.

Jusqu’au 1er septembre 2026, la colonne « source » étiquetait mal une grande partie des avis de marchés publics. Le défaut est corrigé. Les statistiques par source antérieures à cette date sont à refaire.

Avant cette même date, la collecte d’une source européenne de marchés publics était tronquée : les avis les plus récents manquaient. Ce trou ne se mesure pas après coup.

Deux des treize sources ne sont pas des sites d’annonces au sens usuel : l’une fournit des pistes, l’autre ne compte que quelques entrées.

Le repérage des postes salariés qui peuvent s’aborder en prestation est une heuristique, pas une mesure.

L’exploitation

Deux collectes par jour, à 7 h 30 et à 18 h, lancées par une tâche planifiée du système (systemd). Une collecte manquée est rattrapée au démarrage de la machine.

Après un échec, une unité de rattrapage rejoue la collecte une fois, vingt minutes plus tard.

Fin août 2026, la collecte a échoué trois jours de suite. Elle démarrait quelques secondes après une sortie de veille, avant le retour du réseau. Le collecteur attend désormais que le réseau réponde.

Une leçon d’exploitation : un message d’information n’est pas un correctif. La troncature était écrite dans le journal depuis le début, et personne ne le lisait. Elle fait maintenant échouer un test.