Mettre à jour un site Drupal très patché sans douleur : un serveur MCP dédié aux montées de version

Le casse-tête des sites Drupal fortement patchés

Dans l'écosystème Drupal, il est courant d'appliquer des patchs (correctifs de code temporaires) aux modules contribués, en attendant qu'ils soient intégrés dans une version officielle. Sur des sites complexes, ces patchs peuvent s'accumuler : l'auteur de l'outil prend l'exemple d'un site en Drupal 10.6 avec un fichier composer.json vieux de plusieurs mois, 120 modules contribués et 47 patchs, à faire migrer vers Drupal 11.4.

Dans ce scénario, la montée de version majeure impose des heures de vérifications manuelles : chaque patch doit être contrôlé pour savoir s'il s'applique encore à la nouvelle version du module, ou s'il est déjà inclus dans la dernière release. Un travail répétitif, source d'erreurs, à refaire plusieurs fois par an.

Trois nouveaux outils dans le serveur MCP Drupal-Code-Query

Pour éviter de refaire ce travail à la main, le développeur a enrichi son serveur MCP (Model Context Protocol, un standard qui permet à un assistant IA d'appeler des outils externes) Drupal-Code-Query avec trois fonctions ciblées :

• scan_composer : on envoie le composer.lock, le composer.json et la version cible du cœur Drupal, et l'outil retourne la liste des modules compatibles avec cette version cible.
• check_patches : indique si un patch s'applique encore à une version plus récente du module, ou s'il est déjà intégré dans la nouvelle release.
• reroll_patch : si le patch ne s'applique plus, l'outil tente de le réadapter (« reroll ») à la nouvelle version et retourne le résultat.

Des gains mesurés en temps, en précision et en coût

L'auteur a testé le dispositif avec Claude Opus 5 : la mise à jour complète est passée de 40 à 30 minutes avec le serveur MCP, avec deux fois moins d'appels d'outils, une meilleure précision et un coût final réduit de 26 %. Le même serveur a également permis à un outil basé sur Mistral de terminer la mise à jour en 7 minutes au lieu de 20.

Un backend déterministe, sans LLM

Point notable : côté serveur, aucun résultat n'est généré par un LLM (grand modèle de langage). L'outil s'appuie sur une copie locale de l'ensemble des dépôts de modules contribués Drupal et sur une indexation étendue du code et des tickets, construite sur plusieurs années. Les réponses sont donc déterministes et vérifiables, ce qui limite les risques d'hallucination sur une opération aussi sensible qu'une montée de version.

Deux API en lecture seule sont exposées publiquement (scan de composer et vérification de patchs) et n'interrogent aucun LLM lors de la réponse. L'assistant IA n'intervient que comme orchestrateur : il pilote la mise à jour, mais s'appuie sur des données factuelles fournies par le serveur.

Ce que cela change pour la maintenance Drupal

Cette approche illustre une tendance de fond : plutôt que de demander à une IA de « deviner » l'état de compatibilité d'un module ou d'un patch, on lui donne accès à des outils spécialisés qui répondent avec certitude. Pour les équipes qui maintiennent des sites Drupal complexes, cela transforme la montée de version majeure, souvent redoutée, en un processus plus rapide, plus fiable et moins coûteux à répéter.