WordPress 7.0 : L'entrée dans l'ère de la collaboration et de l'IA native

SOMMAIRE

Un contexte particulier pour une version majeure

Le 9 avril 2026, WordPress franchit un cap symbolique avec la sortie de sa version 7.0. C’est la mise à jour la plus ambitieuse depuis l’introduction de l’éditeur Gutenberg en 2018, et elle marque l’entrée officielle dans la Phase 3 du projet Gutenberg, consacrée à la collaboration et aux workflows.

L’année 2025 a été particulière pour WordPress. Les tensions juridiques entre Automattic et WP Engine, combinées à un contexte de gouvernance complexe, ont limité le calendrier à deux versions majeures seulement : WordPress 6.8 en avril et 6.9 en décembre. Le projet revient en 2026 avec un rythme soutenu de trois releases prévues : 7.0 en avril, 7.1 en août et 7.2 en décembre.

WordPress 7.0 n’est pas une simple mise à jour incrémentale. C’est un changement de paradigme qui repositionne le CMS comme une plateforme collaborative, dotée d’une infrastructure IA native et d’outils de design qui réduisent la dépendance aux constructeurs de pages tiers. Actuellement en Release Candidate, la version finale est en bonne voie pour la date prévue, qui coïncide avec le Contributor Day du WordCamp Asia 2026 à Mumbai.

La collaboration temps réel arrive dans WordPress

C’est la fonctionnalité phare de WordPress 7.0 et le cœur de la Phase 3 du projet Gutenberg : la possibilité pour plusieurs utilisateurs de travailler simultanément sur un même contenu, directement dans l’éditeur de blocs.

Co-édition multi-utilisateurs

Plusieurs rédacteurs, chefs de projet ou validateurs peuvent désormais modifier le même article ou la même page en temps réel. Les modifications sont synchronisées entre les participants, avec un support du mode hors-ligne : les changements effectués sans connexion sont reconciliés automatiquement à la reconnexion.

L’implémentation technique repose sur un système CRDT (Conflict-free Replicated Data Type) couplé à un sync provider HTTP par polling. Les données de synchronisation sont stockées de manière persistante via post_meta sur un type de post interne dédié (wp_sync_storage). Ce choix technique garantit une compatibilité universelle avec tous les environnements d’hébergement, sans nécessiter de support WebSocket. L’architecture du sync provider est conçue pour être interchangeable : le stockage et la couche de transport peuvent être remplacés par des plugins ou des hébergeurs.

Point important à noter : la collaboration temps réel sera désactivée par défaut dans la version 7.0. Elle est accessible en opt-in via Réglages > Écriture. Dans cette première itération, le nombre de collaborateurs simultanés est limité à deux. Les hébergeurs peuvent activer la fonctionnalité pour leurs clients via une constante wp-config, et des providers WebSocket pourront être ajoutés via des plugins pour améliorer la réactivité.

Ce choix de prudence fait suite aux retours de la communauté pendant la phase beta. Des problèmes de performance lors de l’édition simultanée d’un même bloc ont été identifiés (placement du curseur, latence variable), et l’équipe a préféré proposer une base solide et activable plutôt qu’une expérience instable par défaut. L’objectif clairement affiché est d’activer la fonctionnalité par défaut dans WordPress 7.1, après un cycle de tests complémentaire et une meilleure couverture du support par les plugins.

À noter également : la collaboration temps réel se désactive automatiquement lorsque des meta boxes classiques sont présentes sur une page. Les plugins qui n’ont pas encore migré vers l’API Block ne pourront donc pas cohabiter avec la co-édition.

Notes inline

Introduites dans WordPress 6.9, les Notes sont stabilisées et enrichies dans la version 7.0. Ce système de commentaires contextuels permet de laisser des annotations directement sur des blocs spécifiques dans l’éditeur. Les Notes sont synchronisées en temps réel, et un raccourci clavier dédié facilite leur création.

Pour les équipes éditoriales, c’est un changement majeur : les allers-retours par email ou via des outils externes (Google Docs, Slack) pour les revues de contenu peuvent être remplacés par un workflow intégré directement dans WordPress.

Un tableau de bord modernisé

WordPress 7.0 apporte un rafraîchissement visuel bienvenu à l’interface d’administration, tout en conservant la structure familière que les utilisateurs connaissent.

Nouveau design par défaut

