Documentation, centre d’aide, tarification et changelog : hiérarchie des sources produit
De nombreux sites décrivent un même produit à travers des surfaces différentes : page fonctionnalité, documentation, centre d’aide, FAQ, tarification, journal de version, contrat, réponse de support. Pour un lecteur humain, ces surfaces n’ont pas le même statut. Pour un système de synthèse, elles sont souvent perçues comme des variantes du même « à propos du produit ».
C’est précisément ce glissement que cette page cherche à borner. Le problème n’est pas qu’un produit soit documenté à plusieurs endroits. Le problème apparaît lorsque ces endroits ne déclarent pas quelle source fait foi pour quel type d’énoncé.
Cette hiérarchie n’a pas pour objet de produire un discours marketing plus simple. Elle vise à empêcher qu’une IA reconstruise une vérité moyenne à partir de surfaces qui ne parlent pas du même acte : capacité, disponibilité, condition commerciale, historique de version, engagement contractuel ou simple explication.
1. Toutes les pages produit ne font pas le même travail
Une page produit ne vaut pas une page de tarification. Une page de tarification ne vaut pas un changelog. Un changelog ne vaut pas un contrat. Une réponse de support ne vaut pas une définition canonique.
Ces surfaces peuvent concerner le même objet tout en exerçant des fonctions distinctes :
- la page de présentation décrit un périmètre ou une promesse de lecture ;
- la documentation décrit un fonctionnement, des paramètres ou des limites d’usage ;
- le centre d’aide traite souvent des cas de compréhension ou de support ;
- la tarification qualifie les conditions commerciales d’accès ;
- le changelog qualifie la temporalité et l’obsolescence ;
- le contrat ou les politiques encadrent ce qui devient opposable ;
- la réponse de support est fréquemment contextuelle et non universalisable.
La gouvernance endogène devient insuffisante si elle nomme un canon sans distinguer ces actes documentaires.
2. La vérité produit est distribuée, donc hiérarchisable
Dans un environnement interprété, la vérité produit n’apparaît pas comme un bloc homogène. Elle se distribue par types d’attributs.
Quelques exemples suffisent à montrer l’enjeu :
- l’existence d’une fonctionnalité ne prouve pas sa disponibilité dans tous les plans ;
- une capture du centre d’aide ne suffit pas à établir une promesse contractuelle ;
- une annonce de mise à jour ne vaut pas maintien permanent ;
- une ancienne page de tarification peut rester lisible alors qu’elle ne gouverne plus rien ;
- une réponse de support peut résoudre un cas local sans définir le comportement général du produit.
La hiérarchie des sources produit consiste donc à déclarer : quel attribut doit être lu où, sous quelle version, et avec quelle portée.
Cette logique prolonge la hiérarchie des sources, mais à l’intérieur même du corpus on-site. L’arbitrage n’oppose plus seulement le site et le hors-site. Il oppose des surfaces internes qui n’ont pas la même juridiction.
3. Pourquoi les systèmes de synthèse confondent ces surfaces
Les systèmes de synthèse aiment les formulations structurées, courtes et catégoriques. Or, les pages de tarification, les tableaux de capacités, les centres d’aide et les réponses de support contiennent précisément ce type de matériaux.
Il en résulte plusieurs confusions fréquentes :
- la tarification redéfinit le périmètre produit ;
- le centre d’aide redéfinit la règle générale à partir d’un cas fréquent ;
- une réponse de support devient promesse implicite ;
- le changelog est lu comme historique décoratif et non comme borne d’obsolescence ;
- la documentation technique est écrasée par une formulation commerciale plus simple.
Les analyses déjà publiées sur les plans tarifaires SaaS confondus avec des capacités et sur le support client quand l’IA engage l’entreprise sans autorité montrent que le problème n’est pas la présence de ces surfaces, mais l’absence d’une hiérarchie lisible entre elles.
4. Le changelog n’est pas décoratif
Le changelog, ou journal de version, ne sert pas seulement à signaler qu’« il s’est passé quelque chose ». Il sert à gouverner le pouvoir de version d’un produit.
Sans signal clair de dépréciation, de retrait, de remplacement ou d’entrée en vigueur, les anciennes descriptions continuent d’exister comme matière mobilisable. Une fonctionnalité retirée peut rester citée. Une limite modifiée peut continuer d’être répétée. Une ancienne promesse peut survivre comme si elle était encore actuelle.
C’est ici que la rémanence interprétative et la dette interprétative deviennent centrales. Ce qui n’est plus vrai n’a pas besoin d’être majoritaire pour continuer d’être reconstruit. Il suffit que l’ancienne version reste plus facile à réutiliser que la nouvelle.
5. Quand le non spécifié est plus fidèle qu’une réponse moyenne
Une hiérarchie des sources produit bien conçue ne cherche pas à tout rendre affirmable. Elle cherche à rendre certaines affirmations impossibles sans condition.
Si un prix dépend d’un volume, d’un contrat ou d’une juridiction, la bonne sortie n’est pas une moyenne. Si une fonctionnalité n’existe que dans un plan, la bonne sortie n’est pas « le produit fait X » sans qualification. Si une réponse de support vaut seulement pour un cas documenté, elle ne doit pas devenir vérité générale.
Le rôle du Q-Layer et des conditions de réponse est précisément d’empêcher qu’une synthèse transforme des surfaces hétérogènes en réponse homogène.
6. Ce qu’une hiérarchie produit minimale doit rendre explicite
Une hiérarchie produit minimale devrait au moins rendre visibles les distinctions suivantes :
- source de définition : où le périmètre du produit est déclaré ;
- source d’exécution : où le fonctionnement est expliqué ;
- source commerciale : où les conditions d’accès sont bornées ;
- source temporelle : où l’obsolescence, le retrait ou l’entrée en vigueur sont indiqués ;
- source contextuelle : où un cas particulier est traité sans valoir universalisation.
Le système de renvois canoniques devient ici essentiel. Sans renvoi explicite entre ces surfaces, l’IA n’hérite pas de la hiérarchie voulue. Elle reconstruit une proximité documentaire et l’interprète comme équivalence.
La situation devient encore plus fragile en multilingue, où une documentation FR, une tarification EN et un changelog partiellement traduit peuvent produire une réponse hybride.
7. Portée et limite
Cette page ne fournit ni méthode UX, ni conseil juridique, ni protocole produit. Elle établit un point de doctrine : un produit n’est pas gouverné seulement par « plus de contenu », mais par une hiérarchie explicite entre ses surfaces de vérité.
L’enjeu n’est pas de réduire le corpus. L’enjeu est d’empêcher qu’une synthèse traite comme équivalentes des pages qui n’exercent pas la même autorité.
Raccords canoniques
- Gouvernance endogène : canoniser l’entité on-site
- Le pouvoir de version dans un web interprété par les IA
- Système de renvois canoniques : relier phénomène → cartographie → doctrine
- Plans tarifaires SaaS confondus avec des capacités
- Support client : quand l’IA engage l’entreprise sans autorité
- Multilingue, traduction et hiérarchie des versions