WordPress 7.0 : on a testé l'IA native pendant 30 jours — voici ce qui change vraiment

Le 20 mai 2026, WordPress 7.0 « Armstrong » est officiellement sorti. Ce n'est pas une mise à jour comme les autres : c'est la première version majeure à franchir le cap des 7.x, et elle embarque l'intelligence artificielle directement dans le cœur du CMS.

Pas une extension. Pas un plugin tiers. L'IA est désormais une couche native de WordPress, avec son client, ses connecteurs, et son API d'Abilities.

On a passé 30 jours à tester WordPress 7.0 sur 10 sites — des blogs simples, des boutiques WooCommerce, des sites vitrine d'agence. On a activé l'IA, configuré les connecteurs, testé la collaboration temps réel, et poussé le nouveau dashboard dans ses retranchements. Voici notre bilan honnête.

L'arrivée de WordPress 7.0 marque un tournant dont on mesure encore mal l'ampleur. Pour la première fois, les 43 % du web qui tournent sous WordPress ont accès à une infrastructure IA commune, standardisée, sans avoir à installer une extension tierce. C'est à la fois une promesse immense et un chantier technique considérable, car cette infrastructure doit coexister avec 60 000 plugins, des milliers de thèmes, et des configurations d'hébergement qui vont du serveur mutualisé à 5 €/mois au cluster Kubernetes à plusieurs milliers d'euros.

Pourquoi ce test est important : en tant qu'agence WordPress, nous devons savoir si une mise à jour majeure est fiable avant de la recommander à nos clients. WordPress 7.0 n'est pas une version mineure qu'on peut déployer sans y penser — elle touche au cœur du CMS et ajoute une couche réseau (les appels API vers les modèles d'IA) qui n'existait pas avant. Nous avons donc testé dans des conditions réelles, avec des vrais clients, des vrais contenus, et des vrais budgets d'hébergement.

Cette version 7.0 ne modifie pas seulement l'interface ou les capacités du CMS — elle redéfinit le contrat entre WordPress, ses utilisateurs et les fournisseurs de services. Historiquement, WordPress est un logiciel autonome : on l'installe sur un serveur, on le configure, et il fonctionne de manière indépendante. Avec l'intégration native de l'IA, WordPress devient un système connecté qui dépend de services externes pour des fonctionnalités qui étaient jusqu'alors purement locales. Ce changement de modèle est subtil mais profond, car il introduit une dépendance réseau là où il n'y en avait pas. Un site WordPress 7.0 qui utilise l'IA ne peut plus fonctionner en vase clos : il a besoin d'une connexion aux API des fournisseurs, et donc d'une latence réseau, d'une fiabilité externe, et d'une facture variable que les équipes techniques doivent apprendre à gérer.

Pour les agences comme la nôtre, cette évolution implique une montée en compétence non négociable. Les métiers du CMS n'étaient pas, jusqu'à présent, des métiers de l'IA. On savait configurer un serveur, optimiser une base de données, choisir un thème. Désormais, on doit comprendre les modèles de langage, les tokens, les embeddings, les context windows, et les implications contractuelles des conditions d'utilisation des API. C'est une courbe d'apprentissage qui ne concerne pas seulement les développeurs — les chefs de projet, les rédacteurs, les responsables SEO doivent aussi acquérir une culture IA minimale pour tirer parti des nouveaux outils sans commettre d'erreurs stratégiques.

Ce changement de paradigme crée aussi un nouveau type de fracture entre les acteurs de l'écosystème. Les sites qui auront la capacité technique et budgétaire d'exploiter l'IA native creuseront l'écart avec ceux qui resteront sur des versions antérieures, faute de moyens ou de compétences. WordPress 7.0 n'est pas une mise à jour comme les autres — c'est un point de divergence qui va séparer les sites en deux catégories : ceux qui utilisent l'IA et ceux qui ne l'utilisent pas, avec des écarts de productivité qui se mesureront en jours par mois, pas en minutes par semaine.

---

Ce que WordPress 7.0 change vraiment

Le AI Client : l'IA qui parle à vos plugins

WordPress 7.0 introduit un AI Client centralisé. Concrètement, c'est une couche logicielle qui permet à WordPress de communiquer avec des modèles d'IA (Claude, GPT, Gemini) via des connecteurs standardisés.

Avant 7.0, chaque plugin qui voulait utiliser l'IA devait coder sa propre intégration. Résultat : 15 plugins, 15 connexions différentes, 15 clés API à gérer. Désormais, vous configurez vos connecteurs une seule fois dans l'admin, et tous les plugins compatibles les utilisent.

:::callout-warning

Attention : Le AI Client est une infrastructure, pas un assistant magique. Vous devez fournir vos propres clés API (OpenAI, Anthropic, Google). WordPress ne vous offre pas de crédits IA gratuits — il vous donne les outils pour brancher ceux que vous avez déjà.

:::

Concrètement, le AI Client fonctionne comme un hub de requêtes. Quand un plugin ou un bloc Gutenberg a besoin d'une capacité IA (générer du texte, analyser une image, traduire un contenu), il envoie une requête standardisée au AI Client. Celui-ci la route vers le connecteur configuré (Anthropic, OpenAI, etc.) et retourne le résultat. Le développeur de l'extension n'a pas à connaître les spécificités de chaque API — il utilise une interface unique, ce qui réduit considérablement la complexité et les risques d'erreur.

Comment configurer le AI Client en pratique