Le color scheme par défaut de l’administration est entièrement repensé : des tons plus sobres, une typographie modernisée et un aspect général plus épuré. Ce n’est pas une refonte complète de l’interface (celle-ci est prévue progressivement sur les versions suivantes via le Design System WordPress et les composants DataViews/DataForm), mais un premier pas visible vers une expérience d’administration plus contemporaine.

Révisions visuelles

Les révisions de contenu gagnent une nouvelle dimension avec la comparaison visuelle directement dans l’éditeur. Plus besoin de lire un diff textuel pour comprendre ce qui a changé entre deux versions d’une page : la comparaison s’affiche de manière graphique, rendant le suivi des modifications beaucoup plus intuitif pour les non-développeurs.

View Transitions

Les transitions entre écrans dans le tableau de bord sont désormais fluides grâce aux cross-document view transitions. La navigation entre les différentes sections de l’admin se fait sans rechargement brutal, offrant une expérience plus proche d’une application web moderne.

Command Palette accessible partout

Ajoutée en RC1, la Command Palette est désormais accessible via le raccourci ⌘K (Mac) ou Ctrl+K (Windows/Linux) directement depuis la barre d’administration. Ce centre de commandes permet de naviguer, personnaliser et accéder à n’importe quelle fonctionnalité sans quitter l’écran en cours.

C’est aussi un gain significatif en matière d’accessibilité : la Command Palette offre une navigation complète au clavier, sans dépendre de la souris. Pour les utilisateurs qui naviguent exclusivement au clavier — ou qui utilisent des technologies d’assistance — c’est une avancée concrète dans la gestion quotidienne de leur site WordPress.

Mais c’est aussi un outil de productivité redoutable pour les power users et les gestionnaires de sites. En quelques frappes, vous accédez directement à la gestion des plugins, aux réglages de lecture, à la création d’un nouveau contenu ou à la recherche d’un article spécifique — sans naviguer dans les menus. Pour les équipes qui gèrent plusieurs contributeurs, c’est un gain de temps significatif et un accélérateur de prise en main pour les nouveaux utilisateurs.

Nouveaux blocs et outils de design

WordPress 7.0 enrichit la palette de blocs disponibles et les outils de personnalisation, avec plusieurs ajouts attendus de longue date par la communauté.

Bloc Navigation repensé

Le workflow de gestion de la navigation est simplifié et clarifié. Les overlays de navigation (notamment les menus mobiles) sont désormais personnalisables en tant que template parts, avec la possibilité de définir des breakpoints custom pour contrôler à quel moment le menu bascule vers sa version mobile. Cette fonctionnalité n’est plus expérimentale : elle est intégrée au core et un bouton « Créer un overlay » guide l’utilisateur dans la mise en place.

Bloc Cover : vidéo en arrière-plan

Le bloc Cover accepte désormais les vidéos intégrées (YouTube, Vimeo…) comme arrière-plan. C’est une fonctionnalité qui manquait cruellement pour les designs éditoriaux ambitieux et qui, jusqu’ici, nécessitait du code custom ou un page builder. Le projet architect de Gutenberg, Matías Ventura, a personnellement contribué à cette fonctionnalité — un signe de l’importance que l’équipe core accorde à l’enrichissement des outils de design natifs.

Nouveaux blocs natifs

WordPress 7.0 introduit plusieurs blocs attendus par la communauté :

• Breadcrumbs (fil d’Ariane) : enfin disponible nativement, sans recourir à un plugin SEO ou un snippet custom. Le bloc permet de contrôler l’affichage du lien vers l’accueil, le dernier élément de la hiérarchie, et le caractère de séparation. Il supporte toutes les options de style habituelles (couleur, typographie, dimensions, bordures). C’est un ajout historique pour les professionnels du référencement : le fil d’Ariane est un élément clé du maillage interne et de la compréhension de l’architecture du site par les moteurs de recherche. Jusqu’ici, sa mise en place nécessitait soit un plugin dédié comme Breadcrumb NavXT, soit le module de navigation intégré à des plugins SEO comme Yoast ou Rank Math — souvent surdimensionnés pour ce seul besoin. Le bloc natif WordPress simplifie considérablement cette mise en place. À noter toutefois : en l’état actuel (RC1 & 2), le bloc génère un balisage HTML visible mais ne produit pas automatiquement de données structurées JSON-LD Schema.org BreadcrumbList. Pour le balisage structuré, il reste recommandé de s’appuyer sur votre plugin SEO ou d’ajouter le markup JSON-LD manuellement. C’est un point qui pourrait évoluer dans les versions futures.
• Icons : un bloc dédié à l’intégration d’icônes, avec des options de style limitées pour l’instant mais extensibles dans les versions futures.
• Heading en variations : les niveaux de titres (H1-H6) sont désormais disponibles comme variations du bloc Heading, offrant plus de contrôle sur la hiérarchie sémantique des pages.

