Drupal AI est prêt pour la production. Ses agents IA non.

« On veut de l’IA dans notre site Drupal » est devenue une phrase que j’entends dans la plupart des cadrages. C’est aussi deux demandes complètement différentes sous les mêmes mots, et l’écart entre les deux sépare une fonctionnalité livrable au prochain sprint d’une autre que le projet lui-même vous déconseille de déployer.

Voici la frontière, pièces à l’appui.

Le module AI est solide, et utilisable dès aujourd’hui

Drupal AI n’est pas une expérimentation de week-end. À l’heure où j’écris, il affiche 23 475 installations — contre environ 14 000 en avril, soit deux tiers de croissance en six mois. La dernière version stable, 1.5.0, est sortie le 25 septembre 2026, et le projet bénéficie de la couverture de sécurité de l’équipe sécurité Drupal. C’est ce dernier point qui compte dans un dossier d’achat en entreprise, et c’est celui que les articles enthousiastes ne mentionnent jamais.

Ce qu’il embarque, c’est un socle plus une série de sous-modules assistifs : AI Core, AI Automators, AI CKEditor, AI Translate, AI Search, AI Content Suggestions, AI Assistants, AI Chatbot, AI Validations, AI Logging et AI Observability, entre autres.

Regardez la forme de cette liste. Presque tout y est assistif : un humain demande, le modèle propose, l’humain accepte ou refuse. Des brouillons de traduction. Des suggestions de texte alternatif. De l’aide côté rédacteur dans CKEditor. Une recherche plus intelligente. Tout cela s’insère dans un workflow éditorial parce que cela se greffe sur une étape qu’une personne effectuait déjà.

C’est un produit réellement utile — et quand un client demande « de l’IA dans Drupal », c’est presque toujours de cela qu’il a besoin.

Les agents, c’est tout autre chose

Ce que les gens imaginent, en revanche, ce sont des agents : un logiciel à qui l’on donne un objectif et qui agit seul sur le site.

L’AI Agents Experimental Collection a été créée en mars 2026. Lisez sa page de projet avant de lire l’avis de qui que ce soit, le mien compris. Trois choses qu’elle dit d’elle-même :

• « N’utilisez pas ceci en production — ces agents ne sont pas prêts pour la production et peuvent produire des résultats inattendus. »
• Elle n’est pas couverte par la politique d’avis de sécurité de Drupal.
• L’intégralité du code a été écrite par des agents de codage et n’a pas suivi de processus complet de revue humaine.

Soyons justes sur ce que cela représente. Ce n’est pas un échec, et les mainteneurs méritent du crédit pour l’avoir écrit aussi clairement plutôt que de l’enfouir. C’est un terrain de jeu explicitement étiqueté comme tel, avec un parcours de promotion publié : tout agent jugé prêt sort de la collection pour rejoindre son propre module, après revue humaine.

Mais cela signifie que la réponse honnête à « peut-on mettre des agents IA Drupal sur notre plateforme ? » est non — et le projet est d’accord avec moi.

Pourquoi cette distinction coûte cher

Si cela pèse davantage sur une plateforme éditoriale que sur un site vitrine, c’est une question de gouvernance, pas de capacité technique.

Je passe mes journées dans des back-offices éditoriaux — de ceux où une rédaction publie en continu et où chaque modification est attribuable à une personne. Lâchez un agent autonome là-dedans et les questions difficiles ne portent pas sur le modèle :

• Qui est l’auteur ? Votre workflow suppose un uid derrière chaque révision. Un agent n’est pas une personne, et votre piste d’audit n’a pas été conçue pour lui.
• Quelles sont ses permissions ? Un agent hérite d’un compte. Avec un rôle de rédacteur, il peut tout ce que peut un rédacteur — y compris à 3 h du matin sans personne pour regarder.
• Comment relire un lot ? Une suggestion acceptée par un humain se relit. Quatre cents modifications nocturnes, non : votre interface de modération a été pensée pour le premier cas.
• Comment revenir en arrière ? Pas sur un nœud : sur toute une exécution.

Notez ce que la feuille de route IA 2026 de Dries liste parmi ses huit capacités : « gouvernance avancée — approbations par lot, versionnement par branches et pistes d’audit complètes pour les modifications réalisées par l’IA ». L’initiative sait. Si la gouvernance est sur la feuille de route, c’est précisément parce que l’édition autonome est invendable à des organisations sérieuses sans elle.

Cette feuille de route, au passage, n’est pas une liste de souhaits : 28 organisations et plus de 23 équivalents temps plein la soutiennent. C’est le chantier le mieux doté de l’écosystème Drupal aujourd’hui.

Ce que je ferais concrètement

Si vous exploitez une plateforme Drupal et voulez agir en octobre 2026 :

1. Installez le module AI et activez les briques assistives. AI Translate et AI CKEditor sont vite rentabilisés sur un site éditorial multilingue, et rien d’autonome ne se produit.
2. Prévoyez un vrai budget fournisseur et une politique de journalisation. AI Logging et AI Observability existent pour une raison : activez-les avant vos rédacteurs, pas après la facture.
3. Mettez les agents en recette, sur une copie de contenu, jamais en production. Traitez la collection expérimentale comme un outil de recherche — c’est le mot de ses mainteneurs.
4. Faites de la gouvernance votre critère d’acceptation. Quand un éditeur vous vend des agents de contenu autonomes, demandez qui est l’auteur de la révision, comment une exécution se relit et comment elle se réverte. Sans réponse, le produit n’est pas fini, quelle que soit la qualité de la démo.

Le découpage utile : l’IA assistive est une décision 2026, l’IA autonome une décision 2027. Tout ce qui est dans le premier panier est livrable maintenant, et l’essentiel de la valeur s’y trouve de toute façon : dans une équipe éditoriale, le goulot d’étranglement n’a jamais été la frappe au clavier.

---

Vous vous demandez quelle IA a réellement sa place dans votre plateforme Drupal — et laquelle refuser ? Cette conversation fait partie du travail de développement et d’architecture que je mène, et elle commence généralement par les questions de gouvernance ci-dessus, pas par le modèle.