WordPress 7.0 : collaboration en temps réel, IA native et édition repensée

Une équipe éditoriale qui travaille à plusieurs mains sur le même article, sans se marcher dessus ni devoir se relayer. Un panneau d'administration qui dialogue directement avec ChatGPT, Claude ou Gemini sans passer par une extension. Des révisions comparées visuellement plutôt qu'en lisant des différences de code. Ce sont trois des promesses de WordPress 7.0, la version majeure du CMS qui propulse plus de 40 % du web.

Cette version marque un tournant. Elle ne se contente pas d'ajouter des options ici et là : elle introduit une couche de collaboration native, ouvre WordPress aux modèles d'intelligence artificielle via une API standardisée et retravaille en profondeur l'expérience d'édition. Pour les agences, les équipes marketing, les éditeurs de contenu et les développeurs qui construisent des sites au quotidien, les changements sont concrets et méritent un examen attentif avant la mise à jour.

Nous utilisons WordPress quotidiennement chez MtoM Création, aussi bien sur des sites vitrines que sur des boutiques WooCommerce ou des projets plus techniques. Voici ce que 7.0 va changer, ce qu'il faut préparer côté site et comment aborder cette migration sereinement.

La collaboration en temps réel, la vraie rupture

Jusqu'ici, travailler à plusieurs sur un même contenu WordPress relevait du parcours d'obstacles. Deux rédacteurs qui ouvraient le même article en même temps tombaient sur un verrou d'édition : l'un pouvait travailler, l'autre devait attendre ou écraser les modifications. Pour les équipes qui publient à plusieurs, la seule solution était de se coordonner en dehors de WordPress, souvent via Google Docs, puis de coller le contenu dans l'éditeur une fois la rédaction terminée.

WordPress 7.0 change ce paradigme en introduisant la collaboration en temps réel au cœur du CMS. Plusieurs utilisateurs peuvent désormais éditer la même page ou le même article simultanément, voir les curseurs des autres se déplacer, écrire chacun dans un paragraphe différent et voir les modifications apparaître en direct. La synchronisation fonctionne même quand un utilisateur perd temporairement sa connexion : les modifications locales sont conservées et fusionnées au retour en ligne.

Comment ça fonctionne techniquement

Par défaut, la synchronisation passe par un mécanisme de HTTP polling, ce qui signifie que le navigateur interroge régulièrement le serveur pour récupérer les modifications des autres utilisateurs. Cette approche fonctionne sur n'importe quel hébergement WordPress, sans configuration particulière. Pour les sites qui ont besoin d'une synchronisation plus immédiate, WordPress 7.0 permet aux extensions et aux hébergeurs de brancher un fournisseur WebSocket à la place du polling, offrant une collaboration vraiment instantanée.

Pendant la phase bêta, la collaboration en temps réel est proposée en opt-in, ce qui signifie qu'elle doit être activée manuellement. L'équipe Core a pris cette précaution pour collecter un maximum de retours avant de généraliser la fonctionnalité. Nous y voyons un choix prudent : la couche de stockage derrière la collaboration est complexe, et la stabilité prime sur l'activation par défaut.

Les Notes, complément logique de la collaboration

WordPress 7.0 renforce également le système de notes introduit dans les versions précédentes. Les notes se synchronisent désormais en temps réel comme le contenu lui-même, un raccourci clavier permet d'en créer rapidement et plusieurs corrections de stabilité ont été apportées. Concrètement, les Notes remplacent les commentaires Google Docs utilisés pour valider un texte en interne : elles permettent à un relecteur de pointer un passage, de demander une reformulation ou de laisser un commentaire éditorial sans polluer le contenu publié.

Pour une équipe marketing qui fait valider un article par plusieurs personnes avant publication, l'enchaînement rédaction-relecture-validation se passe enfin sans sortir de WordPress.

Le Web Client AI API : WordPress branche l'IA dans son cœur