À noter : le bloc Tabs, initialement prévu pour 7.0, est repassé en mode expérimental. L’implémentation de l’état actif des onglets nécessite une solution plus générale. Les blocs Playlist et Dialog n’ont pas non plus été finalisés à temps. Ces trois blocs sont les candidats les plus probables pour WordPress 7.1.

Bloc Grid responsive

Le bloc Grid, initialement statique, est désormais responsive. Les mises en page en grille s’adaptent automatiquement aux différentes tailles d’écran, un apport important pour les designs multi-colonnes.

Lightbox natif dans le bloc Gallery

Le bloc Gallery intègre désormais un support lightbox natif : un clic sur une image ouvre une vue agrandie avec navigation entre les éléments de la galerie, sans plugin supplémentaire.

Responsive Editing Mode

C’est l’une des nouveautés les plus demandées par les créateurs de contenus. Il est désormais possible d’afficher ou de masquer des blocs en fonction de la taille de l’écran. On peut par exemple afficher un contenu uniquement sur mobile, ou inversement le réserver au desktop. Cette fonctionnalité réduit considérablement le besoin de recourir à du CSS custom ou à des plugins de visibilité conditionnelle.

Nous avions développé en interne un plugin dédié à cet usage afin de permettre une gestion fine des affichages conditionnels mobile / tablette / desktop sur les sites de nos clients. Voir l’éditeur évoluer dans ce sens ne peut que nous ravir.

Évolution des Patterns

Les Patterns passent par défaut en mode Content-Only editing dans WordPress 7.0. Dans ce mode, les champs sont organisés avec des icônes de blocs et des menus flottants, réduisant le bruit visuel pour les contributeurs qui se concentrent sur le contenu. Le formatage rich text fonctionne en inline sans interruption par la barre d’outils. Un nouveau Spotlight mode permet d’isoler le contenu dans les patterns et les notes, tandis que le mode Isolated Editor sert à l’édition de symboles, patterns synchronisés et template parts.

Les administrateurs peuvent désactiver le mode Content-Only pour les patterns non synchronisés via un filtre PHP ou un dispatch JavaScript.

Outils de design complémentaires

WordPress 7.0 ajoute aussi le support de l’indentation de texte, des colonnes de texte, des ratios d’aspect pour les images en pleine largeur, et des presets de dimensions. La Font Library (gestion des polices) est désormais activée pour tous les thèmes : chaque éditeur de site peut parcourir, installer et organiser les polices disponibles, quel que soit le thème utilisé.

Ce qui a été reporté à WordPress 7.1

Dans un souci de qualité, certaines fonctionnalités initialement prévues pour WordPress 7.0 ont été reportées. C’est un signe de maturité du projet : mieux vaut une fonctionnalité solide plus tard qu’une fonctionnalité instable maintenant.

Traitement média côté navigateur

Le client-side media processing devait être l’une des avancées phares de WordPress 7.0 : le redimensionnement et la compression des images directement dans le navigateur, via WebAssembly et la bibliothèque libvips, plutôt que sur le serveur.

Mais les tests de performance menés par Sérgio Gomes, ingénieur performance chez Automattic, ont révélé des temps de traitement bien au-delà des attentes : environ 19 secondes pour un JPEG et entre 29 et 55 secondes pour un AVIF, y compris sur un MacBook Pro M4 Pro. Des problèmes de compatibilité navigateur et de taille du bundle ont également été identifiés.

Face à ces résultats, la fonctionnalité a été retirée du core et sera livrée sous forme de plugin uniquement dans un premier temps, avant une intégration dans WordPress 7.1 une fois les performances optimisées.

C’est un point important pour nos clients : cette décision illustre la rigueur de l’écosystème WordPress. Cette approche fait la solidité de WordPress en tant que plateforme professionnelle.

Always-iframed post editor

L’isolation systématique de l’éditeur d’articles dans un iframe, prévue pour WordPress 7.0, est reportée à 7.1. L’approche a été révisée : l’iframe ne sera imposé que lorsque tous les blocs insérés dans un article utilisent l’API Block v3 ou supérieure, plutôt que de vérifier chaque bloc enregistré sur l’ensemble des plugins. Le plugin Gutenberg continue d’utiliser cette approche pour collecter les retours.

