Que devient votre logiciel si le développeur s’arrête ?
La réversibilité d’un logiciel, c’est la capacité à en confier la suite à quelqu’un d’autre sans tout reconstruire. Elle ne dépend pas de la taille du prestataire, mais de trois choses matérielles : qui détient le code, qui détient les accès, et qui détient les données.
C’est la première objection qu’on m’oppose, et elle est parfaitement fondée. Je travaille seul : si je m’arrête, quelqu’un doit pouvoir reprendre. Mais la question est mal posée quand on la limite aux indépendants — une agence de trente personnes qui dépose le bilan, ou qui décide d’abandonner votre technologie, vous laisse exactement au même endroit.
Ce qui protège n’est pas la taille du fournisseur. Ce sont trois possessions et une clause. Voici comment les vérifier, avec n’importe quel prestataire.
Qui doit détenir le code ?
Vous. Pas « sur demande », pas « en cas de rupture » : maintenant, et en continu. Le code doit se trouver dans un dépôt dont vous êtes propriétaire, où le développeur a un accès qu’on peut lui retirer — et non l’inverse.
Le test est simple et prend une minute : connectez-vous au dépôt sans passer par le développeur. Si vous ne savez pas où il est, ou si l’accès passe par son compte à lui, vous ne détenez pas votre logiciel, quoi que dise le contrat.
Que faut-il exiger par écrit ?
Quatre points, et ils tiennent en un paragraphe chacun. La cession des droits patrimoniaux sur le code écrit pour vous — sans elle, vous payez un développement que vous n’avez pas le droit de faire modifier par un autre. Le dépôt à votre nom. L’export des données dans un format lisible, à tout moment, sans frais. Et une documentation d’installation à jour, qui permette à un tiers de remonter l’application ailleurs.
Ce dernier point est celui qu’on oublie, et c’est souvent le plus bloquant : un code complet mais impossible à redémarrer sans son auteur ne vaut guère mieux qu’un code perdu.
Comment vérifier que c’est vrai, sans être technicien ?
Par un exercice, une fois par an, qui ne demande aucune compétence : demandez à quelqu’un d’extérieur — un autre développeur, une heure payée — de tenter de remonter votre application à partir de ce que vous détenez, sans contacter le prestataire habituel.
S’il y parvient, votre réversibilité est réelle. S’il bute, vous saurez précisément sur quoi, et vous pourrez le faire corriger pendant que la relation est bonne — pas le jour où elle ne l’est plus. Une heure par an, c’est le meilleur rapport sécurité/prix de tout le dossier.
| Ce que vous devez détenir | Le test | Si le test échoue |
|---|---|---|
| Le code source | Vous vous connectez au dépôt sans passer par le développeur | Demandez le transfert du dépôt à votre compte, par écrit |
| Les accès serveur et nom de domaine | Le domaine et l’hébergement sont facturés à votre nom | Faites-les migrer : c’est gratuit et ça prend une journée |
| Les données | Vous déclenchez un export vous-même, sans demander | Exigez une fonction d’export, pas une extraction sur devis |
| La documentation d’installation | Un tiers remonte l’application en la suivant | Faites-la écrire avant la prochaine échéance de paiement |
Ce qu’il faut retenir
Aucun de ces points ne dépend de la taille du prestataire, et tous se vérifient sans compétence technique. Un indépendant qui les respecte vous expose moins qu’une agence qui ne les respecte pas.
Posez ces quatre questions à qui que ce soit avant de signer — y compris à moi. Un prestataire que la question dérange vient de vous donner sa réponse.
À lire ensuite
- Calculer ce que vous coûte vraiment votre organisation actuelle — Une méthode en quatre relevés pour chiffrer la double saisie, les abonnements dormants et les heures que personne ne facture — et savoir si un logiciel se rembourse.