Chic Dressing SEO Projet OpenClassrooms

Projet Chic Dressing – Optimisation WordPress SEO et accessibilité

Dans ce projet du parcours OpenClassrooms, j’accompagne les étudiants dans l’optimisation complète d’un site WordPress existant pour une marque de vêtements utilisant WordPress et WooCommerce.

L’objectif pédagogique est double :

  1. Améliorer la qualité globale du site,
  2. Développer des compétences clés autour de la performance web, du référencement naturel (SEO), de l’accessibilité numérique et du développement responsable.

Nous partons d’un site fonctionnel mais perfectible : temps de chargement élevés, référencement sous-exploité et accessibilité à renforcer.

Ce projet offre ainsi un terrain concret pour que les étudiants s’exercent aux optimisations SEO on-page et à l’amélioration de l’expérience utilisateur accessible.

Peu de réalisations de ce projet sont visibles en ligne, car des contraintes de sécurité imposent la désactivation de certains modules et l’installation de nouveaux outils (emailing, intégration réseaux sociaux, etc.).

Compétences développées

  • Optimiser les performances d’un site WordPress existant (temps de chargement, structure technique)
  • Mettre en œuvre des bonnes pratiques de référencement naturel (SEO on-page)
  • Améliorer l’accessibilité numérique d’un site web
  • Utiliser des outils d’audit SEO (ex. : Lighthouse, SEOPress)
  • Utiliser des outils d’audit d’accessibilité
  • Réaliser un diagnostic complet avant et après optimisation
  • Mettre en place une démarche structurée d’amélioration continue

Description des étapes du projet

Étape 1 : Importation du site en local
Mise en place d’un environnement de développement local pour travailler en toute sécurité sur une copie du site existant.

Étape 2 : Optimisation des performances
Amélioration de la vitesse de chargement via l’optimisation des images, des scripts, du cache, et de la structure du site.

Étape 3 : Optimisation du SEO et de l’accessibilité
Mise en œuvre des bonnes pratiques de référencement on-page et amélioration de l’accessibilité (balises, navigation, contrastes, ARIA…).

Étape 4 : Diagnostic post-optimisation
Évaluation des résultats obtenus à l’aide d’outils comme Google Lighthouse et comparaison avec l’audit initial.

Contexte du projet

Dans ce projet, l’étudiant intervient en tant qu’intégrateur WordPress freelance, sollicité par une relation de Sarah, fondatrice de Chic Dressing, une boutique spécialisée dans la vente de vêtements et d’accessoires de luxe de seconde main.

Il est chargé d’analyser les performances et de proposer des axes d’amélioration, principalement centrés sur le SEO et l’accessibilité.

Unr rapport de diagnostic doit être remis à Sarah par mail, puis l’étudiant doit procéder aux optimisations nécessaires. Une fois les améliorations mises en place, un bilan post-optimisation détaille les évolutions constatées.

Première étape : l’audit technique

Nous utilisons les Dev tools et Google Lighthouse pour identifier les points faibles du site. Cet audit sert de base pour définir un plan d’action priorisé.

L’étudiant dispose uniquement d’un ancien audit réalisé sur une plateforme en ligne — qui n’existe plus aujourd’hui avec de vieilles métriques.

Rapport Lighthouse

Optimiser sans casser

Les étudiants apprennent à utiliser des plugins comme Autoptimize et WP Super Cache pour améliorer les performances, tout en veillant à ne pas dégrader le design ou la compatibilité mobile.

Il est difficile d’évaluer le travail de l’étudiant lorsqu’il travaille en local, notamment si son environnement n’est pas configuré pour gérer le HTTPS ou les serveurs Nginx/Apache, ce qui peut fausser les tests de formats d’image modernes comme WebP ou AVIF.

Dans ce contexte, les performances mesurées localement ne reflètent pas toujours la réalité en production, et certaines optimisations ne peuvent tout simplement pas être testées correctement.

Il serait utile de proposer des environnements de test plus standardisés ou des alternatives en ligne pour faciliter l’évaluation et garantir la cohérence des résultats Lighthouse.

Travailler la visibilité

Avec SEOPress, les étudiants revoient les balises, les métadonnées et les structures de contenu. Ils découvrent les bases du référencement naturel et les bonnes pratiques d’indexation. Les contenus des billets de blog sont à traduire bien que la plupart des projets réalisés laissent les contenus tels quels en anglais.

À ce stade, les URL des pages doivent être propres et sans doublons : par exemple, privilégier /contact plutôt que /contact-2.

Le plan du site (sitemap) doit également être mis à jour en tenant compte des pages à exclure de l’indexation (noindex).

sitemap chicdressing

Il serait plus pertinent de faire travailler les étudiants sur les données enrichies (schema.org, JSON-LD), qui constituent le cœur de l’optimisation SEO on-page moderne, plutôt que de se concentrer uniquement sur les métadonnées classiques (balises meta title, description, etc.).

Les rich snippets ont aujourd’hui un impact direct sur la visibilité dans les résultats de recherche, et leur mise en œuvre concrète permettrait aux étudiants de mieux comprendre les enjeux réels du référencement sémantique.

Intégrer cette dimension dans le projets renforcerait la dimension stratégique du SEO, tout en offrant une mise en pratique plus concrète et actuelle.

Rendre le site plus inclusif

Nous intégrons les fondamentaux de l’accessibilité : contrastes de couleurs, attributs ARIA, navigation clavier, etc., afin de proposer une expérience accessible à tous les publics.

