Qu’est-ce que le vendor lock-in et comment l’éviter ?

On parle de vendor lock-in lorsqu’un client se lie si étroitement à un fournisseur qu’il lui est de facto impossible d’en changer. Il en résulte une dépendance du client à l’égard du fournisseur. Il convient également de garder à l’esprit le danger de l’effet « lock-in » lors de l’utilisation des offres Cloud. Les point suivants expliquent en quoi consiste exactement le vendor lock-in et comment l’éviter.

En général, l’effet « lock-in » est la dépendance d’un client à un produit ou à une technologie. Cette dépendance est due au fait qu’un changement est associé à des coûts élevés et est donc peu attrayant. Si la technologie est sous le contrôle d’un seul fournisseur (« vendor » en anglais), le client est effectivement lié au fournisseur et un « vendor lock-in » (enfermement propriétaire en francais) se produit.

Il existe sur le marché une multitude de technologies et de services parmi lesquels le client peut choisir. Ils sont proposés à des prix et des conditions différents. Chaque relation commerciale entre le client et le fournisseur a ses propres avantages et inconvénients. Une tension peut naître de la décision de travailler avec plusieurs ou seulement quelques prestataires.

D’un point de vue administratif, il est souhaitable de ne travailler qu’avec un petit nombre de fournisseurs. Cela permet d’obtenir un environnement homogène et moins complexe. Dans les cas extrêmes, tous les produits et services peuvent être achetés auprès d’un seul fournisseur. Cependant, cela conduit également à une dépendance totale vis-à-vis de ce fournisseur. Le client se retrouve en position de faiblesse et est en mauvaise posture pour négocier. L’exemple classique de vendor lock-in dans le secteur des logiciels est la dépendance à l’égard de Microsoft. Dans de nombreux secteurs de l’économie, tous les composants essentiels proviennent de la grande entreprise : système d’exploitation (Windows), logiciels d’application (Office), base de données (Access), etc. Cela signifie que tous les éléments importants du logiciel, des programmes aux licences et de la facturation à l’assistance, sont sous le contrôle d’un seul fournisseur. Le vendor lock-in est complet.

La dépendance à l’égard d’un prestataire résulte de l’impossibilité de changer de prestataire. Même si un changement est théoriquement possible, il se peut qu’il ne soit possible qu’au prix d’un grand effort. Le client est ainsi lié au fournisseur. Illustrons ce principe par un exemple simple :

On appelle souvent les composants technologiques des « biens complémentaires » car il existe une dépendance entre les différents composants. Par exemple, si vous possédez une Xbox ou une Playstation avec une collection de jeux correspondante, vous ne changerez probablement pas de système. Cela vous forcerait à racheter tous les jeux parce qu’ils ne fonctionnent pas sur une autre console.

Outre l’incompatibilité des technologies concurrentes décrite ci-dessus, les obstacles réglementaires et organisationnels rendent le changement de fournisseur encore plus difficile. D’une part, les conditions de licence et autres accords contractuels peuvent lier le client à un seul fournisseur. D’autre part, il se pourrait que des investissements aient déjà été réalisés dans les connaissances et la formation des employés. Si celle-ci est spécifique à la technologie et ne peut être transposée, le statu quo est confirmé.

Au cœur de ces considérations se trouve la prise de conscience que le tout est plus que la somme des parties. En fait, l’ensemble (un système) comprend :

• les parties (composants)
• les interactions et autres connexions explicites ou implicites entre les parties
• les propriétés résultantes (émergentes) de l’ensemble du système.

Les différentes parties peuvent souvent être déplacées relativement facilement lors d’un changement. En revanche, il peut être nécessaire de recréer les interactions à grands frais. Dans un système de culture biologique, les liens entre les composants sont généralement implicites. Il manque alors la description nécessaire pour reconstruire l’ensemble du système ; un changement devient difficile, voire impossible.

Un exemple concret :

Imaginons un système de base de données qui existe au sein de l’infrastructure d’un fournisseur. Les données qui y sont stockées peuvent être migrées relativement facilement lors du passage à un autre fournisseur. Mais qu’en est-il des autres composants et des connexions entre eux ? Paramètres, droits d’accès, répartition de la base de données sur plusieurs serveurs (Sharding), etc. Connaissons-nous la complexité du système global, ou pouvons-nous l’appréhender ? Si oui, l’ensemble du système peut-il être reproduit sans trop de difficultés sur l’infrastructure du nouveau fournisseur ? Dans de nombreux cas, la réponse à au moins une de ces questions est probablement « non ».

