Suite à la publication de cet article,
J’ai lu un commentaire :
sur linkedin de monsieur Jean-Baptiste Audras
Je tiens à souligné le travail de l’équipe WordPress Core qui m’a gentille ment précisé que leur feuille de route privilégie une rétrocompatibilité prudente pour le cœur du CMS.
Note de l’auteur :
L’alerte lancée ici concerne prioritairement l’écosystème tiers (Thèmes, Page Builders, Plugins non maintenus) qui constitue 90% des causes de crashs lors des montées de version PHP.
Le Core de WordPress reste, lui, un modèle de stabilité.

D’ici 2026, deux géants vont simultanément changer les règles du jeu.
La majorité des sites WordPress actuels ne survivront pas à la transition sans une refonte totale.
Nous ne parlons pas d’une simple mise à jour de sécurité.
Nous parlons d’un changement de paradigme architectural. PHP 9.0 ne se contentera plus de vous avertir poliment via des fichiers logs : il exécutera froidement les menaces de dépréciation accumulées depuis dix ans.
Fini le typage approximatif, fini les variables déclarées à la volée.
En parallèle, WordPress 7.0 finalisera sa mutation vers le Full Site Editing (FSE),
rendant obsolète l’architecture PHP monolithique des thèmes classiques (« Legacy Themes »).
Le problème ?
80% du marché repose sur des colosses aux pieds d’argile comme Elementor, Divi ou Avada.
Ces outils, gavés de
<div> inutiles et de dépendances jQuery, sont techniquement incompatibles avec la vision « Performance-First » imposée par le moteur PHP JIT (Just-In-Time) et les Core Web Vitals de Google (INP).Cet article n’est pas une prédiction.
C’est un avis de tempête.
Si votre stratégie repose sur des plugins « tout-en-un » et du code spaghetti,
vous avez deux ans pour pivoter. Voici pourquoi votre stack actuelle est déjà morte.
Comment construire celle qui dominera la prochaine décennie ?
PHP 9.0 : La fin du laxisme (Strict Typing Only)
PHP 9.0 va transformer les
Deprecation Notices de la version 8.x en Fatal Errors.Pour cela, il a besoin de certitudes.
Ce qui va casser :
// ❌ Code Legacy (Actuel)
class User {
public $name;
}
$u = new User();
$u->age = 35; // Création dynamique de propriété : DEPRECATED en 8.2 -> FATAL en 9.0// ✅ Code Strict (Futur)
declare(strict_types=1);
final class User {
public function __construct(
public readonly string $name,
public int $age
) {}
}WordPress 7.0 : L’ère « Interactivity API » (Adieu jQuery)
Tout convergera vers le JSON.
- La mutation de l’architecture
- Database : Abandon progressif de la table
wp_optionsmonolithique au profit de structures indexées pour le JSON (compatible SQLite/MySQL 8+). - Frontend : L’API d’Interactivité (introduite en WP 6.5) deviendra le standard. Si votre plugin utilise encore jQuery pour un toggle de menu, il sera considéré comme « bloatware ».
- Database : Abandon progressif de la table
// store.js (Interactivity API)
const store = getConfig('myPlugin');
store({
state: {
isOpen: false,
},
actions: {
toggle: ({ state }) => {
state.isOpen = !state.state.isOpen;
},
},
});La Stratégie de Migration (Roadmap 2025-2026)
Audit via Rector (Automated Refactoring)
Rector en CLI pour scanner vos plugins custom et forcer le typage strict.composer require rector/rector --dev
vendor/bin/rector process wp-content/plugins/mon-plugin-custom --dry-runAutopsie :
Pourquoi votre Page Builder va crasher (Preuves par le code)
Fatal Error PHP est un fait. Voici les 3 points de rupture critiques qui attendent les sites sous Divi, Avada et Elementor.Le crash PHP 9.0 : La fin des « Dynamic Properties »
Le Code Legacy (Style Divi/Avada/Elementor Core) :
class Elementor_Widget_Base {
public function __construct() {
// En PHP 9.0, ceci déclenche une FATAL ERROR
// car la propriété 'settings' n'a jamais été déclarée dans la classe.
$this->settings = array('color' => 'red');
}
}
// Résultat serveur :
// Fatal error: Uncaught Error: Cannot create dynamic property Elementor_Widget_Base::$settingsfinal class Webmaster67_Block {
// Typage strict et déclaration obligatoire
private array $settings;
public function __construct(array $settings) {
$this->settings = $settings;
}
}
// Résultat serveur :
// Exécution en 0.002ms. JIT Compiler Validated.#[AllowDynamicProperties] qui ralentit l’optimisation OpCode du serveur. C’est une béquille, pas une solution.Le DOM Hell :
Pourquoi l’INP (Interaction to Next Paint) explose
div inutile ajoute du temps de calcul (Style Recalculation) au navigateur.Comparons le code HTML généré pour un simple titre H2 rouge.
<div class="elementor-section">
<div class="elementor-container">
<div class="elementor-row">
<div class="elementor-column">
<div class="elementor-column-wrap">
<div class="elementor-widget-wrap">
<div class="elementor-widget elementor-widget-heading">
<div class="elementor-widget-container">
<h2 class="elementor-heading-title">Mon Titre</h2>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div><h2 class="wp-block-heading has-text-color has-red-color">
Mon Titre
</h2>Le JavaScript Bloat :
jQuery vs Interactivity API
Les builders chargent des fichiers JS énormes (parfois 500kb) juste « au cas où ».
// Chargé sur TOUTES les pages, même sans slider
jQuery(document).ready(function($) {
$('.et_pb_toggle').click(function() {
$(this).find('.et_pb_toggle_content').slideToggle();
// Bloque le Main Thread pendant l'animation
// INP Score : > 200ms (Mauvais)
});
});// view.js - Chargé UNIQUEMENT si le bloc est présent
// Utilise des signaux (comme Preact/SolidJS)
import { store, getContext } from '@wordpress/interactivity';
store( 'my-plugin/toggle', {
actions: {
toggle: () => {
const context = getContext();
context.isOpen = ! context.isOpen;
// Modification directe du DOM virtuel.
// INP Score : < 20ms (Excellent)
},
},
} );Le piège du « Lock-in » (Shortcodes vs HTML)
[et_pb_section bb_built="1"][et_pb_row][et_pb_text]
Bonjour le monde
[/et_pb_text][/et_pb_row][/et_pb_section]<p>Bonjour le monde</p>Conclusion : Innover ou Disparaître
Ils filtreront les « bricoleurs » des « ingénieurs web ».
Chez Webmaster67, nos infrastructures tournent déjà sur PHP 8.3/8.4 avec des règles de compatibilité stricte.
Nous ne subissons pas les mises à jour, nous les attendons pour gagner en performance.
Quand sortiront WordPress 7.0 et PHP 9.0 ?
Selon le cycle de développement, PHP 9.0 est attendu pour fin 2025 / début 2026. WordPress 7.0 suivra probablement en 2026 avec la finalisation des phases 3 et 4 de Gutenberg. Attention : les hébergeurs performants forceront la compatibilité bien avant.
Est-ce que mon site Elementor/Divi va vraiment casser ?
Oui, c’est une certitude technique. PHP 9.0 supprime la gestion des « Dynamic Properties ». Si le noyau de ces builders n’est pas entièrement réécrit en mode « Strict Typed », le site affichera une Fatal Error critique. De plus, leur structure DOM lourde sera pénalisée par les standards INP 2026.
Pourquoi faut-il supprimer jQuery de son site WordPress ?
jQuery est une dette technique de 2010. Charger une librairie bloquante de 80kb pour une animation simple est une erreur de performance. L’avenir est à l’Interactivity API (Preact/Native) qui permet une exécution instantanée (Zero-Runtime) et un score INP inférieur à 50ms.
En quoi consiste la stack « Souveraine & Native » de Webmaster67
C’est une architecture zéro-bloatware : Thème Blocksy Pro (léger), Gutenberg + Greenshift (Code natif), Serveur PHP 8.4/9.0 optimisé opCache, et Analytics Matomo auto-hébergé.
Combien coûte la migration vers une architecture Native ?
Moins cher à long terme que de maintenir un site lent qui perd du SEO et nécessite des correctifs de sécurité constants. Une refonte « One-Shot » vers du code natif garantit la pérennité pour la décennie à venir.
