Per quanto perfetta sia un'idea, se non viene messa a terra nel modo giusto il castello crolla. Esiste un punto preciso in cui il contenuto incontra la tecnologia che ne permette la pubblicazione e la fruizione online: il CMS, il Content Management System. Attorno a questa scelta circolano molti miti, fraintendimenti e mezze verità, e le domande che arrivano sono tante. Prendendo come riferimento un progetto di media o alta complessità — un'azienda con un catalogo prodotti, una presenza in più paesi e lingue, obiettivi di informazione, lead generation ed eventualmente vendita — la risposta alla domanda quale CMS scegliere è quasi sempre la stessa: dipende. Ma dietro quel dipende si nasconde un ragionamento che vale la pena percorrere fino in fondo.
Due anime dei CMS: fare un sito o gestire il contenuto
È utile dividere il campo in due grandi mondi in base al fine dello strumento. Il primo obiettivo, quello che ha decretato il successo di piattaforme diffusissime come WordPress, è permettere a chi non sa maneggiare la tecnologia di realizzare un sito anche complesso senza scrivere una riga di codice: un template, qualche plugin, dei buoni contenuti e in pochi minuti si ottiene un risultato con sforzo minimo. Il secondo obiettivo, più fedele all'acronimo, è gestire contenuti complessi, di cui il sito è solo uno dei possibili output e delle possibili interfacce di fruizione.
Capire quale dei due fini si sta cercando è il primo passo per orientarsi. In un dialogo a due — io azienda e il mercato — la priorità è realizzare da soli un sito senza competenze tecniche. In un dialogo a tre, in cui entra un'agenzia o un partner che progetta design, contenuti e sviluppo, l'azienda ha bisogno soprattutto di uno strumento per gestire bene i contenuti, mentre la piattaforma fa da ponte tra la cura tecnica del fornitore e la gestione autonoma del cliente.
Non è la tecnologia, è l'implementazione
Da qui nasce molta confusione, anche tra gli addetti ai lavori. La tentazione della strada semplice — prendi un template, aggiungi qualche plugin e hai mille funzionalità — promette basso impatto economico e ampia autonomia, ma finisce spesso per schiantarsi contro il perimetro del fattibile: se il template non lo prevede e il plugin non lo fa, e l'esigenza è anche solo un po' diversa, non si può biforcare, perché infilarsi a scrivere codice dentro quell'impianto diventa complicatissimo. È una fortezza con le sbarre alle finestre, dove basta una virgola fuori posto per creare problemi.
La strada alternativa usa la stessa piattaforma come strumento di gestione dei contenuti, impostando un progetto flessibile e progettato a monte. Ecco perché la vera domanda non è quale CMS mi proponi, ma come mi proponi di implementarlo: è una domanda molto più profonda. I nomi più noti del mondo open source hanno ormai tutti, a bordo, le capacità per gestire scenari complessi; fino a un certo livello di discussione l'uno vale l'altro. Ciò che cambia radicalmente è il modo in cui il progetto viene costruito, con i vantaggi, i limiti e i rischi che ne derivano.
Libertà e vincoli: la metafora della casa
Negli ultimi anni le aziende chiedono sempre più autonomia e flessibilità nella gestione, un desiderio sanissimo alimentato dall'abitudine ad app dalla curva di apprendimento vicina allo zero. Ma un progetto web ha complessità che spaziano dalle implicazioni tecniche alla visibilità sui motori di ricerca, dalla resa sui diversi dispositivi alle performance. Per il bene del progetto è necessario porre a monte alcuni vincoli, all'interno dei quali la libertà d'azione può essere massima. Vale la metafora della casa: si può arredare come si vuole, ma la struttura deve essere progettata perché sia antisismica, isolata, con gli impianti al posto giusto. Se si abbattono i muri portanti, entra il freddo.
Gli strumenti moderni offrono grande elasticità, permettendo di creare strutture non previste a priori. È la traduzione del desiderio di massima libertà, che però è anche il massimo grado di rischio: muovere gli elementi fuori dai binari sicuri può avere ricadute negative sul piano tecnico e delle performance. Per questo, in fase di progettazione, conviene perimetrare in anticipo gli spazi in cui servirà libertà e mettere a sistema gli elementi che la consentono, così da rendere il progetto sostenibile nel tempo. WordPress stesso va benissimo se implementato in questa modalità progettata; usato nella modalità semplificata, apparentemente più facile, lascia invece senza le mura di casa.
Open source, closed source e il mito del "chiunque ci mette le mani"
Uno dei mantra più diffusi è la richiesta di una piattaforma open source affinché, in caso di rottura con il fornitore, chiunque possa metterci le mani. L'affermazione è corretta ma non esaustiva, e la sua validità è inversamente proporzionale alla complessità del progetto. Tanto più un progetto è complesso in termini di architettura, lingue, mercati e funzionalità, tanto meno — a prescindere che sia open o closed source — qualcun altro saprà davvero subentrare, perché mettere le mani nel codice scritto da altri è sempre difficilissimo e richiede un'analisi tutt'altro che banale. Per progetti semplici l'open source offre garanzie reali; per progetti medio-complessi non è di per sé un driver di scelta.
A questo si aggiunge il tema delle estensioni e della sicurezza, oggi sempre più centrale. Più si infarcisce un sistema di plugin di terze parti, più si perde il controllo della macchina, esponendosi a vulnerabilità di sicurezza e privacy e a problemi di aggiornamento. L'idea che basti un click per aggiornare tutto non regge alla prova dei fatti: in un sistema complesso gli aggiornamenti dei vari moduli non arrivano sempre in modo coerente, e un plugin gratuito realizzato da un singolo sviluppatore che ha cambiato lavoro può bloccare l'intero impianto quando serve un aggiornamento di sicurezza. Meglio open source, quindi, ma con pochi plugin curati e sicuri, e implementato in una modalità aperta e gestibile nel tempo.
Mercati, performance e integrazioni: dove crescono i limiti
La complessità esplode con l'introduzione dei mercati, una dimensione diversa dalle semplici lingue: un'azienda può avere cataloghi differenti per area geografica, per scelte commerciali o per vincoli normativi, generando una matrice pluridimensionale che, se non gestita a priori, diventa presto ingovernabile. Essere lungimiranti — capire che un'esigenza internazionale potrebbe arrivare anche se oggi non c'è — aiuta a impostare la strada giusta. Al crescere di lingue, mercati, catalogo e funzionalità, che si moltiplicano tra loro anziché sommarsi, strumenti pensati anche per la gestione grafica autonoma come WordPress iniziano a soffrire, mentre soluzioni più Enterprise come Drupal gestiscono in modo più fluido queste relazioni complesse, fino ad arrivare a piattaforme in licenza più costose come Adobe Experience Manager.
Si intreccia qui il tema delle performance, oggi decisivo per il posizionamento sui motori di ricerca: i Core Web Vitals di Google premiano velocità e qualità dell'esperienza. Vale una regola quasi meccanica: più lo strumento gestisce l'autonomia grafica, meno è possibile raggiungere performance elevate. Da questo trade-off nascono i CMS headless, privi di interfaccia grafica: gestiscono solo il dato e lasciano a chi implementa il compito di generare il codice dell'interfaccia. Zero autonomia grafica, ma performance massime. Non è però una scelta gratuita: quello strato di lavoro qualcuno deve comunque realizzarlo e mantenerlo, con più costi e più rigidità.
La scelta come conseguenza, non come premessa
A queste variabili se ne aggiungono altre: la natura del dato, editoriale e ricco di respiro oppure strutturato e quantitativamente ingente; l'approvvigionamento del contenuto, con cataloghi prodotto che dovrebbero risiedere in un PIM a monte anziché dentro il CMS; le integrazioni con CRM, aree riservate e sistemi di Digital Asset Management per foto, video e streaming generati nella versione corretta per ogni contesto d'uso. Ogni scelta è una bilancia: per ottenere qualcosa si cede qualcos'altro, che sia costo, tempo, performance o semplicità di gestione. Mettendo in fila sette, otto, dieci di questi parametri, anche solo con carta e penna su un tovagliolo, ogni piattaforma trova la sua posizione in un grafico: WordPress da una parte, Drupal dall'altra, e via dicendo.
Quando si sa dove si collocano tutti gli strumenti, diventa semplice individuare l'area in cui il proprio progetto vuole stare e scegliere tra le opzioni che vi rientrano. Ecco perché la scelta della piattaforma tecnologica dovrebbe essere una conseguenza del progetto, non una sua premessa: partire dallo strumento significa subire vincoli che possono pesare sulla riuscita. L'unica eccezione sono i vincoli reali e dichiarati fin dal brief — le linee guida di un fondo, o un sistema aziendale già integrato troppo costoso da ricostruire — che vanno distinti da semplici desiderata. Non esiste una risposta valida in un nanosecondo, ma esiste un metodo: mappare gli assi di valutazione, collocare il proprio progetto e scegliere di conseguenza.