Reprendre une application développée par un autre fournisseur

1. Récupérer les accès avant tout le reste

C'est l'étape la plus souvent négligée, et celle qui bloque le plus de reprises. Avant de parler de code, dressez la liste de tout ce qui fait fonctionner l'application et vérifiez qui en est titulaire :

• le dépôt de code source avec tout son historique (Git), et pas seulement une archive de la dernière version ;
• l'hébergement : serveurs, compte infonuagique, panneau de contrôle ;
• le nom de domaine et la zone DNS ;
• la base de données et ses sauvegardes ;
• les comptes Apple Developer et Google Play, s'il y a une application mobile ;
• les services tiers : paiement, envoi de courriels et de textos, cartes, stockage de fichiers ;
• les clés d'API, mots de passe et certificats utilisés par l'application ;
• les outils de surveillance, de journalisation et de déploiement.

Idéalement, chaque compte est au nom de votre entreprise et votre ancien fournisseur n'y a qu'un accès d'invité. Si ce n'est pas le cas, faites transférer ces comptes en priorité, tant que la relation le permet encore.

2. Vérifier qu'on peut reconstruire et déployer l'application

Avoir le code ne suffit pas : une autre équipe doit pouvoir l'installer, l'exécuter et le mettre en ligne sans l'aide de son auteur. Demandez :

• la procédure d'installation d'un environnement de développement ;
• la liste des variables d'environnement et des paramètres (les valeurs secrètes se transmettent par un canal sécurisé, jamais par courriel) ;
• la procédure de déploiement, manuelle ou automatisée ;
• la procédure de restauration d'une sauvegarde, testée au moins une fois.

Le meilleur test est simple : un nouveau développeur réussit-il un déploiement complet en suivant seulement la documentation ? Si oui, le plus gros risque est écarté.

3. Faire auditer l'application

L'audit donne une image fidèle de ce que vous reprenez, avant de vous engager dans des évolutions. Il porte sur :

• Les dépendances : versions des langages, des cadriciels (frameworks) et des bibliothèques, composants arrivés en fin de vie.
• La sécurité : secrets laissés dans le code, droits d'accès trop larges, failles connues, protection des renseignements personnels.
• Le code et les tests : structure, lisibilité, présence de tests automatisés et ce qu'ils vérifient réellement.
• Les données : modèle, cohérence, volumes. Les données survivent souvent au logiciel, et ce sont elles qui ont le plus de valeur.
• L'exploitation : sauvegardes, surveillance, journaux, plan de reprise après incident.

Une application sans documentation peut tout de même être reprise. La compréhension se reconstruit à partir du code, de la base de données, des journaux et de la façon dont vos équipes s'en servent. L'un des premiers livrables doit alors être une documentation minimale.

Chez GentBit, l'audit se termine par la liste des risques classés par gravité, un plan de reprise et une estimation des travaux.

4. Garder, stabiliser ou reconstruire

La tentation de tout réécrire est forte, surtout quand le code est difficile à lire. C'est rarement la meilleure décision : une réécriture complète coûte cher, prend du temps et fait souvent réapparaître des problèmes que l'ancienne version avait déjà réglés.

• Garder et améliorer quand la base est saine : on corrige, on met à jour, on ajoute des tests là où ça compte.
• Stabiliser, puis refaire par morceaux quand certaines parties sont fragiles : on isole les zones à risque et on les remplace une à une, sans interrompre le service.
• Reconstruire quand la technologie n'est plus maintenue, que la sécurité ne peut pas être garantie ou que le coût des correctifs dépasse celui d'une nouvelle version.

Dans tous les cas, prévoyez une période de stabilisation avant d'ajouter de nouvelles fonctions : mise à jour des composants, correction des anomalies connues, mise en place de la surveillance.

5. Le jour du transfert

• Changez tous les mots de passe et renouvelez les clés d'API auxquelles l'ancien fournisseur avait accès.
• Retirez ses accès à tous les comptes, à une date fixée et notée.
• Faites un premier déploiement accompagné, pour vérifier que la nouvelle équipe maîtrise toute la chaîne.
• Si possible, convenez avec l'ancien fournisseur d'une courte période, rémunérée, pendant laquelle il répond aux questions.

Combien de temps, combien ça coûte

Pour une application de taille moyenne dont le code est disponible, l'audit et la remise en état prennent généralement quelques semaines. Le coût dépend surtout de la taille de l'application et de l'état de la documentation et des accès. Pour un premier ordre de grandeur, choisissez « Reprise d'une application existante » dans notre estimateur de budget.

Pour ne pas revivre la situation, une règle suffit : le code, l'hébergement et les comptes restent à votre nom dès le premier jour, quel que soit le fournisseur. C'est la règle que nous appliquons dans nos propres mandats, et notre service de maintenance logicielle prend en charge des applications que nous n'avons pas développées.