Autres reports

Le bloc Tabs, le bloc Playlist et le bloc Dialog n’ont pas été finalisés à temps. Les Core Abilities pour la gestion des posts (core/create-post, core/get-post, etc.) nécessitent une revue supplémentaire sur la structure des schémas et sont reportées à 7.1.

L’intelligence artificielle intégrée au cœur de WordPress

WordPress 7.0 ne se contente pas d’ajouter des fonctionnalités IA : il pose les fondations d’une infrastructure native qui permettra à tout l’écosystème d’exploiter l’intelligence artificielle de manière standardisée.

Ce qui est dans le Core vs. ce qui reste en plugin

Avant de détailler les fonctionnalités, une clarification importante s’impose. La frontière entre core et plugin est volontairement nette dans WordPress 7.0 :

Dans le Core WordPress 7.0 (infrastructure) :

• Le PHP AI Client SDK — la couche PHP provider-agnostic qui gère la communication avec les modèles IA
• L’API Connectors — le framework de gestion des connexions aux services externes
• L’écran Réglages > Connectors — l’interface d’administration pour gérer les providers
• L’Abilities API côté client — le registre standardisé de fonctionnalités découvrables

En plugins séparés (sur WordPress.org) :

• Les providers IA eux-mêmes (Anthropic/Claude, OpenAI/GPT, Google/Gemini) — trois plugins officiels installables directement depuis l’écran Connectors
• Les providers communautaires — Grok, OpenRouter, Ollama (en développement) et d’autres
• Le plugin AI Experiments — les fonctionnalités utilisateur concrètes (génération de contenu, génération d’images, suggestions éditoriales, alt text automatique)

En projet séparé (GitHub) :

• Le WordPress MCP Adapter — le pont entre WordPress et le protocole MCP pour les agents IA externes

Cette séparation est délibérée. Le core fournit la plomberie stable, les plugins apportent les fonctionnalités qui évoluent rapidement. Si vous ne configurez rien, rien ne change sur votre site.

Le WP AI Client : une couche unifiée pour toutes les IA

Aujourd’hui, chaque plugin WordPress qui utilise l’IA embarque son propre wrapper API, sa propre page de réglages pour les clés API, et sa propre logique de connexion aux providers. Si vous installez trois plugins IA, vous configurez trois fois les mêmes credentials.

Le WP AI Client résout ce problème de la même manière que WordPress a résolu l’accès aux bases de données avec $wpdb ou les requêtes HTTP avec wp_remote_post() : avec une couche partagée unique.

Concrètement, le WP AI Client expose une API PHP fluide via la fonction wp_ai_client_prompt(). Les développeurs de plugins peuvent définir des instructions système, attacher des fichiers, spécifier des préférences de modèles avec fallbacks, demander des réponses JSON structurées — le tout via une interface cohérente et conforme aux conventions WordPress (snake_case, WP_Error, transport HTTP WordPress natif).

Point essentiel : le WP AI Client est de l’infrastructure, pas un produit. Il ne fait rien par défaut. Aucun provider n’est pré-configuré, aucune donnée n’est envoyée nulle part sans action explicite de l’administrateur.

L’écran Connectors

L’écran Réglages > Connectors est l’interface centralisée pour gérer les connexions aux services IA. Il affiche chaque provider sous forme de carte avec son nom, sa description et son logo. Depuis cette interface, vous pouvez installer et activer les plugins providers, saisir vos clés API, et vérifier le statut de connexion.

L’écran détecte automatiquement la source des credentials (variable d’environnement, constante PHP, ou base de données), ce qui permet aux hébergeurs de pré-configurer des providers pour leurs clients.

⚠️ Point de vigilance soulevé par la communauté (mars 2026) : une fois un provider IA connecté via l’écran Connectors, tout plugin installé sur le site peut l’utiliser. Il n’existe pas encore de contrôle par plugin. Concrètement, un plugin pourrait mettre à jour et commencer à consommer des tokens via un provider configuré pour un autre usage, sans signal visible pour l’administrateur. L’équipe AI de WordPress travaille déjà sur deux réponses : un dashboard de logs (AI Request Logs, en cours de développement par James LePage chez Automattic) qui affichera les requêtes par provider, modèle, tokens consommés et coût estimé, et un modèle de permissions par plugin proposé par Nik McLaughlin (GoDaddy). Ces fonctionnalités arriveront probablement dans une mise à jour du plugin AI Experiments avant d’être intégrées au core.

