DEV Community: Lyode freelance

Maintenance WordPress : les 7 incidents qui auraient pu être évités

Lyode freelance — Wed, 27 May 2026 21:06:44 +0000

Retour d'expérience de freelance WordPress sur les incidents les plus fréquents en clientèle et pourquoi la maintenance n'est jamais un luxe.

Quand un client appelle en panique parce que son site est en carafe, c'est rarement par hasard. Dans 9 cas sur 10, l'incident aurait pu être détecté plusieurs semaines avant, lors d'une intervention de maintenance bien menée.

Je m'appelle Sébastien, je suis développeur WordPress freelance à Lyon, et je gère plusieurs contrats de maintenance en parallèle de projets de création de sites. Voici une liste honnête des incidents que j'ai eus à traiter ces derniers mois, et ce qu'une maintenance régulière aurait changé.

1. La mise à jour de plugin qui casse l'affichage

Classique. Une extension Elementor passe en version majeure, et tout un layout responsive se retrouve cassé sur mobile. Le client ne s'en rend compte que trois jours plus tard, quand un prospect lui signale.

Ce qu'une maintenance bien faite change : les mises à jour passent d'abord par un environnement de staging ou, à défaut, par un site cloné. Avant chaque update, une sauvegarde complète (fichiers + base + config serveur). Si quelque chose casse, on rollback en 5 minutes plutôt qu'en 4 heures de debug.

2. Le plugin abandonné par son auteur

Un plugin populaire en 2022 n'a plus reçu de mise à jour depuis 18 mois. Compatible jusqu'à WordPress 6.3, on est en 6.7. Au prochain update du core, il casse silencieusement une fonctionnalité critique.

La maintenance permet d'auditer régulièrement les extensions actives : dernière mise à jour, compatibilité annoncée, vulnérabilités CVE connues. Quand un plugin commence à dériver, on cherche un remplaçant maintenu avant qu'il devienne un problème.

3. L'attaque brute force sur wp-login.php

Sans monitoring, vous ne le voyez pas. Avec monitoring, vous voyez 4 000 tentatives de connexion en 48h sur un compte admin avec un identifiant deviné depuis l'URL /author/admin/.

Quelques basiques qui changent tout :

Désactiver l'énumération des auteurs (?author=1)
Renommer ou cacher wp-admin derrière un slug custom
Limiter les tentatives de connexion avec un plugin léger
Mettre en place l'authentification à deux facteurs sur les comptes administrateurs

Aucune de ces actions n'est compliquée. Mais aucune ne se fait toute seule.

4. Le certificat SSL qui expire un dimanche soir

Renouvellement automatique mal configuré chez l'hébergeur, certificat Let's Encrypt qui expire un dimanche, site qui passe en "Connexion non sécurisée" sur Chrome pour tous les visiteurs du lundi matin.

Un monitoring qui surveille la date d'expiration du certificat et alerte 15 jours avant règle le problème. C'est dix lignes de configuration, et ça évite une journée d'incident à fort impact business.

5. Le serveur saturé par les images

Quatre ans d'exploitation, jamais de nettoyage. La médiathèque pèse 28 Go. Les images originales en 4000x3000 px sont servies telles quelles. Le score PageSpeed Mobile est passé de 78 à 31 sans que personne ne le remarque.

La performance ne se dégrade pas d'un coup. C'est une dérive lente, invisible au quotidien, qui finit par impacter le SEO et le taux de conversion. Une maintenance régulière inclut un contrôle des optimisations existantes : cache (WP Rocket, W3 Total Cache), compression d'images (Imagify, ShortPixel), minification HTML/CSS/JS, lazy loading.

6. La base de données qui gonfle silencieusement

Révisions de posts non purgées, transients expirés mais jamais nettoyés, tables d'anciens plugins toujours présentes après désinstallation. La base passe de 80 Mo à 1,2 Go en deux ans. Les requêtes ralentissent. Le TTFB grimpe.

Un nettoyage trimestriel — optimisation des tables, purge des révisions au-delà de N versions, suppression des transients expirés — garde la base saine.

7. Le rapport qu'on ne fait jamais

Le plus invisible des problèmes, mais celui qui empoisonne la relation client. Si vous facturez de la maintenance et que vous ne livrez aucune trace écrite de ce qui a été fait, le client doute. Il ne sait pas s'il en a pour son argent. Et il a raison de douter.

Chaque intervention devrait produire un rapport synthétique : mises à jour appliquées (avec versions avant/après), corrections réalisées, anomalies détectées, actions recommandées pour la suite. C'est ce qui transforme la maintenance d'une dépense floue en un service traçable.

