Agnòstics amb un favorit: com triem la plataforma d'una web

Ens agrada presentar-nos com a agnòstics en tecnologia. Amb els nostres números, aquesta afirmació necessita una explicació. Fa més de quinze anys que construïm webs (el projecte més antic que conservem a l’arxiu és de finals de 2010) i en aquest temps hem treballat amb més de 350 organitzacions: hospitals i centres de recerca com Sant Joan de Déu o Vall d’Hebron, farmacèutiques com Bioibérica o Ferrer, universitats i escoles com la UB, la UPC, la URL, la UdG, ESADE o els Jesuïtes, infraestructures com el Port de Barcelona, indústria com Ercros o Grupo Ehlis, i institucions com el CERN, la CEOE o la Diputació de Barcelona. En nou de cada deu casos, la plataforma va ser Drupal.

Un agnòstic amb aquesta distribució és, o algú que s’enganya, o algú amb una mostra esbiaixada. Acceptem la segona opció i explicarem el mecanisme, perquè el mecanisme és el que és útil. La preferència, sola, no serveix a ningú.

El favorit que va perdre el nostre propi projecte

Comencem per l’excepció més visible. Quan va tocar decidir sobre què construir aquesta web, Drupal va perdre. Aquí edita una persona, no hi ha fluxos d’aprovació, el contingut no té obligacions legals especials, i volíem un laboratori on provar arquitectura desacoblada i una integració forta d’IA tant en el desenvolupament com en la gestió de continguts. Amb aquest perfil, muntar Drupal hauria estat el mateix sobredimensionament que retraiem a qui implanta un ERP per portar tres factures.

Això no és una anècdota simpàtica: és la regla aplicada a casa abans de vendre-la a fora. I és també la raó per la qual el “nou de cada deu” no ens converteix en fanàtics. La desena vegada existeix, i quan apareix, la prenem.

Triar plataforma són dues decisions disfressades d’una

La primera decideix en quina família d’eines jugues. La segona decideix quina eina, dins d’aquesta família, aguanta el teu cas sense trencar-se ni sobrar.

Primera decisió: què estàs disposat a llogar

Una plataforma propietària, sigui una suite tipus Adobe Experience Manager o Sitecore o un SaaS tipus Contentful o HubSpot, et lloga les quatre coses alhora: codi, dades en el seu format, arquitectura i proveïdor. Pot ser una decisió perfectament raonable si tens el pressupost i acceptes que el full de ruta el marqui un altre. El codi obert et lliura la propietat, amb un preu que convé dir en veu alta: la despesa no desapareix, es trasllada de la llicència al desenvolupament i al talent. El que compres amb la diferència és portabilitat, absència de renda perpètua i la certesa que ningú no et pot retirar el producte.

Aquí convé desfer un malentès habitual. La línia no passa entre “codi obert” i “comercial” en el sentit de gratuït davant de pagament. Typo3 és GPL de dalt a baix i té una fundació al darrere; Liferay té una edició comunitària lliure i una edició comercial a sobre. La pregunta útil és una altra: qui controla la llicència i què pot passar si canvia d’idea.

Directus, el CMS d’aquesta web, és un bon exemple de per què aquesta pregunta importa. Va néixer amb llicència MIT, el 2023 va passar a Business Source License 1.1 (ús lliure per sota de cinc milions de dòlars d’ingressos i prohibició d’ús competitiu, una llicència que l’Open Source Initiative no reconeix com a codi obert) i el 2026 ha obert consulta pública sobre una nova revisió. Ho sabíem en triar-lo i ho vam acceptar: si Directus canvia les regles, nosaltres perdem un cap de setmana de migració. Si això mateix li passa a una universitat amb dos-cents llocs i quinze anys de contingut, és una crisi institucional. Una mateixa decisió pot ser assenyada en un cas i temerària en l’altre. Això, exactament, és el que significa tenir criteri en comptes de tenir favorits.

Una mateixa decisió pot ser assenyada en un cas i temerària en l'altre. Això, exactament, és el que significa tenir criteri en comptes de tenir favorits.

Segona decisió: quanta complexitat cal governar

Amb la família decidida, les preguntes es tornen concretes. Quantes persones editen i amb quins permisos? Quants llocs comparteixen marca, components i usuaris? Quants idiomes, i qui és responsable de cada traducció? Quin contingut necessita aprovació abans de publicar-se i qui la dona? Quines obligacions legals apliquen: accessibilitat exigible des del juny de 2025 per l’EAA amb l’estàndard WCAG 2.1 AA, protecció de dades, traçabilitat de canvis? Amb què s’integra: CRM, DAM, SSO, ERP, comerç? Quant de temps viurà? Qui el mantindrà d’aquí a cinc anys, i en sabrà?

Quan la majoria d’aquestes respostes són “un”, “cap” o “encara no ho sé”, la llista de plataformes raonables és llarga i Drupal gairebé mai no és la millor. Hem construït projectes en WordPress i en altres plataformes més lleugeres amb resultats dels quals no ens avergonyim, i continuarem recomanant-les quan el perfil sigui aquest: un equip editorial petit, un model de contingut simple, poca governança.

