Une migration interrompue n’est pas toujours simplement « à moitié terminée ». Elle peut s’être arrêtée avant l’enregistrement d’une unité, après la confirmation de certains changements ou alors que la réponse de la destination était ambiguë. Le processus peut aussi s’être achevé tout en laissant des écarts. Pour décider comment poursuivre, l’équipe doit reconstituer les événements à partir d’éléments vérifiables, et non se fier uniquement au code de sortie ou au dernier identifiant enregistré.
La question pratique n’est pas seulement de savoir comment reprendre une migration de données échouée en PHP, mais aussi ce que l’on peut affirmer sur l’état de chaque unité et quelles vérifications sont nécessaires avant de répéter une opération. Cette distinction réduit les risques de doublons, de relations rompues et de corrections manuelles difficiles à auditer.
Commencez par distinguer une exécution interrompue d’une migration présentant des écarts
Une exécution interrompue est une exécution dont le processus a cessé d’avancer, par exemple à la suite d’une exception, d’une perte de connexion ou d’une intervention opérationnelle. À l’inverse, une migration présentant des écarts est une migration dont le résultat ne respecte pas les conditions attendues, même si le processus s’est achevé sans erreur. Des lignes peuvent avoir été omises, des clés transformées incorrectement ou des relations laissées incomplètes.
C’est pourquoi un état global tel que terminée ou échouée ne suffit pas. Il est utile de distinguer au minimum les états suivants : en cours, interrompue, terminée et terminée avec des écarts. L’état global résume le travail, mais ne remplace ni le journal par unité ni la validation du résultat.
Avant de relancer la commande, conservez les journaux disponibles et déterminez quel système fait foi à cette étape. S’il y a eu des écritures après la migration, des modifications manuelles ou des processus concurrents, identifiez leurs effets sur la comparaison. Poursuivre sans ces informations peut transformer un écart susceptible d’être analysé en une perte de traçabilité.
Définissez des unités de travail et des points de contrôle vérifiables
Choisissez une unité de travail adaptée aux données et à la récupération : il peut s’agir d’une entité, d’un groupe d’enregistrements liés ou d’une partition stable. Évitez de réduire le point de contrôle à « le dernier identifiant traité ». Cet identifiant prouve tout au plus que le programme a atteint une certaine position ; il ne prouve pas que tous les enregistrements précédents ont été correctement enregistrés ni que la destination est cohérente.
Pour chaque unité, conservez une clé source stable, la version ou l’identifiant de l’exécution, l’état et un résultat vérifiable. Le point de contrôle doit pouvoir être comparé à la destination, par exemple au moyen d’une clé de destination, d’une empreinte calculée à partir de champs pertinents ou d’une requête de vérification. Si les données peuvent changer pendant le processus, consignez également le critère de sélection ou l’instant de coupure appliqué.
La conception dépend de l’environnement. Si la source et la destination partagent une transaction, celle-ci peut fournir une preuve de confirmation conjointe ; s’il s’agit de systèmes distincts, ne présumez pas d’atomicité entre eux. Dans une intégration par API, une réponse perdue peut rendre incertain le fait que le serveur ait appliqué l’opération. La stratégie doit tenir compte de cette incertitude et prévoir une vérification ultérieure, plutôt que d’étiqueter automatiquement l’unité comme échouée ou confirmée.
Consignez par unité les opérations tentées et celles confirmées
Un journal utile au support permet de savoir qui a exécuté la migration, quelle unité a été traitée, quand son état a changé et sur quelle preuve repose ce changement. Distinguez traité — le code a exécuté des étapes — de confirmé — un signal fiable indique que le résultat attendu existe dans la destination. Ajoutez le numéro de tentative, une catégorie d’erreur et un identifiant de corrélation pour relier les événements du processus aux appels externes.
Les états doivent décrire des situations opérationnelles, et pas seulement les étapes de l’algorithme. Par exemple : en attente, en cours, confirmation incertaine, confirmé et nécessite une vérification. Si le processus s’arrête alors qu’une unité est indiquée comme étant en cours, il faut la considérer comme incertaine au redémarrage, jusqu’à ce que la destination soit vérifiée. Ne la marquez pas comme échouée sans vérifier si elle a produit des effets.
Consignez suffisamment d’informations pour mener une enquête, mais ne consignez pas d’informations d’authentification, de secrets ni de données personnelles inutiles dans les journaux. Les erreurs doivent permettre d’identifier l’unité et l’opération, sans que la traçabilité augmente l’exposition des données. Définissez également qui peut consulter et conserver ces journaux.
Comparez les invariants avant de décider de la suite
Les invariants sont des conditions qui doivent être respectées quelle que soit l’implémentation de la migration. Le nombre d’enregistrements par type ou par partition aide à localiser les différences, mais ne suffit pas : deux ensembles peuvent avoir la même taille tout en contenant des enregistrements différents. Comparez les clés métier, la présence des enregistrements, les relations et les règles pertinentes, telles que les états autorisés ou les montants recalculés.
Choisissez des vérifications proportionnées à l’impact et au volume. Un échantillon peut servir au diagnostic, mais ne prouve pas à lui seul que l’ensemble est correct. Pour une validation exhaustive, comparez les clés ou les empreintes par blocs et consignez ceux qui ont été vérifiés. Si la transformation modifie délibérément des champs, documentez les différences attendues et celles qui signalent une erreur.
Si la source continue de recevoir des modifications, distinguez les écarts dus à la concurrence de ceux causés par la migration. Il peut être nécessaire de définir une fenêtre de coupure, de capturer les changements ultérieurs ou de répéter une phase de synchronisation. Sans règle claire concernant les modifications concurrentes, la comparaison entre les systèmes peut générer des faux positifs ou ne pas détecter de nouvelles données.
Reprenez uniquement sur la base de preuves et gérez les résultats incertains
Une reprise sûre charge les unités en attente et celles qui sont confirmées, mais ne considère pas comme valides celles dont l’état est incertain. Pour ces dernières, interrogez la destination à l’aide d’une clé stable et comparez le résultat à la transformation attendue. Si les données correspondent, consignez la confirmation sans répéter l’effet ; si elles sont absentes, une nouvelle tentative peut être appropriée. Si elles existent avec un contenu différent, interrompez le traitement de cette unité afin d’enquêter.
Lorsqu’une répétition risque de créer des doublons ou des effets externes — comme l’envoi d’une notification —, utilisez une opération idempotente ou une clé d’idempotence si le système concerné le permet. Si ce n’est pas possible, concevez une vérification préalable et une procédure de réconciliation. Ne présumez pas qu’une exception signifie qu’aucune donnée n’a été écrite : l’échec peut s’être produit après la confirmation du changement, mais avant la réception de la réponse.
Avant la reprise, vérifiez que le même mappage et la même politique de clés sont utilisés, ainsi que la bonne version du code ou de la configuration. Un point de contrôle généré par une transformation différente peut être trompeur. En PHP, la commande de migration devrait accepter un identifiant d’exécution et produire des états structurés ; une personne peut ainsi confronter le journal aux données au lieu de s’appuyer sur des messages génériques dans la console.
Définissez des conditions d’arrêt et terminez par un rapport
Interrompez la reprise en présence de conflits de clés, de données invalides nécessitant une règle métier, de relations orphelines, de résultats incertains impossibles à vérifier ou d’écarts dépassant les limites acceptées. Arrêtez-vous également si les éléments disponibles ne permettent pas de savoir ce qui s’est passé. Dans ces cas, faire remonter le problème et préserver l’état est généralement plus sûr que de relancer à l’aveugle.
À la fin, exécutez les vérifications globales : unités confirmées par rapport aux unités attendues, nombres et clés, relations et règles métier définies pour la migration. Produisez un rapport indiquant ce qui a été migré, vérifié et relancé, ainsi que les écarts encore en attente, avec des références permettant de les examiner. Ne déclarez pas le travail terminé au seul motif que le processus s’est achevé avec le code zéro.
Le critère de reprise est simple à formuler, même s’il exige de la rigueur technique : chaque unité doit être confirmée, vérifiée comme n’ayant pas été appliquée, ou mise à part pour examen. Cet état explicite, associé à des invariants comparables et à des journaux utiles, permet de poursuivre une migration PHP sans confondre progression et réussite, ni incertitude et autorisation de répéter l’opération.
