Introduction#
Nos dépendances aux fournisseurs tiers sont de plus en plus importantes et parfois risquées. Risquées par le changement abrupt de certaines fonctionnalités proposées, du modèle de licences, du tarif de l’hébergement, d’APIs maintenant plus restrictives, et tout cela sans pouvoir en tant que client aller voir ailleurs. Nous parlons de verrouillage ou de lock-in.
Ici nous prenons le rôle d’un architecte logiciel qui conçoit une solution numérique et évalue un service à intégrer dans sa solution.
Le terme service et fournisseur sont utilisés indifféremment pour un service SaaS, un framework open source, ou une technologie. Ils désignent respectivement ce qui est pris en main par le client (nous), et l’entité qui construit.
➡ Proposons une liste de différents lock-in et appliquons-la dans un exemple.
Les types de lock-in#
Savoir-faire technique
Pour ce premier point, l'objectif est de comprendre de quel savoir-faire ou de quelles compétences nous avons besoin pour utiliser le service et le maintenir. L'opposition entre la rareté et l'abondance de la compétence est un bon indicateur. En d'autres mots, quel est le degré de spécificité du savoir-faire attendu ? Plus le logiciel repose sur des concepts propriétaires, plus on dépend d'une expertise arbitraire niche et difficilement accessible.Exemple
- La complexité de Kubernetes peut provoquer un lock-in, car sa complexité nécessite des certifications (CKA, CKAD) dont le marché de profils est tendu.
- Apache Airflow est l’exemple d’un outil niche, dont l’expertise à construire déprécie la rapidité opérationnelle.
Indicateurs clés
- En combien de temps un nouvel arrivant peut faire un changement en production avec la stack technique ?
- Avons-nous ces compétences en interne ?
- Quelle est l’offre de profils correspondants sur le marché — que nous devrons recruter ?
Comment réduire le risque
- Se baser sur des outils standards, éprouvés.
- Estimer l’offre de profils adaptés.
Gouvernance
Quel est notre droit de regard, notre pouvoir de décision face aux évolutions du service utilisé ? Cette dépendance se révèle brutalement le jour où une fonctionnalité clé disparaît ou change de comportement sans préavis. Elle oblige à mesurer la fiabilité des fonctionnalités clés dont nous sommes dépendants et constituent la majeure partie de la valeur ajoutée.Exemple
- Twitter restreignant l’accès au contenu en ligne via son API gratuite.
- Changement significatif des prix de l’API de Google Maps.
Indicateurs clés
- Le fournisseur propose-t-il une roadmap publique, est-il transparent sur ses prochaines évolutions ?
- Quel est le type de gouvernance (fondation, investissements privés,…) ?
Comment réduire le risque
- Se diriger vers un fournisseur transparent sur son évolution et fiable concernant ses changements passés.
- Surveiller les annonces du fournisseur et des ses concurrents (ex: si applicable, surveiller les releases GitHub du service).
Dépendance contractuelle
Gardons à l'oeil les conditions qui nous engagent : la durée du contrat, la reconduction tacite, le préavis de résiliation, les pénalités de sortie anticipée. Attention aux longs engagements et les clauses de sortie qui pourraient diminuer la liberté de manœuvre, et ce même si le service ne convient plus. Quid de l'appartenance contractuelle des données ? Avons-nous signé une clause d'exclusivité pour l'utilisation de ce service ? Le modèle de tarification est-il simple et facilement comparable à la concurrence ? Le modèle de licence est-il correctement décrit ?Exemple
- Coûts des minutes d’exécution des GitHub Runners (CI / CD).
- Accepter un modèle de licence non adapté à nos usages, qui peut rapidement faire augmenter la facture.
Indicateurs clés
- Quelle est la durée d’engagement ?
- Quel est l’impact du modèle de licence sur l’utilisation du service ?
Comment réduire le risque
- S’assister d’une expertise contractuelle.
- Négocier le modèle de licence — si applicable.
- Négocier des clauses de sortie : par exemple demander un préavis court, une période d’accès aux données assez longue et des frais de migration plafonnés.
Dépendance technologique
Les parties du système sont-elles ouvertes (open source), leur technologie standarde avec une rétro-compatibilité ? Un système propriétaire doté d'une technologie fermée ou très spécifique (ou avec beaucoup de customisation) est un fort verrou d'évolution. Quelle est la capacité d'intégration de l'outil (API) ?Exemple
- Utilisation d’Azure DevOps avec les tasks propriétaires.
Indicateurs clés
- Peut-on déployer ce service on-premises, ou est-il seulement disponible en SaaS ?
- Le service ou outil est-il toujours maintenu ?
- Existe-il une communautée vers laquelle nous pouvons nous tourner pour résoudre de futures problèmes techniques ?
- Propose-t-il des intégrations simples ?
- Quel est le paysage concurrentiel — existe-il des alternatives où un transfert est possible ?
- Étudier le coût de customisation : est-ce que le service répond complètement ou partiellement à mon besoin. S’il n’y répond que partiellement, quel est le coût associé aux changements nécessaires ?
Comment réduire le risque
- Se tourner vers des services qui ont des alternatives compatibles selon le besoin (ex: Python FastAPI vs Flask).
- Utiliser des outils d’abstraction pour utiliser le service, tels que Terraform pour le déploiement multi-cloud.
- Dissocier la configuration (peu coûteuse) de la customisation (très coûteuse).
Gestion des données
Enfin, quelle marge de manoeuvre disposons-nous pour gérer nos données : pouvons-nous les importer et exporter intégralement, avec leur historique et leurs relations, ou seulement un extrait, une sous partie ? Leur format est-il standard (CSV, XML, JSON,...) ? Dois-je payer un supplément pour demander le bon format au fournisseur ? Quelle facilité technique pour l'extraction, sommes-nous tributaires du service technique du fournisseur, pouvons-nous le faire nous-même (accès API) et automatiser ?Exemple
- Importation de données JIRA vers une autre instance JIRA soumise à la présence des mêmes plugins de part et d’autre, ainsi qu’une compatibilité serrée entre versions.
- Export de données JIRA disponible sous plusieurs formats.
Indicateurs clés
- Peut-on importer des données depuis d’autres sources sans perte ?
- Des exports réguliers sont-ils possibles ?
- L’automatisation de l’importation, synchronisation et exportation est-elle possible ?
- À qui appartiennent les données générées avec ce service ?
Comment réduire le risque
- S’assurer de la présence de fonctionnalités d’import, synchronisation, export.
- Lister les formats disponibles, connaître les conditions de récupération de nos données.
Pourquoi le lock-in existe-il#
Dans le contexte où le fournisseur cherche à garder ses clients, il doit a minima sur le court terme, les attirer et les garder. Alors même si le lock-in est délétère sur le long terme, quels réels avantages font rester les clients au début ?
- Savoir-faire technique : l’outil est peut-être plus simple à prendre en main au départ, moins de compétences requises. Il existe une grande communauté et le service devient un standard.
- Gouvernance : un fournisseur avec une roadmap active et beaucoup de fonctionnalités est rassurant à court terme, même sans droit de regard réel.
- Dépendance contractuelle : les offres d’appel (freemium, prix de lancement bas, essais gratuits) rendent l’entrée quasi gratuite au début.
- Dépendance technologique : plus de fonctionnalités clé-en-main, moins d’intégrations nécessaires (APIs, webhooks,…) qui sont présentes en coulisses.
- Gestion des données : la facilité d’importation de données existantes accélère le démarrage.
Puis en prenant en compte le facteur temporel, notons aussi une rapidité de conception et déploiement : il est parfois préférable de réaliser les choses rapidement, qu’un écosystème fermé mais très adapté permet de réaliser.
Un exemple#
Tentons d’appliquer cette analyse sur deux services concurrents que sont Gitlab et GitHub sur le segment de la CI/CD.
| Type de lock-in | GitLab | GitHub |
|---|---|---|
| Savoir-faire technique | Savoir-faire DevOps requis pour l’auto-hébergement (configuration de runners, Docker & Kubernetes). | Savoir-faire spécifique à GitHub Actions (YAML, secrets, artifacts). Intégration forte avec Microsoft (Azure, VS Code). |
| Gouvernance | Transparence élevée : Roadmap publique, issues et MRs visibles. Modèle open core : Version Community (open source) + versions payantes. | Transparence moyenne : Roadmap moins détaillée. Dépend de Microsoft. Changements parfois abrupts (ex : suppression des tokens classiques). |
| Dépendance contractuelle | Auto-hébergement (gratuit) ou SaaS (abonnements). Clauses de sortie : Export complet des données (repos, issues, CI/CD) via API ou backup. | Gratuit pour les repos publics, payant pour les privés (par utilisateur). |
| Dépendance technologique | Open source et possibilité d’auto-héberger. Communauté active. Outils intégrés : CI/CD, issue tracking, monitoring (Prometheus), registry Docker. | SaaS dominant, propriétaire : CI/CD via GitHub Actions. Intégrations profondes avec Azure. Dépendance à l’écosystème : Marketplace GitHub (actions tierces parfois payantes). |
| Gestion des données | Export complet : Repos, issues, MRs, pipelines, artifacts, registry (Docker images). Formats : JSON, CSV, archives. API complète : Accès programmatique à toutes les données. | Export partiel : Repos, issues (JSON/CSV), mais pas de données CI/CD (logs, artifacts des Actions). Formats propriétaires : Certains rapports (ex : Insights, Codespaces) non exportables. API limitée : Pas d’accès aux données historiques des Actions. |
On note des points forts sur la transparence et l’exportation des données de la part de Gitlab. Le modèle propriétaire de GitHub nuit à son image et c’est une réalité théorique qui semble incontestable. Pour autant en pratique on pourrait choisir le service GitHub pour une rapidité de mise en place, et parce que l’offre de profils formés à GitHub est plus abondante.
Conclusion#
La méthodologie exposée ici est un point de départ d’une analyse de dépendance à un service numérique. Elle propose une vision en cinq axes (Compétences, Gouvernance, Contractualisation, Dépendance technologique et Gestion des données) pour un tour d’horizon. L’évaluation complète d’une solution ne s’arrête pas à la simple étude de lock-in. On pensera par exemple à une revue de sécurité du service proposé (chiffrement des données au repos, en transit,…) et son architecture.
Cependant, bien comprendre les risques de lock-in et mettre en place des stratégies pour les éviter nous permettra de réduire les inconnues d’exploitation, réduire les coûts non prévus et améliorer la flexiblité.