---
term: 'IaaS vs. PaaS vs. CaaS vs. FaaS vs. BaaS vs. mBaaS vs. SaaS'
seoTitle: 'IaaS vs PaaS vs CaaS vs FaaS vs BaaS vs mBaaS vs SaaS : guide complet'
headline: 'Modèles de service cloud comparés : IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS et SaaS'
slug: modeles-de-service-cloud
category: cloud-architecture
shortDefinition: 'Le spectre des modèles de service cloud est une échelle — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — classée selon ce que le fournisseur opère pour vous.'
relatedTerms:
  - infrastructure-as-a-service
  - paas-vs-baas
  - baas-vs-serverless
  - mbaas-vs-baas
  - baas-vs-custom-backend
  - serverless-architecture
  - containerization
contrastsWith:
  - paas-vs-baas
aboutTerms:
  - 'Infrastructure-as-a-Service (IaaS)'
  - 'Containers-as-a-Service (CaaS)'
  - 'Platform-as-a-Service (PaaS)'
  - 'Functions-as-a-Service (FaaS)'
  - 'Backend-as-a-Service (BaaS)'
  - 'Mobile Backend-as-a-Service (mBaaS)'
  - 'Software-as-a-Service (SaaS)'
faq:
  - question: 'Quelle est la différence principale entre IaaS, PaaS et SaaS ?'
    answer: 'Qui gère quoi. IaaS loue de l''infrastructure — machines virtuelles, stockage, réseaux — et tout ce qui se trouve au-dessus du système d''exploitation vous revient. PaaS loue une plateforme gérée : vous apportez le code applicatif et les données, le fournisseur opère le reste. SaaS livre un logiciel fini que vous utilisez, tout simplement. Chaque échelon gravi échange du contrôle contre de la vitesse et une charge opérationnelle réduite.'
  - question: 'Où se placent CaaS, FaaS et BaaS entre IaaS et SaaS ?'
    answer: 'Sur les échelons que le trio classique saute. Le CaaS se situe entre IaaS et PaaS : vous livrez des conteneurs, le fournisseur opère l''orchestration. Le FaaS se situe au-dessus du PaaS : vous livrez des fonctions individuelles exécutées par événement. Le BaaS va le plus loin tout en restant programmable : le backend lui-même — base de données, auth, stockage, API — arrive pré-construit, si bien que les fonctionnalités standard n''exigent aucun code côté serveur.'
  - question: 'BaaS signifie-t-il Backend-as-a-Service ou Backup-as-a-Service ?'
    answer: 'En développement d''applications, BaaS signifie presque toujours Backend-as-a-Service — un backend pré-construit consommé via des SDK. Une minorité de contextes de stockage d''entreprise utilise le même sigle pour Backup-as-a-Service, sans aucun rapport : des sauvegardes de données gérées. Si la discussion porte sur des apps mobiles, des API ou des plateformes de développement, lisez BaaS comme backend. Le contexte tranche ; cette page couvre le sens backend.'
  - question: 'Quelle est la différence entre CaaS et PaaS ?'
    answer: 'L''unité que vous remettez au fournisseur. Sur un CaaS, vous remettez des conteneurs — n''importe quel langage, n''importe quel stack, empaquetés à votre façon — et vous gardez la main sur les choix d''orchestration. Sur un PaaS, vous remettez du code applicatif et acceptez les runtimes et conventions de la plateforme en échange d''un déploiement plus simple. Le CaaS convient aux microservices et aux stacks polyglottes ; le PaaS aux apps standard qui veulent le minimum de cérémonie.'
  - question: 'Le FaaS est-il la même chose que le serverless ?'
    answer: 'Le FaaS est une moitié du serverless, pas un synonyme. La définition canonique — de Mike Roberts sur martinfowler.com — traite le serverless comme un parapluie couvrant à la fois le FaaS (vos fonctions, exécutées à la demande) et le BaaS (des services backend pré-construits). Familièrement, "serverless" désigne souvent le seul FaaS, et c''est pour cela que les termes s''emmêlent.'
  - question: 'Quelle est la différence entre BaaS et mBaaS ?'
    answer: 'Le mBaaS est le point de départ de la catégorie — un backend pré-construit visant spécifiquement les apps mobiles, avec notifications push, SDK conscients de l''appareil et synchronisation offline en fonctionnalités de premier rang. Quand les apps web sont devenues client-first à leur tour, le modèle s''est généralisé et le m est tombé. Aujourd''hui, tout mBaaS sérieux sert aussi bien le web : les deux termes nomment en grande partie les mêmes plateformes, avec un accent différent.'
  - question: 'Quel modèle de service cloud est le moins cher ?'
    answer: 'Cela dépend de la forme de la charge de travail, pas du modèle. Le FaaS est le moins cher pour un trafic faible ou en pics parce que le coût à vide est nul, et cher sous forte charge soutenue. L''IaaS a le meilleur prix unitaire brut à grande échelle stable, mais porte le coût caché de l''équipe ops qui le fait tourner. CaaS, PaaS et BaaS se placent entre les deux, troquant une marge de plateforme contre du temps d''ingénierie éliminé — qui, pour les petites équipes, est généralement le coût dominant.'
  - question: 'Peut-on combiner plusieurs modèles de service ?'
    answer: 'Presque toutes les entreprises réelles le font. Un stack typique : du SaaS pour les outils métier, un BaaS ou un PaaS pour faire tourner le produit, du FaaS pour la glue événementielle, du CaaS pour les services conteneurisés qui exigent le contrôle de l''orchestration, et de l''IaaS pour la rare charge spécialisée. Les modèles sont des échelons où placer chaque charge individuellement — la compétence pratique consiste à apparier chaque charge avec son échelon suffisant le moins cher.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'As a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/As_a_service'
  - name: 'Kubernetes documentation — overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Commencez en haut de l''échelle'
  text: 'Back4app vous place sur l''échelon BaaS dès le premier jour — base de données, auth, stockage et API pré-construits, avec les fonctions Cloud Code quand vous avez aussi besoin de l''échelon FaaS. Bâti sur de l''open-source, pour que redescendre l''échelle reste possible.'
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-08'
translationKey: iaas-paas-baas-faas
---