Ce que j'ai mis en place

Pour mes propres clients, j'ai structuré la maintenance autour de quatre piliers : sécurité et mises à jour maîtrisées, sauvegardes avec plan de reprise, optimisations continues, et reporting détaillé. Je m'appuie sur un outil de monitoring dédié pour suivre la disponibilité, le temps de réponse, le certificat SSL et les alertes techniques entre deux interventions.

Sur le format, deux options selon le profil du site :

Intervention ponctuelle (150 €, environ une demi-journée) : pour les sites vitrines ou les projets qui n'ont pas besoin d'un suivi mensuel mais qui doivent rester sains.
Contrat mensuel ou trimestriel : pour les sites institutionnels ou e-commerce avec plus d'enjeux, plus de plugins, plus d'exposition.

Si vous êtes basé dans la région lyonnaise et que votre site WordPress tourne sans suivi depuis un moment, le détail de ma prestation est sur lyode.fr — Maintenance WordPress.

En résumé

La maintenance WordPress n'est pas un produit de luxe ni une rente d'agence. C'est juste ce qui fait la différence entre un site qui fonctionne dans cinq ans et un site qui tombe en panne au pire moment. Les sept incidents listés ici ont tous un point commun : ils sont prévisibles, et donc évitables.

Si vous gérez votre site vous-même, vous avez largement de quoi faire avec cette liste. Si vous préférez le confier à quelqu'un dont c'est le métier, c'est aussi une option raisonnable.

WordPress 7.0 Delayed - What It Means for Your Maintenance Strategy

Lyode freelance — Wed, 01 Apr 2026 22:48:01 +0000

WordPress 7.0 was supposed to ship on April 9, 2026. That's no longer happening.
On March 31, Matias Ventura announced on Make WordPress Core that the release is being pushed back by several weeks. No new date has been set yet.
This isn't the first delay in the 7.0 cycle - Beta 1 was already postponed in February due to unit test failures, and RC1 was delayed in March over performance concerns. But this time, the delay is architectural, not just a schedule slip.

What's causing the delay

The core issue is Real-Time Collaboration (RTC) - a feature that introduces live co-editing in the WordPress block editor, similar to what Google Docs offers.
Building this requires a new database table, changes to how WordPress handles editing sessions, and a rethinking of how post caches work during active collaboration. The team realized that the database schema needed more design work before being locked into a major release.
Key concerns raised by contributors:

**Performance: **real-time editing currently disables persistent post caches during active sessions
Database design: the proposed single RTC table tries to serve both real-time editing (high-frequency, low-latency writes) and synchronization (batch operations) - two fundamentally different workloads
Testing gaps: database schema changes increase the risk of failures during upgrades, and the usual testing path via the Gutenberg plugin was rejected because it could affect production sites

The RTC feature will ship as opt-in, giving hosts and site owners time to evaluate the impact before enabling it.

Why this matters for site maintenance

If you manage WordPress sites - whether it's your own or your clients' - this delay has practical implications.

1. Don't rush the update when it drops
When 7.0 finally ships, it will include database migrations. That's a different beast than a typical minor update. Your maintenance checklist should include:

Full database backup before updating (not just files)
Staging environment test - run the update on a staging copy first
Plugin compatibility check - especially for page builders, caching plugins, and any plugin that hooks into the editor
Monitor post-update - watch for slow queries or unexpected behavior in the editor

2. Use this window to get your house in order
The delay gives you extra time to prepare. Here's what to tackle now:

Update to WordPress 6.9.3 if you haven't already - it includes 10 security patches
Audit your plugins - remove anything inactive or unmaintained. Fewer plugins = smoother major upgrades
Check your PHP version - WordPress 7.0 is expected to require PHP 7.4+ at minimum, and PHP 8.1+ is recommended
Review your backup strategy - make sure automated backups include both files AND database, with at least 7 days of retention

3. Plan for the RTC feature decision
Even though RTC will be opt-in, you'll need to decide whether to enable it for each site you manage. Consider:

Do your clients actually need real-time co-editing?
Can your hosting handle the additional database writes?
Are your caching layers compatible with the new collaboration mode?

For most small business sites, the answer is probably "not yet." But for content teams with multiple editors, it could be transformative.

The bigger picture

