Reproduire et citer le pilote📋

Complément technique du pilote Fessenheim, paquet 2.0.1 publié le 20 octobre 2026.

Cette révision corrige la vérification par un tiers. Les codes initiaux, les protocoles figés et les trois références calculées restent inchangés. Le manuel et les résultats scientifiques restent en version 2.0, avant arbitrage ; le paquet de distribution passe en 2.0.1. Les corrections sont décrites dans le journal.

Télécharger une arborescence complète📋

Télécharger le paquet autonome de vérification, puis le décompresser. Le ZIP contient les scripts, leurs entrées, les trois références, les manifestes, la provenance, les métadonnées de citation et les conditions de réutilisation. Les neuf PDF officiels restent externes ; leurs URL et empreintes sont publiées.

L'empreinte SHA-256 du ZIP diffusé et ses métadonnées de fabrication sont publiées séparément. Elles décrivent les octets de cette archive, avec Python, zlib et le manifeste source. Une reconstruction avec une autre version peut produire un autre ZIP : contrôler alors ses fichiers internes avec le vérificateur, sans lui attribuer l'empreinte de l'archive publiée.

Le mode d'emploi inclus décrit les commandes et les états d'échec. Une copie isolée du script ne suffit pas : les chemins relatifs du paquet doivent être conservés.

Vérifier sans remplacer les données📋

Prérequis : Python 3.9 ou ultérieur, sans dépendance externe. La vérification locale a été menée avec Python 3.9.13. Depuis le répertoire décompressé :

python donnees/fessenheim/verifier.py

Avec GNU Make installé, la commande équivalente est :

make verify

Le Makefile utilise python3 par défaut. Si seul python est disponible, utiliser make verify PYTHON=python.

Le vérificateur contrôle les empreintes, la présence des dépendances et la cohérence des deux manifestes. Il recalcule les trois fichiers, les compare octet par octet aux références et contrôle que les fichiers scellés n'ont pas changé pendant l'opération. Le code de sortie est 0 en cas de succès et 1 en cas d'échec, accompagné d'un objet JSON explicatif.

Les seules sorties de calcul et de vérification sont écrites dans donnees/fessenheim/out/ : resultats.json, demandes.csv, decisions.csv et verification.json. Les références publiées ne sont pas remplacées. Ce répertoire local est exclu de la publication automatique. La commande de fabrication du ZIP est une opération distincte et explicite.

Le calculateur peut aussi être lancé seul. Il écrit ses trois sorties dans out/, sans contrôle comparatif complet. Utiliser le vérificateur pour contrôler le résultat publié.

Les fichiers nécessaires📋

Le manifeste descriptif liste tous les fichiers du paquet, leur rôle et leurs empreintes, ainsi que les neuf PDF externes. Le fichier d'empreintes scelle les fichiers publics et le manifeste CSV. L'empreinte du fichier d'empreintes ne peut figurer en lui-même ; les deux manifestes sont décrits dans le CSV avec cette exception explicite. Le ZIP dérivé et out/ sont exclus du scellement pour éviter une autoréférence.

Les entrées du calcul sont accessibles individuellement :

Le paquet contient aussi les règles S, le registre des jalons, le gel des demandes, la fiche juridique et les références : résultats JSON, demandes CSV, décisions CSV.

Les empreintes des fichiers initiaux conservés sont également rassemblées dans l'état de contrôle avant correction. Ce relevé est daté de la correction ; les empreintes des quatre codes bruts concordent avec celles déjà publiées dans le résultat initial. Il ne se présente pas comme un horodatage externe rétroactif.

Les tests de non-régression s'exécutent sur les fichiers scellés et ne demandent aucun ZIP préexistant. Depuis un paquet fraîchement décompressé, lancer python donnees/fessenheim/test_verification.py. Le test de distribution fabrique sa propre archive dans un répertoire temporaire.

Accéder aux références juridiques📋

Les références juridiques et leur état d'accès complètent la fiche juridique sans modifier ses observations. L'accès direct à Légifrance peut être bloqué. La version applicable depuis le 4 mars 2018 a été retrouvée par une ancienne adresse officielle redirigeant vers le même identifiant ; la rédaction historique a été retrouvée dans l'index officiel et peut être confrontée à son texte de création. Ces chemins supplémentaires ne garantissent pas l'accès depuis chaque réseau.

La fiche juridique CNDP sur les comptes rendus↗ (ouvre dans une nouvelle fenêtre) fournit une source institutionnelle complémentaire pour le mécanisme actuel ; elle ne remplace pas la version historique applicable en 2008. Légifrance, article 134 de la loi du 27 février 2002↗ (ouvre dans une nouvelle fenêtre) ; Légifrance, version applicable depuis mars 2018↗ (ouvre dans une nouvelle fenêtre).

Contrôler aussi les PDF📋

Le manifeste publie pour chaque PDF l'URL officielle, la date de consultation, le SHA-256, le rôle, les pages utilisées lorsqu'elles sont identifiées et le statut de diffusion. Un repère non conservé est marqué inconnu ; une liste de pages vérifiées ne prétend pas décrire toutes les pages parcourues par un agent.

