À quoi ressemble ce départ, vu du bureau du dirigeant ?
Le développeur salarié qui a écrit votre outil de gestion des commandes il y a huit ans vient de poser sa démission, ou il est déjà parti. Tant qu'il était là, tout passait par lui : l'ajout d'un tarif, la correction d'un export, le redémarrage du serveur un lundi matin. Trois semaines après son départ, l'envoi automatique des écritures vers le cabinet comptable s'arrête, et personne ne sait où ce traitement était programmé.
Les découvertes qui suivent se ressemblent d'une entreprise à l'autre :
- le dépôt de code est hébergé sur son compte personnel, ou n'existe que sur son ordinateur portable ;
- le nom de domaine et l'hébergement sont réglés avec sa carte bancaire, et les alertes d'expiration arrivent dans sa boîte mail ;
- les clés d'accès aux services du transporteur, de la banque ou de l'envoi de SMS ont été créées à son nom ;
- les règles métier, comme la remise négociée avec un gros client ou le calcul des frais de port par zone, ne sont écrites nulle part ailleurs que dans le code.
Le coût caché d'un logiciel que plus personne ne comprend
Le coût d'un départ non préparé ne figure sur aucune facture. Il se mesure en évolutions gelées, parce que personne n'ose toucher un programme qu'il ne comprend pas, et en contournements : un tableur à côté du logiciel, une ressaisie, une validation faite à la main. Chaque contournement ajoute de la dette technique et des erreurs.
Le risque est aussi sécuritaire. Un compte d'administration resté actif après un départ est une porte ouverte. Dans sa fiche « Sécurité : gérer les habilitations » (mars 2024), la CNIL demande de supprimer les permissions d'accès des utilisateurs dès qu'ils ne sont plus habilités, y compris à la fin de leur contrat, et de revoir les habilitations au minimum une fois par an. Enfin, les mises à jour de sécurité des composants du logiciel cessent d'être appliquées le jour où la seule personne qui savait les installer s'en va.
Le code écrit par votre ancien développeur vous appartient-il ?
Pour un développeur salarié, la réponse est en principe oui. Le guide pratique de l'INPI « La propriété intellectuelle et l'entrepreneur » indique que les droits patrimoniaux sur un logiciel réalisé par un employé dans l'exercice de ses fonctions, ou d'après les instructions de son employeur, sont dévolus à l'employeur. La fiche de Service-public.fr sur le contrat de cession de droits d'auteur (vérifiée le 3 mai 2024) précise que ces droits sont cédés automatiquement à l'employeur. Pour un indépendant, la situation est différente : il faut un contrat écrit qui énumère les droits cédés.
| Qui a écrit le code | Situation des droits | Ce qu'il faut vérifier |
|---|---|---|
| Un salarié, dans le cadre de ses fonctions | Droits patrimoniaux à l'employeur | Que le logiciel a été écrit pour l'entreprise, pendant le contrat de travail |
| Un indépendant ou une société prestataire | Restent à l'auteur sans cession écrite | Le contrat de cession : droits listés, étendue, destination, territoire, durée |
| Des bibliothèques open source intégrées | Restent sous leur licence d'origine | Les licences utilisées et leurs obligations |
Être propriétaire ne suffit pas : il faut aussi détenir physiquement le code et les accès. Si votre ancien salarié conserve des éléments, demandez-les par écrit et faites-vous conseiller par un avocat si la demande reste sans suite. Notre guide sur la propriété du code source détaille les clauses utiles.
S'il est encore en préavis : ce qu'il faut obtenir avant son dernier jour
Un préavis bien employé évite la plupart des difficultés. Réservez-en une partie à la transmission, avec une liste écrite, cochée et signée à la fin :
- Transfert du dépôt de code vers une organisation au nom de l'entreprise, avec tout l'historique des modifications.
- Inventaire des serveurs, bases de données, noms de domaine et services tiers, avec le titulaire de chaque compte.
- Bascule de ses comptes personnels vers des comptes d'entreprise, et des paiements vers un moyen de paiement de l'entreprise.
- Liste des tâches planifiées : exports de nuit, envois de mails, sauvegardes, purges.
- Procédure de mise en production écrite, puis rejouée par une autre personne devant lui.
- Séances enregistrées où il présente l'architecture, les règles métier et les parties fragiles du code.
- Restauration d'une sauvegarde sur un environnement de test, pour prouver qu'elle fonctionne.
S'il est déjà parti, la même liste sert de plan de reconstitution. Certains anciens salariés acceptent une courte mission de transfert de connaissances en indépendant : c'est parfois l'option la plus économique.
Reprendre la main : sécuriser, inventorier, auditer, documenter
La reprise suit un ordre précis, parce qu'une modification faite trop tôt sur un système mal connu peut casser ce qui tourne encore.
- Sécuriser : changer les mots de passe des comptes d'entreprise, révoquer puis recréer les clés d'accès créées par l'ancien développeur, couper les accès distants devenus inutiles.
- Inventorier : tout ce qui tourne (applications, tâches planifiées, connecteurs) et tout ce qui est payé (abonnements, licences, domaines), avec les échéances.
- Reconstruire à côté : réinstaller le logiciel sur un environnement de test à partir du code récupéré. Si la version reconstruite diffère de la production, le code récupéré n'est pas le bon.
- Auditer : sécurité, versions des composants, qualité du code, cohérence de la base. Les facteurs qui font varier cet effort sont présentés sur notre page consacrée au prix d'un audit de code.
- Documenter : schéma des données, règles métier retrouvées dans le code et confirmées par les utilisateurs, procédure de mise en production.
Les utilisateurs quotidiens sont la meilleure source sur les règles métier : la comptable sait pourquoi tel client a un taux de TVA particulier, le responsable logistique connaît l'exception sur les palettes.
Recruter, externaliser ou remplacer : quelles options ?
| Option | Quand elle convient | Point de vigilance |
|---|---|---|
| Recruter un nouveau développeur | Le logiciel évolue chaque semaine et porte un avantage propre à l'entreprise | Le recrutement prend du temps et la dépendance à une seule personne revient |
| Confier la maintenance à un prestataire | Le logiciel est stable, les évolutions sont ponctuelles | Exiger que code, accès et documentation restent au nom de l'entreprise |
| Combiner les deux | Un profil technique interne existe sans tout couvrir | Écrire qui décide et qui met en production |
| Remplacer par un logiciel du marché | L'outil maison fait ce que font des produits standard | Prévoir la reprise des données et l'adaptation des habitudes |
La comparaison détaillée entre maintenance externalisée et recrutement figure sur notre page TMA ou développeur interne.
Ce que YMHB Web fait concrètement
Tout commence par un échange où vous décrivez ce qui tourne, ce que vous avez récupéré et ce qui manque ; le fondateur de YMHB Web mène ce premier rendez-vous et reste votre interlocuteur jusqu'à la remise en service. Viennent ensuite la sécurisation, l'inventaire et l'audit, conclus par un rapport écrit qui classe les risques et les travaux à mener. La reprise du logiciel existant se poursuit par la documentation, les corrections urgentes puis les évolutions, en cycles courts avec une version de test accessible en permanence.
Si le logiciel a été laissé par un prestataire externe plutôt que par un salarié, les questions contractuelles changent : elles sont traitées sur la page reprendre un logiciel abandonné.
Comment éviter que la situation se reproduise
- Le dépôt de code vit dans une organisation appartenant à l'entreprise, avec au moins deux administrateurs.
- Chaque service a des comptes nominatifs, sans compte partagé non tracé, et les secrets sont rangés dans un coffre de mots de passe d'entreprise.
- Les abonnements techniques sont payés par l'entreprise et leurs alertes arrivent sur une adresse générique.
- Une documentation courte mais tenue à jour couvre l'installation, la mise en production, la restauration et les règles métier.
- Les habilitations sont revues à chaque départ et au moins une fois par an, comme le recommande la CNIL.
- Tout prestataire signe une clause de cession des droits et remet le code à chaque livraison.
Quand la reprise n'est pas la bonne réponse
Reprendre un logiciel maison n'a de sens que s'il rend un service qu'aucun produit standard ne rend aussi bien. Si l'outil ne gère plus qu'une liste de clients et des devis, un logiciel du marché fera le travail après une reprise des données. Si l'application n'a plus que deux utilisateurs occasionnels, archiver les données et l'arrêter peut être plus sage. Et si votre ancien développeur accepte de continuer en indépendant, un contrat de maintenance avec lui, assorti d'une vraie documentation, règle parfois la question plus simplement qu'une reprise.
Questions fréquentes
Mon ancien développeur salarié peut-il garder le code du logiciel ?
En principe non. Pour un logiciel écrit par un salarié dans l'exercice de ses fonctions, les droits patrimoniaux reviennent à l'employeur, comme le rappellent l'INPI et Service-public.fr. L'ancien salarié doit donc remettre le code et les accès qu'il détient encore. En cas de refus, une demande écrite puis l'avis d'un avocat sont les étapes à suivre, après avoir sécurisé tout ce qui est déjà au nom de l'entreprise.
Que faire en premier quand le développeur est déjà parti ?
Après le départ du développeur, commencez par sécuriser : changez les mots de passe des comptes d'entreprise, révoquez les clés d'accès qu'il a créées et supprimez ses permissions d'accès, comme la CNIL le demande à la fin d'un contrat. Viennent ensuite l'inventaire de ce qui tourne, la sauvegarde complète et l'audit. Aucune modification en production avant qu'une sauvegarde ait été restaurée avec succès sur un environnement de test.
Combien de temps faut-il pour qu'un nouveau prestataire maîtrise le logiciel ?
Le temps nécessaire pour qu'un nouveau prestataire maîtrise un logiciel maison dépend de la taille du code, du nombre de technologies, de l'état de la documentation et de la disponibilité des utilisateurs pour expliquer les règles métier. Il s'estime après une première lecture du code. Les corrections urgentes peuvent démarrer avant la fin de l'audit, sur un périmètre limité et avec une sauvegarde vérifiée.
Faut-il recruter un développeur ou passer par une agence après un départ ?
Recruter un développeur se justifie quand le logiciel évolue en permanence et porte un avantage propre à l'entreprise. Passer par une agence convient mieux quand le logiciel est stable et que les évolutions sont ponctuelles, avec l'avantage que plusieurs personnes connaissent le code. Dans les deux cas, le code, les accès et la documentation doivent rester au nom de l'entreprise. Un modèle mixte est aussi possible.
Comment ne plus dépendre d'un seul développeur ?
Pour ne plus dépendre d'un seul développeur, placez le dépôt de code dans une organisation au nom de l'entreprise avec au moins deux administrateurs, rangez les accès dans un coffre de mots de passe d'entreprise, exigez une procédure de mise en production écrite et testée par une autre personne, et revoyez les habilitations au moins une fois par an. Une documentation des règles métier complète le dispositif.
À lire aussi
Sources
- INPI, guide pratique « La propriété intellectuelle et l'entrepreneur » (données de janvier 2016) : droits sur un logiciel réalisé par un employé
- Service-public.fr (Entreprendre), Contrat de cession de droits d'auteur, fiche F22667 vérifiée le 3 mai 2024
- CNIL, Sécurité : gérer les habilitations (13 mars 2024)