11.02 — Auditabilité « en une après‑midi »#

Engagement opérationnel : un humain doit pouvoir lire tout le framework et le comprendre en quelques heures. Pas de magie cachée.

Engagement#

Citation du Holy Book (chapitre « Qu’est donc Ocarina ? ») :

Pour les équipes bloquées par des politiques de sécurité : le code est petit, auditable en une après‑midi. Rien de caché. Les seules dépendances externes sont dans les plugins post‑exécution et si l’une d’elles ne passe pas, elle se retire sans que le reste ne casse.

Le moins de dépendances possible#

dependencies = ["python-docx>=1.2.0"]

python-docx est utilisé exclusivement par generate_docx_proof (plugin post-exécution).
Le reste du framework ne l’importe nulle part.

AuditVerdict
Quelles libs sont vendor-shipped avec Ocarina ?python-docx (+ Python stdlib)
Si l’auditeur ne fait pas confiance à python-docx ?Désactiver le plugin DOCX → tout le reste tourne
Y a-t-il des deps cachées dans requirements-dev.txt ?Oui (Selenium, allure, mypy, ruff, …) mais elles ne sont pas embedded dans les binaires release
Combien de SBOM entries pour pip install ocarina ?~2 (ocarina + python-docx)

Rien de caché#

L’auditeur peut tout vérifier :

  1. Le code source : public sur GitHub MIT.
  2. La build : hatchling build standard, reproductible.
  3. Les tests : cram + pytest + mypy plugins + syrupy + hypothesis.
  4. Le rapport Allure : publié sur GitHub Pages, consultable par tout le monde.
  5. Les CI : main_ci.yml

Pas de :

  • Build step propriétaire.
  • Téléchargement d’artefacts tiers à l’install.
  • Code obfusqué.
  • Télémétrie caché.
  • API call externe pour autoriser l’usage.

Code is Law#

Cf. ../01-philosophy/04-citations-and-influences.md

Le code se substitue à la Loi. Lessig, 1999, un cri d’alerte. Puis repris par Ethereum, 2015, à l’inverse comme idéal politique.

Pour que « le code soit la loi », il faut qu’il soit lisible.
Sinon c’est juste « la loi est ce qu’on ne comprend pas, mais qui s’exécute ».

Ocarina est explicitement auditable, donc législatif au sens noble.

Portage#

Citation du Holy Book :

Pour les scénarios les plus extrêmes : Ocarina n’a pas besoin d’être installé. Il se copie, s’adapte, et tourne. Pas de dépendance à auditer.

→ L’auteur affirme qu’on peut littéralement copier le dossier src/ocarina/ dans son projet et l’utiliser comme un sub-package. Aucune install.

Cas d’usage : un client ultra-paranoïaque qui refuse toute install pip. On copie. On adapte. Ça tourne.

Séparation dsl/infra/opinionated/#

Cf. ../02-ocarina/02-module-tree.md

CoucheAuditer en premier
railway/30 minutes : comprendre ROP
custom_types/30 minutes : types et alias
dsl/testing_with_railway/1h : la machine à états du DSL
dsl/invariants/1h : chaîne d’invariants
dsl/testing/1h : orchestration (Test → Suite → Campaign → Cycle)
infra/30 minutes : pool, builder, screenshotter
opinionated/30 minutes : CLI, loggers, plugins, bootstrap

→ Total : ~5 heures pour un audit complet. Soit une après-midi calme.

Plugins post-exécution uniquement#

Les seules dépendances externes sont dans les plugins post‑exécution et si l’une d’elles ne passe pas, elle se retire sans que le reste ne casse.

Cf. ../02-ocarina/11-opinionated/05-plugins-reports.md et ../02-ocarina/11-opinionated/06-bootstrap-launcher.md

run_plugins(*plugins, exceptions_logger) :

def _run_plugin(plugin: Effect, exceptions_logger: ILogger) -> None:
    try:
        plugin()
    except Exception as exc:
        exceptions_logger.exception("The plugin failed.", exc=exc)

Si python-docx est cassé / non installable : le plugin DOCX lève, on log, le reste continue.

Le run produit toujours :

  1. Le rapport pretty_print_results.
  2. Le rapport JSON (results_to_json).
  3. Le sys.exit(1) si fail.

Seul le DOCX manquera.
Par hygiène, on peut retirer l’appel au plugin DOCX de son fichier main.py en tant qu’utilisateur.

Anti No-Code#

Cf. Holy Book (chapitre « Premiers retours », section « Anti No-Code ») :

Le code est une donnée brute. Auditable. Consultable. Une boîte blanche. Très exactement ce avec quoi l’IA sait travailler depuis ses débuts.

→ « Boîte blanche » : on voit tout. Pas de boîte noire propriétaire.

L’opposition au No-Code n’est pas idéologiquement gratuite : c’est une revendication d’auditabilité. Un workflow No-Code est par définition non-auditable.

Anti dévs#

Holy Book :

contrairement aux Chercheurs, les ingénieurs et leurs amis d’école de commerce s’appuient sur des vues de l’esprit. Les écoles les plus “prestigieuses” leur ont appris une chose : faire passer le melon pour de “l’ingénierie”, là où ceux qui savent qualifient ce travail d’astrologie de la programmation.

→ Ocarina rejette le melon. Le code est ce qu’il est, vérifiable. Pas de « patterns » ésotériques qui justifient une complexité stupide.

Conséquence pour les équipes bloquées par les politiques de sécurité#

Le pitch de l’auditabilité s’adresse explicitement à elles :

Pour les équipes bloquées par des politiques de sécurité : le code est petit, auditable en une après‑midi.

Une équipe qui n’a pas droit à pip install <random> peut :

  1. Auditer Ocarina (une après-midi).
  2. Auditer les adapters projet (quelques heures de plus).
  3. Demander à ce que ce soit whitelist par l’équipe sécurité.
  4. Tourner sans crainte.

Pas besoin d’un consultant Ocarina, pas besoin d’un SaaS, pas besoin d’une licence entreprise.
C’est libre.