Le verrouillage fournisseur, le Data Act et la différence avec une vraie propriété

Votre contrat arrive à échéance, vous voulez changer de fournisseur, et c'est seulement là qu'apparaît le vrai prix. Les données sont dans un format que seul le fournisseur lit aisément. L'export se facture au gigaoctet. Le préavis est plus long que vous ne le pensiez. À ce moment-là, vous ne payez plus pour du logiciel, vous payez pour le droit de partir.

Le verrouillage n'est pas un détail IT, c'est un risque de gouvernance

Qui signe pour un système central signe aussi pour la voie de sortie. Cette seconde partie figure rarement dans l'offre, et pourtant elle détermine votre position pour toute la durée du contrat. Pour les systèmes qui portent l'exploitation quotidienne, il ne s'agit pas de mois mais d'années. La dépendance vous coûte alors à des endroits qui n'apparaissent jamais sur la facture.

Commençons par le prix. Un fournisseur qui sait que changer représente des mois de travail et un budget conséquent a peu de raisons de rester compétitif au renouvellement. La hausse arrive proprement au moment du renouvellement, précisément quand revenir en arrière n'est plus une véritable option. Vous ne négociez alors plus sur la valeur du produit, mais sur ce que la sortie peut coûter. Position faible, et l'autre partie le sait.

Ensuite, il y a votre rythme. Vous suivez la feuille de route du fournisseur au lieu de celle de votre propre marché, et une intégration dont votre exploitation a besoin glisse discrètement vers un prochain trimestre ou disparaît de la liste. Le plus marquant se joue sur la continuité. Si le produit est arrêté, si le fournisseur est racheté ou si le modèle de licence est revu, ce risque se déplace directement vers votre comptoir, votre entrepôt et votre comptabilité. Une direction qui range le verrouillage parmi les choix techniques l'a confié au mauvais service.

Ce que le Data Act impose désormais

Vous n'êtes désormais plus seul face à cela. Le Data Act, Règlement (UE) 2023/2854, est entré en vigueur le 11 janvier 2024 et s'applique depuis le 12 septembre 2025. Il s'attaque directement au changement entre services cloud et rend une part du pouvoir au client. Concrètement, il impose ceci :

• Les fournisseurs doivent lever les obstacles commerciaux, techniques et contractuels au changement.
• L'équivalence fonctionnelle et l'interopérabilité doivent être prises en charge, afin que vos processus continuent de tourner même après le changement.
• Le préavis est limité à deux mois.
• Le changement lui-même doit pouvoir être bouclé en trente jours.
• Les frais de changement et de sortie sont progressivement supprimés.

Pour qui signe, cela signifie la fin du « vous êtes bloqué, c'est comme ça » comme réponse valable. Et pour les personnes qui devront plus tard réaliser la migration, c'est au moins aussi important : un format d'export lisible et un chemin de migration opérationnel sont désormais exigibles contractuellement, ce n'est plus quelque chose qu'il faut aller arracher après coup. C'est un déplacement réel, et il tourne à votre avantage.

Pouvoir changer n'est pas encore la même chose qu'être propriétaire

La différence tient à une question simple : où réside le code source ? Dans le modèle classique, vous louez l'accès à un logiciel que quelqu'un d'autre possède, et un règlement organise au mieux un départ propre. Avec une vraie propriété, partir n'est pas un projet en soi, car il n'y a rien à laisser derrière. Vous construisez dès le départ sur ce qui vous appartient déjà.

Chez nous, cela ressemble à ceci, et cela explique pourquoi « comment repartir d'ici » n'est presque jamais une question chez nos clients :

• Le code se trouve dès le jour 1 dans votre propre dépôt, pas dans le nôtre.
• La stack est un standard open source : Kubernetes, PostgreSQL, ClickHouse et Metabase, sans format fermé que quelqu'un devrait plus tard déchiffrer.
• Un accord de séquestre vous donne accès à la source dans tous les scénarios.
• La plateforme est transférable à n'importe quel intégrateur, y compris un autre que YK.
• Chaque vague se clôture par un go/no-go, de sorte que l'on peut s'arrêter sans perdre l'ensemble.

L'open source n'est pas ici une idéologie, mais une garantie pratique. Si votre plateforme tourne sur PostgreSQL, tout développeur connaissant PostgreSQL lit vos données, aujourd'hui et dans dix ans. Aucun format fermé à rétroconcevoir, aucun bouton d'export à attendre. L'interopérabilité que le Data Act formule comme un droit est ici simplement la manière dont c'est construit.

Ce qu'il vaut mieux demander maintenant

Avant de signer un prochain contrat, posez deux questions sur la table. Au fournisseur : où se trouvent notre code et nos données, dans quel format emportons-nous tout intégralement, et que coûte un départ au premier jour du contrat ? À vous-même : si cette partie disparaît demain, l'activité continue-t-elle de tourner ? La réponse à cette deuxième question est votre véritable profil de risque.

Le Data Act a ouvert la porte du marché, et c'est un gain pour tous ceux qui la trouvaient fermée auparavant. L'étape suivante n'est pas d'attendre de pouvoir invoquer ce droit, mais de choisir des systèmes où cette porte n'a jamais été verrouillée. La propriété n'est pas une clause de sortie à la fin du contrat. C'est le point de départ, tout en haut.