WordPress powers a massive share of the web. A major version release with database schema changes affects millions of sites simultaneously. The fact that the core team is taking extra time to get the architecture right - rather than shipping on schedule and patching later - is a good sign.
But it also reinforces something I see constantly in my work as a WordPress freelancer in Lyon: maintenance isn't optional, it's infrastructure. Every major WordPress release is a moment where the gap between "sites that are actively maintained" and "sites that are left on autopilot" becomes painfully visible.
Sites with a proper maintenance workflow - regular backups, staging environments, plugin audits, monitoring - will handle the 7.0 transition smoothly. Sites without one will scramble.

What to do right now

Don't install WordPress 7.0 RC builds on production sites - they're for testing only
Set up a staging environment if you don't have one (most hosts offer one-click staging)
Run a full backup and verify you can restore from it
Subscribe to Make WordPress Core for the updated release timeline
Audit your plugin list - anything that hasn't been updated in 12+ months is a risk factor for 7.0 compatibility

The new release date hasn't been announced yet, but it's expected to be "a few weeks" after the original April 9 target. I'll update this post when the timeline is confirmed.

I'm Sébastien, a WordPress developer and SEO specialist based in Lyon, France. I help businesses build, optimize, and maintain their WordPress sites. If you're looking for help preparing for WordPress 7.0 or need ongoing maintenance support, you can find out more about my services here.

Web Project Acceptance Testing: A Practical Guide (with Checklist)

Lyode freelance — Tue, 10 Mar 2026 12:22:46 +0000

Ever launched a website only to discover a broken form, a missing redirect, or a page that looks terrible on mobile — after going live? That's what proper acceptance testing is designed to prevent.

What is Web Acceptance Testing?
Web acceptance testing (called recettage in French project management) is the structured process of validating a website or web application before it goes live. It ensures the final deliverable matches the initial specifications — functionally, technically, and from a user experience standpoint.
It's not just "clicking around to see if things work." It's a documented, step-by-step validation that covers every layer of your project.

The 3 Phases You Shouldn't Skip

Intermediate testing (during development) Run at the end of each sprint or functional phase. Validates features progressively and avoids the "big bang" effect at delivery.
User Acceptance Testing (UAT) Performed by the client or end users. The goal: confirm the product actually meets real business needs — not just technical specs.
Final pre-production testing The last checkpoint before go-live. Everything gets tested one final time: responsiveness, SEO, RGPD compliance, redirects, performance. This phase ends with a sign-off document authorizing production deployment.

Step-by-Step Method
Step 1 — Write your acceptance test plan
Document every feature to test, the expected result, and the validation criteria. Derive it directly from your specifications or backlog.
Step 2 — Build your test scenarios
Each scenario simulates a real user action:

Submit a contact form → verify email received
Add product to cart → complete checkout
Navigate on mobile → check layout and readability

Always include edge cases: empty fields, unauthorized actions, unusual screen sizes.
Step 3 — Run the tests
Each test gets one of three statuses:

✅ Passed
⚠️ Minor issue
❌ Blocking bug

Use a simple tool (Notion, Trello, or even a spreadsheet) to track results.
Step 4 — Track and fix anomalies
Every bug must be documented (screenshot + steps to reproduce), prioritized, assigned, fixed, and retested. Don't skip the retest — fixes sometimes introduce new issues.
Step 5 — Technical & SEO verification
This is where many teams cut corners. Before signing off, verify:

Page load speed (PageSpeed Insights)
Every page returns HTTP 200 (no silent errors)
No broken links or missing redirects
JavaScript console is clean
robots.txt and sitemap are correct

The Acceptance Testing Checklist
FUNCTIONAL
☐ All forms submit correctly and trigger expected emails
☐ Navigation links point to correct pages
☐ Dynamic content loads properly (sliders, filters, search)

RESPONSIVE
☐ Mobile layout is clean and usable
☐ Touch targets are large enough
☐ No content overflow on small screens

TECHNICAL
☐ All pages return HTTP 200
☐ No 404 errors on internal links
☐ 301 redirects are active (after a redesign)
☐ Page speed score is acceptable (Core Web Vitals)
☐ No JS errors in browser console

SECURITY
☐ SSL certificate is valid on all pages
☐ Admin access is protected
☐ Forms are protected against XSS and SQL injection

LEGAL & COMPLIANCE
☐ Cookie consent banner is present
☐ Privacy policy is linked in forms
☐ GDPR data handling is documented

SIGN-OFF
☐ All blocking bugs resolved
☐ Client/stakeholder approval obtained
☐ PV de recette (acceptance report) signed

Common Mistakes to Avoid

Testing only in your local environment, not on a staging server
Skipping mobile testing entirely
Not involving the actual end user in UAT
Forgetting to document anomalies (memory is not a bug tracker)
Treating acceptance testing as a one-time event rather than an iterative process

