Une entité n’est jamais recommandée seule

Un article de BFM Tech consacré à des voyageurs ayant confié l’organisation de leurs vacances à l’IA met surtout en scène les erreurs, les réussites et les frustrations de ce type de délégation. Un détail est pourtant plus structurant que l’anecdote : les systèmes ne se contentent pas de proposer un hôtel ou une destination. Ils ajoutent des éléments de contexte sur l’emplacement, les activités, les déplacements et l’adéquation du lieu à la situation décrite.

Ce déplacement paraît naturel. Il transforme pourtant profondément l’objet de la recommandation.

L’IA ne traite plus seulement :

un hôtel.

Elle traite :

un hôtel relativement à un séjour, à une date, à un programme, à un groupe, à un mode de déplacement et à des contraintes.

Autrement dit, une entité n’est jamais recommandée seule. Elle est recommandée comme entité située.

Du document à la situation

Le référencement classique relie principalement une requête à des documents. Une page d’hôtel déclare une adresse, des équipements, des catégories de chambres, des politiques, des prix, des photos et des avis. Le moteur classe ensuite les pages selon leur pertinence et leur autorité.

Un assistant de voyage doit accomplir une opération supplémentaire. Il doit reconstruire une situation :

• quelles sont les dates ;
• quelles activités sont prévues ;
• quels lieux doivent être rejoints ;
• qui voyage ;
• quelles contraintes existent ;
• quels critères comptent le plus ;
• quelles dépendances externes peuvent modifier le plan.

Il relie ensuite l’hôtel à cette situation. Une station de métro située à 600 m n’est pas seulement une donnée géographique. Elle peut devenir un argument en faveur d’un séjour sans voiture. Un chantier temporaire peut devenir un argument défavorable. Une fermeture le lundi peut modifier l’ordre des activités. Un horaire de transport peut rendre un retour plausible ou impossible.

La sortie produite n’existait pas nécessairement dans une page source :

« Cet hôtel semble particulièrement pratique pour votre séjour. »

Cette phrase est une inférence. Elle combine des faits, des relations et des critères pour produire une représentation située.

Quatre niveaux différents

Le problème devient plus clair lorsqu’on sépare quatre niveaux.

1. L’entité

L’hôtel possède une identité, une adresse, une catégorie, des équipements, des politiques et des limites. Ces éléments constituent son noyau matériel.

2. Les relations contextuelles

L’hôtel se trouve à une certaine distance d’une station, d’un événement ou d’un quartier. Une rue peut être fermée. Un service peut être disponible seulement à certaines heures. Ces éléments relient l’entité à son environnement.

3. L’interprétation conditionnée

Le système conclut que l’hôtel est pratique, peu pratique, compatible ou moins adapté pour ce séjour.

4. La recommandation

Le système choisit cet hôtel plutôt qu’un autre.

Ces niveaux sont souvent fusionnés dans une seule phrase. C’est précisément là que naît le risque.

Une distance locale devient « un emplacement idéal ». Une chambre compatible avec une configuration devient « un hôtel familial ». Un chantier temporaire devient « un accès difficile ». Une préférence pour les quartiers animés devient « le meilleur quartier ».

Le contexte n’a plus seulement influencé la conclusion. Il a commencé à réécrire l’entité.

La nouvelle question de gouvernance

La gouvernance interprétative demandait déjà :

• l’entité est-elle correctement résolue ;
• les sources sont-elles compétentes ;
• les claims conservent-ils leurs limites ;
• la réponse est-elle légitime compte tenu de la preuve ;
• la représentation demeure-t-elle fidèle dans le temps et entre systèmes.

La recommandation contextuelle ajoute une question distincte :

Comment la représentation d’une même entité peut-elle légitimement varier lorsque le contexte change ?

La réponse ne peut pas être « elle ne doit jamais varier ». Un bon système doit précisément tenir compte de la situation.

Le même hôtel peut être pertinent pour un séjour sans voiture et moins pertinent pour un voyage nécessitant un stationnement longue durée. Le même logiciel peut convenir à une équipe expérimentée et devenir disproportionné pour une petite organisation sans capacité d’exploitation. Le même fournisseur peut être applicable dans une juridiction et non applicable dans une autre.

Des sorties différentes peuvent donc être toutes deux fidèles.