**Le spectre des modèles de service cloud est une échelle — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — classée selon ce que le fournisseur opère pour vous.** Chaque "aaS" répond à la même question avec une ligne différente : *vous construisez au-dessus de cette ligne ; nous opérons en dessous.* La plupart des guides s'arrêtent au trio classique que la définition du NIST a formalisé — IaaS, PaaS, SaaS — et sautent les échelons où vivent réellement les produits modernes. Ce guide couvre les sept, définit chacun avec précision, puis compare les paires que l'on confond vraiment. Choisissez l'échelon, et vous avez choisi ce à quoi votre équipe passera sa vie.

## Points clés

| Question | Réponse |
| --- | --- |
| L'échelle en une ligne | IaaS : louer les machines · CaaS : louer l'orchestration · PaaS : louer la plateforme · FaaS : louer à l'exécution de fonction · BaaS : louer le backend · mBaaS : louer le backend mobile · SaaS : louer l'app finie |
| La vraie variable | Où passe la ligne vous-gérez / le-fournisseur-gère |
| L'unité que vous déployez | VM → conteneur → application → fonction → modèle de données → rien |
| Serverless ? | Le parapluie au-dessus du FaaS *et* du BaaS — pas un échelon à part |
| Lequel est le meilleur | Mauvaise question — appariez chaque charge avec son échelon suffisant le moins cher |
| La tendance | Chaque année, les équipes démarrent plus haut sur l'échelle |

## Ce que "lancer le backend" signifie à chaque échelon

```bash
# La même tâche — un backend qui sert des requêtes — échelon par échelon
# IaaS — vous recevez des machines :
$ ssh admin@vm-01              # puis : installer, configurer, patcher, mettre à l'échelle, surveiller…
# CaaS — vous recevez l'orchestration :
$ docker push registry/api:v1  # vos conteneurs ; leur scheduler, leur réseau, leur scaling
# PaaS — vous recevez une plateforme :
$ git push platform main       # votre code d'app ; leurs serveurs, runtime et scaling
# FaaS — vous recevez un runtime par événement :
$ deploy functions/api.js      # vos fonctions ; exécutées à la demande, à zéro au repos
# BaaS / mBaaS — vous recevez le backend lui-même :
#   rien à déployer — auth, base de données et API tournent déjà
# SaaS — vous recevez le produit fini :
#   rien à construire — connectez-vous et utilisez-le
```

