Schéma visuel
Chaîne minimale de preuve d’un audit d’intégrité
Un audit ne vaut pas par un verdict isolé, mais par une chaîne continue entre canon, capture, écart, preuve et correction.
Source
Canon déclaréPages, exclusions, versions et surfaces machine-first qui fixent ce qui peut être opposé.
Cadre
Périmètre et autoritéDélimiter ce qui entre dans l’audit, ce qui reste hors champ et quelles autorités priment.
Capture
Runs et capturesPrompts, systèmes, dates, contexte, sortie observée et conditions d’exécution sont consignés.
Trace horodatée
Constat
Écart canon-sortieQualifier la dérive, la collision, la lacune ou la reformulation fautive sous forme explorable.
Preuve
Preuve de fidélitéChaque constat doit être rattaché à des extraits, snapshots ou matrices vérifiables.
Boucle
Correction et monitoringLa boucle se ferme par une correction publiée, un rerun et une surveillance de continuité.
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.
Iip Scoring Standard Manifest
/iip-scoring.standard.manifest.json
Surface qui explicite les conditions de réponse, de retenue, d’escalade ou de non-réponse.
Iip Report Schema
/iip-report.schema.json
Surface d’observation qui expose des journaux, métriques, snapshots ou protocoles de mesure.
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
- 02Autorisation de répondreQ-Layer : légitimité de réponse
- 03Observation faibleQ-Ledger
- 04Mesure dérivéeQ-Metrics
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-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.
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.
Surfaces probatoires complémentaires (4)
Ces artefacts prolongent la chaîne principale. Ils servent à qualifier un audit, un niveau de preuve, une citation ou une trajectoire de version.
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.
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.
CTIC compliance report schema
/ctic-compliance-report.schema.json
Schéma public pour publier des constats de conformité et des findings sans exposer la logique privée complète.
Changelog IA
/changelog-ai.md
Journal public qui rend les évolutions des surfaces IA plus datables et plus auditables.
Audit d’intégrité interprétative : protocole complet (end-to-end)
Un audit d’intégrité interprétative vise à répondre à une question simple : un système d’IA restitue-t-il fidèlement une entité, une doctrine ou un corpus, dans les conditions réelles d’usage ? Dans un Web interprété, une vérité peut être disponible, indexée et publiée, sans pour autant exister dans la réponse. L’audit sert à mesurer et gouverner cet écart.
Ce protocole end-to-end formalise un cycle complet : définition du canon, délimitation de l’autorité, tests, preuves, diagnostic, correction et monitoring.
Définition opératoire
Audit d’intégrité interprétative (end-to-end) : protocole visant à mesurer, documenter et corriger l’écart entre le canon (ce qui est déclaré et opposable) et la sortie (ce que les systèmes d’IA restituent effectivement), en imposant une frontière d’autorité, des conditions de réponse, une trace d’interprétation et une preuve de fidélité.
Quand déclencher l’audit
- variation forte des réponses selon la requête (instabilité)
- confusions d’entités (collisions, contaminations)
- recommandations incohérentes ou non alignées sur le canon
- attribution incorrecte ou citations hors périmètre
- incidents “plausibles” (erreurs discrètes mais répétées)
- changement majeur : rebrand, pivot, nouvelle offre, nouvelle politique.
Surfaces d’application
- Web ouvert : moteurs de réponse, IA grand public, résumés, comparatifs, citations persistantes.
- RAG fermé : corpus interne, embeddings, retrieval, routage des sources, citations.
- Agentique : exécution d’actions, décisions automatisées, outils, formulaires, workflows.
Objets audités
- Entité : marque, organisation, personne, produit, service.
- Corpus : doctrine, normes internes, politiques, documentation.
- Règles : conditions de réponse, non-réponse légitime, frontières d’autorité.
- Changements : mises à jour versionnées, corrections, releases.
Modèle de sortie attendu
Un audit end-to-end produit :
- un registre canon (sources + périmètres + exclusions)
- une batterie de tests (requêtes et scénarios)
- un rapport de preuves (trace + fidélité)
- un diagnostic (types de dérives)
- un plan de correction (endogène + exogène)
- un plan de monitoring (observabilité + version).
Protocole (AII-1 à AII-10)
AII-1 : définir le canon
Identifier les sources canoniques, leur périmètre d’interprétabilité, et leurs exclusions. Un canon sans frontières produit une inférence non gouvernée.
AII-2 : établir la frontière d’autorité
Déclarer ce qui peut être déduit et ce qui est interdit. Hors frontière : non-réponse légitime.
AII-3 : définir les conditions de réponse
Spécifier quand répondre, quand répondre sous preuve, et quand refuser. Les attributs critiques exigent preuve ou refus.
AII-4 : constituer l’espace de tests
Construire une batterie de tests couvrant requêtes ambiguës, comparatives, adversariales, multi-tours et multi-langues.
AII-5 : exécuter les tests sur surfaces
Tester séparément Web ouvert, RAG, agentique. Une “bonne” sortie sur une surface ne garantit rien ailleurs.
AII-6 : produire une trace d’interprétation
Capturer sources, contexte, date, conditions de réponse appliquées, et décisions de non-réponse.
AII-7 : produire la preuve de fidélité
Démontrer que la sortie respecte le canon, ne dépasse pas l’autorité, et ne masque pas des conflits d’autorité.
AII-8 : mesurer l’écart canon-sortie
Quantifier les distorsions : omissions critiques, confusions, contaminations, extrapolations normatives, lissage.
AII-9 : plan de correction (endogène + exogène)
Corriger le canon on-site, puis corriger les sources externes dominantes responsables de la contamination ou de la capture.
AII-10 : monitoring et pouvoir de version
Versionner les corrections, re-tester périodiquement, surveiller la dérive de conformité et la rémanence.
Typologie des dérives (diagnostic)
- Collision : confusion ou fusion d’entités.
- Capture : domination d’un narratif externe.
- Invisibilisation : info présente mais absente de la réponse.
- Extrapolation normative : règle étendue hors périmètre.
- Lissage : standardisation qui gomme la spécificité.
- Décrochage d’état : vérité périmée figée comme stable.
Artefacts attendus
- Registre canon : sources, périmètres, exclusions, versions.
- Matrice de conditions de réponse : attributs critiques, preuves exigées, non-réponse.
- Batterie de tests : prompts, requêtes, scénarios, résultats.
- Rapport de trace : sources, contexte, horodatage, règles appliquées.
- Rapport de preuve : correspondances canon-sortie, conflits, décisions.
- Plan de correction : endogène, exogène, priorités, owners, versions.
- Plan de monitoring : métriques, seuils, cadence, re-tests.
FAQ
Quelle différence entre “audit d’intégrité interprétative” et “audit SEO” ?
L’audit SEO mesure la visibilité. L’audit interprétatif mesure l’existence dans la réponse, la fidélité au canon et la gouvernance de l’inférence.
Pourquoi tester plusieurs surfaces ?
Parce que la dérive peut se produire au retrieval (RAG), à la réponse (LLM), ou à l’exécution (agentique). Sans séparation, tu diagnostiques mal.
Quel est le livrable le plus important ?
Le couple trace d’interprétation + preuve de fidélité. Sans preuve, tu ne gouvernes pas. Tu débats.
Pages associées
- Frontière d’autorité
- Périmètre d’interprétabilité
- Conditions de réponse
- Non-réponse légitime
- Trace d’interprétation
- Preuve de fidélité
- Écart canon-sortie