Reprendre une TMA Drupal : la checklist des 30 jours

Objectifs des 30 premiers jours

Stabiliser, sécuriser, gagner en visibilité

Avant de parler amélioration, parlez contrôle. Les 30 premiers jours ont trois objectifs, dans cet ordre :

• Stabiliser : aucune régression introduite par les premières interventions, aucun incident déclenché par un manque de connaissance de l'environnement.
• Sécuriser : les vulnérabilités critiques et les problèmes de configuration manifestes sont traités en priorité.
• Gagner en visibilité : à la fin du mois, vous disposez d'une image fidèle de l'état de la plateforme — pas une estimation, une cartographie.

Tout le reste — les améliorations, les nouvelles fonctionnalités, la montée de version — vient après.

Accès et gouvernance

Comptes, clés, dépôts, environnements, rôles

La première heure d'une reprise de TMA Drupal se passe sur un seul sujet : accéder à ce qui doit l'être, et ne rien toucher d'autre.

Checklist accès :

• Accès au dépôt de code source (Git). Si ce dépôt n'existe pas ou si le code n'est pas versionné, c'est votre premier chantier.
• Accès aux environnements : production, staging, développement. Vérifiez que l'environnement de staging reflète fidèlement la production — c'est là que toutes les interventions futures seront testées avant d'être appliquées.
• Accès à l'hébergeur et à la configuration serveur (ou à l'interface de la plateforme cloud si vous êtes sur un environnement managé).
• Accès aux outils de monitoring existants, s'ils existent.
• Inventaire des comptes d'administration Drupal : combien d'utilisateurs avec le rôle administrateur, depuis quand, pour quel usage. Les comptes orphelins (départs non traités) sont une faille courante.
• Transmission des clés de chiffrement, des secrets d'API et des credentials de services tiers. Tout ce qui est stocké dans un settings.php ou dans des variables d'environnement doit être documenté et transféré de façon sécurisée.

Sur la gouvernance : définissez dès le départ qui fait quoi. Qui peut valider un déploiement en production ? Qui est l'interlocuteur côté client pour les priorités ? Qui notifier en cas d'incident ? Ces questions non résolues génèrent des délais et des malentendus au pire moment.

Sécurité et conformité

Mises à jour core et modules, correctifs, sauvegardes

C'est le chantier qui ne se reporte pas.

Checklist sécurité :

• État des mises à jour : quelle version du core Drupal est installée ? Quels modules ont des mises à jour de sécurité en attente ? Utilisez drush pm:security ou le rapport de statut de l'administration Drupal pour obtenir la liste immédiatement.
• Appliquez en priorité les mises à jour marquées « Security release » sur le core et les modules critiques. Ces correctifs répondent à des vulnérabilités connues et documentées publiquement.
• Vérifiez la configuration des sauvegardes : fréquence, emplacement (hors serveur de production), test de restauration. Une sauvegarde qui n'a jamais été testée est une sauvegarde dont vous ne pouvez pas certifier le fonctionnement.
• Si la plateforme tourne sur Drupal 10, anticipez dès maintenant la migration vers Drupal 11 — la fin de vie de Drupal 10 est prévue pour décembre 2026, et plus le chantier est engagé tôt, plus il est maîtrisable.
• Vérifiez la configuration HTTPS, les headers de sécurité (Content-Security-Policy, X-Frame-Options, etc.) et les permissions des fichiers sur le serveur.

Supervision et performance

Monitoring, logs, alerting, SLO et SLA

Vous ne pouvez pas maintenir ce que vous ne mesurez pas.

Checklist supervision :

• Existence d'un outil de monitoring applicatif : uptime, disponibilité des pages critiques, temps de réponse. Si rien n'existe, c'est à mettre en place avant la fin du premier mois.
• Accès aux logs applicatifs Drupal (dblog ou Syslog) et aux logs serveur (Nginx/Apache). Un pic d'erreurs PHP, une page qui retourne des 500, une explosion du cache — ces signaux doivent pouvoir être lus et interprétés.
• Configuration des alertes : qui est notifié en cas d'indisponibilité ? Sur quel canal ? Avec quel délai ?
• État des performances : temps de réponse moyens, taux de cache hit, taille des pages clés. Ces indicateurs de base permettent d'identifier rapidement les régressions introduites lors des premières interventions.

