Phosphoria : trier les offres de mission avec l'IA, sans lui laisser la décision

Le besoin était de centraliser les offres, de les filtrer, d'en faciliter la lecture et de repérer celles qui correspondent au cabinet. La plupart ne lui correspondent pas : elles visent une autre région ou un autre métier, elles sont périmées, elles apparaissent sur plusieurs plateformes à la fois, ou ce sont des communications des plateformes elles-mêmes.

Innéair a construit un pipeline en quatre étages : il recueille les offres, les trie, étiquette et note celles qui restent, puis compose les e-mails du jour. Le tri a écarté neuf offres sur dix, et aucune n'a été jetée : chacune reste en base avec son motif, ce qui permettra de régler les seuils sur des cas réels. Un e-mail que le pipeline ne sait pas lire ne disparaît pas non plus : il part dans un canal de maintenance, avec son expéditeur, son sujet et l'erreur rencontrée, et il n'empêche pas les autres e-mails d'être traités.

Les candidatures, elles, restent écrites et envoyées à la main : le pipeline ne démarche personne.

La décision qui structure le pipeline a été prise avant la première ligne de code : il lit les alertes que les plateformes envoient déjà, dans une boîte dédiée, plutôt que d'aspirer leurs sites. Un robot qui parcourt un site comme LinkedIn est la pièce la plus fragile à maintenir, la plus exposée au blocage et la plus risquée sur le plan juridique. Le prix de ce choix est de dépendre de ce que couvrent les alertes de chaque plateforme.

Chaque source a son propre adaptateur, qui ramène ses offres à un même modèle : trois lisent des alertes reçues par e-mail, et une quatrième recherche chaque jour les publications publiques qui annoncent une mission.

Le modèle de langage pose seulement des étiquettes choisies dans des listes fermées : le métier, la posture attendue, le type de contrat, le taux journalier quand il est annoncé. La note de 0 à 100 vient d'une formule écrite dans le code et testée, à partir d'un score de base par métier, de modificateurs et de plafonds sur les signaux faibles. La même offre reçoit donc la même note, même si le modèle change ; chaque note porte ses raisons, affichées dans l'e-mail du jour ; et ajuster un barème revient à modifier un fichier testé.

Trois garde-fous encadrent le modèle. Des règles tranchent avant lui les intitulés évidents, et il ne décide que des cas ambigus. Un taux journalier qu'il annonce mais qui n'apparaît nulle part dans le texte de l'offre est rejeté. Enfin, quand il ne sait pas répondre, chaque source a sa valeur par défaut.

Comme le tri a lieu avant l'étiquetage, seules les offres retenues atteignent le modèle : le pipeline coûte de l'ordre d'une vingtaine d'euros par mois à faire tourner.

Le pipeline tourne dans n8n, un orchestrateur où le code vit dans des blocs sans typage, sans tests et sans historique. Innéair n'a pas accepté ces limites. Le cœur métier vit dans un dépôt Git, et chaque ligne du code métier se retrouve dans les blocs de n8n, avec un adaptateur minimal, ce qu'un audit vérifie. Le code est typé en TypeScript strict, sans étape de compilation ; les barèmes sont figés, l'horloge est injectée dans tout ce qui dépend de la date, et une fonction renvoie un résultat explicite plutôt qu'une valeur vide qu'il faudrait interpréter.

L'analyse statique, le contrôle des types et les tests passent avant chaque commit. Une procédure écrite compare le code déployé dans n8n à celui du dépôt. Le cœur métier n'a aucune dépendance à n8n : si le pipeline doit un jour quitter cet outil, il partira tel quel.

Chaque choix important a fait l'objet d'une décision d'architecture écrite : le contexte, la décision, les options écartées et leurs raisons. Avant de construire, Innéair a évalué trois outils existants. Du plus proche, elle a repris trois principes de conception, mais pas le logiciel lui-même : cinq écarts le rendaient inadapté, dont une licence qui aurait pu bloquer un usage commercial.

Le code est découpé par domaine plutôt que par étape du pipeline : un module se définit par ce qu'il connaît, pas par le moment où il s'exécute. Le cœur métier ne fait aucun appel extérieur, et c'est la partie que le réglage des barèmes viendra modifier. L'option d'un agent d'IA qui remplacerait tout le pipeline a été étudiée, puis écartée pour trois raisons : savoir pourquoi une offre passe ou non, garder un tri déterministe et ne pas dépendre d'un fournisseur d'IA. La décision écrit aussi dans quelles conditions elle serait à revoir.

En juillet 2026, Innéair a écrit pour Phosphoria un second outil. Pennylane permet d'exporter les fiches de fournisseurs ou de clients incomplètes, puis de réimporter le fichier complété. L'outil remplit les colonnes vides à partir de bases publiques et gratuites : SIRET, adresse, code postal, ville et pays. Pour un numéro de TVA français, il en extrait le SIREN et interroge l'API Sirene ; pour un numéro européen, il interroge VIES. Il corrige aussi le code pays, que Pennylane met souvent à « FR » par défaut.

Quand une fiche n'a pas de numéro de TVA, l'outil cherche l'entreprise par son nom, mais il ne complète la fiche que si un seul établissement actif correspond exactement : écrire un mauvais SIRET dans la comptabilité serait plus grave que de laisser une ligne à traiter. Il produit deux fichiers, l'un prêt à réimporter, l'autre à reprendre à la main avec des liens de vérification. Une version en ligne traite le fichier dans le navigateur, sans l'envoyer nulle part ; une version à télécharger y ajoute les entreprises européennes.

Le pipeline a été livré et mis en production en septembre 2026. Il compose deux e-mails du jour, envoyés à 8 heures à la responsable administrative et financière de Phosphoria : les missions à traiter et les pistes de prospection. Un jour sans offre retenue, aucun e-mail ne part. Un troisième canal, la maintenance, part vers Innéair avec les e-mails illisibles et les erreurs. Le code ne sait pas qui lit quoi : il émet des canaux, et leur destinataire se règle dans la configuration.

Chaque offre retenue porte deux liens, « pertinente » et « pas pertinente ». Ces retours serviront à régler les barèmes. Les évolutions suivantes sont déjà écrites : de nouvelles sources, et des signaux d'achat qui précèdent les offres, comme une levée de fonds ou l'arrivée d'un nouveau dirigeant financier.