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

On parle de vendor lock-in lorsqu’un client se lie si étroi­te­ment à un four­nis­seur qu’il lui est de facto im­pos­sible d’en changer. Il en résulte une dé­pen­dance du client à l’égard du four­nis­seur. Il convient également de garder à l’esprit le danger de l’effet « lock-in » lors de l’uti­li­sa­tion des offres Cloud. Les point suivants ex­pli­quent en quoi consiste exac­te­ment le vendor lock-in et comment l’éviter.

En général, l’effet « lock-in » est la dé­pen­dance d’un client à un produit ou à une tech­no­lo­gie. Cette dé­pen­dance est due au fait qu’un chan­ge­ment est associé à des coûts élevés et est donc peu attrayant. Si la tech­no­lo­gie est sous le contrôle d’un seul four­nis­seur (« vendor » en anglais), le client est ef­fec­ti­ve­ment lié au four­nis­seur et un « vendor lock-in » (en­fer­me­ment pro­prié­taire en francais) se produit.

Il existe sur le marché une multitude de tech­no­lo­gies et de services parmi lesquels le client peut choisir. Ils sont proposés à des prix et des con­di­tions dif­fé­rents. Chaque relation com­mer­ciale entre le client et le four­nis­seur a ses propres avantages et in­con­vé­nients. Une tension peut naître de la décision de tra­vail­ler avec plusieurs ou seulement quelques pres­ta­taires.

D’un point de vue ad­mi­nis­tra­tif, il est sou­hai­table de ne tra­vail­ler qu’avec un petit nombre de four­nis­seurs. Cela permet d’obtenir un en­vi­ron­ne­ment homogène et moins complexe. Dans les cas extrêmes, tous les produits et services peuvent être achetés auprès d’un seul four­nis­seur. Cependant, cela conduit également à une dé­pen­dance totale vis-à-vis de ce four­nis­seur. 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é­pen­dance à l’égard de Microsoft. Dans de nombreux secteurs de l’économie, tous les com­po­sants es­sen­tiels pro­vien­nent de la grande en­tre­prise : système d’ex­ploi­ta­tion (Windows), logiciels d’ap­pli­ca­tion (Office), base de données (Access), etc. Cela signifie que tous les éléments im­por­tants du logiciel, des pro­grammes aux licences et de la fac­tu­ra­tion à l’as­sis­tance, sont sous le contrôle d’un seul four­nis­seur. Le vendor lock-in est complet.

La dé­pen­dance à l’égard d’un pres­ta­taire résulte de l’im­pos­si­bi­lité de changer de pres­ta­taire. Même si un chan­ge­ment est théo­ri­que­ment possible, il se peut qu’il ne soit possible qu’au prix d’un grand effort. Le client est ainsi lié au four­nis­seur. Il­lus­trons ce principe par un exemple simple :

On appelle souvent les com­po­sants tech­no­lo­giques des « biens com­plé­men­taires » car il existe une dé­pen­dance entre les dif­fé­rents com­po­sants. Par exemple, si vous possédez une Xbox ou une Plays­ta­tion avec une col­lec­tion de jeux cor­res­pon­dante, vous ne changerez pro­ba­ble­ment pas de système. Cela vous forcerait à racheter tous les jeux parce qu’ils ne fonc­tion­nent pas sur une autre console.

Outre l’in­com­pa­ti­bi­lité des tech­no­lo­gies con­cur­rentes décrite ci-dessus, les obstacles ré­gle­men­taires et or­ga­ni­sa­tion­nels rendent le chan­ge­ment de four­nis­seur encore plus difficile. D’une part, les con­di­tions de licence et autres accords con­trac­tuels peuvent lier le client à un seul four­nis­seur. D’autre part, il se pourrait que des in­ves­tis­se­ments aient déjà été réalisés dans les con­nais­sances et la formation des employés. Si celle-ci est spé­ci­fique à la tech­no­lo­gie et ne peut être trans­po­sée, le statu quo est confirmé.

