Votre site de production fonctionne sur Drupal 7, et depuis le 5 janvier 2025, il ne reçoit plus de correctifs de sécurité. Pas de correctifs d'urgence. Pas de sauvetage communautaire. Pas d'extensions supplémentaires. J'ai guidé six équipes d'entreprise à travers cette migration au cours des dix-huit derniers mois, et le modèle est clair : celles qui l'ont traité comme une case à cocher du Q4 ont payé 40-60% plus cher que celles qui ont planifié six mois à l'avance. La taxe de délai est réelle — non seulement en termes de dollars, mais en dette technique que vos ingénieurs hériteront s'ils sont forcés de livrer une migration en huit semaines au lieu de vingt. C'est le guide que je remets à chaque VP of Engineering au moment où il admet que Drupal 7 alimente toujours sa propriété phare. Vous n'êtes pas en retard encore, mais la fenêtre se ferme plus vite que votre feuille de route ne l'admet.

Table des matières

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

Ce que la Fin de Vie de Drupal 7 signifie réellement

Soyons précis sur ce que « fin de vie » signifie en pratique, car j'ai vu beaucoup de confusion ici :

  • Plus de mises à jour de sécurité. L'équipe de sécurité de Drupal n'émettra plus de bulletins de sécurité ou de correctifs pour le noyau Drupal 7 ou les modules contrib. Si une vulnérabilité critique d'injection SQL est découverte demain, vous êtes livré à vous-même.
  • Plus de corrections de bogues. Tout ce qui est cassé reste cassé.
  • Les mainteneurs de modules contrib se concentrent sur d'autres choses. La plupart l'ont déjà fait. De nombreux modules Drupal 7 populaires n'ont pas reçu de mise à jour depuis des années.
  • Les fournisseurs d'hébergement vont abandonner le support. Pantheon, Acquia et Platform.sh ont tous annoncé des calendriers pour déprécier les environnements d'hébergement Drupal 7. Acquia a prolongé son support Drupal 7 jusqu'en 2026 pour les clients existants, mais c'est un module complémentaire payant, pas une solution à long terme.
  • Les problèmes de compatibilité PHP vont s'aggraver. Drupal 7 a été construit pour PHP 5.x. Il s'exécute sur PHP 8.1 avec des correctifs, mais PHP 8.1 lui-même atteint la fin de vie en décembre 2025. Vous empilerez des logiciels non supportés sur d'autres logiciels non supportés.

Le seul risque de sécurité devrait suffire à déclencher une action. Si votre organisation traite une quelconque forme de données personnelles, de données financières ou de données de santé, l'exécution de Drupal 7 sans correctifs est une responsabilité en matière de conformité. PCI DSS, HIPAA, SOC 2 — elles exigent toutes que vous mainteniez des logiciels correctifs et supportés.

Pourquoi les équipes d'entreprise ont continué à repousser

J'ai eu cette conversation des dizaines de fois. Les raisons sont toujours une variation de :

  1. « Notre site Drupal 7 fonctionne très bien. » C'est vrai. Jusqu'à ce qu'il ne fonctionne plus. Le code ne cessera pas de fonctionner le 6 janvier, mais le profil de risque change considérablement.
  2. « La migration vers Drupal 8/9/10 n'est pas une simple mise à niveau. » C'est effectivement vrai. Contrairement au chemin de mise à niveau Drupal 6→7, passer de Drupal 7 à Drupal moderne est essentiellement une reconstruction. L'architecture est fondamentalement différente — basée sur Symfony, gestion de la configuration, templates Twig. Vos modules personnalisés ne porteront pas.
  3. « Nous avons 15 ans de contenu et de fonctionnalités personnalisées. » Les sites Drupal 7 d'entreprise ont tendance à être fortement personnalisés. Modules personnalisés, configurations Views, structures de taxonomie complexes, intégrations avec des systèmes hérités. La portée de la migration est véritablement importante.
  4. « Le budget n'a pas été approuvé. » La réponse la plus honnête, et la plus courante.

