CapordiaEspace client Délimiter ce qui migre et ce qui doit attendre
Ce guide s’adresse à la personne qui coordonne le calcul, les données et l’exploitation. Un lot désigne ici un paquet de travail identifié, distinct d’un lot de cartes GPU du catalogue. La méthode convient d’abord aux sorties qui peuvent être contrôlées avant acceptation. Pour un service recevant des demandes sans arrêt, prévoyez où les nouvelles entrées attendront, combien de temps cette attente est acceptable et comment elles rejoindront la cible. Un dossier copié ne définit pas à lui seul cette politique d’admission.
L’exercice proposé travaille sur un ensemble fermé de huit lots synthétiques. Il n’envoie aucune requête réseau et ne sollicite ni GPU ni compte Capordia. Il enseigne une logique de reprise sur un seul poste et un seul processus de travail. Il ne valide pas une file distribuée, la continuité d’un service exposé ou le déplacement à chaud d’un calcul. Avant une migration réelle, votre équipe doit qualifier ces éléments avec l’application et le matériel retenus.
Constituer un inventaire qui permet de reconstruire
Rassemblez le code et sa version, les dépendances, les paramètres, les modèles, les entrées, les tâches planifiées et les destinations de sortie. Pour chacun, indiquez le propriétaire, la méthode de reconstruction et le contrôle attendu sur la cible. Notez le nom des secrets et leur mode de fourniture, sans placer leur valeur dans le registre partagé. Une installation manuelle ou une tâche déclenchée au démarrage peut manquer dans une simple copie du répertoire du projet.
Séparez les fichiers d’entrée, les résultats acceptés et l’état nécessaire au redémarrage. Pour un entraînement, cet état peut dépasser les poids du modèle : le tutoriel PyTorch de sauvegarde d’un checkpoint général comprend notamment l’état de l’optimiseur et l’avancement. Le contenu requis dépend de votre code. Restaurez-le dans un processus neuf, puis comparez les sorties selon une tolérance décidée avant l’essai ; ne déduisez pas une identité numérique universelle d’un seul redémarrage réussi.
Attribuer la décision, le transfert et l’acceptation
Désignez les rôles avant de fixer la fenêtre. Une même personne peut en tenir plusieurs dans une petite équipe, mais les décisions restent distinctes. Le responsable de bascule confirme l’arrêt de l’ancien producteur et autorise le démarrage de la cible. Le responsable des données contrôle l’inventaire, les empreintes et les sorties. Le propriétaire du traitement juge la qualité fonctionnelle. L’exploitation conserve le journal des changements et prépare la passation.
La fiche de bascule doit répondre à quatre questions concrètes : qui peut arrêter les entrées, qui constate que l’ancien traitement ne publie plus, qui accepte les premiers résultats et qui décide du retour. Inscrivez aussi une heure limite de décision et les moyens de contacter ces personnes. « Revenir si nécessaire » ne suffit pas lorsque la cible a déjà produit des résultats que l’ancien registre ne connaît pas.
Tenir un registre qui distingue commencé et accepté
Attribuez un identifiant stable à chaque lot et rattachez-le à une version précise des données. Conservez son état, le nombre de tentatives, l’emplacement du résultat et le contrôle qui autorise son acceptation. Un lot en cours n’est pas terminé parce qu’un fichier de sortie existe : ce fichier peut être partiel ou provenir d’une tentative précédente. La procédure doit expliciter ce qui sera conservé, ce qui sera recalculé et ce qui restera en quarantaine pour examen.
Dans l’exercice, un registre SQLite local garde ensemble l’état et l’acceptation du résultat dans une transaction. Ses états sont termine, en_cours et a_reprendre ; ce dernier couvre aussi un lot qui n’a pas encore démarré. La cible reprend les lots non validés au lieu de relancer indistinctement les huit entrées. Les exports JSON et CSV rendent le suivi lisible. Le CSV vierge accompagne votre préparation et votre revue humaine ; il ne remplace pas le mécanisme de coordination d’une application réelle.
| Lots | État à la frontière | Décision avant reprise |
|---|---|---|
| LOT-001 à LOT-003 | termine | Conserver les résultats et vérifier leur intégrité |
| LOT-004 | en_cours, résultat non accepté | Préparer explicitement une nouvelle tentative |
| LOT-005 à LOT-008 | a_reprendre, aucune tentative | Lancer sur la cible après autorisation |
Télécharger et lancer l’exercice de coupure et de reprise
Prévoyez Python 3.10 ou plus récent avec le module sqlite3, et un répertoire local accessible en écriture. Téléchargez l’archive complète et extrayez-la en conservant le script, le dossier de données et le manifeste ensemble. Le fichier README détaille les commandes disponibles. Aucun pilote, paquet de calcul ou modèle n’est à installer. Lisez le script avant de l’exécuter, puis utilisez un dossier de sortie neuf pour que les preuves de plusieurs tentatives ne se mélangent pas.
Depuis le répertoire contenant exercice.py, la commande ci-dessous produit une référence continue, un traitement interrompu, une copie de bascule et une reprise comparée à la référence. Les huit fichiers CSV contiennent 48 mesures dimensionnelles fictives de coupons, exprimées en micromètres entiers et créées pour ce dossier. Aucun contrôle industriel réel n’est représenté. Le calcul sur CPU sert à examiner la gestion des lots, pas à estimer un débit GPU ou une durée de migration de vos données.
python exercice.py demonstration --dossier essai-capordiaLire les preuves de la reprise, lot par lot
Exemple Capordia : une équipe prépare huit paquets de fichiers à traiter. La référence les traite sans coupure. Sur l’autre parcours, l’arrêt laisse trois lots terminés, LOT-004 en cours et quatre lots à reprendre sans tentative. Le responsable de bascule ne demande pas « reprendre vers la moitié » : il désigne LOT-004. La préparation de reprise le remet à l’état a_reprendre : trois lots sont alors terminés et cinq sont à exécuter. Les lots déjà acceptés ne doivent pas être recalculés.
Consultez etat.json pour les identifiants, états et tentatives, registre-lots.csv pour la revue, resultats.json pour les sorties, puis rapport-verification.json pour les contrôles. Lors de l’exécution locale du 24 septembre 2026 sous Windows AMD64, Python 3.14.6 et SQLite 3.50.4, les 16 contrôles issus de 37 lancements du script ont réussi : les huit résultats repris correspondent à la référence, les lots terminés ne sont pas recalculés et une nouvelle acceptation du même lot est refusée. Les entrées altérées, identifiants dupliqués et sorties corrompues sont également détectés.
Copier un état cohérent, puis contrôler son intégrité
Dans une bascule réelle, arrêtez l’admission ou placez les nouvelles entrées dans une file explicitement prévue. Attendez la fin du travail en cours, ou enregistrez les lots interrompus selon votre règle de reprise. Confirmez ensuite que l’ancienne instance ne peut plus publier. Le scellage de la source dans cet exercice empêche le script de la réutiliser comme producteur. Il reste une protection locale du scénario, pas une exclusion mutuelle entre plusieurs machines qui posséderaient chacune une copie de l’état.
Pour copier une base SQLite utilisée par une application, sa documentation propose une API de sauvegarde qui produit un instantané cohérent. Une copie ordinaire d’un fichier de base en cours d’écriture n’est donc pas une procédure à improviser. Vérifiez aussi le manifeste des fichiers transférés. Les empreintes SHA-256, disponibles dans hashlib, aident ici à détecter une différence de contenu ; elles ne disent pas si le résultat est correct pour votre métier, ni si le manifeste de référence est digne de confiance.
Décider quand reprendre et quand revenir
Autorisez la cible seulement lorsque les entrées, le registre et les résultats conservés concordent, que l’ancien producteur est arrêté et que les prérequis logiciels sont satisfaits. Lancez d’abord un périmètre dont les sorties peuvent être relues. Le propriétaire du traitement accepte la qualité ; le responsable des données vérifie les identifiants, les manquants et les doublons. Un démarrage sans erreur ne suffit pas si le résultat utile est incomplet.
Si le défaut apparaît avant toute nouvelle publication, gardez la cible à l’arrêt et repartez de l’état source contrôlé selon la procédure prévue. Après une publication, préservez d’abord les résultats et le registre de la cible. Rapprochez les lots qu’elle a terminés avec ceux de la source, puis choisissez une seule reprise autorisée. Réactiver les deux côtés pour gagner du temps peut précisément créer les doublons que la migration devait éviter.
| Observation | Décision immédiate | Condition pour poursuivre |
|---|---|---|
| Entrée absente ou empreinte différente | Suspendre le transfert et isoler la copie | Récupérer une entrée conforme au manifeste de référence |
| Identifiant dupliqué ou sortie inattendue | Ne pas publier le lot concerné | Comprendre le conflit et retenir une seule version acceptée |
| État de reprise inutilisable | Arrêter la cible et conserver les preuves | Restaurer un état connu ou appliquer le retour préparé |
| Résultat hors du critère métier | Arrêter l’élargissement de la reprise | Corriger puis refaire la validation fonctionnelle |
| Heure limite de décision atteinte | Déclencher la décision de retour ou de report | Accord explicite du responsable et capacité de finir l’export |
Mesurer toute la fenêtre et préparer la passation
Répétez l’installation, la copie, la vérification, la reprise et l’export dans leur ordre réel. Notez le temps de chaque phase et les interventions humaines, avec un échantillon dont le transfert est autorisé. Pour estimer votre fenêtre, tenez compte des nouvelles entrées qui attendront et de la capacité à résorber ce retard. Le meilleur temps observé sur un petit dossier n’est pas un engagement sur un volume plus grand.
La période choisie doit couvrir préparation, répétition, bascule, observation et récupération des résultats. Les forfaits Capordia de 3, 7 ou 30 jours restent des périodes à organiser ; ce guide n’en déduit aucun temps de calcul. Avant la clôture, une seconde personne doit retrouver le registre, ouvrir les sorties depuis leur destination et savoir relancer le traitement. Archivez la décision de fin du repli, les écarts acceptés et les actions restantes avant de retirer les accès devenus inutiles.
Ce que l’exercice vérifie et ce qui reste à qualifier
L’apport de ce dossier est une procédure lisible et une expérience reproductible de reprise sur des fichiers synthétiques. Le même lot doit être identifiable avant l’arrêt, pendant la bascule et après la reprise. Le registre, la comparaison avec une référence et les refus provoqués rendent cette règle observable. L’interruption est déclenchée par une exception contrôlée dans le script : aucun essai de panne électrique n’a été réalisé. La documentation technique citée explique les mécanismes employés ; elle ne certifie pas votre futur environnement de production.
Un seul processus travaille à la fois dans le scénario. Le scellage local n’est pas un verrou distribué ; une empreinte n’est pas un test de qualité ; un résultat CPU n’est pas une qualification CUDA, ROCm ou multi-GPU. Une application qui écrit aussi dans une base externe, un stockage partagé ou une file nécessite une règle cohérente sur l’ensemble de ces destinations. Faites valider cette règle et votre plan de retour avant de migrer le traitement réel.
Pour préparer la suite
Une sauvegarde doit permettre de reprendre le travail.
Restaurer dans une cible isolée et vérifier que la copie permet réellement de reprendre.
Passer le relais avec un état, une action et un responsable.
Transmettre les actions, les limites et les responsabilités à une autre personne.