Finch

Le conseiller d'achat IA qui n'a rien à vendre

Type

Case study

Timeframe

4 days

Toolkit

Figma & AI agents

Year

2026

Problem

Quand on cherche à acheter un laptop aujourd'hui, tous les outils disponibles travaillent pour quelqu'un d'autre que l'acheteur. Google sert ses annonceurs, le bot d'un site marchand sert la conversion et le panier moyen. Aucun ne dira jamais « ce modèle est surcoté » ou « c'est moins cher ailleurs » : structurellement, il est juge et partie. Il manque un quatrième modèle, un agent loyal à l'acheteur par construction : pas de commission, pas de stock à écouler, le droit de dire « n'achète pas ».

Solution

J'ai conçu Finch, un agent conversationnel qui conseille l'achat de laptops sans toucher aucune commission. Il cerne le besoin en deux échanges, recommande deux machines au maximum, trouve les annonces réelles du jour et vérifie pour l'utilisateur les pièges du reconditionné. Le parti pris central : la loyauté n'est pas affichée, elle est rendue visible dans l'interface. Chaque annonce porte des badges qui séparent ce qui est confirmé sur la fiche de ce qu'il reste à vérifier avant d'acheter. La confiance devient un composant, pas un argument marketing.

Finch est un projet personnel mené de bout en bout : recherche, conception, design d'interface, prompt engineering et mise en production. Approche AI-native, avec Figma pour le design, Lovable pour le prototypage et la mise en ligne, et Gemini pour le moteur conversationnel et la recherche web en temps réel.

L'objectif n'était pas de lancer une startup, mais de tester une hypothèse de design : la loyauté d'un agent IA n'est pas un parti pris éthique, c'est une décision d'architecture. Voici les trois décisions qui l'ont prouvé.

Décision 1 : Rendre les hallucinations impossibles, pas improbables

Le problème. Aux premiers tests, l'agent produisait des liens produits d'apparence parfaite : adresse propre, identifiant crédible. Ils menaient vers des pages d'erreur. Le modèle reconstruisait les URL de mémoire. J'ai durci les consignes anti-hallucination trois fois ; il a recommencé trois fois.

L'arbitrage. J'ai compris qu'un prompt exprime une intention, jamais une garantie. La solution n'était pas une meilleure consigne, mais un changement d'architecture : ne plus jamais demander d'URL au modèle. L'agent fournit désormais des mots-clés, et c'est le code de l'application qui construit les liens vers la recherche interne de chaque marchand.

Le principe. Le modèle décide du conseil, le système garantit les liens. Cette frontière entre ce qu'on délègue au modèle et ce qu'on verrouille dans le code est, selon moi, le cœur du métier quand on conçoit un produit IA fiable.

Décision 2 : Une question conversationnelle ne se découpe pas comme un formulaire

Le problème. Ma question d'ouverture demandait trois choses à la fois (neuf ou reconditionné, transport, budget), avec des réponses rapides à cliquer. Le système générait des boutons absurdes du type « reconditionné, léger, moins de 500 € » , des combinaisons qui ne couvraient qu'une fraction arbitraire des cas possibles.

L'arbitrage. Mathématiquement, on ne couvre pas un espace à trois dimensions avec quatre boutons. J'ai redécoupé : une seule dimension par série de réponses rapides, et un champ libre maintenu pour ceux qui savent déjà ce qu'ils veulent. Les deux ne s'opposent pas, à condition que chacun fasse ce qu'il sait faire, l'un accélère les cas simples, l'autre absorbe la nuance.

Le principe. Les réponses rapides doivent être exhaustives sur leur dimension, sinon elles excluent l'utilisateur au lieu de le guider (heuristiques de Nielsen : flexibilité d'usage, prévention des impasses).

vs

Décision 3 : Rendre la fiabilité lisible d'un coup d'œil

Le problème. Mes premiers badges sur les annonces affichaient « Batterie : absente ». Les testeurs comprenaient « le laptop n'a pas de batterie », alors que cela signifiait « l'information n'est pas sur la fiche ». Le code couleur à trois états n'était jamais expliqué.

L'arbitrage. J'ai reformulé chaque badge du point de vue de l'utilisateur (« Batterie : à vérifier »), réduit à deux états visuels lisibles, ajouté une légende, et rendu l'interface robuste : toute valeur inattendue du modèle bascule automatiquement vers « à vérifier » plutôt que d'afficher une donnée brute.

Le principe. La loyauté ne doit pas être affirmée, elle doit être visible dans l'interface. Ces badges sont la signature du produit : ils matérialisent, dans l'interface, ce qu'un bot marchand ne dira jamais.

Méthode

Le projet a été conçu avec un workflow entièrement AI-native : itérations rapides du moteur conversationnel par prompt engineering, prototypage et mise en production sur Lovable, et tests d'utilisabilité guérilla auprès d'utilisateurs non-experts pour valider la lisibilité des recommandations. Chaque bug rencontré (hallucinations, saturation du modèle, débordements de format) a donné lieu à une décision de design, pas seulement à un correctif technique.

Limites assumées

Finch est une démonstration, pas un produit fini, et c'est un parti pris. Sa fonction de veille (« je surveille les arrivages pour toi ») est simulée, alors que c'est elle qui distingue un véritable agent d'un chatbot : agir quand on ne lui demande rien. Sa connaissance des catalogues marchands est encodée manuellement et ne passerait pas à l'échelle — dans une vraie équipe, ce serait une base de données maintenue, avec un responsable désigné.

Ces limites ne sont pas des oublis : ce sont les frontières que j'ai choisi de poser pour livrer un produit testable en quelques jours plutôt qu'un projet jamais fini.