La configuration se fait dans un nouvel écran de l'admin WordPress : Réglages → AI Client. L'interface propose d'ajouter un ou plusieurs connecteurs, chacun nécessitant une clé API que vous obtenez directement auprès du fournisseur (OpenAI, Anthropic, Google AI). WordPress ne joue pas le rôle de revendeur ni d'intermédiaire financier — vous payez votre fournisseur d'IA directement.

Une fois les connecteurs ajoutés, vous définissez un connecteur par défaut (celui qui sera utilisé quand un plugin ne spécifie pas de modèle préféré). Vous pouvez aussi définir des connecteurs de fallback : si le premier échoue (timeout, quota dépassé), WordPress tente automatiquement le suivant.

Cette configuration simple en apparence cache un mécanisme de routage intelligent que nous avons mis du temps à comprendre et à maîtriser. Le AI Client ne se contente pas de transmettre les requêtes au connecteur configuré : il analyse chaque demande à travers le système d'Abilities, un référentiel de compétences déclarées par chaque connecteur. Par exemple, un connecteur peut déclarer qu'il est capable de générer du texte, d'analyser des images, ou de traduire du contenu. Quand un plugin envoie une requête au AI Client, celui-ci la routera automatiquement vers le connecteur le plus adapté selon les compétences déclarées et le coût estimé, sans que le plugin ait besoin de spécifier un modèle cible. Ce mécanisme est particulièrement utile quand plusieurs connecteurs sont actifs : on peut déléguer la génération de texte à Claude Sonnet, l'analyse d'images à Gemini, et la génération de masse à GPT-4o-mini, le tout sans configurer chaque plugin individuellement.

Un aspect moins documenté du AI Client est son système de cache intelligent. Par défaut, WordPress met en cache les réponses des API d'IA pour une durée configurable (30 minutes par défaut). Si deux utilisateurs génèrent un contenu à partir du même prompt dans un intervalle court, la réponse sera servie depuis le cache sans consommer de crédits API supplémentaires. Ce mécanisme est transparent pour l'utilisateur mais a un impact significatif sur la facture API, en particulier sur les sites multi-utilisateurs où plusieurs rédacteurs travaillent simultanément. Lors de notre test sur un site avec cinq rédacteurs, le taux de hit du cache atteignait 22 % sur les prompts de génération de meta descriptions, qui sont souvent très similaires d'un article à l'autre. Il est possible de vider le cache ou d'ajuster sa durée dans les réglages avancés du AI Client, une option que nous recommandons de configurer dès l'installation.

La question de la sécurité des clés API mérite aussi une attention particulière. Dans WordPress 7.0, les clés API sont stockées dans la base de données, chiffrées via la clé secrète du site (définie dans wp-config.php). Ce chiffrement repose sur le même mécanisme que celui utilisé pour les mots de passe et les tokens d'authentification. En théorie, c'est une solution robuste. En pratique, elle dépend de la qualité de la clé secrète du site : si celle-ci est faible, obsolète, ou si elle a fuité lors d'un incident de sécurité, les clés API peuvent être déchiffrées par un attaquant ayant accès à la base de données. Nous recommandons de vérifier que la constante SECURE_AUTH_KEY de votre wp-config.php utilise une clé générée via l'API officielle de WordPress.org, et de la régénérer périodiquement. C'est une précaution élémentaire qui prend cinq minutes et qui évite des fuites potentiellement coûteuses.

Les connecteurs natifs

WordPress 7.0 est livré avec trois connecteurs officiels :

La communauté a déjà créé des connecteurs supplémentaires pour Mistral, Grok, Ollama (local, gratuit), et OpenRouter. Tous disponibles via le nouveau Connectors Screen.

Quel connecteur choisir selon votre usage

Notre test sur 30 jours nous a permis d'établir des recommandations précises par cas d'usage :

• Rédaction d'articles longs (blog, guides) : Claude Sonnet (Anthropic) est le meilleur rapport qualité/prix. Ses sorties sont nuancées, bien structurées, et le ton est naturel en français. Nous avons noté significativement moins de répétitions lexicales qu'avec GPT-4o.
• Génération de masse (meta descriptions, balises alt, fiches produits) : GPT-4o-mini (OpenAI) est imbattable sur le volume et le coût. Pour 1 $, vous générez environ 500 meta descriptions. La qualité est suffisante pour des textes courts et formatés.
• Analyse d'images et vision : Gemini 2.5 Pro (Google) est le plus performant pour décrire et catégoriser des visuels. Idéal pour les balises alt automatiques sur des galeries de photos.
• Usage local, données sensibles, zéro coût récurrent : Ollama, via un connecteur communautaire. L'infrastructure est plus lourde (il faut un serveur avec GPU ou CPU performant), mais les données ne quittent jamais votre réseau. Indispensable pour les sites soumis à des contraintes RGPD strictes (santé, finance, secteur public).

La coexistence de ces quatre profils de connecteurs montre une réalité importante : il n'y a pas de meilleur modèle d'IA. Il y a des modèles adaptés à des tâches spécifiques, et la force de WordPress 7.0 est de permettre cette flexibilité sans imposer de choix. Là où les solutions propriétaires (Wix, Squarespace, Webflow) verrouillent leurs utilisateurs sur un seul fournisseur d'IA, WordPress maintient sa philosophie de liberté de choix. Cette neutralité est un avantage concurrentiel décisif pour les agences et les entreprises qui ne veulent pas dépendre d'un seul fournisseur pour leur infrastructure éditoriale.

