Changer d'agence de développement : la checklist de réversibilité
28/08/2026
Changer d'agence de développement n'est pas un acte technique, c'est un transfert. Le code n'est qu'une partie de ce qui doit passer d'une main à l'autre, et c'est souvent la partie la plus facile. Ce qui bloque, ce sont les accès dispersés, les secrets stockés nulle part, les comptes ouverts au nom d'un développeur parti depuis longtemps.
Une transition mal préparée coûte des semaines et parfois une interruption de service. Une transition organisée se déroule en quelques jours sans que vos utilisateurs s'en aperçoivent. La différence tient à une liste et à un ordre. Cet article donne les deux.
L'ordre des opérations
Trois principes gouvernent une transition réussie, et ils sont contre-intuitifs.
Récupérez avant d'annoncer. Tant que la relation est normale, les demandes d'accès passent pour de la bonne gestion. Après l'annonce du départ, chaque demande devient une négociation. Constituez votre dossier d'abord.
Faites se recouvrir les deux prestataires. La tentation est de couper le premier pour ne pas payer deux fois. C'est une fausse économie : deux à quatre semaines de recouvrement permettent à l'équipe entrante de poser ses questions à celle qui part, pendant qu'elle est encore payée pour répondre.
Testez ce que vous récupérez. Un accès transmis n'est pas un accès vérifié. Une sauvegarde livrée n'est pas une sauvegarde restaurable. Chaque élément de la liste ci-dessous doit être testé, pas seulement reçu.
Les 8 blocs à récupérer
1. Le code et son historique
Demandez le dépôt complet avec son historique de versions, pas une archive du dernier état. L'historique raconte pourquoi le code est ce qu'il est, et cette information vaut des jours de travail pour l'équipe qui reprend.
Vérifiez que toutes les branches actives sont présentes, ainsi que les éventuels dépôts annexes : scripts d'infrastructure, outils internes, applications mobiles séparées. Un projet vit rarement dans un seul dépôt.
2. Les secrets et variables d'environnement
C'est le bloc le plus souvent oublié et le plus bloquant. Clés d'API, jetons d'accès, chaînes de connexion à la base, certificats, clés de signature. Ces valeurs ne figurent jamais dans le code, par bonne pratique, et vivent dans la configuration du serveur ou dans le gestionnaire de secrets du prestataire.
Sans elles, le code récupéré ne démarre pas. Exigez la liste exhaustive avec, pour chacune, le service concerné et son usage.
3. La base de données
Un export complet et récent, avec le schéma et les données. Puis, immédiatement, un test de restauration sur un environnement séparé. Un export qui ne se restaure pas est un fichier inutile, et cela se découvre uniquement en essayant.
Récupérez aussi les scripts de migration qui décrivent l'évolution du schéma dans le temps. Ils sont indispensables pour toute évolution future.
4. L'hébergement et l'infrastructure
Identifiez les comptes concernés et leur titulaire. L'objectif est que la facturation et la propriété des comptes soient à votre nom, pas à celui du prestataire. Un compte cloud au nom de l'agence sortante reste une dépendance après son départ.
Récupérez la description de l'architecture : quels serveurs, quels services managés, comment le déploiement se déclenche, où vont les journaux applicatifs.
5. Le nom de domaine et le DNS
Vérifiez le titulaire du domaine et l'accès à la zone DNS. Exportez la configuration DNS complète avant toute manipulation, car c'est le genre d'élément dont on découvre l'importance au moment où il casse, en emportant les courriels avec lui.
Si le domaine est au nom du prestataire, traitez ce point en priorité absolue. Notre article sur le prestataire qui ne répond plus détaille les recours quand la situation se complique.
6. Les comptes tiers
Passerelle de paiement, envoi de courriels transactionnels, SMS, stockage, outils d'analyse, service de suivi des erreurs. Chacun a un compte, un abonnement et des clés.
Pour chaque service, trois questions : au nom de qui est le compte, qui paie, et où sont les clés utilisées par l'application. Les comptes ouverts avec l'adresse électronique d'un développeur sont fréquents et deviennent inaccessibles dès son départ.
7. La documentation
Prenez ce qui existe, même incomplet : schémas d'architecture, procédures de déploiement, particularités connues, décisions techniques. À défaut de document, organisez une session d'une à deux heures entre les deux équipes et enregistrez-la. La transmission orale vaut mieux que rien, à condition d'en garder une trace.
8. La propriété intellectuelle
Le dernier bloc est juridique. Vérifiez que votre contrat comporte une cession de droits en bonne et due forme, faute de quoi la reprise par une autre équipe vous expose. Ce sujet est développé dans notre article sur la récupération du code source, car le droit français est moins protecteur pour le client qu'on ne l'imagine.
La clause de réversibilité, à écrire avant d'en avoir besoin
Tout ce qui précède se règle en une clause, si elle a été prévue au contrat initial. La réversibilité organise à l'avance la restitution complète en fin de relation.
Une clause utile précise quatre choses : la liste des éléments restitués, le délai de restitution après notification, l'obligation d'assistance au transfert pendant une période définie, et le format attendu des livrables. Certains contrats prévoient que cette assistance est incluse, d'autres qu'elle est facturée à un tarif convenu d'avance. Les deux sont acceptables, l'absence de clause ne l'est pas.
Le meilleur moment pour la négocier est la signature, quand la relation est bonne et que le prestataire veut le contrat. Six mois plus tard, la même demande sera lue comme un signe de méfiance.
Les erreurs qui coûtent cher
Couper trop tôt. Économiser un mois de prestation pour perdre trois semaines à reconstituer une configuration est un mauvais calcul.
Annoncer avant de sécuriser. L'ordre compte plus que la vitesse.
Se contenter d'un transfert de fichiers. Le code sans les secrets, sans la base et sans l'infrastructure ne redémarre pas.
Négliger le test de restauration. C'est le seul moyen de savoir si votre sauvegarde existe vraiment.
Oublier les comptes tiers. Ils cassent des fonctions visibles du produit, souvent quelques semaines après la transition, quand plus personne ne fait le lien.
Comment nous prenons le relais
Une reprise commence chez nous par cette checklist, transformée en état des lieux partagé avec le client. Chaque ligne est marquée reçue, testée ou manquante, ce qui rend visible ce qui reste à obtenir du prestataire sortant pendant qu'il est encore joignable.
Vient ensuite la mise en route sur notre environnement : redémarrage complet de l'application à partir des seuls éléments reçus. C'est le test de vérité, celui qui révèle les secrets oubliés et les dépendances non documentées. Nous préférons le faire pendant la période de recouvrement, quand les questions trouvent encore une réponse.
L'audit du code suit, une fois l'application maîtrisée, et débouche sur un état des lieux chiffré. Le passage en maintenance applicative intervient quand le socle est stable, avec des engagements de délai écrits. Les ordres de grandeur budgétaires sont détaillés dans notre article sur le coût de la maintenance d'une application.
Une transition proprement menée prend en général deux à quatre semaines pour une application de taille moyenne. Ce qui l'allonge n'est presque jamais la complexité technique, mais l'attente d'éléments que personne n'avait pensé à demander.
Questions fréquentes
Dans quel ordre changer d'agence de développement ?
Récupérez et testez vos accès pendant que la relation est encore normale, faites se recouvrir les deux prestataires deux à quatre semaines, puis coupez. Annoncer le départ avant d'avoir sécurisé les accès transforme un transfert en négociation.
Qu'est-ce qu'une clause de réversibilité ?
C'est la clause qui organise la restitution complète en fin de contrat : code, données, accès, documentation, comptes tiers, avec un délai et une obligation d'assistance au transfert. Elle se négocie à la signature, pas au moment du départ.
Que faut-il récupérer en plus du code source ?
Les secrets et variables d'environnement, un export restaurable de la base, les accès à l'hébergement, le domaine et la zone DNS, les comptes tiers, la documentation, et la preuve de la cession des droits. Le code seul ne suffit jamais à redémarrer une application.
Faut-il faire se chevaucher l'ancien et le nouveau prestataire ?
Oui, deux à quatre semaines dans la plupart des cas. Le coût de ce recouvrement est très inférieur à celui d'une reconstitution à l'aveugle, et c'est la seule période où l'équipe sortante répond encore aux questions.
Combien de temps prend un changement de prestataire ?
Deux à quatre semaines pour une application de taille moyenne quand les accès sont disponibles. Le facteur limitant est rarement technique, c'est l'obtention des éléments manquants auprès du prestataire sortant.
Mon application peut-elle tomber pendant la transition ?
Le risque existe mais se maîtrise. Les points de rupture sont connus : renouvellements de domaine et de certificats, moyens de paiement des services, secrets manquants au redémarrage. Traités en amont, ils ne provoquent pas d'interruption visible.