Garantir aux clients PaaS la portabilité applicative de leurs workloads — packaging OCI standard, manifestes portables vers des cibles diverses (Compose self-hosted en privilégié, autres PaaS, Kubernetes en option), services managés détachables, contrat de relocalisation testé#

De quoi s’agit-il concrètement#

Pour un fournisseur PaaS — entendu comme tout opérateur d’une plateforme d’exécution de workloads qui prend en charge le build, le déploiement, le scaling et un ensemble de services managés (base de données, cache, files de messages, observabilité, authentification) — la réversibilité ne se résume pas à un export de données. Le client a investi du code et de la configuration spécifiques à la plateforme : pipelines de build propriétaires (buildpacks fermés, conventions d’auto-détection non standard), API d’orchestration spécifiques (déclencheurs, webhooks, scaling), services managés non-portables (auth interne, queues propriétaires), formats de packaging propres. Au moment de partir, ce qui se présente comme une « migration de code » est en réalité un projet de réécriture partielle — souvent pluri-mois, parfois pluri-ans, et toujours d’un coût sans commune mesure avec celui d’un export de données SaaS.

L’engagement consiste à offrir aux clients PaaS, dès le contrat, une garantie de portabilité applicative structurée autour de quatre éléments :

• Formats de packaging standardisés. Les workloads clients sont packagés selon des standards ouverts (image OCI conforme, Dockerfile public et reproductible) — pas dans un format binaire propriétaire que seule la plateforme sait relire, ni sous une étiquette commerciale qui ne correspondrait à aucune spec ouverte.
• Manifestes de déploiement portables vers des cibles diverses. La configuration de déploiement (variables d’environnement, secrets, ressources allouées, dépendances inter-services) est exportable dans plusieurs formats standards adaptés au profil du client — un fichier Docker Compose pour la cible privilégiée self-hosted léger (exécutable sur un VPS ou une machine standard équipée de Docker ou Podman, sans cluster à orchestrer), et à la demande un Helm chart, des manifestes Kubernetes ou un Kustomize overlay pour les clients dont la complexité ou la volumétrie justifient un orchestrateur. La cible Compose est privilégiée parce qu’elle est la moins dépendante, elle-même, d’un fournisseur tiers : elle s’exécute sur n’importe quel hôte Linux.
• Services managés détachables. Pour chaque service managé fourni par la plateforme (PostgreSQL, Redis, Kafka, MinIO/S3, OpenSearch, etc.), le fournisseur publie une procédure documentée d’auto-hébergement (image officielle ou communautaire upstream, schéma compatible, scripts de migration de données et de réplication) ; les services managés propriétaires (par exemple, un système d’authentification propre à la plateforme, une queue maison, un orchestrateur d’événements spécifique) sont identifiés explicitement comme tels et accompagnés d’une stratégie de remplacement (alternative open source recommandée et scripts de mapping).
• Contrat de relocalisation testé. Le contrat client comporte un engagement chiffré sur le délai de relocalisation possible (typiquement 90 à 180 jours pour un workload type), assorti d’un test périodique documenté — au moins une fois par an, le fournisseur démontre publiquement (anonymisé) qu’un workload représentatif peut être relocalisé. La démonstration de référence est faite en self-hosted via Compose, parce que c’est la cible la plus accessible et la plus indépendante de tout autre fournisseur ; les autres cibles (autre PaaS conforme, Kubernetes managé, Kubernetes auto-hébergé) sont documentées en complément pour les clients qui en ont besoin.

Cet engagement s’inscrit dans le domaine 5 du Profil de souveraineté (continuité) et complète directement pub-009-standard-reversibility-clause (qui couvre les données pour le SaaS) en couvrant les workloads applicatifs pour le PaaS. Il participe de la condition n° 3 « Clause de réversibilité standard » des conditions d’équivalence pour le propriétaire (cf. page À propos), mais en décline la version PaaS-spécifique — la condition reste unique conceptuellement, sa déclarabilité opérationnelle se dédouble selon le modèle de service.

