Préparer les critères avant la dernière semaine
Transformez les besoins du projet en scénarios : trouver un service, envoyer une demande, recevoir une confirmation, modifier un contenu et retrouver un dossier. Pour chacun, décrivez le point de départ, les étapes et le résultat attendu. Nommez la personne qui valide le fonctionnement métier.
Distinguez ce qui bloque le lancement de ce qui peut être planifié ensuite. Un formulaire qui perd une demande est bloquant ; un espacement légèrement différent peut attendre. Les critères doivent être convenus avant le jour du lancement pour éviter des arbitrages improvisés.
Tester les parcours complets
Sur chaque parcours prioritaire, vérifiez le mobile, le clavier et les cas d’erreur. Envoyez une demande de test identifiable, puis contrôlez sa réception dans les outils prévus. Supprimez ou archivez proprement les données d’essai selon la procédure convenue.
Pour un site marchand, testez notamment les variantes, les frais de livraison, les confirmations et les retours d’échec de paiement dans un environnement adapté. Pour un espace privé, vérifiez qu’un utilisateur ne peut pas consulter les données d’un autre compte en modifiant une URL.
Contrôler contenus et référencement
Vérifiez les titres, les descriptions, les liens internes et les URL canoniques. La préproduction peut être protégée contre l’indexation ; la version publique doit recevoir les réglages appropriés lors du basculement. Ne retirez pas une protection au hasard sans distinguer les environnements.
Relisez les coordonnées, les prix et les promesses. Vérifiez le plan de redirection des anciennes pages et la présence des nouvelles destinations dans le maillage. Une page « introuvable » graphiquement réussie ne doit pas renvoyer un statut de succès à la place d’une véritable erreur.
Documenter les anomalies et la décision
Une anomalie doit contenir une URL, les conditions de test, les étapes de reproduction, le résultat attendu et le résultat constaté. Cela permet de corriger sans multiplier les échanges. Rejouez le scénario après correction, puis quelques parcours voisins si la modification touche un composant partagé.
Avant le lancement, confirmez la sauvegarde, le responsable du basculement et le moyen de retour en arrière. Après publication, rejouez les parcours essentiels sur la vraie adresse et contrôlez les transmissions. La recette en préproduction ne couvre pas tous les effets du changement d’environnement.
Questions fréquentes
Qui doit faire la recette ?
L’équipe technique vérifie le système ; les responsables métier confirment les usages et les contenus. Leurs validations sont complémentaires.
Faut-il tester tous les navigateurs possibles ?
Définissez une couverture adaptée au public et aux données disponibles, puis concentrez les scénarios critiques sur les environnements réellement utilisés.
Passer à l’action
Transformez vos objectifs en scénarios vérifiables avant de fixer le lancement. IIDI peut structurer votre recette.
Référence utile
W3C WAI — Premières vérifications d’accessibilité, un point de départ qui ne remplace pas une évaluation complète.
IIDI relie stratégie, design, technologie et acquisition.
Nous transformons ce sujet en feuille de route priorisée, puis en dispositif concret, mesurable et administrable par vos équipes.