Article

Contestation et journalisation : quand le recours devient une contrainte de design

Si une sortie peut faire l’objet d’un recours, la traçabilité n’est plus un luxe technique. Elle devient une contrainte de design.

FR EN
CollectionArticle
TypeArticle
Catégoriegouvernance exogene
Publié2026-03-26
Mise à jour2026-03-26
Lecture5 min

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. 02Politique d’interprétation
  3. 03Canon de définitions
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.

Politique et légitimité#02

Politique d’interprétation

/.well-known/interpretation-policy.json

Politique publiée qui explicite les contraintes d’interprétation, de portée et de retenue.

Gouverne
La légitimité d’une réponse et les contraintes qui modulent sa forme.
Borne
Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.

Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.

Canon et identité#03

Canon de définitions

/canon.md

Surface canonique qui fixe l’identité, les rôles, les négations et les règles de divergence.

Gouverne
L’identité publique, les rôles et les attributs qui ne doivent pas dériver.
Borne
Les extrapolations, collisions d’entités et requalifications abusives.

Ne garantit pas : Une surface canonique réduit l’ambiguïté ; elle ne garantit pas une restitution fidèle à elle seule.

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é.

Canon et identité#04

Verrou d’identité

/identity.json

Fichier d’identité qui borne les attributs critiques et réduit les collisions biographiques ou professionnelles.

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
    Autorisation de répondreQ-Layer : légitimité de réponse
  2. 02
    Observation faibleQ-Ledger
  3. 03
  4. 04
    Rapport d’auditIIP report schema
Couche de légitimité#01

Q-Layer : légitimité de réponse

/response-legitimacy.md

Surface qui explicite quand répondre, quand suspendre et quand basculer en non-réponse légitime.

Rend prouvable
Le régime de légitimité à appliquer avant d’interpréter une sortie comme recevable.
Ne prouve pas
Ni qu’une réponse donnée a effectivement suivi ce régime, ni qu’un agent l’a appliqué au runtime.
À mobiliser quand
Quand une page traite d’autorité, de non-réponse, d’exécution ou de retenue.
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.
Protocole d’attestation#03

Q-Attest protocol

/.well-known/q-attest-protocol.md

Spécification facultative qui sépare clairement les sessions inférées des attestations validées.

Rend prouvable
Le cadre minimal requis pour élever une observation vers une attestation vérifiable.
Ne prouve pas
Ni qu’un endpoint d’attestation existe, ni qu’une attestation a déjà été reçue.
À mobiliser quand
Quand une page traite de preuve forte, de validation opérationnelle ou de séparation des niveaux de preuve.
Schéma de rapport#04

IIP report schema

/iip-report.schema.json

Interface publique d’un rapport d’intégrité interprétative : périmètre, métriques et taxonomie de dérives.

Rend prouvable
La forme minimale d’un rapport d’audit reconstructible et comparable.
Ne prouve pas
Ni les poids privés, ni les heuristiques internes, ni la réussite d’un audit concret.
À mobiliser quand
Quand une page parle d’audit, de livrable probatoire ou de rapport opposable.

Dès qu’une réponse peut être contestée, la manière de publier doit changer. Une sortie contestable n’est pas seulement une mauvaise réponse possible. C’est une réponse qui peut déclencher un recours, une objection, une révision, une demande de justification ou une exposition juridique. À ce moment-là, la journalisation et la trace cessent d’être des options techniques. Elles deviennent des contraintes de design.

Le recours change la nature du système

Beaucoup d’équipes conçoivent encore la traçabilité comme un bonus d’observabilité. C’est trop faible. Quand une sortie influence un accès, une décision, un engagement, une interprétation réglementaire ou un périmètre contractuel, la possibilité de recours change la nature du système. Il faut être capable de montrer :

  • ce qui a été lu ;
  • ce qui a primé ;
  • ce qui a été ignoré ;
  • ce qui a été déduit ;
  • ce qui aurait dû conduire à une abstention.

Sans cela, on dispose peut-être d’un log technique, mais pas d’une justification instruisible.

Pourquoi la journalisation doit être pensée en amont

La plupart des organisations découvrent ce besoin après incident. C’est trop tard. Une trace utile ne se reconstruit pas facilement après coup si l’architecture ne distingue pas clairement canon, observation, preuve et règles de légitimité. L’enjeu n’est donc pas seulement de “garder des logs”. L’enjeu est de publier un système où la sortie contestée peut être comparée à une base opposable.

Observation, preuve, attestation

Trois niveaux doivent être distingués :

  • observation : ce qui a été vu ou mesuré ;
  • preuve : ce qui est publié comme surface opposable ;
  • attestation : ce qui permet de formaliser un constat selon un protocole.

Cette distinction évite deux erreurs fréquentes : prendre une observation pour une preuve, ou sur-promettre une attestation à partir d’un log partiel.

Ce que le design doit intégrer

Si la contestation est possible, le design doit intégrer :

  • des conditions de réponse ;
  • des seuils d’abstention ;
  • des traces d’interprétation ;
  • un protocole de qualification de preuve ;
  • un canon qui permette de mesurer l’écart.

Le recours n’est donc pas un problème juridique “en aval”. C’est une force de gouvernance exogène “en amont”.

Liens recommandés