Aucune de ces raisons n'a disparu, mais la date limite est arrivée. Parlons donc de ce qu'il faut vraiment faire.

Vos options de migration en 2026

Vous avez quatre chemins réalistes à suivre. Chacun a des compromis. Permettez-moi de les décomposer honnêtement.

Option Calendrier Plage de coûts Idéal pour Niveau de risque
Drupal 10/11 6-18 mois 200 K$-1 M$+ Équipes investies dans l'écosystème Drupal Moyen
Frontend Headless + Backend Drupal 4-12 mois 150 K$-600 K$ Équipes voulant une UX moderne avec un CMS familier Moyen
Migration vers un CMS Headless 3-9 mois 100 K$-500 K$ Équipes prêtes à quitter complètement Drupal Moyen-Élevé
Fournisseur de support étendu Immédiat 30 K$-100 K$/an Équipes ayant besoin de 6-18 mois supplémentaires de temps de planification Bas (court terme)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

Option 1 : Migrer vers Drupal 10/11

Drupal 10 est la version stable actuelle en 2026, avec Drupal 11 libéré à la mi-2024 et gagnant une adoption solide. Si votre équipe connaît Drupal, votre modèle de contenu est solide et vous voulez rester dans l'écosystème, c'est le chemin le plus simple.

Mais « simple » ne signifie pas « facile ».

Ce que la migration implique vraiment

Drupal fournit une API Migrate qui peut extraire du contenu d'une base de données Drupal 7 dans un site Drupal 10/11. D'après mon expérience, elle gère environ 60-70% d'une migration typique. Le reste est des plugins de migration personnalisés pour :

  • Les types de champs personnalisés
  • Les références d'entités complexes
  • Les paragraphes (si vous avez utilisé le module Paragraphs)
  • Les fichiers et les assets médias
  • Les alias d'URL et les redirections
  • Les comptes utilisateur et les rôles

Vos modules personnalisés doivent être réécrits. Pas portés — réécrits. Drupal 10/11 utilise une architecture complètement différente. Si vous aviez un module personnalisé qui se connectait à hook_node_view(), vous écrivez maintenant des abonnés à des événements et des plugins.

// Drupal 7 - basé sur les hooks
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, basé sur Symfony
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Votre logique ici
    }
  }
}

La couche de templates Twig est également complètement différente de PHPTemplate. Chaque thème personnalisé doit être reconstruit.

Calendrier réaliste

Pour un site d'entreprise de taille moyenne (500-5 000 pages, 10-20 types de contenu, 5-10 modules personnalisés), attendez-vous à 9-15 mois. Cela inclut la découverte, la modélisation de contenu, le développement, la migration de contenu, l'assurance qualité et le lancement.

Option 2 : Passer à une architecture headless avec un frontend moderne

C'est là que les choses deviennent intéressantes, et franchement, c'est l'approche que je recommande le plus souvent aux équipes d'entreprise en 2026. Conservez Drupal comme backend de contenu (mis à niveau vers Drupal 10/11), mais construisez le frontend avec un framework JavaScript moderne.

Drupal 10/11 a un excellent support JSON:API intégré au noyau. Vous pouvez exposer votre contenu sous forme de données structurées et le consommer avec Next.js, Astro ou tout autre framework frontend.

Pourquoi cette approche fonctionne bien

  • Votre équipe éditoriale garde l'interface administrateur de Drupal. Elle la connaît. Elle est productive dedans. Arracher cela provoque une douleur organisationnelle.
  • Votre frontend devient dramatiquement plus rapide. Génération statique, mise en cache des bords, optimisation moderne des images — des choses qui sont douloureuses à ajouter à la couche de rendu de Drupal.
  • Vous pouvez migrer progressivement. Lancez le nouveau frontend à côté de l'ancien site et migrez les sections une à la fois.

Nous avons construit plusieurs frontends Drupal headless avec Next.js et Astro, et les améliorations de performance sont substantielles. Un client a vu sa Largest Contentful Paint passer de 4,2s à 0,8s après être passé à un frontend Next.js avec ISR (Incremental Static Regeneration).