Si la collaboration est la rupture côté éditeurs, l'arrivée d'une API native pour l'intelligence artificielle est la rupture côté architecture. WordPress 7.0 introduit le Web Client AI API, une couche dans le Core qui permet à n'importe quelle extension ou thème d'interagir avec un modèle d'IA générative de façon standardisée.

Pourquoi c'est important

Avant 7.0, chaque extension qui voulait intégrer l'IA devait gérer elle-même la connexion à OpenAI, Anthropic, Google ou un autre fournisseur. Chacune avec ses propres clés API, sa propre interface de configuration, sa propre gestion des erreurs. Résultat : un site qui utilisait trois extensions IA différentes se retrouvait avec trois configurations dupliquées, trois endroits où saisir sa clé API et aucun moyen de passer facilement d'un fournisseur à l'autre.

Le Web Client AI API règle ce problème en fournissant un point d'entrée unique. L'administrateur configure ses connecteurs IA une seule fois, dans une interface dédiée de wp-admin (Réglages > Connecteurs), et toutes les extensions qui utilisent l'API officielle accèdent à ces connexions sans avoir besoin de reconfigurer quoi que ce soit. Le changement de fournisseur devient aussi simple que de basculer un paramètre.

Ce que ça change en pratique

Pour le propriétaire d'un site, cela signifie une gestion simplifiée des outils IA. Vous renseignez vos clés API pour Claude, ChatGPT et Gemini une seule fois, et vos extensions de génération de contenu, de résumé, de traduction ou d'assistance à l'écriture se branchent dessus.

Pour un développeur d'extension, cela signifie qu'ajouter une fonctionnalité IA à son produit ne nécessite plus de réinventer l'intégration. Le SDK d'Anthropic, de Google ou d'OpenAI est abstrait derrière l'API Core, et le code reste portable entre fournisseurs.

Les fournisseurs d'IA restent externes à WordPress : Automattic n'embarque pas de modèle dans le Core et ne se positionne pas comme fournisseur. WordPress joue ici le rôle de couche d'abstraction, pas de plateforme propriétaire. C'est cohérent avec la philosophie open source du projet, et ça évite de dépendre d'un seul acteur.

Cette API se combine avec l'Abilities API, dont nous reparlons plus bas dans la section développeurs, pour permettre la construction d'agents et de workflows automatisés directement dans WordPress.

Une expérience d'édition rafraîchie

Au-delà des grandes nouveautés, WordPress 7.0 retravaille l'ensemble de l'interface d'administration. Le tableau de bord adopte une nouvelle palette de couleurs par défaut, les transitions entre écrans sont fluidifiées grâce aux view transitions natives du navigateur, et plusieurs outils d'édition gagnent en clarté.

Les révisions visuelles

Jusqu'ici, comparer deux versions d'un article passait par un écran qui affichait les différences en texte, mot par mot, avec des ajouts en vert et des suppressions en rouge. Lisible pour du texte, mais peu exploitable quand les changements portaient sur la mise en page ou sur un bloc complexe.

WordPress 7.0 introduit les révisions visuelles : vous comparez deux versions d'une page en voyant réellement ce qui a changé à l'écran, avec des surlignages directement sur les blocs modifiés. Un bloc supprimé est barré, un bloc ajouté est encadré, un bloc modifié est mis en évidence. Pour valider une modification avant publication, l'outil est bien plus clair que l'ancien diff textuel.

La palette de commandes

Raccourci ⌘K sur Mac, Ctrl+K sur Windows et Linux, WordPress 7.0 généralise la palette de commandes à toute l'interface d'administration. Vous tapez "nouveau produit" et l'action correspondante apparaît. Vous tapez le nom d'une page et vous y accédez directement. Vous tapez "connecteur IA" et vous êtes redirigé vers l'écran de configuration.

L'approche est inspirée des éditeurs de code modernes comme VS Code, et elle change réellement la vitesse d'utilisation du back-office pour quelqu'un qui travaille quotidiennement dans WordPress. Plutôt que de naviguer dans des menus imbriqués, vous tapez ce que vous cherchez et vous y allez.

