Dépendance à un développeur freelance : comment protéger votre logiciel métier

Vous confiez la création de votre logiciel à un développeur indépendant, puis un jour il n'est plus disponible : maladie, changement d'activité, désaccord. Si personne d'autre ne peut reprendre le projet, votre outil devient fragile du jour au lendemain.

La dépendance à un développeur freelance, c'est la situation où votre logiciel métier ne peut être compris, modifié ou hébergé que par une seule personne, parce que le code, la documentation ou les accès lui appartiennent de fait. Ce risque n'est pas propre aux indépendants : une petite agence peut créer exactement le même. Il se prévient surtout par des choix faits au départ.

Je suis moi-même développeur freelance à Toulon, et je préfère que vous posiez ces questions avant de signer. Cet article explique ce que votre entreprise doit détenir, la documentation à exiger, les clauses à prévoir et les limites de ces précautions.

Pourquoi le risque est réel pour une TPE ou une PME

Dans une petite structure, le logiciel métier porte souvent des tâches vitales : devis, planning, suivi des chantiers, facturation. Quand il s'arrête ou ne peut plus évoluer, l'activité en souffre directement. Et peu d'entreprises de cette taille disposent d'un service informatique capable de reprendre la main.

Prenons un exemple type : une entreprise de services dont le planning d'interventions repose sur une application sur mesure. Le code est hébergé sur le compte personnel du développeur, aucune procédure n'est écrite, et les mots de passe sont dans sa tête. Le jour où il cesse son activité, l'entreprise possède un outil qu'elle n'a plus les moyens de faire évoluer ni même de remettre en ligne.

Ce scénario n'a rien d'exceptionnel, et il ne suppose aucune mauvaise foi. Il naît le plus souvent de la facilité : au début, tout est rapide quand une seule personne gère tout, et personne ne pense à formaliser. C'est précisément à ce moment qu'il est le plus simple et le moins coûteux de poser de bonnes règles.

Ce que votre entreprise doit détenir : code, données et accès

Trois éléments comptent. Le code source, c'est-à-dire les fichiers que les développeurs lisent et modifient. Les données, c'est-à-dire tout ce que vos équipes saisissent. Les accès, c'est-à-dire les comptes d'hébergement, de nom de domaine et de sauvegarde.

Un point doit être précisé par écrit : qui détient les droits sur le code une fois le projet livré. Dans bien des cas, l'entreprise cliente obtient soit la cession du code spécifique, soit une licence d'usage durable, tandis que le prestataire conserve ses briques réutilisables. L'essentiel est que ce soit écrit. Si l'enjeu est important, faites relire le contrat par un juriste.

Des comptes ouverts à votre nom

L'hébergement, le nom de domaine, le dépôt de code et les sauvegardes doivent être ouverts au nom de votre entreprise, avec votre développeur invité comme utilisateur. Dans le cas contraire, vous dépendez de son bon vouloir pour récupérer votre propre outil.

Des données toujours exportables

Vous devez pouvoir obtenir à tout moment un export de vos données dans un format ouvert, par exemple des fichiers CSV ou une copie de la base de données. Testez cet export une fois par an, sans attendre un incident.

La documentation minimale à demander

Une bonne documentation n'a pas besoin d'être longue. Elle doit répondre à quelques questions simples, que n'importe quel développeur compétent se posera en reprenant le projet :

• un schéma simple de ce que fait le logiciel et de ses différentes parties ;
• la liste des services externes utilisés (hébergeur, messagerie, paiement) et de leurs comptes ;
• la procédure pour installer le projet sur une nouvelle machine ;
• la procédure de mise en ligne d'une nouvelle version ;
• la procédure de restauration d'une sauvegarde ;
• les règles métier importantes, expliquées en langage courant.

Avec ces éléments, un développeur peut souvent reprendre un projet en quelques jours plutôt qu'en quelques semaines, sans que personne puisse le garantir à l'avance.

Demandez que cette documentation soit livrée avec le logiciel, puis relue à chaque évolution notable. Un bon réflexe consiste à faire vérifier une fois qu'une personne extérieure sait suivre la procédure d'installation : si elle bloque, c'est que la documentation est incomplète. Ce petit test vaut mieux que de longues promesses.

Les clauses à prévoir pour pouvoir changer de prestataire

Le contrat est l'endroit où la dépendance se prévient le plus efficacement. Voici les points que je vous conseille d'y faire figurer :

• la cession ou la licence du code, avec son périmètre précis ;
• la remise du code et de la documentation à la fin du projet, puis après chaque évolution importante ;
• un engagement de réversibilité : aide à la reprise par un autre prestataire, avec une durée et un tarif annoncés ;
• un délai de préavis en cas d'arrêt de la maintenance ;
• la liste des composants tiers utilisés et de leurs licences.

Un bon prestataire ne craint pas d'être remplaçable : il rend son travail lisible pour que quelqu'un d'autre puisse le reprendre.

Limites et risques : ce que ces précautions ne règlent pas

Aucune clause ne remplace la connaissance du projet. Même avec un code propre et une documentation à jour, un nouveau développeur doit comprendre vos choix, et cela prend du temps et se paie. La réversibilité réduit le risque, elle ne l'annule pas.

D'autres limites existent. Une documentation qui n'est pas mise à jour devient vite trompeuse. Un code livré sans accompagnement peut rester inexploitable pour votre équipe. Enfin, exiger tous les livrables sur un petit projet peut alourdir le budget sans nécessité : pour un outil peu critique, un niveau de précaution plus léger suffit souvent.

Enfin, la dépendance ne disparaît pas en changeant de statut. Une agence peut aussi perdre la personne qui connaît votre projet. La vraie question n'est pas freelance ou agence, mais : le savoir est-il partagé et écrit ?

Les questions à poser avant de signer

Posez ces questions à tout prestataire, moi compris. Les réponses vous diront rapidement s'il travaille pour que vous restiez autonome.

• Où sera hébergé le logiciel, et à quel nom ?
• Qui détiendra le code à la livraison ?
• Que se passe-t-il si vous ne pouvez plus assurer la maintenance ?
• Pouvez-vous me montrer un exemple de documentation de projet ?
• Selon vous, combien de temps faut-il à un autre développeur pour reprendre le projet ?

En résumé

Pour limiter la dépendance à un développeur freelance, faites en sorte que les comptes, le code et les données appartiennent à votre entreprise, que la documentation permette une reprise rapide et que le contrat prévoie la réversibilité. Ces précautions ne suppriment pas le risque, mais elles le rendent gérable.

Pour aller plus loin : ce que doit couvrir un contrat de maintenance, la rédaction d'un cahier des charges de logiciel métier et les droits d'accès et les sauvegardes.

Vous envisagez un logiciel métier et voulez poser ces règles dès le départ ? Découvrez mon accompagnement en logiciel sur mesure ou contactez-moi pour en parler.