Guide · Reprise de code
Comment reprendre le code d’un prestataire ?
L’agence a fermé, le freelance ne répond plus, ou vous voulez simplement changer de prestataire informatique. La reprise se passe bien si elle suit un ordre précis ; elle se passe mal quand on commence par coder.
Pour reprendre le code d’un prestataire, il faut d’abord récupérer tout ce qui vous appartient : le dépôt de code avec son historique, les accès à l’hébergement, à la base de données et aux sauvegardes, le nom de domaine, les comptes tiers et les secrets de configuration. Ensuite, un nouveau prestataire audite le code et l’exploitation avant de le modifier, sécurise la production, puis reprend les évolutions par ordre de priorité.
Avant de changer de prestataire : vérifier ce qui vous appartient
Commencez par relire le contrat : il dit à qui appartient le code, et à quelles conditions il doit vous être remis. Vérifiez ensuite, concrètement, où se trouve le code (sur un dépôt à votre nom ou à celui du prestataire), au nom de qui sont ouverts l’hébergement, le nom de domaine et les services tiers, et qui détient les mots de passe.
Si des comptes sont au nom du prestataire, demandez leur transfert avant la fin de la relation, par écrit. En cas de doute sur vos droits, un avis juridique vaut mieux qu’une supposition. Pour les projets que nous réalisons, le code est sur votre dépôt dès le premier commit et les comptes tiers sont à votre nom, précisément pour éviter cette situation.
La liste de ce qu’il faut récupérer
Cochez chaque élément. Ceux qui manquent deviennent la première tâche de la reprise, avant tout développement.
- Le dépôt de code complet, avec son historique, et pas seulement une archive des fichiers
- Les accès à l’hébergement (serveur ou cloud) et à la base de données
- Les sauvegardes, et la preuve qu’une restauration a déjà été testée
- Le nom de domaine et les certificats
- Les comptes des services tiers : paiement, envoi de courriels, magasins d’applications Apple et Google, cartographie
- Les secrets de configuration : clés d’API, mots de passe techniques, variables d’environnement
- La documentation existante : installation, déploiement, schéma de la base, même incomplète
- La liste des incidents connus et des demandes en cours
L’audit de code avant de reprendre
Le nouveau prestataire ne doit pas commencer par modifier le code. Il doit d’abord le comprendre : vérifier qu’il sait l’installer et le déployer, examiner les dépendances et les failles connues, la qualité des données, les sauvegardes et la possibilité réelle de restaurer le service. Il rencontre aussi les utilisateurs, parce que certaines règles métier ne sont écrites nulle part ailleurs que dans le code.
L’audit doit se conclure par un document clair : ce qui peut être conservé, ce qui doit être corrigé, ce qui mérite une réécriture, et un découpage chiffré par priorité. Ce document vous appartient, même si vous confiez la suite à quelqu’un d’autre. Notre page Reprise de code et de logiciel existant détaille le contenu de notre audit.
Les étapes d’une reprise de code
L’ordre compte plus que la vitesse. Chaque étape réduit un risque avant de passer à la suivante.
- Récupérer les accès, le code, les sauvegardes et les comptes
- Vérifier qu’on sait reconstruire et redéployer le logiciel
- Auditer le code, les données et l’exploitation
- Sécuriser la production : sauvegardes testées, correctifs urgents, supervision
- Prioriser les corrections et les évolutions par lots chiffrés
- Reprendre les évolutions, avec documentation et tests à chaque livraison
Faut-il tout réécrire ?
Rarement. La tentation est forte quand le code semble désordonné, mais une réécriture complète oblige à redécouvrir toutes les exceptions accumulées dans l’usage et à tout basculer d’un coup. Une refonte progressive, qui remplace une partie à la fois pendant que le service continue de fonctionner, est souvent plus sûre. L’audit dit, partie par partie, ce qui est raisonnable.
Méfiez-vous d’un prestataire qui conclut à une réécriture complète avant d’avoir ouvert le code. À l’inverse, conserver à tout prix une partie qui bloque chaque évolution coûte aussi cher, simplement plus lentement.
Les pièges d’un changement de prestataire informatique
Ces erreurs reviennent souvent. Elles sont évitables si on les connaît.
- Mettre fin au contrat avant d’avoir récupéré les accès et le code
- Accepter une archive de fichiers sans l’historique du dépôt
- Laisser le nom de domaine ou l’hébergement au nom de l’ancien prestataire
- Demander un devis de refonte sans audit préalable
- Refaire la même erreur : laisser à nouveau le code et les comptes au nom du nouveau prestataire
Questions fréquentes
Comment récupérer le code source auprès de mon ancien prestataire ?
Relisez d’abord le contrat, puis demandez par écrit la remise du dépôt de code complet avec son historique, ainsi que le transfert des accès et des comptes. En cas de désaccord sur vos droits, prenez un avis juridique.
Un autre prestataire peut-il reprendre le code d’une agence ?
Oui, à condition d’avoir le code et les accès nécessaires. Il doit commencer par un audit pour comprendre le logiciel avant de le modifier.
Que faire si le freelance ne répond plus ?
Faites l’inventaire de ce que vous contrôlez déjà : hébergement, nom de domaine, comptes à votre nom. Un audit permet ensuite de mesurer ce qui manque et de construire un plan à partir de ce qui est réellement disponible.
Combien coûte la reprise du code d’un prestataire ?
Cela dépend de l’état du code, des accès disponibles, des données et des incidents à traiter. L’audit se chiffre d’abord ; le reste se chiffre à partir de ses conclusions. Voir Reprise de code.
Faut-il tout réécrire quand on change de prestataire ?
Pas nécessairement. L’audit dit ce qu’il faut conserver, corriger ou remplacer ; une refonte progressive est souvent plus sûre qu’une réécriture complète.
Un projet, une question ?
Décrivez votre besoin en quelques lignes : vous échangez directement avec l’équipe, à Lille.