Quand OpenClassrooms m’a contacté pour structurer un mentorat WordPress, j’aurais pu faire comme tout le monde : te balance 30 plugins à connaître, te montre comment installer Gutenberg, et hop, « Formation terminée ! ».
Sauf que j’ai choisi de faire autrement. Bien autrement.
Au lieu de plaquer une formation générique, j’ai construit un vrai accompagnement réflexif. On a pris du temps pour se demander « pourquoi » avant de faire « comment« . On a simplifié avant d’ajouter. On a mesuré avant de crier victoire.
Et franchement ? Après 3 séances espacées (20 mars, 13 avril, 17 avril 2026), le site associatif de l’étudiant a vraiment changé. Pas parce qu’on a ajouté plein de trucs. Parce qu’on a réfléchi ensemble, étape par étape.
Pourquoi les formations « classiques » échouent (et comment j’ai décidé de faire différemment)
Imagine une formation WordPress typique. Premier jour : « Voici 15 blocs Gutenberg, 20 plugins essentiels, 3 extensions de sécurité. » Deuxième jour : « Activez le cache, compressez vos images, installez Rank Math pour le SEO. » Et pis voilà, t’es lâché avec plein de notes et aucune idée de comment tout s’articule vraiment.
Trois mois plus tard ? Le site ressemble à un Frankenstein. Huit plugins inutiles qui ralentissent tout. Des images non optimisées. Une structure confuse où le fondateur de l’association n’ose même plus y toucher.
J’ai décidé de faire l’inverse. Au lieu de démarrer par « Voici les outils », commencer par : « C’est quoi ton vrai problème ? Et comment on le résout sans te pourrir ce qui marche déjà ? »
Première séance (20 mars 2026) – Maîtriser son environnement local et cloner son site existant
Durée prescrite : 1h | Durée réelle : 63 minutes | Niveau : 3/5
Le vrai point de départ : « Tu as un site en production, on ne le touche pas »
J’ai commencé la séance par une affirmation qui a tranquillisé l’étudiant :
« On ne va rien casser. On va copier ton site existant en local et on travaille là-dessus. Le site en ligne, il reste intact. »
C’est bête, mais c’est psychologiquement énorme. Quand tu travailles sur ton site de production, tu as peur. Quand tu as une copie locale, tu peux tester, casser, réparer, apprendre.
Étape 1 : Installer LocalWP pour une copie locale du site
LocalWP, ça paraît compliqué dit comme ça. En réalité, c’est super simple.
C’est un logiciel qu’on installe sur ton ordinateur (Windows, Mac, Linux). Une fois que c’est installé, tu crées un nouveau site local en trois clics. Y’a tout dedans : WordPress, la base de données, le serveur web, tout. Aucune installation complexe à faire.
Pourquoi c’est important ? Parce qu’avec LocalWP, tu peux tester sans montrer tes trucs au monde entier. Tu peux casser une page, et pendant ce temps, le site réel de l’association fonctionne normalement.
L’étudiant a installé LocalWP en deux minutes. Vraiment simple.
Étape 2 : Cloner le site existant de la production en local
Là, c’est un moment clé. On va copier le site réel de l’association, celui qui est en ligne, sur l’ordinateur de l’étudiant.
Pourquoi faire ça ? Parce que tu dois apprendre en travaillant sur quelque chose de réel. Un site « template » ou un site d’école, c’est jamais pareil que ton vrai site. Il y a des pages bizarres, des plugins qui traînent, une structure un peu chaotique. C’est ça la réalité.
On utilise pour ça AllInOneMigration ou WP Vivid. Des plugins gratuits qui font une copie complète du site : toutes les pages, tous les articles, tous les réglages, tous les plugins, la base de données.
L’étudiant a lancé le plugin, créé une sauvegarde, téléchargé le fichier.
Ensuite, dans LocalWP, on importe cette sauvegarde. Et poof, une copie identique de son site apparaît sur l’ordinateur.
Test : vérifier que tout fonctionne comme en ligne. Les pages s’affichent ? Les plugins aussi ? Bon.
Étape 3 : Comprendre la base de données et comment elle vit
C’est là qu’on s’arrête pour penser, pas juste faire.
La base de données de WordPress, c’est le cœur. C’est là que vivent tous les articles, toutes les pages, tous les paramètres. Quand tu changes un titre d’article, tu changes la base de données. Quand tu ajoutes un utilisateur, c’est la base de données qui le mémorise.
LocalWP, c’est important aussi pour ça : tu as une copie de ta base de données en local. Tu peux la bidouiller sans risque. La vraie base de données, celle en ligne, elle ne sait rien.
J’ai montré à l’étudiant comment accéder à phpMyAdmin, l’outil qui te permet de voir ta base de données. Qu’est-ce qu’il y a dedans ? Des tables. Une table pour les articles, une pour les pages, une pour les utilisateurs, etc.
L’étudiant a regardé sa vraie base de données en ligne. Il a compris sa structure. Ça lui a donné confiance. Il savait maintenant que si quelque chose allait mal, c’était des données, qu’on pouvait restaurer, pas de la magie.
Étape 4 : La vision « architecture » – penser avant d’agir
Une fois qu’on avait une copie locale du site et qu’on comprenait la base de données, on a réfléchi.
Avant de modifier une ligne, j’ai demandé à l’étudiant :
« Quel est l’état réel de ton site associatif ? Qu’est-ce qui marche ? Qu’est-ce qui ne marche pas ? »
Il a analysé. Des pages qui ne sont jamais mises à jour. Des plugins installés mais jamais utilisés. Une structure confuse. Trop de bruit pour rien.
Ensuite : « Qu’est-ce que tu veux vraiment faire évoluer ? Où tes visiteurs viennent vraiment chercher quoi ? Qu’est-ce qui crée de la valeur pour l’association ? »
L’idée : savoir avant de bouger. Rien que ça change tout.
On a décidé ensemble qu’on allait :
- Nettoyer les pages inutiles
- Vérifier les plugins et voir lesquels servaient vraiment
- Identifier une structure claire pour le futur
Mais ça, ce serait pour les prochaines séances. Pour cette première, on avait juste : une copie locale qui marche, une compréhension de la base de données, et une vision claire du point de départ.
La fin de la séance 1
L’étudiant repartait avec :
- Un site local en miroir exact de son site en prod
- La confiance de pouvoir tester n’importe quoi en local sans toucher au vrai site
- Une compréhension de comment vit ses données
- Un plan pour les deux prochaines séances
Deuxième séance (13 avril 2026) – Sauvegardes et sécurité, les vrais fondations
Durée prescrite : 1h | Durée réelle : ~67 minutes | Niveau : 3/5
Pourquoi commencer par la sécurité et les sauvegardes ?
J’ai commencé direct avec une histoire vraie :
« Il y a deux semaines, j’ai reçu un appel d’une association. Son site avait été hacké. Un bénévole avait utilisé un mot de passe pourri. Résultat ? Trois jours de pagaille, perte de contenu, perte de confiance. Ils n’avaient pas de sauvegarde. »
L’étudiant a serré les fesses. « Ça se peut vraiment ? »
« Tous les jours. Et tu sais quoi ? C’était évitable. »
Voilà pourquoi avant d’optimiser, avant de faire du SEO, avant d’ajouter des fonctionnalités, tu dois avoir deux trucs solides :
- Des sauvegardes automatiques, au cas où tout se casse
- Des protections contre les attaques, parce que WordPress c’est une cible
Une association sans sauvegarde ni sécurité, c’est comme conduire une voiture sans assurance et sans ceinture de sécurité.
Étape 1 : Mettre en place les sauvegardes automatiques
J’ai présenté trois outils gratuits.
UpdraftPlus. C’est un plugin qui fait une sauvegarde complète de ton site (tous les fichiers, toute la base de données) et l’envoie automatiquement sur le cloud. Google Drive, Dropbox, AWS, où tu veux. Une fois par semaine, c’est bon pour une association.
Comment ça marche ? Tu installes le plugin, tu le configures pour qu’il envoie les sauvegardes sur ton Google Drive, et c’est fini. Chaque semaine, une nouvelle sauvegarde. Si ton site explose, tu restaures en cinq minutes.
AllInOneMigration. On l’a déjà utilisé pour cloner en local. Mais ça marche aussi pour créer des sauvegardes à la demande. Utile si tu veux garder une version « avant » avant de faire une grosse modification.
WP Vivid. Plus léger. Moins de fonctionnalités. Mais pour une association avec peu de contenu, c’est suffisant.
L’étudiant a installé UpdraftPlus. Configuration : sauvegarde une fois par semaine, destination Google Drive. Hop, c’est fait.
Avant de continuer, il a testé. Créé une sauvegarde à la main, vérifiée que le fichier était bien sur Google Drive. Ça paraît bête, mais c’est important. Je veux qu’il soit certain que ça marche.
Étape 2 : Les risques de sécurité du WordPress classique
J’ai expliqué les attaques courantes sans paniquer.
Le brute force sur la page admin. Des bots testent des milliers de mots de passe pour rentrer dans le back-office. Si ton mot de passe c’est « 123456 » ou « association », ils rentrent en 10 secondes. Si tu laisses la page admin par défaut (wp-admin), les bots savent exactement où chercher.
Les plugins et thèmes non mis à jour. WordPress évolue, les plugins aussi. Quand une faille de sécurité est découverte, elle est patchée en quelques jours. Mais si tu ne mets pas à jour, tu restes vulnérable pendant des années. Les bots savent quelles failles existent, et ils testent tous tes plugins.
La base de données mal configurée. Par défaut, WordPress utilise des noms de tables qui commencent par « wp_ ». Les bots le savent. Si tu les laisses comme ça, c’est plus facile à pirater.
Un mot de passe admin pourri. Je ne vais pas lister tous les pires mots de passe, mais tu vois l’idée. Si c’est quelque chose qu’on peut deviner, c’est un problème.
L’étudiant écoutait et réalisait l’importance du truc.
Étape 3 : Mettre en place les protections essentielles
Pas besoin de 10 plugins. Trois, et tu couvres 95% des attaques.
Limiter les tentatives de connexion échouées.
Plugin : Limit Login Attempts Reloaded. C’est gratuit.
Qu’est-ce que ça fait ? Si quelqu’un essaie 5 fois de rentrer avec un mauvais mot de passe, il est bloqué pendant 15 minutes. Après 20 fois, il est bloqué pour 24 heures. Les bots qui testent des milliers de mots de passe ? Bloqués.
Configuration rapide. L’étudiant a installé, réglé les paramètres par défaut (c’était déjà bon), terminé.
Cacher la page admin.
Plugin : WPS Hide Login. Gratuit aussi.
Par défaut, tout le monde sait que la page d’admin de WordPress c’est /wp-admin. Avec ce plugin, tu la renommes. Admettons, tu le dis que c’est /secret-admin. Maintenant les bots qui cherchent /wp-admin ne trouvent rien. Zéro tentative.
C’est bête, mais c’est diablement efficace.
L’étudiant a installé, choisi une URL cachée, c’était fait.
Vérifier HTTPS.
HTTPS, c’est le petit cadenas à côté de l’URL. Ça chiffre tout ce qu’il se passe entre l’ordinateur du visiteur et le serveur. Aucun secret n’est envoyé en clair.
Pour une association, c’est standard. L’hébergeur (o2switch, Hostinger, peu importe) le propose gratuitement maintenant. L’étudiant a vérifié que le sien était activé. Oui. Bon.
Étape 4 : Vérifier la santé générale du site
WordPress te donne un tableau de bord appelé « Outils > Santé du site ». C’est une checklist de tous les trucs qui pourraient poser problème.
L’étudiant a lancé ça. Résultats :
- PHP à jour ? Oui.
- Permissions des fichiers bonnes ? Oui.
- Plugins actifs mais pas à jour ? Deux. On les a mis à jour.
- Thème actif ? Bon.
Rien de grave. Mais c’est bon de vérifier régulièrement.
Étape 5 : Tester la restauration d’une sauvegarde
C’est l’étape que la plupart des gens sautent. Grosse erreur.
Une sauvegarde, c’est utile seulement si tu peux la restaurer. Je voulais que l’étudiant soit certain.
On a créé une sauvegarde manuellement. Puis, on a simulé un problème : on a supprimé une page du site local. Et on a restauré à partir de la sauvegarde.
La page supprimée ? Revenue. Tout intacte.
Psychologiquement, c’est énorme. Maintenant il savait : si quelque chose va mal, je peux revenir en arrière.
La fin de la séance 2
L’étudiant repartait avec :
- Un système de sauvegarde qui marche, automatique
- Une page admin cachée et protégée contre le brute force
- La conscience que la sécurité, c’est pas optionnel
- La certitude qu’il peut restaurer si besoin
On avait jeté les vraies fondations. Pas sexy, pas visible pour les visiteurs. Mais indispensable.
Troisième séance (17 avril 2026) – Performances et SEO, rendre le site vivant
Durée prescrite : 1h | Durée réelle : 67 minutes | Niveau : 3/5
Passer de « ça marche » à « ça marche bien »
À ce stade, l’étudiant avait :
- Un site local en miroir
- Des sauvegardes automatiques
- Une sécurité basique mais solide
Maintenant : comment faire en sorte que les visiteurs trouvent le site, et qu’il soit rapide quand ils y arrivent ?
Étape 1 : Mesurer les performances actuelles
Avant d’optimiser, on mesure. Je suis pas un fan de supposer.
J’ai lancé Google PageSpeed Insights sur le site de production de l’association. Score : 58 sur 100 en mobile, 78 en desktop. Pas catastrophe, mais y’avait clairement du boulot.
La question : pourquoi cette différence entre mobile et desktop ?
On a creusé. Les images étaient trop lourdes (images de 3-4 MB, jamais compressées). Le cache n’était pas activé du tout. Et quelques plugins inutiles tournaient en arrière-plan.
C’était mesurable. C’était clair. Maintenant on pouvait avancer.
Étape 2 : Optimiser les images, le plus haut impact
Les images, c’est souvent 80% du problème de performance. Et c’est simple à fixer.
L’étudiant avait des images partout sur son site. Photos de l’association, screenshots, tout ça en JPG normal, jamais compressé.
J’ai montré comment faire :
Convertir en WebP. C’est un format d’image plus moderne que JPG. Il prend 30% moins de place sans perte de qualité. Presque tous les navigateurs le supportent maintenant.
Tool : TinyImage, Squoosh, ou un plugin WordPress.
Réduire la taille avant upload. Une photo prise avec un téléphone, c’est souvent 3-4 MB. T’as pas besoin de ça pour une image web. 500 KB c’est suffisant.
Plugin utile : WP Optimize. Il compresse les images automatiquement quand tu les upload, et gère un petit cache aussi.
L’étudiant a installé WP Optimize, configuré pour compresser en WebP par défaut, et lancé une première compression sur toutes les images existantes.
Résultat immédiat : Google PageSpeed passe de 58 à 72 en mobile.
Temps de chargement du site : 4,2 secondes avant, 2,8 secondes après.
C’est mesurable. C’est visible. L’étudiant voyait l’impact.
Étape 3 : Activer le cache, mais intelligemment
Le cache, c’est une copie « figée » du site que tu montres à chaque nouveau visiteur, au lieu de recalculer la page à chaque fois.
Pour une association peu visitée (100 visites/jour), un cache léger suffit. Pas besoin de système d’usine à gaz.
WP Optimize a aussi un cache léger intégré. L’étudiant l’a activé. Configuration par défaut, c’était déjà bon.
Résultat : PageSpeed passe de 72 à 78 en mobile. Encore +6 points.
Étape 4 : Le SEO local, parce qu’une association doit se trouver
J’ai posé la question clé :
« Qui cherche vraiment ton association sur Google ? »
Réponse : des gens qui tapent « Association X + Lyon » ou « bénévolat environnement + Lyon ».
Donc pas besoin de ranker pour des mots génériques comme « association ». Faut ranker pour des termes locaux.
J’ai installé Rank Math, le plugin SEO gratuit, et on a regardé ensemble.
L’analyse montrait : contenu bien structuré, mais métadonnées incomplètes. Pas de description pour les pages clés.
On a fait simple : réécrire les descriptions des 5-6 pages principales en pensant SEO local. « Association X, basée à Lyon, aide les bénévoles à… »
Et ajouter la structure « Local Business » dans le code, pour que Google sache qu’on est une association locale.
Étape 5 : Le SEO technique, c’est aussi des basiques
On a checké les basiques :
- Les pages ne sont pas indexées par Google pour une raison quelconque ? Non, tout est bon.
- Les images ont des « alt text » ? Quelques-unes manquent. On les a ajoutées.
- Les URLs sont propres ? Oui.
- Le sitemap XML existe et est soumis à Google ? On l’a vérifié.
Rien de compliqué. Juste des choses qu’on doit vérifier.
Étape 6 : Mesurer avant et après
À la fin de la séance, on a refait les mesures.
Avant (début de la séance 3) :
- PageSpeed mobile : 58
- Temps de chargement : 4,2 secondes
- Pas de SEO local configuré
Après (fin de la séance 3) :
- PageSpeed mobile : 78
- Temps de chargement : 2,8 secondes
- SEO local en place
C’est mesurable. C’est tangible. L’étudiant pouvait voir le progrès.
Attendu : hausse du trafic organique local de 30-50% dans les 3 mois.
Étape 7 : La vision long terme
Au lieu de finir par « Et voilà c’est fini », j’ai ouvert des portes.
Porte 1 : Optimiser le contenu. Les pages principales sont maintenant rapides et bien optimisées pour le SEO local. Mais y’a toujours des petites améliorations possibles. Une checklist mensuelle.
Porte 2 : Monitorer les perfs. Avec Google Search Console, voir comment le site performe réellement. Quels mots-clés attirent du trafic ? Quelles pages manquent de visibilité ?
Porte 3 : Garder à jour. Les plugins se mettent à jour. WordPress se met à jour. Les images restent optimisées. Aucun plugin inutile ne s’accumule.
La fin de la séance 3
L’étudiant repartait avec :
- Un site notablement plus rapide
- Un SEO local en place
- Une compréhension de comment les performances et le SEO se mesurent
- Une roadmap pour continuer
Avant et après, concrètement
Quand on a commencé, le site associatif était :
- Lent (4,2 secondes de chargement)
- Peu optimisé pour les moteurs de recherche
- Fragile (pas de sauvegardes, peu sécurisé)
- Peu visible localement
Après les trois séances :
- Rapide (2,8 secondes de chargement) ✓
- SEO local en place ✓
- Sauvegardes automatiques + sécurité basique ✓
- Optimisé pour être trouvé par les visiteurs locaux ✓
Trafic organique attendu : hausse de 30% en trois mois.
Et honnêtement ? Le plus important, c’est que l’étudiant a pas juste « appris WordPress ». Il a compris l’ordre logique : d’abord sécuriser et sauvegarder, ensuite optimiser et faire connaître. C’est pas sexy, mais c’est intelligent.
Pourquoi cet ordre des séances ? C’est pas un hasard.
Si j’avais commencé par le SEO et les perfs sans avoir de sauvegardes, c’aurait été dangereux. Tu optimises, tu casses quelque chose, et tu peux pas revenir en arrière.
Si j’avais pas dit « d’abord on clone en local », il aurait eu peur de tout modifier.
En trois séances bien pensées, on a :
- Sécurisé l’environnement (local + compréhension)
- Protégé les données (sauvegardes + sécurité)
- Optimisé la performance et la visibilité (perfs + SEO)
C’est un ordre logique. Et ça marche.
Pourquoi c’est important pour vous
Si vous avez un site WordPress qui :
- Vous fait peur à toucher (pas de sauvegardes, pas de local)
- Est lent
- Se trouve pas sur Google
- Manque de protections de base
Cette approche peut vraiment transformer votre situation.
C’est pas « juste une formation WordPress ». C’est un accompagnement où on réfléchit à l’ordre des choses, où on mesure, où on crée quelque chose de durable.
Ce que le choix d’OpenClassrooms change
Quand une plateforme de 2 millions d’utilisateurs mensuels te demande de structurer un mentorat, c’est qu’il y a quelque chose. C’est pas du vide, c’est une vraie validation de compétence.
Ça prouve que je sais comprendre en profondeur ce qu’il faut faire et dans quel ordre. Ça prouve que je sais comment faire progresser quelqu’un sans le submerger. Et ça prouve surtout qu’on peut vraiment transformer un site de façon mesurable et intelligente.
C’est cette même rigueur que j’apporte à chaque projet : diagnostic clair, ordre logique, vision long terme.
Publié en avril 2026 | Spécialités : WordPress, accompagnement, SEO, pragmatisme, sites associatifs
