Votre plateforme tourne, mais la collaboration avec l'équipe IT actuelle ne fonctionne plus. Vous vous demandez si une autre société peut reprendre l'existant, ou si vous êtes condamné à reconstruire depuis zéro. La réponse tient en un mot : ça dépend. Pas de l'état du code, mais de la façon dont l'équipe sortante a documenté son travail et structuré les livrables. Une reprise réussie commence bien avant le jour J, au moment où le premier contrat a été signé.
Cet article présente un plan de transfert éprouvé, applicable à toute plateforme métier. Il décrit les étapes qui permettent à une équipe entrante de reprendre un projet sans tout réécrire, et il nomme ce qui rend une reprise impossible, donc ce qu'il fallait exiger dès le départ.
Les signaux qui justifient un changement d'équipe, et ceux qui n'en sont pas
Un changement de prestataire coûte cher et immobilise la plateforme pendant trois à six mois. Autant être certain que le problème ne vient pas d'un manque de communication interne ou d'objectifs flous.
Les bonnes raisons de changer :
- L'équipe ne livre plus, malgré plusieurs alertes formelles et l'attribution de ressources supplémentaires.
- Le turnover côté prestataire atteint 50 % par an, chaque nouveau développeur pose des questions auxquelles ses prédécesseurs avaient déjà répondu.
- L'infrastructure est détenue par le prestataire, sous des comptes qu'il refuse de transférer ou de documenter.
- Les coûts de maintenance dépassent de 40 % les devis initiaux, sans augmentation de périmètre ni justification technique.
- Les audits de sécurité révèlent des vulnérabilités critiques que le prestataire corrige une fois sur deux, avec des délais de six semaines.
Les mauvaises raisons de changer :
- Une seule grosse erreur, même coûteuse, si elle a été traitée rapidement et si des actions préventives ont été mises en place.
- Un désaccord sur les priorités de fonctionnalités, quand aucun backlog formalisé n'a été partagé entre donneur d'ordre et équipe.
- Un langage ou un framework perçu comme "vieux", alors que la plateforme est stable, documentée et supporte la montée de charge. La dette technique se mesure en risque métier, pas en tendance sur Hacker News.
- Des délais qui glissent parce que le cahier des charges change chaque semaine. Avant de reprocher le retard, mesurez la volatilité de vos demandes.
La règle : si le problème se corrige en réécrivant un contrat ou en clarifiant les attentes, gardez l'équipe. Si le problème résiste à trois tentatives d'amélioration documentées, planifiez la reprise.
L'audit de reprise : ce qu'une équipe entrante doit pouvoir lire en dix jours
Un audit de reprise n'est pas un audit de code. Il ne cherche pas à évaluer la qualité technique, mais à répondre à une question : est-ce que cette plateforme peut être reprise par une autre équipe, sans tout réécrire ?
L'équipe entrante analyse les documents suivants, que le prestataire sortant doit fournir sous dix jours ouvrables. Si un document manque ou reste flou après deux échanges, la reprise est compromise.
-
Architecture diagram : schéma des composants (API, bases de données, workers, intégrations tierces), avec leurs relations et les flux de données. Accepté au format Draw.io, Miro, Figma ou Lucidchart, avec possibilité d'export PDF. Une capture d'écran PowerPoint n'est pas un schéma exploitable.
-
Environment inventory : liste de tous les environnements (dev, staging, production), leur URL, leur infrastructure (serveur dédié, cloud, PaaS), leur version applicative et la procédure de déploiement. Si la production tourne sur trois serveurs différents sans justification, c'est un signal.
-
Dependencies manifest : fichier généré par le gestionnaire de paquets (package.json, requirements.txt, composer.lock, pom.xml), avec les versions exactes. Un manifeste à jour garantit un rebuild reproductible. Un manifeste qui date de huit mois signifie que l'équipe déploie sans connaître ses dépendances.
-
API documentation : endpoints, méthodes HTTP, paramètres, codes de retour et exemples de requêtes. Postman collection, Swagger ou OpenAPI sont acceptés. Une suite de tests d'intégration bien commentée peut compenser l'absence de doc formelle, si elle couvre 80 % des routes.
-
Database schema : diagramme ERD des tables principales, ou export SQL avec contraintes et index. La nouvelle équipe doit comprendre le modèle de données en une heure, sans appeler l'équipe sortante.
-
Secrets inventory : liste des secrets utilisés (clés API tierces, tokens OAuth, certificats SSL), avec leur emplacement (fichier .env, gestionnaire de secrets cloud, variables d'environnement système). Il n'est pas demandé de fournir les secrets eux-mêmes à ce stade, seulement leur inventaire.
-
Backup and restore procedure : fréquence des sauvegardes, emplacement des fichiers, durée de rétention et procédure testée de restauration. Un backup qui n'a jamais été restauré n'est pas un backup.
L'audit produit un verdict en trois niveaux :
- Reprise immédiate : tous les documents sont à jour, l'équipe entrante peut démarrer le recouvrement dans la semaine.
- Reprise conditionnelle : deux ou trois documents manquent ou sont obsolètes. L'équipe sortante doit compléter avant la passation, délai estimé entre deux et quatre semaines.
- Reprise impossible : plus de la moitié des documents sont absents ou inutilisables. Reconstruire coûte moins cher que reprendre.
L'inventaire de sortie : dépôts, secrets, infrastructure, comptes, contrats tiers
Lorsque la reprise est validée, l'équipe sortante établit un inventaire exhaustif de tout ce qui sera transféré. Ce document contractuel engage sa responsabilité : tout élément omis et découvert plus tard dans l'année justifie une pénalité financière, à prévoir dans l'avenant de fin de contrat.
Dépôts de code
Liste des repositories Git, avec leur URL, leur branche principale et les droits d'accès actuels. Si les dépôts sont hébergés sur le compte personnel d'un développeur (GitHub, GitLab, Bitbucket), ils doivent être transférés vers l'organisation du client avant la fin du préavis. Un fork ne suffit pas, le dépôt original peut disparaître.
Secrets et credentials
Fichier sécurisé (1Password, Bitwarden, vault chiffré) contenant :
- Clés API des services tiers (paiement, email, SMS, analytics, monitoring).
- Tokens OAuth et refresh tokens pour les intégrations SaaS.
- Certificats SSL/TLS et leurs clés privées.
- Mots de passe administrateur des bases de données.
- Accès root ou administrateur aux serveurs de production.
Cet inventaire doit être livré au client, pas à l'équipe entrante. Le client décide ensuite ce qu'il partage et quand.
Infrastructure et comptes cloud
Liste de tous les comptes cloud (AWS, Azure, GCP, OVH, Scaleway) utilisés pour la plateforme, avec le niveau d'accès détenu par le prestataire. L'inventaire précise :
- Les ressources actives (serveurs, bases managées, CDN, stockage objet).
- Les coûts mensuels observés sur les trois derniers mois.
- Les alertes de monitoring configurées et leur destination (email, Slack, PagerDuty).
Le transfert des comptes se fait en deux temps : ajout de l'administrateur côté client comme propriétaire, puis révocation des accès du prestataire sortant après validation du recouvrement.
Contrats et abonnements tiers
Les plateformes B2B modernes s'appuient sur cinq à quinze services SaaS. L'inventaire liste :
- Le service (nom, URL, usage).
- Le type de contrat (gratuit, mensuel, annuel, usage).
- Le contact commercial (email, téléphone) si le service a été négocié directement.
- La date de renouvellement et le montant.
L'objectif est d'éviter qu'un service critique expire sans que personne ne le remarque, ce qui coupe la plateforme le jour du renouvellement raté.
La période de recouvrement entre l'équipe sortante et l'équipe entrante
Le recouvrement est la période où les deux équipes travaillent ensemble, sous pilotage du client. Sa durée varie de deux à six semaines selon la complexité de la plateforme. Moins de deux semaines, l'équipe entrante n'a pas le temps de poser toutes ses questions. Plus de deux mois, le budget explose et les responsabilités se diluent.
Semaine 1 : installation et première exploration
L'équipe entrante clone les dépôts, installe l'environnement local et déploie un environnement de staging miroir de la production. Elle vérifie que la procédure de build fonctionne et que les tests automatisés passent. Si des bloqueurs apparaissent (dépendances manquantes, secrets mal documentés, tests qui échouent), l'équipe sortante les corrige sous 48 heures.
Semaine 2 : session de transfert de connaissance
Réunion quotidienne d'une heure entre l'équipe entrante et un expert côté sortant, sur des modules précis :
- Jour 1 : architecture globale, flux de données entre composants.
- Jour 2 : authentification, autorisation, gestion des sessions.
- Jour 3 : intégrations tierces (paiement, facturation, notifications).
- Jour 4 : tâches planifiées (cron, workers, jobs asynchrones).
- Jour 5 : monitoring, logging, gestion des incidents.
Chaque session produit un compte-rendu écrit validé par les deux parties. Ces documents remplacent la documentation manquante.
Semaine 3 : déploiement supervisé
L'équipe entrante effectue son premier déploiement en production, sous supervision de l'équipe sortante. Le déploiement concerne une correction mineure ou un ajustement de configuration, pas une nouvelle fonctionnalité. L'objectif est de tester la procédure de déploiement et de vérifier que les accès sont bien transférés.
Semaine 4 et au-delà : support dégradé
L'équipe sortante reste joignable par email pour répondre aux questions ponctuelles, avec engagement de réponse sous 48 heures. Elle n'intervient plus directement sur la plateforme, sauf incident critique bloquant la production (critère : service inaccessible depuis plus de deux heures).
Le recouvrement se termine quand l'équipe entrante a déployé en production au moins trois fois sans aide, et que les délais de réponse aux incidents reviennent sous les SLA contractuels.
Ce qui rend une reprise impossible, et donc ce qu'il fallait exiger au départ
Certaines pratiques transforment une plateforme en actif non transférable. Voici les six situations qui rendent une reprise techniquement ou économiquement impossible.
1. Infrastructure détenue par le prestataire, sous ses propres comptes
Si la plateforme tourne sur le compte AWS ou Azure du prestataire, avec facturation refacturée au client, le transfert nécessite une migration complète des ressources. Coût estimé : entre 15 000 et 60 000 EUR selon le nombre de services utilisés, avec une indisponibilité de deux à cinq jours. La clause à exiger au départ : "Tous les comptes cloud sont créés au nom du client, le prestataire reçoit des accès délégués révocables."
2. Code propriétaire non documenté avec dépendances vers des bibliothèques internes du prestataire
Si l'application dépend de packages privés hébergés sur le registre interne du prestataire, sans licence de redistribution, l'équipe entrante ne peut pas reconstruire l'application. Elle doit soit réécrire les modules concernés, soit négocier une licence avec le prestataire, ce qui peut prendre six mois. La clause à exiger : "Toutes les dépendances logicielles doivent être open source ou disponibles via un registre public. Les bibliothèques internes sont livrées en source au client avec droits de modification."
3. Base de données sans schéma documenté et sans contraintes d'intégrité
Une base avec 80 tables sans clés étrangères, sans commentaires et sans diagramme est une boîte noire. L'équipe entrante passe trois mois à tracer les relations entre entités avant de pouvoir corriger le moindre bug. La clause à exiger : "Le schéma de base de données est livré sous forme de diagramme ERD mis à jour chaque trimestre, avec documentation des colonnes critiques."
4. Aucun test automatisé
Sans tests, impossible de vérifier qu'une correction ne casse pas une autre fonctionnalité. L'équipe entrante doit tester manuellement chaque scénario avant chaque déploiement, ce qui multiplie les délais et les coûts par trois. La clause à exiger : "Couverture de tests unitaires et d'intégration à 60 % minimum des modules métier, mesurée trimestriellement."
5. Déploiement manuel sans procédure écrite
Si le déploiement se fait "à la main" via FTP ou en copiant des fichiers sur le serveur, sans script ni pipeline CI/CD, chaque nouveau déploiement est un risque. L'équipe entrante doit reconstruire la procédure par essais-erreurs. La clause à exiger : "Déploiement automatisé via pipeline CI/CD, avec rollback en un clic."
6. Secrets et credentials stockés en dur dans le code
Clés API, tokens OAuth et mots de passe en clair dans les fichiers source sont un vecteur de fuite et un cauchemar en cas de reprise. L'équipe entrante doit traquer chaque occurrence dans l'historique Git et régénérer toutes les clés. La clause à exiger : "Tous les secrets sont stockés dans des variables d'environnement ou un gestionnaire de secrets, jamais dans le code source ou les commits."
Ces six critères constituent une checklist de démarrage de projet. Refuser un prestataire qui ne les accepte pas coûte moins cher que subir une reprise impossible trois ans plus tard.
Le coût réel d'un changement de prestataire, et comment on le réduit à l'avance
Un transfert de plateforme coûte entre 20 000 et 120 000 EUR selon la complexité, hors refonte. Ce budget se répartit ainsi :
- Audit de reprise : 3 000 à 8 000 EUR (10 à 20 jours d'expertise technique senior).
- Recouvrement et transfert de connaissance : 8 000 à 25 000 EUR (4 à 8 semaines à deux développeurs côté entrant, un expert côté sortant).
- Documentation manquante à reconstituer : 5 000 à 30 000 EUR (si moins de 40 % de la doc existe).
- Migration d'infrastructure : 4 000 à 35 000 EUR (si comptes cloud au nom du prestataire).
- Réécriture des modules critiques non documentés : 0 à 50 000 EUR (dépend de l'état du code et de la couverture de tests).
À cela s'ajoute le coût d'opportunité : pendant trois à six mois, aucune nouvelle fonctionnalité n'est livrée, ce qui retarde les objectifs métier.
Deux leviers réduisent le coût de 40 à 60 % :
Levier 1 : clauses de documentation obligatoire dans le contrat initial
Imposer une revue de documentation trimestrielle, avec pénalité de 2 % du montant mensuel en cas de non-conformité. Les livrables attendus : architecture diagram, API docs, database schema, deployment procedure. Coût de maintien de la doc : 2 à 4 jours par trimestre, soit moins de 3 000 EUR par an. Économie en cas de reprise : 15 000 à 40 000 EUR.
Levier 2 : comptes cloud et dépôts Git au nom du client dès le départ
Le prestataire reçoit des accès délégués, révocables à tout moment. En cas de reprise, il suffit de révoquer les accès, sans migration. Coût de mise en place : une demi-journée administrative. Économie en cas de reprise : 4 000 à 35 000 EUR.
Ces deux mesures doivent être négociées avant la signature du premier contrat. Les ajouter en cours de projet est juridiquement difficile et financièrement coûteux.
Reprendre sans réécrire : la règle des trois mois sans nouvelle fonctionnalité
La tentation après une reprise est de corriger immédiatement tout ce qui paraît mal fait. C'est une erreur stratégique. Chaque modification introduit un risque de régression, et l'équipe entrante n'a pas encore la connaissance métier pour arbitrer les priorités.
La règle des trois mois fonctionne ainsi :
Mois 1 : correction des bugs critiques uniquement. Critère : un bug est critique s'il bloque un processus métier ou expose des données sensibles. Tout le reste attend. Objectif : stabiliser la plateforme et comprendre les flux réels.
Mois 2 : refactoring localisé, un module à la fois. L'équipe identifie les trois zones du code les plus risquées (forte complexité cyclomatique, absence de tests, dépendances obsolètes) et les refactorise une par une. Chaque refactoring fait l'objet d'une revue de code et d'une validation sur staging avant production.
Mois 3 : premières fonctionnalités mineures. Ajout d'une nouvelle option dans un formulaire, export CSV d'un tableau existant, ajustement d'un email de notification. Rien qui touche au cœur métier. Objectif : valider que l'équipe maîtrise le cycle complet (développement, tests, déploiement, monitoring).
À partir du mois 4, l'équipe peut livrer des fonctionnalités métier à rythme normal. Les statistiques montrent qu'une équipe qui respecte cette règle réduit les incidents de production de 60 % par rapport à une équipe qui livre dès la semaine 2.
L'erreur courante : promettre au management une amélioration visible sous 30 jours. Résultat : une fonctionnalité bâclée, deux régressions non détectées et une perte de confiance qui dure six mois. Mieux vaut trois mois de stabilité, puis une roadmap solide.
FAQ
Un prestataire peut-il refuser de fournir l'inventaire de sortie ?
Juridiquement non, si le contrat initial inclut une clause de réversibilité ou de transfert de connaissances. En pratique, un prestataire mécontent peut rendre le processus difficile en fournissant des documents incomplets ou obsolètes. C'est pourquoi la clause doit préciser un format exigible (par exemple, "architecture diagram au format exportable, base de données sous forme de diagramme ERD, procédure de déploiement testable par une équipe tierce"). La présence d'une pénalité financière en cas de non-conformité (par exemple, retenue de 10 % sur la facture finale) incite au sérieux.
Combien de temps faut-il garder l'équipe sortante disponible après le recouvrement ?
Deux mois de support dégradé, avec réponse sous 48 heures, est la durée moyenne. Passé ce délai, l'équipe entrante doit être autonome. Prévoir une clause de support ponctuel après cette période (facturation à la demi-journée) pour les cas exceptionnels, comme la découverte d'un module critique non documenté.
Peut-on reprendre une plateforme sans accès au code source ?
Non. Une plateforme livrée uniquement sous forme binaire ou hébergée sur infrastructure inaccessible est un actif bloqué. Le client possède une licence d'utilisation, pas la maîtrise technique. Dans ce cas, la seule option est de reconstruire la plateforme avec un nouveau prestataire, en spécifiant dès le départ la propriété du code source et l'accès aux dépôts Git.
Quels indicateurs mesurent le succès d'une reprise ?
Trois KPI : temps de réponse aux incidents (doit revenir sous les SLA dans les deux mois), nombre de déploiements réussis sans assistance (au moins 5 sur 5 après trois mois), et taux de régression (bugs introduits par les corrections, doit rester sous 5 %). Si ces trois indicateurs sont au vert, la reprise est réussie.
Faut-il changer de stack technique lors d'une reprise ?
Seulement si la stack actuelle présente un risque avéré : framework en fin de vie sans migration officielle, dépendance vers une technologie propriétaire inaccessible, ou incompatibilité avec les compétences disponibles sur le marché local. Changer de stack pour suivre une tendance coûte entre 80 000 et 300 000 EUR et rallonge le projet de six à douze mois. Mieux vaut moderniser progressivement une fois la reprise stabilisée.
Pour approfondir les bonnes pratiques de développement sur mesure et sécuriser vos projets IT, consultez notre guide sur l'audit digital au Maroc. Nos équipes accompagnent également les entreprises dans le conseil digital pour structurer leurs partenariats techniques dès le départ.