Trois propriétés distinctes déterminent qui possède réellement un outil numérique : le code qui l'exécute, les données qu'il contient, et la configuration ou le modèle qui encodent vos règles métier. Un contrat qui garantit un dépôt de code accessible, un export à tout moment et le droit de faire évoluer l'outil par un tiers répond aux trois. La plupart des contrats SaaS, et une partie des contrats de développement sur mesure mal rédigés, ne répondent à aucune des trois.
Trois propriétés, trois questions différentes
La première propriété, c'est le code. Existe-t-il un dépôt — un espace où le code source vit, versionné, daté — auquel vous avez un accès réel, ou seulement la promesse qu'on vous le remettra si vous le demandez ? La différence entre les deux n'apparaît que le jour où la relation se tend.
La deuxième, ce sont les données. Pouvez-vous les extraire intégralement, dans un format exploitable, à l'instant où vous le décidez, ou faut-il ouvrir un ticket et attendre le bon vouloir d'un support ? C'est la question que je détaille dans Comment migrer ses données hors d'un SaaS sans rien casser.
La troisième propriété est la plus souvent oubliée : la configuration, ou le modèle. Les workflows patiemment construits dans un outil no-code, les règles métier paramétrées dans un ERP, le réglage fin d'un modèle d'IA sur vos propres données — tout ce travail a une valeur réelle, mais il vit souvent entièrement à l'intérieur d'un outil que vous ne possédez pas. Le jour où vous partez, cette logique reste chez l'éditeur, parce qu'elle n'a jamais été à vous, seulement louée avec le reste.
Que veut dire « propriétaire », concrètement, dans un contrat ?
Le mot « propriétaire » se glisse facilement dans une plaquette commerciale et beaucoup plus difficilement dans une clause contractuelle précise. Trois éléments transforment l'intention en réalité vérifiable.
Un dépôt de code accessible en continu, et pas seulement livré une fois le projet clos : vous devez pouvoir y accéder à tout moment, pas seulement au moment où le prestataire décide de vous l'ouvrir. Un export de données en libre-service, disponible sans dépendre d'une intervention du fournisseur — la différence entre un bouton que vous actionnez et une demande que vous formulez en espérant une réponse. Et le droit, explicite, de faire évoluer l'outil par un tiers : sans clause d'exclusivité qui vous attache au prestataire d'origine pour toute modification future, et avec une documentation suffisante pour qu'un autre développeur reprenne le travail sans deviner.
Posséder un outil suppose donc ces trois propriétés distinctes — le code, les données, la configuration ou le modèle — répondant chacune à cette même exigence : un accès réel, pas une promesse.
Le sur-mesure bien fait livre le code par défaut
C'est un engagement que je tiens pour non négociable dans mon travail : quand je construis un outil sur mesure, le dépôt de code appartient au client dès le premier jour, sans qu'il ait besoin de le demander, et sans surcoût pour y accéder. Le site que vous lisez en ce moment, mcva.ch, a été refondu selon exactement ce principe — code accessible, documenté, transférable si un jour je cesse d'en être le seul à y toucher.
FiscalDoc, l'application locale que j'ai construite pour ma propre fiscalité, pousse le même principe à son terme : je possède l'outil, je possède le code, je possède les données, je possède même le modèle d'IA qui les analyse. J'ai documenté ce cas dans FiscalDoc : remplacer 1'400 CHF/an de SaaS par une IA locale. Ce n'est pas une question de confiance envers le prestataire, c'est une question de contrat, et un projet sur-mesure bien cadré la règle dès le départ, pas après coup.
Les pièges des CMS maison et des configurations captives
Le piège le plus trompeur n'est pas le SaaS classique, qu'on identifie assez facilement comme loué. C'est le CMS ou l'outil « maison », construit par une agence, présenté comme un actif propre à l'entreprise, alors que le code n'est documenté nulle part, qu'aucun dépôt n'est accessible en dehors de cette agence, et que la moindre évolution repasse obligatoirement par elle. Le mot « sur mesure » a servi d'habillage à un verrouillage aussi strict qu'un SaaS fermé, parfois davantage.
La configuration captive suit la même logique par un autre chemin. Des semaines passées à paramétrer des automatisations dans un outil no-code, à construire des scénarios complexes dans un CRM, à affiner des règles dans un ERP : ce travail a une vraie valeur, mais il n'existe qu'à l'intérieur de la licence qui le fait tourner. Le jour où vous voulez partir, cette logique ne s'exporte pas, elle reste enfermée dans un format que seul l'éditeur sait lire.
Quelques signes trahissent, assez fiablement, un outil qui ne vous appartient pas réellement :
- aucun dépôt de code accessible, seulement la parole du prestataire ;
- l'export exige un ticket de support plutôt qu'un geste en libre-service ;
- aucune documentation technique ne permet à un tiers de reprendre le travail ;
- personne d'autre que le fournisseur d'origine n'a jamais réellement pu intervenir ;
- votre logique métier n'existe que dans un format propriétaire, illisible ailleurs.
Comment vérifier ce que vous possédez, dès aujourd'hui
L'exercice ne demande pas d'expertise juridique poussée pour démarrer : posez, à chaque prestataire de votre pile logicielle, les trois questions de fond — où est le code, comment sortent les données, qui peut faire évoluer l'outil demain. Les réponses, ou leur absence, vous situent immédiatement sur l'échelle de la propriété réelle.
Cet inventaire rejoint celui que je recommande dans nLPD : où dorment réellement les données de votre PME ? : savoir où vivent vos données est la moitié du travail, savoir qui en détient les clés est l'autre moitié. Il rejoint aussi la question de l'hébergement — un hébergement suisse ne dit rien de la propriété du code qui tourne dessus, comme je le détaille dans Héberger en Suisse : ce que ça change vraiment — et celle de la sortie, le jour où la propriété s'avère insuffisante et qu'il faut migrer, traitée dans Comment migrer ses données hors d'un SaaS sans rien casser.
Le bon moment pour clarifier ces trois propriétés n'est jamais après un différend. C'est avant de signer, ou à défaut, au prochain renouvellement — c'est l'un des points que je vérifie systématiquement dans le cadrage d'une solution sur-mesure, et l'un des chantiers que je resitue dans Que doit faire une PME suisse face à l'IA en 2026 ?
Ce qu'il faut retenir
— Un outil numérique se possède à travers trois propriétés distinctes : le code, les données, et la configuration ou le modèle qui encode vos règles métier. — « Propriétaire » ne veut rien dire sans un dépôt de code accessible, un export en libre-service et le droit de faire évoluer l'outil par un tiers. — Le sur-mesure ne protège pas automatiquement de l'enfermement : un CMS maison mal documenté peut verrouiller autant qu'un SaaS fermé.
FAQ
Si j'ai payé pour un développement sur mesure, le code m'appartient-il automatiquement ? Pas nécessairement. Tout dépend des termes du contrat : une cession de droits explicite n'a rien à voir avec une simple licence d'usage, même quand la facture est identique. Vérifiez, dans les contrats déjà signés comme dans les prochains, la clause de propriété intellectuelle plutôt que de la supposer favorable.
Un CMS « propriétaire » construit par mon agence est-il forcément un problème ? Pas forcément, mais il mérite une vérification. Un dépôt de code accessible et documenté, même chez un prestataire unique, reste gérable. Le vrai problème apparaît quand rien n'est documenté et que personne d'autre ne pourrait reprendre la main si la relation s'arrêtait demain.
Je découvre que je ne possède rien de ce que je croyais posséder : que faire ? Commencez par l'inventaire plutôt que par la confrontation : quels outils, quelles données, quel code, chez qui. Portez ensuite la question de la propriété au prochain renouvellement de contrat, moment où le fournisseur a le plus à perdre en refusant. Pour les outils vraiment critiques, un rebuild sur mesure devient parfois la solution la plus sûre à long terme.
Un modèle d'IA que j'ai affiné chez un éditeur m'appartient-il ? En général, non, par défaut : le modèle de base reste la propriété de l'éditeur, et votre réglage fin reste le plus souvent sous licence plutôt que transféré. Les termes varient fortement d'un fournisseur à l'autre — c'est une clause à lire avant d'investir du temps à affiner un modèle, pas après.
Posséder son code coûte-t-il forcément plus cher que louer un SaaS ? Pas systématiquement, et l'écart s'est réduit ces dernières années : le développement assisté par IA a fait baisser le coût de construction d'un outil sur mesure, comme je l'ai documenté avec FiscalDoc. La question mérite d'être reposée à neuf, fonction par fonction, plutôt que tranchée par habitude.
Vous ne sauriez pas dire, aujourd'hui, qui détient vraiment le code de vos outils ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic
Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.