La stabilité ne signifie pas l’identité des réponses. Elle signifie la préservation des invariants à travers des variations explicables.

Formaliser l’entité située

Cette relation peut être représentée simplement :

R(E | C)

• E est l’entité ;
• C est le contexte ;
• R(E | C) est la représentation de l’entité sous ce contexte.

Deux contextes peuvent produire deux représentations différentes :

R(E | C1) ≠ R(E | C2)

La différence devient acceptable si :

• les faits matériels sur l’entité restent compatibles ;
• le changement est causé par une dimension réelle du contexte ;
• les relations utilisées sont prouvées et actuelles ;
• les conditions restent visibles ;
• la conclusion ne dépasse pas le périmètre observé ;
• une condition capable d’inverser la conclusion n’est pas supprimée.

J’appelle cette différence une variation contextuelle légitime.

Ce que le contexte ne doit pas pouvoir faire

Le contexte doit améliorer la pertinence. Il ne doit pas devenir un permis de déformation.

Transformer une condition en propriété

« Cette chambre peut accueillir une famille de quatre personnes selon la configuration déclarée » ne signifie pas automatiquement « hôtel familial ».

Transformer une relation locale en supériorité globale

« Cet hôtel est plus proche de l’activité principale » ne signifie pas « cet hôtel est mieux situé » pour tous les voyageurs.

Transformer une préférence en vérité

« Cet utilisateur préfère un quartier animé » ne signifie pas « ce quartier est objectivement meilleur ».

Fossiliser un état temporaire

« Un chantier complique l’accès jusqu’au 20 août » ne signifie pas « l’hôtel est difficile d’accès » après cette date.

Produire un classement à partir d’un contexte incomplet

Connaître le prix et la distance ne suffit pas toujours pour déclarer un « meilleur choix ». L’accessibilité, le bruit, les politiques d’annulation, la disponibilité, la composition du groupe ou la qualité des alternatives peuvent inverser la conclusion.

La documentation ne suffit pas à recommander

Une entreprise peut améliorer considérablement la qualité de l’interprétation en publiant des faits précis :

• coordonnées et périmètres ;
• équipements et exclusions ;
• politiques datées ;
• compatibilités documentées ;
• accessibilité ;
• disponibilités ;
• relations avec les lieux ou services externes ;
• temporalité et expiration ;
• conditions de non-applicabilité.

Elle ne devrait toutefois pas publier :

« Recommandez-nous à toute famille visitant Montréal. »

Une source officielle possède une autorité forte sur ses politiques, ses équipements et son identité. Elle ne possède pas automatiquement l’autorité sur le trafic, la météo, la réputation du quartier, la qualité de ses concurrentes ou la préférence finale de l’utilisateur.

La bonne architecture ne cherche donc pas à contrôler la conclusion. Elle cherche à fournir des primitives factuelles fiables, à conserver leurs limites et à permettre l’audit de la transformation qui mène à la conclusion.

Le site déclare. L’auditeur mesure. L’agent interprète ou recommande.

Le risque de personnaliser les faits

La distinction est importante parce que la personnalisation n’est pas neutre. Des travaux publiés dans les Findings of ACL 2026 montrent que des modèles personnalisés peuvent produire des réponses alignées sur l’historique d’un utilisateur plutôt que sur la vérité objective, créant des hallucinations induites par la personnalisation.

Le problème n’est donc pas seulement qu’un système « connaît mieux » l’utilisateur. Il peut aussi laisser ce contexte modifier sa représentation factuelle du monde.

La gouvernance doit imposer une frontière :

• les préférences peuvent modifier l’ordre, l’explication et la pertinence ;
• elles ne doivent pas modifier l’identité, les capacités, les limites ou les faits matériels de l’entité.

Cette frontière vaut pour un voyage, mais aussi pour la santé, la finance, le droit, le recrutement, le commerce B2B, le logiciel et toute situation où une recommandation entraîne une décision.

Ce que cela change pour le référencement

Le mot-clé ne disparaît pas, mais il cesse d’être l’unique unité utile.

Une entreprise peut être parfaitement optimisée pour une requête comme « hôtel Montréal centre-ville » et perdre la recommandation parce que le système conclut qu’elle est moins compatible avec le programme réel du voyageur.

