Du 28 septembre au 1er octobre 2026, DrupalCon Rotterdam consacre un parcours entier à la question : « Digital Sovereignty & Open Web ». Ce n'est pas un signal anodin. La communauté Drupal reconnaît que la licence seule ne suffit plus à définir ce que signifie contrôler son système numérique.
Pour les organisations du secteur public, les collectivités et les entreprises qui traitent des données sensibles, cette nuance est essentielle. Drupal est open source depuis 2001. Mais la souveraineté numérique, elle, ne se prononce pas sur une licence : elle se mesure sur chaque composant de la pile, de l'infrastructure d'hébergement jusqu'au modèle d'IA qui alimente les modules.
Cet article cartographie ce que la licence GPL garantit réellement, ce qu'elle ne couvre pas, et les dépendances qui restent à arbitrer. À la fin, une grille d'audit directement applicable à votre contexte.
Ce que la licence GPL garantit
La licence GPL (General Public License) sous laquelle Drupal est distribué offre quatre protections concrètes.
Accès au code source. Quiconque reçoit un logiciel sous GPL peut en obtenir le code complet. Pas de boîte noire, pas de comportement opaque impossible à vérifier.
Liberté de modifier. Vous pouvez adapter Drupal à vos besoins métier sans demander d'autorisation à un éditeur. Les modifications ne vous appartiennent pas à titre exclusif, mais vous les contrôlez tant qu'elles restent dans votre périmètre.
Redistribution sous les mêmes termes. Un module ou un thème distribué doit rester sous GPL. C'est ce qui protège l'écosystème contre les bifurcations propriétaires qui enfermeraient les utilisateurs.
Absence de dépendance contractuelle envers un éditeur unique. Avec Drupal, il n'y a pas de renouvellement de licence à négocier, pas de clause de renchérissement, pas de condition unilatérale modifiable à la prochaine version.
Ces quatre garanties sont réelles et solides. Mais elles concernent le CMS, pas le système dans lequel il s'insère.
Ce que la licence ne garantit pas
Une organisation peut déployer Drupal sous GPL et pourtant dépendre entièrement d'infrastructures sur lesquelles elle n'a aucun contrôle. Voici les cinq couches concernées.
Hébergement
Drupal tournant sur une instance AWS, Azure ou Google Cloud est Drupal sous licence libre — hébergé dans une infrastructure soumise au droit de l'État du fournisseur. Pour les organisations françaises traitant des données à haute sensibilité, cette question n'est plus théorique : la qualification SecNumCloud de l'ANSSI exige que les prestataires cloud soient immunisés contre toute demande de communication extra-européenne. Un cloud non qualifié, même excellent sur le plan technique, peut exposer vos données à des réquisitions étrangères.
L'ANSSI recense actuellement 17 prestataires en cours de qualification SecNumCloud, dont OVH SAS, Orange Business et Scaleway. Ce chiffre illustre que l'offre qualifiée existe, mais reste plus étroite que l'offre globale.
Fournisseurs d'IA
Les modules d'IA pour Drupal (génération de résumés, suggestions de contenu, chatbot éditorial) appellent des API externes : OpenAI, Anthropic, Google, et d'autres. Ces API transmettent des données — parfois des données de production — vers des serveurs hors UE.
L'initiative AI de la communauté Drupal a précisément pour objectif de rendre ces modules indépendants du modèle d'IA sous-jacent, en définissant des interfaces communes et des garde-fous de gouvernance. Cette approche, discutée lors de l'Enterprise AI Summit à DrupalCon Rotterdam 2026, rend possible le remplacement d'un fournisseur par un autre, ou par un modèle auto-hébergé. Mais cette flexibilité n'est pas automatique : elle suppose une configuration délibérée et un choix de fournisseur compatible avec vos exigences de localisation des données.
Modules contrib non maintenus
L'écosystème Drupal compte plus de 50 000 modules contrib sur drupal.org. La majorité sont maintenus activement. Certains ne le sont plus.
Un module non maintenu est une dépendance ouverte : pas de correctif de sécurité, pas de compatibilité garantie avec les prochaines versions de Drupal, comportement inconnu face aux nouvelles exigences réglementaires. Pour un cms souverain, les dépendances open source non maintenues sont un vecteur de risque aussi réel qu'un contrat avec un fournisseur propriétaire.
CDN tiers
Les CDN (Content Delivery Networks) servent les ressources statiques de votre site : images, CSS, JavaScript. Ils voient aussi les adresses IP de vos visiteurs, parfois leurs comportements de navigation. Cloudflare, Fastly et leurs équivalents ont des présences mondiales et des conditions d'utilisation régies par le droit américain.
Un audit de souveraineté numérique Drupal doit nommer explicitement le CDN utilisé et sa localisation contractuelle des données.
Services SaaS intégrés
Un site Drupal standard en production peut intégrer : un outil d'emailing (Brevo, Mailchimp), un formulaire tiers (Typeform, HubSpot), un analytics (Google Analytics, Hotjar), un système de paiement (Stripe). Chacun de ces services est régi par ses propres conditions et localise des données là où il l'entend.
La licence GPL de Drupal ne dit rien sur aucun de ces composants.
Le cadre réglementaire français : SecNumCloud et doctrine cloud de l'État
Pour les organisations publiques et parapubliques françaises, deux références structurent les choix d'infrastructure.
La qualification SecNumCloud de l'ANSSI définit les exigences qu'un prestataire cloud doit remplir pour être considéré apte à héberger des données sensibles. Le critère central est l'immunité vis-à-vis du droit extra-européen : un prestataire qualifié ne peut pas être contraint de communiquer des données par une juridiction non européenne. La qualification s'applique aux offres IaaS, PaaS et SaaS.
La doctrine « cloud au centre » du gouvernement, pilotée par la DINUM, pose le cloud comme option par défaut pour tout nouveau projet numérique. Elle distingue le cloud interne (interministériel) du cloud commercial de confiance. Pour les données à haute sensibilité (ordre public, sécurité nationale, santé), elle prescrit la qualification SecNumCloud.
Ces deux références ne concernent pas seulement les administrations : elles touchent aussi leurs prestataires et sous-traitants, ainsi que les organisations qui hébergent des données personnelles ou stratégiques au sens du RGPD.
Pour une organisation qui évalue Drupal comme cms souverain pour le secteur public, la question n'est donc pas « Drupal est-il open source ? » — la réponse est oui depuis 25 ans. La question est : « Sur quelle infrastructure, avec quels modules, quels fournisseurs d'IA et quels services tiers ce Drupal va-t-il fonctionner ? »
Grille d'audit des dépendances
L'outil ci-dessous est un point de départ. Il couvre les six couches d'une installation Drupal typique. Chaque ligne doit être renseignée avec vos réponses réelles avant de porter un jugement sur le niveau de souveraineté de votre système.
CoucheQuestions à se poserIndicateurs d'une situation maîtrisée CMS (Drupal)Quelle version ? Qui maintient les modules critiques ? Les modules contrib sont-ils actifs ?Drupal 10/11 à jour, modules contrib maintenus, pas de fork privé non documenté HébergementOù sont physiquement les données ? Le prestataire est-il soumis à un droit extra-européen ?Hébergement UE, prestataire qualifié SecNumCloud ou équivalent selon sensibilité des données Fournisseurs d'IAQuels modules IA sont activés ? Vers quelles API envoient-ils des données ? Les données transmises sont-elles des données de production ?Modules configurés avec un fournisseur à localisation UE ou auto-hébergé, données anonymisées ou chiffrées avant transmission Modules contribQuels modules non maintenus sont en production ? Depuis combien de temps ?Inventaire à jour, aucun module en statut « unsupported » sur des fonctions critiques CDNQuel CDN est utilisé ? Où sont journalisés les accès (IP, comportement) ?CDN avec conditions de traitement des données conformes RGPD, hébergement logs en UE Services SaaS intégrésQuels outils tiers (analytics, emailing, formulaires, paiement) sont connectés ? Où traitent-ils les données ?Chaque service tiers documenté, base légale RGPD établie, localisation des données connueCette grille n'est pas un outil de conformité réglementaire. C'est un outil de visibilité : elle force à nommer les dépendances qui existent déjà, qu'on les ait choisies délibérément ou non.
Ce que cela change concrètement pour un projet Drupal
Un projet Drupal souverain n'est pas plus complexe qu'un projet Drupal standard. Il exige simplement que les décisions d'architecture soient prises en connaissance de cause.
En pratique, cela se traduit par trois choix à documenter avant le démarrage :
- Le prestataire d'hébergement et son statut vis-à-vis des réglementations applicables à vos données.
- La liste des modules IA activés, les API qu'ils appellent, et la politique de données du fournisseur.
- L'inventaire des services SaaS intégrés avec leur localisation contractuelle.
Ces trois points ne sont pas des contraintes supplémentaires. Ce sont des décisions que tout projet sérieux doit prendre de toute façon. Les documenter au moment de l'architecture évite de les découvrir lors d'un audit ou d'un incident.
Pour aller plus loin
Chez DrupaLabs, nous accompagnons les organisations qui veulent construire ou auditer un système Drupal en tenant compte de leurs exigences de souveraineté numérique. Notre point de départ est toujours un diagnostic : comprendre votre contexte, cartographier vos dépendances actuelles, identifier les arbitrages à faire.
La licence open source de Drupal est une fondation solide. Ce qui se construit dessus reste votre décision.