Qu'est-ce que l'architecture serverless ?

L’architecture serverless est un modèle d’exécution cloud où le fournisseur exécute votre code à la demande : vous ne provisionnez ni ne gérez aucun serveur. Les serveurs existent toujours — vous cessez simplement de les louer, de les patcher et de les mettre à l’échelle. Vous déployez des fonctions ; la plateforme alloue du calcul quand un événement arrive et ne vous facture que ce qui s’exécute.

Points clés

Le problème qu’elle résout

Avec un déploiement traditionnel, vous louez de la capacité avant la demande : dimensionner l’instance, configurer l’autoscaling, payer le temps d’inactivité, patcher l’OS. Trompez-vous dans un sens et vous brûlez de l’argent ; dans l’autre, vous perdez des requêtes à votre pic de trafic.

Dans un modèle serverless, cette boucle entière disparaît. Vous écrivez une fonction, et passer de zéro à des milliers d’exécutions concurrentes est le travail du fournisseur. Voici tout le code backend nécessaire pour calculer côté serveur la note moyenne d’un film :

// cloud/main.js — une fonction Cloud Code de Back4app
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});

Aucune app Express autour, pas de Dockerfile, pas de load balancer. La fonction est l’unité de déploiement.

L’appeler depuis n’importe quel client

Chaque SDK client invoque la même fonction par son nom — le transport, l’auth et la mise à l’échelle sont pris en charge par la plateforme :

// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}

Comment circule une requête serverless

La branche à surveiller est le cold start. Quand aucune instance chaude n’existe, la plateforme doit provisionner un runtime avant d’exécuter votre code — de quelques millisecondes à plusieurs secondes selon le langage, la taille du code et les dépendances. En production, il ne touche qu’une petite fraction des requêtes, puisqu’une fonction invoquée régulièrement continue de réutiliser des instances chaudes — négligeable pour la plupart des API, mais réel sur les chemins critiques en latence, et l’une des raisons pour lesquelles les fonctions edge et les stratégies de warm-up existent.

Serverless vs. conteneurs vs. serveurs traditionnels

FaaS et BaaS : les deux moitiés du serverless

« Serverless » couvre deux modèles complémentaires, une distinction que l’article canonique de Mike Roberts sur martinfowler.com a formalisée. La séparation a une date de naissance : le calcul commercial déclenché par événements est apparu en 2014 et, en deux ans, le serverless est passé d’idée de recherche à standard de production pour le travail orienté événements — c’est pourquoi le vocabulaire semble encore plus neuf que les idées qu’il recouvre. Le FaaS (Functions as a Service) signifie que vous écrivez encore de la logique côté serveur, mais qu’elle s’exécute dans un calcul stateless, déclenché par événements et entièrement géré — le modèle des « cloud functions ». Le BaaS (Backend as a Service) va plus loin : la base de données, l’authentification, le stockage de fichiers et les API sont eux-mêmes consommés comme des services gérés, si bien que la majeure partie du code backend que vous auriez écrit disparaît entièrement.

La plupart des applications réelles ont besoin des deux — des fonctions pour la logique sur mesure, des services gérés pour tout le reste. Cette combinaison est exactement ce qu’une plateforme BaaS réunit clé en main. Pour approfondir cette moitié du modèle, lisez notre guide complet du Backend as a Service.

Cas d’usage courants du serverless

• API et backends mobiles. Le cas dominant : un trafic piloté par les requêtes qui dort la nuit et explose au lancement — exactement la forme que la tarification à l’exécution récompense.
• Traitement d’événements et de données. Redimensionner une image à l’upload, valider un enregistrement à la sauvegarde, synchroniser un changement vers un système tiers — des réactions brèves à des événements.
• Jobs planifiés. Rapports nocturnes, tâches de nettoyage et synchronisations récurrentes tournent comme des fonctions déclenchées par cron, sans serveur qui attend entre deux exécutions.
• Fonctionnalités temps réel. Chat, notifications et dashboards en direct associent des fonctions serverless à une infrastructure temps réel gérée, plutôt qu’à des serveurs WebSocket faits main.
• MVP et prototypes. Quand on valide une idée, passer zéro minute sur l’infrastructure est tout l’intérêt — déployez une fonction, obtenez une URL, livrez.
• Agents IA et webhooks. Le code de liaison entre LLM, prestataires de paiement et API SaaS est naturellement orienté événements et de courte durée — un cas idéal pour le serverless.

Devriez-vous passer au serverless ? Matrice de décision

Sur le coût, des repères concrets aident : les plateformes serverless facturent par requête plus le temps de calcul consommé (Go-secondes), sans engagement initial — et l’offre gratuite de Back4app inclut 25 000 requêtes d’API par mois, de quoi faire tourner un vrai MVP à 0 $ avant toute décision de mise à l’échelle.

Limites et trade-offs

• Les cold starts. La première invocation d’une fonction inactive paie une pénalité de provisionnement (de moins de 100 ms à plus d’une seconde). Atténuations : concurrence chaude, bundles plus petits, runtimes edge.
• Les limites de durée d’exécution. Les fonctions sont faites pour du travail court ; l’encodage vidéo ou les batchs d’une heure relèvent des conteneurs ou des systèmes de jobs en arrière-plan.
• Débogage et observabilité plus difficiles. Il n’y a pas de serveur où entrer en SSH. Vous dépendez des logs, des métriques et du tracing de la plateforme — évaluez-les avant de vous engager.
• Le vendor lock-in. Les fonctions qui dépendent d’API propriétaires coûtent cher à déplacer. Préférez les plateformes construites sur de l’open source — Cloud Code de Back4app repose sur une fondation open-source que vous pouvez auto-héberger à tout moment.
• Le coût à l’échelle soutenue. Payer à l’exécution est imbattable à faible volume et en pics, mais peut dépasser un tarif serveur fixe sous une charge constante et lourde. Refaites le calcul quand le trafic se stabilise.
• L’absence d’état. Les fonctions ne gardent aucune mémoire entre les invocations ; la session et l’état applicatif doivent vivre dans une base de données ou un cache — une contrainte de conception si vous portez du code stateful.

L’architecture serverless 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 vous donne les deux moitiés dans une seule plateforme. La moitié FaaS est Cloud Code : des fonctions JavaScript comme averageStars ci-dessus, déployées depuis le dashboard ou la CLI, plus des triggers de base de données et des jobs planifiés — aucune gateway, politique IAM ni infrastructure à configurer. La moitié BaaS vient provisionnée avec chaque app Back4app : la base de données, l’authentification des utilisateurs, le stockage de fichiers et les API REST et GraphQL générées automatiquement. Et parce que Back4app se construit sur une fondation open-source, les fonctions que vous écrivez sont portables — vous pouvez auto-héberger le même stack plus tard, ce qui lève l’objection de lock-in qui pèse sur les plateformes serverless liées à un fournisseur.