WordPress 7.0 et l’IA : une imposition ? Comment change le travail des web agencies

Ceux qui attendaient un rédacteur automatique dans l’admin ont été déçus, et heureusement. Le core n’a imposé aucun fournisseur d’IA : il a posé trois briques sous le plancher, et ce sont des briques d’ingénieurs, pas de marketing.

WP AI Client : un seul canal vers les modèles

C’est une interface PHP indépendante du fournisseur : les plugins parlent aux modèles génératifs sans réécrire l’intégration à chaque fois, et le routage des requêtes est géré par le core. Les développeurs peuvent exprimer une préférence de modèle avec using_model_preference() et construire les prompts avec WP_AI_Client_Prompt_Builder. Traduction : le modèle devient un détail de configuration, pas un choix gravé dans le code du thème.

Abilities : le site devient invocable

Les Abilities, introduites dans WordPress 6.9 et disponibles aussi côté client en 7.0, sont des actions enregistrées avec schémas d’entrée et de sortie, permissions et annotations : lecture seule, idempotente, destructive. C’est ainsi qu’un assistant — ou un workflow interne — découvre ce que le site sait faire et l’exécute, sans endpoint REST artisanal pour chaque plugin. Au-dessus, l’adaptateur MCP : des outils comme Claude, ChatGPT ou Gemini peuvent voir ces actions et les appeler. Ce n’est pas de la magie, c’est un contrat.

Connectors : où finissent les clés API

Dans Réglages → Connectors se gèrent les connexions aux fournisseurs : Anthropic, Google et OpenAI par défaut, plus vos propres connecteurs. Attention à un détail qui compte en production : les clés saisies depuis cet écran sont masquées à l’affichage mais pas chiffrées en base. Sur un site de production, elles doivent venir de variables d’environnement ou de constantes PHP.

Le cycle qui suit une version majeure en dit toujours plus que la majeure elle-même. Ici, il a dit deux choses : le core s’est stabilisé vite, et la sécurité n’a pas attendu vos plans de livraison.

9 juillet 2026 — 7.0.1, maintenance

Version mineure avec 31 correctifs répartis entre le core, l’éditeur de blocs et les médias. Rien à raconter au client, tout à planifier.

17 juillet 2026 — 7.0.2, la version qui s’est installée toute seule

Version de sécurité avec une vulnérabilité critique et une élevée (CVE-2026-60137 et CVE-2026-63030). WordPress.org a forcé les mises à jour automatiques sur les versions concernées, avec des backports en 6.9.5 et 6.8.6. Quand on gère cinquante ou deux cents sites, c’est là que ça fait mal : une mise à jour du core peut démarrer la nuit sur un parc que personne n’a testé en staging. Si vous avez encore des installations sous 6.8, ce backport ne vous couvre pas.

19 août 2026 — 7.1 « Mary Lou »

Moins d’IA de manifeste, plus de travail quotidien : barre d’admin cohérente dans tout le back-office, visibilité responsive des blocs sans CSS custom, nouvel éditeur média avec recadrage libre, retournement et rotation, Notes avec texte enrichi et @mentions n’importe où dans le contenu, blocs Playlist et Tabs, API pour enregistrer des jeux d’icônes SVG. La 7.1 ne contredit pas la 7.0 : elle la rend utilisable par une équipe.

Cela dépend de ce que vous appelez imposition. Il vaut mieux séparer les deux faces, car la réponse n’est pas la même.

Ce qui n’est pas obligatoire

• Aucun fournisseur inclus. Le core ne livre pas de fournisseur d’IA : sans connecteurs configurés, rien ne démarre.
• Des fonctions opt-in. Résumés, extraits et textes alternatifs générés vivent surtout parmi les expériences IA, à activer à la main.
• Aucun coût caché. Les tokens sont payés par celui qui branche sa clé. Un site 7.x peut rester muet vis-à-vis des modèles et fonctionner comme avant.

Ce que vous subissez en revanche