Pourquoi cet engagement compte#

La thèse 13 du manifeste fonde cet engagement : « la souveraineté technologique n’est pas une fin. Elle est la condition pour qu’une organisation — entreprise, administration, particulier — puisse continuer à exploiter ses données et à mener ses opérations, quels que soient les événements : défaillance d’un fournisseur, conflit géopolitique, sanctions, rachat hostile, bascule unilatérale d’un éditeur. C’est un droit, pas un confort. » Cette thèse s’applique au PaaS avec une force particulière : le verrouillage y est structurellement plus profond qu’au niveau SaaS, parce qu’il porte sur le code et sur l’architecture d’exécution, pas seulement sur les données. Un client SaaS qui veut changer de fournisseur exporte ses données et migre ses utilisateurs ; un client PaaS qui veut changer de fournisseur, sans dispositif explicite de portabilité, doit réinstrumenter ses pipelines de build, réécrire sa configuration de déploiement, remplacer chaque service managé propriétaire par un équivalent et reprouver l’ensemble — plusieurs entreprises européennes hébergées sur des PaaS américains ont découvert au moment d’une décision tarifaire défavorable que migrer ailleurs représentait six à douze mois de travail d’ingénierie, sans alternative équivalente managée immédiate.

Une note importante sur la cible de relocalisation. La plupart des fournisseurs PaaS supposent implicitement qu’un client qui les quitte ira vers Kubernetes — managé chez un autre fournisseur ou auto-hébergé. Cet engagement rejette cette hypothèse comme cible privilégiée, pour deux raisons. D’abord, Kubernetes est lui-même un projet à gouvernance américaine (CNCF, hébergé par la Linux Foundation, principaux sponsors et contributeurs américains), sans alternative européenne établie : en faire la seule cible de portabilité, c’est reproduire au niveau de l’orchestrateur la dépendance qu’on cherche à briser au niveau de la plateforme. Ensuite, Kubernetes auto-hébergé est une infrastructure lourde à monter, à sécuriser et à maintenir : pour la grande majorité des charges applicatives, c’est une usine à gaz dont le client n’a pas besoin et dont la maintenance retombe sur lui. La cible privilégiée par cet engagement est donc le self-hosted via Docker Compose : suffisant pour la majorité des workloads applicatifs, exécutable sur un VPS standard, sans cluster ni dépendance à un orchestrateur sous gouvernance étrangère. Kubernetes (managé ou auto-hébergé) et les autres PaaS restent des options, pas des prescriptions.

Les annexes du dispositif documentent par ailleurs le cas SecNumCloud / Cloud Temple PaaS OpenShift, S3NS Kubernetes managé et autres redistributions de stacks américaines sous étiquette française : même les fournisseurs « souverains » ne garantissent pas la portabilité applicative par construction, et la qualification juridictionnelle ne dit rien de la portabilité technique. Cet engagement comble cet angle mort. La nouvelle section « Les conditions d’équivalence pour le propriétaire » de la page À propos cite cet engagement comme la déclinaison PaaS de la condition 3, en complément de pub-009 : la condition reste unique, mais sa preuve opérationnelle se décline selon le modèle de service.

Exemple concret de mise en œuvre#

Un fournisseur français de PaaS de conteneurs pour applications web et API, environ 50 salariés, environ 200 clients ETI/TPE, prend cet engagement en mai 2026 avec un horizon de 18 mois. Les actions concrètes se déroulent ainsi :

