De quoi traite ce domaine#
Le deuxième domaine prolonge le premier en demandant, pour chaque composant tiers stratégique identifié au domaine 1, l’existence d’un plan de contournement en cas de défaillance, de bascule de licence, de hausse tarifaire unilatérale, ou de blocage juridictionnel. Le plan peut prendre plusieurs formes : alternative identifiée et nommée, estimation du temps et du coût de migration, niveau de testabilité (jamais testé, POC réalisée, environnement de test fonctionnel, migration partielle déjà conduite).
Le domaine ne demande pas que vous ayez tout testé — il demande que vous ayez réfléchi à la question pour chaque composant stratégique, et que vous le déclariez honnêtement, y compris en mentionnant les composants pour lesquels aucune alternative n’est identifiée à ce jour. Cette honnêteté est explicitement valorisée.
Pourquoi ce domaine compte#
La thèse 5 du manifeste fonde l’exigence du domaine 2 : « un projet open source dont les contributions, les artefacts ou la roadmap dépendent d’un sponsor unique est un projet libre révocable. » La révocabilité n’est pas hypothétique — elle s’est matérialisée à plusieurs reprises ces dernières années sur des composants massivement utilisés. MongoDB SSPL en octobre 2018, Elastic SSPL en janvier 2021, HashiCorp BSL en août 2023, Redis BSL/SSPL en mars 2024, MariaDB sous K1 Investment Management en septembre 2024, le rachat HashiCorp par IBM finalisé en 2025 : chaque événement a pris au dépourvu un nombre substantiel d’organisations qui n’avaient pas anticipé la situation et se sont retrouvées en position de faiblesse pour réagir.
Le coût d’une migration menée sous pression temporelle est typiquement plusieurs fois supérieur à celui d’une migration planifiée à froid. Avoir un plan de contournement, même non exécuté, transforme un risque flou en option opérationnelle. Pour un client qui évalue votre solution, l’existence du plan est une garantie concrète que vous lui offrez : si la situation change brutalement, vous savez quoi faire. Pour vous comme fournisseur, c’est aussi une protection contre l’escalade tarifaire ou contractuelle d’un éditeur qui se sait sans alternative testée.
À l’échelle collective, la publication des plans de contournement révèle où l’écosystème dispose effectivement d’alternatives crédibles — Valkey ou KeyDB pour Redis, OpenTofu pour Terraform, OpenBao pour Vault, OpenSearch ou PostgreSQL pour Elasticsearch — et où les zones de blanc subsistent. Cette information alimente l’observatoire des lacunes.
Ce qui est demandé par catégorie de déclarant#
Pour un éditeur de logiciel. Pour chaque composant stratégique du domaine 1, alternative identifiée (nommée si possible), estimation du temps de migration en jours-homme et de la durée calendaire, niveau de testabilité atteint à ce jour. Mention explicite des composants pour lesquels aucune alternative n’est identifiée, avec hypothèses sur la conduite à tenir en cas de défaillance.
Pour un hébergeur. Plan de bascule pour les composants centraux de la stack en cas d’indisponibilité. Le cas VMware-Broadcom est emblématique : avec des hausses tarifaires allant jusqu’à 1050 % constatées chez certains clients (AT&T cité publiquement) à partir de janvier 2024, la question de l’alternative à VMware vSphere — Proxmox VE, OpenStack, KVM nu, autre — devient une question légitime que tous les hébergeurs doivent se poser et déclarer publiquement.
Pour un distributeur ou intégrateur. Plan en cas de modification unilatérale des conditions par l’éditeur d’origine, de hausse massive de prix, ou de cessation de service au marché européen. Le distributeur dispose-t-il des compétences techniques pour assurer une continuité de service par lui-même ? Peut-il proposer une migration vers une alternative équivalente ? Les clients sont-ils prévenus en amont des risques structurels associés aux solutions distribuées ?
Exemple de réponse honnête bien faite#
Un éditeur français de logiciel de gestion documentaire, 35 personnes, déclare au domaine 2 sa stratégie composant par composant. Pour PostgreSQL : pas de plan de contournement nécessaire, gouvernance distribuée non révocable. Pour son cache Valkey : alternative KeyDB identifiée, migration estimée à 2 jours-homme, pas testée à ce jour. Pour son moteur de recherche Elasticsearch (qu’il utilise encore dans certaines configurations clients) : alternative OpenSearch identifiée et testée fonctionnellement en environnement de pré-production sur 3 jours en septembre 2025, migration estimée à 12 jours-homme par client, basculement réversible. Pour Keycloak (en cas de durcissement Red Hat / IBM) : pas de plan formalisé à ce jour, alternative Authentik à explorer dans les 12 mois, déclaré comme angle mort dans le domaine 7. Pour son hébergement chez Outscale (qualifié SecNumCloud) : alternative OVHcloud identifiée mais migration non testée, estimation à 30 jours-homme.
Anti-pattern à éviter#
Un domaine 2 qui se résume à « nous suivons les évolutions du marché et adapterons notre stratégie en cas de besoin » est un vœu pieux qui n’apporte aucune sécurité. Symétriquement, une déclaration trop ambitieuse (« nous sommes capables de migrer chaque composant en moins de 24 heures ») sans test concret est une fausse rassurance qui se retournera contre le déclarant le jour où la situation se présentera. L’honnêteté pèse plus que la performance : « alternative identifiée mais non testée, estimation à 15 jours-homme » est une réponse parfaitement acceptable.
Articulation avec les autres domaines et engagements#
Le domaine 2 dépend logiquement du domaine 1 (les composants doivent être identifiés avant qu’on puisse en décrire le contournement). Il s’articule directement avec l’engagement utilisateur user-004-study-migration-single-vendor : ce que vous étudiez sérieusement comme migration côté utilisateur correspond à ce que votre fournisseur idéalement déclare en domaine 2. Il s’articule également avec le domaine 5 (continuité en cas de défaillance) : les plans de contournement sont une partie de la réponse au scénario de défaillance, mais pas la totalité.
Comment remplir le formulaire#
Pour chaque composant stratégique listé au domaine 1, vous documentez un plan de substitution : quelle alternative, à quel coût, et a-t-elle été testée concrètement.
Composant concerné#
- Composant concerné (référence ou nom) : utilisez idéalement le nom exact tel qu’il apparaît au domaine 1, pour faciliter le rapprochement par le lecteur.
Alternatives identifiées#
Une bibliothèque vous propose les substituts les plus courants par catégorie. Vous pouvez en ajouter d’autres librement.
- Nom : nom précis du candidat-substitut (ex. : MariaDB comme alternative à MySQL).
- Éditeur ou fondation : qui contrôle ce substitut.
- Statut de qualification : où en êtes-vous ? Suggestions de valeurs : identifié, évalué techniquement, prototype validé, production. Soyez précis.
- Commentaire : limites connues, écarts fonctionnels, rééducations nécessaires côté équipe.
Estimation de migration#
- Effort (mois·personne) : combien de mois·personne au total pour réaliser la bascule. Une estimation grossière vaut mieux que rien.
- Délai (mois calendaires) : entre le déclenchement et le passage en production. Inclut formations, parallèle, cutover.
- Postes de coût principaux : où va l’effort (dev, formation, licences, re-tests, migration de données…).
Test concret#
C’est ce qui distingue un plan crédible d’une bonne intention.
- Statut du test : Pleinement testé (migration complète déjà jouée en bac à sable ou bascule réelle), Partiellement testé (sous-ensemble fonctionnel), Non testé (papier uniquement).
- Date du dernier test : un test vieux de trois ans n’a plus la même valeur qu’un test récent.
- Commentaire sur le test : ce qui a marché, ce qui n’a pas marché, périmètre couvert, écueils rencontrés.
Discours commercial et compétences internes#
- Discours commercial qualifié vis-à-vis des risques : votre relation client mentionne-t-elle honnêtement ces dépendances et ces risques ? Oui / Partiel / Non. Le commentaire détaille (page transparence sur le site, mention dans le contrat, etc.).
- Compétences internes pour la continuité : disposez-vous des profils nécessaires pour mener une migration sans dépendre uniquement du fournisseur sortant ? Soyez honnête : « non » est plus utile au lecteur qu’un « oui » de façade.