Aller au contenu

Doctrine

Signal, preuve et conformité

Fixe la différence entre un signal publié, une preuve opposable, et une conformité effectivement démontrée. Évite les raccourcis fréquents dans la lecture des fichiers de gouvernance.

CollectionDoctrine
TypeDoctrine
Couchetransversal
Version1.0
Niveaunormatif
Publié2026-03-31
Mise à jour2026-03-31

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.

  1. 01Entrypoint IA canonique
  2. 02Manifeste IA public
  3. 03Contexte du site
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 (2)

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

Politique et légitimité#04

Q-Layer en Markdown

/response-legitimacy.md

Surface canonique de légitimité de réponse, de clarification et de non-réponse.

Frontières et exclusions#05

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.

  1. 01
    Carte d’observationObservatory map
  2. 02
    Observation faibleQ-Ledger
  3. 03
    Mesure dérivéeQ-Metrics
Index d’observation#01

Observatory map

/observations/observatory-map.json

Index machine-first des ressources d’observation, des snapshots et des points de comparaison publiés.

Rend prouvable
Où se trouvent les objets d’observation mobilisables dans une chaîne probatoire.
Ne prouve pas
Ni la qualité d’un résultat, ni la fidélité d’une réponse particulière.
À mobiliser quand
Pour localiser les baselines, journaux, snapshots et artefacts dérivés.
Journal d’observation#02

Q-Ledger

/.well-known/q-ledger.json

Journal public de sessions inférées qui rend visibles certaines consultations et séquences observées.

Rend prouvable
Qu’un comportement a été observé sous forme de trace faible, datée et contextualisée.
Ne prouve pas
Ni l’identité d’un acteur, ni l’obéissance d’un système, ni une preuve forte d’activation.
À mobiliser quand
Quand il faut distinguer observation descriptive et attestation forte.
Métriques descriptives#03

Q-Metrics

/.well-known/q-metrics.json

Couche dérivée qui rend certaines variations plus comparables d’un snapshot à l’autre.

Rend prouvable
Qu’un signal observé peut être comparé, versionné et contesté comme indicateur descriptif.
Ne prouve pas
Ni la vérité d’une représentation, ni la fidélité d’une sortie, ni un pilotage réel à elle seule.
À mobiliser quand
Pour comparer des fenêtres, prioriser un audit et documenter un avant/après.

Pourquoi ces trois mots ne doivent jamais être fusionnés

Dans la plupart des discussions sur la gouvernance IA, les mots signal, preuve et conformité sont employés comme s’ils étaient interchangeables.

Ils ne le sont pas.

Les confondre conduit à annoncer une force que l’organisation ne possède pas, ou à attribuer à un système une obéissance qui n’a jamais été démontrée.

Le signal

Un signal est une information publiée qui oriente la lecture, l’accès, la hiérarchie ou l’interprétation.

Un signal peut être :

  • un fichier robots.txt ;
  • un llms.txt ;
  • un manifeste de gouvernance ;
  • une page de contexte ;
  • une déclaration de précédence ;
  • une négation explicite.

Le signal est important. Mais il reste une déclaration publiée.

Il ne prouve pas, à lui seul :

  • qu’un système l’a lu ;
  • qu’il l’a correctement interprété ;
  • qu’il s’y est conformé ;
  • qu’il le respectera durablement.

La preuve

Une preuve exige une chaîne plus exigeante.

Il faut au minimum :

  • une trace ou une observation située ;
  • une méthode déclarée ;
  • un périmètre ;
  • une lecture des limites ;
  • et, si possible, une fidélité partiellement vérifiable.

C’est précisément la fonction de la Couche de preuve, de Q-Ledger et des surfaces d’observation.

Une preuve ne vaut pas seulement parce qu’un fichier existe. Elle vaut parce qu’un effet, une lecture, une continuité ou une absence de fidélité peut être décrit et borné.

La conformité

La conformité ajoute encore une couche.

Elle suppose non seulement qu’un signal a été publié et qu’une observation a eu lieu, mais qu’un système s’est comporté conformément à ce qui était déclaré, et ce d’une manière suffisamment stable ou documentable pour dépasser la simple plausibilité.

Or, dans le Web ouvert, cette conformité reste souvent partielle, intermittente, ou difficile à opposer.

Dire « j’ai publié un signal » n’est pas dire « le système s’y conforme ». Dire « j’ai une observation » n’est pas dire « la conformité est générale ».

Pourquoi cette distinction compte pour Better Robots.txt

Better Robots.txt publie et structure des signaux de gouvernance sur WordPress.

C’est utile. C’est opérable. Mais le plugin ne doit pas être lu comme s’il transformait automatiquement un signal publié en conformité démontrée.

Le plugin matérialise une couche de déclaration et d’implémentation. Il peut contribuer à une stratégie de preuve. Il ne remplace pas, à lui seul, la chaîne probatoire complète.

Règle de lecture

L’ordre correct est le suivant :

  1. signal : ce qui a été déclaré ;
  2. preuve : ce qui a été observé et borné ;
  3. conformité : ce qui peut être soutenu sans extrapolation abusive.

Cette séquence évite deux dérives :

  • survendre la portée des fichiers de gouvernance ;
  • sous-estimer l’utilité réelle des signaux parce qu’ils ne prouvent pas tout.

Ce que cette page interdit de déduire

Cette page interdit de déduire que :

  • un fichier de gouvernance serait une garantie ;
  • une trace isolée serait une conformité générale ;
  • une recommandation IA prouverait une fidélité de lecture ;
  • une absence de preuve autoriserait l’inférence inverse.