Les view transitions

Passer d'une page d'admin à une autre ne provoque plus ce rechargement sec familier depuis toujours. WordPress 7.0 active les cross-document view transitions, une API native du navigateur qui anime le passage d'un écran à l'autre. Rien de spectaculaire visuellement, juste une continuité qui rapproche wp-admin des applications modernes et atténue la sensation de rupture à chaque clic. L'animation s'active automatiquement dans les navigateurs qui la supportent et retombe sur une navigation classique dans les autres, sans extension ni paramètre à régler.

Les nouveaux blocs et les options de design

WordPress 7.0 enrichit la bibliothèque de blocs et améliore ceux qui existent déjà. Les ajouts sont pensés pour couvrir des besoins fréquents qui nécessitaient jusqu'ici une extension ou du code personnalisé.

Breadcrumbs et Icons, enfin natifs

Le fil d'Ariane (breadcrumb) est un élément attendu sur la plupart des sites structurés, aussi bien pour l'UX que pour l'optimisation SEO. Jusqu'à présent, il fallait installer Yoast SEO, Rank Math ou une extension dédiée pour en ajouter un. WordPress 7.0 intègre un bloc Breadcrumb natif qui se configure en quelques clics et s'affiche dans le thème sans dépendance externe.

Le bloc Icon fait la même chose pour les icônes SVG. Plutôt que d'intégrer une icône via du code, une bibliothèque tierce ou un service comme Font Awesome, vous insérez un bloc Icon, vous choisissez votre SVG, vous ajustez sa taille et sa couleur depuis l'interface visuelle.

Le bloc Heading revu

Un H4 qui suit un H2 sans H3 intermédiaire, trois H1 sur la même page, une hiérarchie qui se construit par intuition plutôt que par logique : les structures de titres incohérentes sont un classique des sites rédigés sans relecture technique. WordPress 7.0 s'attaque au problème à la source en faisant de chaque niveau de titre une variation distincte du bloc Heading. Vous insérez directement un "H2" ou un "H3" depuis l'inserteur au lieu de changer le niveau dans un menu après coup. La hiérarchie devient une décision, pas une correction.

Google lit cette structure pour comprendre l'organisation d'un contenu. Une page où les niveaux s'enchaînent proprement renvoie une crédibilité technique qu'aucun plugin SEO ne compense vraiment. Pour les équipes qui publient sans développeur en relecture, ce petit changement agit comme un garde-fou intégré contre les erreurs de hiérarchie les plus fréquentes.

Cover block avec arrière-plan vidéo embarqué

La section hero animée est devenue un standard sur les sites d'agence, les portfolios et les pages de lancement produit. WordPress 7.0 la rend accessible sans uploader de fichier lourd : le bloc Cover accepte désormais comme arrière-plan les vidéos embarquées depuis YouTube, Vimeo ou d'autres plateformes. La vidéo reste hébergée par la plateforme source, votre serveur n'a rien à servir, et les algorithmes de compression adaptative livrent la bonne qualité selon la connexion du visiteur.

Un détail à garder en tête : la dépendance à une plateforme externe. Si la vidéo source est supprimée ou passée en privé, la section hero se retrouve vide. La règle que nous appliquons chez MtoM Création : cette option pour des vidéos de marque hébergées sur un compte que vous contrôlez, pas pour des vidéos empruntées à des tiers.

Le Grid block devient responsive

Le bloc Grid gagne enfin ce qui lui manquait depuis sa création : des breakpoints responsives natifs. Quatre colonnes sur desktop, deux sur tablette, une seule sur mobile se configurent visuellement avec un aperçu en direct pour chaque taille d'écran. Chaque breakpoint accepte ses propres réglages de gap, d'alignement et d'ordre des éléments, ce qui permet d'inverser l'ordre d'une image et d'un texte entre desktop et mobile sans écrire une ligne de CSS.