Le téléchargement du ZIP suffit au recalcul des codes, pas à une nouvelle lecture des sources. Sans PDF locaux, le vérificateur les énumère comme absents et ne prétend pas les avoir contrôlés. Tout PDF présent est contrôlé. Pour exiger les neuf, les placer aux chemins du manifeste puis lancer :

python donnees/fessenheim/verifier.py --avec-sources

Un PDF modifié ou manquant provoque alors un échec. Les copies de tiers et leurs figures ne sont pas redistribuées dans le ZIP ni placées sous les licences du paquet.

Ce que l'on sait des deux sessions📋

Les métadonnées A et les métadonnées B sont extraites des journaux locaux retrouvés. Les deux sessions déclarent gpt-6.1-sol, effort xhigh.

La révision interne exacte du modèle est inconnue. Les consignes A et les consignes B signalent que le texte original complet et les relances ne sont pas récupérables en clair dans les traces consultées. Les protocoles conservés fournissent les critères de codage ; ils ne sont pas présentés comme la totalité des messages effectivement reçus.

La liste exhaustive des pièces fournies reste également inconnue. Les pièces identifiées par les codes et la note sont distinguées de cette liste exhaustive. Les journaux complets, qui comprennent un contexte privé, ne sont pas diffusés. La provenance retrouvée ne transforme pas ces deux lectures du même modèle en validation humaine ou entre familles de modèles.

Citer, réutiliser et figer une version📋

Le fichier CITATION.cff du paquet conserve l'état au scellement. La notice de citation ajoutée après publication associe le DOI de la version : 10.5281/zenodo.23505871↗ (ouvre dans une nouvelle fenêtre). Cette notice externe ne remplace pas le fichier de l'archive figée. Les licences et leur périmètre distinguent les données originales sous CC BY 4.0, les scripts et le Makefile sous MIT, et les sources de tiers exclues. Ces conditions concernent ce paquet ; elles ne remplacent pas celles de l'ensemble du site.

Le dépôt scientifique dédié↗ (ouvre dans une nouvelle fenêtre) est public. La release pilote-fessenheim-v2.0.1↗ (ouvre dans une nouvelle fenêtre) contient le ZIP, son SHA-256 et ses métadonnées de fabrication. L'étiquette désigne le commit 5054192046ca245f24628742cd62dbc1b7dde1ba. Le premier commit du dépôt conserve le paquet antérieur aux derniers correctifs techniques ; les codes initiaux restent identiques dans les deux états.

Le fichier publication.json est l'instantané scellé avant création de l'étiquette. Le suivi actuel, également publié dans le dépôt↗ (ouvre dans une nouvelle fenêtre), consigne les démarches ultérieures sans réécrire cet instantané ni déplacer le tag. La publication Zenodo↗ (ouvre dans une nouvelle fenêtre) est confirmée : son ZIP retéléchargé anonymement est identique à celui de GitHub. Software Heritage confirme une visite complète et l'archive de la release↗ (ouvre dans une nouvelle fenêtre), identifiée par swh:1:rel:f21771808d273487540004fa86916e79524ccd30, pointe vers le commit étiqueté. Les accusés et contrôles sont joints au suivi.

Les tentatives Wayback n'ont fourni aucun accusé exploitable et la consultation de l'API de disponibilité reste inaccessible depuis cet environnement. La liste des neuf captures à reprendre conserve les URL officielles, leurs empreintes et les liens Save Page Now. Aucune capture Wayback n'est déclarée obtenue.

Le contrôle du téléchargement public confirme le SHA-256, la vérification et les neuf tests sur une extraction neuve dont les 35 fichiers d'entrée ont été rendus en lecture seule. Aucun n'a été modifié.

Le mode d'emploi donne les étapes d'archivage. Save Page Now capture une URL à la fois ; une demande n'est pas une capture constatée. Software Heritage doit avoir effectivement ingéré la révision avant qu'un identifiant soit annoncé. Pour Zenodo, une release GitHub demande une intégration activée ; un dépôt manuel du paquet est une autre possibilité. Internet Archive, Save Pages↗ (ouvre dans une nouvelle fenêtre) ; Software Heritage, FAQ↗ (ouvre dans une nouvelle fenêtre) ; Zenodo, archiver une release↗ (ouvre dans une nouvelle fenêtre).

Le journal externe consigne l'obtention du DOI et du SWHID. Les URL de captures restent vides tant qu'elles ne sont pas réellement obtenues. Les mises à jour restent hors de l'archive figée ; les codes initiaux sont conservés dans l'état auquel ils appartiennent.

Portée du succès de la vérification📋

Un contrôle réussi établit que le paquet reçu est cohérent avec ses empreintes et reproduit les trois références. Il ne valide ni les choix du manuel, ni l'exactitude technique des réponses d'EDF, ni la disponibilité historique des pièces. Les empreintes n'authentifient pas seules l'auteur ou la date de diffusion.

La validation extérieure du codage et la diversification du corpus restent donc ouvertes. Ce correctif résout une difficulté de distribution et de calcul ; les limites de l'enquête restent celles de l'addendum.

Pilote et résultats · Introduction · Addendum