Commencez par les parcours critiques, pas par un scan géant
Choisissez cinq à dix URL et définissez le résultat attendu pour chacune : une page de confirmation, un reçu, un enregistrement CRM ou un handoff vers un prestataire. Incluez des pages publiques et des actions qui génèrent des revenus, instaurent la confiance, créent des demandes de support ou génèrent une obligation légale. Testez comme visiteur dans une fenêtre de navigateur en session non authentifiée et sur un téléphone.
Si un tiers gère une étape critique, cartographiez le handoff et le contact de support. Vous pouvez tester votre transition, mais vous ne pouvez pas certifier ce que réalise ce prestataire. Classifiez les constats en blocage, dégradation matérielle ou amélioration pour que le travail cosmétique ne dissimule pas un parcours cassé.
Couvrez les routes qui génèrent des revenus, instaurent la confiance, créent des demandes de support ou des obligations légales.
Chaque constat matériel nécessite un responsable nommé et une date cible.
Vérifiez l’usage accessible autant que l’apparence
L’accessibilité signifie que des personnes peuvent percevoir et utiliser le site avec différents modes d’entrée et technologies d’assistance. Sur les pages sélectionnées, parcourez au clavier (Tab) la navigation, les menus, les contrôles et les formulaires. Vérifiez la visibilité du focus clavier, l’opérabilité sans souris des contrôles essentiels, et un accès au contenu principal. Les Easy Checks du W3C identifient le focus clavier et un lien de saut comme des éléments utiles pour un premier examen.
Inspectez le texte alternatif des images, les titres de page, les rubriques, le contraste, le comportement au zoom, les alternatives médias lorsque nécessaire, les labels de formulaire, les champs obligatoires et les messages d’erreur compréhensibles. Envoyez une soumission de test non sensible. Ce n’est pas un audit de conformité : le W3C met en garde qu’une page peut passer des vérifications rapides tout en contenant des barrières significatives. Faites appel à une évaluation qualifiée pour les travaux à risque élevé, les refontes ou les problèmes connus.
Testez les labels, instructions, erreurs et le chemin effectif jusqu’à la confirmation.
Le texte alternatif doit communiquer l’objet d’une image ; les rubriques doivent organiser la page.
Examinez la découvrabilité sans promettre un classement
Le SEO aide les moteurs de recherche à comprendre le contenu et aide les personnes à décider si elles doivent visiter depuis la recherche. Pour chaque page prioritaire, lisez le titre, l’en-tête principal, le texte d’ouverture, l’URL et les liens internes comme si vous étiez un nouvel arrivant. Ils doivent énoncer l’objectif et conduire à des étapes utiles. Google recommande des URLs descriptives, du contenu utile et des textes d’ancrage descriptifs.
Si vous utilisez Google Search Console, inspectez les URL clés après une mise en production significative. Google indique que l’Inspection d’URL peut aider à vérifier comment son robot voit une page et s’il peut accéder aux ressources importantes. Corrigez les blocages accidentels, les liens internes cassés ou les chemins peu clairs, puis laissez du temps pour le recrawling. Google ne garantit pas l’indexation ni le classement.
Ouvrez les liens internes en étant déconnecté et consignez les pages 404, les boucles et les destinations non pertinentes.
Observez la délivrance là où les visiteurs la ressentent
La délivrance comprend la réponse du serveur, les images, polices, scripts, la mise en cache et les tiers. Lancez un contrôle de performance dans le navigateur sur les pages prioritaires, puis répétez la tâche principale sur un téléphone réel. Notez le contenu primaire tardif, les contrôles lents, les sauts de mise en page, les ressources échouées ou les bannières qui bloquent une tâche. Core Web Vitals est un cadre d’expérience utilisateur (web.dev) ; utilisez les mesures pour cibler l’investigation, pas pour remplacer les tests de parcours.
Passez en revue les nouvelles balises, widgets, embeds, polices et changements d’images avec l’implémenteur. Les caches HTTP réutilisent des réponses antérieures. MDN explique que Cache-Control communique des instructions de mise en cache et que les réponses mises en cache peuvent être fraîches ou périmées. Après une mise en production, comparez des sessions ordinaires et des sessions avec cache vidé, puis demandez au responsable technique d’examiner les en-têtes et les règles CDN. Évitez les changements globaux de cache sans comprendre leurs impacts sur la confidentialité et les versions.
Enregistrez si le contenu primaire apparaît, si la page reste stable et si les contrôles essentiels répondent.
MDN note qu’un cookie seul ne rend pas une réponse privée ; demandez à un responsable technique d’examiner la mise en cache personnalisée.
Confirmez le socle de sécurité et protégez les changements de paiement
Un contrôle par le propriétaire peut repérer des lacunes visibles ; ce n’est pas un test d’intrusion. Ouvrez le site public en HTTPS et essayez en HTTP. OWASP recommande TLS pour toutes les pages et décrit la redirection du trafic HTTP public vers HTTPS comme une approche courante. Faites remonter les avertissements de certificat ou de contenu mixte, les domaines inattendus et les pages HTTP qui servent du contenu au lieu de rediriger en toute sécurité.
Confirmez la propriété actuelle des accès de publication, domaine, DNS, paiement, plugins et sauvegardes. Un professionnel qualifié ou le fournisseur doit revoir la configuration TLS, le patching, l’authentification, la configuration serveur et les logs. Pour les paiements, n’utilisez que la méthode de test approuvée par le prestataire ou un environnement non production sûr. N’insérez jamais de données de carte réelles ou d’identifiants dans un test informel et ne prétendez pas qu’un examen visuel prouve la conformité PCI.
Considérez un avertissement de certificat, un avertissement d’insecure content ou une redirection inattendue comme un motif d’arrêt de publication jusqu’à investigation.
Orientez les suspicions de compromission, les exigences de sécurité et les questions de conformité paiement vers des reviewers qualifiés.
Prouvez la récupération et bouclez le suivi
Listez ce qui reconstruit le parcours prioritaire : version de l’application, base de données, médias téléchargés, emplacements de configuration, accès DNS et domaine, paramètres d’intégration et contacts fournisseurs. CISA conseille d’identifier les données critiques, de protéger les bases de données du site et opérationnelles, de sécuriser les sauvegardes et de tester la récupération totale et partielle. Demandez quand une restauration a été testée, ce qu’elle a restauré, combien de temps elle a pris et qui peut l’autoriser. Répétez des exercices en toute sécurité quand c’est praticable.
Avant une mise en production, identifiez la version antérieure, le déclencheur de bascule (rollback), l’autoriseur et la prise en charge pour DNS, cache, schéma de base de données et changements tiers. Une sauvegarde n’est pas une réparation instantanée, et un rollback peut ne pas inverser les données externes ou les événements de paiement. Tenez un registre des constats, preuves, responsable, date et résultat de retest.
Un enregistrement du périmètre, de la date, du résultat et des lacunes vaut mieux que «les sauvegardes tournent».
Vérifiez le parcours initialement défaillant après un correctif dans l’environnement pertinent.