Qu'est-ce qu'une reprise de TMA Drupal ?
La reprise de TMA (Tierce Maintenance Applicative) consiste à transférer la maintenance corrective, évolutive et préventive d'un site Drupal vers un nouveau prestataire.
La maintenance corrective couvre le traitement des anomalies : les bugs, les régressions après mise à jour. Le prestataire qui gère la TMA doit être capable d'intervenir rapidement. Les SLA (Service Level Agreement) typiques vont généralement de 2h à 1 jour ouvré selon criticité.
La maintenance préventive concerne la supervision de l'applicatif et de l'infrastructure, la sécurité, le maintien en condition opérationnelle, la vérification des sauvegardes, la surveillance de la santé de la base de données, les mises à jour et correctifs planifiés.
La maintenance évolutive consiste à modifier un site web pour y ajouter de nouvelles fonctionnalités, améliorer ses performances ou s'adapter à de nouvelles réglementations. Elle permet d'éviter l'obsolescence des outils et d'accompagner la croissance d'une organisation.
Concrètement, la reprise de TMA ne se résume pas à récupérer un dépôt Git. Une reprise implique de comprendre l'historique du projet, d'évaluer son état technique, de sécuriser les accès et de mettre en place un fonctionnement permettant d'intervenir rapidement dès les premières demandes.
Chaque projet étant différent, l'objectif est toujours le même : garantir la continuité de service sans repartir de zéro.
Pourquoi changer de prestataire Drupal ?
Les organisations changent rarement d'agence uniquement pour une question de coût. Les motifs les plus fréquents sont souvent liés à la qualité de la maintenance.
Il peut s'agir de mises à jour Drupal ou d'évolutions qui prennent trop de retard, de délais de réponse incompatibles avec les besoins métier ou encore une documentation inexistante ou incomplète qui complique la gestion et le suivi.
Parfois encore, on constate une dette technique qui augment jusqu'à bloquer les évolutions ou constater des interventions isolées sans véritable feuille de route ni vision d'ensemble.
Et dans d'autre cas, le changement est également subi : arrêt d'activité du prestataire, réorganisation interne ou perte d'un développeur historique.
Les risques d'une reprise mal préparée
Une transition improvisée peut rapidement générer des difficultés :
- perte d'accès à certains outils ;
- absence de sauvegardes exploitables ;
- dépendances Composer non documentées ;
- modules personnalisés peu ou pas documentés ;
- environnements de développement incomplets ;
- procédures de déploiement inconnues.
La plupart de ces risques peuvent être anticipés grâce à un audit de reprise réalisé avant le début de la maintenance.
Notre méthode de reprise en 7 étapes
- Comprendre le contexte du projet
Avant toute intervention, nous échangeons avec les équipes métier et techniques afin de comprendre :
- les objectifs du site ;
- les contraintes métier ;
- les incidents récurrents ;
- les évolutions attendues ;
- les outils utilisés.
Cette phase permet de prioriser les actions dès les premiers jours de la reprise.
- Récupérer tous les accès
Une reprise ne peut être sereine sans disposer de l'ensemble des accès.
La checklist comprend notamment :
- dépôt Git ;
- hébergement ;
- environnements de développement, recette et production ;
- accès SSH ;
- base de données ;
- DNS ;
- certificats SSL ;
- Composer ;
- système de tickets ;
- outils de monitoring ;
- Google Search Console ;
- Matomo ou Google Analytics ;
- Google Tag Manager ;
- SMTP et gestion des e-mails ;
- sauvegardes automatiques.
Il est fréquent que certains accès aient été créés avec une adresse appartenant à l'ancien prestataire. Identifier ces dépendances dès le départ évite de nombreuses difficultés.
- Réaliser un audit technique
L'audit permet d'établir une photographie objective de l'état du projet.
Nous analysons notamment :
Le socle technique
- la version de Drupal ;
- la version PHP ;
- Composer ;
- les modules contribués et personnalisés ;
- les thèmes ;
- les dépendances externes.
La sécurité
- les mises à jour disponibles ;
- les modules abandonnés ;
- les droits d'administration ;
- la configuration des sauvegardes ;
- la gestion des comptes.
Les performances
- le cache Drupal ;
- reverse proxy (Varnish) ;
- Redis ;
- l'optimisation des médias ;
- le temps de réponse.
La qualité du code
- l'architecture générale ;
- la dette technique ;
- le respect des bonnes pratiques Drupal ;
- la qualité des développements spécifiques.
L'objectif est clair : identifier rapidement les risques et les priorités.
- Sécuriser la plateforme
Avant d'ajouter de nouvelles fonctionnalités, il est souvent préférable de stabiliser l'existant.
Les premières actions concernent généralement :
- les mises à jour de sécurité critiques ;
- les sauvegardes ;
- les accès administrateurs ;
- la supervision ;
- les procédures de restauration.
Cette étape réduit fortement le risque d'incident pendant la transition.
- Vérifier les processus de déploiement
Une maintenance efficace repose sur un processus de livraison fiable.
Nous vérifions notamment :
- la gestion de configuration Drupal ;
- les pipelines CI/CD ;
- les procédures de déploiement ;
- les environnements disponibles ;
- les validations avant mise en production.
- Corriger les irritants les plus importants
Une fois le projet sécurisé, nous priorisons les premiers correctifs apportant un bénéfice immédiat :
- bugs bloquants ;
- problèmes de performance ;
- améliorations de l'administration ;
- optimisation des développements existants.
Cette phase permet aux équipes métier de constater rapidement les bénéfices de la reprise.
- Construire une feuille de route
La reprise ne marque pas la fin du projet. Elle constitue le point de départ d'une stratégie d'amélioration continue.
Selon les besoins, cette feuille de route peut inclure :
- la montée de version Drupal ;
- des optimisations de performances ;
- des évolutions fonctionnelles ;
- l'amélioration de l'accessibilité ;
- des actions d'éco-conception ;
- la réduction progressive de la dette technique.
Les documents à récupérer avant la transition
Même lorsqu'un projet est ancien, certains éléments sont indispensables
| Élément | Pourquoi est-ce important ? |
|---|---|
| Dépôt Git | Reprendre les développements |
| Sauvegardes | Restaurer le site en cas d'incident |
| Documentation technique | Comprendre l'architecture |
| Procédure de déploiement | Éviter les erreurs de mise en production |
| Inventaire des modules | Identifier les dépendances |
| Accès hébergement | Administrer l'infrastructure |
| Comptes administrateurs | Garantir l'autonomie |
| Historique des tickets | Connaître les problèmes récurrents |
Combien de temps dure une reprise de TMA Drupal ?
La durée dépend principalement de la taille du projet et de la qualité de la documentation existante.
À titre indicatif :
- Site vitrine : quelques jours.
- Site institutionnel : une à deux semaines.
- Plateforme métier ou multisite : plusieurs semaines selon la complexité.
L'objectif n'est pas de tout refaire, mais de reprendre progressivement la maîtrise du projet.
Questions fréquentes
Peut-on changer d'agence sans interrompre le site ?
Oui. Dans la majorité des cas, la transition est réalisée sans interruption de service.
Une reprise implique-t-elle une refonte ?
Non. Une reprise de TMA concerne la maintenance du site existant. Une refonte n'est envisagée que lorsque la dette technique ou les besoins métiers le justifient.
Peut-on reprendre un site sans documentation ?
Oui, mais cela nécessite un audit plus approfondi afin de reconstituer le fonctionnement du projet.
Faut-il migrer l'hébergement ?
Pas nécessairement. La reprise de la maintenance peut être réalisée tout en conservant l'hébergeur actuel.
Une reprise réussie commence par un audit
La réussite d'une reprise de TMA repose avant tout sur une bonne préparation. Plus les accès sont identifiés, les risques documentés et les priorités partagées dès le départ, plus la transition est fluide.
Chez bluedrop.fr, nous disposons d'une solide expérience et d'une équipe organisée pour assurer la maintenance préventive, corrective et évolutive de votre projet Drupal.
Pour rappel, bluedrop.fr c'est :
- 82 clients actifs en projet/TMA.
- 180 sites gérés maintenus et administrés.
- 535 tickets de maintenance créés par mois.
Vous envisagez de changer de prestataire Drupal ? Contactez-nous pour échanger sur votre contexte. Nous pourrons évaluer ensemble l'état de votre plateforme et définir les meilleures conditions pour une reprise sereine.
Nos clients témoignent
"Nous avons confié à l'agence bluedrop.fr la maintenance évolutive et corrective d’un extranet de gestion de frêt maritime très complexe sans pouvoir assurer un transfert de connaissance avec la société de maintenance précédente. L’équipe s’est attelée à ce défi et progresse dans l’efficacité de cette maintenance un peu plus tous les jours. Étant satisfait de notre collaboration, nous avons travaillé et travaillons sur de nouveaux projets."
Christian Saurat Directeur des Systèmes d'Information de La Méridionale![]()
"L’accompagnement de Bluedrop répond pleinement à nos attentes pour notre usine à sites Drupal. Les équipes font preuve d’une grande disponibilité et d’une réelle capacité de conseil, tant sur la maintenance évolutive que sur les choix structurants à moyen et long terme. Cette collaboration nous permet aujourd’hui de disposer d’un écosystème robuste, évolutif et aligné avec les besoins de nos filiales et de nos utilisateurs à l’international, tout en garantissant un haut niveau de qualité et de sécurité.Il est essentiel pour nous de pouvoir compter sur un partenaire capable de nous accompagner sur le long terme, aussi bien sur les enjeux techniques que sur la performance et la pérennité de la plateforme."
Thomas Soltys Head of Digital Communication chez Elior Group