Recommandations d'outils via Grounded Search : comment LucidFlow évite le piège de l'hallucination LLM

Demandez à un LLM générique quel outil utiliser pour un processus métier spécifique et vous obtenez des recommandations confiantes avec un schéma d'échec prévisible : le modèle recommande des outils qui étaient les meilleurs de leur catégorie il y a deux ou trois ans (le millésime de ses données d'entraînement), cite une tarification datée ou fabriquée et cite des URL produit qui soit redirigent, soit renvoient 404, soit pointent vers un produit complètement différent. Même les modèles frontier font ça, parce que la tâche de recommandation elle-même est intrinsèquement temporelle, la bonne réponse change chaque trimestre au fur et à mesure que de nouveaux outils sortent, que les acteurs en place augmentent leurs prix et que les catégories se consolident. Aucune quantité d'échelle ne corrige un problème de millésime de données d'entraînement.

Le mode d'échec concret qu'on a audité dans la Knowledge Base LucidFlow avant de livrer la couche recherche ancrée : les modèles recommandaient des plateformes RPA de 2022 pour des tâches où un concurrent natif IA millésime 2025 a explicitement pris la catégorie, citaient une tarification annuelle basée sur des pages de prix publiques de 2023 qui sont depuis passées derrière des murs de ventes enterprise, et citaient avec confiance des URL qui étaient la page produit du vendeur il y a trois ans mais qui sont maintenant une redirection vers une page d'accueil générique. Les recommandations se lisent comme faisant autorité parce que le modèle est bon pour écrire de la prose qui fait autorité. Elles échouent comme orientation réelle de sélection de produits.

La couche de recommandation d'outils LucidFlow utilise Gemini 3.1 Pro avec ancrage Google Search comme fournisseur primaire. Le modèle est invoqué avec l'option Google Search activée dans la configuration de génération, ce qui permet à Gemini de faire des recherches web en temps réel pendant la réponse et d'ancrer sa sortie dans les pages qu'il récupère. Le prompt instruit explicitement le modèle de CHERCHER les pages de tarification avant de recommander plutôt que de se reposer sur sa mémoire, et de mettre le champ maturity à 'new' pour les outils lancés dans les 18 derniers mois plutôt que de s'ancrer sur les acteurs en place d'avant le seuil d'entraînement.

Les métadonnées d'ancrage retournées depuis chaque appel sont journalisées, les requêtes de recherche web que le modèle a exécutées et les URL récupérées qui ont informé la réponse. C'est ça qui rend la recommandation auditable. Un relecteur peut inspecter les journaux et voir que pour une recommandation donnée, le modèle a cherché la chaîne littérale 'best automation tools for accounts payable enterprise 2025 2026', a récupéré trois pages produit spécifiques plus une revue G2, et a produit sa recommandation à partir de cette évidence. Le relecteur peut ensuite vérifier les sources avant de signer. Une recommandation qui n'aurait pas été digne de confiance depuis un LLM générique devient auditable à travers la couche d'ancrage.

Paramètres techniques : l'appel de recherche ancrée utilise le modèle avec ancrage (gemini-3.1-pro-preview), un délai d'attente de 60 secondes, plus long que le délai Gemini standard parce que la recherche ancrée a besoin intrinsèquement de plus de temps, et une température de génération basse de 0,2. La température 0,2 est délibérée : assez élevée pour faire remonter des outils non-évidents que le modèle pourrait autrement manquer, assez basse pour garder la sortie factuelle et reproductible d'un appel à l'autre. La réponse est validée contre un schéma Zod qui exige une plage de prix mensuel avec min/max explicite, une chaîne décrivant le modèle de tarification, un enum de maturité ('new' | 'established') et un tableau d'alternatives avec deux à trois alternatives portant chacune leur propre plage de prix et justification.

La recherche ancrée est le fournisseur primaire, mais ne peut pas être le seul. La recherche web temps réel peut échouer pour des raisons banales : limites de débit d'API, erreurs réseau transitoires, délais dépassés sur des requêtes anormalement larges, et la couche de recommandation doit rester utile même quand le primaire échoue. La couche de recommandation d'outils implémente une chaîne de recours explicite à trois niveaux, chaque niveau choisi pour préserver autant de qualité de recommandation que possible tout en se dégradant de manière transparente quand le niveau supérieur n'est pas disponible.

