Reprendre son code après un prestataire

Récupérer une archive du code ne signifie pas avoir repris votre SaaS. La reprise est terminée quand une autre personne peut installer, déployer, diagnostiquer et restaurer le produit sans appeler l'ancien prestataire.

Je me souviens d'une plateforme de santé développée par une agence. Le code avait bien été livré. Pourtant, le développeur recruté en interne passait des jours, parfois des semaines, sur des modifications simples. L'agence avait construit des microservices avec une architecture hexagonale. Le choix se défendait sur le papier, mais il ne correspondait ni à la taille de l'équipe ni à son expérience.

Nous n'avons pas tout jeté. Nous avons conservé les parties utiles, regroupé les services dans un monolithe et simplifié l'organisation du code. Le développeur interne a participé à ce travail en binôme. Quelques mois plus tard, il pouvait maintenir la nouvelle structure et livrer les fonctionnalités prévues.

C'est là que j'ai compris quelque chose : avoir accès au repo et maîtriser un produit sont deux choses différentes.

Le dépôt de code ne suffit pas

Quand une mission se termine mal, tout le monde réclame le code source. C'est normal. Mais le code n'est qu'une pièce du produit.

Un SaaS vit aussi dans son historique Git, sa base de données, ses noms de domaine, son hébergement et les services externes qu'il utilise. Les secrets techniques, les sauvegardes et la procédure de déploiement comptent tout autant. Il suffit qu'un de ces éléments manque pour se retrouver avec du code inexploitable.

Le contrat doit également être relu avant de lancer la reprise. En France, la transmission des droits d'auteur doit préciser les droits cédés et délimiter leur exploitation, comme le prévoit l'article L131-3 du Code de la propriété intellectuelle. Une facture payée et le code source en zip récupéré ne répondent donc pas, à eux seuls, à toutes les questions d'utilisation, de modification ou de transmission du logiciel.

Si la clause est absente ou ambiguë, faites-la valider par un juriste. L'audit technique répond à une autre question : qu'avez-vous réellement récupéré, et que pourra en faire une nouvelle équipe ?

Demandez aussi le repo complet, avec ses branches et son historique, plutôt qu'un fichier ZIP. Les anciens changements expliquent parfois une règle métier introuvable dans la documentation. Ils permettent aussi de vérifier que le code reçu correspond à la version en production.

Je pose toujours la même question : une personne qui n'a jamais travaillé sur le projet peut-elle lancer l'application et déployer une correction sur un environnement de test ? Si elle doit encore appeler l'agence, la passation n'est pas terminée.

La dépendance finit par bloquer le business

Le piège, c'est que cette dépendance reste discrète tant que le prestataire répond. Elle apparaît le jour où un client signale un incident, une facture affiche un mauvais montant ou une faille demande une correction rapide.

Et là, les heures de développement deviennent une petite partie de la facture. Il faut retrouver un compte, comprendre un script inconnu, parfois deviner comment la production a été installée. Pendant ce temps, les décisions commerciales attendent.

Le risque concerne aussi les données. Si personne ne sait exporter la base, vérifier une sauvegarde ou restaurer le service, la continuité de l'entreprise dépend d'une connaissance qui ne lui appartient pas. Lorsque le prestataire traite des données personnelles pour votre compte, la fin de mission doit encadrer leur restitution ou leur suppression. La CNIL recommande de prévoir ces opérations dans le contrat.

Faute d'informations, on finit souvent par rester avec l'ancien prestataire parce que personne d'autre ne peut intervenir. À l'autre extrême, on accepte une réécriture complète proposée après quelques minutes de discussion.

Le problème est le même dans les deux cas. Vous ne savez pas ce qui fonctionne, ce qui est fragile ni ce qui peut être transmis. Aucun devis de reprise n'est vraiment comparable dans ces conditions.

C'est ce qui me gêne le plus dans ce genre de situation : le fondateur perd sa capacité à décider. Une évolution produit ou un engagement client dépend désormais de contraintes que personne dans l'entreprise ne sait expliquer. Le SaaS fonctionne encore, mais il n'est plus vraiment piloté.

Récupérer les actifs dans le bon ordre

Je commence par les droits et les accès d'administration. Qui possède le repo, le cloud, le domaine, le DNS, la base de données et les comptes de paiement ? Les comptes principaux doivent être rattachés à l'entreprise, avec un moyen de récupération qu'elle contrôle. L'ancien prestataire peut garder un accès temporaire pendant la passation. Il ne doit simplement plus être le seul administrateur.

Ensuite, je regarde le système qui tourne réellement. Le code du repo correspond-il à la production ? Où sont les variables d'environnement, les tâches planifiées et les webhooks ? Une application peut sembler autonome alors qu'un script lancé depuis un serveur personnel traite encore les commandes chaque nuit.