Les constructeurs comme Bricks Builder ou Elementor gardent leur avance sur l'ergonomie globale d'édition. Mais pour un site qui s'en tient à l'éditeur WordPress natif, cette évolution comble un manque qui obligeait beaucoup de projets à basculer vers un constructeur tiers uniquement pour gérer le responsive de quelques sections.

Le bloc Gallery gagne le lightbox

Un visiteur clique sur une photo dans une galerie. Elle s'ouvre en plein écran, des flèches apparaissent pour naviguer d'une image à l'autre, l'arrière-plan s'assombrit. Ce comportement, appelé lightbox, est attendu sur la plupart des sites qui affichent des images. WordPress 7.0 l'intègre nativement au bloc Gallery.

Sur le papier, c'est un détail. Sur les Core Web Vitals, c'est mesurable. Les extensions comme FooGallery ou NextGEN chargent chacune leur propre JavaScript, leurs styles CSS et parfois plusieurs requêtes réseau supplémentaires, ce qui pèse sur le Largest Contentful Paint et le Cumulative Layout Shift. Le lightbox natif s'appuie sur le code existant du bloc et n'ajoute rien. Pour les photographes, les sites touristiques, les portfolios d'architectes ou les fiches produit, c'est une extension de moins à maintenir et un point de défaillance de moins à surveiller.

La Font Library universelle

La Font Library existe depuis WordPress 6.5, mais elle était réservée aux thèmes basés sur les blocs, ce qui laissait de côté la majorité des sites WordPress en production, notamment ceux construits avec Bricks Builder ou Elementor. WordPress 7.0 étend la fonctionnalité à tous les thèmes, classiques inclus.

Au-delà du confort de gestion, l'intérêt est juridique. Plusieurs décisions de justice européennes ont qualifié l'appel direct aux serveurs de Google Fonts de transfert de données personnelles vers les États-Unis, exposant les propriétaires de sites à des plaintes RGPD. Héberger les polices localement règle la question, et la Font Library native transforme cette mise en conformité en quelques clics, là où il fallait passer par l'extension OMGF ou une configuration manuelle. Les temps de chargement s'améliorent au passage, puisqu'une requête réseau vers un domaine externe est remplacée par un fichier servi depuis le même serveur que le reste du site.

Le responsive et l'édition de patterns gagnent en maturité

Au-delà des blocs individuels, WordPress 7.0 travaille la notion de contrôle responsive et d'édition de patterns. Ces deux chantiers sont moins visibles mais ils changent profondément la façon de concevoir une page.

Le mode d'édition responsive

La visibilité des blocs peut désormais être conditionnée à la taille d'écran. Un bloc peut être affiché uniquement sur desktop, masqué sur mobile, ou l'inverse. Jusqu'ici, cela nécessitait du CSS personnalisé ou une extension comme Block Visibility. Désormais, c'est un réglage natif dans l'inspecteur de blocs.

Pour des scénarios classiques (un menu desktop différent du menu mobile, une image simplifiée sur petit écran, un bloc publicitaire masqué en mobile), l'économie en code et en extensions est significative.

L'édition de patterns et les modes Spotlight / Isolated

WordPress 7.0 introduit deux nouveaux modes d'édition pour les patterns et les éléments réutilisables. Le mode Spotlight isole visuellement le bloc sur lequel vous travaillez, en atténuant le reste de la page. Pratique pour se concentrer sur un pattern complexe sans se laisser distraire par le contexte.

Le mode Isolated Editor pousse la logique plus loin : il permet d'éditer un pattern synchronisé, un template part ou un élément de navigation dans un environnement dédié, sans voir la page qui l'utilise. Pour les équipes qui gèrent des sites avec beaucoup de patterns réutilisables, c'est un gain de lisibilité et d'efficacité.

Côté performance : le traitement média passe dans le navigateur

WordPress 7.0 introduit une optimisation technique qui passe sous le radar des utilisateurs finaux, mais qui a un impact réel sur la performance perçue et sur la charge serveur : le traitement média côté client.

Ce qui change

