Un import d’entreprise ne devrait pas obliger à choisir entre annuler un lot entier à cause d’une ligne défectueuse et intégrer des données douteuses. La quarantaine de données dans les imports PHP offre une troisième option : accepter les enregistrements valides, isoler ceux qui nécessitent une attention particulière et conserver suffisamment de contexte pour les résoudre en toute sécurité.
La quarantaine n’est pas simplement un dossier d’erreurs ni une table où stocker les lignes en échec. C’est un flux opérationnel assorti de règles de classification, d’états explicites, d’une correction contrôlée et de nouvelles tentatives qui ne répètent pas les effets. Pour le concevoir, il convient d’abord de s’accorder sur ce que signifie « valide » pour l’entreprise et sur les actions que chaque rôle peut effectuer.
Classez les erreurs avant de décider quoi faire de chaque ligne
Un import combine généralement différentes vérifications. Les séparer permet d’expliquer le résultat et de décider si l’enregistrement peut continuer, doit être rejeté ou nécessite une vérification humaine.
- Validation structurelle : vérifie le format et le contenu de base : colonnes présentes, types de données, dates interprétables, champs obligatoires et limites raisonnables. Un fichier illisible peut empêcher le traitement du lot ; une date invalide dans une seule ligne ne devrait généralement pas l’empêcher.
- Règles métier : vérifie les conditions du domaine, comme un prix non négatif, un client actif ou une catégorie autorisée. Certaines infractions peuvent entraîner un rejet ; d’autres peuvent dépendre d’une décision opérationnelle.
- Conflits avec les données existantes : détecte, par exemple, un identifiant externe déjà associé à un autre enregistrement ou une mise à jour fondée sur une version obsolète. Ces conflits ne se résolvent pas toujours en corrigeant le fichier : ils peuvent nécessiter un rapprochement ou une vérification.
Définissez une politique pour chaque type d’erreur. Un champ facultatif absent peut accepter une valeur par défaut ; une identité ambiguë ne devrait pas être résolue en choisissant un enregistrement de manière arbitraire. Évitez aussi bien les règles trop permissives que la classification de tout défaut comme erreur fatale. La décision doit refléter les conséquences de l’acceptation de la donnée et le coût de l’interruption du lot.
Modélisez des états et des transitions explicites
Utilisez des états ayant une signification opérationnelle, plutôt que de déduire la situation à partir de champs vides ou de messages textuels. Un modèle initial peut inclure pending, accepted, rejected et needs_review. N’ajoutez des états tels que processing ou resolved que s’ils correspondent à de véritables transitions dans votre flux.
Documentez ce que permet chaque transition. Par exemple, une ligne en attente est validée ; si elle respecte les règles, elle est acceptée et, si elle présente un conflit pouvant être examiné, elle reste en attente de vérification. Une ligne corrigée peut être validée à nouveau, mais une ligne acceptée ne devrait pas être retraitée comme si elle était nouvelle. Enregistrez séparément l’état du lot : un lot peut se terminer avec des lignes acceptées et d’autres en quarantaine ; « terminé partiellement » décrit donc mieux le résultat qu’un indicateur unique de réussite ou d’échec.
Les états doivent correspondre à des décisions vérifiables. « Rejetée » devrait signifier que la modification métier n’a pas été appliquée ; « nécessite une vérification » indique qu’une personne doit prendre une décision. Si l’écrasement de données existantes est autorisé, précisez qui peut le faire et dans quelles conditions.
Conservez l’original et expliquez chaque décision
Enregistrez l’entrée d’origine de la ligne et, séparément, ses valeurs normalisées et le résultat de la validation. Cette séparation permet d’enquêter sur les divergences — par exemple, les différences entre une date reçue et son interprétation — sans faire de la version transformée l’unique élément de preuve disponible.
Une structure de persistance peut inclure un identifiant de lot, un numéro de ligne, une source, une référence au fichier, le contenu d’origine, l’état, les erreurs détectées, les dates de création et de résolution, ainsi que l’acteur responsable. Enregistrez les motifs sous forme de codes stables et de messages compréhensibles : un code comme customer_id_ambiguous facilite le filtrage et la mesure des cas ; le message doit expliquer quelle donnée vérifier. Évitez de vous appuyer sur du texte libre comme unique logique de classification.
Conservez également le contexte nécessaire pour reproduire l’analyse : version ou identifiant des règles utilisées, identifiant externe et données pertinentes pour le conflit. Ne stockez pas de secrets ni de données personnelles superflues dans les journaux techniques. Définissez des contrôles d’accès et une durée de conservation adaptés à la sensibilité des données et aux obligations applicables. Si le fichier complet peut contenir des informations inutiles à la résolution d’une ligne, limitez son exposition.
Corrigez et réessayez sans dupliquer les effets
Pour réessayer en toute sécurité, commencez par distinguer la ligne de la tentative de traitement. Attribuez une identité stable à chaque ligne dans son périmètre, par exemple une combinaison du lot et de l’index de ligne, ou une clé externe validée. Pour les imports répétables, définissez également une clé d’idempotence permettant de reconnaître la même opération. Le choix dépend de ce qui doit se passer lors du rechargement du même fichier : mettre à jour les données, les ignorer ou créer une nouvelle version.
Lors du traitement d’une ligne, effectuez l’écriture métier et le changement d’état de manière atomique, dans la mesure du possible : les deux opérations sont validées ensemble, ou aucune ne l’est. En PHP, une transaction de base de données peut protéger les modifications qui utilisent la même connexion ; elle ne rend pas à elle seule atomique un appel à une API externe. Pour les effets externes, utilisez une stratégie compatible avec le système destinataire, comme des clés d’idempotence, une table d’outbox transactionnelle ou une compensation conçue pour le cas concerné.
Après une correction, relancez les validations pertinentes et conservez l’historique précédent. Ne supprimez pas l’erreur d’origine : ajoutez une nouvelle tentative avec son résultat. Si les règles ou les données de référence changent, indiquez quelle version a été appliquée et évitez qu’une nouvelle tentative ne modifie silencieusement une décision déjà acceptée. La nouvelle tentative ne doit concerner que les enregistrements sélectionnés et ne doit pas relancer indistinctement tout le lot.
Concevez une vérification opérationnelle et auditable
L’interface de vérification doit aider à prendre une décision, et pas seulement afficher une exception technique. Incluez la valeur reçue, le motif, le champ concerné, le contexte pertinent et, lorsque cela ne présente pas de risque, une proposition de correction. Permettez le filtrage par état, lot, type d’erreur et ancienneté ; indiquez clairement quelles lignes ont déjà produit des effets et lesquelles n’en ont pas produit.
Enregistrez qui a examiné le cas, à quel moment, quelle valeur a été modifiée, quelle décision a été prise et pour quel motif. Distinguez la correction effectuée par un opérateur d’une transformation automatique. Appliquez des autorisations en fonction des responsabilités : la personne autorisée à importer un fichier ne devrait pas nécessairement pouvoir approuver des conflits ou modifier des enregistrements acceptés. Pour les changements à fort impact, envisagez une approbation supplémentaire.
Évitez que l’outil facilite l’écrasement d’informations sans avertissement. Avant d’accepter une correction, vérifiez à nouveau l’unicité, les autorisations et l’état actuel de l’enregistrement. Si une autre personne a modifié la donnée depuis la détection du conflit, signalez cette situation afin qu’elle soit résolue, plutôt que d’appliquer une mise à jour obsolète.
Testez les échecs partiels et la reprise
Les tests doivent couvrir les règles aussi bien que le comportement du flux. Incluez des fichiers mêlant lignes valides et invalides, des formats inattendus, des conflits, des erreurs temporaires de base de données et des tentatives répétées. Vérifiez qu’une ligne rejetée n’empêche pas l’acceptation des autres si telle est la politique convenue, et qu’un échec au sein d’une transaction ne laisse aucun effet partiel.
- Le retraitement d’une ligne avec la même clé d’idempotence ne duplique ni les enregistrements ni les actions externes.
- La correction d’un champ permet une nouvelle validation sans supprimer l’original ni l’historique.
- Une ligne déjà acceptée n’est pas appliquée à nouveau lorsqu’une autre ligne fait l’objet d’une nouvelle tentative.
- Les conflits détectés entre la vérification et la résolution ne sont pas écrasés silencieusement.
- Les messages d’erreur permettent d’agir sans exposer inutilement des données sensibles.
En production, surveillez le volume et l’ancienneté des enregistrements en quarantaine, les motifs les plus fréquents, le taux de résolution et les échecs des nouvelles tentatives. Une hausse persistante peut signaler un changement du système source, une règle obsolète ou des instructions de chargement peu claires. La quarantaine est efficace lorsqu’elle rend ces causes visibles et permet de les résoudre de manière contrôlée, et non lorsqu’elle devient un dépôt indéfini d’exceptions.
