# Procédure de bascule et de retour — modèle à adapter

Le cas Capordia est une équipe qui traite des lots indépendants. L'objectif
est de reprendre les travaux identifiés sans perdre leur acceptation. Une
interruption planifiée est possible. La durée admissible, les critères de
qualité et les responsabilités sont décidés avant la fenêtre de migration.

## 1. Désigner les responsabilités

| Rôle | Responsabilité | Preuve à conserver |
|---|---|---|
| Pilote de bascule | Autorise arrêt, changement d'autorité et reprise | Décision et heure UTC |
| Responsable des données | Fige les entrées, contrôle copie et inventaire | Manifeste versionné et empreintes |
| Responsable du traitement | Arrête le producteur, classe les tentatives | Registre des lots et journal du processus |
| Responsable de réception | Compare sorties et critères convenus | Résultats, refus et accord de réception |

Une petite équipe peut cumuler des rôles, mais la personne qui prononce
l'acceptation et celle qui sait arrêter l'ancienne autorité doivent être
identifiables. Le modèle CSV fourni n'impose aucun nom de personne.

## 2. Établir la référence avant de copier

Attribuer à chaque lot un identifiant stable et une version d'entrée.
Enregistrer son chemin, son empreinte, le traitement exact et le critère
d'acceptation. Distinguer une tentative lancée d'un résultat accepté.
Conserver les paramètres et dépendances nécessaires à la reprise, y compris
les états de calcul que votre logiciel exige. Un nom de fichier `final`
ne suffit pas à prouver une acceptation.

Dans l'exercice, huit lots représentent 48 coupons fictifs. L'acceptation
repose sur un résultat déterministe en entiers ; ce n'est pas un modèle de
checkpoint GPU. Les huit sorties de référence sont calculées avant la coupure.

## 3. Arrêter l'arrivée de nouveaux travaux

Fermer l'admission de nouveaux lots et noter le dernier identifiant admis.
Arrêter le worker ou attendre la frontière de reprise prévue. Confirmer
qu'aucun processus de l'ancienne machine ne peut encore accepter des sorties.
Classer le registre : terminé, en cours, à reprendre. Préserver les traces
d'un lot ambigu au lieu de le déclarer terminé par supposition.

Dans l'exercice, la coupure sur LOT-004 donne 3 / 1 / 4. Une relance sans
réconciliation est refusée. Le registre et ses résultats restent ensemble.

## 4. Copier, contrôler, changer d'autorité

La cible doit disposer du jeu figé, de l'état nécessaire et du programme
compatible. Vérifier les empreintes et l'inventaire depuis la cible.
Bloquer la reprise si une entrée manque, si le manifeste a changé ou si un
résultat ne correspond plus à son empreinte et à la règle d'acceptation.

Dans cet exercice, `basculer` clôture d'abord la source, puis copie les
fichiers après fermeture des connexions. Le programme ouvre la cible à la
production seulement après contrôle. Ne pas imiter une copie à chaud d'une
base active en dehors de cette procédure. Un échec laisse la source arrêtée.

Dans un système réel, la clôture d'un fichier local n'interdit pas une ancienne
machine isolée de continuer. Un droit de publication exclusif doit être
imposé par le système qui reçoit les résultats, avec refus des anciens droits
et preuve de ce refus. Le présent programme ne fournit pas cette protection.

## 5. Réconcilier et réceptionner

Vérifier que tous les résultats terminés sont présents et acceptables.
Les tentatives en cours sans acceptation sont remises à reprendre après
confirmation de l'arrêt de leur ancien producteur. Faire une reprise limitée
avant de rouvrir l'admission. Comptabiliser les lots attendus, les identifiants
uniques acceptés, les erreurs et les reprises. Enregistrer une acceptation
distincte de la simple fin du processus.

Dans le programme : `preparer-reprise` transforme le seul lot en cours en lot
à reprendre. `executer` ne recalcule pas les trois lots terminés. Le contrôle
final exige huit sorties acceptées et identiques à la référence. LOT-004 a
deux tentatives, mais une seule sortie acceptée.

## 6. Déclencher le retour sur un signal observable

| Signal | Décision proposée pour cet exercice |
|---|---|
| Empreinte d'entrée différente | Bloquer avant traitement ; retrouver la version figée |
| Résultat manquant ou altéré | Bloquer la réception ; examiner le lot et l'état |
| Deux autorités possibles | Arrêter la reprise ; établir une autorité unique |
| Programme incapable de reprendre | Garder l'admission fermée et transférer l'état récent vers l'environnement compatible |
| Délai de fenêtre dépassé | Appliquer la décision et la limite fixées par l'équipe avant bascule |

Si la cible a déjà accepté de nouveaux résultats, revenir à la vieille copie
de la source perdrait ces acceptations. Geler la cible, exporter son état
récent, le vérifier et le transférer vers un nouvel emplacement de retour.
Réconcilier les résultats avant de relancer. En présence d'effets externes,
leur inventaire fait partie du retour ; cet exercice n'en produit aucun.

```text
python exercice.py basculer --source manuel/cible --destination manuel/retour --proprietaire atelier-retour
python exercice.py preparer-reprise --dossier manuel/retour
python exercice.py executer --dossier manuel/retour
python exercice.py comparer --reference manuel/reference --candidat manuel/retour
```

Après cette opération, `manuel/source` et `manuel/cible` sont clôturés. Seul
`manuel/retour` peut travailler. Si la copie échoue ou si le contrôle refuse
un résultat, conserver les preuves et ne pas déverrouiller deux producteurs.

## 7. Clore la migration

Conserver manifeste, registre avant/après, empreintes, résultats de contrôle,
version du programme, décision de reprise et décision de retour éventuelle.
Ne supprimer l'ancienne copie qu'après la période de conservation choisie
par l'équipe. L'exercice ne supprime aucun dossier ; ses ressources sont
fictives et peuvent être archivées avec le rapport.