Jusqu'ici, quand vous téléversiez une image dans WordPress, le serveur générait plusieurs tailles intermédiaires (thumbnail, medium, large, et d'autres selon le thème), compressait l'image, et parfois la convertissait en WebP. Tout ce travail se faisait côté serveur, en PHP, au moment de l'upload. Sur un hébergement mutualisé modeste, le téléversement d'une photo haute résolution pouvait prendre plusieurs secondes et monopoliser les ressources.

WordPress 7.0 déplace une partie de ce traitement dans le navigateur de l'utilisateur. Le redimensionnement et la compression initiale se font côté client, avant même que l'image n'arrive sur le serveur. Le serveur reçoit des fichiers déjà prêts, ou dans des formats plus optimisés, et termine le travail sans avoir à faire le gros du calcul.

Ce que ça apporte concrètement

Pour les sites éditoriaux qui téléversent régulièrement des photos, le gain se joue sur plusieurs plans. La bande passante utilisée diminue (moins de données envoyées au serveur). Le temps perçu du téléversement devient plus court, surtout sur des connexions lentes. Et la charge serveur baisse, ce qui laisse plus de ressources disponibles pour servir les visiteurs.

WordPress 7.0 ouvre aussi la porte à l'utilisation de formats d'image plus modernes comme l'AVIF, qui offrent des taux de compression supérieurs au WebP. Combiné avec les Core Web Vitals et l'impact du temps de chargement sur le référencement naturel, le traitement média côté client est une évolution bienvenue, particulièrement pour les sites e-commerce et les blogs à fort volume de contenu visuel.

Pour les développeurs : Abilities API, blocs PHP-only et DataViews

La version 7.0 ne change pas que l'expérience utilisateur. Elle introduit plusieurs API qui modifient la façon de développer des extensions et des thèmes WordPress.

La Client Side Abilities API

L'Abilities API existait déjà côté serveur. Elle permet à une extension de déclarer des "capacités" (abilities) que d'autres extensions ou des agents IA peuvent découvrir et invoquer. WordPress 7.0 étend cette API côté client, dans le navigateur.

Pour un développeur, cela signifie qu'une extension peut exposer des capacités accessibles depuis l'interface utilisateur, la palette de commandes ou même depuis un agent IA qui interagit avec le site. Concrètement, une extension de formulaire peut déclarer une capacité "créer une nouvelle entrée", que la palette de commandes exposera comme une action directe.

Couplée au Web Client AI API, cette architecture pose les fondations d'agents IA qui agissent dans WordPress. Un assistant rédactionnel peut créer des brouillons, un assistant e-commerce peut modifier des stocks, un assistant d'optimisation SEO peut ajuster des metadata. La structure existe, reste à voir quelles extensions s'en empareront en premier.

Les blocs PHP-only auto-enregistrés

Créer un bloc WordPress personnalisé impliquait jusqu'ici un couplage avec JavaScript, React et un workflow de build. Le script create-block générait un squelette, le développeur écrivait du code dans src/, compilait, puis enregistrait le bloc côté PHP. Une procédure lourde pour des blocs simples.

WordPress 7.0 introduit l'enregistrement de blocs uniquement en PHP, avec génération automatique des contrôles de l'inspecteur à partir de la définition PHP du bloc. Pour un développeur qui a juste besoin d'un bloc dynamique (afficher les trois derniers articles d'une catégorie, insérer un encart de contact), la complexité s'effondre. L'idée : déclarer des attributs avec leur type directement dans l'appel à register_block_type, et laisser WordPress en déduire les champs de formulaire à afficher dans l'inspecteur.

register_block_type('mtom/articles-recents', [
    'render_callback' => 'mtom_render_articles_recents',
    'attributes' => [
        'nombre' => [
            'type' => 'integer',
            'default' => 3,
        ],
        'categorie' => [
            'type' => 'string',
            'default' => '',
        ],
    ],
]);

