Votre plateforme Drupal est-elle prête pour 2027 ?
Pourquoi 2027 ? Les jalons à connaître
Drupal 10 atteindra sa fin de vie le 9 décembre 2026. Drupal 12 est actuellement planifié pour la semaine du 7 décembre 2026 selon le calendrier officiel du projet Drupal.
Ces jalons servent à planifier. Ils ne déterminent pas, à eux seuls, la bonne trajectoire pour votre site et ne justifient pas une migration précipitée.
Selon l’état de votre plateforme, la prochaine étape peut être une mise à niveau, une modernisation progressive, une migration plus structurée ou simplement quelques vérifications avant de décider.
Dans quelles situations êtes-vous concerné ?
Un état des lieux peut être utile si :
- vous êtes sur Drupal 7, 8, 9, 10 ou 11 et la prochaine trajectoire n’est pas claire ;
- vous ne connaissez pas précisément la version Drupal ou les dépendances réellement en place ;
- le site fonctionne, mais les évolutions deviennent plus difficiles à prévoir ou à valider ;
- des modules contribués, du code sur mesure ou des intégrations importantes doivent être conservés ;
- une refonte, un changement d’hébergement ou une modernisation est envisagé ;
- vous voulez savoir ce qui doit réellement être vérifié avant d’engager un budget ou un chantier.
Aucune de ces situations ne signifie qu’il faut tout refaire. L’objectif est d’éviter de choisir une trajectoire sur des suppositions.
Les points à vérifier
Une trajectoire Drupal crédible ne se résume pas au numéro de version du CMS. Les vérifications se regroupent en quatre familles lisibles.
1. Socle technique
- version exacte de Drupal Core ;
- PHP et environnement d’exécution ;
- dépendances Composer ;
- base de données et services nécessaires au projet.
2. Application et dépendances
- modules contribués et compatibilité ;
- développements spécifiques ;
- thème et couche front-end ;
- intégrations avec des services ou systèmes externes.
3. Usages, contenus et qualité
- workflows métier critiques ;
- données et modèle de contenu ;
- multilingue ;
- SEO et URLs ;
- performance et accessibilité là où elles affectent les parcours.
4. Capacité à changer de manière contrôlée
- maintenance et suivi de sécurité ;
- sauvegardes et possibilité de rollback ;
- environnements DEV / PREPROD / PROD ;
- tests automatisés et validation humaine ;
- déploiement et contrôles après mise en production.
Pourquoi ce n’est pas juste `composer update`
Composer gère les dépendances d’un projet Drupal moderne. Il ne peut pas, à lui seul, vérifier qu’un développement spécifique reste compatible, qu’une intégration métier fonctionne toujours, que le thème conserve son comportement ou qu’un parcours critique n’a pas régressé. Le bon objectif est de distinguer ce qui peut être mis à jour simplement de ce qui doit être vérifié, adapté ou testé.
Notre méthode en quatre étapes
1. COMPRENDRE
Premier diagnostic + contexte
Comprendre la situation, les objectifs et ce qui mérite réellement d’être vérifié. Un audit technique n’est proposé que s’il apporte une base de décision utile.
2. PRÉPARER
Développement + tests
Traiter les adaptations nécessaires et vérifier les changements avant de les présenter comme prêts.
3. VALIDER
PREPROD + validation humaine
Observer le candidat dans un environnement de validation, contrôler les parcours utiles et décider humainement avant la production.
4. DÉPLOYER & SUIVRE
Mise en production + monitoring
Déployer de manière contrôlée puis vérifier le comportement réel après la mise en production.
Ces quatre étapes sont une présentation commerciale de capacités Agency réellement pratiquées ; elles n’impliquent pas que chaque projet exige le même niveau de dispositif.
Un premier diagnostic gratuit et humain, pas une migration décidée d’avance
- Premier diagnostic gratuit
- revue humaine et faible friction
- pas de scanner automatique ni d’audit exhaustif
- aucun accès au repository ou à la production requis par défaut
- audit payant seulement si utile, sans migration automatique
Le premier diagnostic est gratuit, relu humainement et volontairement faible friction. L’URL de la plateforme et quelques éléments de contexte suffisent pour commencer ; un accès au repository ou à la production n’est pas requis par défaut.
Ce premier diagnostic n’est ni un scanner automatique ni un audit technique exhaustif. Il sert à comprendre la situation, à identifier ce qui mérite réellement d’être vérifié et à déterminer la prochaine étape utile.
Le Webform existant drupal_lifecycle_diagnostic reste la seule surface de diagnostic. Un audit technique payant n’est proposé que si une analyse plus approfondie apporte une vraie valeur de décision, et une migration n’est jamais automatique.
Si un audit technique est réellement utile
Un audit technique payant n’est proposé que lorsqu’une analyse plus approfondie apporte une base de décision utile. Il n’est pas systématique et peut aussi conclure qu’aucune migration immédiate n’est justifiée.
Selon le contexte, il peut couvrir le Core et l’environnement, les modules contribués, le code spécifique, le thème, Composer, les intégrations, les dépréciations, les tests, l’infrastructure et le déploiement.
Le livrable reste exploitable pour comprendre les constats, prioriser les vérifications et décider de la suite, même si E-merging Digital n’exécute pas ensuite la modernisation ou la migration.
Le contenu réel issu de #958 sur la fin de vie de Drupal 10 reste une ressource d’approfondissement pertinente. Son intégration comme lien public sera faite à partir de l’URL publique effectivement confirmée lors de la future matérialisation/revue, sans inventer de route.
FAQ minimale
Je ne connais pas ma version Drupal. Est-ce un problème ?
Non. L’URL et le contexte du projet suffisent pour commencer. La version exacte fait partie des éléments à vérifier.
Le premier diagnostic est-il gratuit ?
Oui. Il s’agit d’un premier diagnostic humain et faible friction destiné à comprendre la situation et à déterminer ce qui mérite réellement d’être vérifié. Il ne remplace pas un audit technique approfondi.
Le diagnostic est-il un scanner automatique ?
Non. Il est relu humainement et ne constitue pas un audit automatisé exhaustif. Un accès au repository ou à la production n’est pas requis par défaut.
Faut-il passer directement à Drupal 12 ?
Pas nécessairement. La bonne trajectoire dépend de la version de départ, des dépendances, du code spécifique et du calendrier du projet. L’objectif est de comprendre l’existant avant de décider.
Un audit signifie-t-il qu’il faut migrer ?
Non. L’audit est payant uniquement lorsqu’une analyse plus approfondie est utile, et il peut conclure qu’aucune migration immédiate n’est justifiée.