Quan les respostes comencen a acumular-se, la llista s’escurça de pressa. I aquí és on apareix Drupal, no perquè sigui millor en abstracte, sinó perquè el que altres plataformes resolen amb plugins de tercers (contingut estructurat amb tipus i camps propis, permisos fins al nivell de camp, revisions i fluxos d’aprovació, multisite, multiidioma) a Drupal forma part del nucli, mantingut pel mateix equip de seguretat que publica els avisos del projecte. Menys peces de tercers significa menys superfície per auditar i menys dependències que es trenquen a cada actualització.

Les dades de mercat expliquen la mateixa història si es miren bé. Segons W3Techs, Drupal està al voltant del 0,7% de tots els llocs web del món. Segons HTTP Archive, entre el 6% i el 7% dels deu mil llocs amb més trànsit. Deu vegades més presència on la web es complica que on la web és una web.

Què és Drupal quan deixa de ser un CMS

Aquesta mateixa arquitectura és la raó per la qual Drupal apareix en projectes que no encaixen en l’etiqueta de “gestor de continguts”. Sobre el mateix nucli es construeixen botigues (Drupal Commerce), plataformes de formació (Opigno) i comunitats (Open Social), i en els tres casos el model de contingut, els permisos i els fluxos són els mateixos que governen la web pública. Un hospital pot tenir web, intranet i portal de pacients amb un sol model d’usuaris; una universitat, cent llocs de facultats amb marca comuna i autonomia editorial.

I es pot servir acoblat, amb Drupal renderitzant les pàgines, o desacoblat, amb Drupal com a font de contingut per a un frontend en el framework que l’equip prefereixi. Les dues opcions conviuen en el mateix projecte, i la decisió es pren per equip i per cas d’ús, no per moda.

Quan recomanem una altra cosa

A més de la nostra pròpia web, hi ha tres situacions en què Drupal surt de la conversa. La primera, ja dita: projecte editorial senzill, un editor, vida curta. La segona: el client té un requisit de plataforma que no discutirem, perquè forma part de la seva estratègia de sistemes i no de la nostra opinió. La tercera és la més instructiva: llocs desenvolupats a mida per tercers en què hem hagut d’intervenir. Aquí vam aprendre l’argument invers a la propietat. Posseir el codi no serveix de res si l’única persona que l’entenia ja no hi treballa. Un desenvolupament propi és propietat sense comunitat, i la comunitat (desenes de milers de contribuïdors, documentació, avisos de seguretat, talent contractable) és el que fa que la propietat sigui mantenible.

Els propers editors de la teva web no seran persones

Hi ha un motiu més per prendre’s seriosament la segona decisió, i apunta al futur immediat. Els següents a editar contingut a la teva web no seran només persones: seran agents d’IA que generen, actualitzen i publiquen. El nostre propi laboratori ja hi parla: Directus va incorporar suport natiu de Model Context Protocol a finals de 2025, i Drupal també el suporta. La qüestió que s’obre és quin sistema decideix el que un agent pot tocar, amb quina identitat i qui ho revisa. Avancem la resposta: l’arquitectura que governa bé les persones és la que governarà els agents. Ho desenvoluparem en les properes peces d’aquesta sèrie.

Abans de la propera reunió amb un proveïdor

Aquest és el qüestionari que apliquem abans de recomanar una plataforma. Fes-lo servir amb qualsevol proveïdor, nosaltres inclosos.

1. Si demà el propietari de la llicència canvia les condicions, què perdo i en quant de temps?
2. Puc exportar tot el contingut en un format que un altre sistema entengui?
3. Quantes persones editaran, amb quins permisos, i qui aprova què?
4. Quants llocs i idiomes comparteixen aquesta plataforma d’aquí a tres anys?
5. Quines obligacions legals apliquen (accessibilitat, dades, traçabilitat) i qui en respon?
6. Amb quins sistemes s’integra avui, i quins vindran?
7. Quina part del que necessito és al nucli i quina part depèn de tercers?
8. Qui mantindrà això d’aquí a cinc anys, i quant talent hi ha disponible per fer-ho?
9. Què podrà fer un agent d’IA en aquesta plataforma, i qui en decideix els límits?
10. La plataforma que em proposen resol el meu problema, o resol el del proveïdor?

Si en acabar la resposta continua sent Drupal, sabràs per què. I si no ho és, nosaltres també.

Fonts

• W3Techs, Quota de mercat de sistemes de gestió de continguts, 2026 — Drupal al voltant del 0,7% del total de llocs web.
• HTTP Archive, Presència de Drupal al top 10.000 de llocs per trànsit — entre el 6% i el 7%.
• Directus, Why We’re Relicensing Directus (abril 2023) i Changing Our License: One Year Later (2024) — canvi a BSL 1.1 i reconeixement que la BSL no és una llicència aprovada per l’OSI.
• Directiva (UE) 2019/882 (EAA), aplicable des del 28 de juny de 2025 — estàndard harmonitzat EN 301 549 v3.2.1 (WCAG 2.1 AA).