Pour les secrets, couper toutes les clés le même jour donne une impression de contrôle. Cela peut aussi arrêter les paiements ou l'envoi d'emails. Il faut d'abord comprendre où chaque clé est utilisée, créer les nouveaux accès au nom de l'entreprise, puis remplacer les anciens un par un. Et vérifier après chaque changement.

Je demande aussi à la nouvelle équipe de restaurer une sauvegarde dans un environnement isolé. Un export posé dans un dossier ne prouve rien si personne ne sait le relire. Ce test révèle vite les sauvegardes incomplètes, les fichiers stockés ailleurs ou une dépendance oubliée.

Je ne lancerais pas non plus un grand chantier documentaire de six mois. Il faut décrire comment installer le projet, déployer une version, lire les erreurs et restaurer les données. Puis une personne extérieure suit les instructions. Dix pages qui fonctionnent valent mieux qu'un dossier exhaustif jamais testé.

Cette vérification complète la checklist d'audit technique d'une startup. Je m'intéresse moins à la beauté du code qu'à la continuité du produit. À la fin, je veux connaître les blocages, leur responsable et les opérations que l'équipe sait réellement répéter.

Pour moi, la passation est terminée quand l'ancien prestataire peut encore aider, sans être indispensable.

Garder, sécuriser ou refaire

Un audit utile débouche sur une décision. Un rapport de cinquante pages que personne ne transforme en plan d'action ne sert pas à grand-chose.

Le produit doit pouvoir être lancé, testé et déployé sans rituel connu d'une seule personne. Je regarde aussi les flux qui touchent le revenu ou la confiance des clients : authentification, permissions, paiement et données. L'équipe qui reprend compte tout autant. Une architecture peut être correcte et rester inadaptée aux personnes chargées de la maintenir. C'est exactement ce qui s'était passé sur la plateforme de santé évoquée plus haut.

Le tri se fait rarement en bloc. Une partie du code fonctionne, tout le monde la comprend et il n'y a aucune raison d'y toucher. Ailleurs, il faut sécuriser la facturation, automatiser le déploiement ou retirer un secret d'un compte personnel. Les zones qui ralentissent chaque modification peuvent demander un refactor ciblé.

La réécriture complète reste une option, mais je me méfie d'un verdict prononcé avant l'audit. Elle se justifie si les fondations empêchent les usages attendus ou si les risques sont dispersés dans tout le système. Avant de prendre cette décision, lisez aussi comment arbitrer entre refactor et rewrite.

En pratique, une reprise mélange souvent ces choix. On garde les règles métier éprouvées, on sécurise l'exploitation, puis on remplace les zones qui bloquent vraiment. Le produit continue d'avancer pendant que la nouvelle équipe apprend son histoire.

Sans direction technique interne, un CTO part-time peut apporter ce regard indépendant. Il commence par l'urgence et les accès, puis transforme l'audit en plan de reprise. Le fondateur sait enfin ce qu'il doit sécuriser et dans quel ordre.

Ce qu'il faut retenir

Un ZIP ou un accès au repo ne suffit pas pour reprendre un SaaS. L'entreprise doit contrôler les droits, les comptes, les données et les procédures qui font tourner le produit. Une autre personne doit ensuite prouver qu'elle peut installer, déployer, diagnostiquer et restaurer le service sans dépendre de son ancien auteur.

Une fois les actifs récupérés et la passation testée, l'audit aide à choisir ce qui sera gardé, sécurisé, simplifié ou remplacé. Avant ce travail, une promesse de reprise ou de réécriture reste une estimation faite dans le brouillard.

Questions fréquentes

Que faire si le prestataire refuse de livrer le code source ?

Relisez le contrat, le devis et les clauses de cession ou de réversibilité avant toute action. Faites préciser par écrit les éléments manquants et leur date de restitution. Si les droits ou les obligations restent contestés, consultez un juriste spécialisé en propriété intellectuelle avant de confier le code à une nouvelle équipe.

Une archive ZIP suffit-elle pour changer de prestataire ?

Non. Elle ne contient pas forcément l'historique du projet, la configuration de production, les données, les sauvegardes ni les accès aux services externes. Demandez le dépôt complet et faites tester l'installation puis un déploiement par la personne qui reprendra le produit.

Faut-il réécrire un SaaS difficile à reprendre ?

Pas automatiquement. Commencez par isoler les blocages qui empêchent l'exploitation ou les évolutions prioritaires. Un refactor ciblé et une simplification de l'architecture coûtent souvent moins cher qu'une reconstruction, mais seul un audit permet de comparer les deux trajectoires.

Conclusion

Si votre prestataire ne répond plus ou si la passation vous semble incomplète, réservez un échange de 30 minutes pour qualifier l'urgence, les accès manquants et le périmètre d'un audit de reprise.