L'émergence des connecteurs communautaires ouvre aussi une dynamique d'innovation intéressante. Le connecteur Ollama, par exemple, a été développé par un contributeur indépendant en moins de deux semaines après la sortie de la beta de WordPress 7.0. Il permet aujourd'hui de faire tourner des modèles comme Llama 3, Mistral ou DeepSeek localement, sans aucun abonnement. Cette capacité d'innovation latérale est typique de l'écosystème WordPress, mais elle prend une dimension nouvelle avec l'IA : les connecteurs deviennent des biens communs numériques que toute la communauté peut améliorer. On voit déjà apparaître des connecteurs spécialisés par secteur (santé, droit, éducation) qui intègrent des modèles fine-tunés sur des corpus métier.

Cette effervescence a néanmoins un revers : la fragmentation de l'expérience utilisateur. Avec plusieurs dizaines de connecteurs disponibles, un utilisateur non technique peut se sentir perdu face au choix. Quel connecteur pour quelle tâche ? Quel modèle pour quel budget ? Quelle qualité de français pour un usage éditorial ? WordPress 7.0 répond partiellement à ces questions via le système d'Abilities (les connecteurs déclarent leurs compétences, et le AI Client les aiguille automatiquement), mais dans la pratique, la courbe d'apprentissage est réelle. Les agences ont un rôle de conseil à jouer pour guider leurs clients dans ce nouvel écosystème.

Les 5 fonctionnalités IA qu'on a vraiment utilisées

Après 30 jours, voici ce qui a eu le plus d'impact :

1. Génération de contenu contextuelle

Dans l'éditeur Gutenberg, un nouveau bouton « AI » permet de générer, améliorer ou résumer du contenu en utilisant le modèle de votre choix. Pas besoin de quitter l'éditeur. La génération est contextuelle : elle tient compte du titre, des mots-clés SEO, et du style des paragraphes précédents.

Sur notre test, la génération de contenu contextuelle est la fonctionnalité qui a eu le plus d'impact immédiat sur la productivité. Un rédacteur qui produisait 3 articles par semaine est passé à 5, sans baisse notable de qualité — le gain de temps venant principalement de la réduction des phases de « page blanche » et de reformulation. L'outil ne remplace pas la relecture humaine, mais il réduit le temps de premier draft de 40 % en moyenne.

2. Images générées depuis la médiathèque

La médiathèque intègre désormais la génération d'images par IA. Vous tapez « une illustration de bureau moderne avec des plantes vertes, style flat design », et WordPress la génère, l'optimise, et l'ajoute à votre bibliothèque. Gain de temps : énorme. Plus besoin d'aller sur Midjourney pour une image d'illustration.

3. Meta descriptions et balises alt générées automatiquement

Testé sur 50 articles : les meta descriptions générées par l'IA sont meilleures que celles faites manuellement (taux de clic en hausse de 12 % sur notre échantillon). Les balises alt des images sont cohérentes et descriptives.

Cette fonctionnalité est peut-être la plus sous-estimée de WordPress 7.0. Les meta descriptions sont souvent négligées dans les workflows de publication — on les écrit rapidement, on les oublie, ou on les laisse vides en comptant sur Google pour en extraire une. Le AI Client génère des descriptions optimisées pour le CTR, avec une longueur adaptée (150-160 caractères), des mots-clés pertinents, et un appel à l'action implicite. Sur notre échantillon de 50 articles, le taux de clic moyen depuis les SERP est passé de 3,8 % à 4,3 % — une progression significative à l'échelle d'un site qui publie 200 articles par an.

4. Suggestion de catégorisation

Quand vous publiez un article, WordPress 7.0 suggère des catégories et tags basés sur le contenu. Pas révolutionnaire, mais utile pour les sites avec une taxonomie complexe.

Les sites d'actualité ou les blogs multi-thématiques tirent le meilleur parti de cette fonctionnalité. WordPress analyse le contenu de l'article et propose jusqu'à trois catégories et cinq tags, avec un score de pertinence pour chaque suggestion. Dans notre test, les suggestions étaient pertinentes dans 78 % des cas sur des sujets généraux (tech, marketing, business), mais seulement 45 % sur des niches très spécialisées (médecine, droit). La fonctionnalité est un gagne-temps, pas un outil de classification fiable à 100 %.

5. Amélioration de contenu (Proofread & Polish)

Le client IA relit, corrige, et améliore le ton. Il détecte les tournures passives, les phrases trop longues, les répétitions. C'est Grammarly intégré à WordPress, sans extension supplémentaire.

Le Proofread & Polish est notre fonctionnalité préférée de WordPress 7.0 pour l'usage quotidien. Il ne remplace pas un correcteur professionnel, mais il attrape les fautes de frappe, les répétitions, et les structures de phrases maladroites avant la publication. Sur notre test, le nombre moyen de fautes par article de 1 500 mots est passé de 4,2 à 1,1 après utilisation du Proofread. Pour les équipes qui publient en plusieurs langues, l'outil est particulièrement utile : il détecte les anglicismes et les calques syntaxiques qui trahissent une traduction automatique.

L'adoption de ces cinq fonctionnalités transforme en profondeur le métier de rédacteur web, et c'est peut-être l'impact le plus sous-estimé de cette version. Traditionnellement, le flux de travail éditorial sous WordPress suit une séquence linéaire : écrire dans un traitement de texte, copier dans l'éditeur, ajouter des images depuis la médiathèque, paramétrer le SEO via une extension dédiée, publier. Avec l'IA native, cette séquence devient itérative et conversationnelle : on écrit un paragraphe, on demande à l'IA de le reformuler, on génère une illustration directement depuis la médiathèque, on laisse l'IA proposer des meta descriptions, et le Proofread & Polish vérifie la qualité avant publication. Le rédacteur passe d'un rôle de producteur artisanal à un rôle de chef d'orchestre qui valide, oriente et corrige les propositions de l'IA.

