Histoire et développement du cloud computing : une chronologie claire

Le développement du cloud computing s'étend sur plusieurs décennies. Le temps partagé a rendu des ordinateurs coûteux accessibles à plusieurs utilisateurs ; la virtualisation a permis à différents systèmes de partager le matériel ; les réseaux ont relié les utilisateurs à des ressources distantes. Les applications web, les interfaces de services et l'automatisation ont ensuite rendu les logiciels, le stockage et la capacité de calcul disponibles à la demande.

Le cloud computing n'a ni inventeur unique ni date de lancement universelle. Les services commerciaux apparus à la fin des années 1990 et dans les années 2000 ont réuni des idées développées par des chercheurs, des ingénieurs, des éditeurs de logiciels et des fournisseurs d'infrastructure. Comprendre ces contributions permet de mieux retracer cette histoire que de choisir une seule entreprise comme point de départ.

L'histoire du cloud computing en un tableau

Ces repères montrent ce qui a changé pour les utilisateurs à chaque étape. Les périodes se chevauchent : une nouvelle approche pouvait élargir les possibilités pendant que les systèmes antérieurs continuaient de fonctionner.

Années 1960 : le temps partagé rend l'informatique interactive accessible à plusieurs utilisateurs

Les premiers grands systèmes traitaient souvent les tâches par lots. Un utilisateur soumettait un programme et ses données, puis attendait le résultat. L'accès à un ordinateur coûteux s'organisait autour d'une file d'attente, avec peu de possibilités d'ajuster un programme pendant son exécution.

Le temps partagé répartissait le temps processeur assez rapidement pour permettre à plusieurs personnes de travailler de manière interactive. Le Compatible Time-Sharing System du MIT, ou CTSS, a été présenté en 1961. Son exploitation ultérieure comprenait un accès distant par terminaux et connexions téléphoniques. Le projet MAC a élargi les travaux sur l'informatique interactive au cours des années 1960.

La conception de Multics a commencé en 1964. Dans leur bilan des sept premières années du projet, ses développeurs décrivaient un service informatique offrant un accès distant pratique, un fonctionnement continu et une capacité pouvant augmenter. Ces objectifs montrent que les chercheurs envisageaient déjà l'informatique comme un service disponible dans la durée.

Le temps partagé a établi un accès interactif et collectif à la capacité de calcul. Les services cloud modernes ont ajouté une autre combinaison de mutualisation, de provisionnement automatisé, d'élasticité et d'interfaces standardisées. Présenter CTSS comme un précurseur permet de conserver cette distinction sans minimiser sa contribution.

Années 1960–1970 : la virtualisation sépare une machine de son matériel

La virtualisation permet à un ordinateur physique d'héberger plusieurs machines virtuelles, chacune avec son propre environnement d'exploitation. Une couche de contrôle répartit l'accès au processeur, à la mémoire et aux autres ressources. Les utilisateurs disposent d'une machine logique sans qu'un système physique distinct soit nécessaire pour chaque charge de travail.

Les travaux d'IBM sur les machines virtuelles comprenaient CP-40 et CP-67 dans les années 1960. L'entreprise a annoncé VM/370 le 2 août 1972, intégrant ces idées dans un produit officiel pour le System/370.

Cette séparation est devenue un fondement important de l'infrastructure cloud. Un fournisseur pouvait attribuer des machines virtuelles à partir d'un ensemble de ressources matérielles, tandis que les clients installaient leurs logiciels dans leurs propres environnements. La capacité physique devait toujours exister et l'isolation dépendait de la mise en œuvre.

Un centre de données virtualisé ne fournit pas automatiquement des services cloud. Le libre-service, le provisionnement, la mesure des usages et la gestion des ressources nécessitent des systèmes supplémentaires. Les fournisseurs cloud peuvent également proposer des serveurs physiques dédiés en complément des machines virtuelles.

1969–années 1990 : les réseaux donnent accès aux ressources distantes

L'informatique partagée est devenue plus utile à mesure que les utilisateurs pouvaient y accéder depuis des lieux plus éloignés. La DARPA situe le premier signal entre deux ordinateurs sur ARPANET en octobre 1969. Ce réseau initial de quatre nœuds a constitué une étape importante du développement d'internet ; son passage à TCP/IP en 1983 a contribué à relier différents réseaux.

