Une opération qui modifie des centaines d’enregistrements peut respecter ses règles tout en affectant davantage de données que prévu. Une confirmation générique — « Êtes-vous sûr ? » — ne permet ni d’évaluer la portée de l’opération ni de détecter des conditions inattendues. Un aperçu des modifications en PHP doit montrer quels enregistrements seraient concernés, quelles valeurs changeraient et dans quelles conditions l’opération pourrait être exécutée.
L’aperçu réduit les surprises, mais ne garantit pas que l’exécution ultérieure produira exactement le même résultat. Entre les deux phases, les données, les autorisations ou la portée de l’opération peuvent changer. La conception doit rendre cette incertitude visible et valider à nouveau les éléments nécessaires avant toute écriture.
Quand un aperçu est utile
Il est pertinent d’envisager un aperçu pour les opérations en masse, sensibles ou difficiles à annuler : mettre à jour des prix, changer des états, réattribuer des comptes, supprimer des informations ou recalculer des données dérivées. Il est également utile lorsque la personne qui lance la tâche doit examiner son impact ou obtenir une approbation avant de l’exécuter.
Toutes les actions n’ont pas besoin d’une interface d’aperçu. Si une opération est limitée, réversible et que son résultat ne prête pas à équivoque, une confirmation contextuelle peut suffire. En revanche, si l’utilisateur ne peut pas savoir ce que signifie confirmer, le problème exige d’afficher des données concrètes, et non d’ajouter une autre boîte de dialogue.
L’aperçu ne remplace pas non plus une sauvegarde, un mécanisme de retour arrière ni une politique d’approbation. Si une erreur peut avoir de graves conséquences, il faut envisager des contrôles supplémentaires, tels que l’approbation par une autre personne, une exécution progressive ou un processus de récupération éprouvé.
Séparer le calcul de l’application
La règle métier doit pouvoir calculer une proposition sans modifier la base de données. Une stratégie pratique consiste à partager la sélection et le calcul entre deux modes : l’un décrit la modification et l’autre l’applique. Éviter deux implémentations indépendantes réduit le risque que l’aperçu et l’exécution interprètent différemment les règles.
Pour chaque élément concerné, la proposition peut inclure :
- Un identifiant permettant de reconnaître l’enregistrement.
- Les valeurs actuelles pertinentes et les valeurs attendues.
- La raison pour laquelle l’élément est inclus ou exclu.
- Les validations effectuées et les conflits détectés.
- La portée de l’opération, comme les filtres, le compte ou la période.
Par exemple, une opération visant à changer l’état de commandes peut afficher l’état actuel, l’état proposé et la raison pour laquelle la commande est admissible. S’il y a trop d’éléments pour tous les afficher à l’écran, il est possible de présenter des totaux et un échantillon, à condition de préciser ce qui est affiché et de permettre, si nécessaire, d’inspecter ou d’exporter le détail.
En PHP, il est préférable d’encapsuler la sélection et le calcul dans des composants aux responsabilités clairement définies. Un service métier peut produire les modifications proposées ; un autre composant peut les présenter ; et une route applicative peut se charger de les valider et de les persister. L’aperçu ne doit pas déclencher indirectement une écriture par des effets de bord liés à la lecture.
Valider les données, les autorisations et la portée
Une proposition utile explique non seulement ce qui changerait, mais aussi pourquoi la modification est autorisée. Validez les conditions métier à partir des données actuelles et vérifiez que l’utilisateur a l’autorisation de consulter et d’exécuter l’opération. L’autorisation de consulter des enregistrements n’implique pas nécessairement celle de les modifier.
La portée doit être explicite. Si l’action dépend de filtres, d’une sélection ou du chargement d’un fichier, consignez ces paramètres de façon compréhensible et indiquez les limites, les exclusions et les erreurs. Évitez qu’une recherche trop large ou un filtre omis transforme accidentellement une action limitée en modification globale.
Il faut également signaler ce qui ne peut pas être prévu avec certitude. L’aperçu n’anticipe pas automatiquement les modifications effectuées par d’autres processus, les règles exécutées dans des systèmes externes ni les effets de bord dépendant d’un état futur. En présence d’intégrations, de files d’attente ou de calculs ultérieurs, décrivez ces effets séparément et ne les présentez pas comme faisant partie du résultat confirmé.
Éviter d’appliquer une proposition obsolète
Un aperçu représente les données à un instant donné. Si elles changent avant l’exécution, une commande peut ne plus remplir les conditions requises, un utilisateur peut perdre ses autorisations ou un enregistrement peut avoir été mis à jour par un autre processus. Le résultat affiché ne doit donc pas être considéré comme une autorisation permanente d’écrire.
Lors de l’exécution, vérifiez à nouveau les conditions qui déterminent l’admissibilité ainsi que les autorisations. Selon le cas, vous pouvez comparer une version de l’enregistrement, un horodatage ou les valeurs pertinentes avec celles observées lors du calcul de la proposition. En cas d’écart, ne prenez pas silencieusement une décision différente : signalez le conflit et demandez de générer un nouvel aperçu ou de le résoudre explicitement.
Dans les processus qui exigent une correspondance stricte, conservez une référence à la proposition et vérifiez que son application utilise toujours sa portée et ses règles. Une transaction peut protéger un ensemble d’écritures contre les défaillances intermédiaires, mais elle ne supprime pas à elle seule le délai entre l’aperçu et l’exécution. La stratégie de concurrence doit être adaptée au risque et au volume de l’opération.
Exécuter par lots et consigner les résultats
Pour les gros volumes, tout appliquer en une seule opération peut prolonger les verrouillages et compliquer la récupération. Définissez des limites de lot adaptées à la base de données et au comportement de l’application. En cas d’échec partiel, l’utilisateur doit pouvoir distinguer les enregistrements appliqués, ceux qui ont été ignorés et ceux qui nécessitent un examen.
Consignez suffisamment d’informations pour examiner le résultat : qui a lancé et approuvé l’opération, quand elle a été préparée et exécutée, quelle portée a été demandée, combien d’éléments ont été traités et quelles erreurs sont survenues. Évitez d’enregistrer des données personnelles ou des valeurs sensibles sans nécessité ; les journaux d’audit doivent eux aussi respecter les contrôles d’accès et les règles de conservation applicables.
Si l’opération est relancée, tenez compte de l’idempotence : la répétition d’une requête ne doit pas produire d’effets inattendus en double. Un identifiant d’opération et des états d’exécution peuvent aider à reconnaître les requêtes répétées et à distinguer la préparation, l’approbation, l’exécution et la finalisation. Ne présentez pas le déploiement du code comme équivalent à la mise à disposition ou à l’activation de l’opération : ce sont des décisions distinctes qui doivent disposer de leurs propres contrôles.
Vérifier que l’aperçu ne modifie pas les données
Les tests doivent vérifier à la fois le calcul et l’absence d’écriture en mode aperçu. Utilisez des données représentatives pour vérifier les inclusions, les exclusions, les valeurs actuelles et proposées, les autorisations insuffisantes et les validations en échec.
Vérifiez également que l’exécution applique la proposition attendue et que les changements concurrents produisent le comportement défini. Testez les défaillances au sein d’un lot, les nouvelles tentatives et les erreurs d’intégration, le cas échéant. Les tests d’intégration avec la base de données sont importants : un test unitaire du calcul ne démontre pas qu’une route d’aperçu est dépourvue d’effets de bord.
Les cas limites doivent inclure des filtres vides, des volumes importants, des enregistrements supprimés ou modifiés entre les phases et des utilisateurs ayant des périmètres d’accès différents. Il est également utile de vérifier que l’interface n’affirme pas « ces éléments précis seront mis à jour » si l’application recalcule l’ensemble au moment de l’exécution.
Liste de contrôle pour déterminer le contrôle nécessaire
- L’opération concerne-t-elle de nombreux enregistrements, a-t-elle des effets difficiles à annuler ou nécessite-t-elle une approbation ?
- La portée, les éléments concernés ainsi que les valeurs actuelles et attendues sont-ils affichés ?
- L’aperçu est-il séparé des écritures et de leurs effets de bord ?
- Les autorisations, les règles métier et les données sont-elles validées lors de la préparation comme de l’exécution ?
- Les changements importants survenus entre les deux phases sont-ils détectés ?
- Existe-t-il des limites de lot, une procédure définie pour les échecs partiels et des journaux d’audit proportionnés ?
- Les tests confirment-ils que l’aperçu ne modifie pas les données et que l’exécution respecte le résultat validé ?
Un aperçu est approprié lorsqu’il aide à prendre une décision éclairée et que ses limites sont clairement définies. S’il est impossible de fournir une estimation fiable de l’impact, mieux vaut réduire la portée, commencer par une exécution dans un environnement contrôlé ou exiger un examen supplémentaire, plutôt que de transformer un chiffre ou une liste partielle en promesse de résultat.
