Cloud computing — définition et différences entre IaaS, PaaS et SaaS

Le cloud computing n'est pas un lieu, mais une façon de répartir le travail. Quand une entreprise « passe au cloud », elle ne confie pas son serveur aux nuages — elle délègue à un fournisseur une partie des couches qu'elle gérait elle-même : matériel, système d'exploitation, base de données, parfois l'application entière. Elle reste responsable du reste.

La définition la plus utile vient de l'institut américain de normalisation NIST, référence du secteur depuis 2011 : « a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction » — soit un modèle permettant un accès réseau omniprésent, pratique et à la demande à un ensemble mutualisé de ressources informatiques configurables (réseaux, serveurs, stockage, applications, services), pouvant être rapidement mises à disposition puis libérées avec un effort de gestion minimal (NIST SP 800-145, traduction libre — le NIST ne publie pas de version française).

En français, on parle aussi d'« informatique en nuage », ou simplement de « cloud ». Cet article détaille ce que recouvre cette définition, en quoi l'IaaS, le PaaS et le SaaS diffèrent, quels sont les types de cloud et ce que les entreprises utilisent réellement en Europe.

Qu'est-ce que le cloud computing ?

La définition du NIST repose sur cinq caractéristiques. Si un service ne les réunit pas toutes, ce n'est pas du cloud — c'est un simple serveur distant dans la salle informatique de quelqu'un d'autre, ce qui n'est pas mauvais en soi, mais fonctionne différemment.

1. Libre-service à la demande. Vous commandez vous-même les ressources — puissance de calcul, espace de stockage — depuis un tableau de bord ou une API, sans passer par un commercial ni attendre un technicien. Un nouveau serveur est prêt en quelques minutes, pas en quelques semaines.

2. Accès réseau étendu. Le service est accessible par le réseau, avec des outils standards — navigateur, téléphone, ordinateur portable — pas uniquement depuis un bureau.

3. Mutualisation des ressources. Le fournisseur sert de nombreux clients sur la même infrastructure sous-jacente et leur alloue des ressources dynamiquement. Le client ne sait généralement pas sur quel serveur précis tourne sa charge de travail — tout au plus dans quelle région ou quel centre de données.

4. Élasticité rapide. Les ressources peuvent être ajoutées rapidement, et libérées tout aussi vite, parfois automatiquement. Du point de vue du client, elles paraissent illimitées.

5. Service mesuré. L'usage est mesuré et facturé — vous payez ce que vous consommez réellement : heures de serveur, gigaoctets de données, nombre d'utilisateurs.

Cette dernière caractéristique change le plus les choses pour une entreprise : l'achat ponctuel de matériel devient une facture mensuelle qui varie avec l'usage. C'est un avantage en cas de charge variable, un inconvénient quand la charge est stable et prévisible — la facture cumulée peut alors dépasser le coût du matériel possédé en propre. Nous y revenons plus loin.

IaaS, PaaS et SaaS — les trois modèles de services cloud

Le NIST distingue trois modèles de services. La façon la plus simple de les différencier : quelles couches maintenez-vous, et lesquelles le fournisseur maintient-il ?

IaaS — infrastructure as a service. Le fournisseur vous donne des ressources « brutes » : puissance de calcul, stockage, réseau. Le client peut y déployer n'importe quel logiciel, y compris systèmes d'exploitation et applications. Vous ne gérez pas l'infrastructure physique, mais gérez le système d'exploitation, les données et tout ce qui tourne dessus. Exemple familier : un VPS loué, ou une machine virtuelle chez AWS, Azure ou Google Cloud. Le serveur est prêt en quelques minutes, mais mises à jour, correctifs et sauvegardes restent à votre charge.

PaaS — platform as a service. Le fournisseur maintient aussi le système d'exploitation et l'environnement d'exécution. Vous déployez votre application — dans les langages que la plateforme prend en charge — et en configurez les réglages. Fini les correctifs système et le dimensionnement des serveurs, mais vous acceptez les contraintes de la plateforme : ses versions de langages, sa base de données, sa façon de déployer le code.

Deux notions que tout développeur évoque en parlant de cloud méritent mention, bien que la définition du NIST, datée de 2011, ne les connaisse pas. Le serverless, et en particulier les fonctions en tant que service (FaaS), poussent cette frontière plus loin. Selon la CNCF, le serverless consiste à construire et exécuter des applications sans gérer de serveurs : l'application, découpée en fonctions, est déployée puis exécutée, dimensionnée et facturée selon la demande (CNCF). Vous ne maintenez alors même plus une application qui tourne en permanence, seulement des fonctions que le fournisseur déclenche à chaque événement — ainsi AWS décrit son service Lambda : du code exécuté sans provisionner ni gérer de serveurs (AWS Lambda). Les conteneurs en tant que service se situent de l'autre côté : vous fournissez un conteneur prêt à l'emploi, le fournisseur l'exécute et le dimensionne. Les deux restent dans la logique du PaaS.

