---
term: 'Cloud Code (Fonctions Serverless)'
seoTitle: 'Cloud Code et fonctions serverless : FaaS, triggers, cold starts'
headline: 'Qu''est-ce que Cloud Code (fonctions serverless) ?'
slug: cloud-code-fonctions-serverless
category: backend-compute
shortDefinition: "Cloud Code est un modèle serverless où la logique backend s'exécute en fonctions côté serveur, déclenchées par appels, événements de données ou cron."
relatedTerms:
  - serverless-architecture
  - baas-vs-serverless
  - iaas-paas-baas-faas
  - webhooks
contrastsWith:
  - edge-computing-edge-functions
aboutTerms:
  - 'FaaS (Functions-as-a-Service)'
  - 'Cloud Functions'
  - 'Function Triggers'
faq:
  - question: 'Qu''est-ce qu''une fonction serverless ?'
    answer: 'Un petit bloc de code côté serveur, à usage unique, que la plateforme exécute à la demande en réponse à un événement — un appel HTTP, un changement de données, une tâche planifiée. Le fournisseur prend en charge le provisioning, la mise à l''échelle et la maintenance : vous déployez la logique, la plateforme possède toute la machinerie qui l''exécute.'
  - question: 'Quelle est la différence entre FaaS et serverless ?'
    answer: 'FaaS — Functions-as-a-Service — est la moitié compute du modèle serverless : des fonctions individuelles déclenchées par des événements. Serverless est le modèle plus large, qui inclut aussi les services backend gérés (base de données, authentification, stockage — la moitié BaaS). Cloud Code est le point où les deux moitiés se rejoignent : des fonctions qui tournent avec un backend géré.'
  - question: 'Comment les fonctions serverless sont-elles déclenchées ?'
    answer: 'Cinq familles : les appels directs (un client ou une API invoque la fonction par son nom), les événements de données (du code qui s''exécute avant ou après les sauvegardes et suppressions), les événements d''authentification (hooks sur la connexion et l''inscription), les tâches planifiées (jobs de type cron) et les webhooks entrants de systèmes externes. Une bonne plateforme expose les cinq comme un simple enregistrement de code, pas comme de l''infrastructure.'
  - question: 'Qu''est-ce qu''un cold start ?'
    answer: 'La latence — de quelques centaines de millisecondes à plusieurs secondes — quand la plateforme doit initialiser un environnement d''exécution neuf pour une fonction descendue à zéro. Les mitigations incluent des instances chaudes minimales et des bundles plus légers ; les fonctions hébergées sur un backend toujours actif esquivent entièrement le cas du redémarrage depuis zéro.'
  - question: 'Pourquoi les fonctions serverless doivent-elles être stateless ?'
    answer: 'Parce que n''importe laquelle des nombreuses instances parallèles et éphémères peut servir la requête suivante — la mémoire conservée entre invocations est un bug en sursis. L''état persistant appartient à une base de données ou à un cache. Dans la variante BaaS, la base de données est déjà attachée, et c''est là une bonne part de la commodité du modèle.'
  - question: 'Quelles sont les limites des fonctions serverless ?'
    answer: 'Les plateformes plafonnent le temps d''exécution (quelques secondes par défaut, quelques minutes au maximum), la mémoire et la taille des payloads — le travail de longue durée relève des jobs en arrière-plan, et un débit élevé et soutenu peut coûter plus cher qu''un serveur toujours actif. Les limites sont le prix de la mise à l''échelle par requête.'
  - question: 'Quelle est la différence entre fonctions serverless et microservices ?'
    answer: 'Des axes différents : les microservices sont une décomposition architecturale ; serverless est un modèle d''exécution. Une fonction est plus fine qu''un microservice, et un microservice peut être implémenté en fonctions, en conteneurs ou comme tranche de monolithe. Les conteneurs achètent du contrôle et des processus longue durée ; les fonctions achètent zéro opération et une mise à l''échelle par requête.'
  - question: 'Les fonctions serverless causent-elles du vendor lock-in ?'
    answer: 'Les formats d''événements et l''outillage propriétaires créent un couplage réel sur les plateformes fermées. Le contrepoids, c''est l''open source : des fonctions écrites contre des runtimes ouverts — y compris le Cloud Code open-source de Back4app, qui tourne sur n''importe quel hôte Node.js — se déplacent avec votre backend au lieu de vous lier au système d''événements d''un seul cloud.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Serverless Architectures — Martin Fowler'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'CNCF Serverless Whitepaper'
    url: 'https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview'
  - name: 'Cloud Code guide'
    url: 'https://docs.parseplatform.org/cloudcode/guide/'
  - name: 'OpenFaaS — open-source functions'
    url: 'https://www.openfaas.com/'
  - name: 'Function as a service — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Function_as_a_service'