Sur les engagements de service : les niveaux de service (délai de prise en charge des incidents, fenêtres d'intervention, planification des montées de version) se définissent contractuellement, projet par projet. Ce qui se passe dans les 30 premiers jours, c'est la collecte des données qui permettra d'en définir des pertinents.

Backlog et dette

Tri : quick wins versus chantiers

À la fin des deux premières semaines, vous avez suffisamment de visibilité pour faire un tri.

Les quick wins sont les interventions rapides à fort impact : une mise à jour de sécurité appliquée, un module obsolète désactivé, une configuration mal calée corrigée. Ils permettent de montrer une valeur immédiate et d'améliorer objectivement l'état de la plateforme.

Les chantiers sont les travaux structurants : refactoring du code personnalisé, restructuration des permissions, migration de version majeure, refonte d'une section fonctionnelle. Ils se planifient avec le client après le bilan du premier mois.

Ce qu'il faut éviter dans les 30 premiers jours : engager un chantier structurant avant d'avoir une vision complète de la plateforme. L'urgence perçue au démarrage conduit parfois à des interventions qui créent plus de dette qu'elles n'en résolvent.

Rythme et rituels

Kanban, triage, rapport mensuel, calendrier de release

Une maintenance Drupal sans structure devient vite un fourre-tout. Les rituels ne sont pas de la bureaucratie — ce sont les mécanismes qui permettent à l'exploitation de rester prévisible et maîtrisée.

À mettre en place dès le premier mois :

• Un backlog structuré avec catégories (incidents, évolutions, mises à jour, dette technique) et priorités claires.
• Une cadence de triage : qui décide de la priorité des nouvelles demandes, avec quelle fréquence ?
• Un cycle de release défini : quand sont déployées les mises à jour, avec quel processus de validation avant production ?
• Un rapport mensuel simple : ce qui a été fait, ce qui est en cours, ce qui arrive. Il doit pouvoir être lu en cinq minutes par un interlocuteur non technique.

La régularité du rapport mensuel est souvent sous-estimée. Elle construit la confiance, documente la valeur délivrée et réduit les demandes d'explication en dehors des réunions.

Roadmap 90 jours et KPI

Qualité, lead time, MTTR, budget

À la fin des 30 premiers jours, vous avez les éléments pour construire la roadmap des 60 jours suivants.

Les indicateurs à suivre dans une infogérance Drupal sérieuse :

• Taux de disponibilité de la plateforme, mesuré sur une période glissante.
• Lead time : temps moyen entre l'ouverture d'une demande et sa résolution.
• MTTR (Mean Time To Recovery) : temps moyen pour rétablir le service après un incident.
• Arriéré de sécurité : nombre de mises à jour de sécurité en attente à un instant T. L'objectif est que ce nombre reste proche de zéro en permanence.

Ces indicateurs ne se fixent pas le premier jour — ils se mesurent d'abord, puis on définit des objectifs réalistes à 90 jours avec le client.

FAQ

Mon prestataire précédent n'a pas de documentation. Comment démarrer ? C'est fréquent. Le premier travail est une reconnaissance : drush status, rapport d'état Drupal, liste des modules actifs, état des logs. En quelques heures, vous avez une image de base. La documentation complète se construit ensuite au fil des interventions.

Mon site est en multisite. La checklist s'applique-t-elle ? Globalement oui, mais chaque site du multisite doit être traité comme une instance à part entière pour ce qui concerne les accès, les mises à jour et la supervision. Le code partagé (core, modules contrib communs) se met à jour une fois ; les configurations et les contenus sont propres à chaque site.

Mon site fait du e-commerce Drupal (Commerce). Quelles priorités ? Les flux de commande, de paiement et de stock sont les zones à stabiliser en priorité. Documentez les intégrations de passerelles de paiement, vérifiez les webhooks et les connexions aux systèmes de gestion des stocks avant toute autre intervention.

Et le RGPD ? Inventoriez les formulaires qui collectent des données personnelles, vérifiez la présence des mentions légales et du bandeau cookies, et assurez-vous que les données de logs ne conservent pas d'informations personnelles au-delà de la durée légale. C'est un audit rapide mais non négligeable.