L’exemple de l’archivage électronique sécurisé peut être utilisé pour illustrer comment les propriétés des systèmes émergents rendent le changement de fournisseur plus difficile. L’archivage sécurisé en tant que critère comprend des exigences techniques, organisationnelles et réglementaires. Il s’agit donc d’une propriété supérieure du système. L’archivage électronique sécurisé d’un système est prouvé par la certification. La certification est liée à un cas spécifique ; lorsqu’un fournisseur est changé, le système est reconstruit et doit être recertifié en conséquence. L’effort supplémentaire nécessaire augmente les coûts de changement et contribue à l’effet de lock-in.

L’utilisation du Cloud offre de nombreux avantages. Cependant, le vendor lock-in constitue également une menace. Un exemple typique : des données importantes sont stockées chez un fournisseur de services Cloud. Si nous voulons faire appel à un autre fournisseur pour traiter les données, celles-ci doivent être transférées via le réseau. Cela entraîne des coûts de transfert. Il est donc intéressant de confier aussi le processus au premier prestataire. Il en résulte un effet de lock-in insidieux.

Plus vous stockez de données et plus la relation commerciale dure longtemps, plus l’effet de lock-in est important. Si votre propre logique d’entreprise repose sur des fonctionnalités, des API et des configurations propres à un fournisseur, il vous sera difficile de démêler la toile. Dans les cas extrêmes, tout est entre les mains d’un seul Managed Service Provider (fournisseur de services managés). Il convient également d’être prudent lorsqu’une entreprise de services du numérique crée une solution personnalisée. Un degré élevé de personnalisation se traduit par un lien fort entre le client et le fournisseur.

Examinons d’abord les capacités technologiques qui composent le Cloud. Nous identifions trois fonctionnalités de base :

• Software Defined Networking(SDN) : au lieu d’utiliser et de configurer des routeurs et des commutateurs physiques, on utilise des réseaux et des périphériques réseau virtuels.
• Software Defined Storage (SDS) : au lieu d’un stockage physique de masse, des sites d’hébergement de fichiers comme « Amazon S3 » et des solutions de stockage d’objets comme « Azure Blob Storage » sont utilisés dans un centre de données défini par logiciel.
• Solutions informatiques et sans serveur : Avec « Infrastructure-as-a-Service » (IaaS) et « Container-as-a-Service » (CaaS), les systèmes d’exploitation et les applications sont virtualisés. Avec « Function-as-a-Service » (FaaS), comme « AWS Lambda » et « Microsoft Azure Functions », des fonctions individuelles sont mises à disposition pour être utilisées.

Un environnement de cloud computing comprend les aspects techniques de l’hébergement, du stockage et des applications. On y trouve également les aspects organisationnels de la configuration, du support et des règlements. Un environnement Cloud spécifique est constitué de différentes manifestations de ces aspects. L’abondance desdifférentes caractéristiques peut être utilisée pour estimer à quel point la migration entre les fournisseurs s’avère généralement complexe :

Les produits Cloud mentionnés, tels que IaaS, PaaS, SaaS et CaaS, sont tous des services. Ceux-ci sont fournis par le fournisseur contre paiement, mais n’appartiennent à aucun moment au client. Il revient donc au prestataire, dans le cadre des contrats conclus, de décider si et à quelles conditions les services sont offerts.

Que se passe-t-il si les paramètres d’un service utilisé changent ? Dans le pire des cas, la qualité ou la portée du service est réduite, ou le fournisseur augmente le prix ou modifie les conditions au détriment du client. En principe, c’est le fournisseur qui est aux commandes, car le client dépend du fournisseur.

Les raisons de la dépendance à l’égard d’un fournisseur se manifestent également du côté du client. Par exemple, les employés de l’entreprise ont l’habitude de travailler avec la technologie fournie par le fournisseur. Les experts techniques sont généralement spécialisés dans certaines technologies. Lors du passage à un autre fournisseur, il peut être nécessaire de reformer le personnel, voire d’embaucher de nouveaux employés.

Pour sortir du vendor lock-in, il faut migrer les données et les processus vers un nouveau fournisseur. Une telle migration est souvent un processus complexe. Comme le bien-être de l’organisation dépend du succès de la migration, celle-ci doit être planifiée et testée au préalable. Même en faisant preuve d’une grande prudence, il est possible que les erreurs n’apparaissent que plus tard. Une migration complexe comporte donc toujours un risque élevé et il est normal de se demander si l’effort en vaut vraiment la peine.

