Posséder son logiciel : ce que le mot recouvre vraiment
« Vous êtes propriétaire de vos données » : la phrase rassure. Elle ne dit rien tant qu'on n'a pas vérifié ce qu'elle recouvre vraiment.
Le jour où le commerçant veut partir
Un gérant de boutique utilise depuis trois ans un logiciel de caisse et de gestion en ligne. Le contrat, l'éditeur, la présentation commerciale : tout insiste sur un point, « vos données vous appartiennent ». Le jour où il veut changer d'éditeur — parce que les tarifs augmentent, parce qu'un concurrent propose mieux, parce qu'il veut enfin un outil qui colle à son métier — il découvre la réalité derrière la formule. L'export proposé est un PDF ou un tableau figé, inexploitable par un autre logiciel. La base de données vit sur les serveurs de l'éditeur, pas sur un compte qu'il contrôle. Et la « réversibilité » promise au contrat n'a jamais été testée, encore moins chiffrée en délai.
Ce commerçant n'est pas propriétaire de son logiciel. Il en est locataire, avec une clé qui ne rentre que dans la serrure de l'éditeur.
Propriétaire, un mot qui ne coûte rien à dire
Toute plateforme SaaS peut écrire « vous restez propriétaire de vos données » dans ses conditions générales. La phrase ne coûte rien et n'engage à rien tant qu'elle n'est pas adossée à des conditions techniques précises. La propriété réelle ne se juge pas sur une promesse contractuelle mais sur ce qui se passe concrètement le jour où l'entreprise veut partir, migrer, ou simplement faire auditer son système par un tiers.
Ce qui rend la propriété réelle
Quelques critères permettent de distinguer une propriété réelle d'une propriété de façade :
- La base de données est hébergée sur un compte cloud dont l'entreprise détient les accès administrateur, pas uniquement sur l'infrastructure de l'éditeur.
- L'export se fait dans un format standard et documenté (SQL, CSV structuré, JSON), directement réutilisable par un autre logiciel sans intervention de l'éditeur d'origine.
- La licence n'est pas indexée sur le nombre d'utilisateurs ou de postes : ajouter une personne dans l'équipe ne déclenche pas une négociation tarifaire.
- Le code source, ou au minimum une documentation technique complète, est remis ou accessible en cas de rupture du contrat avec le prestataire.
- Le contrat prévoit une réversibilité chiffrée : un délai précis, un format de restitution défini, et une procédure déjà décrite plutôt qu'une simple mention de principe.
Ce qui vide le mot de son sens
À l'inverse, certains signaux indiquent que la propriété reste théorique :
- L'hébergement n'existe que chez l'éditeur : aucune migration n'est possible sans son accord et sa participation active.
- Le format d'export est propriétaire, non documenté, ou nécessite un logiciel tiers payant pour être lisible.
- La clause de réversibilité figure dans le contrat mais n'a jamais été précisée en pratique : pas de délai, pas de format, pas de responsable identifié côté éditeur.
- La tarification par utilisateur ou par module verrouille l'entreprise dans l'écosystème de facturation de l'éditeur, rendant tout changement coûteux avant même d'être techniquement possible.
- Aucune documentation technique n'existe en dehors de l'interface elle-même : impossible pour un tiers d'auditer ou de reprendre le système.
Ce qu'il faut vérifier avant de signer, ou avant de rester
La vérification n'a pas besoin d'être technique pour être utile. Quelques questions simples, posées avant signature ou lors d'un renouvellement de contrat, suffisent à révéler la situation réelle :
- Demander un export test complet et regarder concrètement le fichier obtenu, pas la description qui en est faite.
- Demander où est hébergée la base de données et si l'entreprise peut en obtenir un accès direct.
- Demander qui détient le code source ou la documentation technique, et ce qui se passe en cas de rupture.
- Demander un chiffrage du délai de portabilité : combien de temps pour tout récupérer et repartir ailleurs.
- Comparer le coût d'ajout d'un utilisateur avec le coût d'ajout d'une fonctionnalité : le premier ne devrait pas peser plus lourd que le second.
Le cas particulier du logiciel sur mesure
Un logiciel de gestion construit sur mesure change la nature du problème. La base de données appartient à l'entreprise dès le départ, hébergée sur son infrastructure ou sur un compte qu'elle contrôle. Le code est remis, pas loué. Il n'y a pas de licence par utilisateur à négocier chaque fois que l'équipe grandit. La question de la réversibilité ne se pose même pas de la même façon : il n'y a rien à « récupérer » puisque rien n'a jamais été enfermé ailleurs.
Cela ne dispense pas de vérifier, au moment de commander un tel logiciel, que ces conditions sont bien écrites et pas seulement sous-entendues. Un développement sur mesure mal cadré peut reproduire les mêmes verrous qu'un SaaS fermé, si le prestataire garde la main sur l'hébergement ou refuse de documenter son travail.
Une propriété qui se vérifie, pas qui se déclare
La propriété d'un logiciel ne se juge pas à ce qu'écrit l'éditeur dans sa communication, mais à ce que l'entreprise peut réellement faire le jour où elle veut partir. Vérifier ces points avant de signer coûte une heure. Les découvrir après, au moment où l'on cherche à partir, coûte beaucoup plus.
Vérifier la réversibilité réelle de votre logiciel actuel
ArkonLabs conçoit des logiciels de gestion sur mesure où la base de données, le code et l'hébergement restent entre les mains de l'entreprise, sans licence par utilisateur ni format fermé. Pour faire le point sur ce que votre logiciel actuel permet réellement de récupérer, la discussion se prend sur www.arkon-labs.com.