L'exemple ci-dessus illustre le principe, la forme exacte des annotations reste à confirmer dans la documentation finale de la 7.0. Pour les agences qui développent des blocs métier spécifiques à leurs clients, l'intérêt est clair : plus de workflow de build JavaScript à maintenir pour la majorité des cas simples, et un gain de temps considérable sur chaque nouveau bloc.

DataForm et DataViews

WordPress 7.0 fait évoluer DataViews et DataForm, les composants qui gèrent respectivement l'affichage et l'édition de données dans l'admin. DataForm gagne une disposition "détails", de nouveaux contrôles (combobox, adaptiveSelect), et un système de validation complet avec gestion des messages d'erreur. DataViews ajoute une disposition "activité" et pose les bases pour enregistrer des types tiers dans les versions futures.

Pour les développeurs qui construisent des interfaces d'administration personnalisées, ces composants remplacent progressivement les anciennes listes WordPress héritées de WP_List_Table. Le passage n'est pas trivial, mais la direction est claire : l'ancien système disparaît, le nouveau devient la norme.

Block Bindings et patterns dynamiques

Imaginez un pattern "carte produit" réutilisé sur vingt pages, chacune devant afficher un produit distinct. Jusqu'en 7.0, deux options : dupliquer le pattern vingt fois en variante, ou écrire du PHP pour injecter les bonnes données au rendu. Les Block Bindings étendus dans WordPress 7.0 ouvrent une troisième voie, sans duplication ni code personnalisé.

L'attribut du bloc Image se lie au champ "image_produit", le Heading au champ "nom_produit", le Paragraph au champ "description". WordPress substitue les valeurs au rendu et le même pattern s'adapte automatiquement à la page où il est placé. L'extension ACF avait popularisé ce type de mécanique, mais imposait son propre cadre d'abstraction. Avec les Block Bindings élargis aux blocs dynamiques personnalisés, la logique passe dans le Core et devient portable d'un site à l'autre, sans dépendance à une extension tierce.

Quand 7.0 arrive et comment préparer votre site

WordPress suit un cycle de releases majeures planifiées, avec en général trois versions majeures par an. La 6.9 est sortie fin 2025, la 7.0 suivait normalement en avril 2026, et les 7.1 et 7.2 sont projetées respectivement sur août 2026 et décembre 2026. Cette cadence permet aux hébergeurs, aux auteurs d'extensions et aux agences d'anticiper les migrations.

Pour 7.0 spécifiquement, le calendrier initial prévoyait une sortie début avril 2026. L'équipe Core a choisi de prendre quelques semaines supplémentaires pour finaliser la stabilité de la collaboration en temps réel, en particulier la couche de stockage et les mécanismes d'invalidation de cache qui synchronisent les modifications entre utilisateurs. Un calendrier révisé est publié par l'équipe Core sur le blog officiel make.wordpress.org/core et tient compte de ces ajustements.

Quelle que soit la date finale, préparer un site à une mise à jour majeure suit les mêmes étapes.

Auditer vos extensions

Chaque mise à jour majeure peut casser la compatibilité avec certaines extensions. Listez les extensions actives avant la migration, vérifiez pour chacune que l'auteur a confirmé la compatibilité avec WordPress 7.0, regardez le champ "Testé jusqu'à" dans sa page. Une extension non mise à jour depuis deux ans est un signal d'alerte, quelle que soit la version cible.

Cet audit gagne à s'inscrire dans la durée. Un simple tableau tenu à jour avec le nom, le rôle, l'auteur, la fréquence de mise à jour et la criticité de chaque extension transforme chaque migration en revue méthodique au lieu d'une découverte improvisée. Les extensions orphelines ou redondantes, repérées à cette occasion, sont des candidates naturelles à la désinstallation. Moins d'extensions, c'est moins de surface d'attaque, moins de conflits potentiels et un back-office plus rapide. Une bonne migration commence toujours par un ménage.

Tester sur un environnement de préproduction

