Le problème
Mettre à jour un plugin ou un thème WordPress reste un moment de tension : une mise à jour peut entrer en conflit avec autre chose et casser le site en production, parfois sans avertissement. La réaction la plus commune est de retarder les mises à jour — ce qui laisse justement les failles de sécurité connues ouvertes plus longtemps.
La philosophie du plugin
SafeCore ne prétend pas empêcher un plugin de mal se comporter. Il part du principe qu’une mise à jour peut échouer, et construit un filet de sécurité autour de ce moment précis : instantané ciblé avant la mise à jour, vérification automatique après, et restauration ou isolement si quelque chose casse.
Fonctionnalités
- Instantané ciblé du plugin ou du thème avant chaque mise à jour
- Vérification de santé automatique du site après la mise à jour
- Restauration automatique en cas d’erreur fatale détectée
- Isolement automatique du plugin ou thème fautif si la restauration n’est pas possible
- Console de secours accessible même quand WordPress ne charge plus
- Notifications par email et par webhook
Architecture technique
Le cœur du plugin est en PHP, sans dépendance externe pour les scripts de secours : ils doivent pouvoir s’exécuter même quand WordPress lui-même est cassé, donc ils redéfinissent leurs propres fonctions d’échappement plutôt que d’appeler celles de WordPress. L’interface d’administration, elle, est une application Vue 3 construite avec Vite et Tailwind CSS.
Choix techniques
Le mécanisme de détection s’appuie sur le gestionnaire d’erreurs fatales natif de WordPress, qui identifie automatiquement, à partir du chemin du fichier fautif, quel plugin ou thème est responsable du crash. La vérification de santé après mise à jour est volontairement conservatrice : un simple délai d’attente n’est pas traité comme un crash, pour éviter de déclencher une restauration à cause d’un faux positif.
Difficultés rencontrées
La difficulté principale n’est pas de sauvegarder un site — c’est de garantir qu’un mécanisme de secours reste fonctionnel au moment précis où tout le reste a cessé de fonctionner. Cela impose d’écrire du code qui ne dépend d’aucune des briques qu’il est censé réparer, à l’opposé des réflexes habituels de développement WordPress.
C’est directement lié à ce que je fais en maintenance WordPress : les mises à jour sont la source la plus fréquente d’incidents, et c’est aussi un terrain que je connais en développement de plugin sur mesure.