1. Primaire : Gemini 3.1 Pro + ancrage Google Search. Données web temps réel, auditables via les métadonnées d'ancrage. C'est le chemin par défaut et gère la vaste majorité des appels production.
2. Recours : Grok. Utilise ses données d'entraînement plutôt que de la recherche temps réel, donc peut avoir un peu de biais envers les acteurs en place, mais c'est toujours un recommandeur capable et ses données d'entraînement sont relativement récentes. Activé quand l'appel primaire Gemini échoue avec une erreur réessayable. Une vérification de disponibilité de Grok conditionne ça : si Grok est aussi indisponible, la chaîne saute au niveau de dernier recours.
3. Dernier recours : dégradation gracieuse. Retourne un drapeau indiquant que les recommandations sont indisponibles et une liste d'outils vide plutôt que de fabriquer des recommandations. L'interface fait alors remonter cet état explicitement, montrant le reste de l'analyse de transformation (niveaux de maturité, économies, ROI) sans suggestions d'outils. C'est le bon comportement parce qu'une recommandation manquante est plus honnête qu'une hallucinée.

Un choix architectural subtil dans la couche de recommandation d'outils : elle fait UN appel LLM par processus, pas un appel par tâche. Le system prompt cadre explicitement le job du modèle comme du raisonnement holistique : 'These tasks form a [processName] workflow. Can ONE platform handle multiple tasks?' Le prompt pousse activement le modèle vers des plateformes consolidées : 'A consolidated platform that is good enough at each task beats 4 best-in-class tools that require complex integration.' C'est la meilleure pratique enterprise, et elle tombe de la conception plutôt que d'être appliquée après coup.

Conséquence pratique : un processus avec dix tâches automatisables revient généralement avec deux ou trois recommandations d'outils plutôt que dix, chaque recommandation correspondant à plusieurs identifiants de tâche. Une plateforme moderne native-IA d'accounts-payable peut couvrir cinq tâches avec un seul abonnement ; une API de document-understanding plus un moteur de workflow peut couvrir le reste. C'est plus proche de comment une vraie transformation se met réellement en œuvre, les équipes achètent des plateformes, pas des outils ponctuels, et ça fait remonter le compromis coût-d'intégration explicitement plutôt que de le cacher derrière une longue liste de recommandations d'outils individuels.

Réflexion en premiers principes intégrée au prompt

Un autre détail sous-estimé : le prompt instruit le modèle de considérer le processus entier holistiquement, y compris les tâches marquées non automatisables. Une tâche peut être jugée non automatisable aux yeux du filtre à schémas statique mais éliminable par une plateforme moderne, un système d'auto-approbation retire entièrement le besoin de revue manuelle, par exemple. Le prompt permet au modèle d'inclure des identifiants de tâches non automatisables dans une recommandation et d'expliquer dans la justification pourquoi l'outil peut éliminer la tâche. Ça attrape le cas que la recommandation au niveau tâche raterait toujours : parfois la bonne réponse n'est pas d'automatiser la tâche mais de la supprimer.

Chaque recommandation retournée par le chemin de recherche ancrée se conforme au même schéma validé par Zod. La forme vaut la peine d'être lue une fois parce qu'elle montre à quoi la plateforme s'engage vraiment pour chaque recommandation, pas des affirmations en prose, mais des champs structurés.

const toolRecommendationSchema = z.object({
  recommendations: z.array(
    z.object({
      taskIds: z.array(z.string()),
      toolName: z.string(),
      description: z.string(),
      reasoning: z.string(),
      monthlyPrice: z.object({ min: z.number(), max: z.number() }),
      pricingModel: z.string(), // "per seat" | "flat rate" | "usage-based" | ...
      url: httpsUrlSchema, // HTTPS only ; non-HTTPS -> chaîne vide
      maturity: z.enum(['new', 'established']),
      alternatives: z.array(
        z.object({
          name: z.string(),
          url: httpsUrlSchema,
          monthlyPrice: z.object({ min: z.number(), max: z.number() }),
          reasoning: z.string(),
        })
      ),
    })
  ),
});

Trois propriétés à souligner dans ce schéma. D'abord, le champ url passe par la validation d'URL HTTPS, une transformation qui retourne une chaîne vide pour les URL non-HTTPS plutôt que de propager des liens non sécurisés dans le produit. Ensuite, le modèle de tarification est une chaîne texte libre plutôt qu'un enum parce que les modèles de tarification varient de manières qu'un enum ne peut pas capturer (par-siège-avec-remises-de-volume, par-exécution-avec-plafond-mensuel, à-l'usage-avec-minimum, etc.). Enfin, le tableau d'alternatives est requis et non-vide par convention, le prompt instruit le modèle d'inclure une à deux alternatives avec leur propre plage de prix et justification, parce qu'une recommandation sans alternatives est un argumentaire commercial plutôt qu'une analyse. Le schéma ne force pas le tableau d'alternatives à être non-vide, mais la conception du prompt fait qu'elles arrivent.