Recherche en langage naturel

L'écart

La plateforme de sourcing donnait aux acheteurs l'ensemble du marché carbone au même endroit : des dizaines de milliers de projets, plus de 40 données par projet, tous filtrables et triables. Le filtrage était exhaustif, et il était lent. Exprimer ce que l'on voulait passait par une longue suite de sélections. Des critères formulés naturellement comme "Nature-based removal" ne correspondent pas à un seul filtre ; ce sont quinze types de technologies et quelques mécanismes combinés dans une catégorie de projets couramment utilisée. Un acheteur qui savait exactement ce qu'il voulait dire passait quand même 15+ clics à assembler une liste de filtres à soumettre pour trouver ce qu'il cherchait.

Ce coût touchait tout le monde, qu'il s'agisse des experts qui savaient quoi chercher (par exemple des projets NBR labellisés CCP, notés BeZero AA+, sur un registre ICROA) ou des acheteurs qui voulaient explorer et comprendre le marché (par exemple : quels sont les meilleurs projets ocean-based ?). Le filtrage fonctionnait. Il rendait simplement tout le monde plus lent, plusieurs fois par jour.

En 2026, avec un bon setup IA, un designer peut voir l'écart, en cadrer le périmètre, puis s'en charger lui-même. C'est ce que j'ai fait.

Construit en deux semaines

Pour ça, je n'ai pas construit une interface de chat. Nous avions déjà un système de filtres et de tri solide, ainsi qu'un ensemble de données structurées. Ce dont nous avions besoin, c'était d'une interprétation probabiliste en langage naturel de la requête d'un utilisateur, que nous pourrions transformer en résultats déterministes. Langage naturel en entrée, un ensemble de filtres visible et modifiable en sortie. Vous tapez ce que vous cherchez, l'IA le traduit en état de filtres, et vous voyez exactement ce qu'elle a fait. Elle vous a mal compris ? Ou peut-être n'avez-vous pas formulé votre requête exactement comme vous le vouliez ? Aucun problème : il suffit d'ajuster les filtres directement. L'IA réduit simplement le coût d'exprimer ce que vous voulez. Elle ne vous retire pas la décision.

De quelques maquettes Figma rapides, à une preuve de concept fonctionnelle construite avec Cursor sur de vraies données de projets, puis à une PR fonctionnelle en trois jours et un déploiement de bout en bout en deux semaines, le projet est passé de l'idée à la prod sans jamais devenir un item de roadmap. L'idée était claire et le coût du build suffisamment faible pour que trop réfléchir aurait été l'erreur. Les ingénieurs ont été précieux par leurs retours, tout en pouvant rester concentrés sur les sujets roadmap plus prioritaires sur lesquels ils travaillaient.

L'expérience était simple : taper une requête en langage naturel dans la barre de recherche, puis laisser un petit agent Haiku, conscient de l'ensemble des filtres et options de tri à sa disposition et connaissant la terminologie clé, interpréter la requête et appliquer automatiquement, avec un retour visible, un ensemble de filtres et une logique de tri correspondant aux critères. L'utilisateur pouvait ensuite revoir et modifier cela si besoin, soit de nouveau en langage naturel, soit via des patterns de filtre et de tri plus classiques.

Ce que ça m'a appris

L'IA a fait s'effondrer le coût de l'essai. Dans le pire des cas ici, c'était une semaine pour apprendre que l'idée ne fonctionnait pas, face à un vrai build et à de vraies données. Elle m'a aussi permis de prototyper sur le dataset réel en quelques jours, ce qui compte : la recherche est difficile à juger sur des maquettes. On voit si ça marche seulement quand ça traite de vraies données, désordonnées.

Et l'effet de levier d'un designer a changé. Un travail UX-first comme celui-ci, chez Patch, était autrefois un item roadmap qui concurrençait du temps d'ingénierie et perdait la plupart du temps. Maintenant, c'est le side project d'un seul designer, construit et livré avec un peu de soutien. Le travail qui se fait n'est plus limité au travail qui est priorisé.