Changer d'agence de développement sans coupure de service : la méthode en 5 étapes

Changer d'agence de développement est stressant mais gérable. Voici les 5 étapes pour éviter la coupure de service et récupérer la maîtrise de votre code. En 40+ transitions réalisées chez Nehos, nous n'avons jamais eu de coupure de production non planifiée.

#Les 6 signaux qui indiquent qu'il faut changer d'agence

Avant de parler de méthode, voici les signaux d'alerte que nos clients nous rapportent systématiquement avant de faire appel à nous :

1. Délais non tenus de façon répétée : un retard ponctuel est humain. Des retards systématiques (> 3 sprints consécutifs) révèlent un problème structurel de capacité ou de gestion de projet.
2. Absence totale de documentation : si vous n'avez aucun document décrivant l'architecture de votre application, vous êtes en dépendance totale vis-à-vis de votre prestataire.
3. Turnover fort côté agence : vous avez eu 4 développeurs différents sur votre projet en 18 mois. À chaque rotation, la connaissance métier repart à zéro.
4. Aucun test automatisé : un projet sans tests unitaires ou d'intégration est impossible à maintenir sereinement. Chaque correction risque de casser autre chose.
5. Factures incompréhensibles : des bons de commande libellés « développements divers » sans détail de ce qui a été livré cachent souvent une gestion de projet approximative.
6. L'agence ne répond plus : mails sans réponse depuis plus de 72h ouvrables, ticket de support en attente depuis 2 semaines. C'est le signal le plus clair.

Si vous cochez 3 de ces 6 signaux, il est temps d'agir — avant l'urgence, pas pendant.

#Ce que vous devez récupérer AVANT de résilier

C'est l'étape la plus critique. Voici la liste exhaustive de ce qu'il faut récupérer avant que la relation commerciale se dégrade :

Astuce : demandez ces éléments en invoquant votre droit à la portabilité contractuelle — pas en mentionnant votre intention de partir. Une agence coopérative les fournira sans difficulté. Une agence qui résiste sur ces points vous donne une information précieuse sur la suite.

#Le problème de l'agence qui retient le code

C'est plus courant qu'on ne le croit, et c'est illégal. En droit français, le code source produit dans le cadre d'un contrat de prestation de services appartient au client donneur d'ordre, sauf clause contractuelle explicite transférant la propriété à l'agence (ce qui est rare et doit être accepté consciemment).

La jurisprudence française est claire sur ce point : les tribunaux condamnent régulièrement les prestataires qui refusent de livrer le code source après la fin du contrat. Les dommages et intérêts accordés incluent souvent le coût de reconstitution du code et le préjudice commercial lié à l'indisponibilité.

Concrètement, si votre agence refuse de vous transmettre le code :

1. Envoyez une mise en demeure par LRAR précisant votre droit à la propriété du code
2. Contactez votre avocat spécialisé en droit du numérique (48-72h suffisent pour obtenir une ordonnance de référé)
3. Documentez tous les échanges (emails, messages, tickets)

Nous accompagnons certains clients dans cette situation — l'audit de reprise peut se faire à partir d'une copie partielle du code ou d'un accès temporaire obtenu par voie légale.

#Les 5 étapes de la transition : notre méthode

#Étape 1 — Audit de reprise (2 semaines)

Avant de signer quoi que ce soit avec une nouvelle agence, faites auditer la base de code existante. Cet audit doit couvrir :

• Architecture technique : structure du projet, patterns utilisés, couplage entre modules
• Dette technique : dépendances obsolètes, failles de sécurité connues (CVE), code mort
• Couverture de tests : quels tests existent, sont-ils maintenus ?
• Documentation : ce qui existe, ce qui manque
• Déployabilité : comment l'application se déploie-t-elle ? Existe-t-il un processus CI/CD ?

Chez Nehos, cet audit est proposé à un forfait fixe de à partir de 2 125 € HT et produit un rapport de 20 à 40 pages. Il est réalisable sans que l'agence sortante ne soit impliquée, votre accès Git.

#Étape 2 — Sélection et onboarding de la nouvelle agence

Une fois l'audit en main, vous avez une base objective pour consulter des prestataires. Partagez le rapport d'audit (ou un résumé) aux agences candidates — celles qui le lisent sérieusement et posent des questions pertinentes méritent votre attention.

Les questions à poser à la nouvelle agence avant de signer :

• Comment gérez-vous l'onboarding sur une base de code existante ?
• Qui sera le responsable technique dédié sur notre projet ?
• Quels SLA proposez-vous pour la maintenance corrective ?
• Comment documentez-vous le code que vous produisez ?
• Quelle est votre procédure de transfert de connaissance en fin de contrat ?

#Étape 3 — Période double (2 à 4 semaines)

C'est l'étape que la plupart des entreprises sautent, au détriment de la continuité de service. La période double consiste à faire cohabiter les deux agences pendant quelques semaines :

• L'agence sortante assure encore les urgences P1
• La nouvelle agence monte en compétence sur la base de code
• Les credentials et accès sont progressivement transférés
• Les déploiements sont réalisés en double validation

Cela nécessite une communication claire avec l'agence sortante. Même si la relation est dégradée, les deux semaines de cohabitation sont infiniment moins coûteuses qu'une coupure de service.

#Étape 4 — Bascule (J-day)

La bascule doit être planifiée, documentée et réversible :

• Choisissez un créneau à faible trafic (nuit, week-end selon l'activité)
• Préparez un plan de rollback (comment revenir en arrière si la bascule échoue ?)
• Notifiez les parties prenantes internes (DSI, métier, direction)
• Réalisez un smoke test immédiatement après la bascule (15 à 30 points de contrôle)

#Étape 5 — Stabilisation (2 à 4 semaines)

Les premières semaines après la bascule sont à surveiller de près. La nouvelle agence doit :

• Répondre aux tickets P1 avec les SLA contractuels
• Documenter les éléments découverts en cours d'intervention
• Établir le premier rapport mensuel d'activité
• Proposer une roadmap de traitement de la dette technique identifiée

#Ce qu'on trouve typiquement dans un code « abandonné »

En 40+ reprises de projet, voici les problèmes que nous rencontrons systématiquement :

• Secrets dans le code : clés API, mots de passe, tokens hardcodés dans le repository (parfois poussés sur GitHub public par accident)
• Dépendances non mises à jour depuis 3 à 5 ans : certains packages ont des CVE critiques connues depuis 2 ans
• Zéro test automatisé : ou des tests qui ne passent plus depuis 6 mois et que personne n'a corrigés
• Configuration hardcodée : URLs de production en dur dans le code, chemins de fichiers absolus spécifiques au serveur de l'agence
• Absence de CI/CD : les déploiements se font par FTP ou par SSH manuel — chaque déploiement est un risque
• Base de données sans index : requêtes qui fonctionnaient bien avec 1 000 lignes et qui explosent à 100 000 lignes

Notre guide pour choisir votre prochaine agence IA liste les questions à poser pour éviter de se retrouver dans la même situation.

#Pour aller plus loin : service TMA Nehos

Une fois la transition réalisée, la mise sous TMA est la meilleure façon d'éviter de revivre cette situation. Un contrat TMA bien structuré inclut la documentation systématique, les rapports mensuels et une clause de réversibilité — ce qui vous protège même si vous décidez de changer à nouveau de prestataire dans 3 ans.

Pour évaluer l'état de votre application actuelle, utilisez notre outil de diagnostic de dette technique — gratuit, résultat en 15 minutes.