Au cœur de ces con­si­dé­ra­tions se trouve la prise de cons­cience que le tout est plus que la somme des parties. En fait, l’ensemble (un système) comprend :

• les parties (com­po­sants)
• les in­te­rac­tions et autres con­nexions ex­pli­cites ou im­pli­cites entre les parties
• les pro­prié­tés ré­sul­tantes (émer­gentes) de l’ensemble du système.

Les dif­fé­rentes parties peuvent souvent être déplacées re­la­ti­ve­ment fa­ci­le­ment lors d’un chan­ge­ment. En revanche, il peut être né­ces­saire de recréer les in­te­rac­tions à grands frais. Dans un système de culture bio­lo­gique, les liens entre les com­po­sants sont gé­né­ra­le­ment im­pli­cites. Il manque alors la des­crip­tion né­ces­saire pour re­cons­truire l’ensemble du système ; un chan­ge­ment devient difficile, voire im­pos­sible.

Un exemple concret :

Imaginons un système de base de données qui existe au sein de l’in­fras­truc­ture d’un four­nis­seur. Les données qui y sont stockées peuvent être migrées re­la­ti­ve­ment fa­ci­le­ment lors du passage à un autre four­nis­seur. Mais qu’en est-il des autres com­po­sants et des con­nexions entre eux ? Pa­ra­mètres, droits d’accès, ré­par­ti­tion de la base de données sur plusieurs serveurs (Sharding), etc. Con­nais­sons-nous la com­plexité du système global, ou pouvons-nous l’ap­pré­hen­der ? Si oui, l’ensemble du système peut-il être reproduit sans trop de dif­fi­cul­tés sur l’in­fras­truc­ture du nouveau four­nis­seur ? Dans de nombreux cas, la réponse à au moins une de ces questions est pro­ba­ble­ment « non ».

L’exemple de l’archivage élec­tro­nique sécurisé peut être utilisé pour illustrer comment les pro­prié­tés des systèmes émergents rendent le chan­ge­ment de four­nis­seur plus difficile. L’archivage sécurisé en tant que critère comprend des exigences tech­niques, or­ga­ni­sa­tion­nelles et ré­gle­men­taires. Il s’agit donc d’une propriété su­pé­rieure du système. L’archivage élec­tro­nique sécurisé d’un système est prouvé par la cer­ti­fi­ca­tion. La cer­ti­fi­ca­tion est liée à un cas spé­ci­fique ; lorsqu’un four­nis­seur est changé, le système est re­cons­truit et doit être re­cer­ti­fié en con­sé­quence. L’effort sup­plé­men­taire né­ces­saire augmente les coûts de chan­ge­ment et contribue à l’effet de lock-in.

L’uti­li­sa­tion du Cloud offre de nombreux avantages. Cependant, le vendor lock-in constitue également une menace. Un exemple typique : des données im­por­tantes sont stockées chez un four­nis­seur de services Cloud. Si nous voulons faire appel à un autre four­nis­seur pour traiter les données, celles-ci doivent être trans­fé­rées via le réseau. Cela entraîne des coûts de transfert. Il est donc in­té­res­sant de confier aussi le processus au premier pres­ta­taire. Il en résulte un effet de lock-in insidieux.

Plus vous stockez de données et plus la relation com­mer­ciale dure longtemps, plus l’effet de lock-in est important. Si votre propre logique d’en­tre­prise repose sur des fonc­tion­na­li­tés, des API et des con­fi­gu­ra­tions propres à un four­nis­seur, 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 (four­nis­seur de services managés). Il convient également d’être prudent lorsqu’une en­tre­prise de services du numérique crée une solution per­son­na­li­sée. Un degré élevé de per­son­na­li­sa­tion se traduit par un lien fort entre le client et le four­nis­seur.

Examinons d’abord les capacités tech­no­lo­giques qui composent le Cloud. Nous iden­ti­fions trois fonc­tion­na­li­tés de base :

