Aller au contenu
tak.tn
← Retour au blog
3 min de lecture

Migrer de Drupal 10 vers Drupal 11 : le guide pratique

#drupal#migration

Drupal 10 arrive en fin de support en décembre 2026. Si votre site tourne encore dessus, vous avez encore le temps de migrer sereinement — à condition de commencer maintenant plutôt qu’au dernier trimestre, quand toutes les agences et tous les freelances Drupal seront saturés.

Bonne nouvelle : contrairement au traumatisme Drupal 7 → 8/9/10, la montée de version 10 → 11 est une mise à jour majeure classique, pas une réécriture. Voici la méthode que j’applique en mission, étape par étape.

1. Faire l’état des lieux avec Upgrade Status

Le module Upgrade Status est votre point de départ. Il analyse le site et répond à trois questions :

  • votre environnement est-il prêt (version de PHP, de la base de données, de Composer) ?
  • vos modules contrib ont-ils une version compatible Drupal 11 ?
  • votre code custom utilise-t-il des APIs dépréciées ?
composer require --dev drupal/upgrade_status
drush en upgrade_status
drush upgrade_status:analyze --all

Exportez le rapport et transformez-le en backlog : chaque ligne est une tâche, avec une gravité et un responsable.

2. Préparer l’environnement

Drupal 11 exige PHP 8.3 et des versions récentes de la base de données. C’est le moment de mettre à niveau vos environnements (local, CI, préproduction, production) — avant la migration, pour isoler les problèmes. Si votre hébergement ne suit pas, le sujet est là, pas dans Drupal.

3. Nettoyer avant de monter

Une règle d’or que j’applique sur chaque mission : on ne migre pas ce qui ne sert plus.

  • Désinstallez les modules inutilisés (vraiment désinstallés, pas juste désactivés).
  • Supprimez les thèmes morts et le code commenté « au cas où ».
  • Auditez les patches Composer : beaucoup sont devenus inutiles.

Chaque module retiré, c’est du risque et du temps de migration en moins.

4. Corriger les deprecations avec Rector

Pour le code custom, Drupal Rector automatise une grande partie des corrections :

composer require --dev palantirnet/drupal-rector
vendor/bin/rector process web/modules/custom --dry-run

Ce qui reste après Rector se corrige à la main — c’est en général là que se cachent les vrais sujets (APIs retirées, hooks réorganisés, changements de constructeurs de services).

5. Traiter la contrib au cas par cas

Trois situations possibles pour chaque module contrib :

  1. Version compatible disponible : mettez à jour, testez, passez au suivant.
  2. Compatibilité en cours : il existe souvent une merge request fonctionnelle dans la file d’issues. En tant que mainteneur de 24 modules, je peux vous le confirmer : tester et commenter ces MRs fait gagner du temps à tout le monde — et lenient permet de les utiliser proprement en attendant.
  3. Module abandonné : cherchez le remplaçant moderne, ou interrogez-vous — si personne ne le maintient, en avez-vous vraiment besoin ?

6. Migrer, tester, basculer

La montée elle-même est une simple formalité quand tout ce qui précède est fait :

composer require drupal/core-recommended:^11 drupal/core-composer-scaffold:^11 --update-with-all-dependencies
drush updb
drush cr

Ensuite, la vraie valeur est dans la recette : parcours critiques testés avec les équipes métier, comparaison des pages clés, vérification des exports/APIs, plan de retour arrière documenté.

7. Ne sacrifiez pas votre SEO à la bascule

C’est l’angle mort de la plupart des migrations, et la raison pour laquelle je traite chaque migration aussi comme un projet SEO :

  • inventaire des URLs et des positions avant la bascule (crawl + Search Console) ;
  • toute URL qui change reçoit une redirection 301 — page à page, pas vers l’accueil ;
  • vérification des balises meta, canoniques, hreflang et données structurées à l’arrivée ;
  • suivi de la couverture d’index dans Search Console pendant les semaines qui suivent.

Une migration technique réussie qui perd 40 % de trafic organique n’est pas une migration réussie.

Combien de temps prévoir ?

Ordre de grandeur constaté en mission : de quelques jours pour un site vitrine bien entretenu à plusieurs semaines pour une plateforme riche en code custom et en contrib exotique. L’audit de l’étape 1 vous donne la réponse pour votre site en une journée.


Vous voulez un état des lieux avant de vous lancer, ou déléguer la migration complète ? Parlons-en — je fais ça toute l’année.

Un projet Drupal ou un besoin SEO technique ?

Parlons-en. Réponse sous 24 h ouvrées, sans engagement.

Me contacter