La plupart des guides expliquent comment choisir un partenaire logiciel. Bien peu expliquent comment en changer, alors que c’est souvent la décision la plus difficile. Un système tourne déjà en production, des équipes en dépendent chaque jour, et la seule équipe qui le comprend entièrement est justement celle dont vous n’êtes plus sûr. Nous reprenons régulièrement des projets de ce type, et ceux qui se passent bien ont un point commun : le client a préparé sa sortie avant de l’annoncer.
Les signes qu’il est temps de changer de partenaire
Toute mission connaît un mauvais mois. Ce qui compte, c’est de savoir si les problèmes sont expliqués et corrigés, ou simplement répétés. Voici les schémas qui, sur deux ou trois trimestres, signifient généralement que la relation ne s’en remettra pas :
Des échéances manquées sans explication. Un retard avec une cause claire et un nouveau plan, c’est normal. Des retards qui arrivent par surprise, sans que rien ne change dans la conduite du travail, trahissent un problème de pilotage que le prestataire ne règle pas.
Seul le prestataire sait déployer. Si une mise en production exige une personne précise chez le prestataire, votre système ne vous appartient pas tout à fait, et plus cela dure, plus partir coûte cher.
Chaque évolution coûte plus cher que la précédente. Des estimations en hausse pour un travail comparable sont le signe le plus clair d’une base de code de plus en plus difficile à faire évoluer, et d’une équipe qui ne rembourse pas cette dette.
L’équipe ne cesse de tourner. De nouveaux visages chaque trimestre et aucune documentation : le savoir s’en va avec chaque départ. Demandez qui, parmi l’équipe du premier mois, travaille encore sur votre projet.
Si au moins deux de ces constats se vérifient, appliquez à votre prestataire actuel la liste de contrôle pour choisir un partenaire de développement logiciel, comme si vous le rencontriez pour la première fois. Parfois, une conversation franche et une organisation revue suffisent à redresser la situation. Souvent, l’exercice confirme ce que vous soupçonniez déjà.
Ce qu’il faut sécuriser avant d’en parler à quiconque
L’ordre des opérations compte plus que le choix du nouveau prestataire. Avant d’annoncer le changement, et même avant d’entamer des discussions sérieuses avec un remplaçant, assurez-vous que votre entreprise détient les éléments suivants, en son nom propre :
- Un accès administrateur à chaque dépôt de code, y compris ceux qu'utilise seulement la CI du prestataire
- La propriété des comptes cloud, des domaines, du DNS et des fiches sur les stores d'applications, au nom de votre entreprise
- Chaque secret et identifiant : clés d'API, mots de passe des bases de données, certificats de signature, accès aux services tiers
- Des sauvegardes de base de données que vous avez vous-même restaurées au moins une fois
- Toute la documentation existante : notes d'architecture, runbooks, procédures de déploiement, aussi maigres soient-elles
- La liste de chaque service tiers dont dépend le système, et de qui le paie
L’essentiel devrait déjà vous appartenir en vertu de votre contrat. Relisez les clauses sur la propriété intellectuelle, les obligations de réversibilité et les préavis, et gardez un ton professionnel : vous aurez besoin de la coopération de l’équipe sortante pendant des semaines après la décision.
Le moment le moins cher pour sécuriser l’accès à votre propre système, c’est avant que quiconque ne sache que vous partez.
Un plan de passation par étapes
La façon la plus risquée de changer de partenaire, c’est une bascule unique à date fixe. Une passation par étapes maintient le système en marche et laisse à la nouvelle équipe le temps de l’apprendre, pendant que l’ancienne peut encore répondre aux questions.
Semaines 1-2 : observer. La nouvelle équipe lit le code, monte ses propres environnements et regarde l’équipe sortante déployer et gérer les incidents. L’objectif est une cartographie écrite du système : composants, flux de données, intégrations, et les parties que personne ne comprend.
Semaines 3-4 : évolutions supervisées. La nouvelle équipe réalise de petites évolutions réelles et les déploie, sous la relecture de l’ancienne. C’est là que remontent la documentation manquante et les étapes de build fragiles, et mieux vaut maintenant qu’en pleine panne.
Semaines 5-8 : reprise par périmètre. La responsabilité change de mains un périmètre à la fois : d’abord les parties les mieux couvertes par les tests, en dernier les plus risquées. Le prestataire sortant reste en astreinte, idéalement sous un petit forfait, jusqu’au transfert du dernier périmètre.
Résistez à l’envie de tout réécrire dès l’arrivée de la nouvelle équipe. Un nouveau partenaire qui propose de tout reconstruire avant de comprendre le système répète l’erreur que vous cherchez à fuir. Stabilisez d’abord, puis améliorez un module à la fois, l’approche que nous décrivons dans moderniser l’existant sans tout réécrire.
Choisir le partenaire suivant
Le second choix doit être plus exigeant que le premier. Demandez au candidat comment il a déjà repris des systèmes, et réclamez un plan de passation anonymisé issu d’un vrai projet. Convenez d’une facturation au jalon plutôt que d’un contrat en régie sans limite, et faites de la documentation un livrable, pas une faveur. Surtout, vérifiez qu’il serait facile de quitter ce nouveau partenaire : la meilleure protection contre une seconde lecture de cet article reste une relation à laquelle vous pourriez mettre fin à peu de frais.
Questions fréquentes
Quand faut-il changer de partenaire de développement logiciel ?
Quand les problèmes cessent d'être expliqués et commencent à se répéter : des échéances manquées sans raison, un système que seul le prestataire sait déployer, un coût par évolution qui grimpe et une équipe qui tourne sans cesse. Un mauvais mois est normal ; un schéma qui dure deux ou trois trimestres est un signal.
Comment changer de prestataire informatique sans perdre son projet ?
Sécurisez le code, l'infrastructure, les identifiants et les sauvegardes avant d'annoncer le changement, puis organisez une passation par étapes : la nouvelle équipe observe, puis déploie sous supervision, puis reprend un périmètre à la fois pendant que l'ancien prestataire reste joignable.
Combien de temps dure une passation logicielle ?
Pour un système de gestion classique, quatre à huit semaines de chevauchement entre l'ancienne et la nouvelle équipe. Les systèmes sans documentation ou sans tests demandent davantage, car la nouvelle équipe doit d'abord reconstituer ce savoir.
Faut-il réécrire le logiciel quand on change de partenaire ?
Presque jamais en première étape. Un nouveau partenaire doit stabiliser et comprendre le système avant de proposer des changements. Ne remplacez des parties que lorsqu'une raison claire le justifie, un module à la fois.