Drupal 7 est en fin de vie. Drupal 8 et 9 aussi. Drupal 10 reçoit ses dernières évolutions. Si vous n'êtes pas encore sur Drupal 11, il est temps d'y réfléchir.
La migration d'un site Drupal n'est pas un projet technique anodin. Selon la version de départ, l'historique du site et la complexité des modules custom, elle peut aller d'une montée de version routinière à un quasi-refonte. La première chose à savoir, c'est dans quelle situation vous êtes — et c'est ce que je vous aide à déterminer.
Drupal 7 a atteint sa fin de vie officielle en janvier 2025. Concrètement : plus de correctifs de sécurité publiés par la communauté, plus de mise à jour des modules contrib, fragilité croissante face aux audits de conformité. Continuer sur D7 reste possible techniquement, mais devient indéfendable côté gouvernance et sécurité.
Drupal 9 a atteint sa fin de support en novembre 2023. Drupal 10 est supporté jusqu'en décembre 2026. Drupal 11 est la version actuelle, sortie en août 2024, et c'est elle qui recevra les évolutions majeures dans les années à venir. Ces échéances ne sont pas une appréciation de ma part : elles sont publiées par le projet lui-même, dans le calendrier officiel des versions de Drupal core (drupal.org, nouvelle fenêtre).
Migrer aujourd'hui vers Drupal 11 vous donne plusieurs années de tranquillité avant la prochaine échéance majeure — Drupal 10, supporté jusqu'en décembre 2026, n'est plus une cible pertinente avant la prochaine échéance majeure. C'est aussi l'occasion de moderniser ce qui mérite de l'être (thème, modules obsolètes, performance) et d'aligner votre stack sur les standards actuels du PHP et de la sécurité web.
Techniquement une refonte plus qu'une migration. L'architecture interne de Drupal a fondamentalement changé entre D7 et D8 (passage à Symfony, configuration en YAML, nouveau système d'entités). On reconstruit, en récupérant contenus, utilisateurs et structure métier.
Durée typique : 1 à 3 mois selon la complexité, avec phase de cohabitation.
Une vraie migration, plus simple que la précédente mais qui demande de la rigueur. Modules contrib compatibles D11, thème adapté, déprécations PHP corrigées, configuration validée. Si le site a été bien maintenu sur D9, quelques semaines suffisent.
Durée typique : 1 à 4 semaines.
Une montée de version routinière, comparable à une mineure. La rupture de compatibilité est limitée. Si le site est à jour côté modules contrib, la bascule se fait en quelques jours de travail effectif.
Durée typique : 2 à 5 jours.
Cinq étapes structurées pour limiter les risques et garantir la qualité du livrable.
J'audite votre site existant : version Drupal, modules utilisés (contrib et custom), thème, intégrations tierces, volume de contenus, dette technique. Je formalise dans un document trois éléments : le périmètre exact de la migration, la stratégie recommandée (migration vs refonte vs hybride), et une estimation de charge avec un planning macro. Vous repartez de cette phase avec une vision claire de ce qui vous attend, indépendamment de votre décision de me confier ou non la suite.
Avant de toucher au site de production, je mets en place l'environnement cible : nouveau dépôt Git, environnement de développement Drupal 10 ou 11, pipelines CI/CD pour le futur déploiement. J'identifie les modules contrib à remplacer (ceux qui n'existent pas dans la version cible) et je réécris les modules custom. Cette phase est invisible pour vos utilisateurs et peut être très longue selon la complexité.
À l'aide du framework Migrate de Drupal (ou de scripts custom pour les cas particuliers), je transfère vos contenus, vos utilisateurs, vos taxonomies, vos médias, vos URLs. Je préserve les liens internes, les redirections. Les tests de migration sont rejoués plusieurs fois sur staging avant la bascule réelle.
La bascule production est planifiée à l'avance avec vous : créneau horaire, communication aux utilisateurs si nécessaire, plan de rollback. La recette se fait en deux temps : recette technique (tests fonctionnels, performance, sécurité) avant la bascule, et recette utilisateur (sur quelques jours) après la bascule, pour traiter les retours.
Le premier mois après la bascule est inclus dans la prestation : correctifs des points remontés, monitoring de la stabilité, ajustements de configuration. À l'issue de ce mois, vous pouvez basculer sur un contrat de maintenance régulier.
Une migration mal conduite peut casser votre référencement, perdre vos contenus, ou rompre vos intégrations. Mes engagements de préservation :
Les prix donnés ci-dessous sont indicatifs et calibrés sur des sites de complexité moyenne. Le devis précis est établi après la phase de cadrage.
| Formule | Charge | Coût |
|---|---|---|
| Drupal 10 → 11 | Charge2 à 5 jours | Coût1 700 à 4 250 € HTVA |
| Drupal 8/9 → 11 | Charge1 à 4 semaines | Coût4 250 à 17 000 € HTVA |
| Drupal 7 → 10/11 | Charge1 à 3 mois | Coût17 000 à 51 000 € HTVA |
La phase de cadrage initiale est facturée 1 500 € HTVA (forfait 2 jours), déductible de la facture finale si la mission se confirme.
Pour les migrations D10→D11 et D9→D11, la bascule peut généralement se faire sans interruption visible (déploiement par blue/green ou rolling update selon votre hébergement). Pour une migration D7→D10/11, je prévois généralement une fenêtre de maintenance courte (1 à 4 heures) en heures creuses, avec une page de maintenance personnalisée.
Oui, et c'est même souvent le bon moment. Le coût marginal d'une refonte graphique pendant une migration D7→D10/11 est limité, puisqu'on reconstruit déjà le thème. Pour les migrations D9→D11 ou D10→D11, on peut conserver le thème existant ou en profiter pour le moderniser, à arbitrer au cadrage.
Si la migration est bien conduite (URLs préservées, redirections en place, balisage technique reconstruit à l'identique), l'impact SEO doit être nul ou positif. La modernisation technique (passage à PHP 8.x, performance, Core Web Vitals) joue souvent en faveur du référencement.
Je peux mener la migration en autonomie quasi complète, mais j'ai besoin de vous pour deux choses : les décisions métier (que faire des contenus obsolètes ? quels modules custom sont encore nécessaires ?) et la recette utilisateur. Le reste — code, infra, déploiement — peut être pris en charge entièrement.
Le cadrage initial de votre migration n'est pas un acte d'engagement. Je préfère vous remettre un document honnête, qui vous donne la mesure du projet, et vous laisser décider ensuite — plutôt que de signer aveuglément.