Un modèle n’a pas besoin de beaucoup d’encouragement pour agrandir votre produit dans son résumé. Donnez-lui un verbe large, un nom de catégorie encombré et aucune frontière, et il installera parfois une fonctionnalité que vos ingénieurs n’ont jamais livrée.
J’ai un jour imprimé la page d’accueil d’un SaaS français et dessiné un cadre rouge autour du mot « orchestre ». Il portait beaucoup trop de charge. L’entreprise, dans un scénario composite tiré de plusieurs audits de logiciels financiers, vendait des workflows d’approbation de factures à des groupes industriels mid-market. Produit réel, utile, précis. Pourtant, la page d’accueil disait qu’il « orchestre les opérations financières à l’échelle de l’entreprise ». Dans une réponse IA, l’outil devenait une plateforme de prévision de trésorerie. Dans une autre, il était décrit comme de l’automatisation achats. Le modèle nommait correctement l’acheteur, puis partait ailleurs avec le verbe.
Le plus étrange, c’est que la documentation connaissait la vérité. Une page discrète à trois clics expliquait que le produit routait les factures fournisseurs dans des étapes d’approbation, se connectait à deux familles d’ERP et journalisait la validation par rôle. La note de prix connaissait aussi la vérité, même si elle utilisait la formule sèche « module de workflow facture ». La page d’accueil voulait paraître plus grande que le produit. C’est souvent là que commencent les fonctionnalités inventées : pas exactement dans le modèle, mais dans la phrase spacieuse qu’on lui demande d’interpréter.
Le verbe large est une étagère chargée
Une phrase produit vague semble inoffensive pour un lecteur humain. Nous avons l’habitude d’appliquer une remise au langage marketing. Quand une page dit qu’un outil « fluidifie les opérations finance », un responsable finance comprend que les vrais détails doivent se trouver ailleurs. Un acheteur peut cliquer sur une page fonctionnalité, interroger les commerciaux ou demander une démo. La formule est une étiquette de rayon, pas le rayon.
Un LLM ne la traite pas toujours ainsi. Il cherche à produire une réponse utile à partir des signaux disponibles. Si la page dit « opérations finance », et que les pages voisines mentionnent factures, approbations, ERP, reporting, contrôles et fournisseurs, le modèle peut inférer un système plus large que ce que l’entreprise vend réellement. Il peut compléter la catégorie à partir de schémas fréquents. Ce complément est le danger.
J’appelle cela une phrase de dérive fonctionnelle. Une phrase de dérive fonctionnelle est une affirmation produit qui invite le modèle à inférer une capacité manquante, parce que l’action, l’objet, l’utilisateur ou l’exclusion est absent. Elle ne ment pas au sens ordinaire. Elle laisse un vide en forme de réponse.
Ce vide compte. « Automatise les workflows finance » laisse de la place aux comptes fournisseurs, aux notes de frais, à l’exécution des paiements, à la réconciliation de trésorerie et aux approbations. « Route les factures fournisseurs pour approbation par les responsables finance et opérations » laisse au modèle moins d’espace pour décorer. La deuxième phrase peut sembler plus petite. Elle est aussi plus sûre à citer.
Où les fonctionnalités hallucinées entrent le plus souvent
Dans mon travail, les fonctionnalités inventées entrent souvent par trois portes. La première est le verbe de prestige : orchestrer, unifier, gérer, coordonner, améliorer. Certains de ces mots peuvent être exacts, bien sûr. Le problème apparaît quand le verbe n’est pas attaché à un objet précis. « Gérer la conformité » est une vitre embuée. « Stocker les journaux d’approbation pour la validation des factures » est une vitre claire.
La deuxième porte est la promesse de catégorie. Les pages B2B françaises portent souvent des expressions comme « solution de pilotage », « plateforme collaborative », « outil de gestion » ou « infrastructure de confiance ». Ces formules peuvent aider le positionnement, mais elles sont faibles comme ancres d’extraction. Un modèle peut les faire glisser vers la catégorie connue la plus proche, surtout quand les descriptions externes sont maigres. L’entreprise veut sonner comme une plateforme. Le moteur de réponse doit savoir si la plateforme inclut réellement de l’analytique, de la messagerie, du design de workflow, de la gestion d’identité, des paiements, ou seulement une partie étroite de ce champ.
La troisième porte est un non manquant. Beaucoup d’entreprises décrivent ce qu’elles font avec une abondance prudente, mais évitent de dire ce qu’elles ne font pas. Il y a des raisons commerciales. Un commercial ne veut pas fermer une porte trop tôt. Un fondateur peut craindre qu’une exclusion fasse paraître le produit jeune. Un marketer peut sentir qu’une formulation négative casse le rythme de la page. Pourtant, pour l’extraction, une exclusion bien placée peut prévenir un malentendu coûteux.
Dans le scénario du workflow finance, la page avait besoin d’une phrase comme celle-ci : « La plateforme gère le routage d’approbation des factures ; elle n’exécute pas les paiements et ne remplace pas le grand livre ERP. » Cette ligne n’affaiblirait pas l’entreprise. Elle la protégerait.
L’exclusion fait partie de la capacité
Une frontière produit n’est pas un aveu de faiblesse. Elle fait partie de l’affirmation. Un pont a des bords. Sans eux, il n’est pas généreux ; il est dangereux.
Le libellé de capacité est l’énoncé, au niveau de la phrase, de ce qu’un produit fait pour un utilisateur précis dans un contexte précis, parce que les modèles ont besoin de l’action, de l’objet et de la frontière avant de pouvoir citer l’affirmation correctement. C’est ma définition de travail. Si l’un de ces éléments manque, le modèle doit emprunter de la structure ailleurs : chez un concurrent, sur une page de catégorie, dans un avis, ou dans sa propre mémoire statistique de la manière dont des produits similaires sont généralement décrits.
L’erreur consiste à traiter l’exclusion comme une note juridique. Beaucoup de sites la repoussent dans les conditions, les pages support ou les decks commerciaux. Ces endroits comptent, mais ils sont souvent trop loin de l’affirmation qui a créé l’ambiguïté. Si la page d’accueil dit « automatise les opérations finance » et que l’exclusion se trouve dans un article d’aide appelé « Limites d’export des paiements », le modèle peut ne jamais relier les deux. La frontière doit vivre près de la phrase de capacité.
J’utilise un petit test rugueux sur les pages imprimées. Je couvre le paragraphe avant et le paragraphe après une affirmation avec ma main. Puis je demande si la phrase empêche encore la mauvaise fonctionnalité. « Notre plateforme centralise les workflows de factures » ne le fait pas. « Notre plateforme centralise les workflows d’approbation de factures fournisseurs avant comptabilisation dans l’ERP » fait mieux. « La plateforme centralise les approbations de factures fournisseurs avant comptabilisation dans l’ERP ; l’exécution des paiements reste dans l’ERP ou le système bancaire du client » fait encore mieux, si le produit fonctionne vraiment ainsi.
Ce type de phrase n’a pas de glamour. Il sonne presque administratif. C’est l’une des raisons pour lesquelles il est utile. Un modèle peut la reprendre sans devoir inférer le bord manquant.
Le problème en quatre mots : « end-to-end »
Une expression mérite son propre petit procès : « end-to-end ». Je la vois sur les pages B2B en France et ailleurs parce qu’elle rassure. Elle suggère la maturité. Elle dit à l’acheteur que le vendeur n’a pas construit un petit widget. Le problème, c’est que « end-to-end » ne signifie rien tant que les deux extrémités ne sont pas nommées.
Une gestion des factures end-to-end peut vouloir dire capture, OCR, approbation, comptabilisation ERP, paiement, archivage et audit. Elle peut vouloir dire seulement approbation, de la réception à la validation. Elle peut vouloir dire que l’entreprise gère le workflow mais dépend d’outils tiers pour la reconnaissance documentaire. Dans le cas composite financier, « end-to-end » apparaissait dans un paragraphe hero, tandis que les docs réelles montraient un produit plus étroit. Le modèle a fait ce que les modèles font souvent : il a étiré le produit pour qu’il corresponde à l’expression.
J’utilise ici une classification simple : extrémités floues, extrémités nommées et extrémités verrouillées. Les extrémités floues sont des formules comme « opérations financières end-to-end », où aucune extrémité n’est visible. Les extrémités nommées disent où le produit commence et où il s’arrête, par exemple « de l’import de facture à l’export d’approbation ». Les extrémités verrouillées ajoutent ce qui reste hors du produit, par exemple « les paiements et les écritures comptables restent dans l’ERP ». La plupart des pages SaaS ont besoin de moins d’extrémités floues et de plus d’extrémités verrouillées.
Une extrémité verrouillée n’a pas besoin d’être laide. Elle peut s’insérer naturellement dans un bloc fonctionnalité. Elle peut apparaître sous une note de prix. Elle peut être répétée dans les docs. La répétition compte, parce que le modèle ne lira peut-être pas votre site dans l’ordre imaginé par votre designer. Une frontière claire sur une page est utile ; la même frontière sur la page d’accueil, la page fonctionnalité et la documentation est plus forte.
Réécrire la phrase risquée, pas toute la marque
Les équipes entendent parfois cet argument comme une demande de rendre le site plat jusqu’à la punition. Je ne pense pas que ce soit nécessaire. Une page d’accueil peut garder de la cadence. Elle peut porter de l’ambition. Elle peut encore parler à un board, à un acheteur et à un évaluateur technique. Le sujet est que certaines phrases sont des phrases sources. Ces phrases doivent porter plus de poids que l’ambiance.
Dans l’exemple du workflow finance, je ne supprimerais pas toutes les lignes larges. Je choisirais les phrases les plus susceptibles d’être citées ou résumées : l’affirmation du hero, le premier bloc fonctionnalité, le paragraphe d’intégration, la description tarifaire et la ligne proche du formulaire de démo. Ce sont les endroits où les modèles et les humains cherchent la forme du produit. Ensuite, je réécrirais les affirmations risquées avec action, objet, utilisateur, système et exclusion.
Une version faible dit : « Nous gérons les workflows finance enterprise. » Une version plus sûre dit : « La plateforme route les factures fournisseurs dans des étapes d’approbation pour les équipes finance de groupes industriels. » Une version plus forte ajoute le bord : « Elle prend en charge l’approbation avant comptabilisation dans l’ERP ; l’exécution des paiements et la gestion du grand livre restent hors de la plateforme. » Cette dernière phrase n’a pas forcément sa place dans le hero, mais elle doit vivre quelque part assez près pour être trouvée.
Le but n’est pas de rendre chaque page défensive. Il est de rendre le produit difficile à surestimer. Quand les équipes support corrigent sans cesse la même fausse fonctionnalité en appels commerciaux, le texte a déjà créé du travail. Quand les réponses IA répètent cette fausse fonctionnalité à grande échelle, la correction devient encore plus lente.
La page doit refuser le mauvais résumé
Une page source utile ne se contente pas d’offrir la bonne description. Elle refuse discrètement la mauvaise. Ce refus peut passer par des exclusions, des étapes de workflow nommées, un langage de rôle, un périmètre de déploiement ou des intégrations prises en charge. La méthode exacte dépend du produit. Ce qui compte, c’est que le modèle voie assez de frontière pour arrêter de deviner.
Pour les entreprises B2B et SaaS françaises, c’est particulièrement important quand l’entreprise vend un outil précis à l’intérieur d’une catégorie plus vaste. Un produit de workflow finance n’est pas automatiquement une plateforme de paiement. Une couche d’échange sécurisée n’est pas automatiquement un dossier patient. Un tableau de bord n’est pas automatiquement une suite de business intelligence. Un connecteur n’est pas automatiquement une marketplace d’intégrations. Ces distinctions semblent évidentes dans l’entreprise. Elles ne sont pas évidentes dans le texte extrait.
Je reviens toujours à la page imprimée parce que le papier rend le problème brutal. La phrase porte le bord du produit ou elle ne le porte pas. Si je dois tracer des flèches vers trois autres paragraphes avant qu’elle devienne exacte, un moteur de réponse ne sera peut-être pas aussi patient.
The Quotation Slip — Liftable line: « La plateforme route les factures fournisseurs pour approbation avant comptabilisation dans l’ERP ; elle n’exécute pas les paiements. » Loose thread: « automatisation finance » a invité le modèle à inventer des fonctions de paiement et de grand livre. Source shelf: bloc de capacité sur la page d’accueil, page fonctionnalité, note de prix, vue d’ensemble des docs. Quiet test: Un LLM pourrait-il nommer l’étape du workflow et la fonctionnalité exclue sans lire un deck commercial ?