L’opérateur coche une ligne d’inventaire portant REF70, puis trie la liste pour retrouver une autre référence. La case reste visuellement cochée au même endroit, mais cette place affiche maintenant REF20. Le bouton de préparation reprend la nouvelle ligne sans signaler que la sélection a changé d’objet ; le risque apparaît avant toute écriture de stock.
Le défaut peut être pris pour une mauvaise manipulation, surtout quand les lignes se ressemblent. Un comptage par lots rend pourtant le raccourci plus dangereux : deux lignes de REF70 peuvent concerner des lots et des emplacements différents. La référence produit seule ne suffit donc pas non plus à porter le choix de l’opérateur pendant un tri, une pagination ou une mise à jour.
En pratique, la sélection doit conserver l’identité de la ligne d’inventaire et laisser l’écran changer son ordre d’affichage. Le témoin exécuté dans le navigateur compare une mémoire par position et une mémoire par identifiant, puis prépare les valeurs réellement cochées. Huit observations et 39 assertions exposent la substitution, le maintien du bon lot et la sélection de deux lots distincts, sans mouvement de stock réel.
Cette vérification appartient au développement web métier et à la recette des applications métier sur mesure. Dawap cadre les identités, les interactions et les contrôles serveur avec les équipes d’exploitation, pour que le tableau, la préparation et l’effet autorisé restent attachés au même objet.
Pour qui : une sélection porte sur un lot et un emplacement
Reconnaître une ligne qui change sous la case cochée
Le problème concerne les écrans où l’utilisateur sélectionne plusieurs objets avant une opération groupée : inventaire, préparation, contrôle qualité ou reprise de dossiers. Le symptôme apparaît quand l’ordre change entre le choix et la préparation. L’interface peut conserver un compteur exact de cases cochées tout en pointant vers les mauvaises lignes, ce qui rend le défaut difficile à voir depuis un indicateur global.
Pour un inventaire, le responsable doit connaître la granularité de la ligne : article, lot, emplacement, unité de conditionnement ou autre périmètre défini dans l’application. Une grille de produits et une grille de lignes de comptage peuvent afficher la même référence sans désigner le même objet. Cette distinction précède le choix d’un composant frontend ou d’une bibliothèque de tableau.
Ne pas confondre identité sélectionnée et quantité validée
Le témoin ne calcule aucun ajustement de stock et ne décide pas si une quantité comptée est correcte. Il vérifie uniquement quel objet rejoint la préparation locale. Le contrôle métier doit ensuite comparer l’état courant, les droits et les préconditions de l’opération. Une bonne sélection constitue un prérequis de cette validation ; elle ne démontre pas la justesse du mouvement qui pourrait suivre.
Le coût caché vient des recherches après coup : relire les références, retrouver le lot, comparer les écrans et décider si une opération a déjà eu lieu. Mesurez les reprises liées à une sélection déplacée séparément des écarts de comptage. Un utilisateur qui doit revérifier toutes les lignes après chaque tri perd le bénéfice de l’action groupée, même lorsqu’aucun stock n’a été modifié à tort.
Anatomie : position, référence produit et identité d’inventaire
La position décrit une vue temporaire
Dans le témoin, la première ligne est I30 : REF70, lot L7, emplacement A, quantité fictive quatre. I20 porte REF20, lot L3, emplacement B et huit unités fictives. I40 porte encore REF70, mais lot L8, emplacement C et deux unités fictives. Le tri par référence place I20 devant I30 ; la position zéro change donc d’objet.
La mémoire défectueuse conserve ce rang zéro. Après reconstruction du tableau, la case de la ligne maintenant située à ce rang devient cochée. Le défaut est volontaire dans cette application de test : il permet d’observer la conséquence d’une sélection indexée par position, sans attribuer le comportement à un framework ou à un logiciel d’inventaire client.
Une même référence peut correspondre à plusieurs lignes
I30 et I40 partagent REF70 mais portent des lots et des emplacements différents. Le modèle corrigé conserve leurs identifiants de ligne distincts. Le cas G sélectionne les deux et les retrouve séparément dans la préparation. Une mémoire limitée au SKU pourrait les confondre, même si elle résiste au tri ; la clé doit correspondre à l’unité métier que l’action vise réellement.
Dans une application réelle, cette identité peut provenir d’un identifiant persistant ou d’une clé composée qualifiée. Le projet vérifie sa portée dans une campagne, un site et un contexte de gestion. Il ne doit pas inventer une unicité globale d’article à partir d’un libellé visible. Conservez le lien vers l’objet source pour expliquer la préparation et les éventuels refus serveur.
Faire évoluer le tableau sans déplacer l’intention
Séparer état de sélection et ordre des résultats
Le modèle corrigé mémorise I30 indépendamment de sa position. Le rendu recalcule ensuite la case cochée de chaque ligne depuis cette identité. Après tri, I30 apparaît au deuxième rang et reste sélectionnée. La présentation peut changer sans recréer le choix métier ; un compteur de sélection doit être calculé depuis les objets retenus, pas depuis la position de leurs cellules.
La documentation React sur les listes et leurs clés explique pourquoi une clé stable aide à associer les composants aux éléments lors des tris, insertions et suppressions. Le banc utilise cependant du HTML et du JavaScript natifs, sans exécuter React. Une clé de composant adaptée et un état métier correctement identifié sont des contrôles complémentaires.
Expliquer ce qu’un filtre fait aux objets déjà choisis
Si un filtre masque I30, le produit doit définir si sa sélection reste active, devient visible dans un récapitulatif ou est annulée avec un message. Cette politique n’est pas testée par les huit observations de tri. Elle mérite une recette spécifique, parce qu’une case absente du DOM peut correspondre à un objet encore retenu dans l’état applicatif.
La pagination et la virtualisation posent une frontière comparable : les lignes montées à l’écran ne représentent pas nécessairement toute la sélection. Affichez la portée avant l’action groupée et faites vérifier le résultat attendu avec les opérations. « Tout sélectionner » doit préciser page, résultats filtrés ou identifiants choisis, au lieu de laisser le serveur interpréter une liste dont l’origine demeure ambiguë.
Exercice de décision : huit observations depuis les cases réelles
Les actions ont été exécutées dans un navigateur sur trois lignes fabriquées. Le bouton lit les cases du formulaire avec FormData, puis affiche leur préparation JSON locale. Les 39 assertions portent sur ces observations enregistrées : ordre, identités cochées, objets préparés et absence d’appels métier. Aucun ERP, WMS, framework React ou mouvement de stock n’a été exécuté.
| Cas | Action native | Ligne cochée observée | Conséquence locale |
|---|---|---|---|
| A | Mode position, choisir I30 | I30 | REF70, lot L7 sélectionné |
| B | Trier par référence | I20 | Le choix passe à REF20 |
| C | Préparer en mode position | I20 | REF20, lot L3 préparé |
| D | Mode identité, choisir I30 | I30 | REF70, lot L7 sélectionné |
| E | Trier par référence | I30 | Le lot L7 reste choisi |
| F | Préparer en mode identité | I30 | REF70, lot L7 préparé |
| G | Ajouter I40 puis préparer | I30 et I40 | Deux lots de REF70 conservés |
| H | Décocher I30 puis préparer | I40 seulement | Seul le lot L8 reste retenu |
Observer l’objet préparé après le symptôme visuel
Le cas B montre une substitution dans les cases, tandis que C confirme que le bouton utilise effectivement I20 dans cette application. Ces deux observations répondent à des questions différentes. Une capture d’écran seule n’établirait pas ce que prépare le formulaire ; une liste JSON seule ne montrerait pas pourquoi l’opérateur croit encore avoir conservé son choix initial.
La documentation MDN sur la construction de FormData décrit la lecture des contrôles de formulaire. Le témoin vérifie ensuite les valeurs obtenues dans son propre parcours. La recette d’une application cliente doit observer sa véritable méthode de préparation, qui peut utiliser un état frontend ou un payload API différent.
Vérifier les deux lots sans les agréger
Le cas G conserve deux occurrences REF70 et leurs lots L7 et L8. Le cas H retire uniquement I30, sans supprimer I40 qui partage le même SKU. Cette paire de témoins révèle une clé trop large même lorsque le tri est réparé. Elle exige une preuve sur les identités et les lots, au-delà du nombre de produits différents présents dans le récapitulatif.
Par exemple, un inventaire par emplacement peut utiliser la même référence dans deux zones avec des états de comptage différents. Une action groupée doit conserver cette granularité jusqu’au serveur. Le témoin ne calcule aucune somme et ne vérifie aucun stock physique ; la quantité fictive sert seulement à reconnaître l’objet préparé et à éviter une validation limitée au libellé produit.
Revérifier l’identité et les droits avant l’effet métier
Ne pas transformer un identifiant frontend en autorisation
Le backend reçoit les identifiants et qualifie leur campagne, leur site et les droits de l’utilisateur. Un objet stable peut néanmoins être clôturé, modifié ou inaccessible au moment de l’action. Le contrat API doit distinguer ces refus et restituer les lignes concernées. La réussite du témoin navigateur ne démontre aucune de ces protections serveur, qui demandent leurs propres tests d’intégration.
Le payload peut aussi porter une version attendue lorsque le workflow l’exige. Le serveur compare cette précondition à son état de référence avant de produire l’effet. Une divergence rejoint la procédure métier prévue, sans corriger automatiquement la quantité pour rendre le dossier transmissible. Les opérations doivent comprendre si elles doivent actualiser, recompter ou faire examiner le lot concerné.
Conserver le rapport d’une action partielle
Si plusieurs lignes sont traitées, le rapport distingue succès, refus et résultat inconnu avec leur identité originale. La journalisation conserve entrée qualifiée, sortie et responsabilité de reprise, avec les dépendances ERP ou WMS nommées. L’idempotence doit être vérifiée au niveau qui porte réellement l’écriture ; un identifiant de ligne ne prouve pas qu’un retry ne répétera pas un effet.
Le runbook définit le seuil d’arrêt et le repli lorsque le résultat externe manque. Le monitoring suit les dossiers à rapprocher au lieu de les annoncer réussis parce que l’interface s’est vidée. Ces contrôles complètent la sélection stable. Ils restent distincts des 39 assertions sur les observations du navigateur, afin que l’équipe sache quelle propriété chaque test démontre.
Maintenir le contexte pour le clavier et la lecture du tableau
Nommer la case avec l’objet qu’elle représente
Le témoin donne aux cases un nom incluant identifiant, référence et lot, ce qui permet une sélection non ambiguë pendant la recette. L’application réelle doit présenter les informations nécessaires à ses opérateurs, sans imposer un identifiant technique illisible comme seul repère. Un libellé accessible doit aussi distinguer les deux lots de la même référence lorsque les cellules sont parcourues au clavier.
Après tri, le focus ne doit pas laisser croire qu’il concerne encore une ligne qui a été remplacée. Testez le changement d’ordre, la case retenue et la lecture de son lot avec votre composant réel. Le banc utilise des cases natives et ne constitue pas un audit complet d’accessibilité. Une grille interactive demande une recette supplémentaire de navigation et de gestion du focus.
Montrer la sélection avant de préparer le lot d’opérations
Un récapitulatif doit nommer les objets retenus, leurs lots et la portée de l’action. Il peut être utile lorsque le tableau dépasse la largeur mobile ou plusieurs pages, mais ne répare pas une sélection déjà indexée par position. Comparez le récapitulatif avec les cases après chaque transformation importante, puis avec la sortie préparée lorsque l’opérateur confirme son intention.
Paradoxalement, un compteur stable peut renforcer une mauvaise confiance : une case reste cochée dans les cas A et B, alors que son identité change. Le nombre de lignes ne constitue donc pas la preuve principale. Le contrôle vérifie l’ensemble des identifiants et la possibilité de retrouver les détails, avec une explication visible si certains objets ont quitté le périmètre autorisé.
Distinguer le tri d’une mise à jour du comptage
Ne pas conserver aveuglément une ligne devenue invalide
Un tri change la position sans nécessairement changer l’objet. Une actualisation peut au contraire modifier son état, sa quantité ou sa disponibilité. Le modèle doit conserver l’identité du choix tout en requalifiant sa validité. Si la ligne sélectionnée n’est plus admissible, l’interface l’explique et suspend l’action correspondante au lieu de substituer la prochaine ligne disponible.
Cette politique n’est pas exécutée dans le témoin : les trois objets restent immuables. Ajoutez un scénario dans lequel le serveur ferme I30 après son choix, puis vérifiez la préparation et le refus attendu. Un traitement optimiste peut améliorer l’interface, mais sa confirmation doit rester compatible avec le workflow et la capacité réelle à récupérer une opération devenue obsolète.
Garder une version pour expliquer la divergence
La traçabilité rapproche la version affichée, celle préparée et celle finalement acceptée par le service métier. Elle doit permettre d’identifier une mise à jour externe plutôt que d’attribuer toute différence à l’utilisateur. Le délai entre choix et exécution constitue un contexte de diagnostic ; il ne justifie pas une tolérance qui laisserait traiter un autre objet à sa place.
La conservation des observations reste proportionnée à leur utilité et aux droits applicables. Les logs techniques n’ont pas besoin d’accumuler l’ensemble du référentiel ou les données d’autres sites. Un jeu anonymisé doit reproduire l’ordre et les identités nécessaires au défaut. La recette compare ensuite les mêmes témoins sur la version qui sera réellement déployée.
Erreurs fréquentes : réparer l’affichage sans réparer la préparation
Choisir une clé stable pour un objet trop large
Une clé SKU peut paraître meilleure qu’un index et continuer de confondre I30 avec I40. Le remède dépend de la granularité de l’action, pas seulement de la stabilité d’une chaîne. Définissez l’identité de ligne avec les opérations, puis vérifiez qu’une désélection du lot L7 laisse le lot L8 intact lorsque les deux portent REF70.
Par exemple, le code-barres d’un article peut être commun à plusieurs lots suivis dans l’application. L’utiliser comme unique identité de comptage efface une distinction métier. Le traitement du scan et la sélection des lignes doivent donc partager un référentiel qualifié, sans supposer que chaque lecture physique désigne automatiquement une occurrence unique dans la campagne ouverte.
Vérifier uniquement les classes visuelles de la case
Un style correct ou une coche visible ne suffit pas à qualifier le formulaire préparé. Le cas C lit I20 après la substitution, tandis que F lit I30 après conservation de son identité. Testez la frontière réellement utilisée : valeurs des contrôles, état applicatif ou construction du payload. Une capture doit compléter cette observation et rester rattachée au même scénario.
Lors d’un rafraîchissement asynchrone, le tableau et son récapitulatif peuvent momentanément présenter des versions différentes. Le parcours doit suspendre une confirmation dont la portée n’est pas encore établie, puis montrer les objets qui seront préparés. La recette examine cet état intermédiaire avec le composant réel ; le tri synchrone du témoin ne prouve aucune protection contre une réponse réseau arrivée en retard.
Plan d’action : observer la ligne du choix à la préparation
Recetter le tableau utilisé par les opérations
Commencez avec trois lignes distinctes, dont deux partagent une référence mais pas le lot. L’opérateur choisit une ligne, change le tri puis prépare son action par le bouton normal. Le développeur compare identités cochées et sortie préparée ; le responsable métier valide la portée. Les dépendances serveur et les droits restent explicitement hors de ce premier témoin de rendu.
La livraison conserve la fixture et la version du composant observé, puis rejoue le parcours depuis un chargement propre. Le rollback peut rétablir l’ancien écran, mais ne retire pas une opération déjà envoyée au service métier. Les responsabilités de rapprochement et le rapport des effets partiels doivent rester accessibles pendant le repli, avec une prochaine action attribuée aux opérations.
- Refuser une préparation dont les identifiants diffèrent du choix conservé par l’utilisateur.
- Conserver séparément deux lots d’une même référence pendant le tri et la désélection.
- Valider le comportement des objets masqués avant d’ouvrir une sélection sur plusieurs pages.
- Tester les préconditions backend avant d’autoriser une écriture de stock ou une reprise.
Relier l’identité aux risques du parcours complet
Le cadrage des listes et filtres du back-office pose les questions de portée, volume et action groupée. Le témoin d’inventaire apporte une preuve plus étroite sur la position, la ligne et le lot. Gardez ces niveaux séparés pour que la correction reste testable sans promettre une refonte générale de tous les tableaux.
La stratégie de tests d’une application métier critique aide à placer ensuite les preuves backend et de reprise. Le seuil de livraison dépend des effets autorisés par votre application : le banc local ne réalise aucun comptage officiel. Faites observer les conséquences au niveau qui peut réellement les rompre, avec une fixture maintenable et un responsable de diagnostic.
Conclusion : déplacer les lignes sans déplacer les objets choisis
Le rang d’une ligne appartient au tableau courant, tandis que l’identité d’inventaire appartient à la décision de l’opérateur. Une sélection stable conserve cette frontière pendant les tris et distingue aussi les lots d’un même produit. Le compteur et la coche complètent la lecture ; ils ne remplacent pas la vérification des objets préparés.
Les huit observations natives et les 39 assertions montrent une substitution REF70 vers REF20, puis la conservation de I30 et la séparation de I40. Les valeurs proviennent de cases et de préparations JSON fabriquées. Cette preuve n’exécute ni React, ni API de stock, ni règle d’ajustement ; les protections serveur restent nécessaires avant tout effet métier.
Avant de généraliser une action groupée, faites reproduire le tri, la désélection et la préparation avec les opérations. La conception d’une application métier sur mesure doit définir la granularité, les objets masqués et les conflits, avec des témoins adaptés au workflow réellement autorisé.
Dawap vous accompagne en développement web pour relier l’expérience de sélection, les contrats de données et les contrôles backend. Nous cadrons la recette sur vos identités et vos lots, afin que l’utilisateur puisse retrouver l’objet choisi jusque dans la préparation et les reprises permises.