// Page Next.js récupérant depuis le JSON:API de Drupal
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR : régénérer toutes les 60 secondes
  };
}

Le paquet next-drupal (maintenu par Chapter Three) rend cela encore plus facile avec un support intégré pour le mode aperçu, l'authentification et le mappage des types de contenu.

Le hic

Vous devez toujours migrer Drupal 7 vers Drupal 10/11 sur le backend. Vous ne contournez pas ce travail. Mais vous découplez le frontend de la reconstruction, ce qui vous donne plus de flexibilité dans la séquence.

Option 3 : Migrer complètement vers un CMS headless

Parfois, le bon choix est de quitter complètement Drupal. Si votre équipe n'a pas une forte expertise en Drupal, si vous avez du mal à embaucher des développeurs Drupal (et vous en avez — le bassin de talents Drupal a considérablement rétréci depuis 2020), ou si votre modèle de contenu a dépassé ce que Drupal fait bien, un CMS headless pourrait être le bon choix.

Cibles de migration populaires

CMS Tarification (2026) Idéal pour API de contenu Courbe d'apprentissage
Contentful 300$-2 500$/mois+ Grandes équipes éditoriales GraphQL + REST Moyen
Sanity 99$-949$/mois+ (personnalisé entreprise) Équipes dirigées par des développeurs GROQ + GraphQL Bas-Moyen
Storyblok 109$-449$/mois+ Besoins d'édition visuelle REST + GraphQL Bas
Strapi (auto-hébergé) Gratuit (auto-hébergé) / 29$/mois+ (cloud) Équipes voulant le contrôle REST + GraphQL Moyen
Payload CMS Gratuit (auto-hébergé) / 35$/mois+ (cloud) Équipes axées sur TypeScript REST + GraphQL Moyen

Nous travaillons avec plusieurs d'entre eux à travers notre pratique de développement CMS headless. Le bon choix dépend des compétences techniques de votre équipe, de la complexité du contenu et du budget.

Migration de contenu de Drupal 7 vers un CMS headless

C'est en fait plus facile qu'une migration vers Drupal 10/11 à certains égards. Vous n'êtes pas limité par le cadre de migration de Drupal. L'approche typique :

  1. Exporter le contenu Drupal 7 via Drush ou des requêtes de base de données directes
  2. Transformer les données dans le modèle de contenu de votre CMS cible à l'aide de scripts (Python et Node.js fonctionnent tous les deux bien)
  3. Importer via l'API de gestion du CMS
  4. Vérifier et corriger les références, les médias et les relations
# Export de contenu simple Drupal 7 via base de données
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

La partie difficile n'est pas l'export. C'est le mappage du modèle de contenu de Drupal 7 (avec son système de champs, les références d'entités, les termes de taxonomie et les Paragraphs) aux structures de données d'un nouveau CMS. Prévoyez que cela prend un temps d'analyse significatif.

Option 4 : Fournisseurs de support étendu (Gagner du temps)

Si vous avez vraiment besoin de plus de temps — et parfois c'est le cas, surtout avec les cycles budgétaires et les priorités organisationnelles — les fournisseurs de support étendu peuvent maintenir votre site Drupal 7 correctif pendant que vous planifiez.

Principaux fournisseurs offrant un support étendu Drupal 7

  • Tag1 Consulting — L'un des plus établis. Ils rétroportent les correctifs de sécurité et fournissent une maintenance continue. La tarification varie selon la complexité du site, mais attendez-vous à 30 K$-80 K$/an.
  • Acquia — Offre un support étendu Drupal 7 via sa plateforme, actuellement jusqu'en 2026 pour les clients d'entreprise.
  • mySociety / D7 LTS Contributors — Support étendu communautaire via le programme de support étendu Drupal 7.

C'est une stratégie de pont légitime, pas une solution à long terme. Je la plafonnais à 12-18 mois maximum. Chaque mois que vous restez sur Drupal 7 augmente la complexité de votre migration à mesure que l'écart entre D7 et les plateformes modernes s'élargit.