L'accès commercial à internet et le web ont ensuite élargi le public des applications distantes. Les navigateurs offraient un moyen commun d'interagir avec les services, tandis que les interfaces web permettaient aux logiciels de différents systèmes de communiquer. Les organisations pouvaient fournir des applications sans installer l'ensemble du logiciel sur chaque appareil.

Les réseaux ont aussi permis le développement de l'informatique distribuée, dans laquelle des composants se coordonnent sur plusieurs machines. Cette approche architecturale recoupe le cloud computing, mais les deux termes décrivent des réalités différentes. Notre guide sur le fonctionnement du traitement distribué explique comment les machines répartissent et coordonnent le travail.

Les clusters et les grilles de calcul se développent en parallèle du web

Les réseaux permettaient aussi aux organisations de réunir des ressources informatiques pour des travaux importants. Les clusters coordonnaient un groupe de machines, tandis que les grilles de calcul reliaient des ressources au-delà des frontières d'une organisation. Le Globus Toolkit permettait de construire des infrastructures de grille et de calcul haute performance, notamment pour des environnements de recherche exploités par les institutions elles-mêmes.

Les grilles de calcul et les services cloud partagent le principe de mutualisation des ressources, mais les modalités d'accès, de propriété et d'exploitation peuvent différer. Les grilles de recherche ont constitué une branche du développement de l'informatique en réseau. Elles n'ont pas simplement disparu avec l'arrivée des plateformes cloud commerciales.

Années 1990–2000 : les logiciels hébergés familiarisent les utilisateurs avec les services en ligne

L'hébergement web et les applications professionnelles exploitées à distance ont contribué à établir l'intérêt commercial du logiciel fourni comme un service. Les clients utilisaient une application en ligne pendant que son fournisseur gérait les serveurs et les mises à jour. Selon les services, la facturation reposait sur un abonnement, sur l'usage ou sur d'autres modalités.

Salesforce constitue un repère utile dans cette évolution. Selon son histoire officielle, l'entreprise a été constituée en mars 1999 et son lancement officiel a eu lieu en février 2000. Son logiciel de gestion de la relation client accessible sur le web a contribué à populariser le logiciel en tant que service, ou SaaS. La date de création de l'entreprise ne doit pas être confondue avec celle de son lancement public, ni présentée comme l'invention de tous les logiciels hébergés.

Le changement concernait à la fois la fourniture du logiciel et la répartition des responsabilités. Les utilisateurs s'attendaient de plus en plus à ouvrir une application pour travailler, tandis que le fournisseur entretenait son environnement d'exploitation. Les services d'infrastructure allaient étendre une approche comparable aux développeurs ayant besoin de ressources pour leurs propres logiciels.

2006 : le stockage et le calcul deviennent une infrastructure programmable

Amazon a présenté Simple Storage Service, ou S3, en mars 2006. Le service proposait une interface pour stocker et récupérer des données sans acheter le matériel de stockage sous-jacent. En août, Amazon a ouvert EC2 à des tests en version bêta limitée, donnant aux développeurs accès à une capacité de calcul virtuelle.

Ces lancements ont marqué des étapes importantes pour l'infrastructure en tant que service, ou IaaS. Les développeurs pouvaient demander des ressources par des interfaces de services et intégrer le provisionnement à leurs processus logiciels. Le fournisseur prenait en charge l'infrastructure physique ; les clients conservaient la maîtrise de leurs systèmes d'exploitation et de leurs applications.

Une équipe pouvait, par exemple, créer un environnement de test pour une version de son application, l'utiliser, puis le supprimer. Le faire de manière fiable nécessitait toujours de la configuration et de l'automatisation, mais ne dépendait plus de l'achat d'un serveur dédié à chaque environnement.

L'importance de 2006 tient à l'accessibilité commerciale d'une infrastructure programmable. Le temps partagé, la virtualisation, les réseaux et les applications hébergées existaient déjà. AWS a réuni de telles idées dans des services qui ont contribué à établir le cloud public moderne.

À partir de 2008 : les plateformes prennent en charge davantage d'opérations applicatives

Google App Engine a été lancé en 2008 comme plateforme applicative gérée. Les développeurs déployaient leurs applications dans un environnement pris en charge, tandis que Google exploitait l'environnement d'exécution et les services associés.