La meilleure façon d’éviter le vendor lock-in est de le contrer de manière stratégique dès le départ. Au lieu de s’appuyer sur un seul fournisseur et donc de lui donner les pleins pouvoirs, on utilise plusieurs bases. Les systèmes internes sont explicitement construits dans le but de pouvoir échanger ultérieurement des composants partiels.

Voici un résumé des mesures stratégiques, organisationnelles et techniques spécifiques qui vous aideront à éviter le vendor lock-in.

Il est possible de prendre de meilleures décisions lorsque le risque de vendor lock-in est pris en compte dès le départ lors du choix des partenaires et des technologies. Par exemple, si l’on examine des technologies comparables proposées par deux fournisseurs à des prix légèrement différents, il peut être judicieux d’opter pour l’offre dont le prix est le plus élevé. Du moins, si cela permet de réduire le risque de vendor lock-in.

D’une manière générale, un bilan rigoureux s’impose : comprendre ses propres besoins en termes de technologie et recenser les structures informatiques déjà existantes est essentiel. Sur la base de la connaissance de ses propres systèmes et exigences, le paysage informatique est analysé. Il est important de tenir compte des tendances émergentes et de garder un œil sur l’obsolescence des technologies. Si d’anciens systèmes sont encore utilisés, par exemple, il est recommandé de procéder à un changement.

Si une technologie ou un fournisseur semble risqué en termes de vendor lock-in, vous devez définir une stratégie de sortie dès le départ. De cette manière, vous pouvez réagir rapidement et de manière ciblée aux changements défavorables qui pourraient survenir. Vous savez à l’avance ce qui doit être fait et êtes conscient des coûts et des risques encourus.

L’approche la plus évidente pour éviter le vendor lock-in est de ne pas devenirdépendant d’un seul fournisseur. Au lieu de déplacer tous les processus d’entreprise vers le Cloud, on opte pour une approche hybride. Ici, un Cloud privé est utilisé en plus des ressources Cloud d’un fournisseur. De cette manière, les processus centraux et les données qui y sont utilisées restent sous le contrôle de l’entreprise, ce qui permet de préserver la souveraineté des données.

Suivant le même schéma, il peut être avantageux de recourir aux services Cloud de plusieurs fournisseurs plutôt que d’un seul. Il est cependant important que tous les services utilisés disposent d’interfaces adéquates. Ce n’est que de cette manière qu’un système global cohérent peut être créé à partir des différents composants. De plus, les services des fournisseurs qui prennent explicitement en charge l’interopérabilité via des interfaces ouvertes sont préférables.

Toutes ces mesures ne sont efficaces que si elles couvrent les structures qui existent réellement au sein de l’organisation. Si les processus passent inaperçus, le vendor lock-in s’installera malgré tous vos efforts. Cela est particulièrement clair en ce qui concerne les « Dark data » (données sombres) : il s’agit de données qui existent en dehors des systèmes prévus. Il est utile de rendre les dépendances explicites et de normaliser dans une large mesure les processus et les systèmes.

La mesure technique la plus simple pour éviter le vendor lock-in consiste à ne pas utiliser de systèmes et de formats propriétaires. Si vous utilisez systématiquement des normes ouvertes et des logiciels libres, vous n’êtes par définition pas dépendant d’un seul fournisseur. Toutefois, cette approche ne suffit pas à garantir le succès de l’utilisation du Cloud si l’on a renoncé au contrôle des ressources matérielles.

Heureusement, de puissants outils d’orchestration ont été créés ces dernières années pour remédier à ce problème. Il s’agit notamment d’OpenShift et de Terraform. Ces outils servent de couche intermédiaire abstraite et découplent les exigences propres à l’infrastructure informatique de la couche sous-jacente, spécifique au fournisseur. Il est ainsi possible de construire une infrastructure informatique complète répartie sur plusieurs Cloud.

Le mot-clé ici est « Infrastructure-as-Code » (IaC). Attention : « code », pas « service ». Alors qu’un service est loué, le code reste sous le contrôle de l’utilisateur. Les structures souhaitées sont définies dans le code. Il s’agit des composants individuels, ainsi que des connexions entre eux. Outre la documentation explicite des systèmes dans le code que cela implique, il existe d’autres avantages décisifs.

À partir des structures définies de manière abstraite dans le code, le logiciel d’orchestration fournit les systèmes informatiques correspondants. Il est possible de répartir les différents composants sur plusieurs Cloud. Cela fonctionne pour les infrastructures Cloud de différents fournisseurs, ainsi que pour les Cloud privés de la propre entreprise. La réduction des coûts de changement de fournisseur qui en découle contribue de manière significative à la protection contre le vendor lock-in.