En attendant, notre recommandation : si vous configurez un provider IA, auditez les plugins installés sur votre site et surveillez votre consommation API.

L’Abilities API : WordPress devient découvrable par les agents IA

L’Abilities API, introduite expérimentalement dans WordPress 6.9 et intégrée au core dans 7.0, est peut-être l’innovation la plus structurante à long terme.

Le concept : chaque fonctionnalité WordPress (qu’elle vienne du core, d’un plugin ou d’un thème) peut se déclarer sous forme d' »ability » — une unité fonctionnelle autonome avec un nom, une description, des inputs/outputs définis en JSON Schema, des permissions d’accès, et un callback d’exécution.

Le résultat : ces abilities sont découvrables par les agents IA, les outils d’automatisation et les systèmes externes. Un agent IA peut interroger un site WordPress pour savoir ce qu’il sait faire, comprendre comment chaque fonctionnalité fonctionne, et l’exécuter dans le respect des permissions définies.

Trois usages concrets émergent :

• Actions unitaires : un bouton « résumer le contenu » dans l’éditeur qui appelle une ability liée au WP AI Client
• Boucles agentiques : un modèle IA qui planifie et exécute une séquence d’abilities (traduire, résumer, extraire des entités, formater)
• Workflows déterministes : des chaînes d’abilities exécutées dans un ordre défini (classifier → résumer → appliquer des règles de modération → publier)

Cette architecture prépare aussi le terrain pour des évolutions majeures à venir. L’Abilities API est la brique technique qui pourrait, à terme, faciliter la mise en œuvre du multilingue natif dans WordPress, prévu dans les premières étapes pour la version 7.2 (décembre 2026). En standardisant les workflows de traduction comme des abilities (détection de langue, traduction, validation), WordPress pourrait offrir une solution de gestion multilingue intégrée sans dépendre de plugins tiers comme WPML, Polylang.

Le MCP Adapter : piloter WordPress via un agent IA

Le WordPress MCP Adapter (disponible sur GitHub, projet séparé du core) transforme un site WordPress auto-hébergé en serveur MCP (Model Context Protocol). Un agent IA externe — Claude Desktop, Cursor, VS Code, ou tout client MCP compatible — peut alors découvrir les abilities disponibles, comprendre leur fonctionnement, et les exécuter à distance, avec les permissions appropriées.

Imaginez demander à un assistant IA : « Vérifie les articles qui n’ont pas été mis à jour depuis six mois sur mon site » ou « Résume les commentaires de la semaine dernière ». Au lieu de se connecter au tableau de bord et de naviguer dans les menus, l’agent le fait pour vous.

C’est le début d’une transformation profonde : WordPress ne sera plus seulement un outil que l’on utilise, mais une plateforme avec laquelle on converse.

La boîte à outils des développeurs

WordPress 7.0 apporte plusieurs améliorations significatives pour les développeurs.

Blocs PHP-only

Il est désormais possible d’enregistrer des blocs uniquement en PHP, avec génération automatique des inspector controls côté éditeur. Plus besoin de JavaScript pour créer un bloc simple. C’est un changement important qui abaisse la barrière d’entrée pour les développeurs PHP et simplifie la maintenance wordpress des blocs.

Block Bindings étendu

Les Block Bindings supportent désormais les blocs dynamiques custom via les pattern overrides, offrant plus de flexibilité aux créateurs de blocs.

DataViews et DataForm

DataViews, qui remplace progressivement les WP List Tables, introduit un nouveau layout « activity » et la possibilité d’enregistrer des types tiers. DataForm ajoute un layout « details », de nouveaux contrôles (combobox, adaptiveSelect) et une validation complète. Ces composants sont les fondations techniques de la refonte progressive de l’admin WordPress sur les prochaines versions.

WP-CLI 3.0

Le WP-CLI prépare sa version 3.0 avec de nouvelles commandes dédiées aux blocs (wp block) et aux abilities (wp ability), permettant d’interagir avec l’écosystème WordPress de manière programmatique. L’environnement de développement wp-env supporte désormais phpMyAdmin via le runtime Playground, atteignant la parité fonctionnelle avec le runtime Docker.

CodeMirror mis à jour

CodeMirror passe en version 5.65.40, apportant plus de flexibilité et d’options d’extensibilité pour l’édition de code dans l’administration.