L'échelon BaaS mérite une preuve, parce que "rien à déployer" sonne comme du marketing. Enregistrer une commande dans un backend de production — schéma, API, contrôle d'accès et mise à l'échelle côté fournisseur — tient en un seul appel client :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const order = new Parse.Object('Order');
order.set('total', 129.9);
order.set('status', 'paid');
await order.save(); // schema, API, auth, scaling: all the rungs below you
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var order = Order()
order.total = 129.9
order.status = "paid"
order.save { result in
  if case .success = result {
    print("saved — the platform ran every layer underneath")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val order = ParseObject("Order").apply {
  put("total", 129.9)
  put("status", "paid")
}
order.saveInBackground { e ->
  if (e == null) Log.d("Order", "saved — platform ran every layer underneath")
}
```

## Les sept modèles sur une même échelle

```mermaid
flowchart LR
  accTitle: L'échelle as-a-service à sept échelons
  accDescr: Huit marches depuis l'on-premises en passant par IaaS, CaaS, PaaS, FaaS et BaaS avec sa spécialisation mobile mBaaS, jusqu'au SaaS — chacune louant davantage au fournisseur ; les machines, l'orchestration des conteneurs, la plateforme, les fonctions exécutées à la demande, le backend et enfin l'application finie.
  A["On-premises"] --> B["IaaS<br/>louez les machines"]
  B --> C["CaaS<br/>louez l'orchestration"]
  C --> D["PaaS<br/>louez la plateforme"]
  D --> E["FaaS<br/>louez à l'exécution"]
  E --> F["BaaS · mBaaS<br/>louez le backend"]
  F --> G["SaaS<br/>louez l'app finie"]
```

La [définition du cloud computing du NIST](https://csrc.nist.gov/pubs/sp/800/145/final) a formalisé les trois échelons classiques en 2011 — IaaS ("provisionner du calcul, du stockage, des réseaux"), PaaS ("déployer des applications créées par le consommateur avec les outils supportés par le fournisseur"), SaaS ("utiliser les applications du fournisseur") — avant que CaaS, FaaS et BaaS n'existent en tant que catégories. Les nouveaux échelons s'insèrent dans les vides laissés par le NIST : le CaaS entre IaaS et PaaS, le FaaS et le BaaS entre PaaS et SaaS — toujours programmables, mais avec une part de plus en plus mince du programme qui vous appartient.

## Qui gère quoi : la matrice des responsabilités

Tout le sujet en une table. Lisez une colonne de haut en bas pour voir ce qu'un modèle laisse dans votre assiette :

| Couche | On-prem | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Logique métier | Vous | Vous | Vous | Vous | Vous (en fonctions) | Seulement la logique sur mesure | Fournisseur |
| Fonctionnalités backend (auth, CRUD, stockage, push) | Vous | Vous | Vous | Vous | Vous | **Fournisseur** | Fournisseur |
| Empaquetage de l'app et runtime | Vous | Vous | Vous (conteneurs) | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Orchestration et mise à l'échelle | Vous | Vous | **Fournisseur** | Fournisseur | Fournisseur (à zéro) | Fournisseur | Fournisseur |
| OS et patchs | Vous | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Serveurs, réseau, matériel | Vous | **Fournisseur** | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Vos données et votre politique d'accès | Vous | Vous | Vous | Vous | Vous | Vous | **Toujours vous** |

Deux choses que la matrice rend visibles et que la prose cache d'habitude : la ligne du bas ne se transfère jamais — vos données et vos pratiques d'identité restent les vôtres à tous les échelons, même en SaaS — et le nom de chaque modèle n'est que la couche la plus haute où commence "Fournisseur".

## Qu'est-ce que l'IaaS (Infrastructure-as-a-Service) ?

L'IaaS loue de l'infrastructure virtualisée — machines, stockage en mode bloc, réseaux — à l'heure. Tout ce qui se trouve au-dessus de l'hyperviseur vous appartient : système d'exploitation, patchs, runtime, logique de mise à l'échelle et l'astreinte de 3 h du matin. C'est l'échelon du contrôle maximal et de la surface opérationnelle maximale, couvert en profondeur dans l'[entrée IaaS](/glossary/fr/infrastructure-en-tant-que-service/).

| | Profil IaaS |
| --- | --- |
| Vous déployez | Des machines virtuelles et tout ce qui tourne dessus |
| Le fournisseur opère | Matériel physique, virtualisation, réseau |
| Forme du pricing | Par ressource-heure, utilisée ou à vide |
| Choisissez-le quand | Matériel/runtimes spéciaux, contrôle strict de l'infrastructure, lift-and-shift |
| Éloignez-vous quand | La masse salariale ops coûte plus cher que ne vaut le contrôle |

À quoi ressemble le jour deux, voilà le test honnête de l'échelon. Sur IaaS, le jour deux, ce sont des fenêtres de patch de l'OS, des upgrades de kernel, des alarmes de disque plein, des audits de groupes de sécurité, de la planification de capacité et la construction du monitoring que chaque échelon supérieur inclut gratuitement. Rien de tout cela n'est votre produit. L'échelon gagne sa place dans exactement trois situations : du matériel ou des runtimes qu'aucune plateforme n'offre, des régimes de conformité qui imposent le contrôle de l'infrastructure, et une échelle soutenue assez grande pour que le prix unitaire brut batte les marges gérées *après* avoir compté l'équipe qui l'opère — une barre bien plus haute que la plupart des équipes ne l'imaginent.

## Qu'est-ce que le CaaS (Containers-as-a-Service) ?

Le CaaS loue la couche que la plupart des guides sautent : vous empaquetez vos services en [conteneurs](/glossary/fr/conteneurisation/) — n'importe quel langage, n'importe quel stack — et le fournisseur opère le scheduler, le réseau inter-services et la machinerie de mise à l'échelle, typiquement [Kubernetes](/glossary/fr/kubernetes/) ou un équivalent. Il se place délibérément entre IaaS et PaaS : plus abstrait que des machines, moins opinioné qu'une plateforme. Cela en fait le foyer naturel des [microservices](/glossary/fr/microservices-vs-monolithe/) et des parcs polyglottes qui se heurteraient aux conventions d'un PaaS.

| | Profil CaaS |
| --- | --- |
| Vous déployez | Des images de conteneur, des manifestes de déploiement |
| Le fournisseur opère | Le control plane d'orchestration, les nœuds, le réseau |
| Forme du pricing | Par nœud/cluster ou par conteneur en exécution |
| Choisissez-le quand | Microservices, stacks polyglottes, contrôle de l'orchestration sans opérer le cluster |
| Éloignez-vous quand | Une seule app standard — un PaaS ou un BaaS, c'est moins de machinerie pour le même résultat |

La subtilité qui sépare le CaaS d'un tutoriel [Kubernetes](/glossary/fr/kubernetes/) hébergé : ce qui se transfère, c'est le *control plane* — schedulers, etcd, API servers, santé des nœuds — tandis que tout ce qui s'exprime en images et en manifestes reste à vous : hygiène des images de base, resource requests, liveness probes, stratégie de déploiement, topologie des services. C'est une vraie discipline, et c'est précisément pour cela que l'échelon existe en offre à part entière : des équipes qui ont besoin de cette expressivité mais n'ont aucune envie d'opérer la machinerie sous-jacente. Le conteneur lui-même est l'argument de portabilité — la même image tourne sur tout orchestrateur conforme, ce qui maintient le CaaS parmi les échelons au plus faible lock-in de l'échelle.

## Qu'est-ce que le PaaS (Platform-as-a-Service) ?

Le PaaS loue une plateforme applicative gérée : vous poussez le code, le fournisseur met le runtime, la mise à l'échelle et le système d'exploitation en dessous. Le marché, c'est la convention contre la cérémonie — des langages supportés et des idiomes de plateforme en échange d'un déploiement en `git push`. Le point critique que le PaaS n'élimine *pas* : vous écrivez et possédez toujours toute l'application backend — auth, endpoints, validation, tout — une distinction que l'[entrée PaaS vs. BaaS](/glossary/fr/paas-vs-baas/) dissèque.

| | Profil PaaS |
| --- | --- |
| Vous déployez | Du code applicatif |
| Le fournisseur opère | Runtime, OS, serveurs, mise à l'échelle |
| Forme du pricing | Par instance/palier |
| Choisissez-le quand | Apps serveur sur mesure où la logique backend est le produit |
| Éloignez-vous quand | Vous écrivez des fonctionnalités standard qu'un BaaS livre déjà |

Le contrat PaaS a façonné une génération de bonnes habitudes — apps twelve-factor, configuration dans l'environnement, processus stateless, logs en flux — parce que la plateforme *impose* ce qui n'était auparavant qu'un conseil. Sa frontière est tout aussi instructive : la plateforme exécute votre application mais ne sait rien de ce qu'il y a dedans, si bien que chaque préoccupation backend — [sessions](/glossary/fr/gestion-des-sessions/), permissions, migrations, [rate limits](/glossary/fr/rate-limiting-api/) — reste du code que vous écrivez, testez et patchez. C'est le signe que vous êtes sur le mauvais échelon : si l'essentiel de votre code hébergé sur PaaS réimplémente les utilisateurs, le CRUD et l'upload de fichiers, vous construisez à la main l'échelon du dessus.

## Qu'est-ce que le FaaS (Functions-as-a-Service) ?

Le FaaS loue du calcul à l'événement : vous déployez des fonctions individuelles, le fournisseur exécute chaque invocation à la demande et redescend à zéro entre deux. C'est l'expression la plus pure du [calcul serverless](/glossary/fr/architecture-serverless/) — rien ne tourne, et rien n'est facturé, tant que rien ne se passe. Les coûts sont architecturaux : [cold starts](/glossary/fr/cold-starts-serverless/), limites d'exécution et une absence d'état qui pousse toute la persistance ailleurs. Comment les fonctions se comparent à l'exploitation de votre propre flotte de services, c'est la question [fonctions vs. microservices](/glossary/fr/fonctions-serverless-vs-microservices/).

| | Profil FaaS |
| --- | --- |
| Vous déployez | Des fonctions individuelles |
| Le fournisseur opère | Tout le reste, par invocation |
| Forme du pricing | Par invocation + temps d'exécution ; à vide = zéro |
| Choisissez-le quand | Travail événementiel : webhooks, jobs, pipelines, glue |
| Éloignez-vous quand | Forte charge soutenue — le prix par invocation s'inverse |

L'absence d'état est la contrainte porteuse : une fonction peut être détruite après n'importe quelle invocation, donc tout ce qui est durable — sessions, fichiers, files d'attente, données — doit vivre dans des services *autour* de la fonction. Poussée à sa conclusion, cette contrainte assemble silencieusement un BaaS : des fonctions pour la logique, des services gérés pour tout ce qui a un état. C'est pour cela que les deux échelons ont convergé en pratique, et que des runtimes open-source (Knative, OpenFaaS) existent pour les équipes qui veulent le modèle à l'événement sur leur propre orchestration. Le pricing suit la même logique événementielle — gratuit à vide est imbattable pour un trafic en pics et punitif pour une charge constante, l'inversion que toute facture FaaS finit par enseigner.

## Qu'est-ce que le BaaS (Backend-as-a-Service) ?

Le BaaS loue le backend lui-même. La base de données, l'[authentification](/glossary/fr/authentification-vs-autorisation/), le stockage de fichiers, les [API générées automatiquement](/glossary/fr/apis-generees-automatiquement/) et les notifications push arrivent pré-construits et gérés, consommés depuis des [SDK clients](/glossary/fr/sdk-backend/) — pour les fonctionnalités standard, il n'y a aucun code côté serveur à écrire, comme le démontre l'exemple de code ci-dessus. La logique sur mesure tourne dans des [cloud functions](/glossary/fr/cloud-code-fonctions-serverless/) embarquées, et c'est pourquoi les plateformes BaaS matures contiennent l'échelon FaaS au lieu de le concurrencer. La version construire-ou-acheter de cette décision a [sa propre entrée](/glossary/fr/baas-vs-backend-sur-mesure/), et la question du lock-in — la faiblesse honnête de l'échelon — dépend du fait que la plateforme soit [open-source ou propriétaire](/glossary/fr/baas-open-source-vs-proprietaire/).

| | Profil BaaS |
| --- | --- |
| Vous déployez | Un modèle de données, des règles de sécurité, des fonctions sur mesure — souvent rien d'autre |
| Le fournisseur opère | Tout le backend standard, derrière des SDK et des API |
| Forme du pricing | Palier gratuit + usage/plans |
| Choisissez-le quand | Backends d'app standard — utilisateurs, données, fichiers — et la vitesse compte |
| Éloignez-vous quand | La logique backend *est* le produit, ou les besoins sont loin du standard |

Ce que le BaaS élimine, c'est *l'infrastructure et le boilerplate*, pas l'ingénierie : votre [modèle de données](/glossary/fr/modelisation-de-donnees/), vos [règles de sécurité](/glossary/fr/listes-de-controle-d-acces-acl/) et votre logique métier restent des décisions qu'aucune plateforme ne prend à votre place. L'économie de l'échelon est la plus tranchante de l'échelle — quelques minutes jusqu'à un backend fonctionnel, un coût initial quasi nul — et son risque structurel l'est tout autant : sur une plateforme propriétaire, le schéma de données, l'auth et les fonctions vivent au format du fournisseur, ce qui fait du BaaS le lock-in le plus fort des échelons programmables. La variante open-source dissout exactement cela : quand la même plateforme s'auto-héberge, partir signifie déménager, pas réécrire. L'ère de l'IA a aussi élargi l'audience de l'échelon — les frontends générés ont besoin de vrais backends, vite, et un backend pré-construit et soumis à permissions est la forme qui convient.

## Qu'est-ce que le mBaaS (Mobile Backend-as-a-Service) ?

Le mBaaS est le point de départ de la catégorie BaaS : un backend pré-construit visant spécifiquement les apps mobiles, avec [notifications push](/glossary/fr/notifications-push/), SDK conscients de l'appareil et [synchronisation offline](/glossary/fr/synchronisation-offline-first/) en fonctionnalités de premier rang plutôt qu'en options. Quand les single-page apps web sont devenues client-first à leur tour, le modèle s'est généralisé et le *m* est tombé sans bruit — aujourd'hui, toute plateforme sérieuse sert le web et le mobile depuis le même backend. Quand la distinction compte encore — et quand elle n'est qu'un résidu historique — c'est le sujet de l'[entrée mBaaS vs. BaaS](/glossary/fr/mbaas-vs-baas/).

| | Profil mBaaS |
| --- | --- |
| Vous déployez | La même chose qu'en BaaS, via des SDK mobiles natifs |
| Le fournisseur opère | Le backend, plus la plomberie mobile : gateways de push, état par appareil, sync |
| Forme du pricing | Comme le BaaS |
| Choisissez-le quand | Produits mobile-first qui vivent du push, de l'offline et de l'état par appareil |
| Éloignez-vous quand | Jamais séparément du BaaS — c'est une spécialisation, pas un rival |

Le *m* gagne encore sa lettre à trois endroits. Les notifications push ne sont pas un appel d'API mais une relation avec les gateways des plateformes (APNs, FCM) — enregistrement des tokens, ciblage des appareils, sémantique de livraison — qu'une plateforme de calibre mBaaS gère de bout en bout. La synchronisation offline-first signifie que le SDK est une machine à états, pas une fine enveloppe HTTP : persistance locale, écritures en file, gestion des conflits au retour de la connectivité. Et l'état par appareil (installations, canaux, segments) est un modèle de données que les apps web n'ont tout simplement pas. Si ces trois paragraphes décrivent votre produit, l'héritage mobile de votre plateforme compte ; sinon, BaaS et mBaaS sont le même achat.

## Qu'est-ce que le SaaS (Software-as-a-Service) ?

Le SaaS loue du logiciel fini — connectez-vous et utilisez-le. C'est le seul échelon de l'échelle que vous *consommez* au lieu de *construire dessus*, et c'est pourquoi le comparer aux autres est un changement de catégorie : les six premiers modèles répondent à "quelle part du stack de mon produit est-ce que j'opère ?" ; le SaaS répond à "cela doit-il seulement faire partie de mon produit ?". Votre CRM, votre messagerie et votre analytics sont du SaaS. À l'instant où un outil a besoin de votre logique sur mesure à l'intérieur, vous êtes tombé de l'échelon SaaS et il vous en faut un plus bas.

| | Profil SaaS |
| --- | --- |
| Vous déployez | Rien — vous configurez |
| Le fournisseur opère | Tout, sauf vos données et votre politique d'accès |
| Forme du pricing | Par siège/mois |
| Choisissez-le quand | Le problème est déjà productisé et n'est pas votre différenciateur |
| Éloignez-vous quand | Il vous faut un comportement sur mesure que la roadmap de l'éditeur ne partage pas |

Le SaaS compte dans cette comparaison surtout comme *frontière* : il définit à quoi ressemble "entièrement géré" quand il ne reste rien à programmer, la direction vers laquelle tous les autres échelons grimpent depuis deux décennies. Il fixe aussi le plafond du pitch des échelons de construction — plus un BaaS s'approche de "le backend de votre produit ressemble à du SaaS dès le premier jour", plus l'ingénierie restante se concentre exactement sur la partie qui vous différencie. La dépendance est le prix : roadmap, pricing et portabilité des données restent du côté de l'éditeur, vos données et votre politique d'accès étant les seules lignes qui ne cessent jamais d'être à vous.

## Comment l'échelle a grandi

| Ère | Ce qui est apparu | Ce que cela a abstrait |
| --- | --- | --- |
| 2006–2009 | L'IaaS, puis le PaaS | Acheter du matériel ; puis opérer des serveurs |
| 2011 | Le NIST formalise IaaS/PaaS/SaaS · le mBaaS émerge pour les apps mobiles | Les définitions ; puis le backend mobile |
| 2013–2014 | Les conteneurs se généralisent → CaaS · premiers runtimes FaaS | Les images machine ; puis le serveur toujours allumé |
| 2015–2020 | Le mBaaS se généralise en BaaS · le parapluie "serverless" est forgé | Le cadrage mobile-only ; puis le serveur en tant que concept |
| Aujourd'hui | Les équipes choisissent par défaut l'échelon suffisant le plus haut | Le prochain candidat : le boilerplate lui-même |

Le motif sur deux décennies est unidirectionnel : chaque nouveau modèle abstrait la couche que le précédent exposait encore, et chaque génération d'équipes démarre plus haut que la précédente. Que le mBaaS soit arrivé *avant* le BaaS généraliste est la meilleure anecdote de l'échelle — la contrainte mobile (pas d'équipe serveur, cycles de release des app stores) a forcé l'abstraction la plus haute en premier, et le reste de l'industrie l'a rattrapée ensuite.

## La pizza, étendue à sept échelons

L'analogie pédagogique classique (forgée par l'architecte logiciel Albert Barron en 2014) mappe le trio sur le dîner : l'on-prem, c'est cuisiner chez soi, l'IaaS, la pizza à cuire soi-même, le PaaS, la livraison, le SaaS, le restaurant. Les nouveaux échelons l'étendent naturellement. **Le CaaS, c'est louer une cuisine professionnelle avec des moules standardisés** — vos recettes, emballées à votre façon, cuites sur leur équipement. **Le FaaS, c'est payer à la part** — aucune pizza n'existe avant que vous ayez faim, et vous ne payez jamais pour une table vide. **Le BaaS, c'est le kit repas où tout est prêt sauf votre touche signature** — pâte, sauce et four réglés ; vous ajoutez la garniture qui fait que le restaurant est le vôtre. Et **le mBaaS, c'est ce même kit au format food truck** : la contrainte (le mobile) a façonné le kit en premier, et tous les autres l'ont adopté ensuite.

## IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS, comparés

| Dimension | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- |
| Vous gérez | De l'OS vers le haut | Conteneurs + app | App + données | Fonctions + données | Logique sur mesure + données | La configuration |
| Unité de déploiement | Machine virtuelle | Conteneur | Application | Fonction | Souvent rien (appels de SDK) | — |
| Mise à l'échelle | Vous la configurez | Le fournisseur orchestre | La plateforme, par instance | Automatique, à zéro | Automatique derrière les API | Invisible |
| Forme du pricing | Par ressource-heure | Par nœud/conteneur | Par instance/palier | Par invocation + temps | Palier gratuit + plans | Par siège/mois |
| Temps jusqu'à la première requête | Des jours | Des heures | Des heures | Des minutes | **Des minutes, auth et données incluses** | Instantané |
| Pression de lock-in | Faible | Faible-moyenne | Moyenne | Moyenne-forte | Forte — sauf open-source | La plus forte |
| Idéal pour | Contrôle total, charges spéciales | Microservices, stacks polyglottes | Apps serveur sur mesure | Calcul événementiel | Backends d'app standard | Consommer, pas construire |

### Les paires que l'on compare vraiment

**IaaS vs. PaaS** — "voulons-nous opérer des machines ou juste livrer une app ?". Choisissez l'IaaS seulement quand le contrôle est l'exigence ; sinon, le PaaS efface la charge de tout ce qui se trouve au-dessus de l'OS pour la même application.

**IaaS vs. CaaS** — la même question une couche plus haut : opérer votre propre orchestration sur des machines louées, ou louer aussi l'orchestration ? À moins qu'opérer le control plane ne soit votre spécialité, CaaS.

**CaaS vs. PaaS** — l'unité que vous remettez : des conteneurs (n'importe quel stack, votre empaquetage, un contrôle au niveau de l'orchestration) vs. du code applicatif (leurs runtimes, leurs conventions, moins de cérémonie). Les microservices et les parcs polyglottes penchent vers le CaaS ; une seule app standard penche vers le PaaS.

**CaaS vs. FaaS** — la persistance vs. les événements. Les services de longue durée avec du trafic inter-services appartiennent aux conteneurs ; le travail sporadique en forme d'événement appartient aux fonctions qui redescendent à zéro. La plupart des systèmes réels font tourner les deux.

**PaaS vs. BaaS** — la confusion la plus profonde de l'échelle, avec [une entrée complète](/glossary/fr/paas-vs-baas/) : le PaaS héberge le backend *que vous devez encore écrire* ; le BaaS supprime cette étape pour les fonctionnalités standard. Écrire le backend, ou en avoir un.

**FaaS vs. BaaS** — le périmètre de l'externalisation, disséqué dans [BaaS vs. Serverless](/glossary/fr/baas-vs-serverless/) : le FaaS externalise le runtime du code que vous écrivez ; le BaaS externalise le backend pour que l'essentiel de ce code n'existe jamais. Les plateformes BaaS matures embarquent le FaaS, donc en pratique les échelons se combinent.

**BaaS vs. mBaaS** — [l'histoire vs. le présent](/glossary/fr/mbaas-vs-baas/) : le même échelon, avec une origine mobile-first. Si votre produit vit du push, de l'offline et de l'état par appareil, le *m* décrit encore vos besoins ; les plateformes ont convergé de toute façon.

**SaaS vs. tous les autres** — le changement de catégorie : chaque autre modèle est quelque chose sur quoi vous construisez ; le SaaS est quelque chose sur quoi vous ne construisez *rien*. Si une charge peut être du SaaS, c'est presque toujours l'échelon suffisant le moins cher — elle cesse simplement d'être *votre* logiciel.

## Où se place "serverless"

Le serverless n'est pas un huitième échelon — c'est le parapluie au-dessus des deux échelons programmables les plus hauts. La [définition canonique](https://martinfowler.com/articles/serverless.html) couvre à la fois le FaaS (votre code, exécuté à la demande) et le BaaS (des services backend pré-construits) : dans les deux, personne dans votre équipe ne gère de serveur, la capacité se met à l'échelle automatiquement et le coût suit l'usage. Quand quelqu'un dit "nous sommes passés serverless", la question d'échelle à poser est *quel échelon* : des fonctions qu'ils ont écrites, un backend qu'ils n'ont pas écrit, ou — le plus souvent — la combinaison.

## Cas d'usage courants

- **IaaS :** migrations lift-and-shift, runtimes et matériel spécialisés, régimes de conformité qui exigent le contrôle de l'infrastructure.
- **CaaS :** flottes de microservices, systèmes polyglottes, équipes qui veulent une [orchestration de calibre Kubernetes](/glossary/fr/kubernetes/) sans opérer le control plane.
- **PaaS :** applications web et API sur mesure où la logique backend *est* le produit, opérées par des équipes qui veulent déployer sans opérations serveur.
- **FaaS :** handlers de webhooks, jobs planifiés, pipelines d'images et de données — du travail événementiel sans backend complet autour.
- **BaaS :** backends d'app complets aux besoins standard — utilisateurs, données, fichiers, notifications — surtout pour les équipes frontend-first.
- **mBaaS :** la même chose, en mobile-first — des produits bâtis sur le push, la sync offline et l'état par appareil.
- **SaaS :** tout ce que votre entreprise utilise sans le construire — l'échelon que vous consommez au lieu d'architecturer dessus.

## Quel échelon choisir ? Matrice de décision

```mermaid
flowchart TD
  accTitle: Choisir un modèle de service cloud selon ce que vous déployez
  accDescr: Un flux de décision. Si quelqu'un vend déjà le produit, utilisez le SaaS. Si vous construisez et que vos besoins backend sont standard, utilisez un BaaS, ou un mBaaS pour les produits mobile-first. Si la logique backend est le produit, utilisez un PaaS pour une seule app ou un CaaS pour des microservices. Utilisez le FaaS pour la glue événementielle sur n'importe quel chemin, et l'IaaS seulement quand le contrôle de l'infrastructure est lui-même l'exigence.
  Q0{"Le produit existe-t-il<br/>déjà à l'achat ?"} -->|Oui| S["SaaS — consommez-le"]
  Q0 -->|Non, nous construisons| Q1{"Les besoins backend sont-ils standard ?<br/>(utilisateurs, données, fichiers, push)"}
  Q1 -->|Oui| B["BaaS — mBaaS si mobile-first"]
  Q1 -->|"Non — la logique backend EST le produit"| Q2{"Une app ou plusieurs services ?"}
  Q2 -->|Une app| P["PaaS"]
  Q2 -->|Microservices / polyglotte| C["CaaS"]
  Q1 -.->|Travail événementiel annexe| F["FaaS — sur tout chemin"]
  Q2 -.->|Le contrôle de l'infrastructure est l'exigence| I["IaaS"]
```

| Si vous êtes… | Commencez à | Parce que |
| --- | --- | --- |
| Une équipe frontend ou mobile qui livre un produit | BaaS / mBaaS | Le backend standard existe dès le premier jour ; n'écrivez que ce qui vous est propre |
| Une équipe backend avec un seul codebase serveur sur mesure | PaaS | Le contrôle total du code, aucune des machines |
| L'exploitant d'un parc de microservices ou polyglotte | CaaS | L'orchestration sans opérer le control plane |
| Celui qui automatise événements, glue et travail planifié | FaaS | Payez seulement quand quelque chose se passe |
| Celui qui fait tourner du legacy ou du matériel spécial | IaaS | Le contrôle des échelons bas est l'exigence |
| Celui qui résout un problème que quelqu'un a déjà productisé | SaaS | Le construire est une distraction |

Deux règles honnêtes s'empilent par-dessus : choisissez par défaut l'échelon le plus haut qui convient (chaque marche descendue réintroduit du travail opérationnel) et réévaluez charge par charge — les entreprises vivent sur plusieurs échelons à la fois, à dessein.

## Limites et trade-offs

- **IaaS :** le prix unitaire vous flatte ; la masse salariale ops pour patcher, mettre à l'échelle et sécuriser est la vraie facture.
- **CaaS :** vous avez externalisé le control plane, pas la complexité — images, manifestes, service meshes et pipelines de déploiement restent une discipline d'ingénierie.
- **PaaS :** vous possédez toujours une application entière — chaque upgrade de dépendances et chaque bug d'auth inclus — plus des conventions en forme de plateforme.
- **FaaS :** cold starts, limites d'exécution et un prix par invocation qui devient hostile sous forte charge soutenue.
- **BaaS / mBaaS :** un plafond de personnalisation pour les besoins très hors standard, et le [lock-in](/glossary/fr/vendor-lock-in-cloud/) le plus fort de l'échelle *quand il est propriétaire* — la raison pour laquelle les plateformes basées sur l'open-source comptent : elles gardent la sortie réelle.
- **SaaS :** une dépendance totale — roadmap, pricing et portabilité des données vivent dans les décisions de quelqu'un d'autre.
- **Tous :** la ligne de responsabilité partagée bouge, mais ne passe jamais au-dessus de vos données, de votre politique d'accès et de votre jugement.

## L'échelle as-a-service sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Elle occupe l'échelon BaaS — complète au sens mBaaS, avec push et SDK mobiles de premier rang — et se couvre délibérément dans les deux directions. Vers le haut : le backend standard arrive pré-construit, si bien que votre propre produit démarre dès le premier jour avec l'immédiateté d'un SaaS. Vers le bas : les fonctions, triggers et jobs planifiés de [Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) vous donnent l'échelon FaaS à l'intérieur de la plateforme, et la même entreprise documente l'[échelon CaaS](https://blog.back4app.com/containers-as-a-service/) pour les charges qui exigent des conteneurs. Et comme le stack est open-source, le pire mode de défaillance de l'échelle — le lock-in au sommet — vient avec un chemin de descente documenté : auto-héberger le même backend sur n'importe quel échelon inférieur, sans réécriture.