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

PaaS est un modèle cloud où le fournisseur opère la plateforme sur laquelle votre code se déploie, mais vous écrivez et maintenez toujours l’application. En clair : vous louez la plateforme, mais l’app reste la vôtre. La définition du NIST trace la ligne avec précision — le fournisseur contrôle les serveurs, les systèmes d’exploitation et les runtimes ; vous contrôlez l’application déployée et ses données.

Points clés

À quoi ressemble l’utilisation d’un PaaS

L’expérience PaaS par excellence, c’est déployer en une commande, sans configurer d’infrastructure :

# Le flux PaaS typique : poussez le code, la plateforme fait le reste
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

Ce que cette commande déploie, en revanche, reste une application serveur complète que vous avez écrite — routage, validation, câblage de la base de données, gestion de l’auth :

// server.js — sur un PaaS, tout ceci reste à vous d'écrire et de maintenir
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // vous avez construit ceci
  const tasks = await db.query(                    // et ceci
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // et ceci
});

app.listen(process.env.PORT);

C’est le marché essentiel du PaaS : l’infrastructure disparaît, mais l’application backend — et chaque patch de sécurité, upgrade de dépendances et endpoint qu’elle contient — reste votre codebase.

L’échelle d’abstraction

Chaque modèle de service cloud répond à une seule question : combien louez-vous, et combien opérez-vous encore ?

Le partage des responsabilités, couche par couche :

Des variantes spécialisées de PaaS existent pour des tâches plus étroites — plateformes d’intégration, mobiles, de base de données, de communication — mais toutes se tiennent sur la même marche : un endroit géré pour exécuter ou connecter le logiciel que vous construisez.

PaaS vs. BaaS : la différence pratique

Le BaaS est la marche suivante, et la différence se voit dans ce que vous n’écrivez pas. L’endpoint de liste de tâches ci-dessus — vérification d’auth, requête, réponse — est remplacé sur un BaaS par un appel direct du SDK depuis n’importe quel client, le contrôle d’accès étant appliqué par la plateforme :

// JavaScript / Node.js — Back4app JS SDK
const query = new Parse.Query('Task');
query.equalTo('done', false);
query.descending('createdAt');
const tasks = await query.find();
console.log(`${tasks.length} open tasks`);

// Flutter / Dart — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

// iOS / Swift — Back4app Swift SDK
let query = Task.query("done" == false)
  .order([.descending("createdAt")])
query.find { result in
  switch result {
  case .success(let tasks):
    print("\(tasks.count) open tasks")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

PaaS vs. serverless

Les modèles sont cousins, pas synonymes. Une app PaaS tourne en continu sur de la capacité que vous configurez ; le calcul serverless se matérialise par événement, facture par invocation et redescend à zéro — au prix de cold starts et de limites d’exécution. En pratique, la ligne se brouille : les plateformes modernes greffent des fonctions serverless sur un hébergement de style PaaS, et une architecture serverless peut servir une API entière qu’un PaaS aurait hébergée comme une seule app. La décision tient à la forme du trafic : une charge régulière favorise un processus PaaS toujours allumé ; une charge en pics ou largement au repos favorise le calcul par invocation.

Cas d’usage courants

• API et services web sur mesure. Un backend à la logique trop spécifique pour des fonctionnalités pré-construites — moteurs de pricing, marketplaces, outils internes — déployé sans posséder de serveurs.
• Standardiser de nombreux déploiements. Les équipes qui exploitent des dizaines de services adoptent un PaaS pour que chaque service se builde, se déploie, se logue et se mette à l’échelle de la même façon.
• Migrer depuis des serveurs auto-gérés. Les applications serveur existantes (surtout les apps twelve-factor) passent sur un PaaS presque sans changement — le même code, plus aucun patch d’OS.
• Là où le BaaS remplace le PaaS : les backends d’app standard. Si le backend, c’est utilisateurs + données + fichiers + notifications, les fonctionnalités pré-construites éliminent la couche applicative que le PaaS hébergerait — le cas courant pour les produits mobiles et web.
• Hybride : un cœur sur mesure de style PaaS, un BaaS pour le reste. Certaines équipes gardent un service sur mesure sur une plateforme tandis que la gestion des utilisateurs, les API de données et le stockage viennent d’un BaaS à côté.

Devriez-vous choisir PaaS ou BaaS ? Matrice de décision

Si la plupart des besoins sont standard mais que quelques-uns sont sur mesure, ce n’est pas une raison de choisir le PaaS — un BaaS avec un runtime de fonctions embarqué couvre les deux côtés avec moins de code à posséder.

Limites et trade-offs

• Vous possédez toujours une application. Upgrades de framework, patchs de sécurité dans les dépendances, bugs d’auth — un PaaS héberge votre backend ; il ne le maintient pas. C’est le coût que le BaaS supprime et que le PaaS ne supprime pas.
• Vendor lock-in. Les apps écrites contre des services et des formats de déploiement propres à la plateforme coûtent cher à déplacer. Mitigations : tenez-vous-en aux standards ouverts, conteneurisez, préférez les plateformes bâties sur l’open-source — la même prudence de vendor lock-in vaut sur toute l’échelle.
• Le coût sous charge soutenue. La commodité gérée porte une marge ; les grosses charges régulières finissent moins chères sur les marches inférieures de l’échelle — au prix d’un retour de la charge d’exploitation.
• Un contrôle réduit. Pas d’accès à l’OS, un réglage réseau limité et des versions de runtime au calendrier du fournisseur. Les régimes de conformité qui exigent le contrôle de l’infrastructure peuvent écarter le modèle.
• La dépendance au fournisseur. Les pannes, les changements de prix et les dépréciations arrivent au calendrier du fournisseur, pas au vôtre. Jugez son historique comme une partie de l’architecture.

PaaS vs. BaaS 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. Cela la place une marche au-dessus du PaaS : chaque app démarre avec le backend complet déjà provisionné. Le manque de logique sur mesure qui vous ramènerait sinon vers un PaaS est couvert par Cloud Code — fonctions serverless, triggers et jobs planifiés. Et comme le stack est open-source, l’objection du lock-in s’inverse : le même backend peut s’auto-héberger sur n’importe quelle infrastructure, si bien que redescendre l’échelle plus tard reste possible sans réécriture.