Planification de la migration : Un cadre étape par étape

Voici le cadre que j'utilise avec chaque migration d'entreprise. Ce n'est pas glamour, mais ça marche.

Phase 1 : Audit (2-4 semaines)

  • Audit de contenu : Combien de types de contenu ? Combien de nœuds par type ? Quelle est la complexité du modèle de contenu ? Utilisez-vous des Paragraphs, des Field Collections, des Entity References ?
  • Audit de modules : Listez chaque module contrib et personnalisé. Catégorisez comme : a l'équivalent D10, a besoin de remplacement personnalisé, peut être éliminé. J'utilise drush pm:list --status=enabled et j'effectue une référence croisée avec drupal.org.
  • Audit d'intégration : Avec quels systèmes externes Drupal communique ? Passerelles de paiement, CRM, automatisation du marketing, fournisseurs SSO ?
  • Baseline de trafic et de performance : Documentez les mesures de performance actuelles. Vous en aurez besoin pour la comparaison.
  • Audit des rôles utilisateur : Combien de workflows éditoriaux existent ? Quelles permissions ont de l'importance ?

Phase 2 : Décision architecturale (2-3 semaines)

En fonction de votre audit, décidez laquelle des quatre options est la bonne. C'est une véritable décision architecturale qui devrait impliquer le leadership technique, les parties prenantes du contenu et celui qui contrôle le budget.

Phase 3 : Preuve de concept (3-6 semaines)

Avant de vous engager dans une migration complète, construisez une preuve de concept qui couvre :

  • 2-3 types de contenu migrés vers la nouvelle plateforme
  • Le flux de travail éditorial le plus complexe reproduit
  • Une intégration critique connectée
  • Des benchmarks de performance sur la nouvelle pile

C'est là que vous découvrirez les choses que personne n'a mentionnées lors de l'audit. Il y a toujours quelque chose.

Phase 4 : Migration complète (3-12 mois)

C'est le travail proprement dit. Priorisez impitoyablement. Pas tout ce qui vient de Drupal 7 ne doit suivre. D'après mon expérience, 20-30% du contenu et des fonctionnalités sur un site Drupal 7 d'entreprise typique peuvent être éliminés lors de la migration.

Phase 5 : Assurance qualité et lancement (2-4 semaines)

Les redirections sont essentielles. Chaque URL de votre site Drupal 7 qui a une équité de recherche a besoin d'une redirection 301 vers le nouveau site. Utilisez les exports de modules path_redirect et globalredirect comme point de départ, puis explorez l'ancien site avec Screaming Frog pour construire une carte de redirection complète.

Stratégie de migration de contenu

La migration de contenu mérite sa propre section car c'est là que la plupart des migrations deviennent difficiles.

Le problème du champ body

Les champs body Drupal 7 sont généralement un désordre HTML. Vous trouverez des styles inline, des chemins d'image codés en dur, des iframes intégrées et occasionnellement du PHP brut (si quelqu'un a activé le module de filtre PHP — une véritable horreur de sécurité). Avant de migrer, vous devez décider : le nettoyer ou porter le désordre ?

Ma recommandation : nettoyez-le. Écrivez des scripts de transformation qui :

  • Supprimez les styles inline
  • Convertissez les balises <img> en références média appropriées
  • Réparez les liens internes pour utiliser la nouvelle structure d'URL
  • Convertissez tous les jetons d'intégration WYSIWYG au nouveau format

Migration de médias

Les sites Drupal 7 gèrent les médias de façons très différentes. Certains utilisent le module Media (1.x ou 2.x), d'autres utilisent des champs de fichiers simples, d'autres utilisent des jetons de médias intégrés dans des champs body. Mappez chaque modèle de gestion de médias avant de commencer à écrire du code de migration.

Si vous migrez vers un CMS headless, vous devrez également décider où les fichiers multimédias se trouvent. La plupart des CMS headless ont une gestion des assets intégrée, ou vous pouvez utiliser un DAM comme Cloudinary ou imgix.

