Conduire un audit interne de notre exposition aux dépendances technologiques single-vendor#
De quoi s’agit-il concrètement#
Cet engagement consiste à examiner systématiquement les technologies que vous utilisez pour identifier celles dont la trajectoire dépend d’un seul éditeur — ce que le manifeste appelle des projets « single-vendor ». Ces projets sont sous le contrôle exclusif d’une entreprise qui peut, à tout moment, modifier la licence, restreindre les conditions d’usage, ou démanteler l’édition libre, comme l’ont fait Redis Inc. en mars 2024, HashiCorp en août 2023, Elastic en 2021, MongoDB en 2018, ou MinIO entre 2025 et 2026.
L’audit n’a pas vocation à produire un rapport exhaustif sur l’ensemble de votre stack — il cible spécifiquement les composants stratégiques pour vos opérations. La méthode habituelle est la suivante : lister les briques dont la défaillance bloquerait votre activité, identifier pour chacune l’éditeur ou la fondation qui contrôle sa gouvernance, et qualifier la nature de cette gouvernance (fondation neutre multi-vendor, projet single-vendor avec édition entreprise commerciale, propriétaire fermé, etc.).
Le résultat est une cartographie qui rend visibles les zones de risque concentré. Cette cartographie sert ensuite de base à des décisions opérationnelles — par exemple, prioriser la migration vers une alternative pour un composant dont le risque de bascule devient préoccupant.
Pourquoi cet engagement compte#
Beaucoup d’organisations découvrent leur exposition au moment où elle se matérialise par une bascule. C’est trop tard. Le coût de migration est alors maximal — pression temporelle, ressources non planifiées, équipes non formées, alternatives non qualifiées. À l’inverse, une organisation qui a fait l’audit à froid peut planifier sa réaction sereinement : elle a identifié les alternatives, elle a chiffré l’effort, elle a peut-être même testé une POC.
Au niveau collectif, l’agrégation de ces audits — quand ils sont publiés — alimente l’observatoire des lacunes (/dossier) du manifeste. Si plusieurs centaines d’organisations européennes constatent qu’elles dépendent toutes massivement du même registre américain ou de la même brique single-vendor, cette concentration devient un signal pour l’investissement public et les programmes IPCEI-CIS.
Exemple concret de mise en œuvre#
Une administration territoriale française avec environ 200 agents et une stack informatique typique conduit l’audit ainsi. L’équipe SI inventorie les composants stratégiques en partant des trois grandes catégories : infrastructure (hyperviseur, orchestrateur de conteneurs, stockage), applications métier critiques (ERP, gestion documentaire, gestion des ressources humaines), services numériques aux usagers (portail, formulaires en ligne, services tiers intégrés). Pour chaque composant, l’équipe documente l’éditeur, la juridiction, et le modèle de gouvernance.
L’audit identifie quatre zones de concentration sur du single-vendor américain : la suite collaborative (Microsoft 365), l’antivirus (CrowdStrike), une partie de la gestion documentaire (solution propriétaire avec édition cloud aux États-Unis), et le système de gestion des congés (SaaS américain). Pour chacune, l’équipe identifie une alternative crédible — Nextcloud + Collabora pour la collaboration, un EDR open source pour l’antivirus, une solution Cegid pour la gestion documentaire, une solution française pour les congés. Aucune migration n’est engagée immédiatement, mais la cartographie sert à informer les futurs cycles d’achat et à préparer un plan pluriannuel de réduction de l’exposition.
L’administration publie un résumé public de l’audit (sans détails sensibles) sur son site, qui devient un signal pour les fournisseurs alternatifs et un retour d’expérience pour d’autres administrations.
Anti-pattern à éviter#
Un audit qui se contente de lister les éditeurs sans examiner la nature de gouvernance, ou qui agrège « tout est open source donc tout va bien » sans distinguer fondation neutre et single-vendor, rate l’objectif. De même, un audit confidentiel non publié n’alimente pas le bien commun et ne profite qu’à l’organisation qui l’a conduit.
L’audit n’est pas non plus un outil de blâme rétrospectif. Beaucoup de choix ont été faits il y a des années dans un contexte différent. L’objectif est de produire une vision lucide pour orienter les décisions futures, pas de juger les choix passés.
Indicateurs de réussite#
À l’horizon que vous fixez (typiquement 12 mois), vous pouvez raisonnablement considérer cet engagement tenu si vous disposez : d’une cartographie écrite des composants stratégiques avec leur juridiction de gouvernance, d’une qualification du modèle de gouvernance pour chaque composant, d’une identification d’au moins une alternative pour les composants à plus fort risque, et d’une publication ou d’un partage interne du résultat.
L’engagement n’exige pas que vous ayez agi sur les zones de risque — l’audit est l’étape de connaissance, l’action vient ensuite (et fait l’objet d’autres engagements possibles, comme user-004-study-migration-single-vendor).
→ Documenté dans le dossier#
Catégorie dans le schéma JSON : audit. Horizon par défaut : 12 mois. Applicable à : entreprises, administrations publiques, associations, fondations, institutions de recherche.