Recetter un site : la liste que votre prestataire ne vous donnera pas

La livraison arrive. Le client ouvre le site, clique quelques liens, trouve que c’est joli, et valide. Trois semaines plus tard, les problèmes remontent — et le contrat de garantie est discuté.

Recetter est un travail, et il se prépare.

Commencer par les chemins qui rapportent

Lister les trois ou quatre parcours dont dépend l’activité : une commande complète, une demande de devis, une inscription, une déclaration.

Chacun se déroule en entier, jusqu’au bout, y compris le courriel de confirmation et l’apparition de la donnée dans l’outil de gestion. Un formulaire qui affiche « merci » sans que rien n’arrive derrière est un cas classique, et il ne se voit qu’en allant regarder.

Chercher les cas limites, pas les cas nominaux

Le cas nominal fonctionne toujours : il a servi au développement. Les défauts vivent sur les bords :

• un nom avec une apostrophe, un trait d’union, un accent ;
• une adresse à l’étranger, un numéro de téléphone au format international ;
• une quantité nulle, négative, ou à quatre chiffres ;
• un champ texte rempli de mille caractères ;
• deux onglets ouverts sur le même formulaire ;
• le bouton « précédent » du navigateur en plein milieu du parcours.

Ce dernier point est le plus rentable. Le retour arrière casse un nombre surprenant de parcours, et les visiteurs l’utilisent tout le temps.

Recetter avec ses propres données

Une recette faite sur des données de démonstration valide un scénario écrit par le prestataire. Une recette faite avec un vrai catalogue, de vrais libellés et de vraies longueurs de texte révèle les débordements de mise en page, les titres tronqués et les tableaux qui sortent de l’écran.

Le titre de produit le plus long de votre catalogue est un excellent cas de test.

Ce qui n’est pas fonctionnel mais se vérifie quand même

Sur téléphone, sur un appareil réel et pas seulement en réduisant la fenêtre. Au clavier seul, en débranchant la souris, sur un parcours complet. Les pages d’erreur : une adresse inexistante doit afficher une page utile, pas un message technique. Les mentions légales et la politique de confidentialité, qui engagent juridiquement et sont presque toujours livrées avec des mentions à compléter. Le comportement sans JavaScript, en le désactivant : le contenu doit rester lisible.

Formuler les retours utilement

Un retour exploitable comporte l’adresse exacte, ce qui a été fait, ce qui était attendu, ce qui s’est produit, et le navigateur utilisé. « Ça ne marche pas » déclenche un échange de trois messages avant que le travail ne commence.

Une capture d’écran vaut mieux qu’une description, et une capture avec l’adresse visible vaut mieux qu’une capture sans.