MÉTHODE OUVERTE / LIMITES EXPLICITES

Examiner la méthode. Comprendre le livrable.

Un composant pédagogique distinct illustre la vérification. Les modèles de revue expliquent les livrables remis au client. Aucune implémentation interne des programmes de recherche n’est incluse.

Boîtier électronique noir avec câbles et voyants sur un banc de laboratoire — CONTEXTE VISUELCalcul local

01 / DA-MODEL-002

Accusé de réception ≠ effet externe.

DA-MODEL-002 est un banc d’essai fictif avec un voyant. Le logiciel a accepté une commande ; savoir si le voyant s’est allumé relève d’une observation externe distincte.

01
Commande
Une demande d’allumage du voyant.
02
Accusé de réception logiciel
Le logiciel a accepté la demande. L’état du voyant n’est pas établi.
03
Observation externe
Un rapport récent provenant d’un observateur de confiance et lié à cette commande.

La confirmation exige la commande courante et une observation récente et fiable. Les messages mal rattachés, périmés ou falsifiés sont rejetés ; leur rejeu ne renouvelle pas leur fraîcheur.

Résultat exécuté sur l’exemple fini

états accessibles: 106
transitions vérifiées: 1378
séquences de 100 événements: 1000
variantes défectueuses détectées: 4

PASS · Python 3.12.14 · 2026-10-13T04:58:49.960638+00:00

Contre-exemples aux défauts introduits volontairement

receipt_is_effect

request_1 → receipt

wrong_ticket

request_1 → wrong_ticket

stale

request_1 → stale

forged

request_1 → forged

Exemple et vérificateur · ZIP ↓Rapport JSON enregistré ↗

Reproduire localement

Python 3.10+ · sans dépendances externes

python verify.py --report verification.local.json

SHA-256 / ZIP

1ba4989109c73bfb1f16bc0787153e13d4e222a055917b2131b5fc612bae2bff

02 / Modèles de revue

Ce que reçoit le client.

Deux documents cohérents portant sur le même banc fictif. Des identifiants relient chaque frontière de confiance à une lacune, aux preuves requises et au critère de clôture.

Carte des frontières de confiance

Frontière	Éléments qui la traversent	Fondement de confiance / limite
TB-01 · Client → récepteur	Une commande et son identifiant.	L’accusé de réception établit l’acceptation ; il ne prouve pas l’état du voyant.
TB-02 · Récepteur → environnement	Une intention de modifier l’état externe.	L’exécution et l’observation sont distinctes ; un effet peut se produire sans confirmation.
TB-03 · Observateur → évaluation	Une observation liée à la commande.	L’authenticité de la source et l’exactitude de la mesure sont ici supposées. Un système réel exige des preuves distinctes.
TB-04 · Évaluation → interface	Un statut et l’heure de l’observation.	Afficher « observé », l’heure et le périmètre ; ne pas transformer une observation passée en garantie de l’état actuel.

Télécharger le modèle modifiable · Markdown ↓

Registre des lacunes

Lacune	Impact et preuves requises	Critère de clôture
G-01 / TB-03 · Élevé	L’authenticité de l’observateur est supposée. Un modèle de confiance, des règles de gestion des clés et des tests négatifs sont nécessaires.	La source est identifiée ; les rapports étrangers, révoqués ou falsifiés sont rejetés.
G-02 / TB-03 · Élevé	La fraîcheur abstraite n’est pas un temps mesuré. Des bornes de délai, une incertitude d’horloge et un comportement à l’expiration doivent être définis.	Des rapports périmés ou une incertitude d’horloge excessive ne peuvent produire une confirmation récente.
G-03 / TB-02 · Moyen	La reprise et la réutilisation des identifiants ne sont pas modélisées. Des scénarios de redémarrage et de persistance sont nécessaires.	Après redémarrage, une ancienne observation ne peut être rattachée à une nouvelle commande.
G-04 / TB-04 · Moyen	Un utilisateur pourrait interpréter une observation comme l’état actuel. Un exemple d’interface et une revue de compréhension des statuts sont nécessaires.	L’interface distingue les statuts accepté, observé, périmé et inconnu.

Télécharger le modèle modifiable · CSV ↓

Toutes les lacunes restent ouvertes lors du passage du modèle à un banc réel. Il s’agit d’un exemple de livrable, pas d’une revue d’un système client.

Les modèles français sont des documents de travail traduits. Ils ne font pas partie du paquet original signé. Les archives de vérification signées, le code source et les journaux lisibles par machine restent inchangés dans leur langue d’origine.

03 / Niveaux d’accès

Convenir du périmètre. Puis accorder l’accès.

La page publique ne donne pas accès aux documents confidentiels. Chaque transmission exige un objectif, un destinataire et des conditions convenus.

01 / Public

Finalité, limites des conclusions, exemple fictif et modèles de revue. Le code source des programmes de recherche n’est pas publié.

02 / Revue sous NDA

Après accord : résultats de vérification enregistrés, identifiant de version et documents expurgés sélectionnés. Une copie personnalisée comporte une marque de diffusion unique ; aucun code source complet.

03 / Consultation contrôlée

Une liste de documents convenue, un accès nominatif en lecture seule, une date d’expiration et un journal de diffusion. Confirmez le canal et le destinataire avant d’accorder l’accès.

Décrire l’objectif de l’évaluation et le résultat attendu.
Convenir du NDA, de la version des documents et du périmètre autorisé.
Confirmer le destinataire, l’échéance et le canal de consultation.
Fournir une copie marquée et consigner son empreinte, son périmètre et son échéance dans le journal de diffusion.

Une marque de diffusion distingue les copies ; elle ne peut empêcher les captures d’écran ou la transcription. Un NDA seul n’est pas un contrôle technique d’accès. Ce site ne propose pas de dépôt automatique de programmes confidentiels.

Demander une revue technique ↗

Contacter directement le chercheur

1westwestwest@gmail.com

04 / Intégrité et provenance

Intégrité et provenance

Empreintes et signatures vérifiables des documents publics disponibles. Une signature établit la possession de sa clé ; aucune vérification indépendante d’identité ni aucun horodatage indépendant ne sont revendiqués.

Index SHA-256 et signatures ↗Signature de l’index ↓Clé publique ↓

minisign -Vm public-evidence-index.json -p release-key.pub

Téléchargez public-evidence-index.json.minisig dans le même répertoire. Conservez séparément l’empreinte de la clé publique : des fichiers et une clé issus du même site ne créent pas, à eux seuls, une confiance indépendante.

SHA-256 / clé publique

df5ad41bb5583bfe18ce84336e5122a5f24fd8c667868e99b7702c393882fa84

Les signatures couvrent l’exemple public, les modèles de revue et le paquet historique du formulaire. Aucune empreinte de spécifications privées ou de code source des six programmes n’est revendiquée sans instantanés explicitement sélectionnés. L’heure de signature provient de l’horloge de l’émetteur, pas d’un horodatage indépendant.