Clonez votre site sur un environnement de préproduction, appliquez-y la mise à jour, vérifiez que tout fonctionne avant de migrer la production. La plupart des hébergeurs WordPress proposent cette fonctionnalité en un clic. WordPress Playground, accessible depuis playground.wordpress.net, fait même tourner WordPress 7.0 directement dans le navigateur sans toucher à votre site.

Un test utile ne se limite pas à l'affichage de la page d'accueil. Parcourez les formulaires de contact, passez une commande sur la boutique, créez un utilisateur test, déclenchez un paiement en mode sandbox, vérifiez les emails transactionnels. Les régressions se cachent presque toujours dans les parcours transactionnels, pas dans l'affichage statique.

Vérifiez aussi le back-office : édition de pages, publication d'articles, gestion des médias, fonctionnement des éventuels constructeurs comme Bricks Builder ou Elementor. Un fichier de liste de contrôle, tenu une fois et réutilisé à chaque migration, vaut bien plus qu'une mémoire fiable.

Prévoir une sauvegarde complète

Une sauvegarde complète (fichiers et base de données) doit exister avant toute mise à jour majeure. UpdraftPlus, BackupBuddy, Jetpack Backup ou les sauvegardes automatiques fournies par l'hébergeur font le travail. En cas de problème pendant la mise à jour, la restauration ramène le site à son état initial en quelques minutes.

Deux pièges classiques méritent d'être signalés. Le premier : la sauvegarde stockée uniquement sur le même serveur que le site, perdue le jour où le serveur est compromis ou tombe en panne. Les bonnes configurations envoient automatiquement les archives vers un stockage tiers (Dropbox, Google Drive, Amazon S3, un espace dédié chez un autre hébergeur). Le second, plus fréquent qu'il y paraît : une sauvegarde qui échoue silencieusement depuis des semaines. Vérifiez la date de la dernière sauvegarde effectivement réussie avant de lancer la mise à jour, pas la dernière tentative.

Attendre les premières mises à jour mineures si votre site est critique

Pour un site e-commerce en pleine campagne ou un site institutionnel à fort trafic, notre règle est simple : attendre la 7.0.1 ou 7.0.2. Les mises à jour mineures corrigent les bugs remontés par les sites qui ont migré en premier, et les trois ou quatre premières semaines après une sortie majeure concentrent l'essentiel des incidents. Une migration différée de trois semaines ne perd rien en fonctionnalités et gagne en stabilité.

Pour un site vitrine classique, le calcul change. Le risque d'incident reste faible si le site est à jour et bien maintenu, et le coût d'une indisponibilité temporaire est limité. La décision tient donc moins à la dangerosité technique de la mise à jour qu'à la tolérance au risque du projet. Chez MtoM Création, nos clients e-commerce attendent systématiquement la 7.x.1, nos clients en vitrine passent en général plus rapidement.

Ce qu'il faut retenir de 7.0

WordPress 7.0 n'est pas une mise à jour cosmétique. Elle introduit trois chantiers structurants : la collaboration en temps réel, l'IA native via le Web Client AI API et un traitement média modernisé. Pour les équipes éditoriales, elle rapproche WordPress des outils collaboratifs modernes. Pour les développeurs, elle simplifie la création de blocs et pose les bases d'agents IA intégrés au CMS. Pour les propriétaires de site, elle enrichit la boîte à outils native sans alourdir le code.

Le passage à 7.0 ne demande pas de stress particulier si votre site est bien maintenu. Les extensions à jour suivent, les thèmes récents s'adaptent et les nouvelles fonctionnalités sont opt-in dans leurs premières itérations. C'est l'occasion de faire le ménage dans les extensions inutilisées, d'auditer les performances de votre site et de vous assurer que votre maintenance WordPress est bien en place.

Chez MtoM Création, nous suivons ces évolutions de près pour accompagner nos clients dans leurs mises à jour et leur permettre d'exploiter les nouvelles fonctionnalités quand elles servent réellement leur projet. Une fonctionnalité intéressante n'est utile que si elle s'intègre à votre manière de travailler, pas si elle complique votre quotidien pour le plaisir de suivre la nouveauté.