Prérequis techniques et préparation

Avant de mettre à jour vos sites vers WordPress 7.0, plusieurs points méritent votre attention.

Version PHP minimale

WordPress 7.0 abandonne le support de PHP 7.2 et 7.3. La version minimale requise est PHP 7.4, avec une recommandation forte pour PHP 8.3 ou supérieur pour des performances et une sécurité optimales. Vérifiez la version PHP de votre hébergement avant la mise à jour.

L’objectif de cette montée en version minimale est d’assurer la maintenabilité à long terme de WordPress : écosystème de plugins et thèmes, outillage, bibliothèques pour l’IA, perception du projet, et à terme, le code de WordPress lui-même.

Compatibilité thèmes et plugins

Comme pour toute mise à jour majeure, il est essentiel de tester la compatibilité de votre thème et de vos plugins avant de passer en production. Vérifiez que vos extensions ont été testées avec WordPress 7.0 (mention « Tested up to: 7.0 » sur la page du plugin). Les thèmes custom ou anciens qui n’ont pas été mis à jour récemment sont les plus susceptibles de présenter des incompatibilités.

Attention particulière aux plugins qui utilisent des meta boxes classiques : ils désactivent la collaboration temps réel. Et aux blocs custom qui n’ont pas encore migré vers l’API Block v3 : ils pourraient impacter le comportement de l’éditeur iframé.

Environnement de test

Ne mettez jamais à jour un site en production le jour de la sortie. Utilisez un environnement de staging pour tester la mise à jour, vérifier le bon fonctionnement de vos fonctionnalités critiques, et valider le rendu visuel. WordPress Playground permet aussi de tester la version directement dans votre navigateur, sans aucune installation.

Collaboration temps réel

Si vous souhaitez activer la collaboration temps réel, vérifiez que votre hébergeur supporte les connexions longues (et idéalement WebSocket pour une meilleure réactivité). Les hébergements mutualisés basiques fonctionneront avec le sync provider HTTP par défaut, mais l’expérience sera meilleure sur un VPS ou un hébergement managé.

Sauvegardes

Avant toute mise à jour majeure, assurez-vous que vos sauvegardes sont récentes et fonctionnelles. Vérifiez que vous pouvez restaurer votre site en cas de problème.

💡 Notre accompagnement : nous auditons la compatibilité de vos sites WordPress avant chaque mise à jour majeure. Thème, plugins, configurations spécifiques : nous identifions les points de friction potentiels et pilotons la mise à jour en environnement de staging avant tout déploiement en production. N’hésitez pas à nous contacter pour préparer sereinement le passage à WordPress 7.0.

Ce que cette version signifie pour votre site

WordPress 7.0 envoie un signal fort : le CMS le plus utilisé au monde ne se contente pas de maintenir sa position. Il se réinvente.

Pour les entreprises et institutions qui ont fait le choix de WordPress, cette mise à jour valide la pérennité de la plateforme. Les fonctionnalités de collaboration et l’infrastructure IA native positionnent WordPress comme un outil moderne, capable de rivaliser avec les plateformes propriétaires fermées, tout en préservant la liberté et la maîtrise qui font la force de l’open source.

Pour les équipes éditoriales, la collaboration temps réel (même en opt-in dans un premier temps) et les Notes inline transforment le workflow de création de contenu. Les révisions visuelles et le Responsive Editing Mode simplifient le quotidien.

Pour les développeurs et agences, les blocs PHP-only, l’Abilities API et le WP AI Client ouvrent des perspectives considérables en termes de productivité et d’innovation.

En tant qu’agence spécialisée WordPress, nous accompagnons nos clients dans chaque évolution majeure du CMS. WordPress 7.0 ne fait pas exception : audit de compatibilité, mise à jour supervisée, formation aux nouvelles fonctionnalités, migration des solutions custom vers les outils natifs, et intégration des innovations dans vos projets web font partie de notre accompagnement.

Calendrier WordPress 2026

• 9 avril 2026 : WordPress 7.0 — collaboration, IA, admin redesign, nouveaux blocs
• 19 août 2026 : WordPress 7.1 (prévu, coïncide avec WordCamp US) — client-side media processing, RTC activé par défaut, Tabs block, Core Abilities, extensibilité Connectors tiers
• Décembre 2026 : WordPress 7.2 (prévu) — extension des fonctionnalités collaboratives, premiers pas vers le multilingue natif dans le core