Cet exemple illustre la plateforme en tant que service, ou PaaS. Avec l'IaaS, une équipe peut gérer une machine virtuelle et son système d'exploitation. Avec le PaaS, elle déploie son code dans les limites des langages, bibliothèques et modalités d'exécution pris en charge. Le fournisseur assume davantage de tâches opérationnelles, et le développeur accepte les contraintes de la plateforme.

Microsoft a ajouté une autre plateforme importante lorsque Windows Azure est devenu disponible commercialement en février 2010. Son arrivée illustre le développement parallèle de différentes plateformes par les fournisseurs cloud, plutôt qu'une succession universelle de lancements de produits.

L'IaaS, le PaaS et le SaaS se sont développés en parallèle. Ils répondent à des besoins différents : la croissance des plateformes gérées n'a donc pas rendu les services d'infrastructure obsolètes. Une entreprise peut utiliser du SaaS pour collaborer, une plateforme gérée pour une application et des machines virtuelles pour des logiciels nécessitant davantage de contrôle.

2011 : le NIST définit les caractéristiques du cloud computing

En septembre 2011, le National Institute of Standards and Technology des États-Unis a publié la publication spéciale 800-145. Sa définition a fourni aux organisations une référence commune pour distinguer le cloud computing d'un simple hébergement distant.

Le NIST a retenu cinq caractéristiques essentielles :

• Libre-service à la demande : les utilisateurs obtiennent des capacités sans qu'un employé du fournisseur traite chaque demande.
• Accès étendu par le réseau : des mécanismes standard permettent d'accéder aux services depuis différents types d'appareils.
• Mutualisation des ressources : un ensemble de ressources sert plusieurs utilisateurs et peut être réaffecté.
• Élasticité rapide : la capacité peut augmenter ou diminuer avec la demande, parfois automatiquement.
• Service mesuré : l'utilisation des ressources fait l'objet d'un suivi, de contrôles et de rapports.

La publication décrivait également l'IaaS, le PaaS et le SaaS, ainsi que les modèles de déploiement privé, communautaire, public et hybride. Elle documentait un ensemble d'idées existantes plutôt que le lancement d'un nouveau service.

Cette distinction reste utile : un serveur distant ne démontre pas à lui seul les cinq caractéristiques. Un cloud privé peut aussi les proposer sans fournir de services sur l'internet public. La mesure de l'usage facilite la visibilité et la facturation, mais tous les services cloud n'emploient pas la même unité de facturation ni le même abonnement.

Années 2010 : les conteneurs et l'orchestration changent le déploiement des applications

Les conteneurs regroupent les applications et leurs dépendances dans des unités exécutables dans des environnements compatibles. Ils partagent généralement le noyau du système d'exploitation hôte, tandis qu'une machine virtuelle dispose d'un système d'exploitation invité distinct.

Les conteneurs existaient avant Docker, mais Docker a rendu leur création et leur exécution plus accessibles aux développeurs. Sa première démonstration publique a eu lieu en mars 2013. Regrouper un logiciel dans une image aidait les équipes à déplacer la même application entre le développement, les tests et la production, sous réserve de compatibilité et de configuration.

L'exploitation de nombreux conteneurs posait un problème de coordination : choisir où les exécuter, relier les services, ajuster la capacité et remplacer les instances défaillantes. Kubernetes est devenu un outil important pour ces opérations. Le premier commit du projet date de juin 2014 ; la version 1.0 est sortie en juillet 2015.

Les conteneurs et les machines virtuelles continuent de coexister. Une équipe peut exécuter des conteneurs sur des machines virtuelles, des serveurs physiques ou un service géré. L'orchestration automatise certaines opérations ; la conception de l'application détermine toujours si la mise à l'échelle et la reprise fonctionnent comme prévu.

Années 2010 : le serverless et les services gérés déplacent les responsabilités

Les fournisseurs cloud ont également développé des services qui prennent en charge davantage de gestion de l'infrastructure à la place des équipes applicatives. Les bases de données, files de messages, services de stockage et outils d'analyse gérés proposent des fonctions sans demander aux clients d'exploiter eux-mêmes chaque composant.

AWS a présenté Lambda en version préliminaire en novembre 2014. Les développeurs fournissaient des fonctions exécutées en réponse à des événements, tandis que le service gérait les ressources de calcul. Ce modèle est devenu un exemple important du serverless.