Contenu multilingue

Si votre site Drupal 7 utilise i18n, entity_translation ou content_translation, la complexité de la migration double à peu près. Le système multilingue de Drupal 7 était... appelons ça « créatif ». Les structures de données sont incohérentes et nécessitent un mappage prudent.

Estimations de coût et de calendrier

Je vais vous donner de vrais chiffres basés sur des projets auxquels j'ai participé ou dont j'ai une connaissance directe.

Complexité du site Migration Drupal 10/11 Migration vers CMS Headless Frontend Headless + Backend Drupal
Petit (5-10 types de contenu, <1 K pages, 2-3 modules personnalisés) 80 K$-150 K$, 3-6 mois 60 K$-120 K$, 2-4 mois 100 K$-180 K$, 3-6 mois
Moyen (10-20 types de contenu, 1 K-10 K pages, 5-10 modules personnalisés) 200 K$-500 K$, 6-12 mois 150 K$-350 K$, 4-8 mois 200 K$-450 K$, 5-10 mois
Grand (20+ types de contenu, 10 K+ pages, 10+ modules personnalisés, multilingue) 500 K$-1,5 M$+, 12-24 mois 300 K$-800 K$, 6-14 mois 400 K$-1 M$+, 8-18 mois

Ces chiffres sont entièrement chargés et incluent la découverte, le développement, la migration, l'assurance qualité et la gestion de projet. Vos résultats varieront en fonction de la composition de l'équipe (interne vs agence), de la localisation géographique et de la quantité de nettoyage que vous effectuez par rapport à l'import tel quel.

Voulez-vous obtenir une estimation plus spécifique pour votre situation ? Nous effectuons des évaluations de migration qui vous donnent une image claire de la portée et du coût.

Erreurs courantes que j'ai vues des équipes commettre

Essayer de faire une récréation 1:1. Votre site Drupal 7 a accumulé 10+ ans de débris. Ne migrez pas tout. Utilisez la migration comme une opportunité de simplifier.

Sous-estimer l'effort de redirection. J'ai travaillé sur une migration où l'équipe a oublié les redirections jusqu'à deux semaines avant le lancement. Ils avaient 45 000 URL à mapper. Ne soyez pas cette équipe.

Ne pas impliquer les parties prenantes éditoriales assez tôt. Les personnes qui utilisent le CMS au quotidien auront des opinions fermes sur le nouveau système. Impliquez-les en Phase 1, pas en Phase 4.

Choisir une plateforme basée sur les fonctionnalités, pas sur la capacité de l'équipe. Le meilleur CMS est celui que votre équipe peut réellement maintenir. Si vous n'avez pas d'expertise en Drupal, migrer vers Drupal 10/11 sans embaucher pour cela, c'est configurer une répétition de cette situation dans 5 ans.

Exécuter des systèmes parallèles trop longtemps. Définissez une date de basculement dure. Exécuter l'ancien et le nouveau en parallèle est coûteux et confus.

Ignorer le gel du contenu. Pendant la phase de migration finale, vous avez besoin d'un gel du contenu sur l'ancien site. Planifiez-le. Communiquez-le. Les auteurs de contenu le détestent, mais c'est nécessaire pour garantir que rien n'est perdu.

FAQ

Que se passe-t-il si je continue à exécuter Drupal 7 après la fin de vie ?

Votre site ne cessera pas soudainement de fonctionner. Mais vous ne recevrez aucun correctif de sécurité, ce qui signifie que les vulnérabilités nouvellement découvertes resteront sans correctif indéfiniment. C'est un véritable risque — les sites Drupal sont des cibles fréquentes pour les attaques automatisées. Vous ferez également face à des problèmes de compatibilité croissants à mesure que les versions PHP avancent et que les fournisseurs d'hébergement abandonnent le support des versions PHP plus anciennes. Pour toute organisation ayant des exigences de conformité (PCI, HIPAA, SOC 2, RGPD), exécuter des logiciels non supportés est une violation directe.

Puis-je effectuer une mise à niveau directe de Drupal 7 vers Drupal 11 ?

