Durant le printemps, nos experts OCTO vous proposent un cycle de contenus autour du Cloud. Le sujet vous intéresse ? Pour découvrir le programme et ne rien rater, inscrivez-vous sur notre page Cloud, DevOps & Plateformes.
Choisir une solution de Cloud… Voilà bien un problème qui semblait assez enfantin il y a quelques années, et qui de nos jours semble inextricable sitôt qu’on va un tout petit peu plus loin que la surface des choses. Faisons le point !
Si on reste à la surface, le problème a l’air assez simple. Il y a quelques géants, en compétition les uns avec les autres, trois géants américains et un géant chinois, qui offrent des services vaguement similaires, qui évoluent rapidement, avec une grille de prix relativement illisible et où les pièges sont habilement masqués. Vu comme ça, choisir un des quatre, c’est faire un arbitrage entre quelques critères : lequel est le plus agréable à utiliser pour les équipes techniques, lequel offre un modèle de prix qui risque le moins d’exploser pour les usages prévus à moyen terme pour l’entreprise, lequel est le plus proche des modèles techniques choisis par l’entreprise. Bien entendu, on ajoute à tout celà les externalités habituelles (qui joue au golf avec qui, quel accord cadre signé entre grands groupes, et autres questions non-techniques), et on fait un choix.
Et d’ailleurs, pourquoi faut-il donc choisir un fournisseur de Cloud ? Le plus souvent, parce qu’on a cru à un récit légendaire. Posons qu’une légende, c’est un récit, factuellement faux, mais qui pourtant oriente fortement la façon dont la société humaine porteuse de ce récit agit. Par exemple, le Père Noël. On est bien d’accord qu’il n’existe pas. Et pourtant, Noël est un événement commercial absolument considérable, et un moment important dans la vie de bien des familles. C’est une légende. C’est un récit. Il est factuellement faux. Et il a cependant un effet considérable sur le monde.
Les légendes colportées sur le Cloud sont fort nombreuses. Par exemple :
-“On a tout virtualisé”. Quiconque a travaillé dans un datacenter à un moment de sa vie sait que c’est faux. Un serveur installé dans une baie informatique, rien de moins virtuel.
- “Ça scale à l’infini”. Il est évident que c’est faux (je veux une machine virtuelle avec 54 péta-octets de RAM… je veux une base Postgres managée avec 35 exa-octets de données… etc). Tous les informaticiens savent que certaines caractéristiques peuvent, dans certains cadres bien choisis, croître sans rencontrer de limite qui posent problème.
Et pourtant, ces légendes ont vendu du rêve, et ont conditionné la volonté affichée de beaucoup d’aller vers le Cloud. Et dans le mouvement vers le Cloud, les réalités ont refait surface.
Ce récit légendaire autour du Cloud a été un des moteurs de son succès. Pas le seul, bien entendu. Parce qu’un récit faux ne suffit pas à produire du succès. Mais il se trouve qu’il masque une réalité technique, qui est intéressante. Ainsi, passer sur le Cloud, c’est l’occasion de refaire l’ingénierie d’un système informatique, de remplacer une conception rigide par une conception plus distribuée, plus agile, plus évolutive. Il y a beaucoup de systèmes informatiques pour lesquels ce changement s’est révélé très positif, porteur de gains très substantiels ou d’économies conséquentes. Parfois, on partait vers le Cloud pour une croissance infinie, et on gagnait en fait de la souplesse. Et c’est bien parce qu’il y a un gain très réel (et parfois très important) que le récit légendaire peut produire un effet sur le monde.
Souvent, ces derniers temps, on qualifie de “moderne” (et de bien d’autres termes laudatifs) toute l’informatique dans le Cloud, et de “rétrograde “(et de beaucoup d'autres termes péjoratifs) toute celle qui n’y est pas. Et pourtant, une part considérable de l’informatique s’obstine à ne pas être dans le Cloud. Il doit bien y avoir une explication à cet état de fait. L’explication simpliste, centrée sur “c’est trop compliqué à refaire dans le Cloud”, ou sur “ils sont trop mauvais pour aller dans le cloud”, est très superficielle.
Les contraintes réglementaires ont ceci de particulier qu’elles sont rarement prises en compte en premier, dans un projet informatique. Assez souvent, elles arrivent en dernier : on développe le logiciel, et une fois qu’il est fini, on demande aux juristes de rédiger ce qu’il faut pour que ça aille. Un bon exemple de cette approche, pour les applications grand public, est de regarder les conditions générales d’utilisation des grands services destinés aux particuliers : elles sont rédigées une fois que le service est développé et en place, et intègrent les contraintes légales et réglementaires au fur et à mesure de leur apparition.
➡️ Sur ce sujet, lire aussi l’article La privacy comme opportunité.
Pour les systèmes informatiques des grands groupes, il en va autrement. La contrainte réglementaire est souvent intégrée dans les procédures internes de l’entreprise. Par exemple, l’équipe chargée de la sécurité a intégré les contraintes spécifiques, et ne les formule plus explicitement. Ou alors, l’équipe chargée de l’infrastructure physique d’hébergement des machines intègre les contraintes physiques sur la résilience, et ne les formule plus explicitement. Tous ces éléments vont intervenir dans la vie du projet, sous forme de nuisances, de difficultés, mais surtout sous forme non dite, diluée.
Ainsi, le projet de migration vers des technologies Cloud, qui semblait gros mais réaliste sur les plans des architectes, va lentement s’engluer dans des difficultés, dans des lourdeurs, dont ne sait plus bien pourquoi elles sont là, faute d’en avoir une vision transverse.
Pour utiliser du Cloud de manière intelligente dans ce type de contexte, il y a un certain nombre d’étapes, un certain nombre de questions clefs. La première est de chercher si on en a besoin, et quels besoins on cherche à satisfaire. Si vous n’êtes pas prêt à admettre que la réponse puisse être que vous n’en avez pas besoin, c’est que vous ne vous êtes pas posé la question.
Ensuite, il faut avoir conscience de qui on est. En effet, la solution adaptée pour une start-up n’est pas forcément adaptée pour un grand groupe. Et la solution qui est adaptée pour une grande entreprise de la finance ne sera pas forcément idéale pour un grand groupe du divertissement. Ce qui a très bien marché pour Netflix, si vous n’êtes pas Netflix, ce n’est pas une information très pertinente. C’est à cette étape-là qu’il est intéressant de savoir rendre explicite les contraintes réglementaires, les contraintes spécifiques, liées à “qui on est”, pour qu’elles soient intégrées tôt dans le choix de la solution retenue.
“Qui on est” implique également quelles législations nous sont applicables, et le paysage législatif autour du Cloud s’est considérablement complexifié ces dernières années. En effet s’appliquent aux solutions Cloud non seulement les mêmes contraintes qu’aux solutions hébergées localement (même si une partie de ces contraintes sont prises en charge par l’hébergeur) mais également les contraintes inhérentes à la nature même du Cloud. De par sa nature globalement distribuée, le Cloud est soumis à des contraintes pouvant émaner d’instances multiples, et des jurisprudences récentes comme Schrems II ont montré que le paysage législatif est en pleine mutation.
Les termes en vogue de “Cloud souverain” et de “Cloud de confiance” sont pratiques parce qu’ils peuvent servir de mot clé commun, mais ils décrivent mal le problème. Techniquement, le problème est plutôt une forme d’optimisation sous contraintes des choix en matière de migration vers les technologies du Cloud, c’est pourquoi le terme “Cloud sous contrainte” cerne mieux le sujet en ce qu’il décrit la méthode pour trouver une solution.
Les approches qui peuvent émerger de cette optimisation sous contrainte sont général un mixte de plusieurs solutions :
dans certains cas, du Cloud interne, opéré sur les infrastructures en propre de l’entreprise ;
des solutions de Cloud ayant différents niveaux de certification ou spécification (sur la sécurité, sur les données de santé, parfois une offre carrément portée par un secteur économique particulier) ;
des solutions hybrides, où c’est la diversité des fournisseurs utilisés qui viendra réduire la contrainte ;
des outils de séparation des traitements, ou de chiffrement, qui permettent de faire évoluer l’architecture globale du système d’information, et donc de faire que chaque brique subisse des contraintes différentes, plus faciles à satisfaire.
C’est l’analyse globale, holistique en quelques sortes, du problème à résoudre qui permet de choisir les bons outils pour moderniser un système d’information, dont un des outils est l’utilisation des technologies du Cloud.
➡️ Pour aller plus loin :
Pour comprendre les enjeux géopolitiques derrière le Cloud : voir le talk "Cloud Souverain - Géopolitique de la data" lors d'USI.
Pour comprendre les liens entre souveraineté et Cloud avec une approche juridique : lire l'article "Souveraineté et cloud, quel rapport ?"
Pour comprendre la notion de "Cloud sous contraintes" avec une vision architecture : découvrir le compte-rendu du talk "Sous le capot du Cloud Souverain" à La Duck Conf.
Pour tout savoir sur les enjeux Cloud, DevOps et Plateformes, cliquez ici.