Chi negli anni ha proposto Drupal per un sito istituzionale conosce il momento in cui chi deve approvare il budget chiede di giustificare tanto rigore. Le richieste di chiarimento riguardano quasi sempre tre punti, cioè la scelta di modellare ogni contenuto in tipi e campi invece di comporre pagine, di esporlo attraverso API anche quando nessuna app lo consumerà e di versionare la configurazione del sito come se fosse codice. Quelle tre scelte, che per un «semplice sito» sembravano eccessive, oggi permettono a un agente AI di operare su Drupal in modo governato: trova contenuti già strutturati, vi accede tramite API e interviene su una configurazione tracciata come qualunque altro codice.
Il ribaltamento è diventato visibile con il “driesnote” al DrupalCon Rotterdam. Dries ha mostrato agenti AI al lavoro sopra la piattaforma e ha sostenuto che l’architettura esistente di Drupal offre un vantaggio accidentale con l’arrivo dell’AI. Nello stesso intervento ha però riconosciuto che per Drupal esiste un divario di accessibilità e di reputazione ancora aperto, e chi deve decidere un investimento sul CMS ha bisogno di tenere insieme entrambe le cose.
La critica storica e il vantaggio attuale riguardano infatti le stesse decisioni, osservate a undici anni di distanza. Per capire come la stessa architettura passi da costo a risorsa bisogna riprendere le tre scelte una per una, guardando a come apparivano allora e a cosa producono oggi.
Le tre scelte del 2015 che sembravano eccessive
Nel 2015 l’architettura di Drupal chiedeva ai team di pagare in anticipo un costo che molti progetti non vedevano ripagato nel breve periodo. Dalla nostra esperienza, tre scelte in particolare, allora percepite come eccessive, sono oggi la base su cui poggiano l’AI in contesti enterprise, la composizione visuale delle pagine con regole di controllo e un’architettura composable che regge la crescita.1 Abbiamo formulato questa lettura dopo la DrupalCon Vienna 2025, e le demo del keynote di Rotterdam l’hanno messa alla prova.
Structured content. Allora significava modellare i contenuti come dati, con campi tipizzati e relazioni esplicite, al posto di pagine impaginate in un editor, e quindi più lavoro di analisi prima di scrivere una riga di testo. Oggi quel contenuto è un’informazione riusabile su canali diversi e interpretabile da una macchina, perché ogni campo dichiara cosa contiene.
API-first. Allora rendere il contenuto accessibile tramite interfacce programmatiche, oltre che attraverso il front-end del CMS, sembrava utile solo ai progetti decoupled di nicchia. Oggi è il canale con cui un sistema esterno, che sia un’app, un motore di workflow o un agente, interroga il sito senza passare dall’HTML.
Configuration management rigoroso. Allora esportare, versionare e riprodurre tra ambienti ogni modifica alla configurazione appariva un eccesso di processo per team piccoli. Oggi offre la tracciabilità di chi ha cambiato cosa, quando e in quale ambiente.
Nella nostra esperienza su progetti Drupal la resistenza a queste scelte si concentra nella fase di analisi. Il modello dei contenuti richiede decisioni che gli stakeholder preferirebbero rimandare, e il flusso di rilascio della configurazione viene vissuto come burocrazia finché non serve ricostruire perché un permesso o un tipo di contenuto è cambiato tra staging e produzione.
Il filo comune alle tre scelte è la leggibilità del sistema, perché tutte rendono il sito descrivibile in modo esplicito, sia nei contenuti sia nel comportamento. Per un editor umano questa esplicitezza rappresentava soprattutto un costo di analisi, mentre per un sistema automatico che deve operare sul sito diventa il prerequisito per farlo senza dover interpretare pagine scritte come testo libero.
Cosa ha mostrato Dries Buytaert a Rotterdam sugli agenti AI nei CMS?
Nel keynote di Rotterdam, Dries ha ripercorso l’evoluzione di Drupal prima di arrivare all’AI: ciò che oggi si può costruire sopra la piattaforma dipende da come la piattaforma è cambiata.
Buytaert ha mostrato le capacità AI di Drupal con una dimostrazione di audit autonomi dei siti. Al di là dei singoli controlli eseguiti in demo, ci interessa la condizione che rende un audit automatico praticabile. Un agente può verificare un sito solo se trova campi con un significato dichiarato, relazioni esplicite tra contenuti e una configurazione leggibile e confrontabile con uno stato atteso. Su pagine composte come testo libero lo stesso agente sarebbe costretto a inferire la struttura, con margini di errore difficili da governare.
Il secondo passaggio riguarda il collegamento con agenti esterni. Dries ha mostrato come Drupal si colleghi ad agenti AI esterni tramite gli attributi ToolProperty e il Model Context Protocol. MCP è un protocollo aperto che standardizza il modo in cui agenti e modelli AI si collegano a strumenti e fonti dati esterne. Il sistema dichiara quali operazioni mette a disposizione, l’agente le invoca e riceve risultati strutturati. In questo schema l’agente opera esclusivamente su ciò che Drupal gli espone, leggendo campi e chiamando funzionalità dichiarate.
Da qui la tesi di Buytaert, secondo cui l’architettura che Drupal ha già gli dà un vantaggio accidentale con l’arrivo dell’AI. Le stesse scelte che nel 2015 servivano al riuso dei contenuti, alle integrazioni e alla tracciabilità dei rilasci oggi rispondono a una domanda che allora non esisteva.
Resta il nodo della governance. Un agente che propone modifiche a un sistema in produzione solleva domande precise: chi autorizza l’operazione, cosa viene registrato, come si torna allo stato precedente. Secondo noi il configuration management versionato risponde già alle ultime due, perché ogni cambio di configurazione diventa un artefatto confrontabile e reversibile. Non mostra però cosa fa l’agente mentre opera, né stabilisce chi deve approvare un suo intervento prima che arrivi in produzione. Per questo servono l’osservabilità e il controllo degli agenti in produzione, da progettare come un livello a sé.
Drupal CMS 2.2 mette un’esperienza semplice sopra la stessa struttura
Se la reputazione di Drupal è quella di una piattaforma potente ma faticosa da configurare, le novità di Drupal CMS 2.2 vanno nella direzione opposta. Secondo quanto Buytaert, la versione introduce un supporto multilingua semplificato, lo sviluppo JavaScript nativo in Drupal Canvas e l’integrazione headless. La traiettoria non nasce a Rotterdam: la scommessa di Drupal CMS su AI ed esperienza semplificata è il filo conduttore del progetto, e la 2.2 la estende agli strumenti che team ed editor usano ogni giorno.
Rispetto alle scelte del 2015, queste novità corrispondono agli altri due esiti che attribuiamo a quell’architettura: comporre le pagine in modo visuale senza uscire da regole condivise e un’architettura fatta di parti componibili. La semplificazione non toglie struttura: la sposta sotto la superficie.
Drupal Canvas è lo strumento di costruzione visuale delle pagine di Drupal CMS. Secondo Buytaert, con la 2.2 supporta lo sviluppo JavaScript nativo, e questo avvicina i team front-end allo stesso strumento usato dagli editor. Per noi un page builder visuale resta governabile solo se ciò che l’editor compone continua a essere contenuto strutturato e configurazione tracciabile, cioè componenti con proprietà dichiarate e pagine che si possono versionare e confrontare. In superficie c’è un’esperienza drag-and-drop, sotto un modello dati esplicito.
Resta da verificare sul campo se Canvas reggerà i progetti complessi, quelli con grandi volumi di contenuti, flussi redazionali articolati su più ruoli e design system di brand e di sottobrand da cui dipende la coerenza dell’esperienza utente. Canvas, inoltre, non è l’unica strada per il site building in Drupal: esistono iniziative alternative come Display Builder di UI Suite, che punta a sostituire con un unico strumento Layout Builder per le visualizzazioni delle entità, Block Layout per le pagine e la costruzione dei display di Views2. Lo strumento giusto va scelto progetto per progetto, in base ai contenuti, ai processi e al design system che dovrà sostenere.
Tra le novità della 2.2, l’integrazione headless è quella che discende più direttamente dalle scelte del 2015: l’approccio API-first diventa un’opzione di prodotto invece che una scelta progettuale da costruire a mano, e apre la strada a configurazioni in cui Drupal fornisce contenuti a front-end e servizi diversi. È il terreno che abbiamo esplorato parlando di architettura composable con Drupal CMS, dove il disaccoppiamento regge perché il contenuto era già pensato come dato.
Sul supporto multilingua semplificato, terza novità indicata da Dries, la 2.2 lavora su uno dei punti di forza storici di Drupal. Il core gestisce lingue, traduzione dei contenuti, dell’interfaccia e della configurazione, e attorno a questa base ci sono diverse strade per organizzare il lavoro di traduzione. Una è il modulo TMGMT (Translation Management Tool), che gestisce i job di traduzione e li invia a servizi esterni tramite provider. Nel case study dell’Università Luiss lo abbiamo usato aggiungendo il provider Lara Translate con il modulo dedicato.
La gestione di più lingue beneficia di contenuti modellati come dati, perché la traduzione si applica campo per campo e le relazioni tra versioni linguistiche restano esplicite. Un sito che tratta le lingue come copie di pagine moltiplica invece il lavoro di allineamento a ogni modifica, e lo rende opaco anche a qualunque agente debba verificarne la coerenza.
Un vantaggio che nessuno percepisce è ancora un vantaggio?
Oggi pesa poco. L’obiezione più forte all’argomento del vantaggio accidentale, presa nella sua versione migliore, è che un vantaggio architetturale che il mercato non percepisce non entra nelle decisioni d’acquisto. Se un IT Director associa ancora Drupal all’idea di «troppo», le demo sugli agenti restano un argomento per addetti ai lavori.
A questa si somma un secondo dubbio, altrettanto legittimo. Legare la scelta di un CMS all’AI è rischioso se l’AI dovesse rivelarsi una bolla, perché un investimento architetturale giustificato solo dagli agenti perderebbe la sua ragione d’essere insieme alle aspettative.
La prima risposta viene dall’interno della community: dal palco del suo evento principale, Dries ha riconosciuto che per Drupal il divario di accessibilità e di reputazione è ancora aperto. Il fatto che lo dica il fondatore della piattaforma ha un peso non indifferente.
Le risposte annunciate sono due. Dries ha presentato la Rosetta Sprint, che punta a standardizzare schemi e strumenti di Drupal, e il Drupal Advocacy Program, che premia i membri della community che promuovono le capacità moderne della piattaforma: entrambe le iniziative servono ad affrontare il divario e ad ampliare la portata di Drupal. Per noi standardizzare gli schemi rafforza anche la proprietà che serve agli agenti, cioè una struttura prevedibile da un sito all’altro. Un agente configurato per operare su un’installazione ritrova così le stesse convenzioni sulla successiva.
Sul dubbio della bolla il riferimento va cercato fuori da Rotterdam. Alla DrupalCon Vienna 2025 (14-17 ottobre) Buytaert ha sostenuto che l’AI è una tecnologia destinata a rimanere anche se la bolla finanziaria dovesse esplodere, e ha definito Drupal uno dei CMS open-source meglio posizionati per sfruttarla: una posizione che avevamo raccolto nel resoconto da Vienna.
La condividiamo, da azienda AI-native, con una precisazione che viene dal nostro lavoro quotidiano. In SparkFabrik integriamo approcci di agentic development nei workflow, dall’analisi e dalla progettazione fino a revisione, test e delivery3, e proprio per questo sappiamo che un agente rende quanto la struttura su cui opera. Quelle tre scelte servivano già al riuso dei contenuti, alle integrazioni e alla tracciabilità prima che arrivassero gli agenti. Per questo conservano il loro valore anche se le aspettative sull’AI si ridimensionano.
Il divario resta aperto finché le due iniziative non produrranno risultati, e a oggi non ce ne sono da riportare. Il vantaggio architetturale è reale, ma da solo non basta a spostare la percezione di chi valuta un CMS dall’esterno della community.
Tre verifiche prima di confrontare le funzionalità AI
Per chi deve scegliere o rinnovare un CMS in vista degli agenti AI, il criterio si sposta dall’elenco delle funzionalità AI integrate alla qualità della struttura su cui un agente dovrà operare. Prima di confrontare le brochure conviene verificare tre condizioni: se i contenuti sono modellati come dati, con campi e relazioni esplicite; se sono accessibili via API, senza dipendere dal front-end; se le modifiche alla configurazione sono versionate e tracciabili tra ambienti.
Se manca una delle tre condizioni, l’agente opera su contenuti che non può leggere in modo affidabile né governare, e ogni funzionalità AI costruita sopra eredita quel limite. Il test vale per qualunque piattaforma, Drupal incluso. Applicalo al modello dei contenuti e al flusso di rilascio che hai oggi, prima di guardare una demo commerciale. Nella nostra esperienza, sono queste tre domande a distinguere i progetti pronti per gli agenti da quelli che devono prima rifare le fondamenta.
Note e fonti
Fonte video
Questo articolo è basato sul video “#Driesnote | DrupalCon Rotterdam 2026”.
Secondo SparkFabrik, le scelte architetturali di Drupal del 2015 (structured content, API-first, configuration management rigoroso), che allora sembravano eccessive, sono oggi l’infrastruttura necessaria per AI enterprise-grade, visual page building con governance e architettura composable scalabile. Questa valutazione nasce dal DrupalCon Vienna 2025 (14-17 ottobre 2025), non dal DrupalCon Rotterdam. (fonte: DrupalCon Vienna 2025: cosa abbiamo imparato (e cosa cambia per te)) ↩︎
esistono iniziative alternative come Display Builder di UI Suite: «Unified : replace Layout Builder for entity view displays, Block Layout for page displays, and as a replacement of the Views’ display building feature.» (fonte: https://www.drupal.org/project/display_builder) ↩︎
La condividiamo da azienda AI-native. In SparkFabrik l’AI è parte di tutti i processi e del modo in cui svilu…: «Stiamo già integrando approcci di agentic development nei nostri workflow: dall’analisi e dalla progettazione alla scrittura, revisione, test e delivery del software»: La nostra visione sull’AI (fonte: </it/chi-siamo/ai-vision/>) ↩︎