Les services serverless utilisent toujours des serveurs. Ce qui change, c'est la responsabilité du client dans leur provisionnement et leur maintenance. Les équipes continuent de gérer la logique applicative, les autorisations, les données, les dépendances et les conséquences des limites du service. Les fonctions représentent une forme de serverless ; le terme désigne également d'autres capacités gérées.

Il n'existe pas de progression universelle qui conduirait toutes les charges de travail de l'IaaS au PaaS puis au serverless. Une prise en charge accrue par le fournisseur peut réduire les tâches opérationnelles tout en imposant des contraintes d'exécution, de configuration ou de portabilité. Le développement du cloud computing a élargi ces choix.

Années 2020 : l'infrastructure cloud couvre davantage de lieux et de charges de travail

Les services cloud actuels combinent plusieurs approches de déploiement. Des clouds publics et privés peuvent être reliés dans une architecture hybride, tandis que le multicloud désigne l'utilisation de plusieurs fournisseurs. L'edge computing place certains traitements au plus près des appareils ou des utilisateurs. Les infrastructures distribuées coordonnent des ressources situées dans plusieurs lieux.

Ces configurations changent l'emplacement du travail et la gestion des systèmes. Elles ne suppriment pas le besoin de processeurs, de stockage, de réseaux et d'électricité. Notre guide sur l'emplacement des données dans le cloud explique cette réalité physique.

L'intelligence artificielle a créé une demande supplémentaire pour des accélérateurs spécialisés et des services de modèles gérés. Une équipe peut obtenir une capacité GPU pour exécuter son propre logiciel ou appeler un service d'inférence géré par une API. Ces choix prolongent la distinction entre l'accès à une infrastructure et l'utilisation d'une fonction plus élaborée. L'historique des services d'AWS retrace, par exemple, le développement du machine learning géré, des puces dédiées à l'IA et des services de modèles.

Aucune architecture physique unique ne définit tous les services cloud. Des installations centralisées, des ressources régionales et des sites en périphérie peuvent servir des charges de travail différentes. Leur coexistence explique mieux la diversité actuelle qu'une prédiction selon laquelle une approche devrait remplacer toutes les autres.

Questions sur les origines du cloud computing

Qui a inventé le cloud computing ?

Aucune personne ni entreprise n'a inventé l'ensemble du modèle. Chercheurs en temps partagé, ingénieurs en virtualisation, équipes réseau, éditeurs de logiciels hébergés, fournisseurs d'infrastructure et organismes de normalisation ont apporté des éléments différents. Leurs contributions se sont accumulées sur plusieurs décennies.

Quand le cloud computing a-t-il commencé ?

Ses racines techniques comprennent le temps partagé des années 1960 et la virtualisation des grands systèmes. Les services commerciaux de logiciels en ligne et d'infrastructure sont apparus plus tard. Les lancements de S3 et d'EC2 par Amazon en 2006 constituent des repères importants pour l'infrastructure, tandis que la publication du NIST de 2011 fournit une définition couramment utilisée. Chaque date répond à une question historique différente.

Quel a été le premier service cloud ?

Il n'existe pas de réponse universelle utile sans préciser le type de service. L'informatique distante partagée, les applications hébergées et l'infrastructure programmable ont des histoires différentes. Identifier un lancement documenté est plus précis que de déclarer un produit premier cloud de toutes les catégories.

L'origine du nom est-elle celle de la technologie ?

Non. Nommer un modèle de service et développer ses technologies sous-jacentes sont des événements distincts. Les affirmations sur la personne qui aurait créé l'expression « cloud computing » nécessitent leurs propres preuves historiques et ne permettent pas d'établir qui aurait inventé le modèle complet. Cette chronologie suit des systèmes, des services et des références documentés.

Quel a été le principal changement au fil du développement du cloud ?

Les utilisateurs ont obtenu davantage de moyens d'accéder à des ressources partagées, d'automatiser leur provisionnement et de confier des tâches opérationnelles à un fournisseur. Les techniques antérieures restent présentes sous les services plus récents. Pour évaluer un service cloud aujourd'hui, les questions utiles concernent les ressources fournies, leur emplacement et les responsabilités qui restent à la charge du client.