cta:
  title: 'Des fonctions qui vivent avec votre backend'
  text: 'Le Cloud Code de Back4app exécute votre JavaScript à côté de votre base de données, de votre authentification et de vos fichiers — fonctions invocables, triggers de sauvegarde et jobs planifiés en un seul déploiement, sans serveurs et sans la taxe du cold start.'
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-08'
translationKey: cloud-code-serverless-functions
---

**Cloud Code est un modèle serverless où la logique backend s'exécute en fonctions côté serveur, déclenchées par appels, événements de données ou cron.** Deux clarifications d'entrée de jeu, parce que cette famille de termes vit dans la confusion. Premièrement, "serverless" signifie que les serveurs sont *le problème de quelqu'un d'autre* — ils existent, invisibles, mis à l'échelle pour vous. Deuxièmement, les fonctions existent en deux architectures : le **FaaS** autonome, où chaque fonction est une unité isolée câblée à des services externes, et la **variante BaaS** qui donne son nom à cet article — des fonctions déployées *dans* votre backend, partageant leur environnement avec la base de données, l'authentification et les fichiers sur lesquels elles agissent.

## Points clés

| Question | Réponse |
| --- | --- |
| Les quatre propriétés | Déclenchée par événements · stateless · mise à l'échelle auto · paiement à l'usage |
| Les deux saveurs | Unités FaaS autonomes vs. Cloud Code vivant avec votre backend |
| Les familles de triggers | Appel par nom · événements de données · événements d'auth · cron · webhooks |
| Pourquoi côté serveur | Les clients peuvent être décompilés ; les fonctions ne peuvent pas être trafiquées |
| Les limites honnêtes | Timeouts, statelessness et cold starts (là où l'échelle à zéro s'applique) |

## Une fonction, appelée de partout

L'exemple classique de l'agrégation — calculer à côté des données, n'expédier que la réponse :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Calling a Cloud Code function: server-side logic, one line from the client
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
// The aggregation ran NEXT TO the database — only the answer crossed the wire

// The function itself (cloud/main.js — deployed to your backend, not the app):
// Parse.Cloud.define('averageStars', async (req) => {
//   const q = new Parse.Query('Review').equalTo('movie', req.params.movie);
//   const reviews = await q.find({ useMasterKey: true });
//   return reviews.reduce((s, r) => s + r.get('stars'), 0) / reviews.length;
// });
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Calling a Cloud Code function: server-side logic, one line from the client
final response = await ParseCloudFunction('averageStars')
    .execute(parameters: {'movie': 'Arrival'});