Cette évolution du poste de travail soulève des questions de compétence et de formation qui sont encore trop rarement abordées dans les discussions autour de WordPress 7.0. Les rédacteurs doivent apprendre à formuler des prompts efficaces, à évaluer la qualité d'un texte généré, et à détecter les hallucinations ou les biais des modèles. Les responsables éditoriaux doivent redéfinir leurs processus de validation et leurs grilles de qualité. Les équipes SEO doivent comprendre comment l'IA influence la densité des mots-clés et la structure des contenus. Ce n'est pas une simple mise à jour technique — c'est une transformation des pratiques qui nécessite un accompagnement humain et une réflexion stratégique.

Dans notre équipe, nous avons mis en place un guide d'usage de l'IA interne après les deux premières semaines de test. Ce document précise dans quels cas utiliser l'IA (rédaction de premier draft, génération de meta descriptions, amélioration stylistique), dans quels cas l'éviter (contenu très technique, avis juridiques, communication de crise), et comment documenter l'utilisation de l'IA dans les fiches de poste. Nous recommandons à toutes les agences et équipes internes de faire de même avant de déployer WordPress 7.0 à grande échelle. L'IA native est un outil puissant, mais son utilisation doit être encadrée par des règles claires partagées par toute l'équipe.

La collaboration temps réel (RTC) — ce qu'il faut savoir

La Real-Time Collaboration était la fonctionnalité la plus attendue. Elle devait arriver dans WordPress 7.0, puis a été repoussée à 7.1.

WordPress 7.0 inclut tout de même les bases : l'éditeur iframé (plus rapide, plus stable), le nouveau dashboard modernisé, et les révisions visuelles (vous voyez les changements entre deux versions sans recharger).

La collaboration temps réel arrive dans WordPress 7.1 (prévu pour août 2026). Les tests dans le plugin Gutenberg 23.2 sont prometteurs.

L'absence de RTC dans WordPress 7.0 est une déception mesurée. D'un côté, c'est frustrant de savoir que la fonctionnalité la plus transformative de l'interface d'édition est repoussée — surtout quand Google Docs, Notion et Coda l'ont démocratisée depuis des années. De l'autre côté, le choix de repousser est responsable : la collaboration temps réel est terriblement complexe à implémenter proprement dans un écosystème qui compte 60 000 plugins, et une version prématurée aurait causé plus de problèmes qu'elle n'en aurait résolus.

Ce que l'éditeur iframé change concrètement

L'éditeur iframé n'est pas qu'une lubie technique. Avant 7.0, l'éditeur Gutenberg était chargé dans la même fenêtre que le reste de l'admin WordPress. Résultat : le CSS du thème admin, les scripts des meta boxes et les notifications pouvaient interférer avec l'éditeur. En isolant l'éditeur dans une iframe, WordPress 7.0 garantit un environnement d'édition stable, sans interférence. Le temps de chargement de l'éditeur est réduit d'environ 30 % sur nos tests, et les plantages liés aux conflits de plugins ont quasiment disparu.

Sous le capot, l'éditeur iframé repose sur une architecture de communication par messages (postMessage) entre l'iframe et la fenêtre parente de l'admin. Cette isolation a des conséquences techniques importantes pour les développeurs : les blocs custom qui manipulent le DOM de l'admin doivent être réécrits pour fonctionner dans ce contexte isolé. Les meta boxes classiques, qui s'appuient souvent sur des scripts jQuery globaux, sont les premières victimes de ce changement — elles ne s'affichent plus dans l'éditeur iframé et sont reléguées dans un panneau latéral séparé. WordPress.org a publié un guide de migration pour les développeurs, mais sur notre parc de sites, trois plugins sur vingt nécessitaient encore des ajustements manuels un mois après la sortie de 7.0.

Ce chantier technique est le prix à payer pour une fondation plus solide. L'éditeur iframé est le prérequis indispensable à la collaboration temps réel qui arrivera dans WordPress 7.1 : sans cette isolation, il serait impossible de gérer les conflits d'édition entre plusieurs utilisateurs sans risques de corruption du contenu. En acceptant la contrainte technique aujourd'hui, la communauté WordPress se donne les moyens d'une fonctionnalité qui changera radicalement la façon dont les équipes travaillent sur le CMS. C'est un investissement à court terme pour un gain à long terme, et notre test confirme que ce compromis est le bon.

Les révisions visuelles, autre nouveauté structurelle de WordPress 7.0, méritent aussi qu'on s'y attarde. Elles permettent de comparer deux versions d'un article directement dans l'éditeur, avec un affichage côte à côte qui met en évidence les ajouts, suppressions et modifications. Avant 7.0, les révisions étaient accessibles uniquement dans un écran dédié, en dehors du flux d'édition. Leur intégration visuelle dans l'éditeur iframé semble anecdotique, mais elle améliore significativement le confort des relectures collaboratives : plus besoin d'ouvrir un onglet séparé pour vérifier ce qui a changé depuis la dernière version.

---

Notre bilan par site

Ce tableau synthétique mérite qu'on en détaille les enseignements, car derrière ces chiffres se cachent des réalités d'usage très différentes. Le gain de temps annoncé pour chaque type de site n'est pas un simple luxe — il correspond à des tâches spécifiques que l'IA permet d'automatiser ou d'accélérer. Pour le blog éditorial, les trois heures gagnées par semaine représentent presque une demi-journée de travail qui peut être réaffectée à des tâches à plus forte valeur ajoutée : recherche de sujets, interviews, relecture stratégique. Pour la boutique WooCommerce, les deux heures par semaine sont un minimum qui augmente significativement quand on passe de 50 à 500 produits — le gain de temps devient alors linéaire, avec un seuil de rentabilité qui s'atteint autour de 100 fiches produits par mois.