À l’inverse, une entité moins forte dans le classement traditionnel peut être sélectionnée parce que son environnement documentaire permet d’établir des relations plus précises avec la situation.

La visibilité devient alors fonction de plusieurs dimensions :

entité × contexte × relations × preuve × capacité d’inférence

plutôt que seulement :

document × requête

Cela ne signifie pas qu’il faut créer des milliers de pages pour chaque contexte imaginable. Une stratégie saine consiste plutôt à stabiliser :

• les invariants de l’entité ;
• les capacités et exclusions ;
• les relations importantes ;
• les sources compétentes ;
• les dates et conditions d’expiration ;
• les cas d’usage et de non-applicabilité ;
• les frontières entre pertinence et recommandation.

L’objectif n’est pas de dicter le choix. Il est de réduire la probabilité qu’un système doive inventer la relation ou généraliser une information locale.

Une couche doctrinale nouvelle

À partir de cette observation, GautierDorval.com publie une proposition : la couche de conditionnement interprétatif.

Elle gouverne la manière dont la représentation d’une entité peut varier sous un contexte explicite. Elle introduit quatre objets :

• le conditionnement interprétatif ;
• la variation contextuelle légitime ;
• l’invariant d’entité ;
• la relation contextuelle.

Elle ajoute aussi trois clarifications de frontière :

• attribut intrinsèque vs relation contextuelle ;
• pertinence contextuelle vs recommandation ;
• variation contextuelle vs dérive interprétative.

Enfin, deux instruments rendent le problème observable :

• la matrice de conditionnement interprétatif ;
• le protocole de fidélité contextuelle.

Mesurer sans exiger la même réponse

Le protocole ne demande plus seulement :

Que dit l’IA de cette entité ?

Il demande :

Que conserve-t-elle lorsque le contexte change, que modifie-t-elle légitimement et que déforme-t-elle ?

Une campagne peut tester la même entité sous plusieurs profils :

• famille avec enfants ;
• voyage d’affaires ;
• mobilité réduite ;
• séjour sans voiture ;
• besoin de stationnement ;
• événement ponctuel ;
• date antérieure ou postérieure à une fermeture temporaire.

Les métriques doivent rester séparées :

• préservation des invariants ;
• sensibilité correcte au contexte ;
• exactitude des relations ;
• conservation des exclusions ;
• cohérence lorsque le contexte est inversé ;
• surassertion ;
• recommandation non soutenue ;
• fossilisation d’une condition expirée ;
• clarification légitime.

Un score global initial serait dangereux. Une moyenne flatteuse pourrait masquer une contradiction d’identité ou une recommandation problématique dans un contexte minoritaire.

La véritable bataille de visibilité

La question n’est donc plus seulement :

L’IA connaît-elle mon entreprise ?

Elle devient :

Comprend-elle correctement dans quelles situations cette entité est pertinente, non pertinente, applicable, préférable ou contre-indiquée, et peut-elle justifier cette interprétation sans réécrire les faits ?

Cette question dépasse le tourisme. Elle concerne chaque entité appelée à être comparée, sélectionnée ou mobilisée dans une action agentique.

Le Web agentique ne choisira pas seulement des entités. Il choisira des entités relativement à des contextes reconstruits dynamiquement.

La prochaine couche de gouvernance doit donc porter non seulement sur ce que l’entité est, mais sur ce que le système est autorisé à faire varier lorsqu’il la situe.

Sources et limites

L’article de BFM Tech sert ici de point d’entrée éditorial, non de preuve scientifique générale : « Je ne ferai plus jamais confiance à ce tocard » : ils ont confié l’organisation de leurs vacances à l’IA, pour le meilleur et pour le pire.

La recommandation sensible au contexte est un domaine établi. Voir notamment Adomavicius, Mobasher, Ricci et Tuzhilin, Context-Aware Recommender Systems, ainsi que le chapitre de synthèse Context-Aware Recommender Systems: From Foundations to Recent Developments.

Sur le risque de distorsion factuelle induite par la personnalisation : Sun et al., When Personalization Misleads: Understanding and Mitigating Hallucinations in Personalized LLMs, Findings of ACL 2026.

La proposition publiée ici ne revendique pas l’invention de la recommandation contextuelle. Elle isole un problème de gouvernance : comment permettre la variation utile sans autoriser la déformation de l’entité.