Reprendre le code d'un prestataire : la checklist avant de changer d'équipe
Reprendre le code d'un prestataire, c'est confier à une nouvelle équipe un logiciel qu'elle n'a pas écrit, pour le maintenir et le faire évoluer. Pour les entreprises qui changent de prestataire : ce qu'il faut récupérer, ce que l'entrant doit vérifier avant de promettre, et pourquoi une reprise n'est pas une réécriture.
Le prestataire qui a construit votre outil ne répond plus, ou répond trop tard, ou trop cher. Vous cherchez quelqu'un d'autre. Et vous découvrez que vous n'avez pas le code, que le serveur est à son nom, et que personne ne sait comment ça se déploie. C'est le scénario le plus fréquent qu'on rencontre, et il est presque toujours évitable.
Reprendre le code d'un prestataire, c'est confier à une nouvelle équipe un logiciel qu'elle n'a pas écrit, pour le maintenir et le faire évoluer. Ça se passe bien quand trois choses sont réunies : vous détenez ce qui vous appartient, l'entrant a regardé avant de promettre, et personne ne parle de tout réécrire le premier jour.
Une liste courte, à demander par écrit au prestataire sortant. Si vous êtes encore sous contrat avec lui, faites-le maintenant, pendant que la relation est cordiale. Ce sont vos biens.
03
Que doit regarder l'entrant avant de promettre ?
Chez Figue, on regarde le dépôt et les accès dès le premier échange, et on dit tout de suite si on reprend ou non. Voici ce qu'on regarde, et ce que chaque point nous apprend. Demandez la même chose à n'importe quel prestataire.
01
La stack et son âge
Quels langages, quels frameworks, quelles versions. Une stack courante et à jour se reprend en jours. Une stack exotique ou abandonnée se reprend, mais chaque intervention coûtera plus cher, et il faut le dire avant.
02
Les dépendances et les failles connues
Combien de bibliothèques, depuis combien de temps sans mise à jour, combien avec des alertes de sécurité. C'est le premier chantier de sécurisation, et son ampleur se mesure en une heure.
03
Les tests, ou leur absence
S'il y a des tests, on peut modifier sans casser. S'il n'y en a pas, chaque changement demande une vérification manuelle, et les premières demandes serviront à en écrire sur les parcours qui comptent.
04
Le déploiement
Automatique et reproductible, ou manuel et dans la tête de quelqu'un ? Tant qu'on ne sait pas déployer, on ne peut rien livrer. C'est souvent la vraie première demande.
05
La lisibilité
Un ingénieur ouvre trois fichiers au hasard et essaie de comprendre ce qu'ils font. S'il y arrive, la reprise sera fluide. Sinon, on le dit, et on chiffre le temps de compréhension comme du temps, pas comme un mystère.
“On ne promet jamais sur un dépôt qu'on n'a pas ouvert. Une heure de lecture évite trois mois de mauvaises surprises, des deux côtés.”
04
Reprise ou réécriture : la mauvaise question du premier jour
Presque tous les prestataires entrants proposent de tout refaire. C'est plus confortable pour eux (ils connaissent leur propre code) et plus rassurant en apparence pour vous (une page blanche). C'est aussi, dans la grande majorité des cas, la mauvaise décision au mauvais moment.
Une réécriture coûte le prix du logiciel, une seconde fois, pendant que l'ancien continue de tourner et de demander des corrections. Elle reproduit les bugs connus et en ajoute de nouveaux. Et elle repose sur une compréhension du métier que l'équipe entrante n'a pas encore. Le bon ordre est l'inverse : sécuriser, comprendre en faisant évoluer, et décider de refondre une partie, plus tard, avec des faits.
Comment se passe une reprise chez Figue ? Les étapes, délais indicatifs
Pour rendre ça concret, voici les premières étapes d'une reprise, pour un client qui arrive avec un produit existant. Ce sont des demandes ordinaires dans la file, que vous ordonnez comme les autres. Leur durée dépend de l'état du code et de la vitesse à laquelle les accès arrivent : les délais sont indicatifs.
01
Étape 1 : tout à votre nom
Dépôt, hébergement, domaine, comptes tiers, secrets. On rassemble, on transfère, on documente où est quoi. Vous repartez avec une page qui liste vos actifs et leurs accès.
02
Étape 2 : déployer et surveiller
Un déploiement reproductible, une preview pour valider, une alerte quand une erreur apparaît en production. À partir de là, on peut livrer sans retenir son souffle.
03
Étape 3 : sécuriser, puis la première évolution
Les mises à jour de sécurité prioritaires, des tests sur les parcours qui font du chiffre, et déjà la première demande qui compte pour vos utilisateurs. La reprise se termine quand elle devient invisible.
Ce qu'on nous demande quand un client arrive d'ailleurs.
Mon prestataire refuse de donner le code. Que faire ?
Relisez le contrat : si la cession des droits y figure, il est tenu de remettre le code, et une mise en demeure suffit souvent. Si elle n'y figure pas, négociez-la, éventuellement contre le solde d'une facture. Sans code, la seule voie est la réécriture, et il vaut mieux le savoir avant de choisir le suivant.
Vous reprenez n'importe quelle technologie ?
La plupart. On regarde le dépôt dès le premier échange et on vous répond tout de suite, y compris quand c'est non. Une stack rare se reprend, mais on vous dit que chaque intervention coûtera plus de temps.
Combien de temps prend une reprise ?
Les premières demandes servent à tout mettre à votre nom, à déployer proprement et à sécuriser. Ce sont des demandes ordinaires, traitées une à la fois ; leur durée dépend de l'état du code et de la vitesse à laquelle le sortant remet les accès. On ne promet pas de date, on montre l'avancement.
Faut-il prévenir l'ancien prestataire ?
Oui, et le plus tôt possible. Une reprise cordiale, avec une passation d'une heure, vaut des semaines d'enquête. Demandez-lui les accès et une démonstration du déploiement pendant que vous êtes encore client.
Et si le code est vraiment mauvais ?
On vous le dit, avec des exemples, et on chiffre ce que coûte de le faire vivre en l'état contre ce que coûterait de refaire une partie. La décision vous appartient, module par module. Un code mauvais qui tourne vaut souvent mieux qu'un bon code qui n'existe pas encore.
