Cette checklist s'adresse à une entreprise qui prépare la réception d'un configurateur de produit, d'offre ou de projet. Elle permet de définir les preuves attendues avant d'accepter la livraison, sans imposer de technologie particulière.

Définir ce que le configurateur doit livrer

La sortie attendue change les contrôles. Une estimation sert à orienter le visiteur ; une demande de devis doit transmettre assez d'informations pour être traitée ; un achat doit retrouver les choix et le montant validés dans la commande. Écrivez cette sortie avant de tester les écrans.

Précisez aussi qui maintient les options, leurs incompatibilités et les tarifs. Choisissez une configuration de référence dont le résultat attendu est calculé séparément, à partir du tarif et des règles approuvés. Si le résultat attendu est simplement recopié depuis le configurateur, le test peut confirmer sa propre erreur.

Une grille de recette à reprendre avec votre prestataire

Pour chaque ligne, consignez la configuration utilisée, le résultat attendu, le résultat obtenu et une preuve : capture du récapitulatif, référence de demande ou enregistrement reçu. Faites les essais sur un environnement prévu à cet effet, avec des coordonnées de test.

Situation à provoquer Résultat attendu Preuve à conserver
Terminer une configuration de référence Choix, quantités et total conformes au calcul indépendant. Récapitulatif et calcul de référence.
Revenir au premier choix après avoir ajouté des options Les options devenues incompatibles sont retirées ou signalées avant validation ; le prix suit. Comparaison avant et après modification.
Essayer une combinaison interdite La règle est expliquée et la configuration ne peut pas être validée en l'état. Message et absence de demande invalide.
Saisir une dimension ou quantité à sa limite autorisée, puis juste au-delà La limite métier est respectée ; l'unité et la correction attendue sont claires. Valeurs essayées et réponses.
Changer rapidement plusieurs options tarifées Le prix final correspond au dernier choix, même si les réponses réseau arrivent dans un autre ordre. Choix final et montant confirmé.
Actualiser la page ou revenir plus tard Le comportement prévu est respecté : reprise cohérente ou avertissement explicite avant de recommencer. État retrouvé et message affiché.
Envoyer deux fois la même demande ou réessayer après une coupure Une même soumission est reconnue et son état vérifiable, sans doublon silencieux. Référence de soumission et contrôle dans l'outil destinataire.
Refaire le parcours sur téléphone et au clavier Choix, erreurs et récapitulatif restent accessibles ; aucun contrôle essentiel n'est masqué. Parcours observé et anomalies éventuelles.
Modifier un tarif après avoir enregistré une configuration L'ancien prix reste identifiable ; toute actualisation est expliquée avant confirmation. Version du tarif et règle de recalcul.

Cette grille constitue un socle. Ajoutez les règles propres à votre activité : disponibilité, zone desservie, délai de fabrication ou validation technique. Un configurateur destiné uniquement au devis n'a pas à simuler un paiement, mais son arrivée dans l'outil commercial doit être contrôlée.

Prix : distinguer l'affichage de la validation

Le visiteur doit comprendre ce que le montant inclut : options, quantité, devise, taxes et éventuels frais encore à déterminer. Une estimation doit être désignée comme telle. Pour une vente, comparez le récapitulatif avec le montant réellement présenté au paiement.

La vérification technique doit aussi confirmer qu'une modification du prix envoyé par le navigateur ne permet pas d'imposer ce montant. L'OWASP recommande de recalculer les valeurs sensibles côté serveur à partir de données fiables, plutôt que de faire confiance aux champs transmis par le client. Demandez une preuve de ce contrôle sur l'environnement de test : un total juste à l'écran ne le démontre pas.

Exemple méthodologique : une option devenue impossible

Prenons un configurateur fictif d'abri de jardin. La finition choisie n'est disponible que pour certains modèles. Le visiteur sélectionne cette finition, puis revient changer de modèle.

Le test consiste à suivre la même configuration jusqu'au bout. Le nouveau modèle doit déclencher la règle convenue : demander une autre finition ou retirer celle devenue incompatible en l'expliquant. Son supplément doit disparaître du total si l'option est retirée. Le récapitulatif et la demande reçue doivent décrire exactement le même abri.

Cet exemple illustre une méthode de recette ; il ne décrit aucun client ni résultat de Codezilla. Il vérifie une règle à travers plusieurs écrans et jusqu'à la réception, là où des tests écran par écran peuvent laisser passer une incohérence.

Parcours : permettre de comprendre et de corriger

Sur un parcours en plusieurs étapes, indiquez la progression et préservez les choix lorsque le visiteur revient les vérifier. Le W3C recommande de structurer les formulaires par étapes logiques et de rendre leur progression compréhensible.

Une incompatibilité ne doit pas se traduire par un bouton inactif sans explication. Le guide W3C sur les notifications de formulaire préconise des retours clairs sur les erreurs et la réussite de l'envoi. Dans la recette, vérifiez que le visiteur repère le problème, comprend comment le corriger et conserve les autres informations déjà saisies.

Réception : vérifier ce que l'équipe pourra utiliser

Ouvrez la demande dans sa destination réelle : boîte de réception, CRM, outil de devis ou commande. Comparez-la au récapitulatif. Elle doit permettre de retrouver la configuration, ses options, ses quantités, le montant et son contexte tarifaire, ainsi que les coordonnées nécessaires au traitement.

Distinguez la réception dans le système du départ d'un email. Si la demande est enregistrée mais que la notification échoue, l'équipe doit pouvoir la retrouver. Si l'envoi reste incertain, le visiteur doit pouvoir connaître son état ou réessayer sans créer une nouvelle demande à son insu.

Quand reporter l'ouverture ?

Un prix faux, une combinaison interdite acceptée ou une demande introuvable sont des motifs de report. Une anomalie visuelle secondaire peut être planifiée si elle ne gêne ni la compréhension ni l'action. Pour chaque réserve, désignez la personne qui valide sa correction et le scénario à rejouer.

Cette recette ne remplace pas un audit complet de sécurité ou d'accessibilité. Elle établit un point précis : les règles prioritaires du configurateur ont été vérifiées jusqu'à leur résultat métier. Pour cadrer un développement sur mesure relié à votre site, préparez vos règles, une configuration de référence et la destination des demandes. Échangeons sur votre configurateur à partir de ces éléments.

Pour préparer la suite