Changer de prestataire, reprendre un logiciel après le départ d’un développeur clé ou récupérer une application acquise ne consiste pas seulement à transférer un dépôt Git. Une application en production dépend d’un ensemble beaucoup plus large : comptes cloud, certificats, tâches planifiées, sauvegardes, services tiers, procédures d’exploitation, connaissance métier et décisions historiques.
Les premières semaines déterminent la qualité de la relation future. Une équipe qui commence immédiatement par développer de nouvelles fonctions sans sécuriser cet environnement risque de découvrir les dépendances au moment le moins favorable : lors d’un incident ou d’une mise en production.
La méthode des 90 jours vise à reprendre le contrôle sans immobiliser inutilement le produit. Elle combine sécurisation, compréhension, stabilisation et construction d’une feuille de route.
Avant le transfert : définir ce qui doit réellement être remis
La réversibilité doit être préparée avant la date de bascule. La première liste concerne les actifs : code source, historique, tickets, documentation, schémas, fichiers de conception, tests, scripts de déploiement, images de conteneurs et licences.
La seconde concerne les accès : hébergement, DNS, certificats, base de données, stockage, e-mail transactionnel, outils de supervision, CDN, registres de paquets, comptes mobiles, magasins d’applications, services de paiement, plateformes analytiques et sauvegardes. Pour chaque accès, il faut connaître le propriétaire légal, les administrateurs, le mode de récupération et le processus de rotation.
La troisième concerne le fonctionnement métier. Quels parcours ne peuvent pas être interrompus ? Quelles opérations nécessitent un traitement manuel ? Quels échanges sont attendus par des partenaires ? Quels incidents se répètent ? Quels engagements ont été pris envers les utilisateurs ?
Un inventaire incomplet n’empêche pas toujours la reprise. Il transforme toutefois les zones manquantes en risques explicites et en tâches prioritaires.
Phase 1 — J0 à J15 : sécuriser et rendre observable
La première étape ne consiste pas à « nettoyer le code ». Elle consiste à s’assurer que l’application peut être observée, sauvegardée et récupérée.
L’équipe confirme les accès, retire les comptes obsolètes, active l’authentification renforcée lorsque cela est possible et organise la rotation des secrets. Elle vérifie les sauvegardes, leur rétention et surtout la possibilité de restauration. Elle recense les certificats et abonnements qui pourraient expirer silencieusement.
En parallèle, elle reconstitue le chemin de mise en production : construction, configuration, migrations de base, déploiement, purge de caches, redémarrage de workers et retour arrière. Une première exécution doit être réalisée sur un environnement non productif. Si ce chemin n’est pas reproductible, toute évolution est temporairement classée comme risquée.
La supervision doit couvrir les signaux essentiels : disponibilité, taux d’erreur, temps de réponse, saturation, espace disque, files d’attente, échec des tâches planifiées et santé des sauvegardes. L’objectif n’est pas d’installer immédiatement une plateforme complexe, mais d’éviter qu’un incident ne soit découvert par le client final.
Livrables de la phase : inventaire des accès, liste des risques immédiats, procédure de contact, preuve de sauvegarde, carte simplifiée de l’exploitation et premier tableau de bord.
Phase 2 — J15 à J45 : comprendre et documenter
Une fois la continuité minimale assurée, l’équipe reconstitue l’architecture et les principales règles métier. Elle installe le projet sur un environnement propre, exécute les tests, observe les journaux et suit quelques demandes réelles de bout en bout.
Les entretiens sont courts et ciblés. Le métier décrit les opérations critiques et les exceptions. L’ancien prestataire, lorsqu’il est disponible, explique les zones sensibles, les procédures non documentées et les choix qui semblent étranges sans leur contexte. L’exploitation décrit les incidents récurrents et les manipulations manuelles.
Le code est analysé selon les neuf dimensions d’un audit technique : architecture, maintenabilité, dépendances, sécurité, données, performance, tests, exploitation et transférabilité. L’objectif n’est pas encore de corriger chaque défaut, mais de savoir où une modification est sûre et où elle nécessite des protections supplémentaires.
La documentation produite doit être utile immédiatement : démarrage local, architecture, flux externes, procédures de déploiement, restauration, tâches planifiées, matrice des environnements et glossaire métier. Une documentation exhaustive mais jamais relue est moins utile qu’un guide court vérifié par une nouvelle personne.
Livrables de la phase : cartographie, guide de prise en main, registre des dépendances, audit initial et liste des inconnues restantes.
Phase 3 — J45 à J90 : stabiliser et restaurer la capacité d’évolution
La troisième phase traite les risques qui empêchent de travailler normalement. Les correctifs prioritaires concernent généralement les sauvegardes, permissions, dépendances vulnérables, erreurs silencieuses, tâches instables et procédures de déploiement.
Les parcours métier les plus sensibles sont protégés par des tests de caractérisation. Ces tests décrivent le comportement actuel, même lorsque le code n’est pas encore idéal. Ils permettent ensuite de modifier progressivement sans réinventer les règles.
L’équipe construit également une stratégie de mise à niveau. Les dépendances sont classées entre mises à jour simples, migrations à préparer et composants à remplacer. Les améliorations de performance sont basées sur des mesures. Les demandes fonctionnelles en attente sont requalifiées à la lumière des nouvelles contraintes techniques.
Enfin, les parties prenantes valident une feuille de route en trois horizons : sécurisation, modernisation et évolution produit. Chaque chantier précise son bénéfice, son risque, ses dépendances et son ordre de grandeur.
Livrables de la phase : version stabilisée, couverture de tests prioritaire, pipeline de livraison fiable, backlog classé et roadmap arbitrable.
Après 90 jours : passer en maintenance maîtrisée
La maintenance courante repose sur un cadre visible. Les demandes sont qualifiées, les incidents ont une procédure, les changements sont traçables et les versions font l’objet d’une politique. Les indicateurs portent sur la qualité de service, pas seulement sur le nombre de tickets fermés.
Un fonctionnement sain suit notamment : disponibilité des parcours critiques, délai de détection, délai de rétablissement, taux d’échec des déploiements, âge des dépendances, couverture des parcours à risque et volume de travail non planifié.
La connaissance doit rester distribuée. Les revues, comptes rendus, procédures testées et rotations d’astreinte évitent de recréer une dépendance à une seule personne chez le nouveau prestataire.
La chronologie commence avant le transfert par l’inventaire des actifs, des accès et des règles métier. De J0 à J15, la priorité est de sécuriser les accès, les sauvegardes, les déploiements et la supervision. De J15 à J45, l’équipe reconstitue l’architecture, documente l’exploitation et identifie les inconnues. De J45 à J90, elle stabilise les risques prioritaires, protège les parcours sensibles par des tests et construit la feuille de route. Le régime courant maintient ensuite la qualité de service et la connaissance partagée.
Assistant de cadrage local
Générateur de plan de reprise sur 90 jours
Décrivez le contexte connu pour obtenir une chronologie, les blocages à lever et un RACI simplifié. Le résultat est une aide de cadrage : il ne constitue ni un audit, ni un engagement de délai.
Confidentialité : aucune donnée ne quitte votre navigateur et aucune réponse n’est stockée. Ne saisissez aucun nom de serveur, domaine interne, mot de passe ou nom de client.
Feuille de route indicative
Votre plan de reprise personnalisé
RACI simplifié
R réalise, A arbitre, C est consulté, I est informé. Les rôles sont génériques et doivent être nommés lors du cadrage.
| Activité | Client | Ancien prestataire | Nouveau prestataire | Hébergeur | Métier |
|---|
Les scénarios difficiles et la réponse adaptée
L’ancien prestataire ne coopère pas
Commencez par sécuriser ce qui appartient au client : domaines, comptes contractuels, données, dépôts et sauvegardes. Documentez chaque élément manquant et son impact. Évitez les accusations techniques non vérifiées ; concentrez les échanges sur les actifs et obligations de réversibilité.
L’équipe de reprise devra reconstruire une partie de la connaissance à partir du code, des configurations, des journaux et des utilisateurs. Ce travail doit être planifié comme tel, pas absorbé silencieusement dans la maintenance.
Le code ne comporte aucun test
Il serait imprudent de lancer immédiatement une refactorisation générale. Identifiez les parcours à fort impact, capturez leur comportement actuel et ajoutez des tests autour des interfaces stables. Les journaux, copies anonymisées de données et tests de bout en bout peuvent apporter une première protection avant une couverture plus fine.
L’hébergement n’est pas documenté
Établissez une carte depuis l’extérieur vers l’intérieur : DNS, CDN, pare-feu, équilibreurs, serveurs, conteneurs, bases, stockage, tâches et services externes. Vérifiez les factures et consoles pour repérer les ressources invisibles dans le code. Ne supprimez rien sans période d’observation et preuve d’inutilité.
L’application subit déjà des incidents
Séparez le flux « rétablir le service » du flux « comprendre et moderniser ». Mettez en place une cellule d’incident, des priorités temporaires et un gel des changements non essentiels. Chaque incident doit enrichir la cartographie et les protections plutôt que déclencher une succession de correctifs isolés.
Ce que le client doit conserver à l’issue de la reprise
Une reprise réussie ne se mesure pas uniquement au fait que le nouveau prestataire sait intervenir. Le client doit retrouver la maîtrise de ses actifs et de ses décisions. Il doit disposer d’un inventaire des comptes, d’une documentation minimale vérifiée, d’une visibilité sur les risques, d’une procédure de sortie et d’un budget compréhensible.
Les environnements doivent être reproductibles, les sauvegardes restaurables, les mises en production traçables et les accès nominatifs. Le backlog doit distinguer maintenance corrective, dette technique, sécurité, évolutions et demandes métier.
La valeur d’une reprise progressive
La tentation est forte de profiter du changement d’équipe pour tout réécrire. Pourtant, les 90 premiers jours révèlent souvent que certaines briques sont fiables, que des règles métier sont plus complexes qu’annoncé et que les urgences ne se trouvent pas là où l’on pensait.
Une reprise structurée préserve ce qui fonctionne, réduit d’abord les risques et crée les conditions d’une modernisation rationnelle. Partitech sait reprendre la maintenance de projets développés par des tiers et accompagner leur évolution dans la durée, de l’audit à l’hébergement et à l’infogérance.
Pour cadrer la transition, commencez par un audit technique complet de l’application, puis découvrez comment préparer la réversibilité et le changement de prestataire. L’offre Maintenance, évolutions et hébergement et notre référence de plateforme métier financière accompagnée dans la durée complètent cette démarche.
Références officielles
Références vérifiées le 17 août 2026 :