final avg = response.result;
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Calling a Cloud Code function: server-side logic, one line from the client
let avg: Double = try await Cloud.run(name: "averageStars",
                                      parameters: ["movie": "Arrival"])
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Calling a Cloud Code function: server-side logic, one line from the client
val params = mapOf("movie" to "Arrival")
val avg = ParseCloud.callFunction<Double>("averageStars", params)
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.
```

Faire la moyenne de mille avis sur le téléphone, c'est télécharger mille avis ; la version en fonction ne déplace qu'un seul nombre. Cet argument de bande passante se généralise en l'argumentaire complet pour la logique côté serveur, juste en dessous.

## La taxonomie des triggers

Les explications superficielles listent les triggers en une phrase ; la structure mérite une table :

| Famille de trigger | Se déclenche quand | Usage canonique |
| --- | --- | --- |
| Fonctions invocables | Un client invoque par nom avec des paramètres JSON | Logique métier, agrégations, actions |
| Triggers de données | Avant/après save, delete, find sur une classe | Validation, valeurs par défaut, cascades, audit |
| Triggers d'auth | Avant la connexion, après inscription/déconnexion | Blocklists, parcours de bienvenue, audit |
| Jobs planifiés | Expressions cron | Rapports, nettoyages, purges TTL, digests |
| [Webhooks](/glossary/fr/webhooks/) entrants | Un système externe POSTe un événement | Confirmations de paiement, notifications CI |

```mermaid
flowchart LR
  accTitle: Sources d'événements déclenchant des fonctions serverless à côté d'un backend géré
  accDescr: Appels clients, événements de sauvegarde en base de données, événements d'authentification, plannings cron et webhooks externes déclenchent des fonctions côté serveur, qui lisent et écrivent dans la base de données gérée, appellent des API externes avec des secrets conservés côté serveur et renvoient des résultats, la plateforme mettant l'exécution à l'échelle automatiquement.
  C["Appel client<br/>par nom"] --> F["Fonction<br/>(votre logique, runtime géré)"]
  D["Événement de données<br/>avant/après le save"] --> F
  A["Événement d'auth<br/>login, inscription"] --> F
  S["Planning<br/>cron"] --> F
  W["Webhook externe"] --> F
  F --> DB[("Base de données gérée<br/>ACL appliquées")]
  F -->|"les secrets restent côté serveur"| X["API tierces"]
