La souveraineté technologique commence par une question pratique : si je veux partir, le puis-je effectivement ? Pas dans l’abstrait — dans les faits, dans les délais, avec quels outils, avec quel coût. La réversibilité et la portabilité sont les deux faces de cette question, selon le modèle de service.
Pour les solutions SaaS — où l’éditeur opère le service et où le client lui confie ses données — la question est celle de l’export : les données peuvent-elles être récupérées dans un format ouvert, dans un délai contractuel chiffré, avec des scripts éprouvés ? Sans clause précise, l’« exportabilité » figurant au contrat est au mieux une promesse, au pire un piège (cf. fiche pub-009).
Pour les solutions PaaS — où le client a déployé son code et sa configuration sur la plateforme — la question est celle de la portabilité applicative : le workload peut-il être déplacé vers une autre cible (un VPS Compose, un autre PaaS, un orchestrateur alternatif) sans projet de réécriture qui dure des mois ? L’enjeu est plus profond que pour le SaaS, parce qu’il porte sur le code et l’architecture, pas seulement sur les données (cf. fiche pub-014).
Pour les solutions propriétaires en général, la réversibilité passe aussi par des dispositifs de continuité du logiciel lui-même : un séquestre logiciel chez un tiers de confiance européen, ou un engagement public de release du code source sous licence libre dans des circonstances déclenchantes nommées — faillite, liquidation, rachat hors UE (cf. fiche pub-005). Le séquestre garantit que le code reste utilisable même si l’éditeur disparaît ; la clause de réversibilité garantit la portabilité de ce qui y vit.
Ces trois mécanismes forment le bloc de réversibilité des conditions d’équivalence pour le propriétaire (cf. la page philosophie du dispositif). Ils ne sont pas exclusifs : un fournisseur qui opère à la fois SaaS et PaaS, et dont la composante logicielle reste propriétaire, gagne à les combiner.
Une mention importante sur la cible technique du PaaS. Beaucoup de fournisseurs supposent implicitement que la cible de relocalisation est Kubernetes. Cette hypothèse appelle deux réserves : Kubernetes est lui-même un projet à gouvernance américaine (CNCF, Linux Foundation, sponsors et mainteneurs principaux US), sans alternative européenne établie ; et Kubernetes auto-hébergé est une infrastructure lourde dont la maintenance retombe sur le client. La cible privilégiée par les engagements de cette page est le self-hosted via Docker Compose — accessible, exécutable sur un VPS standard, sans cluster ni dépendance à un orchestrateur tiers. Kubernetes (managé ou auto-hébergé) et les autres PaaS restent des options, pas des prescriptions.
Enfin, sans préavis contractuel minimum avant tout arrêt de support ou bascule unilatérale, même la meilleure clause de réversibilité reste théorique : il faut du temps pour activer un séquestre, exporter des données, relocaliser un workload. Le préavis est l’enveloppe temporelle qui rend la réversibilité opérante (cf. fiche pub-010).
Côté acheteur, la réversibilité ne se contente pas d’être déclarée — elle s’éprouve : étudier sérieusement, en amont du contrat, le scénario de migration et son coût (cf. fiche user-004) est ce qui transforme une clause sur le papier en levier réel.
Cette page rassemble les engagements concrets côté fournisseur et côté acheteur. Pour l’analyse des cas où la réversibilité a manqué, voir l’annexe documentaire Famille 1 — Bascules de licence.