De la réalité au système
- 1 — SCÈNE
Décrire l’événement réel, les personnes, outils, contraintes et résultat attendu.
- 2 — OBJETS
Identifier ce qui existe dans le métier et les états possibles.
- 3 — FRICTIONS
Qualifier les pertes, délais, ressaisies, ambiguïtés et dépendances.
- 4 — CONTRAT
Définir ce que le système peut préparer, décider, refuser ou demander à l’humain.
- 5 — BUILD
Construire le plus petit système qui prouve le flux complet.
- 6 — ADVERSARIAL
Tester erreurs, mauvaises données, droits, exceptions et reproduction.
- 7 — TERRAIN
Comparer le modèle à l’usage réel et corriger ce qui ne tient pas.
Builder produit → vérificateur recalcule
Un résultat ne devient pas vrai parce que le système qui l’a produit dit PASS.
Pour les livrables sensibles, la frontière de preuve sépare production et verdict : identités, artefacts, tests, mutations, hashes et post-état doivent pouvoir être recalculés par une couche indépendante.
Règles de vérité
- prototype ≠ déploiement
- capture ≠ preuve de performance
- source propriétaire ≠ corroboration indépendante
- score ≠ décision
- automatisation ≠ autonomie
- PASS de build ≠ succès terrain
- soumission Google ≠ indexation
- crawl autorisé ≠ recommandation IA
Mesurer après le PASS
Un build peut être correct et le produit encore inutile.
Les gates techniques ferment les erreurs que nous savons tester ; le terrain vérifie ensuite que le système réduit réellement la reconstruction de contexte, la ressaisie, le délai ou le risque ciblé. Les métriques de produit restent donc séparées des métriques de build. Cette séparation vaut aussi pour le site lui-même : un sitemap soumis n’est pas une indexation et une page crawlable n’est pas une recommandation par une IA.