• La plateforme est agent-ready. Les plugins sérieux enregistreront des abilities : le site devient pilotable de l’extérieur, que cela vous plaise ou non.
• Le marché bouge avant vous. Les clients demanderont « ça fait aussi de l’IA ? » et les concurrents vendront des packs de contenus automatiques.
• Les mises à jour forcées. La 7.0.2 est entrée en production sans demander la permission à aucune agence.

Donc non, l’IA n’est pas imposée. Mais le modèle de responsabilité a changé quand même : la surface à gouverner s’est élargie, et la mise à jour de sécurité automatique a rappelé à tous que sur WordPress, le temps appartient à ceux qui ont du staging, des sauvegardes et une fenêtre de vérification. Les autres l’apprennent par le ticket client.

En construction : du site au système

La valeur passe de la page unique à l’installation : theme.json, patterns soignés, blocs enregistrés en PHP, abilities documentées. C’est ainsi qu’on livre dix sites cohérents sans cloner le constructeur de pages à la main. L’IA ne remplace pas le design system : elle le consomme. Si les patterns sont faibles, la production générée est faible ; si les permissions des abilities sont larges, cette production devient un dégât.

En maintenance : il faut l’inventaire des abilities

Le forfait de maintenance ne couvre plus seulement versions et sauvegardes. Il faut désormais répondre à de nouvelles questions : quels plugins exposent des abilities, lesquelles sont destructives, où sont les clés API, qui peut activer un fournisseur. Et il faut un protocole de mise à jour écrit, car 7.0.1 et 7.0.2 ont montré que « on met à jour quand on a le temps » n’est pas une stratégie.

En commercial : on vend de la gouvernance, pas de la mise en page

Générer un brouillon de page ou un alt text coûte très peu, et le client va le découvrir. Ce qu’il ne sait pas faire seul, c’est tenir ensemble voix de marque, qualité, accessibilité, SEO et responsabilité. L’agence qui vend des heures de mise en page concurrence un modèle de langage. Celle qui vend des contenus relus, des workflows d’approbation, du monitoring et un hébergement isolé augmente son forfait au lieu de baisser son devis.

• Setup IA et permissions — configuration des connecteurs, clés hors base de données, rôles autorisés, liste des abilities actives avec leurs annotations. Une fois, au projet.
• QA éditoriale de l’IA — relecture humaine des contenus générés : ton, sources, accessibilité, SEO. Au volume ou au forfait.
• Mises à jour du core avec staging — fenêtre de vérification, rollback, rapport au client. C’est le service que la 7.0.2 a rendu vendable sans avoir à expliquer pourquoi il est nécessaire.

Trois lignes que le client comprend et qui défendent la marge : aucune des trois n’est reproductible par un prompt.

• Passez le parc en 7.1 (ou au moins 7.0.2 / 6.9.5 / 6.8.6 selon la branche) après un passage en staging.
• Établissez la liste des plugins et thèmes qui enregistrent des abilities, en signalant les destructives.
• Décidez si l’IA est activée, pour quels rôles et sur quels environnements. Mettez-le par écrit.
• Sortez les clés API de la base de données, vers des variables d’environnement ou des constantes PHP.
• Vérifiez que sauvegardes et staging tiennent une mise à jour forcée le week-end.
• Expliquez au client qui paie les tokens, qui voit les données envoyées au modèle et qui répond si une bêtise se retrouve en ligne.

WordPress ne vous force pas à faire écrire vos sites par un modèle. Il vous force à traiter le site comme une plateforme avec des actions invocables. C’est la même courbe qu’avec Gutenberg, les block themes et WooCommerce : ceux qui s’adaptent vendent de meilleurs services, ceux qui attendent que la mode passe finissent par réparer des sites que leurs clients ont déjà commencé à confier à l’IA tout seuls.

Chez Host.it, les sites WordPress tournent sur une infrastructure italienne, avec sauvegardes, SSL et Application Manager pour publier et mettre à jour sans théâtre. Si vous gérez beaucoup de clients, ce qui fait la différence reste banal et décisif : staging, observabilité et quelqu’un à appeler quand une mise à jour de sécurité tombe un samedi soir. L’IA dans le core ne supprime pas ce besoin : elle le rend plus urgent.