Un site peut être beau et rester difficile à reprendre. Le test du relais consiste à confier quelques opérations courantes à une personne qui n’a pas participé au développement, puis à observer ce qu’elle peut réellement faire.
Pour un projet Phoenix, cette vérification relie la promesse d’autonomie aux champs, aux blocs et aux parcours livrés.
Définir les scénarios avant la validation
Choisissez des tâches représentatives du site. Une communauté peut demander de publier un guide, d’annoncer une séance et de modifier un lien d’inscription. Une entreprise peut privilégier les services, les coordonnées et les demandes de contact.
Chaque scénario doit avoir un résultat observable. « Le formulaire fonctionne » devient : une personne saisit des informations valides, voit la confirmation et l’équipe reçoit le message attendu.
Le périmètre dépend des fonctions réellement installées. Une recette ne doit pas faire croire qu’une intégration absente a été validée.
Tester la gestion des contenus
Demandez à la personne de changer le titre du hero, remplacer une image et ajouter une question de FAQ. Elle doit pouvoir identifier la page et les champs sans ouvrir les fichiers du design.
Essayez aussi un texte plus long que la démonstration initiale. Les cartes, les boutons et les colonnes doivent rester cohérents lorsque les contenus évoluent.
Notez les hésitations. Une instruction manquante, un nom de champ ambigu ou une valeur écrite dans un fichier sont des points de passation à améliorer.
Contrôler les parcours publics
Ouvrez le site déconnecté et utilisez le menu comme un nouveau visiteur. Vérifiez les destinations, le contact, les pages légales et les liens externes.
Testez les ressources ZIP : fichier attendu, nom compréhensible, contenu correspondant à l’article et README présent. Un bouton visible ne prouve pas que le téléchargement peut être terminé.
Pour les événements, vérifiez la date et le fuseau, puis les parcours gratuit et payant lorsqu’ils sont prévus. Testez aussi l’abandon et l’erreur, pas seulement le cas idéal.
Examiner la présentation et l’accessibilité
Parcourez la page sur un petit écran et avec un agrandissement du texte. Utilisez le clavier pour atteindre les liens et les contrôles.
Vérifiez les noms des liens, les textes alternatifs pertinents et les contrastes. Les animations non essentielles doivent respecter la préférence de réduction des mouvements.
Dans un guide technique, copiez un exemple depuis Prism et contrôlez son contenu. Un défilement horizontal doit rester limité au bloc de code.
Séparer les preuves et les points à confirmer
Gardez un tableau de recette qui distingue le résultat, la date du contrôle et la personne qui l’a réalisé.
| Scénario | Preuve utile | Point à reprendre si échec |
|---|---|---|
| Modifier une page | Changement visible après publication | Source du champ et cache |
| Envoyer un formulaire | Confirmation et réception attendues | Traitement, antispam et envoi |
| Télécharger un ZIP | Archive lisible et complète | Dossier, droits et point d’entrée |
| Consulter sur mobile | Parcours lisible sans débordement | Grilles, médias et code |
Des tests avec des données simulées vérifient une logique, mais ne prouvent pas à eux seuls la configuration du serveur, du courriel ou des services tiers. Indiquez cette limite dans la livraison.
Préparer une passation courte
Documentez les écrans à utiliser, les opérations courantes et les responsabilités. Précisez aussi qui effectue les mises à jour, conserve les sauvegardes et reçoit les alertes.
Une liste d’accès et de secrets reste dans un outil interne approprié. Les exemples publics expliquent le fonctionnement sans exposer les identifiants de l’équipe.
Le site est plus facile à reprendre lorsque la personne peut réaliser les tâches prévues et sait à qui s’adresser pour les autres. Le guide de gestion des contenus peut accompagner cette première prise en main.