Cependant, il est important de noter qu’il est souvent difficile pour un étudiant de comprendre et d’interpréter les alertes générées par un audit Lighthouse.
Ces messages techniques manquent parfois de clarté, et une médiation pédagogique est nécessaire pour en tirer des actions concrètes.

Il serait utile de fournir un tableau synthétique avec :

  • les erreurs/accessibilités les plus fréquentes,
  • leur signification concrète,
  • des exemples de correction simples.

Cela permettrait aux apprenants de mieux comprendre les recommandations et de passer plus rapidement à la mise en œuvre des correctifs, tout en renforçant leur autonomie dans l’analyse des performances web.

Recommandations et axes d’optimisation flexibles

Pour ce projet, la modification des modules n’est pas requise. Cependant, je me suis permis de recoder certaines portions du site afin de renforcer la sécurité globale de l’ensemble.

  • Migration sécurisée de MailPoet 2 vers MailPoet 3, avec reformatage du bloc d’abonnement pour garantir compatibilité et stabilité.
  • Déchargement conditionnel de Google reCAPTCHA : ne l’activer qu’en production et uniquement sur les pages nécessaires.
  • Hiérarchie des titres : pour une meilleure sémantique, il est recommandé de conserver les articles de blog en page d’accueil avec des balises <h2>, car ils constituent le contenu principal. Toutefois, ils restent actuellement en <h3>, ce qui reste acceptable si le contexte est maîtrisé.
  • Accessibilité typographique : utiliser des unités relatives (em) pour le corps de texte, afin d’assurer une meilleure adaptabilité aux préférences utilisateur.
  • Évaluation des performances en local :
    • Tester le TTFB (Time To First Byte).
    • Surveiller les indicateurs essentiels comme le LCP (Largest Contentful Paint), le FID (First Input Delay) et le CLS (Cumulative Layout Shift).
    • Prioriser ces métriques pour améliorer la perception de rapidité du site.
  • Mise en cache : affiner la stratégie côté serveur en production pour maximiser la réactivité et la stabilité du site.
  • Remplacement du module de partage social, actuellement désactivé pour raisons de sécurité.
  • Prévoir la migration du Slick Slider vers Swiper.js (ou équivalent accessible), pour des raisons d’accessibilité et de compatibilité future.
  • Google Maps embarqué : privilégier des alternatives comme Leaflet.js ou OpenStreetMap afin d’éviter le chargement externe de polices Google (Roboto notamment).
  • Suppression des polices Google via API : vérifier via l’onglet Réseau des DevTools que toutes les fontes externes ont bien été déchargées.
  • Twitter API : utiliser ses paramètres pour limiter le nombre de Tweets affichés et charger les images associées en WebP pour optimiser le poids.
  • Médias : éviter les plugins d’optimisation « massive » trop agressifs qui risquent d’altérer les images originales. Préférer une optimisation progressive, contrôlée et réversible.
  • Thème parent : correction apportée à une erreur empêchant le fonctionnement du formulaire de recherche.
  • Correctifs JavaScript : certains ajustements supplémentaires auraient pu être apportés via JS, mais ils ont été volontairement écartés à ce stade, pour respecter la progression pédagogique.
  • Accessibilité du logo : un problème de contraste a été identifié à l’emplacement du logo. Sa résolution nécessiterait un traitement JS ou un ajustement design plus avancé.

Avis sur les critères d’évaluation et le cadre du projet

Il serait pertinent que les évaluateurs prennent en compte l’ancienneté des projets et l’évolution des standards web. Certains critères actuellement appliqués ne sont plus totalement adaptés aux réalités du développement actuel, ni au niveau de progression pédagogique des étudiants.

Par exemple, exiger l’absence totale de polices Google peut s’avérer trop complexe à ce stade, notamment lorsqu’une Google Map embarquée est utilisée. Remplacer cette carte par une solution comme Leaflet ou une carte statique suppose des compétences techniques supplémentaires que les étudiants n’ont pas encore acquises.
De plus, les Google Maps intègrent par défaut des polices comme Roboto via des appels externes, ce qui soulève des problèmes de conformité au RGPD difficiles à corriger sans recoder entièrement le composant.

Il serait également souhaitable que les projets soient mieux structurés en amont pour faciliter le travail des mentors.
Actuellement, certains cas demandent une expertise avancée ou des ajustements techniques poussés (sécurité, accessibilité, RGPD), parfois disproportionnés par rapport au niveau attendu dans un projet de milieu de parcours.

Adapter les attentes aux capacités réelles des apprenants et tenir compte des contraintes de suivi côté mentor permettrait un accompagnement plus fluide et plus constructif.

Sur le plan pédagogique, il serait plus motivant de proposer un site de départ plus proprement construit, afin de permettre aux étudiants d’atteindre plus facilement les objectifs fixés, notamment les 100 % Lighthouse.
Cela leur offrirait un cadre réaliste pour visualiser concrètement les effets de leurs actions, renforcerait leur motivation, et éviterait qu’ils soient bloqués par des dettes techniques héritées du projet initial.

Ce projet reste néanmoins abordable et formateur.
Il permet aux étudiants de développer des compétences très recherchées dans le domaine du développement WordPress, notamment en matière de performance, de référencement naturel (SEO) et d’accessibilité.

Le score Lighthouse attendu sur desktop doit atteindre au moins 70, que ce soit en performances, accessibilité, bonnes pratiques ou SEO — un objectif réaliste dans le cadre du projet.

En tant que mentors, nous devons guider les étudiants avec discernement, pour qu’ils ne se perdent pas dans des optimisations prématurées, mais restent concentrés sur les leviers essentiels et concrets d’amélioration.

Catégories : Architecture de l’information & Documentation numérique
Retour en haut