Laissez les clients acheter avant de leur demander de s’inscrire
Faites de l’achat en tant qu’invité la voie par défaut visible quand un compte n’est pas nécessaire pour livrer la commande. Les recommandations de formulaires de Google soutiennent cette approche. Conservez la connexion comme option secondaire visible pour les clients récurrents, puis proposez la création de compte après la confirmation avec un bénéfice concret (par ex. historique de commandes). Si un produit est réglementé, si une adhésion ou une politique antifraude exige une authentification, expliquez l’exigence avant le début du formulaire.
Un nouvel acheteur peut atteindre le paiement sans créer de mot de passe lorsque la politique le permet.
Invitez à créer un compte après la commande, pas comme un péage avant le paiement.
Réduire les champs sans rendre la livraison ambiguë
Demandez l’information uniquement lorsqu’elle modifie l’exécution, le paiement, la fiscalité ou la communication requise. Utilisez des contrôles standard, des libellés visibles, des valeurs name et id stables et des attributs autocomplete appropriés. Laissez la facturation correspondre par défaut à la livraison quand c’est vrai, tout en proposant facilement la sélection d’une adresse différente. Le W3C indique que l’information déjà saisie dans le même processus doit être auto-remplie ou disponible à la sélection, sauf cas limités comme la sécurité ou des données invalides.
Chaque saisie doit avoir un but opérationnel ; supprimez-la ou différez-la si aucun but n’existe.
N’utilisez pas un texte d’indice qui disparaît comme seul libellé ; conservez un libellé visible pendant la saisie.
Transformer les erreurs en chemins de récupération
Validez les problèmes locaux simples pendant la saisie ou à la sortie d’un champ, sans interrompre à chaque frappe. Utilisez des conseils de correction clairs et conservez les saisies sûres non sensibles après une erreur. Après une soumission échouée, affichez un résumé d’erreurs lié avant le formulaire et un message correspondant sur chaque champ. Le W3C recommande que chaque élément du résumé identifie le contrôle, décrive le problème et explique comment corriger. Gardez les données de paiement hors des URLs, des logs et des messages d’erreur.
Expliquez ce qui ne va pas et comment le corriger, au lieu d’utiliser « Invalid input. »
Déplacez le focus vers un point de récupération et annoncez les retours dynamiques aux technologies d’assistance.
Proposer des moyens de paiement sans affaiblir le contrôle de la page de paiement
Affichez les méthodes de paiement que l’entreprise peut autoriser, rembourser, rapprocher et supporter. Nommez chaque méthode clairement et révélez les conditions importantes avant l’engagement. Testez un achat réussi, un paiement refusé et la procédure de remboursement ou d’annulation. Les recommandations du PCI SSC sur l’e-skimming insistent sur les scripts autorisés de la page de paiement, la vérification d’intégrité et la détection de manipulation. Avant d’ajouter un tag, widget, expérience, iframe ou contrôle de carte, impliquez le fournisseur et un réviseur qualifié en sécurité ou PCI ; cet article n’est pas une conclusion de conformité.
Maintenez un inventaire approuvé des ressources et de leurs propriétaires pour les pages pouvant affecter le paiement.
Un changement visuellement mineur peut modifier le code exécuté par le navigateur sur la page de paiement.
Faites du parcours mobile et accessible le parcours normal
Testez avec le clavier à l’écran ouvert sur une fenêtre étroite. Utilisez des types d’entrée appropriés et, lorsque utile, inputmode pour suggérer un clavier virtuel adapté ; MDN note que inputmode ne valide pas lui‑même la saisie. Pour les numéros de carte, Google recommande une saisie textuelle avec inputmode numérique plutôt qu’un contrôle de type number. Fournissez des libellés associés visibles, un focus clavier logique, et du texte ainsi que la couleur pour les erreurs et les sélections. Les scans automatisés seuls ne peuvent pas établir que le passage en caisse fonctionne avec toutes les technologies d’assistance.
Complétez le flux avec Tab, Shift+Tab, Enter, Space et Escape là où c’est pertinent.
Testez les adresses et cartes enregistrées par le navigateur, y compris une adresse de facturation distincte.
Garder le coût, la livraison et l’engagement visibles
Conservez les articles, les contrôles de quantité, les remises, le choix de livraison, les frais connus à ce stade et le total visibles au moment du paiement. Quand la livraison, la taxe ou un prélèvement récurrent dépend d’informations ultérieures, indiquez ce qui est estimé et mettez à jour le récapitulatif immédiatement lorsque l’information est connue. Faites correspondre l’action de commande à l’engagement financier, par exemple « Pay and place order ». Permettez aux acheteurs de modifier un article, une adresse ou un choix de livraison sans quitter le passage en caisse.
Gardez le récapitulatif lisible et modifiable à chaque étape du paiement.
Indiquez quand la livraison, la taxe, la remise ou les prélèvements récurrents deviennent définitifs.
Expérimentez comme un changement contrôlé de fiabilité
Changez une chose significative contre une hypothèse écrite, par exemple déplacer la création de compte après la confirmation. Définissez l’audience, la mesure de complétion et les garde‑fous avant la mise en production. Les garde‑fous peuvent inclure erreurs de paiement, soumissions échouées, contacts du support, remboursements, régressions d’accessibilité et problèmes de performance. Utilisez SIU pour tester le chemin d’achat et ses dépendances, documentez un rollback et restaurez la dernière version connue bonne si un garde‑fou est franchi. Un résultat de conversion ne prouve pas la sécurité, l’accessibilité, la conformité légale ou l’adéquation universelle.
Enregistrez d’abord le taux de complétion par étape, les catégories d’erreurs et le comportement technique.
Décidez quel schéma d’échec pause ou inverse la mise en production.