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.
Q-Metrics JSON
/.well-known/q-metrics.json
Surface de métriques descriptives pour observer des écarts, snapshots et comparaisons.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
Q-Metrics YAML
/.well-known/q-metrics.yml
Projection YAML de Q-Metrics pour instrumentation et lecture structurée.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
Q-Ledger JSON
/.well-known/q-ledger.json
Journal machine-first des observations, baselines et écarts versionnés.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
Artefacts complémentaires (3)
Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.
Q-Ledger YAML
/.well-known/q-ledger.yml
Projection YAML du journal Q-Ledger pour lecture procédurale ou outillage.
Protocole Q-Attest
/.well-known/q-attest-protocol.md
Protocole publié pour cadrer l’attestation, la preuve et la lecture des observations.
Carte de l’observatoire
/observations/observatory-map.json
Carte structurée des surfaces d’observation et des zones suivies.
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.
- 01Canon et périmètreCanon de définitions
- 02Observation faibleQ-Ledger
- 03Mesure dérivéeQ-Metrics
- 04AttestationQ-Attest protocol
Canon de définitions
/canon.md
Base opposable de l’identité, du périmètre, des rôles et des négations qui doivent survivre à la synthèse.
- Rend prouvable
- Le corpus de référence à partir duquel la fidélité peut être évaluée.
- Ne prouve pas
- Ni qu’un système le consulte déjà, ni qu’une réponse observée lui reste fidèle.
- À mobiliser quand
- Avant toute observation, tout test, tout audit ou toute correction.
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.
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.
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.
Surfaces probatoires complémentaires (1)
Ces artefacts prolongent la chaîne principale. Ils servent à qualifier un audit, un niveau de preuve, une citation ou une trajectoire de version.
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.
Observabilité interprétative : métriques, journaux, preuves
L’observabilité interprétative est la capacité de mesurer, dans le temps, ce que les systèmes d’IA restituent réellement d’une entité ou d’un corpus, et d’identifier quand l’interprétation dérive, se fragilise ou se capture.
Sans observabilité, la gouvernance est réactive : on corrige après un incident. Avec observabilité, elle devient préventive : on détecte la dérive avant qu’elle ne se stabilise (inertie, traînée, rémanence).
Définition opératoire
Observabilité interprétative : ensemble de métriques, journaux et artefacts probatoires permettant de mesurer l’écart canon-sortie, la dérive de conformité, la stabilité conversationnelle et la propagation des corrections, sur plusieurs surfaces (Web ouvert, RAG, agentique).
Pourquoi ce framework est indispensable
- Une erreur peut être rare, mais structurante (elle se stabilise).
- Une correction peut sembler efficace localement, mais échouer globalement (traînée).
- Une interprétation peut rester “vraie” après correction (rémanence).
- Le voisinage peut contaminer l’identité progressivement (capture).
L’observabilité rend ces phénomènes visibles et actionnables.
Surfaces d’application
- Web ouvert : moteurs de réponse, IA grand public, citations persistantes.
- RAG : retrieval, routage des sources, chunks, citations.
- Agentique : décisions, outils, exécution, non-réponses.
Le modèle “Métriques + journaux + preuves”
1) Métriques
Indicateurs quantitatifs continus pour suivre la dérive et la stabilité.
2) Journaux
Événements horodatés (tests, incidents, releases, corrections) qui expliquent les variations.
3) Preuves
Artefacts opposables (trace d’interprétation, preuves de fidélité) sur les cas critiques.
Métriques minimales (OM-1 à OM-8)
OM-1 : écart canon-sortie
Distance entre le canon et ce qui est restitué (omission, distorsion, extrapolation).
OM-2 : dérive de conformité
Augmentation de l’écart dans le temps malgré un canon stable.
OM-3 : taux de non-réponse légitime
Fréquence et qualité des refus gouvernés. Trop bas : inférence illégitime. Trop haut : cécité ou sur-barrage.
OM-4 : incidents d’identité
Collisions, contaminations, substitutions d’entités.
OM-5 : stabilité multi-formulations
Écart de sortie pour des requêtes équivalentes (instabilité).
OM-6 : stabilité multi-tours
Décrochage conversationnel sur 5 à 10 tours.
OM-7 : délai de propagation des corrections
Temps entre correction canonique et amélioration observée (traînée).
OM-8 : indice de rémanence
Probabilité qu’une interprétation ancienne réapparaisse après correction.
Journaux attendus
- Journal de tests : date, surface, prompts, résultats, écarts.
- Journal des incidents : type, gravité, contexte, preuve.
- Journal des corrections : endogène, exogène, rationale, version.
- Journal des releases : changements, impacts attendus, validation post-release.
Preuves (formats minimaux)
- Trace d’interprétation : sources, date, version du canon, règle appliquée, décision.
- Preuve de fidélité : correspondances canon-sortie, conflits d’autorité, justification des inférences permises.
Seuils d’alerte et playbooks
Une observabilité utile exige des seuils qui déclenchent une action.
- Seuil 1 : dérive faible → monitoring + re-test.
- Seuil 2 : dérive modérée → correction canonique + validation post-correction.
- Seuil 3 : dérive critique → correction endogène + exogène + release disciplinée.
Intégration avec Q-Layer et discipline de version
- Le Q-Layer fournit les règles (conditions de réponse, non-réponse, preuves).
- L’observabilité mesure la réalité (ce qui sort effectivement).
- La discipline de version rend la correction gouvernable (releases, propagation).
Artefacts attendus
- Tableau de bord des métriques OM-1 à OM-8.
- Registre des incidents (collisions, capture, décrochages).
- Batterie de tests versionnée.
- Rapports périodiques (hebdo/mensuel).
- Playbooks de correction (endogène/exogène/non-réponse).
FAQ
Pourquoi ce n’est pas juste des “analytics” ?
Parce qu’on ne mesure pas des clics. On mesure la fidélité, la légitimité, la preuve et la dérive de l’interprétation.
Est-ce applicable au Web ouvert ?
Oui, via une batterie de tests récurrents, des mesures d’écart canon-sortie, et l’analyse des sources dominantes responsables de la dérive.
Quel est le piège principal ?
Avoir des métriques sans playbooks. Mesurer sans capacité d’intervention revient à observer une dette se former.
Pages associées
- Observabilité interprétative
- Écart canon-sortie
- Dérive de conformité
- Trace d’interprétation
- Preuve de fidélité
- Les métriques GEO ne pilotent pas la représentation
Voir aussi
- Observabilité interprétative
- Écart canon-sortie
- Dérive de conformité
- Trace d’interprétation
- Preuve de fidélité
- Les métriques GEO ne pilotent pas la représentation
- Frameworks et cadres applicables
De l’observation à la preuve
L’observabilité interprétative n’est utile que si elle évite de traiter chaque observation comme une preuve. Une entrée de journal, un résultat de prompt, une citation, une capture ou une réponse de modèle peut montrer que quelque chose s’est produit. Cela ne prouve pas automatiquement pourquoi cela s’est produit, si c’est stable ou si cela doit gouverner une correction.
Le framework sépare donc observations, métriques, traces et preuves. Les observations capturent des sorties. Les métriques agrègent des motifs. Les traces préservent le contexte. Les preuves soutiennent un claim sur la fidélité, la dérive, l’autorité ou le risque. Cette distinction empêche le monitoring de devenir une collection d’anecdotes.
Modèle opérationnel
Un bon modèle d’observabilité définit ce qui est observé, dans quelles conditions, sur quels systèmes, avec quel canon attendu et avec quel seuil d’action. Il doit relier chaque problème récurrent à l’observabilité interprétative, à l’auditabilité interprétative, au Q-Ledger et aux Q-Metrics.
Le modèle doit aussi séparer les indicateurs avancés des seuils de preuve. Un signal faible récurrent peut justifier un monitoring ou une correction légère. Un claim à fort enjeu peut exiger une preuve reconstructible avant action.
Modes de défaillance
Les principales défaillances consistent à surinterpréter des sorties isolées, changer le canon trop vite, mesurer la visibilité sans fidélité et traiter la variabilité d’un modèle comme preuve d’instabilité sans assez de répétition. Un bon framework d’observabilité garde le signal utile en préservant contexte, fréquence, classe de source et statut de correction.