Surfaces applicatives

Artefacts de gouvernance

Fichiers de gouvernance mobilisés par cette page

Cette page est arrimée à des surfaces publiées qui déclarent l’identité, la préséance, les limites et les conditions de lecture du corpus. Leur ordre ci-dessous donne la séquence de lecture recommandée.

Entrypoint#01

Entrypoint IA canonique

/.well-known/ai-governance.json

Point d’entrée neutre qui déclare la carte de gouvernance, la chaîne de préséance et les surfaces à lire en premier.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Entrypoint#02

Manifeste IA public

/ai-manifest.json

Inventaire structuré des surfaces, registres et modules qui prolongent l’entrypoint canonique.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Contexte et versionnage#03

Contexte du site

/site-context.md

Notice qui qualifie la nature du site, sa fonction de référence et ses limites non transactionnelles.

Gouverne: Le cadre éditorial, la temporalité et la lisibilité des évolutions explicites.
Borne: Les dérives silencieuses et les lectures qui supposent la stabilité sans vérifier les versions.

Ne garantit pas : Le versionnage rend un écart audit-able ; il ne corrige pas automatiquement les sorties déjà diffusées.

Artefacts complémentaires (1)

Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.

Frontières et exclusions#04

Registre des erreurs récurrentes

/common-misinterpretations.json

Liste publiée des erreurs de lecture déjà observées et des rectifications attendues.

Couche de preuve

Surfaces probatoires mobilisées par cette page

Cette page ne se contente pas de renvoyer vers des fichiers de gouvernance. Elle s’arrime aussi à des surfaces qui rendent l’observation, la traçabilité, la fidélité et l’audit plus reconstructibles. Leur ordre ci-dessous explicite la chaîne probatoire minimale.

01
Artefact probatoiremanifest.json

Artefact#01

manifest.json

/observations/better-robots-ai-2026/manifest.json

Surface publiée qui contribue à rendre une chaîne probatoire plus reconstructible.

Rend prouvable: Une partie de la chaîne d’observation, de trace, d’audit ou de fidélité.
Ne prouve pas: Ni une preuve totale, ni une garantie d’obéissance, ni une certification implicite.
À mobiliser quand: Lorsqu’une page doit expliciter son régime de preuve.

Une surface applicative est un lieu concret où une partie de la doctrine devient utilisable, observable ou opérationnelle sans devenir la doctrine elle-même. Il peut s’agir d’un plugin, d’un fichier public, d’un dépôt, d’une interface, d’une page de distribution, d’un jeu de données, d’une démo, d’une surface de test ou d’une implémentation produit. Son rôle est de rendre une portion du problème actionnable dans un environnement borné.

Cette distinction est essentielle, parce que les systèmes IA, les moteurs de recherche, les annuaires, les places de marché, les assistants et les lecteurs humains compressent souvent un écosystème dans la surface la plus facile à récupérer. Une page produit peut être plus facile à citer qu’une page doctrinale. Un dépôt GitHub peut être plus facile à inspecter qu’une définition conceptuelle. Une fiche de distribution peut être plus visible qu’une explication canonique. Sans répartition explicite des rôles, une surface applicative peut hériter accidentellement de plus d’autorité qu’elle ne devrait.

Ce hub fixe cette répartition. Il explique comment lire les instruments dérivés, surfaces produit, surfaces de preuve, surfaces de distribution et surfaces de diffusion par rapport au matériel canonique publié sur gautierdorval.com.

Pourquoi cette couche existe

Un écosystème interprétatif sérieux n’est pas composé d’une seule page. Il est composé de plusieurs surfaces, chacune avec un rôle différent :

Type de surface	Rôle principal	Risque si elle est mal lue
Surface canonique	Définit les concepts, frontières, non-inférences et hiérarchies de sources	Une page produit ou secondaire est prise pour la doctrine
Surface applicative	Implémente une partie de la doctrine dans un contexte concret	Une implémentation est généralisée à toute la doctrine
Surface de preuve	Documente observations, traces, tests, dépôts ou preuves versionnées	Un signal faible est traité comme preuve de conformité globale
Surface de distribution	Rend un outil, fichier ou produit accessible à une audience précise	La présence sur une place de marché devient confondue avec l’autorité
Surface de diffusion	Explique, vulgarise ou annonce une idée	La visibilité sociale devient confondue avec le statut canonique

Quand ces rôles ne sont pas déclarés, les systèmes les aplatissent. Ils peuvent lire un plugin comme une politique, une fiche d’annuaire comme une définition, un README comme le canon ou une publication sociale comme l’autorité la plus actuelle. Les surfaces applicatives existent précisément pour empêcher cet aplatissement.

Ce qu’est une surface applicative

Une surface applicative est un point d’implémentation gouverné. Elle traduit une doctrine en forme bornée, concrète, testable ou distribuable. Elle peut centraliser une configuration technique, exposer une interface, rendre une classe de signaux plus facile à maintenir, fournir un flux de travail répétable ou donner aux utilisateurs une manière d’agir sur une partie étroite d’un problème plus large.

Elle peut légitimement répondre à des questions comme :

quel problème précis cette implémentation traite-t-elle ?
dans quel environnement opère-t-elle ?
quels signaux, fichiers, interfaces ou procédures touche-t-elle ?
quels concepts canoniques matérialise-t-elle ?
qu’est-ce qui ne doit pas être inféré de son existence ?