```

## Pourquoi la logique appartient au serveur

Quatre arguments, presque toujours absents des explications habituelles. **Ne faites pas confiance au client :** les apps se décompilent et les requêtes se falsifient ; les calculs de prix, vérifications de permissions et scores de jeu calculés sur l'appareil sont des suggestions, tandis que la même logique dans une fonction fait loi — un trigger `beforeSave` valide chaque écriture, quel que soit le client qui l'a envoyée. **Les secrets restent à la maison :** les clés d'API tierces vivent dans l'environnement de la fonction, jamais dans un bundle que n'importe qui peut déballer — la [discipline des clés d'API](/glossary/fr/securite-des-cles-d-api/) rendue structurelle. **Mettez à jour sans release :** les changements de logique serveur se déploient instantanément chez tous les utilisateurs, sans cycle de revue d'app store entre le correctif et le corrigé. **Calculez près des données :** l'agrégation, le façonnage des recherches et le fan-out s'exécutent à quelques microsecondes de la base de données, pas à l'autre bout d'un réseau mobile.

## Cloud Code vs. FaaS autonome vs. conteneurs

| | Cloud Code (fonctions BaaS) | FaaS autonome | Conteneurs |
| --- | --- | --- | --- |
| S'exécute | Dans le runtime de votre backend | Unités isolées par fonction | Là où vous les orchestrez |
| Contexte | Base de données, auth et ACL déjà attachées | Chaque service câblé à la main | Ce que vous y construisez |
| Unité de déploiement | Un codebase, un déploiement | Par fonction | Par image |
| Cold starts | Aucun — le backend tourne déjà | Oui, au redémarrage depuis zéro | Seulement si vous descendez à zéro |
| Opérations privilégiées | Accès master key pour la logique admin | Câblage IAM par fonction | Votre propre tissu d'auth |
| Mise à l'échelle | Avec le backend | Par requête, jusqu'à zéro | Selon votre configuration |
| Convient à | Backends d'apps sur un BaaS | Travail événementiel isolé et en pics | Services longue durée et avec état |

L'article [architecture serverless](/glossary/fr/architecture-serverless/) couvre le modèle dans son ensemble et [la place du FaaS dans l'échelle des services](/glossary/fr/modeles-de-service-cloud/) a son propre article ; la ligne qui compte ici est *contexte* : les fonctions Cloud Code naissent connectées — même SDK, même sémantique de session, ACL appliquées à leurs requêtes — là où le FaaS autonome commence chaque projet par la plomberie.

## Cold starts et statelessness, sans détour

Deux propriétés découlent de la mise à l'échelle par requête, et toutes deux méritent d'être dites clairement. Les **cold starts** surviennent quand une fonction descendue à zéro doit initialiser un environnement avant de s'exécuter — de quelques centaines de millisecondes à plusieurs secondes sur les plateformes typiques, atténués par des instances chaudes minimales et des bundles légers, et *architecturalement absents* pour les fonctions hébergées sur un backend toujours actif, ce qui est une différence réelle entre les deux saveurs, pas une vantardise de fournisseur. La **statelessness** signifie que, par contrat, rien en mémoire ne survit entre les invocations : compteurs, caches et sessions conservés dans une fonction sont des bugs à retardement. L'état va dans la base de données — et l'avantage discret de la variante BaaS est que la base de données est à une ligne de code, pas derrière un service qu'il faut d'abord choisir, connecter et sécuriser.

## Cas d'usage courants

- **Validation et règles métier** — des portes `beforeSave` qui rendent les invariants non négociables sur tous les clients.
- **Agrégations et rapports** — calculez à côté des données ; renvoyez des réponses, pas des datasets.
- **Intégrations tierces** — paiements, e-mail, API d'IA appelées avec des secrets conservés côté serveur.
- **Récepteurs et émetteurs de [webhooks](/glossary/fr/webhooks/)** — les fonctions comme visages HTTP des intégrations événementielles.
- **Maintenance planifiée** — digests, nettoyages et purges sur cron, sans flotte de workers à opérer.

## Devriez-vous en faire une fonction ? Matrice de décision

| Travail | Destination |
| --- | --- |
| Logique que les clients pourraient trafiquer | Fonction — toujours |
| Tâches en pics, en forme d'événement | Fonction |
| Calcul de longue durée (minutes et plus) | Job en arrière-plan, pas une fonction |
| Services avec état, toujours actifs (sockets, files) | Conteneurs / services de plateforme |
| Hot path critique en latence à très gros volume soutenu | Mesurez — le toujours-actif peut gagner |
| Tout ce qui touche un secret | Fonction — le secret n'est jamais embarqué |

## Limites et trade-offs

- **Les timeouts sont des contrats.** Les fonctions sont plafonnées de quelques secondes à quelques minutes ; le travail qui pourrait dépasser le plafond exige une file de jobs, pas de l'espoir.
- **La statelessness est stricte.** Tout ce qui est en mémoire est éphémère ; les conceptions qui l'oublient passent les tests et échouent sous scale-out.
- **La prolifération est le mode de défaillance.** Cinquante petites fonctions sans modules partagés ni discipline de nommage deviennent un monolithe distribué avec un pire outillage.
- **Le débogage est distant par nature.** Logs et traces remplacent les points d'arrêt ; les plateformes dotées de bonnes surfaces de logs montrent ici tout leur intérêt.
- **Le coût s'inverse sous charge soutenue.** Le paiement à l'usage est imbattable pour le travail en pics mais peut être battu par des serveurs toujours actifs à débit élevé constant — chiffrez la courbe, pas la brochure.

## Cloud Code 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. Ici, Cloud Code est la saveur BaaS dans sa forme originale : du JavaScript déployé dans votre backend Back4app — `Parse.Cloud.define` pour les fonctions invocables comme celle des onglets de code, des triggers `beforeSave`/`afterSave` pour les règles de données, des hooks d'auth et des jobs planifiés, le tout dans un codebase et un déploiement. Les fonctions s'exécutent avec le contexte attaché : le même SDK que vos clients, les ACL et [permissions au niveau des classes](/glossary/fr/permissions-de-classe-clp/) appliquées aux requêtes, l'accès master key disponible quand la logique d'administration doit légitimement les contourner, et les secrets dans la configuration côté serveur. Comme le backend tourne en permanence, le cold start du redémarrage depuis zéro ne s'applique tout simplement pas — et comme la plateforme est open-source, les fonctions sont portables vers n'importe quel hôte qui l'exécute, ce qui est la réponse pratique à la question du lock-in.