• Software Defined Net­wor­king (SDN) : au lieu d’utiliser et de con­fi­gu­rer des routeurs et des com­mu­ta­teurs physiques, on utilise des réseaux et des pé­ri­phé­riques réseau virtuels.
• Software Defined Storage (SDS) : au lieu d’un stockage physique de masse, des sites d’hé­ber­ge­ment 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 in­for­ma­tiques et sans serveur : Avec « In­fras­truc­ture-as-a-Service » (IaaS) et « Container-as-a-Service » (CaaS), les systèmes d’ex­ploi­ta­tion et les ap­pli­ca­tions sont vir­tua­li­sés. Avec « Function-as-a-Service » (FaaS), comme « AWS Lambda » et « Microsoft Azure Functions », des fonctions in­di­vi­duelles sont mises à dis­po­si­tion pour être utilisées.

Un en­vi­ron­ne­ment de cloud computing comprend les aspects tech­niques de l’hé­ber­ge­ment, du stockage et des ap­pli­ca­tions. On y trouve également les aspects or­ga­ni­sa­tion­nels de la con­fi­gu­ra­tion, du support et des rè­gle­ments. Un en­vi­ron­ne­ment Cloud spé­ci­fique est constitué de dif­fé­rentes ma­ni­fes­ta­tions de ces aspects. L’abondance des dif­fé­rentes ca­rac­té­ris­tiques peut être utilisée pour estimer à quel point la migration entre les four­nis­seurs s’avère gé­né­ra­le­ment complexe :

Les produits Cloud men­tion­nés, tels que IaaS, PaaS, SaaS et CaaS, sont tous des services. Ceux-ci sont fournis par le four­nis­seur contre paiement, mais n’ap­par­tien­nent à aucun moment au client. Il revient donc au pres­ta­taire, dans le cadre des contrats conclus, de décider si et à quelles con­di­tions les services sont offerts.

Que se passe-t-il si les pa­ra­mètres d’un service utilisé changent ? Dans le pire des cas, la qualité ou la portée du service est réduite, ou le four­nis­seur augmente le prix ou modifie les con­di­tions au détriment du client. En principe, c’est le four­nis­seur qui est aux commandes, car le client dépend du four­nis­seur.

Les raisons de la dé­pen­dance à l’égard d’un four­nis­seur se ma­ni­fes­tent également du côté du client. Par exemple, les employés de l’en­tre­prise ont l’habitude de tra­vail­ler avec la tech­no­lo­gie fournie par le four­nis­seur. Les experts tech­niques sont gé­né­ra­le­ment spé­cia­li­sés dans certaines tech­no­lo­gies. Lors du passage à un autre four­nis­seur, il peut être né­ces­saire 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 four­nis­seur. Une telle migration est souvent un processus complexe. Comme le bien-être de l’or­ga­ni­sa­tion 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’ap­pa­rais­sent 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 stra­té­gique dès le départ. Au lieu de s’appuyer sur un seul four­nis­seur et donc de lui donner les pleins pouvoirs, on utilise plusieurs bases. Les systèmes internes sont ex­pli­ci­te­ment cons­truits dans le but de pouvoir échanger ul­té­rieu­re­ment des com­po­sants partiels.

Voici un résumé des mesures stra­té­giques, or­ga­ni­sa­tion­nelles et tech­niques spé­ci­fiques qui vous aideront à éviter le vendor lock-in.

Il est possible de prendre de meil­leures décisions lorsque le risque de vendor lock-in est pris en compte dès le départ lors du choix des par­te­naires et des tech­no­lo­gies. Par exemple, si l’on examine des tech­no­lo­gies com­pa­rables proposées par deux four­nis­seurs à des prix lé­gè­re­ment dif­fé­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 : com­prendre ses propres besoins en termes de tech­no­lo­gie et recenser les struc­tures in­for­ma­tiques déjà exis­tantes est essentiel. Sur la base de la con­nais­sance de ses propres systèmes et exigences, le paysage in­for­ma­tique est analysé. Il est important de tenir compte des tendances émer­gentes et de garder un œil sur l’ob­so­les­cence des tech­no­lo­gies. Si d’anciens systèmes sont encore utilisés, par exemple, il est re­com­mandé de procéder à un chan­ge­ment.