Going Deeper
If you work in French or with French-speaking clients, I wrote a comprehensive guide on recettage web covering all these phases in detail, including tools and real-world examples: Recettage : définition, étapes et bonnes pratiques
If you need help running acceptance testing on your WordPress project or want a freelance partner for the full delivery process, you can also check out my freelance services at Lyode.

What's your go-to tool for tracking bugs during acceptance testing? Drop it in the comments.

Cleaning a 4,000-image WordPress Media Library without breaking SEO

Lyode freelance — Thu, 29 Jan 2026 12:41:07 +0000

Cleaning a 4,000-image WordPress Media Library without breaking SEO

On most WordPress sites, the media library is the dirtiest part of the stack.

Not the theme.

Not the plugins.

Not even performance.

The media library.

Recently, I had to clean a WordPress site with nearly 4,000 images accumulated over several years. Multiple contributors, no rules, no real process.

The challenge wasn’t “optimizing images”.

It was cleaning everything without breaking SEO or existing content.

This article explains what actually goes wrong, what you should never do, and a safe strategy to clean a large WordPress media library.

Why WordPress media libraries rot over time

Media libraries don’t become messy because people are careless.

They rot because WordPress makes it very easy to upload files — and very hard to enforce rules.

Over time, you usually end up with:

Images named IMG_4839.jpg, final-banner-ok-v3.png, screenshot_2021_12_edited.jpg
Missing or useless ALT attributes
Images uploaded at 4000px wide for a 1200px layout
Useful formats blocked by default (SVG, WEBM, ZIP…)
No consistency between old and new content

Add editors, clients, interns, agencies… and the mess compounds.

The worst part?

Most people are afraid to touch the media library, because they fear breaking pages or SEO.

That fear is justified.

What you should NOT do

Before talking about solutions, let’s be clear about the mistakes.

❌ Manually renaming files

Renaming media files directly (FTP or media replacement) can break:

internal references
external links
cached URLs
social previews

❌ Re-uploading images “cleanly”

Re-uploading means:

losing existing URLs
losing Google Image history
risking broken layouts

❌ Aggressive compression plugins

Compression is not cleaning.

Compression plugins can:

degrade image quality
change file hashes
trigger layout shifts
hide structural issues instead of fixing them

❌ Blind AI-generated ALT text

Automatically generating descriptive ALT text without context:

creates irrelevant descriptions
introduces semantic noise
can hurt accessibility and SEO

Automation is fine.

Guessing is not.

The safe cleanup strategy

When dealing with thousands of images, the goal is normalization, not magic.

Here’s a strategy that works reliably.

1. Normalize filenames (without breaking URLs)

You don’t need poetic filenames.

You need clean, readable, predictable ones.

Remove useless characters (_, random hashes, duplicated words)
Keep meaningful words when possible
Apply the same rules everywhere

Done properly, this improves long-term maintainability without breaking references.

2. Generate clean, neutral ALT attributes

ALT text is not a keyword playground.

For large libraries:

Neutral, descriptive ALT is safer than “creative” ALT
Consistency is more important than cleverness
Missing ALT is worse than simple ALT

The goal is accessibility first, SEO second.

3. Resize images (not compress them)

Most WordPress images are simply too large.

Resizing means:

keeping visual quality
reducing unnecessary pixels
matching real display needs

On large sites, resizing alone can save hundreds of megabytes, without touching compression.

4. Control allowed formats properly

WordPress blocks many useful formats by default.

Instead of hacks:

explicitly allow required formats
apply proper security rules
keep control at upload level

This avoids unsafe plugins and manual workarounds.

Real case: cleaning a 4,000-image media library

On this project, the site contained 3,949 images.

After cleanup:

79 missing ALT attributes were generated
1,150 filenames were normalized
80 oversized images were resized
~370 MB of disk space was saved

No broken pages.

No URL changes.

No SEO loss.

The tool I used (and why I built it)

To automate this safely, I built a small WordPress plugin called Filikod.

Important clarifications:

No AI
No destructive compression
No guessing

Filikod focuses on:

predictable automation
structural cleanup
long-term consistency

You can find it here on WordPress.org:

https://wordpress.org/plugins/filikod/

And the project website:

https://filikod.com

(No hard sell. Just context.)

When automation makes sense (and when it doesn’t)

Automation makes sense when:

the site has hundreds or thousands of images
multiple people upload content
consistency matters over time

Automation is not always necessary for:

very small sites
single-author blogs
temporary projects

The key is control, not speed.

