Garantir contractuellement un préavis minimum (six à douze mois) avant tout arrêt de support, bascule unilatérale ou modification substantielle du service#
De quoi s’agit-il concrètement#
Cet engagement traite d’une asymétrie courante dans les contrats SaaS : l’éditeur peut, en pratique, modifier les conditions d’usage, abandonner une version, basculer un client vers une nouvelle architecture, changer la licence, ou augmenter brutalement les tarifs, en s’appuyant sur des formulations de type « l’éditeur se réserve le droit de faire évoluer le service ». Le client, lui, n’a aucun moyen d’anticiper ni de négocier, sauf à découvrir le changement à l’occasion d’un mail trente jours avant la bascule effective. Cette asymétrie est précisément ce qui transforme un fournisseur en point de défaillance unique.
L’engagement consiste à inscrire dans le contrat-type un préavis minimum garanti, dont la durée est calibrée sur la criticité du service : six mois pour les services standard, douze mois pour les services critiques ou massivement déployés en production. Sont concernés les événements suivants :
- Arrêt de support d’une version stable encore largement utilisée.
- Bascule unilatérale d’architecture, de socle technique ou de localisation des données.
- Modification substantielle du service — changement de licence (cf. cas Redis, HashiCorp, MongoDB), bascule tarifaire massive, retrait d’une fonctionnalité documentée comme incluse, modification du périmètre de stockage des données.
Le préavis est notifié par écrit, accompagné des modalités de migration, des engagements de réversibilité (cf. pub-009) et de la liste des changements opérés. Cet engagement éclaire directement le domaine 5 (continuité) et le domaine 6 (relation contractuelle) du Profil de souveraineté.
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. » Le préavis minimum est l’instrument qui transforme la « bascule unilatérale » de cette thèse en un événement encadré, anticipable, négociable.
Cet engagement participe de la nouvelle section « Les conditions d’équivalence pour le propriétaire » de la page À propos. La condition « préavis contractuel minimum » est la quatrième de ces conditions, et elle complète mécaniquement pub-005-establish-software-escrow (séquestre) et pub-009-standard-reversibility-clause (réversibilité) : le préavis donne au client le temps d’activer ces deux dispositifs avant qu’il ne soit trop tard. Sans préavis, le client est piégé : un mail trente jours avant le changement, et il subit. Les cas Redis (août 2024, bascule SSPL/RSALv2), HashiCorp Terraform (août 2023, bascule BSL), MongoDB (octobre 2018, bascule SSPL) ont tous opéré sur des préavis trop courts pour permettre une migration ordonnée des bases installées : c’est ce vécu collectif que cet engagement vient corriger.
Exemple concret de mise en œuvre#
Un éditeur français de PaaS d’orchestration de conteneurs, environ 35 salariés, prend cet engagement en mai 2026 avec un horizon de 6 mois. Le contrat-type évolue dès l’automne 2026. Pour les contrats standard, le préavis garanti est de six mois calendaires ; pour les contrats critiques (clients dont le service tourne en production sur l’infrastructure de l’éditeur avec un engagement de niveau de service supérieur), il passe à douze mois. La clause précise les événements couverts : arrêt de support d’une version mineure, retrait d’une fonctionnalité de l’API publique, changement de localisation du datacenter, modification de la licence applicable, augmentation tarifaire supérieure à 15 % par an.
L’éditeur publie également une politique de versioning explicite : chaque version mineure bénéficie d’un support garanti de 18 mois minimum, ce qui rend le préavis de 6 mois compatible avec un cycle de migration soutenable. Cette politique est documentée sur le site, dans une page dédiée référencée depuis le Profil de souveraineté. À l’horizon, deux clients ayant rencontré des bascules abruptes chez d’autres fournisseurs citent la mention explicite de ce préavis comme un facteur déterminant de leur choix.
Anti-pattern à éviter#
Un préavis annoncé verbalement ou par e-mail, sans inscription contractuelle, n’a aucune portée. Un préavis « raisonnable » non chiffré laisse l’éditeur décider seul de ce qui est raisonnable. Un préavis qui ne couvre que les arrêts complets de service, en laissant hors champ les modifications substantielles (licence, tarification, périmètre fonctionnel), passe à côté de l’essentiel des cas réels. Un préavis non assorti d’engagements complémentaires (réversibilité, migration documentée) reste un avertissement sans solution. Enfin, l’usage de formulations ambigües (« nous nous efforcerons de prévenir nos clients dans les meilleurs délais ») revient à ne rien garantir.
Indicateurs de réussite#
À l’horizon des 6 mois, vous pouvez raisonnablement considérer cet engagement tenu si le contrat-type intègre la clause de préavis avec des durées chiffrées, si la liste des événements déclenchant le préavis est explicite et exhaustive, si la politique de versioning ou de support est publique, et si la clause est effectivement appliquée lors du premier événement déclencheur — date d’annonce documentée, modalités de migration jointes.
Catégorie dans le schéma JSON : publication. Horizon par défaut : 6 mois. Applicable à : entreprises.