Un changement de prestataire devient difficile lorsque le client découvre tardivement que le domaine, le compte cloud, le dépôt ou le service d’e-mail ont été créés au nom d’un tiers. Même lorsque la relation est bonne, une transmission incomplète peut ralentir la maintenance pendant des semaines.
La réversibilité désigne la capacité à transférer l’exploitation et l’évolution d’un système sans perdre ses actifs, ses données ni sa continuité. Elle se prépare dès le début du projet et se vérifie régulièrement. Ce guide est technique et organisationnel ; les clauses contractuelles doivent être adaptées et validées par un conseil juridique.
La propriété réelle compte davantage que la possession d’une copie
Recevoir une archive de code ne garantit pas l’autonomie. Il faut connaître l’historique, les dépendances privées, les instructions de construction, les droits sur les composants et l’emplacement des secrets. De même, un export de base n’est utile que s’il est complet, documenté et restaurable.
Pour chaque actif, posez quatre questions :
- qui en est le titulaire contractuel ?
- qui possède un accès administrateur ?
- comment l’actif peut-il être exporté ou transféré ?
- la procédure a-t-elle été vérifiée ?
Cette distinction entre « reçu » et « vérifié » évite une fausse sécurité.
Les huit familles d’actifs à inventorier
1. Code source et chaîne de construction
Dépôts, branches, tags, historique, sous-modules, paquets privés, scripts, fichiers de configuration d’exemple, pipeline d’intégration, images de conteneurs et artefacts mobiles. Le client doit disposer d’un accès administrateur ou d’une copie complète transférable.
Les clés et tokens ne doivent pas être intégrés au code. Ils sont inventoriés par usage et recréés dans les comptes du client.
2. Données et fichiers
Bases, stockage objet, médias, documents, journaux nécessaires, index de recherche et données analytiques. L’export doit inclure le schéma, les encodages, les relations, les volumes, les règles de rétention et un contrôle d’intégrité.
Une restauration sur un environnement isolé constitue la meilleure preuve de transférabilité.
3. Infrastructure et environnements
Cloud, serveurs, conteneurs, réseau, pare-feu, CDN, bases managées, tâches planifiées, workers, sauvegardes, supervision et environnements de recette. Les ressources doivent être cartographiées avec leur région, leur coût, leur propriétaire et leur dépendance.
Lorsque l’infrastructure est codifiée, le dépôt et l’état associé font partie du transfert.
4. Noms de domaine et certificats
Registrar, DNS, zones, certificats TLS, renouvellements, sous-domaines, redirections et validation d’e-mail. Le titulaire du domaine doit être le client ou une entité explicitement mandatée avec une procédure de transfert documentée.
5. Services tiers
Paiement, e-mail, SMS, cartographie, recherche, authentification, analytics, stockage, IA et outils de support. Pour chaque service : contrat, compte propriétaire, plan, limites, clés, webhooks, données hébergées et procédure de sortie.
6. Documentation et connaissance métier
Architecture, flux, modèle de données, déploiement, sauvegarde, incidents, glossaire, règles métier, exceptions, tickets et décisions. La documentation doit être testée par une personne qui ne connaît pas déjà le système.
7. Propriété intellectuelle et licences
Contrats de cession ou de licence, composants open source, polices, images, bibliothèques commerciales et droits sur les créations. L’objectif est de savoir ce que le client peut modifier, exploiter et transférer.
8. Exploitation et gouvernance
Contacts, astreinte, niveaux de service, calendrier de maintenance, incidents ouverts, vulnérabilités, roadmap, budgets, procédures de validation et comptes utilisateurs. La transmission doit inclure le fonctionnement quotidien, pas seulement les actifs techniques.
Le schéma place la maîtrise du client au centre de huit familles complémentaires. Cette représentation ne définit pas une hiérarchie : une reprise exige que chaque famille soit inventoriée, transmise et vérifiée. La liste suivante en donne une version textuelle équivalente.
- Code source : dépôts, historique, construction, dépendances privées et artefacts.
- Données : bases, fichiers, schémas, volumes, intégrité, rétention et restauration.
- Infrastructure : cloud, réseau, serveurs, environnements, sauvegardes et supervision.
- Domaines et certificats : titulaires, DNS, TLS, renouvellements et moyens de transfert.
- Services tiers : comptes, contrats, APIs, clés, webhooks, limites et procédures de sortie.
- Documentation : architecture, exploitation, règles métier, incidents et décisions.
- Propriété intellectuelle : cessions, licences, composants, polices, images et droits d’usage.
- Exploitation : responsabilités, niveaux de service, maintenance, risques, roadmap et comptes.
Checklist locale de 60 contrôles
Préparer et vérifier la réversibilité
Choisissez le type de service, qualifiez chaque remise et obtenez une liste de relance ainsi qu’un procès-verbal de transfert. Un élément « reçu » reste distinct d’un élément réellement « vérifié ».
Confidentialité : ne saisissez jamais de mot de passe, token, clé, secret, domaine interne ni donnée client. Tout reste dans ce navigateur ; aucune information n’est envoyée à Partitech.
Le socle commun est toujours affiché. Le profil active en plus les contrôles propres au service sélectionné.
La checklist sera activée avec JavaScript.
| Contrôle | Statut | Responsable facultatif | Échéance facultative | Note locale facultative |
|---|---|---|---|---|
| Activez JavaScript pour personnaliser la checklist. Le socle de vérification reste décrit ci-dessous. | ||||
La conservation est désactivée par défaut. Elle ne commence qu’après votre accord explicite et peut être effacée en un clic.
Progression déclarée
État de la remise
Le calcul apparaîtra après l’activation de la checklist.
Blocages critiques à lever
Un blocage ne disparaît qu’au statut « Vérifié ». « Reçu » signale une remise encore à contrôler.
- Les contrôles critiques seront listés à l’activation.
Progression par domaine
| Domaine | Applicables | Reçus ou vérifiés | Vérifiés | Inconnus |
|---|---|---|---|---|
| En attente d’activation. | ||||
Ordre de relance
- Les éléments critiques et à demander apparaîtront en premier.
RACI générique de la remise
R réalise, A arbitre, C est consulté, I est informé. Remplacez ces rôles génériques par des personnes nommées dans le plan réel.
| Activité | Client | Prestataire sortant | Prestataire entrant | Hébergeur | Métier |
|---|
Aperçu du procès-verbal de remise
Le procès-verbal sera généré localement.
Préparer le transfert en quatre temps
Étape 1 — Geler l’inventaire
Établissez une version datée de la liste des actifs et identifiez les inconnues. Le gel ne signifie pas arrêter le projet, mais disposer d’une base commune pour suivre les changements jusqu’à la remise.
Étape 2 — Sécuriser les comptes du client
Créez ou confirmez les comptes administrateurs appartenant au client. Activez l’authentification renforcée et définissez des contacts de récupération. Les accès du prestataire restent nominatifs et révocables.
Étape 3 — Transmettre et vérifier
La nouvelle équipe clone, construit, déploie et restaure sur un environnement contrôlé. Elle compare les volumes et teste les parcours critiques. Les écarts deviennent des actions avec propriétaire et échéance.
Étape 4 — Révoquer et surveiller
Après acceptation, les secrets sont renouvelés, les comptes inutiles supprimés et les journaux surveillés. Les accès nécessaires à une période de support transitoire sont limités dans le temps.
Le contenu minimal d’un dossier de réversibilité
Le dossier doit permettre à une équipe compétente de reprendre sans dépendre de conversations privées. Il contient :
- inventaire des actifs et propriétaires ;
- architecture et flux ;
- procédure de démarrage et de déploiement ;
- sauvegarde et restauration ;
- matrice des environnements ;
- services tiers et contrats ;
- accès transmis, sans inclure les secrets en clair ;
- incidents et risques connus ;
- backlog et feuille de route ;
- procès-verbal de vérification.
Lorsque l’ancien prestataire ne coopère pas
Commencez par les actifs détenus directement par le client : contrats, factures, domaines, comptes, données et dépôts accessibles. Formalisez les demandes de manière précise : actif, format, date, moyen de transmission et critère de vérification.
La nouvelle équipe peut reconstruire une architecture à partir des DNS, consoles, code et journaux, mais ce travail doit être identifié et budgété. Ne supprimez pas une ressource inconnue simplement parce qu’elle semble inactive.
Les désaccords contractuels doivent être séparés du plan de continuité. L’objectif immédiat est de protéger les données, le service et les preuves.
Les clauses techniques à anticiper
Sans rédiger le contrat à la place d’un juriste, le cahier technique peut préciser :
- les formats d’export et leur périodicité ;
- la propriété des comptes et dépôts ;
- le délai de remise ;
- le volume d’assistance inclus ;
- la documentation attendue ;
- les conditions de suppression des copies ;
- la continuité pendant le transfert ;
- les méthodes de vérification.
Ces éléments sont plus efficaces lorsqu’ils correspondent à des procédures réellement testées.
Tester la réversibilité avant d’en avoir besoin
Une fois par an, choisissez un actif critique et vérifiez son transfert : restaurer une sauvegarde, cloner un dépôt avec un compte neuf, exporter les utilisateurs ou reconstruire un environnement. Ce test révèle les dépendances silencieuses et maintient la documentation à jour.
La réversibilité doit aussi être examinée lors de l’ajout d’un nouveau service. Un outil difficile à quitter peut être acceptable si sa valeur et son risque sont compris ; il ne doit pas devenir un verrou par accident.
Une relation saine repose sur la maîtrise du client
Un bon prestataire n’a pas besoin de retenir les actifs pour fidéliser. La valeur de la relation vient de la connaissance, de la qualité d’exécution et de la capacité à faire évoluer la plateforme. Le client conserve ses comptes, ses données et la liberté de décider.
Partitech sait reprendre des applications développées par des tiers et organiser leur maintenance, leur hébergement et leur modernisation. Nous pouvons également aider à construire le dossier de réversibilité avant qu’un changement ne devienne urgent.
Pour préparer la suite, consultez la méthode des 90 premiers jours pour reprendre la maintenance d’une application, cadrez un audit technique complet de l’application et anticipez le contrat de maintenance applicative. Découvrez également les prestations Partitech.
Références officielles
Références vérifiées le 17 août 2026 :