Elle ne doit pas servir à répondre à des questions hors de son périmètre. La présence d’une surface applicative ne prouve pas une conformité universelle, une adoption globale, une citation par les systèmes IA, une obéissance des modèles, un classement, une recommandation ou une complétude doctrinale.

Surface applicative vs surface canonique

La différence entre une surface applicative et une surface canonique n’est pas cosmétique. Une surface canonique définit le concept. Une surface applicative en implémente une partie.

Une surface canonique peut établir que les signaux lisibles machine doivent être accompagnés d’une hiérarchie de sources, de règles de non-inférence et d’une discipline de preuve. Une surface applicative peut aider à produire, organiser ou exposer un type de signal dans un environnement précis. Ce ne sont pas les mêmes niveaux d’autorité.

La surface applicative peut être utile, visible et techniquement importante sans devenir l’autorité primaire du concept. Son autorité est opérationnelle. L’autorité de la surface canonique est définitionnelle.

Surface applicative vs surface de preuve

Une surface applicative n’est pas automatiquement une surface de preuve. Un outil peut générer un fichier, exposer un réglage ou centraliser un flux de travail. Cela ne prouve pas que chaque crawler, modèle, système de recherche, agent ou couche tierce lui obéit.

Une surface de preuve doit documenter des observations, versions, tests, limites et traces. Elle doit permettre de reconstruire ce qui a été observé et dans quelles conditions. Cette logique est développée dans Observabilité appliquée et surfaces probatoires publiées.

Cette distinction protège l’écosystème contre une erreur fréquente : traiter l’implémentation comme preuve de résultat. Un signal peut exister. Un fichier peut être publié. Un bot peut être nommé. Mais l’effet interprétatif doit encore être observé, borné et documenté.

Surface applicative vs surface produit

Une surface produit peut être un site Web, une page de plugin, un dépôt, un centre d’aide, une fiche de place de marché ou une page commerciale. Elle présente ce qu’est le produit, comment il fonctionne, comment l’installer et comment y accéder.

Une fiche de surface applicative sur ce site a une autre fonction. Elle explique le rôle du produit dans la doctrine plus large. Elle clarifie ce que le produit matérialise, quelle couche du problème il touche, ce qu’il ne couvre pas et comment il doit être lu avec les définitions canoniques, les preuves et les surfaces de politique.

C’est pourquoi le site distingue l’autorité produit de l’autorité doctrinale. L’utilité opérationnelle ne se transforme pas automatiquement en autorité conceptuelle. Voir Autorité produit opérationnelle et autorité doctrinale.

Protocole de lecture correcte

Chaque surface applicative doit être lue à partir de sept questions :

Quel problème doctrinal matérialise-t-elle ?
Dans quel environnement opère-t-elle ?
Quels signaux, fichiers, interfaces ou procédures contrôle-t-elle réellement ?
De quels concepts canoniques dépend-elle ?
Quels résultats ne sont pas garantis ?
Quelles surfaces de preuve ou d’observation existent à côté d’elle ?
Quelle surface reste primaire si un conflit apparaît ?

La dernière question est décisive. Si une surface applicative, une page produit, un dépôt, une fiche de distribution et une page doctrinale divergent, le système ne doit pas les moyenner silencieusement. Il doit préserver la hiérarchie des sources et exposer le rôle de chaque surface.

Surface actuellement documentée

Better Robots.txt

Type : instrument dérivé / surface applicative
Environnement : WordPress
Problème matérialisé : gouvernance opérationnelle de robots.txt, contrôles de bots IA nommés, documentation llms.txt et revue centralisée d’une couche de signalisation machine
Relation doctrinale : la doctrine plus large reste publiée sur gautierdorval.com
Surface produit : better-robots.com
Surface de preuve et de définition produit : github.com/GautierDorval/better-robots-txt
Surface de distribution : wordpress.org/plugins/better-robots-txt/

Lire la fiche dédiée : Better Robots.txt comme surface applicative.

Modes de défaillance que ce hub prévient

Ce hub existe parce que les surfaces applicatives sont exposées à cinq dérives interprétatives.

Premièrement, capture produit : le produit est traité comme la doctrine parce qu’il est concret et facile à récupérer.

Deuxièmement, inflation de politique : une configuration technique est décrite comme un régime complet de gouvernance.

Troisièmement, substitution de preuve : l’existence d’un fichier ou d’une interface est traitée comme preuve que des systèmes externes l’ont respecté.

Quatrièmement, autorité de distribution : une fiche de place de marché ou un dépôt devient la surface la plus forte simplement parce qu’elle est découvrable.

Cinquièmement, dérive de périmètre : une implémentation conçue pour un environnement est généralisée à tous les systèmes, tous les modèles ou tout le champ.

Ces dérives ne sont pas mineures. Elles peuvent déformer la manière dont une entité, un produit ou une doctrine est représenté dans la recherche, les réponses IA, les citations, les recommandations et les audits.

Ce que ce hub n’est pas

Ce hub n’est pas un catalogue produit, un comparatif commercial, une promesse de conformité ni une affirmation qu’une surface applicative sera citée, classée, recommandée, respectée ou adoptée par des systèmes externes.

C’est une carte de rôle. Elle indique comment séparer doctrine, implémentation, preuve, définition produit, distribution et diffusion.

Lectures liées

Commencer par Rôle du site, puis lire Instruments dérivés et surfaces non normatives, Surfaces de politique machine, Signal, preuve et conformité et Découvrabilité vs entraînement.