La plupart des problèmes de matching se résolvent de la même manière. On écrit une fonction de scoring, on pondère une poignée de champs, on trie les résultats, et on livre. Puis les exigences changent, et on se retrouve à rouvrir la fonction pour ajouter un nouveau if. Six mois plus tard, plus personne n'est capable d'expliquer pourquoi tel match a obtenu le score qu'il a eu.

Sur une plateforme de levée de fonds que nous avons construite, l'objectif était de mettre en relation les fondateurs avec les bons investisseurs. Nous avons d'abord essayé la voie de la fonction de scoring. Elle a fonctionné, jusqu'à ce que la définition du mot « bon » se révèle être une cible mouvante qui vivait dans les conversations, pas dans les colonnes.

Alors nous avons tenté autre chose. Nous avons donné la base de données à un modèle de langage et l'avons laissé faire le raisonnement.

Le montage

L'agent tourne sur Claude via le Vercel AI SDK. Il ne reçoit pas une liste figée de candidats. Il reçoit des outils : un pour exécuter du SQL en lecture seule sur un réplica, un pour décrire une table, et le schéma. Ses instructions sont une grille de critères, pas un algorithme. D'abord les éliminatoires, puis les signaux principaux comme le secteur, le stade et la taille du ticket, ensuite les signaux plus subtils, et une préférence pour les matches que l'utilisateur n'a pas encore vus.

Il interroge lui-même la base de données, présélectionne une vingtaine de candidats, attribue un score à chacun, et renvoie les meilleurs via un appel d'outil structuré au schéma fixe. Si rien ne franchit la barre, on lui demande de ne rien renvoyer plutôt que de gonfler la liste avec des noms faibles.

Cette dernière instruction compte plus que toutes les autres. Un système de matching qui produit toujours des résultats apprend aux utilisateurs à l'ignorer.

Ce que cela nous a apporté

La logique vit désormais dans le langage, ce qui signifie que les personnes qui comprennent le métier peuvent la lire et la discuter. Quand la définition d'un bon match évolue, nous modifions la grille de critères au lieu de redéployer une fonction de scoring. L'agent explique aussi son raisonnement, si bien qu'un humain qui examine un match voit pourquoi il a été proposé, et pas seulement un chiffre.

Il gère les cas ambigus qu'une fonction figée n'aurait jamais su traiter. Un fondateur dont le stade indique une chose mais dont le deck en dit une autre. Un investisseur dont la thèse affichée et l'historique réel ne s'accordent pas. Le modèle pèse la contradiction comme le ferait une personne.

Quand la logique de matching vit dans un prompt, ceux qui connaissent le métier peuvent enfin la lire.

Ce qu'il a fallu mettre en cage

Confier une base de données à un LLM est exactement aussi dangereux que cela en a l'air, et c'est pourquoi cette liberté est clôturée de tous les côtés.

Il ne touche jamais qu'à un réplica en lecture, via une connexion qui ne peut physiquement pas écrire. Aucun SQL, aussi créatif soit-il, ne peut modifier les données. Nous plafonnons la quantité qu'il peut extraire, afin qu'une requête maladroite se dégrade en douceur au lieu de marteler la base. La sortie finale passe par un schéma strict, de sorte que le code en aval n'a jamais à analyser de la prose. Et l'exécution entière est un workflow durable qui suit les coûts, rembourse le crédit de l'utilisateur en cas d'échec ou d'absence de résultat, et laisse une trace que nous pouvons auditer.

Nous ne le laissons pas non plus agir sur ses propres conclusions. Les matches qu'il produit passent par une étape de revue humaine avant que quiconque ne soit présenté. Le modèle propose. Ce sont les humains qui disposent.

Quand c'est le bon choix, et quand ce ne l'est pas

Cette approche fait ses preuves quand la règle est véritablement floue et ne cesse de changer, quand les entrées sont non structurées, et quand une mauvaise réponse est rattrapable. Le matching, le triage et le classement entrent dans ce moule.

C'est le mauvais choix quand la règle est nette et stable. Si vous pouvez écrire la logique sous forme de fonction claire, écrivez la fonction. Elle sera plus rapide, moins chère et plus facile à faire confiance. N'allez pas chercher un modèle pour faire de l'arithmétique.

Le glissement intéressant n'est pas qu'un LLM sache écrire du SQL. C'est que, correctement clôturé, il vous permet de sortir toute une catégorie de jugements hors du code et de les faire entrer dans le langage, où ils sont plus faciles à modifier et plus faciles à expliquer. L'ingénierie n'est plus dans l'algorithme. Elle est dans la cage que vous construisez autour de lui.