Final thoughts

A messy media library is not a minor issue.

It’s a structural problem that affects:

performance
accessibility
SEO
long-term maintenance

The solution isn’t magic plugins or AI promises.

It’s boring, predictable cleanup, done safely.

Tools should clean.

Not guess.

Filikod : le plugin WP qui prend soin de vos images

Lyode freelance — Thu, 11 Dec 2025 21:23:36 +0000

Gérer les médias d’un site WordPress n’est jamais anodin.
Images trop lourdes, ALT text oubliés, formats refusés… ces petits détails s’accumulent et finissent par impacter les performances, l’accessibilité et le SEO.

Pour aider les utilisateurs à simplifier cette gestion, nous avons créé Filikod, un plugin gratuit dédié à la qualité des images.
https://filikod.com

Qu’est-ce qu’un ALT text et pourquoi est-il important ?

L’ALT text est une description d’image utilisée :

par Google pour comprendre le contenu visuel,
par les lecteurs d’écran pour l’accessibilité,
par les navigateurs si l’image ne peut pas s’afficher.
Un ALT text manquant ou mal renseigné affaiblit le SEO et crée un obstacle pour les utilisateurs en situation de handicap.

Avec Filikod

Le plugin génère automatiquement un ALT text propre lors de l’upload,
et propose un outil permettant de corriger l’intégralité des images déjà présentes dans la médiathèque.

Pourquoi vos images doivent-elles être redimensionnées ?

Une image trop large ralentit le chargement de vos pages et alourdit votre espace de stockage.
La plupart des images envoyées sur WordPress dépassent la largeur réellement nécessaire pour l’affichage.

Avec Filikod

Le plugin peut :

redimensionner automatiquement les nouvelles images,
ajuster les images existantes via un traitement global. Il conserve la qualité, réduit le poids et applique une taille cohérente pour tout le site.

Quels formats supplémentaires peut-on activer ?

WordPress n’autorise pas certains fichiers utiles au quotidien :
PSD, AI, ICO, ZIP, WEBM…
**
Avec Filikod**

Vous pouvez activer ou désactiver ces formats directement depuis le tableau de bord, sans manipulations complexes.

Le contrôle est simple, visuel, et adapté aux besoins de chaque site.

Comment installer Filikod ?

Aller sur WordPress.org : https://wordpress.org/plugins/filikod
Installer le plugin
Activer
Laisser Filikod travailler en arrière-plan

5 bonnes pratiques pour améliorer la performance de votre site WordPress

Lyode freelance — Wed, 29 Oct 2025 20:20:22 +0000

La performance d’un site WordPress n’est pas qu’une question de rapidité : c’est aussi un facteur essentiel pour le référencement naturel (SEO) et l’expérience utilisateur.

En tant que développeur WordPress freelance à Lyon, j’optimise chaque projet pour obtenir un site à la fois fluide, léger et durable.

Voici 5 bonnes pratiques simples à mettre en place 👇

⚙️ 1. Allégez vos plugins

Chaque plugin ajoute du code, parfois inutile. Avant d’en installer un nouveau, demandez-vous s’il est vraiment indispensable.

Supprimez les extensions inactives et privilégiez les solutions légères (ou un petit bout de code sur mesure).

🧠 2. Optimisez vos images

Les images sont souvent les fichiers les plus lourds. Utilisez le format WebP quand c’est possible, activez la compression et le lazy loading.

Des outils comme TinyPNG ou des plugins spécialisés comme filikod ou imagify peuvent vous aider.

🔒 3. Activez la mise en cache

Une extension comme WP Rocket ou LiteSpeed Cache permet de stocker des versions statiques de vos pages pour accélérer le chargement.

C’est souvent la première amélioration visible pour l’utilisateur.

📡 4. Surveillez vos Core Web Vitals

Les métriques comme LCP, FID et CLS sont mesurées par Google et influencent votre positionnement.

Testez régulièrement votre site sur PageSpeed Insights pour détecter les points d’amélioration.

🧰 5. Tenez votre site à jour

WordPress, les thèmes et les plugins doivent être mis à jour pour garantir la stabilité et la sécurité.

Une maintenance régulière évite les lenteurs et les vulnérabilités.

💡 Ces optimisations sont cumulatives : appliquées ensemble, elles améliorent le score Lighthouse et la satisfaction des visiteurs.

📍 Je partage régulièrement des tutoriels WordPress et des conseils sur la performance, la sécurité et le SEO.

👉 Découvrez mon plugin et mes conseils sur Lyode.fr – création et optimisation de sites WordPress