SaaS — software as a service (logiciel en tant que service). Le fournisseur maintient tout : infrastructure, plateforme et application elle-même. Vous utilisez un programme prêt à l'emploi via un navigateur ou une application, et configurez tout au plus les réglages accessibles aux utilisateurs. Messagerie dans le navigateur, suite bureautique en ligne, logiciel de facturation, CRM — tout cela relève du SaaS. Nous détaillons le modèle SaaS lui-même, ses avantages et ses limites, dans notre guide du SaaS.

Exemples de cloud computing dans chaque modèle

Les modèles se reconnaissent plus facilement à travers des services que la plupart des entreprises ont déjà croisés :

• IaaS — machines virtuelles : Amazon EC2, Azure Virtual Machines, Google Compute Engine, ainsi que les serveurs privés virtuels (VPS) vendus par les hébergeurs. Vous recevez un système d'exploitation à administrer vous-même.
• PaaS — plateformes d'exécution : Azure App Service, Google App Engine, bases de données managées comme Amazon RDS. Vous déployez du code ou des données ; le fournisseur maintient le reste.
• Serverless et conteneurs — AWS Lambda et Google Cloud Run : fonctions ou conteneurs exécutés à la demande.
• SaaS — Microsoft 365, Google Workspace, comptabilité et facturation en ligne, CRM. Vous vous connectez et travaillez.

Une même entreprise utilise généralement les trois modèles à la fois, souvent sans s'en rendre compte : la messagerie en SaaS, un site sur un serveur virtuel, et un logiciel de gestion des stocks chez un fournisseur qui, lui-même, l'exécute dans le cloud de quelqu'un d'autre.

Ces trois modèles forment un escalier. Plus on monte, moins il vous reste de travail — et moins vous avez de liberté : en IaaS, vous pouvez installer ce que vous voulez ; en SaaS, vous utilisez exactement ce que le fournisseur a construit.

La dernière ligne de ce schéma compte le plus, et c'est celle qu'on oublie le plus souvent. Dans chaque modèle — y compris en SaaS — les données, les comptes et l'accès restent toujours à la charge du client. AWS distingue ce qu'il appelle security of the cloud — l'infrastructure, sa responsabilité — de security in the cloud — ce que le client y installe (la page française d'AWS brouille cette distinction en traduisant les deux par « sécurité dans le cloud » ; nous gardons donc les termes anglais) (AWS), et Microsoft précise que la répartition varie selon que la charge tourne en SaaS, PaaS, IaaS ou dans votre propre centre de données (Microsoft Learn). Nous détaillons ce que cela signifie concrètement dans notre article sur la sécurité du cloud.

Cloud public, privé et hybride — les types de cloud computing

La deuxième distinction ne porte pas sur ce que vous achetez, mais sur où et avec qui vous partagez l'infrastructure. Le NIST décrit quatre modèles de déploiement.

Cloud public — l'infrastructure d'un fournisseur, mise à disposition de tous. C'est AWS, Microsoft Azure, Google Cloud, mais aussi des fournisseurs de serveurs virtuels plus modestes. Vous payez à l'usage, vous n'achetez pas de matériel, et vous partagez les ressources physiques avec d'autres clients (dans des environnements logiquement séparés).

Cloud privé — une infrastructure réservée à une seule organisation. Elle peut se trouver dans son propre centre de données ou chez un fournisseur, mais n'est partagée avec personne d'autre. Elle offre un contrôle total, au prix d'une maintenance interne — et l'élasticité s'arrête au matériel acheté.

Cloud hybride — la combinaison de deux modèles ou plus, qui restent distincts mais sont reliés de façon à ce que les données et les applications puissent circuler entre eux. Configuration typique : données sensibles et charge stable dans un cloud privé, pics de trafic et services annexes dans le cloud public.

Cloud communautaire — une infrastructure partagée par un groupe d'organisations aux besoins communs, par exemple des institutions d'un même secteur. C'est, en pratique, le plus rare pour une entreprise.

Cloud public ou privé ? Pour une PME, la réponse est presque toujours : public — et le plus souvent en SaaS ou en PaaS. Le cloud privé a du sens quand la réglementation ou des contrats exigent une séparation physique des données, ou quand une charge stable et importante rend une infrastructure propre moins coûteuse qu'une location.

Comment les entreprises utilisent le cloud en Europe

Eurostat mesure chaque année, dans son enquête sur l'usage des technologies dans les entreprises, ce qu'elles achètent réellement comme services cloud. La dernière vague porte sur 2025 et sur les entreprises d'au moins 10 salariés (Eurostat, isoc_cicce_use) — un instrument européen qui ne couvre pas la Suisse, et il n'existe pas de statistique officielle suisse strictement comparable.

À titre d'illustration du mécanisme, les chiffres européens de 2025 : 52,7 % des entreprises de l'UE achetaient un service cloud payant, avec une adoption qui augmente avec la taille — de 49,3 % parmi les petites entreprises (10 à 49 salariés) à 66,8 % parmi les moyennes (50 à 249) et 84,7 % parmi les grandes (250 et plus).

Le détail par usage est plus parlant encore que le chiffre global :

