Changer de prestataire technique sans interrompre votre service

Introduction

Changer de prestataire technique est une situation fréquente : fin de contrat, manque de disponibilité, évolution des besoins ou volonté de reprendre la maîtrise de l'environnement.

Cette transition peut toutefois présenter des risques si elle n'est pas préparée :

• perte d'accès aux ressources
• absence de documentation
• dépendance à un intervenant unique
• environnement instable ou non maintenu

L'objectif d'une reprise technique est de sécuriser les accès, comprendre l'existant et garantir la continuité du service.

Quand envisager un changement de prestataire

Les situations les plus courantes :

• délais d'intervention trop longs
• manque de visibilité sur les actions réalisées
• difficultés à faire évoluer l'application
• absence de maintenance ou de mises à jour
• dépendance à une seule personne
• impossibilité de récupérer les accès ou la documentation
• besoin d'un accompagnement plus structuré dans la durée

Les risques d'une transition non préparée

Sans préparation, un changement peut entraîner :

• perte d'accès au code, au serveur ou aux services tiers
• interruption de service lors du transfert
• incompatibilités techniques non identifiées
• absence de sauvegardes exploitables
• environnement obsolète ou non sécurisé
• dette technique importante découverte trop tard

Une phase d'analyse est essentielle avant toute modification.

Les accès à récupérer en priorité

Une reprise technique nécessite l'accès à l'ensemble des éléments critiques :

Code et versions

• dépôt Git ou archive du code source
• dépendances et configuration

Infrastructure

• hébergement ou serveur (SSH, FTP)
• configuration web et base de données

Services associés

• DNS et nom de domaine
• certificats SSL
• services tiers (email, paiement, API, SMS…)

Administration

• comptes WordPress / application
• accès aux outils de déploiement ou de supervision

Méthode de reprise recommandée

Une transition sécurisée se déroule généralement en quatre étapes.

1. Audit initial
   • analyse de l'architecture et de l'environnement
   • vérification des versions et dépendances
   • contrôle des sauvegardes
   • identification des risques et points critiques
2. Sécurisation
   • récupération et centralisation des accès
   • mise en place d'un environnement de travail
   • gel des modifications non maîtrisées
3. Stabilisation
   • correction des anomalies critiques
   • mise à niveau si nécessaire
   • tests de fonctionnement
4. Mise en place du suivi
   • documentation minimale
   • organisation des interventions
   • cadre de maintenance ou d'évolution

Signes qu'une reprise technique est nécessaire

• aucune documentation disponible
• mises à jour jamais réalisées
• environnement PHP ou serveur obsolète
• incidents récurrents ou instabilité
• impossibilité de déployer ou de tester
• absence d'historique des interventions

Cas réel d'intervention

Reprise d'une application PHP reposant sur un environnement obsolète. Après audit, mise à niveau progressive, stabilisation et mise en place d'un cadre de maintenance ont permis de sécuriser l'exploitation.

→ Voir le cas : Reprise application legacy PHP

Pourquoi réaliser un audit avant la transition

Un audit permet de :

• identifier les risques techniques
• estimer les priorités d'intervention
• éviter les interruptions de service
• préparer une reprise progressive et sécurisée

Il constitue la base d'une collaboration dans la durée. Voir un exemple de rapport d’audit et notre réponse à la question peut-on reprendre un projet web abandonné ?