• Audit interne des dépendances propriétaires de la plateforme au troisième trimestre 2026 : le système d’authentification interne est identifié comme propriétaire ; la queue maison est marquée pour remplacement à terme par NATS et/ou Redis Streams documentés ; l’orchestrateur, déjà basé sur Kubernetes upstream, est nativement portable côté image OCI.
• Publication sur le site d’une documentation « Quitter la plateforme » au quatrième trimestre 2026 : pour chaque service managé, son équivalent self-hosted (PostgreSQL upstream, Redis upstream, MinIO compatible S3, OpenSearch upstream, Authelia ou Keycloak en remplacement de l’auth propriétaire) avec image OCI officielle, schéma de base et script de migration ; un fichier docker-compose.yml de référence assemble l’ensemble pour une exécution sur un VPS standard.
• Intégration au contrat-type, début 2027, d’une clause de relocalisation à 120 jours pour les workloads standard, 180 jours pour les workloads à services propriétaires intensifs, avec engagement de remise gratuite ou à coût plafonné des livrables.
• En septembre 2027, premier test de relocalisation public anonymisé sur un workload représentatif (e-commerce, environ 50 GB de base, queue, cache, authentification déléguée). La cible démontrée est le self-hosted via Docker Compose sur un VPS européen standard : la relocalisation est faisable en 78 jours, dont 18 jours d’écriture du fichier Compose de mapping (PostgreSQL upstream, Redis upstream, MinIO pour le stockage objet, Authelia pour l’auth en remplacement du système propriétaire) et 60 jours de bascule progressive des données. Le retour d’expérience documente également des chemins alternatifs pour ceux qui les justifient : portage vers un autre PaaS conforme dans 95 jours, portage vers Kubernetes managé dans 110 jours, portage vers Kubernetes auto-hébergé dans 130 jours (la complexité supplémentaire venant de l’orchestration et non du workload lui-même).

À l’horizon 18 mois : la clause figure dans 100 % des nouveaux contrats, une démonstration de relocalisation Compose self-hosted a été publiée, deux clients déclenchent effectivement une étude de relocalisation (l’un pour migrer chez un confrère, l’autre pour internaliser sur Compose self-hosted) et les deux opérations confirment les délais annoncés. La direction commerciale observe que la mention de ce dispositif détaillé est désormais explicitement positive dans les soutenances d’appels d’offres face à des concurrents PaaS américains au discours flou sur la portabilité.

Anti-pattern à éviter#

Cinq pièges classiques vident l’engagement de sa portée :

• Réduire la portabilité au seul packaging — « vos conteneurs sont à vous, vous pouvez les exporter » — sans traiter les services managés ni la configuration de déploiement : le packaging Docker n’est qu’une partie minoritaire du verrou, et l’essentiel du coût de migration tient aux services managés propriétaires et à la reconstruction de la configuration.
• Déclarer un format propriétaire « standard » sous une étiquette commerciale qui ne correspond à aucune spec ouverte (par exemple un slug propre à la plateforme) : un format n’est standard que s’il est lisible et reconstructible par un tiers sans permission.
• Prescrire Kubernetes comme seule cible de relocalisation : c’est reporter la dépendance d’un cran (du PaaS vers l’orchestrateur sous gouvernance américaine) tout en alourdissant inutilement l’infrastructure que devra maintenir le client ; la cible privilégiée doit rester le self-hosted léger via Compose, le reste étant offert en complément.
• Une documentation d’auto-hébergement écrite mais jamais maintenue ni testée : elle devient inopérante au premier changement de version et son existence purement formelle trompe le client.
• Un test de relocalisation conduit sur un workload jouet plutôt que sur un workload représentatif : la démonstration perd toute valeur si le test ne porte pas sur une charge réaliste — taille de base, dépendances inter-services, services propriétaires effectivement utilisés.

Indicateurs de réussite#

À l’horizon 18 mois, vous pouvez raisonnablement considérer cet engagement tenu si la clause de portabilité figure dans 100 % de vos nouveaux contrats ; si la documentation « Quitter la plateforme » est publiée et tenue à jour, avec un fichier Compose de référence vérifiable ; si au moins un test de relocalisation public a été mené sur un workload représentatif avec Compose self-hosted comme cible démonstrative principale, et son retour d’expérience publié sous forme anonymisée ; si le délai contractuel de relocalisation est tenu lors des sollicitations effectives de clients sortants.

Catégorie dans le schéma JSON : publication. Horizon par défaut : 18 mois. Applicable à : entreprises.