Le schéma qui s'en dégage est net : les entreprises adoptent le cloud d'abord par des catégories SaaS génériques — messagerie et bureautique —, bien avant d'y déplacer leurs propres systèmes. L'hébergement de bases de données est acheté par à peine plus de la moitié des entreprises qui achètent une messagerie, et la puissance de calcul pour des applications propres par environ un tiers seulement.

Une réserve de lecture : Eurostat mesure la part d'entreprises qui achètent un service donné, pas l'intensité de son usage. Une entreprise avec une seule boîte mail dans le cloud compte de la même façon qu'une entreprise qui y a tout transféré.

Quand le cloud a du sens pour une entreprise, et quand ce n'est pas le cas

Le cloud n'est ni moins cher ni plus sûr par définition. Il est plus pratique dans certaines situations, et plus coûteux dans d'autres.

Cela a du sens quand :

• la charge varie — boutique saisonnière, campagne, système utilisé intensivement quelques jours par mois ;
• vous n'avez pas d'administrateur — le SaaS et le PaaS déchargent l'entreprise des mises à jour et du remplacement du matériel ;
• vous avez besoin de rapidité — un nouvel environnement en minutes plutôt qu'en semaines ;
• l'équipe travaille depuis plusieurs sites — l'accès réseau est une caractéristique du modèle, pas une option.

Cela demande de la prudence quand :

• la charge est stable et importante — une facture mensuelle, cumulée sur plusieurs années, peut dépasser le coût du matériel possédé en propre ;
• vous dépendez d'un seul fournisseur — plus vous utilisez de services propres à une plateforme, plus il est difficile d'en partir. Mieux vaut savoir dès le départ dans quel format vous récupéreriez vos données ;
• la réglementation ou des contrats exigent que les données restent à un endroit précis — le choix de la région cesse alors d'être une question purement technique.

Prenons notre propre cas. Ce site ne tourne pas sur une plateforme managée : il tourne sur un serveur privé virtuel loué, avec Coolify — de l'IaaS, sur lequel nous avons construit une couche qui ressemble à du PaaS. La facture, et trois choses qui tournent mal dans une telle configuration, sont décrites dans notre article sur l'auto-hébergement de Next.js et Payload. Nous avons fait ce choix délibérément : charge stable, contrôle total sur la base de données et les coûts. Mais cette décision a un prix qu'il vaut mieux connaître avant de la prendre : chaque couche, à part le matériel, est restée à notre charge. Nous l'avons appris à nos dépens quand le redémarrage d'un conteneur a effacé les fichiers d'une de nos collections, parce que le système de fichiers d'un conteneur est éphémère et que personne n'avait configuré de volume persistant. Sur une plateforme PaaS, cette erreur n'aurait pas pu se produire ; en IaaS, c'est notre responsabilité, exactement comme le montre le schéma plus haut.

Si vous hésitez entre acheter un logiciel prêt à l'emploi dans le cloud ou en construire un vous-même, c'est une décision distincte — nous la détaillons dans notre article sur le logiciel sur mesure.

Par où commencer pour migrer son entreprise vers le cloud

Si votre entreprise fait ses premiers pas dans le cloud, les données européennes suggèrent un ordre naturel : d'abord les services que la plupart des entreprises ont déjà adoptés, puis — s'il y a une raison de le faire — vos propres systèmes.

1. Faites l'inventaire. Listez les systèmes utilisés : messagerie, documents, comptabilité, ventes, stock, site web. Notez pour chacun qui l'utilise et quelles données il contient.

2. Commencez par le SaaS évident. Messagerie, bureautique et fichiers partagés sont les catégories les plus adoptées, et celles où le risque de migration est le plus faible — pas de changement de processus, seulement une migration et une formation.

3. Classez vos données. Données personnelles, données financières, secrets d'affaires — chaque catégorie a ses exigences de lieu de stockage et de contrat avec le fournisseur.

4. Planifiez votre sortie avant de signer. Demandez dans quel format et dans quel délai le fournisseur restituera vos données en cas de résiliation — la question qui détermine si vous pourrez changer de fournisseur dans trois ans.

5. Ne migrez vos propres systèmes que pour une bonne raison. Une base de données migrée « parce que tout le monde le fait » coûte souvent plus cher que sur votre propre serveur, sans que les problèmes de performance ne disparaissent.

Sécurité des données dans le cloud

« Le cloud est-il sûr ? » revient dans chaque projet de migration — et c'est la mauvaise question. Les grands fournisseurs protègent mieux leur infrastructure que ne le feraient la plupart des entreprises dans leur propre salle serveur. Mais les données, les comptes et l'accès restent toujours à la charge du client, tout comme le contrat avec le fournisseur, le lieu de stockage des données et un plan pour le jour où quelque chose tourne mal. C'est le sujet d'un article à part : sécurité du cloud — qui est responsable de quoi, et que demander à votre fournisseur.

Et ensuite

Si vous voulez comprendre le modèle SaaS lui-même — celui sur lequel s'appuient la plupart des entreprises sans même y penser —, commencez par notre guide du SaaS. Si vous envisagez de construire votre propre produit selon ce modèle, consultez nos idées de micro-SaaS.