Si une tech­no­lo­gie ou un four­nis­seur 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 ra­pi­de­ment et de manière ciblée aux chan­ge­ments dé­fa­vo­rables qui pour­raient 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 devenir dépendant d’un seul four­nis­seur. Au lieu de déplacer tous les processus d’en­tre­prise vers le Cloud, on opte pour une approche hybride. Ici, un Cloud privé est utilisé en plus des res­sources Cloud d’un four­nis­seur. De cette manière, les processus centraux et les données qui y sont utilisées restent sous le contrôle de l’en­tre­prise, ce qui permet de préserver la sou­ve­rai­neté des données.

Suivant le même schéma, il peut être avan­ta­geux de recourir aux services Cloud de plusieurs four­nis­seurs plutôt que d’un seul. Il est cependant important que tous les services utilisés disposent d’in­ter­faces adéquates. Ce n’est que de cette manière qu’un système global cohérent peut être créé à partir des dif­fé­rents com­po­sants. De plus, les services des four­nis­seurs qui prennent ex­pli­ci­te­ment en charge l’in­te­ro­pé­ra­bi­lité via des in­ter­faces ouvertes sont pré­fé­rables.

Toutes ces mesures ne sont efficaces que si elles couvrent les struc­tures qui existent réel­le­ment au sein de l’or­ga­ni­sa­tion. Si les processus passent inaperçus, le vendor lock-in s’ins­tal­lera malgré tous vos efforts. Cela est par­ti­cu­liè­re­ment 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é­pen­dances ex­pli­cites et de nor­ma­li­ser 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 pro­prié­taires. Si vous utilisez sys­té­ma­ti­que­ment des normes ouvertes et des logiciels libres, vous n’êtes par dé­fi­ni­tion pas dépendant d’un seul four­nis­seur. Toutefois, cette approche ne suffit pas à garantir le succès de l’uti­li­sa­tion du Cloud si l’on a renoncé au contrôle des res­sources ma­té­rielles.

Heu­reu­se­ment, de puissants outils d’or­ches­tra­tion 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 in­ter­mé­diaire abstraite et dé­couplent les exigences propres à l’in­fras­truc­ture in­for­ma­tique de la couche sous-jacente, spé­ci­fique au four­nis­seur. Il est ainsi possible de cons­truire une in­fras­truc­ture in­for­ma­tique complète répartie sur plusieurs Cloud.

Le mot-clé ici est « In­fras­truc­ture-as-Code » (IaC). Attention : « code », pas « service ». Alors qu’un service est loué, le code reste sous le contrôle de l’uti­li­sa­teur. Les struc­tures sou­hai­tées sont définies dans le code. Il s’agit des com­po­sants in­di­vi­duels, ainsi que des con­nexions entre eux. Outre la do­cu­men­ta­tion explicite des systèmes dans le code que cela implique, il existe d’autres avantages décisifs.

À partir des struc­tures définies de manière abstraite dans le code, le logiciel d’or­ches­tra­tion fournit les systèmes in­for­ma­tiques cor­res­pon­dants. Il est possible de répartir les dif­fé­rents com­po­sants sur plusieurs Cloud. Cela fonc­tionne pour les in­fras­truc­tures Cloud de dif­fé­rents four­nis­seurs, ainsi que pour les Cloud privés de la propre en­tre­prise. La réduction des coûts de chan­ge­ment de four­nis­seur qui en découle contribue de manière sig­ni­fi­ca­tive à la pro­tec­tion contre le vendor lock-in.