Dernière publication
Search for:
Gouvernance AI

Runbook & ops : du log au snapshot, sans fuite et sans dérive

Une gouvernance machine-first ne devient réelle que lorsqu’elle est opérationnalisée. Sans runbook, l’historique dérive, les archives se contaminent, et les métriques perdent leur valeur.

Ce texte décrit un pipeline minimal pour passer d’une observation (logs edge) à des artefacts publiables (Q-Ledger, Q-Metrics) et à une archive immuable, en évitant les pièges récurrents.

Portée : observation, pas attestation.
Ce pipeline vise la traçabilité et la lisibilité des signaux. Il ne constitue ni une preuve d’identité, ni une conformité, ni une certification.

Pipeline minimal

  1. Observation : collecte locale ou contrôlée de signaux edge (logs).
  2. Normalisation : dérivation en artefacts publiables (Q-Ledger, puis Q-Metrics).
  3. Publication : exposition des entrypoints machine-first (ex. /.well-known/).
  4. Archive : snapshots immuables dans un dépôt dédié (timeline).
  5. Vérification : contrôles de continuité, d’intégrité, et anti-fuite.

Pièges classiques (et comment les éviter)

1) Commiter des données sensibles par accident

Le risque le plus fréquent est de versionner des exports bruts (CSV, JSONL, Parquet) contenant IP, user agents complets, IDs, ou tokens. La règle est simple : l’archive ne contient que des artefacts dérivés et publiables.

2) Archiver une page d’erreur HTML

Un pipeline automatisé peut « capturer » une page d’erreur (403, 404, 5xx) renvoyée en HTML. Une archive doit échouer plutôt que d’archiver un contenu corrompu.

3) Casser la continuité sans le documenter

Les gaps (snapshots manquants), resets ou réécritures silencieuses détruisent la valeur de la timeline. Le chaînage (ex. previous_ledger_hash_sha256) et l’archive immuable rendent ces ruptures détectables, mais il faut aussi les documenter.

4) Confondre observabilité et attestation

Une suite de snapshots chaînés n’est pas une preuve d’identité. Une métrique n’est pas une preuve de conformité. La discipline consiste à séparer clairement les registres : observation (Q-Ledger), métriques descriptives (Q-Metrics), et, si nécessaire, attestation cryptographique (couche distincte).

Pourquoi séparer code et archive

Un dépôt de code doit rester stable et lisible. Un dépôt d’archive reçoit des commits fréquents. Séparer les deux réduit le bruit, évite les fuites accidentelles, et rend l’historique plus auditables.

  • Repo tooling : scripts, spec, runbook.
  • Repo archive : snapshots, manifest, baseline report.

Ce qui change dans une phase de découvrabilité passive

Une fois le baseline établi, l’objectif n’est plus de “collecter” en continu. L’objectif devient la découvrabilité passive : publier des entrypoints stables et laisser les agents/crawlers les découvrir, pendant que l’archive capture l’historique de publication.

Ressources