Oui, l'API Migrate supporte la migration directe de Drupal 7 vers Drupal 10 ou 11. Vous n'avez pas besoin de passer par Drupal 8 et 9. Cependant, ce n'est pas une « mise à niveau » au sens traditionnel — c'est une reconstruction de votre site sur la nouvelle plateforme avec la migration de contenu. Vos thèmes, modules personnalisés et configurations ne se transfèrent pas directement.

Combien de temps prend généralement une migration Drupal 7 ?

Pour un site d'entreprise de taille moyenne, prévoyez 6-12 mois entre le démarrage et le lancement. Les sites plus petits avec une fonctionnalité personnalisée limitée peuvent être fait en 3-4 mois. Les sites grands et complexes avec du contenu multilingue, des intégrations étendues et une lourde personnalisation peuvent prendre 12-24 mois. La phase d'audit vous donnera une estimation beaucoup plus précise pour votre situation spécifique.

Vaut-il la peine de migrer vers Drupal 10/11, ou dois-je changer de plateforme CMS ?

Cela dépend de votre équipe et de vos besoins. Si vous avez une expertise en Drupal en interne, votre modèle de contenu convient bien au système d'entités de Drupal et vous avez besoin des forces de Drupal (permissions complexes, multilingue, multi-site), alors rester dans l'écosystème a du sens. Si vous avez du mal à embaucher des développeurs Drupal, votre site est principalement un site marketing sans workflows éditoriaux complexes ou vous voulez passer à une architecture headless, un CMS différent pourrait être un meilleur investissement.

Quelle est l'option la moins chère pour migrer de Drupal 7 ?

Le support étendu d'un fournisseur comme Tag1 (30 K$-80 K$/an) est l'option la moins chère à court terme, mais cela ne résout pas le problème sous-jacent. Pour une migration réelle, passer à un CMS headless comme Sanity ou Storyblok avec un frontend statique tend à être le chemin le plus économe pour les sites simples, à partir d'environ 60 K$-120 K$. Consultez notre page de tarification pour plus de détails sur la façon dont nous structurons les projets de migration.

Mon classement SEO sera-t-il affecté par la migration ?

Ils peuvent l'être, mais une planification appropriée minimise l'impact. Les facteurs critiques sont : maintenir les structures d'URL (ou implémenter des redirections 301 appropriées pour chaque URL indexée), préserver les métadonnées et les balisages de données structurées, s'assurer que le nouveau site se charge au moins aussi vite que l'ancien (idéalement plus rapide), et soumettre les plans de site mise à jour à Google Search Console. J'ai vu des migrations bien exécutées améliorer les résultats SEO en raison d'une meilleure vitesse de page et d'une meilleure expérience mobile. J'ai également vu des migrations ratées réduire le trafic de 50% parce que quelqu'un a oublié les redirections.

Puis-je migrer le contenu progressivement ou doit-ce être tout à la fois ?

La migration progressive est possible et souvent préférable pour les sites grands. Avec une architecture headless, vous pouvez lancer le nouveau frontend et migrer les sections du site une à la fois, en utilisant les règles de proxy inverse pour acheminer le trafic vers le backend approprié. Cela réduit le risque et vous permet de valider chaque section avant de continuer. Le compromis est une complexité opérationnelle accrue pendant la période de migration.

Devrais-je considérer WordPress comme une cible de migration ?

WordPress est une option viable pour les sites plus simples, mais j'hésiterais pour les cas d'usage d'entreprise. Si votre site Drupal 7 a des types de contenu complexes, des permissions granulaires ou des workflows éditoriaux sophistiqués, WordPress semblera une régression. Le modèle de contenu de WordPress (articles, pages et types de publication personnalisés) est plus simple que le système d'entités de Drupal. Pour les équipes d'entreprise, je regarderais plus sérieusement Drupal 10/11 ou un véritable CMS headless. Cela dit, WordPress avec ACF Pro et un frontend headless peut fonctionner bien pour les sites axés sur le marketing.