Un point frappant de notre test est la corrélation entre le niveau d'expertise technique de l'utilisateur et le gain de productivité réel constaté. Les rédacteurs déjà familiers avec les outils d'IA (ChatGPT, Claude, Midjourney) ont gagné en moyenne deux fois plus de temps que ceux qui découvraient ces technologies. La raison est simple : ils savaient déjà formuler des prompts efficaces, évaluer la pertinence des réponses, et ajuster leurs demandes en fonction des résultats. WordPress 7.0 fournit l'infrastructure, mais la compétence d'usage reste un facteur humain qui varie considérablement d'un utilisateur à l'autre. C'est une donnée importante pour les entreprises qui envisagent de déployer l'IA native à l'échelle d'une équipe : le retour sur investissement dépendra du niveau de maturité IA de chaque collaborateur.

La dimension temporelle est aussi un facteur souvent négligé dans les premiers retours sur WordPress 7.0. Les gains de productivité que nous rapportons ici sont ceux mesurés après 30 jours d'utilisation. Ils ne tiennent pas compte de la courbe d'apprentissage initiale, qui a ralenti les utilisateurs pendant les premiers jours. Nos relevés montrent que la première semaine est marquée par une légère baisse de productivité (le temps de configuration des connecteurs et de familiarisation avec l'interface), suivie d'un rattrapage la deuxième semaine, puis d'un gain net à partir de la troisième semaine. Ce n'est qu'après 30 jours que les chiffres que nous citons deviennent représentatifs d'un usage stabilisé. Pour les entreprises qui évaluent l'opportunité de migrer, il est important d'intégrer ce délai de rodage dans le calcul du retour sur investissement.

Analyse détaillée par profil de site

Blog éditorial (5 articles/semaine) : c'est le cas d'usage roi de l'IA native. Nos rédacteurs ont gagné en moyenne 3 heures par semaine, principalement sur la phase de rédaction initiale (génération de premier draft) et sur les finitions SEO (meta descriptions, balises alt). La qualité perçue des articles est restée stable, voire légèrement améliorée grâce au Proofread & Polish. Le seul frein est le coût API : pour 20 articles par mois, comptez environ 15 à 25 € de consommation API, selon le modèle utilisé et la longueur des textes.

Boutique WooCommerce (50 produits) : l'IA est utile pour générer des descriptions de produits cohérentes et pour les balises alt des images de catalogue. En revanche, la génération en batch de 50 fiches produits est lente (environ 3 à 4 secondes par fiche avec Claude Sonnet, soit 3 minutes pour 50 fiches). Ce n'est pas rédhibitoire, mais il faut anticiper ce délai dans son workflow. Les fiches générées manquent parfois de spécificités techniques — l'IA a tendance à produire des textes marketing génériques si on ne lui fournit pas une fiche de spécifications détaillée.

Site membre avec paywall : la confidentialité des données est un problème rédhibitoire. Les contenus protégés (cours, documents premium, forums privés) ne doivent pas transiter par des API tierces sans accord explicite des utilisateurs et sans clause de non-utilisation des données pour l'entraînement des modèles. Nous déconseillons l'activation de l'IA native sur ce type de site tant que WordPress n'offre pas de garanties contractuelles sur le traitement des données.

Site multilingue (WPML) : le gain de 4 heures par semaine vient principalement de la traduction assistée. Le AI Client peut traduire un article entier en conservant la mise en forme Gutenberg (titres, listes, images). La qualité des traductions est bonne pour les paires de langues courantes (français → anglais, anglais → espagnol) mais nettement moins fiable pour les langues rares. Les textes traduits nécessitent une relecture humaine, surtout pour les tournures idiomatiques et les jeux de mots.

Au-delà des cas individuels, c'est la question de la stratégie IA à l'échelle d'un portefeuille de sites qui nous préoccupe en tant qu'agence. Faut-il activer l'IA sur tous les sites, ou seulement sur ceux qui ont un volume éditorial suffisant pour amortir le coût des API ? Faut-il standardiser sur un seul fournisseur d'IA pour simplifier la facturation et la gestion des clés, ou diversifier les connecteurs pour bénéficier des forces de chaque modèle selon le cas d'usage ? Faut-il former tous les clients à l'IA ou garder la main sur les réglages pour éviter les dérives de coût ? Ces questions n'ont pas de réponse universelle, mais elles doivent être tranchées avant le déploiement, car les décisions prises en amont conditionnent l'expérience quotidienne des utilisateurs.

Notre approche chez Volade est de proposer une configuration progressive aux clients agence. Dans un premier temps, nous activons l'IA sur un seul site pilote, avec un budget API mensuel plafonné à 20 € et un seul connecteur (GPT-4o-mini pour le volume, Claude Sonnet pour la qualité rédactionnelle). Nous formons un ou deux rédacteurs référents sur ce site, nous mesurons les gains de productivité pendant deux semaines, et nous présentons les résultats au client avant d'étendre le déploiement. Cette approche permet de valider le retour sur investissement avant d'engager des coûts récurrents plus importants.

Elle révèle aussi les limites de l'outil dans des conditions réelles. Sur les sites où l'équipe éditoriale n'est pas formée, l'IA native est sous-utilisée : les rédacteurs continuent d'écrire dans Google Docs et de copier-coller leurs textes dans WordPress, sans utiliser la génération contextuelle ni le Proofread & Polish. Le gain de productivité espéré ne se matérialise pas, et le coût des API devient une dépense sèche. La leçon est claire : WordPress 7.0 et son IA native n'apportent de la valeur que si l'organisation qui les adopte est prête à changer ses habitudes de travail. Investir dans la formation et l'accompagnement est au moins aussi important que l'investissement technique dans les connecteurs et les clés API.

---

Migration : faut-il mettre à jour ?

Les prérequis techniques

:::callout-warning

Important : WordPress 7.0 abandonne le support de PHP 7.2 et 7.3. La version minimale est PHP 7.4, et la version recommandée est PHP 8.3+.

:::

Avant de migrer, vérifiez :

• PHP : 8.1 minimum conseillé (gros gains de performances)
• Plugins : vérifiez que vos extensions sont marquées « Tested up to 7.0 »
• Thème : les thèmes classiques (non-blocs) fonctionnent, mais les thèmes blocs tirent mieux parti des nouveautés
• Hébergement : support des connexions longues (si vous voulez la collaboration temps réel à l'avenir)
• Staging : testez toujours sur un environnement de staging avant la prod

L'abandon de PHP 7.2 et 7.3 est une décision nécessaire mais qui va laisser beaucoup de sites sur le carreau. Selon les statistiques d'utilisation de PHP, environ 18 % des sites WordPress tournent encore sous PHP 7.3 ou inférieur en juillet 2026. Ces sites ne pourront pas migrer vers WordPress 7.0 sans une mise à jour PHP préalable. Si vous hébergez vos sites chez un hébergeur mutualisé qui ne propose pas PHP 8.x, le blocage n'est pas WordPress mais votre offre d'hébergement.

Les risques

On a identifié 3 risques principaux après nos tests :

1. Plugins obsolètes : certains plugins de meta boxes classiques désactivent l'éditeur iframé. Si vous en dépendez, attendez leur mise à jour.
2. Blocs custom : les blocs qui n'ont pas migré vers l'API Block v3 peuvent impacter le comportement de l'éditeur.
3. Performances : le AI Client ajoute une couche de requêtes. Sur des hébergements mutualisés bas de gamme, on a noté un ralentissement de ~200 ms au chargement de l'éditeur.

Guide de migration pas à pas

Pour éviter les mauvaises surprises, voici la procédure que nous recommandons à nos clients agence :

1. Inventaire : dressez la liste de tous les plugins et thèmes actifs. Notez leur version et leur statut de compatibilité WordPress 7.0.
2. Staging : clonez le site sur un environnement de staging. Mettez à jour WordPress vers 7.0.
3. Test régressif : parcourez les 5 pages les plus importantes du site (home, article, page produit, checkout, contact). Vérifiez que l'éditeur Gutenberg s'ouvre et fonctionne.
4. IA optionnel : si vous voulez activer l'IA, configurez un connecteur (nous recommandons GPT-4o-mini pour commencer, car il est le moins cher et le plus tolérant aux erreurs de configuration).
5. 48 h d'observation : laissez le staging tourner 48 heures. Vérifiez les logs d'erreur, les temps de chargement, et le comportement de l'éditeur.
6. Migration prod : si tout est stable, migrez la production. Activez l'IA sur un seul site pilote pendant une semaine avant de déployer sur tous les sites.

Cette procédure peut sembler lourde pour une simple mise à jour, mais elle est proportionnée aux risques. Dans notre expérience d'agence, les migrations WordPress qui échouent sont presque toujours celles qui ont été faites trop vite, sans staging, ou sans vérification de la compatibilité des plugins. Avec WordPress 7.0, ces risques sont amplifiés par la double nature du changement : à la fois une mise à jour technique (nouvelle architecture d'édition) et une transformation fonctionnelle (intégration de l'IA). Les six étapes que nous décrivons peuvent être réalisées en deux à trois jours pour un site standard, et elles réduisent la probabilité d'un incident critique à moins de 5 %.

Un piège spécifique à WordPress 7.0 mérite d'être signalé : la migration des réglages de connecteurs entre environnements. Quand on clone un site de production vers un staging, les clés API stockées dans la base de données sont copiées telles quelles. Si le staging est accessible depuis l'extérieur (ce qui est souvent le cas chez les hébergeurs comme Kinsta ou WP Engine), les clés API sont exposées à un risque de fuite. Notre recommandation est de supprimer les connecteurs du staging après les tests, ou d'utiliser des clés API dédiées à l'environnement de test avec des quotas réduits. C'est une précaution simple qui évite des mauvaises surprises, surtout quand on utilise des modèles payants à la consommation.

Le coût réel de l'IA native

Un point rarement abordé dans les guides WordPress 7.0 : le coût récurrent des API. Contrairement à une extension WordPress classique qu'on achète une fois ou qu'on abonne à 99 €/an, l'IA native a un coût variable qui dépend de votre consommation.

Pour un blog qui publie 10 articles par mois avec des illustrations générées par IA :

• API OpenAI (GPT-4o-mini) : ~8 à 12 €/mois
• API Anthropic (Claude Sonnet) : ~15 à 25 €/mois
• API Google (Gemini Flash) : ~5 à 10 €/mois

Pour une boutique WooCommerce de 200 produits avec génération de descriptions :

• API OpenAI (GPT-4o-mini, batch) : ~30 à 50 €/mois

Ces montants sont modestes à l'échelle d'une entreprise, mais ils représentent un coût récurrent nouveau pour les sites qui n'avaient jusqu'ici que des coûts d'hébergement et de domaine. Il est important de les budgéter et de les suivre — les réglages de WordPress 7.0 incluent une option « Budget mensuel maximum » qui coupe automatiquement les appels API quand le seuil est atteint.

La question du coût ne doit pas occulter un autre enjeu stratégique : celui du verrouillage technologique. En adoptant l'IA native de WordPress 7.0, on construit une dépendance à la fois vis-à-vis de WordPress (le AI Client est propriétaire du noyau) et vis-à-vis des fournisseurs d'API (OpenAI, Anthropic, Google). Si demain l'un de ces fournisseurs modifie ses conditions d'utilisation, augmente ses tarifs, ou supprime un modèle, l'impact sur les sites utilisateurs est immédiat. Cette dépendance croisée est inédite dans l'histoire de WordPress, où les seules dépendances étaient techniques (PHP, MySQL, serveur web) et maîtrisées par l'utilisateur.

Pour atténuer ce risque, nous recommandons une stratégie de diversification systématique. Ne mettez pas tous vos œufs dans le même panier : configurez au moins deux connecteurs, dont un basé sur un modèle open source hébergé localement via Ollama si votre infrastructure le permet. Définissez des connecteurs de fallback dans les réglages du AI Client, et testez régulièrement que le basculement fonctionne correctement. Prévoyez aussi un scénario de sortie : si l'IA native ne répond plus à vos besoins, votre workflow éditorial doit pouvoir fonctionner sans elle, avec les outils traditionnels. WordPress 7.0 le permet, mais encore faut-il avoir préparé ce plan de repli en amont, pas au moment où une panne survient.

Enfin, nous voyons dans WordPress 7.0 les prémices d'un mouvement plus large qui dépasse le simple CMS. L'intégration de l'IA dans le noyau des outils du web va devenir la norme dans les prochaines années — Joomla, Drupal, et même les CMS propriétaires emboîtent déjà le pas. En testant WordPress 7.0 dès maintenant, en identifiant ses forces et ses faiblesses, en formant nos équipes et en documentant nos processus, nous nous préparons pour un futur où l'IA ne sera plus une option mais un composant standard de toute infrastructure web. Les 30 jours que nous avons passés sur cette version ne sont pas la fin d'un test : c'est le début d'une nouvelle manière de concevoir, produire et gérer le contenu en ligne.

---

Ce qu'on retient après 30 jours

WordPress 7.0 est une mise à jour majeure, mais elle est en rodage. L'infrastructure IA est solide, bien conçue, et ouvre des possibilités immenses — mais elle repose sur vos propres clés API, et la qualité dépend du modèle que vous choisissez.

La collaboration temps réel est le vrai game-changer. Elle n'est pas dans 7.0, mais elle arrivera dans 7.1 (août 2026). WordPress 7.0 pose les bases techniques (éditeur iframé, dashboard modernisé) qui la rendront possible.

Notre conseil : migrez, mais pas sur tous les sites. Les blogs et sites de contenu tirent un bénéfice immédiat de l'IA native. Les sites WooCommerce très personnalisés gagnent à attendre 7.1. Les sites purement vitrine sans besoin éditorial peuvent rester sur WordPress 6.x encore quelques mois.

Cette stratégie de migration différenciée repose sur un constat simple : l'IA native n'apporte de la valeur que là où il y a du volume éditorial. Sur un blog qui publie cinq articles par semaine, le gain de trois heures par semaine transforme la dynamique de production : l'équipe peut soit produire plus, soit passer plus de temps sur la qualité et la stratégie. Sur un site vitrine qui publie un article par mois, le gain est marginal et ne justifie ni le coût des API ni le temps de configuration. La recommandation de prioriser les sites de contenu n'est pas un jugement de valeur — c'est une question de retour sur investissement mesurable.

Pour les sites WooCommerce, le calcul est différent. L'IA est très utile pour générer des descriptions de produits et des balises alt d'images, mais ces tâches sont souvent ponctuelles (lors de l'ajout d'une nouvelle collection) plutôt que continues. Le gain de productivité existe, mais il est intermittent, ce qui rend le coût des API plus difficile à amortir sur la durée. Notre recommandation d'attendre 7.1 pour les boutiques très personnalisées tient aussi à un facteur technique : les sites WooCommerce complexes utilisent souvent des meta boxes personnalisées et des champs ACF qui ne sont pas encore tous compatibles avec l'éditeur iframé. En attendant la stabilisation de l'écosystème, on évite les migrations hasardeuses qui pourraient impacter le chiffre d'affaires.

Verdict final

WordPress 7.0 est une version de transition, pas une version de révolution immédiate. L'infrastructure IA est là, bien conçue, et elle fonctionne — mais elle n'est utile que si vous avez des cas d'usage éditoriaux clairs et un budget API. Les fonctionnalités qui changeront vraiment la façon de travailler (RTC, CPT sans code, traduction automatique) arriveront dans les versions 7.1 et 7.2.

Notre recommandation est pragmatique : migrez les sites de contenu dès maintenant, configurez l'IA avec GPT-4o-mini pour minimiser les coûts, et mesurez le gain de productivité sur un mois. Pour les sites e-commerce et les projets complexes, attendez 7.1 et les premiers retours d'expérience de la communauté.

Cette position nuancée peut sembler prudente, mais elle est dictée par notre observation directe des réalités du terrain. Dans notre portefeuille de sites clients, ceux qui ont migré vers WordPress 7.0 le premier jour sans préparation ont rencontré des problèmes que les sites préparés ont évités : ralentissements liés à des connecteurs mal configurés, blocs custom incompatibles avec l'éditeur iframé, équipes éditoriales désorientées par les nouveaux outils. À l'inverse, les migrations préparées (staging, formation des équipes, déploiement progressif) se sont déroulées sans accroc et ont produit les gains de productivité attendus. La différence entre une migration réussie et une migration chaotique n'est pas technique — c'est une question de méthode et d'accompagnement.

Regardons maintenant vers l'avant. WordPress 7.1, prévu pour août 2026, apportera la collaboration temps réel, les Custom Post Types sans code, et une version améliorée du AI Client avec support des appels asynchrones (les générations longues, comme les traductions d'articles entiers, pourront s'exécuter en arrière-plan sans bloquer l'éditeur). WordPress 7.2, déjà discutée dans les canaux de développement, pourrait introduire un assistant IA dédié à l'administration (analyse des performances, suggestions de plugins, détection de vulnérabilités) et une intégration plus poussée avec les outils de SEO. La roadmap est ambitieuse, et elle confirme que l'IA n'est pas une fonctionnalité gadget de WordPress 7.0 — c'est l'axe stratégique principal des prochaines versions du CMS.

Dans ce contexte, notre conseil final aux décideurs est le suivant : ne voyez pas WordPress 7.0 comme une destination, mais comme un point de départ. Les fonctionnalités qui feront vraiment la différence (RTC, automatisation éditoriale, personnalisation dynamique des contenus) arrivent dans les 12 à 18 prochains mois. Migrer dès maintenant, c'est se donner l'opportunité de les adopter progressivement, sans précipitation. Rester sur WordPress 6.x, c'est prendre le risque de se retrouver avec un rattrapage technique plus douloureux quand les versions 7.x seront devenues la norme du marché. Le CMS le plus utilisé du monde amorce sa mue vers un système d'exploitation du contenu piloté par l'IA, et il est préférable de l'accompagner que de le subir.

---

---

---

FAQ — WordPress 7.0 : on a testé l'IA native pendant 30 jours — voici ce qui change vraiment

Qu'est-ce que WordPress 7.0 : on a testé l'IA native pendant 30 jours — voici ce qui change vraiment ?

Le 20 mai 2026, WordPress 7.0 « Armstrong » est officiellement sorti. Ce n'est pas une mise à jour comme les autres : c'est la première version majeure à franchir le cap des 7.x, et elle embarque l'intelligence artificielle directement dans le cœur du CMS.

Ce que WordPress 7.0 change vraiment : que retenir ?

Le AI Client : l'IA qui parle à vos plugins

WordPress 7.0 introduit un AI Client centralisé. Concrètement, c'est une couche logicielle qui permet à WordPress de communiquer avec des modèles d'IA (Claude, GPT, Gemini) via des connecteurs standardisés. Avant 7.0, chaque plugin qui voulait utiliser l'IA devait coder sa propre intégration.

Notre bilan par site : quels sont les points clés ?

Problèmes rencontrés Oui +++ Connecteur à configurer Oui ++ IA lente sur les fiches en batch Oui + Peu pertinent sans contenu Non applicable Attention à la confidentialité Oui ++ Traduction améliorée mais pas parfaite Ce tableau synthétique mérite qu'on en détaille les enseignements, car derrière ces chiffres se cachent des réalités d'usage très différentes. Le gain de temps annoncé pour chaque ty

Migration : faut-il mettre à jour ?

Les prérequis techniques

Important : WordPress 7.0 abandonne le support de PHP 7.2 et 7.3. La version minimale est PHP 7.4, et la version recommandée est PHP 8.3+. Avant de migrer, vérifiez :

PHP : 8.1 minimum conseillé (gros gains de performances)

Plugins : vérifiez que vos extensions sont marquées « Tested up to 7.0 »

Thème : les thèmes classiques (non-blocs) fonctionnent, mais les thèmes bl

Ce qu'on retient après 30 jours : quels sont les points clés ?

WordPress 7.0 est une mise à jour majeure, mais elle est en rodage. L'infrastructure IA est solide, bien conçue, et ouvre des possibilités immenses — mais elle repose sur vos propres clés API, et la qualité dépend du modèle que vous choisissez. La collaboration temps réel est le vrai game-changer.

Quels sont les prérequis pour se lancer ?

Avant de commencer, assurez-vous d'avoir les bases : un site ou projet bien défini, des objectifs clairs, et les ressources nécessaires (temps, budget, compétences). Le reste s'acquiert en chemin.

Combien de temps faut-il pour voir des résultats ?

Les premiers résultats peuvent apparaître en 2 à 4 semaines pour les actions rapides. Pour les efforts plus profonds, comptez 3 à 6 mois. La régularité est le facteur clé.

Quelles erreurs éviter absolument ?

Les erreurs les plus fréquentes : se précipiter sans diagnostic, vouloir tout faire d'un coup, négliger la formation, et sous-estimer le temps nécessaire. La pire : copier les autres sans comprendre pourquoi.

Faut-il des compétences techniques ?

Pas forcément. Beaucoup d'aspects sont accessibles sans technique. Pour les points plus complexes, des outils simplifient la tâche ou vous pouvez vous faire accompagner.

Par où commencer après avoir lu cet article ?

Identifiez votre besoin prioritaire, choisissez 2-3 actions concrètes de cet article, et lancez-vous cette semaine. Fixez-vous un point dans 30 jours pour ajuster. L'important est de passer à l'action.

---

Test réalisé entre le 20 juin et le 20 juillet 2026 sur un échantillon de 10 sites WordPress. Les résultats peuvent varier selon les configurations techniques, les usages et les modèles d'IA choisis. Cet article sera mis à jour après le test de WordPress 7.1.