Comment reprendre l'application d'un autre prestataire ?
En bref
Pour reprendre une application développée par un autre prestataire, récupérez d'abord tous les accès : code source, hébergement, base de données, nom de domaine et comptes des services tiers. Sécurisez ensuite l'existant par des sauvegardes et le changement des mots de passe, faites auditer le code, la sécurité et la documentation, puis décidez entre maintenir, faire évoluer progressivement ou reconstruire.
Reprendre une application développée par un autre prestataire se fait en trois temps : récupérer tout ce qui permet de la faire fonctionner, sécuriser l'existant, puis évaluer son état avant de décider de la suite. La reprise intervient dans des situations variées : fin de relation, prestataire devenu injoignable, insatisfaction, besoin d'évolutions que l'équipe actuelle ne peut pas assurer. Dans tous les cas, l'ordre des étapes compte.
Étape 1 : récupérer tous les accès
Sans accès complets, aucune reprise n'est possible. Dressez la liste et vérifiez chaque élément :
| Élément | Pourquoi il est indispensable |
|---|---|
| Code source et historique | Le dépôt du gestionnaire de versions, l'outil qui conserve toutes les modifications du code, permet de comprendre comment l'application a évolué. |
| Hébergement et serveurs | Pour déployer, surveiller et intervenir en cas de panne. |
| Base de données | Elle contient vos données : accès administrateur et sauvegardes. |
| Nom de domaine et DNS | L'adresse de l'application et ses réglages de redirection. |
| Services tiers | Paiement, envoi de courriels, cartographie, stockage, clés d'API. |
| Comptes des magasins d'applications | Indispensables pour publier une mise à jour d'une application mobile. |
| Documentation | Installation, architecture, procédures de mise en production. |
Vérifiez aussi que ces comptes sont au nom de votre organisation, et non au nom personnel d'un développeur ou du prestataire sortant.
Étape 2 : sécuriser l'existant immédiatement
- Changer les mots de passe et les clés d'accès dès que la transmission est faite, pour que l'ancien prestataire n'ait plus d'accès non prévus.
- Réaliser une sauvegarde complète du code, de la base et des fichiers, puis tester sa restauration. La règle de la sauvegarde 3-2-1 (trois copies, sur deux supports, dont une hors site) est un bon repère.
- Mettre en place une surveillance de la disponibilité, pour être alerté en cas de panne.
- Noter l'état de fonctionnement actuel : ce qui marche, ce qui est déjà signalé comme défectueux.
Étape 3 : auditer l'application
L'audit sert à connaître l'état réel de l'application avant de s'engager. Il porte sur :
- Le code : lisibilité, organisation, cohérence.
- Les composants : versions utilisées, composants obsolètes ou abandonnés.
- La sécurité : failles connues, gestion des mots de passe et des droits, exposition des données. Un audit de sécurité dédié peut compléter ce volet.
- Les tests automatisés : existent-ils, et couvrent-ils les fonctions critiques ?
- L'hébergement : configuration, sauvegardes, emplacement des données.
- Le respect du RGPD : données collectées, durées de conservation, accès.
L'audit mesure notamment la dette technique : l'ensemble des raccourcis, solutions provisoires et retards de mise à jour qui rendent chaque évolution future plus lente et plus risquée.
Étape 4 : choisir la bonne stratégie
| Stratégie | Adaptée quand |
|---|---|
| Maintenir en l'état | Le code est sain, les composants à jour, et peu d'évolutions sont prévues. |
| Faire évoluer progressivement | La base est exploitable mais demande une remise à niveau par étapes, menée en parallèle des évolutions. |
| Reconstruire | La dette technique est telle que chaque modification coûte plus qu'une nouvelle base, ou la technologie n'est plus maintenue. |
La reconstruction complète séduit souvent, mais elle comporte ses propres risques : règles métier oubliées, reprise de données, période de double fonctionnement. Elle se justifie par l'audit, pas par l'intuition.
Étape 5 : organiser la transition
- Obtenir, si possible, une passation avec l'ancien prestataire : explications sur l'architecture et les points fragiles.
- Commencer par des corrections simples, qui permettent de prendre en main le code sans risque.
- Documenter au fur et à mesure ce qui est découvert.
- Vérifier que le contrat initial vous autorise à utiliser, modifier et faire modifier le code par un tiers.
Préparer la prochaine reprise dès maintenant
Pour ne pas revivre la situation, faites inscrire dans tout nouveau contrat une clause de réversibilité : remise du code source, des accès, de la documentation et des données, dans un format et un délai définis.
NexSecure reprend la maintenance d'applications développées par d'autres prestataires, dans le cadre de son offre de maintenance.
Questions fréquentes
Que faire si l'ancien prestataire ne transmet pas le code source ?
Relisez le contrat pour vérifier ce qu'il prévoit sur la remise du code et les droits. En cas de blocage, un conseil juridique vous indiquera les démarches possibles.
Faut-il forcément reconstruire une application que l'on reprend ?
Non. Beaucoup d'applications peuvent être maintenues ou remises à niveau progressivement. Seul un audit permet de trancher.
Qu'est-ce que la dette technique ?
C'est l'accumulation de raccourcis, de solutions provisoires et de mises à jour repoussées, qui rend chaque évolution future plus lente et plus risquée.
Pourquoi changer les mots de passe après une reprise ?
Pour que seules les personnes chargées de l'application y aient accès. Les anciens identifiants ont pu être partagés ou conservés.
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet