Jean-Jacques Quisquater, Charles Cuvelliez et Bruno Colman
Photo d'illustration
Pxfuel
Les clients des hyperscalers ont beau être des sociétés du CAC40, leur pouvoir de négociation est très limité. Souscrire à un service cloud se fait en ligne, avec une création automatique et une signature à distance du contrat sauf pour les plus gros contrats où un peu de marge reste possible. Ensuite, explique l'Autorité de la concurrence, le fournisseur de cloud se permet parfois de changer le contrat en cours de route.
Mais le problème est ailleurs : les hyperscalers savent bien, au fond d'eux-mêmes, que les clients ne peuvent pas bien anticiper le coût d'utiliser le cloud : les offres sont complexes, la structure des tarifs est peu claire. Les clients ne réalisent pas toujours que les services auxquels ils souscrivent sont complémentaires. Même si cela peut se justifier au niveau technologique, le lien entre tous ces services est peu transparent. Les hyperscalers ont un catalogue varié et très attirant mais les clients qui migrent pour la première fois dans le cloud n'ont aucune visibilité sur les services qu'ils prendront après les produits de base d'un cloud : de la capacité de stockage, de la puissance de calcul. Le volume d'utilisation leur est inconnu aussi. L'achat de services cloud se fait malheureusement un peu à l'aveugle. Il serait plus judicieux pour éviter les mauvaises surprises, dit l'Autorité de concurrence, de ne pas facturer au trafic mais au forfait. Au fond, n'est-ce pas ce qui est proposé quand on souscrit à une offre cloud pour particulier chez Microsoft ?
Il y a ensuite les crédits cloud que l'Autorité de la concurrence pointe du doigt : c'est un montant à dépenser pendant un temps donné qui vient ensuite en déduction de la facture future. C'est très attirant pour les startups qui y voient la possibilité de se construire une infrastructure IT gratuite dans le cloud pendant quelques mois mais après, quand tout est bien construit et fonctionne, la startup n'a plus d'autre choix que de rester avec ce fournisseur de cloud qu'il ne testait qu'au départ. Ces crédits clouds ne sont pas donc pas une offre limitée d'essai ! Seuls les hyperscalers sont en mesure de proposer systématiquement ces crédit clouds à qui le veut : cela ne représente quasiment rien par rapport à la masse de revenus qu'ils engrangent mais on imagine bien qu'un concurrent ne puisse répliquer les crédits cloud de manière aussi systémique.
Il y a ensuite les egress fees, qui sont facturés quand le client souhaite sortir les données du cloud, soit pour aller chez un concurrent, soit dans une stratégie multi-cloud c'est-à-dire les faire aller et venir dans un autre cloud pour répartir la charge de travail. L'Autorité de la Concurrence appelle ces coûts, une facturation à la sortie. Les hyperscalers ont expliqué que c'était le seul moment où ils pouvaient récupérer les coûts d'utilisation de l'infrastructure du cloud, de l'usage des centres de données, de la fibre, des serveurs. L'Autorité de la concurrence ne l'entend pas ainsi. Ces coûts que les egress fees sont censés récupérer sont des coûts communs à tous les services proposés sur le cloud : pourquoi les facturer alors sur du trafic sortant. En fait, les egress fees peuvent atteindre un tel montant que les clients qui se décideraient à diversifier leur risque de concentration entre plusieurs fournisseurs de cloud y renonceraient bien vite. Ces egress fees, pour l'Autorité de la concurrence, sont un moyen de proposer des prix attractifs au départ, tant qu'on ne quitte pas le cloud. Une stratégie multicloud reste possible mais à condition que ces clouds ne se parlent jamais pour éviter les egress fees.
Il est tout aussi étrange, note l'Autorité de la Concurrence, que les tarifs pour le trafic entrant et le trafic sortant soient différents. Ce qui coûte au fournisseur de cloud, c'est la bande passante utilisée, le débit, pas la direction de ce dernier. En ne facturant quasi rien le trafic entrant, c'est un moyen de capturer le plus possible de données venant du client.
L’actualité qui compte pour vous, chaque jour dans votre boîte mail.
Les fournisseurs de cloud qui proposent des logiciels ne se privent pas de restreindre leur utilisation dans des clouds concurrents (comme Office même si Windows y a mis récemment fin ou les serveurs Windows ou Oracle qui interdit carrément l'utilisation de ses produits ailleurs que dans son cloud). Les fournisseurs de cloud menacent même de mener des audits pour vérifier l'adéquation de la licence avec son usage dans le « bon » cloud ou non.
La tendance des fournisseurs de logiciels à faire évoluer leur offre de logiciel vers des SaaS (c'est-à-dire accéder à distance plutôt que de l'installer sur ses propres serveurs) est aussi fortement critiquée par l'Autorité de concurrence. Non, ce n'est pas toujours pour des raisons d'efficacité que cette évolution est proposée : on présente le SaaS comme une opportunité d'avoir en permanence accès à la dernière version du logiciel et de ne pas devoir installer des correctifs soi-même : le fournisseur s'en occupe. Certes, mais la dépendance à ce dernier s'en trouve augmentée : on passe à une offre par abonnement plutôt qu'un achat unique de la licence. En cas de rupture de contrat avec le fournisseur, l'accès au SaaS est bloqué alors qu'avec un logiciel qui tourne sur ses propres serveurs, rien n'empêche de continuer à l'utiliser. Le client en est propriétaire et peut continuer à le faire tourner (même si ce n'est pas sain de continuer à utiliser un logiciel qui ne sera plus mis à jour).
Migrer vers un autre cloud reste une gageure : les hyperscalers ont beau expliquer que les offres IaaS (infrastructure as a service) sont des services de base : de la capacité de stockage, de la puissance de calcul aisément transposable d'un fournisseur à l'autre sauf que la version du système d'exploitation peut varier d'un cloud à l'autre tout comme les correctifs déjà installés chez l'un et pas chez l'autre, le type de serveur qui peut tourner chez l'un et pas l'autre.
Si on passe au PaaS (Platform as a Service), la situation empire car cette offre est très spécifique au vendeur puisqu'il va à juste titre proposer des services à valeur ajoutée qui feront la différence avec le voisin quand le client utilise le cloud pour y faire des développements. Ce n'est pas l'open source de Kubernetes qui fera la différence ni même Terraform avec sa promesse de porter d'un cloud à l'autre son code. Leur pénétration est trop faible. Quand un client doit passer d'un cloud à l'autre, il doit adapter un minimum ses codes applicatifs via le refactoring ou même le rendre natif au cloud (replatorming). Une fois ce développement fait, passer à un cloud concurrent demanderait à nouveau cet effort. Une interopérabilité totale entre clouds nécessiterait de mettre des ponts entre nouveaux et anciens services d'un cloud et de l'autre, ce qui peut présenter des trous de sécurité. Soit.
Il y a aussi des barrières volontaires pour l'interopérabilité qu'introduisent les fournisseurs de clouds. Ce sont par exemple des standards fermés pour les logiciels utilisés par les hyperscalers et l'imposition d'une distance délibérée avec des standards ouverts afin de limiter l'interopérabilité avec les services d'autres fournisseurs. Il y aurait des pratiques d'hyperscalers, notamment AWS et Microsoft, qui limitent l'interopérabilité de leurs services en ne partageant pas ouvertement des informations telles que les interfaces de programmation d'applications (jusqu'à être non disponibles aux tiers) ou en combinant open source et normes propriétaires.
Et quoi de plus attirant qu'un accès à Google Maps ou Google Search via des interfaces de programmation propriétaires, offerts quasiment gratuitement à qui développera un service dans son cloud.
Enfin, quoique le problème n'est pas encore présent, l'Autorité de concurrence se méfie des fournisseurs de cloud qui ont aussi des places de marché qu'ils peuvent imposer à leur client pour capturer tous les services de ce dernier.
Le droit de la concurrence pourra -t-il faire quelque chose pour remédier à ces caveat ? Ou faudra-t-il une régulation qui impose interopérabilité et portabilité entre clouds. A moins que les couches intermédiaires logicielles qui rendent invisible la tuyauterie sous-jacente de chaque cloud soient la solution.
_______
À lire également
Pour en savoir plus : Avis n° 23-A-08 du 29 juin 2023, portant sur le fonctionnement concurrentiel de l'informatique en nuage (« cloud »)
Jean-Jacques Quisquater, Charles Cuvelliez et Bruno Colman
