Qu'est-ce que le serverless ? Le calcul sans serveur expliqué simplement

Le serverless est une façon d'exécuter du code sans configurer ni gérer soi-même de serveurs. Vous confiez votre code à un fournisseur cloud, qui ne l'exécute que lorsqu'un événement le déclenche (une requête web, un fichier envoyé, une notification de paiement), puis s'arrête. En général, vous payez le temps d'exécution réel de votre code, et non une machine qui attend sans rien faire.

Pourquoi le serverless compte quand on crée avec l'IA

Quand vous créez une application avec l'IA et que vous examinez les options d'hébergement ou le code, vous rencontrerez les « fonctions serverless », « fonctions edge » ou « fonctions cloud ». De nombreuses plateformes d'hébergement les proposent, et certains générateurs IA déploient des backends de cette façon. Comprendre ce modèle vous aide à répondre à trois questions pratiques :

• Le coût. Votre application coûtera-t-elle de l'argent alors que personne ne l'utilise ?
• La rapidité. Pourquoi la première requête après une période calme est-elle plus lente ?
• Les limites. Pourquoi une tâche longue, comme la génération d'un gros rapport ou le traitement d'une vidéo, a-t-elle expiré ?

Il est aussi utile de savoir ce que le serverless n'est pas : ce n'est pas l'absence de backend. Vous avez toujours du code côté serveur ; quelqu'un d'autre se charge simplement de faire tourner les machines. Pour les bases, voir qu'est-ce qu'un serveur.

Une analogie du quotidien

Un serveur traditionnel, c'est posséder une voiture. Elle est toujours là, prête à partir immédiatement, mais vous la payez — assurance, stationnement, entretien — que vous la conduisiez ou non.

Le serverless, c'est appeler un taxi. Vous ne payez que les trajets effectués, et si cent personnes ont besoin d'une course en même temps, cent taxis arrivent. Mais il peut y avoir une courte attente pour que la voiture arrive (un démarrage à froid), chaque trajet a une durée maximale, et le chauffeur ne se souvient pas de vous d'une course à l'autre (les fonctions sont sans état, ou stateless).

Fonctionnement des fonctions serverless

Dans sa forme la plus courante, appelée functions as a service (fonctions en tant que service) :

1. Vous écrivez une fonction : un petit morceau de code qui gère un type d'événement, par exemple « traiter un POST sur /api/bookings ».
2. Vous la déployez. Le fournisseur la stocke et la relie à un déclencheur : une URL, une planification, un nouveau fichier dans le stockage, un message dans une file d'attente.
3. Un événement arrive. Le fournisseur démarre une copie de votre fonction (ou réutilise une copie déjà active), l'exécute et renvoie le résultat.
4. Elle s'adapte seule. Si mille requêtes arrivent en même temps, le fournisseur exécute de nombreuses copies en parallèle, dans les limites de votre compte.
5. Elle se met en veille. Quand le trafic s'arrête, les copies sont arrêtées. Sans rien en cours d'exécution, vous ne payez rien pour le calcul.

Une toute petite fonction serverless en JavaScript pourrait ressembler à ceci :

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Aucun code n'est nécessaire pour démarrer un serveur, ouvrir un port ou maintenir un processus en marche. La plateforme s'occupe de tout cela.

Le terme « serverless » est aussi utilisé plus librement pour d'autres services managés qui s'adaptent automatiquement et facturent à l'usage, par exemple les bases de données serverless, qui se mettent en pause lorsqu'elles sont inactives.

Termes clés

Un exemple concret : un petit site de réservation

Le site de réservation d'un studio de yoga reçoit une vague de visites chaque dimanche soir, lorsque le nouveau planning est publié, et très peu le reste de la semaine.

• Avec un serveur toujours allumé, le studio paie une machine 24 h/24, dimensionnée pour le pic du dimanche soir, et qui reste surtout inactive le reste du temps.
• Avec des fonctions serverless, GET /api/classes et POST /api/bookings sont des fonctions. La ruée du dimanche lance automatiquement de nombreuses copies ; un mardi matin calme, presque rien ne tourne et la facture est proche de zéro.

Les compromis apparaissent aussi. La première personne qui ouvre le site le mardi matin peut attendre un peu plus à cause d'un démarrage à froid. La base de données doit gérer de nombreuses connexions de courte durée venant de nombreuses copies de fonctions, ce qui peut nécessiter un pool de connexions. Et si le studio souhaite plus tard une tâche « générer le PDF de présence annuelle de tout le monde », elle pourrait dépasser la limite de temps de la fonction et devoir tourner ailleurs.

Quand le serverless convient, et quand il ne convient pas

Idées reçues courantes

• « Serverless signifie pas de backend. » Cela signifie pas de serveurs à gérer. Vous écrivez et sécurisez toujours du code backend.
• « Le serverless est toujours moins cher. » Il est bon marché pour un faible volume, mais une tarification à la requête peut grimper avec un volume élevé et constant.
• « Le serverless passe à l'échelle à l'infini. » Les plateformes ont des limites de simultanéité, et votre base de données peut devenir le goulot d'étranglement bien avant les fonctions.
• « Les fichiers enregistrés dans une fonction seront là la prochaine fois. » Le stockage local est temporaire. Utilisez une base de données ou un stockage de fichiers.
• « La mise à zéro est la même chose que le serverless. » C'est lié mais pas identique. Certaines plateformes exécutent votre application comme un serveur ordinaire qui s'endort lorsqu'il est inactif et se réveille à la requête suivante : des économies similaires et un délai similaire pour la première requête, mais sans les limites de temps propres aux fonctions pour chaque requête.

Quoi demander à votre générateur d'applications IA

• « Ce backend fonctionnera-t-il en fonctions serverless, ou sur un serveur toujours allumé ou qui se met en veille ? Qu'est-ce que cela implique pour le coût ? »
• « Certaines tâches risquent-elles de dépasser la limite de temps de la plateforme ? Si oui, comment les gérer ? »
• « Stocke tout ce qui doit persister dans la base de données ou le stockage de fichiers, et non en mémoire ou dans des fichiers locaux. »
• « Comment gérer les connexions à la base de données si de nombreuses copies tournent en même temps ? »
• « Quel est le délai de la première requête après une période d'inactivité de l'application ? »

Comment Mythex héberge les applications

Mythex ne décrit pas son hébergement comme des fonctions serverless. Lorsque vous publiez, votre application tourne comme une application web ou un conteneur ordinaire que Mythex gère pour vous ; il n'y a aucun hébergement à configurer. C'est une mise à zéro : les applications publiées et leurs bases de données s'endorment lorsqu'elles sont inactives et se réveillent à la visite suivante ; une application endormie ne coûte rien en calcul, et des machines supplémentaires ne démarrent que lorsque le trafic est élevé (Pro autorise jusqu'à 3 par service). La base Postgres attachée s'endort aussi après 5 minutes d'inactivité et est facturée pour le temps pendant lequel elle a été éveillée. Vous bénéficiez donc d'une bonne part de l'avantage « payer ce que l'on utilise », avec le même type de délai pour la première requête après une période calme. Voir les limites d'hébergement dans la documentation, ainsi que nos guides sur l'hébergement web et la réduction des coûts d'hébergement.

Questions