_

Changer d'agence Drupal

Un guide pratique des signaux d'alerte, de la checklist de transfert, des 30 premiers jours et d'un plan de reprise commençant par l'audit.

10 min de lecture · Issu des reprises, audits Drupal et missions de support de Droptica.

Commencez par le risque, pas par le contrat

Changer d'agence Drupal est une décision opérationnelle. La voie la plus sûre est de comprendre le code, les accès, l'hébergement, le déploiement et le risque lié au backlog avant que quiconque promette une reprise sans accroc.

Une reprise n'est pas un démarrage à l'aveugle

Vous avez besoin d'une baseline technique avant que la nouvelle équipe ne modifie le code, le déploiement ou l'hébergement. Sinon, les premières semaines deviennent des conjectures.

L'audit précède la responsabilité

L'audit Drupal payant vérifie ce que vous héritez : qualité du code, mises à jour, modules sur mesure, accès, intégrations, déploiement et risque opérationnel.

Le résultat doit être un plan

Vous devriez terminer la première phase avec des priorités, un registre des risques, une checklist d'accès et un chemin réaliste vers la stabilisation ou Care & Growth.

Signes que votre agence Drupal ne convient peut-être plus

Voici les schémas qui justifient généralement un second avis ou un changement d'agence encadré.

Drupal n'est plus leur priorité

L'équipe pousse une autre stack, ne publie plus de travaux Drupal ou ne peut pas expliquer comment elle maintient un savoir-faire Drupal senior disponible.

Chaque changement révèle de nouvelles inconnues

Les petits correctifs se transforment en découverte de régressions, les délais glissent et l'équipe ne sépare pas clairement le risque du backlog de la dette technique.

Les mises à jour de sécurité sont irrégulières

Les mises à jour du core et des contribs attendent trop longtemps, les livraisons sont manuelles ou personne ne peut montrer un processus prévisible de patch et de rollback.

Le savoir repose sur une seule personne

Le projet dépend d'un seul développeur, d'accès d'hébergement non documentés ou d'étapes de déploiement informelles que personne d'autre ne peut reproduire en toute sécurité.

Les coûts sont difficiles à planifier

Chaque ticket exige une nouvelle négociation, personne ne relie feuille de route, risque et capacité mensuelle, et les discussions budgétaires remplacent la planification de la livraison.

Votre activité a dépassé la configuration

Nouveaux marchés, WCAG, SEO, intégrations, contenu multilingue ou exigences de conformité nécessitent une architecture plus solide et une responsabilité à long terme.

La checklist de transfert que les acheteurs devraient préparer

Vous n'avez pas besoin d'un dossier de transfert parfait, mais d'assez d'accès et de contexte pour qu'une équipe Drupal senior puisse auditer la plateforme de façon responsable.

Accès et exploitation

  • Dépôt Git ou copie complète du code
  • Dump de base de données et sauvegarde des fichiers
  • Responsabilité de l'hébergement, du DNS, du CDN et des sauvegardes
  • Processus de déploiement et environnements
  • Monitoring, logs et historique des incidents

Contexte Drupal et métier

  • État des mises à jour du core et des contribs
  • Modules sur mesure, thèmes et intégrations
  • Rôles, permissions et workflow éditorial
  • Bugs connus, backlog et priorités des parties prenantes
  • Contraintes SEO, WCAG, analytics et campagnes

Des 30 premiers jours concrets

Le premier mois doit réduire l'incertitude. Il ne doit pas devenir une nouvelle phase de découverte sans fin.

Semaine 1 : audit

Rassembler les accès, établir la baseline technique, inspecter le code et cartographier les risques qui affectent la reprise, la sécurité et la feuille de route.

Semaine 2 : plan de stabilisation

Traduire les constats en priorités : ce qui doit être corrigé immédiatement, ce qui peut attendre et ce qui nécessite une décision plus large de migration ou de reconstruction.

Semaine 3 : transfert encadré

Confirmer le déploiement, les sauvegardes, les rôles, le workflow de support et le rythme de communication afin que les changements en production soient prévisibles.

Semaine 4 : modèle de prise en charge

Convenir de la capacité mensuelle, des attentes de SLA, de la revue de feuille de route et du plan Care & Growth qui remplace le support réactif.

Utilisez le guide pour préparer. Utilisez l'audit pour décider.

Un changement d'agence ne devrait pas dépendre d'une promesse commerciale. Commencez par un audit Drupal payant lorsque vous avez besoin d'une baseline indépendante, d'un registre des risques et d'une feuille de route concrète avant de confier la plateforme à un nouveau propriétaire de long terme.

Prochaines étapes liées

Le changement d'agence est un scénario. Le premier service que vous achetez est l'audit ; le modèle à long terme est le support, le développement ou l'extension d'équipe.

Audit de code Drupal

La première étape payante pour le code, l'architecture, la sécurité et le risque opérationnel.

Voir le périmètre de l'audit

Care & Support Drupal

Prise en charge mensuelle après stabilisation : mises à jour, support, feuille de route et travaux de croissance.

Voir les offres de support

Développement Drupal

Développement de fonctionnalités, modernisation et reconstruction lorsque l'audit va au-delà de la maintenance.

Voir le développement Drupal

Extension d'équipe

Capacité Drupal senior lorsque votre équipe interne conserve la responsabilité opérationnelle.

Voir l'extension d'équipe