1. Définir l'objectif et le périmètre
Nommez un·e propriétaire unique et rédigez l'objectif avant d'ouvrir un outil d'audit. Indiquez l'audience, le parcours, les pages ou routes, la fenêtre temporelle et la décision que le travail doit soutenir. Un objectif utile décrit une tâche, par exemple compléter un flux mobile du produit vers le panier, et non un souhait vague d'accélérer le site.
Listez les éléments non négociables : flux d'achat ou de demande fonctionnel, accès au compte, comportement de consentement, accessibilité, crawlabilité pour les moteurs et contenu approuvé. Un gain synthétique de score n'est pas une victoire si un formulaire échoue, si du contenu est masqué aux moteurs ou si l'utilisation au clavier devient plus difficile.
Rédigez en une phrase la page de départ, l'action utilisateur et l'état final réussi.
Choisissez un résultat qui ne doit pas se détériorer, par exemple une soumission réussie ou l’absence d’un nouvel obstacle à l’accessibilité.
2. Capturer une ligne de base comparable
Avant de modifier du code, du contenu, une configuration ou des balises, enregistrez la liste d'URL, la date, les conditions de test, la version de déploiement, les rapports ou traces, et le résultat des tests manuels. web.dev recommande d'enregistrer l'état du site avant les changements et de tester plusieurs types de pages ; pour les applications monopage, incluez les routes, composants et flux plutôt que seulement le premier chargement.
Utilisez plus d'un angle d'analyse. Lighthouse fournit des audits automatisés de performance, d'accessibilité, de référencement et autres. Testez le premier chargement avec le stockage vidé ou un profil propre, puis complétez la tâche cible. Lorsque des données réelles d'utilisateurs existent, comparez les groupes de pages et classes d'appareils importants. Les Core Web Vitals sont des mesures de terrain : LCP couvre le chargement, INP l'interactivité et CLS la stabilité visuelle.
Les données terrain (field) reflètent les visites réelles ; les tests en laboratoire (lab) facilitent la reproduction d'un problème. Utilisez les deux quand ils sont disponibles.
Un chargement simulé ne peut pas mesurer l’INP, car il ne comporte aucune interaction utilisateur ; le Total Blocking Time en laboratoire n’est qu’un indicateur indirect.
3. Auditer le parcours de bout en bout
Groupez les constats par parcours et par mécanisme. Passez en revue la taille, le timing et les dépendances des requêtes pour les ressources de page et les tiers. Vérifiez la fenêtre d'affichage mobile, le parcours clavier, le focus visible, les libellés, les erreurs, les titres, l'intention des liens, le zoom, et ce qui se passe si une image, un script ou un service dépendant du consentement est lent ou indisponible.
Considérez les résultats automatisés d’accessibilité comme un outil de triage. Le W3C indique qu’aucun outil ne peut, à lui seul, déterminer si un site respecte les normes d’accessibilité ; une évaluation humaine compétente est nécessaire. Pour le référencement, assurez-vous que les ressources importantes générées côté client restent accessibles aux robots d’indexation comme aux utilisateurs. Incluez les redirections, les balises canoniques, les liens internes, les directives robots, les plans de site et les données structurées lorsque la modification les concerne.
Listez les tag managers, analytics, chat, paiement, polices, CDN, APIs et outils de consentement dont la tâche dépend.
Pour le paiement, l'authentification, les données utilisateur, les en-têtes ou les contrôles de sécurité, obtenez une revue sécurité et paiement qualifiée.
4. Constituer un backlog classé
Rédigez une petite hypothèse pour chaque élément : sur cette page ou ce flux, changez ce mécanisme parce que des preuves suggèrent qu'il cause ce problème ; mesurez le résultat attendu et protégez les garde-fous nommés. Gardez l'observation distincte du diagnostic. Une trace sauvegardée peut montrer une grosse image retardant le contenu, mais le remède nécessite encore revue du design et du contenu.
Classez les éléments par Impact, Confiance, Effort et Risque. L'impact correspond au parcours prioritaire affecté. La confiance mesure si les preuves lab, terrain et manuelles concordent. L'effort inclut la coordination, pas seulement le code. Le risque couvre dépendances, sécurité, complexité de release et réversibilité. Une exposition fonctionnelle ou de sécurité critique peut primer sur ce modèle et nécessite un triage spécialisé.
Conservez propriétaire, lien vers preuves, hypothèse, pages, mesure, garde-fous, dépendances, méthode de release et déclencheur de rollback.
Ne regroupez pas des refontes sans rapport dans un changement mesuré sauf si la sécurité l'exige.
5. Publier en sécurité et conserver un retour arrière
Avant le déploiement, enregistrez ce qui change, l'approbateur, la fenêtre de release, le vérificateur, la condition de succès, le déclencheur de rollback et la méthode de restauration. Testez dans un environnement non production représentatif quand c'est possible, y compris contenu, permissions, intégrations, redirections, choix de consentement et chemins d'échec courants. La production peut encore différer à cause des données, du cache, de la configuration et des tiers.
Utilisez un déploiement progressif, un feature flag, un asset versionné ou une configuration réversible lorsque la plateforme le permet. Confirmez le comportement du cache et du CDN avant de comparer les résultats. OWASP considère la gestion de configuration et de déploiement comme un domaine de test de sécurité ; en-têtes, permissions, exposition de fichiers et paramètres de domaine ou cloud ne doivent pas être modifiés à la légère pour une optimisation.
Définissez un déclencheur observable, comme un paiement échoué, une navigation cassée, une erreur client inattendue ou une régression d'accessibilité.
Un plan de rollback peut réduire le temps de récupération mais ne supprime pas tous les risques ; testez la restauration avant d'en dépendre.
6. Vérifier, décider et répéter
Après la mise en production, répétez les vérifications fonctionnelles de la ligne de base et des tests de laboratoire comparables. Revérifiez les appareils, navigateurs, états et intégrations pertinents. Comparez des éléments analogues : URL, état du cache, classe d'appareil, région quand c'est faisable, et fenêtre de mesure. Confirmez les garde-fous ainsi que la métrique cible.
Laissez le temps aux données de mûrir. Google note que les changements de référencement peuvent prendre de quelques heures à plusieurs mois pour apparaître et suggère d’attendre quelques semaines pour évaluer leur effet. Les données réelles d’utilisateurs constituent une preuve agrégée, pas un verdict immédiat sur une mise en production. Consignez la décision : conserver, modifier, approfondir ou annuler, puis établissez un nouvel état de référence après toute évolution importante des modèles, de la plateforme, des balises, du contenu ou des dépendances.
Le résultat attendu du parcours s'améliore et les garde-fous convenus restent intacts.
Intervenez lorsque les preuves terrain ou la tâche manuelle contredisent le résultat de laboratoire, ou qu'un garde-fou critique régresse.