--- term: 'Cold Starts en Serverless' seoTitle: 'Cold starts en serverless : causes, durée, atténuation' headline: 'Que sont les cold starts en serverless ?' slug: cold-starts-serverless category: backend-compute shortDefinition: "Un cold start est la pénalité de latence payée quand la plateforme serverless doit créer et initialiser un nouvel environnement avant d'exécuter votre code." relatedTerms: - serverless-architecture - cloud-code-serverless-functions - edge-computing-edge-functions - baas-vs-serverless contrastsWith: - edge-computing-edge-functions aboutTerms: - 'Cold Start' - 'Warm Start' - 'Provisioned Concurrency' faq: - question: "Qu'est-ce qu'un cold start ?" answer: "La latence supplémentaire quand la plateforme serverless doit construire un environnement d'exécution neuf avant de lancer votre fonction : allouer une instance, télécharger votre code, démarrer le runtime, exécuter votre code d'initialisation — et seulement alors traiter la requête. Un warm start saute directement à la dernière étape." - question: 'Combien de temps dure un cold start ?' answer: "Typiquement d'une centaine de millisecondes à plus d'une seconde. Les runtimes interprétés (JavaScript, Python) tournent autour de 200–400 ms ; les compilés (Go, Rust) peuvent descendre sous 100 ms ; les runtimes à VM (JVM, .NET) vont de 500 ms à plusieurs secondes, les setups chargés en frameworks étant les pires. Les latences de queue font deux à trois fois la médiane." - question: 'Quelle est la différence entre un cold start et un warm start ?' answer: "Un warm start réutilise un environnement gelé mais déjà initialisé : la plateforme le dégèle et appelle votre handler, en ajoutant moins de 10 ms. Tout ce qui vit hors du handler — connexions, caches, modules chargés — survit, et c'est pourquoi la discipline d'initialisation rapporte à chaque invocation chaude suivante." - question: 'À quelle fréquence les cold starts se produisent-ils ?' answer: "Les deux réponses sont vraies : moins d'un pour cent des invocations pour un trafic de production régulier — et l'écrasante majorité pour un trafic clairsemé, puisqu'une fonction appelée toutes les heures fait un cold start presque à chaque fois. Les rafales en ajoutent : chaque requête concurrente au-dessus du pool chaud déclenche son propre cold start." - question: 'Comment réduire les cold starts ?' answer: "Gravissez l'échelle du gratuit vers le payant : réduisez le bundle de déploiement et élaguez les dépendances (le plus grand gain gratuit), chargez paresseusement les imports rarement utilisés, choisissez un runtime plus rapide, augmentez la mémoire (le CPU suit), utilisez le snapshot-restore quand la plateforme le propose — et seulement ensuite payez pour de la capacité préchauffée." - question: "Qu'est-ce que la concurrence provisionnée ?" answer: "La solution payante, aussi vendue comme instances minimales : la plateforme garde N environnements initialisés en avance de la demande, ce qui élimine les cold starts pour le trafic jusqu'à N. L'ironie est comprise dans le prix — vous réintroduisez un coût toujours actif dans un modèle de paiement à l'usage, et c'est pourquoi elle n'a sa place que sur les chemins critiques en latence." - question: 'Les pings de keep-warm fonctionnent-ils ?' answer: "Partiellement, et fragilement : un ping planifié garde un seul environnement chaud, mais ne fait rien quand la concurrence monte — la dixième requête simultanée fait un cold start, aussi chaud que soit le premier environnement. Les warmers sont le hack hérité ; les instances minimales sont la réponse supportée." - question: 'Les cold starts comptent-ils vraiment pour mon app ?' answer: "Seulement là où un humain attend : les chemins synchrones face à l'utilisateur, comme les API interactives et les paiements. Les files d'attente, les webhooks, les jobs planifiés et le reste du travail asynchrone absorbent les cold starts de façon invisible. Mesurez la latence de queue sous un trafic proche de la production avant de dépenser de l'argent sur le problème." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' - name: 'Serverless cold starts — cross-provider benchmarks (Shilkov)' url: 'https://mikhail.io/serverless/coldstarts/' - name: 'lambda-perf — continuously updated runtime benchmarks' url: 'https://github.com/maxday/lambda-perf' - name: 'Serverless Cold Starts and Where to Find Them — EuroSys 2025' url: 'https://dl.acm.org/doi/10.1145/3689031.3696073' cta: title: 'Latence constante, sans warmers' text: "Cloud Code de Back4app s'exécute sur un backend toujours actif — pas de scale-from-zero, pas de phase d'init à prendre de vitesse, pas de facture de capacité provisionnée. Vos fonctions répondent à la même vitesse à la première requête et à la millionième." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-08' translationKey: serverless-cold-starts --- **Un cold start est la pénalité de latence payée quand la plateforme serverless doit créer et initialiser un nouvel environnement avant d'exécuter votre code.** Ce n'est pas un bug, c'est une facture : le [scale-to-zero](/glossary/fr/architecture-serverless/) signifie que les environnements inactifs sont récupérés pour que l'inactivité ne coûte rien — et la première requête après cette récupération paie le setup. Comprendre les phases, les vrais chiffres et l'échelle de mitigation transforme les cold starts d'une peur diffuse en une décision d'ingénierie avec un prix. ## Points clés | Question | Réponse | | --- | --- | | La cause | Scale-to-zero : aucun coût à l'inactivité ⇒ quelqu'un initialise à la demande | | Les phases | Allouer → télécharger le code → démarrer le runtime → exécuter l'init → répondre | | Les chiffres | ~100 ms–1 s+ typique ; moins de 1 % du trafic régulier, presque tout le trafic clairsemé | | Le déclencheur oublié | Le scale-out de concurrence — les warmers n'y peuvent rien | | L'échelle | D'abord les corrections gratuites dans le code ; en dernier la capacité payante toujours chaude | ## Les cinq phases, chronomètre en main ```text COLD START coût typique 1 Allouer un sandbox (micro-VM / conteneur) ~50–100 ms 2 Télécharger votre paquet de déploiement 50–500 ms ← dépend de la taille du bundle 3 Démarrer le runtime du langage 50–1 000 ms ← interpréteur rapide, VM lente 4 Exécuter VOTRE init (imports, clients SDK, conn. BDD) 0 ms–secondes ← le plus grand levier entre vos mains 5 Invoquer le handler le vrai travail WARM START = étape 5 seulement (+ ~1–10 ms de dégel). L'environnement a été gelé, pas détruit — les connexions et caches hors du handler survivent, et c'est pourquoi la discipline d'init paie un loyer à chaque requête suivante. ``` Le contraste qui vaut la peine d'être mesuré vous-même — une fonction sur un backend toujours en exécution, où la course ne démarre jamais : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Cloud Code runs on an always-on backend — no scale-from-zero cold start const t0 = Date.now(); const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' }); console.log(`Round trip: ${Date.now() - t0} ms`); // consistent p50 ≈ p99 // The FaaS mitigations (warmers, provisioned capacity, bundle diets) // don't apply here: the process serving this call was already running. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Cloud Code runs on an always-on backend — no scale-from-zero cold start final t0 = DateTime.now(); final response = await ParseCloudFunction('averageStars') .execute(parameters: {'movie': 'Arrival'}); print('Round trip: ${DateTime.now().difference(t0).inMilliseconds} ms'); // Consistent p50 ≈ p99: the process serving this call was already running. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Cloud Code runs on an always-on backend — no scale-from-zero cold start let t0 = Date() let avg: Double = try await Cloud.run(name: "averageStars", parameters: ["movie": "Arrival"]) print("Round trip: \(Int(Date().timeIntervalSince(t0) * 1000)) ms") // Consistent p50 ≈ p99: the process serving this call was already running. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Cloud Code runs on an always-on backend — no scale-from-zero cold start val t0 = System.currentTimeMillis() val avg = ParseCloud.callFunction( "averageStars", mapOf("movie" to "Arrival")) println("Round trip: ${System.currentTimeMillis() - t0} ms") // Consistent p50 ≈ p99: the process serving this call was already running. ``` ```mermaid flowchart LR accTitle: Chemin froid versus chemin chaud d'une invocation serverless accDescr: Une requête entrante trouve un environnement chaud déjà initialisé et va directement au handler, ou n'en trouve aucun et doit attendre l'allocation d'instance, le téléchargement du code, le démarrage du runtime et le code d'initialisation avant que le handler s'exécute. La récupération pour inactivité et les déploiements vident le pool chaud, et les pics de concurrence au-dessus de lui déclenchent des cold starts supplémentaires. R["Requête"] --> P{"Environnement chaud
disponible ?"} P -->|"oui"| H["Le handler s'exécute
+ ~1–10 ms"] P -->|"non — récupéré pour inactivité,
déploiement récent ou
pic de concurrence"| C["Allouer → télécharger →
démarrer → init"] C -->|"+100 ms – secondes"| H H --> F["Environnement gelé,
conservé pour réutilisation (minutes)"] F -.-> P ``` ## Cold starts vs. warm starts | | Cold start | Warm start | | --- | --- | --- | | Environnement | Créé et initialisé maintenant | Réutilisé, dégelé | | Latence ajoutée | ~100 ms à quelques secondes | Moins de 10 ms | | Quand | Premier appel, post-déploiement, post-inactivité, scale-out | Trafic régulier dans le pool chaud | | Code d'init | S'exécute | Sauté — ses résultats persistent | | Note de facturation | Sur les grandes plateformes, la phase d'init est désormais facturée comme l'exécution | Temps du handler seulement | ## Combien de temps, et à quelle fréquence — honnêtement **La durée** dépend surtout du runtime et du bundle : les runtimes interprétés (JavaScript, Python) typiquement 200–400 ms ; les compilés (Go, Rust) sous ~100–300 ms ; les runtimes à VM (JVM, .NET) de 500 ms à plusieurs secondes, le snapshot-restore réduisant spectaculairement le chiffre de la JVM ; les p99 font 2–3× la médiane, et des arbres de dépendances obèses multiplient le démarrage plusieurs fois, quel que soit le langage, tandis que des [benchmarks hello world](https://github.com/maxday/lambda-perf) montrent la base de chaque runtime. **La fréquence** est là où la plupart des explications ne racontent que la moitié de l'histoire. Un trafic de production régulier voit des cold starts sur *moins d'un pour cent* des invocations — rassurant, et réel. Mais le calcul s'inverse pour le trafic clairsemé : [l'arithmétique de Mike Roberts](https://martinfowler.com/articles/serverless.html) — une fonction invoquée une fois par heure fait un cold start pratiquement à chaque fois, et les environnements de développement voient des taux froids de 30–90 %. Et le déclencheur que tout le monde oublie : **le scale-out de concurrence** — quand dix requêtes arrivent et que trois environnements sont chauds, sept font un cold start simultanément, en plein milieu de votre pic de trafic, précisément quand ça fait mal. ## L'échelle de mitigation, avec les prix Par ordre de coût, le moins cher d'abord. **Gratuit, dans le code :** réduisez le bundle de déploiement et élaguez les dépendances — le plus grand levier que la plupart des équipes n'ont pas encore actionné ; importez seulement les sous-modules du SDK que vous utilisez ; chargez paresseusement les modules lourds des chemins rares ; ouvrez les connexions à la base de données dans le scope d'init pour que les warm starts les réutilisent. **Bon marché, dans la configuration :** augmentez la mémoire (le CPU monte avec elle, de façon sensible pour les runtimes à VM) ; activez le snapshot-restore là où la plateforme le propose. **Fragile, remède de grand-mère :** les pings de keep-warm — une requête planifiée toutes les quelques minutes garde *un* environnement chaud et ne fait rien pour le scale-out ; statut honnête : hack hérité. **Payant, définitif :** la capacité pré-provisionnée (« concurrence provisionnée », « instances minimales ») — N environnements toujours initialisés, cold starts éliminés jusqu'à N, à un prix toujours actif qui annule en partie le paiement à l'usage. L'ironie mérite sa phrase : la solution au problème signature du serverless consiste à racheter le serveur qu'on vous avait promis de ne pas avoir. ## Les isolates : comment les runtimes edge les contournent [Les plateformes edge](/glossary/fr/edge-computing/) affichent des cold starts quasi nuls en changeant l'architecture plutôt qu'en la chauffant : au lieu de démarrer un conteneur ou une micro-VM par tenant, elles exécutent des milliers d'**isolates V8** — des sandboxes façon onglet de navigateur — dans un seul processus de longue durée. Créer un contexte d'isolate coûte quelques millisecondes et quelques mégaoctets, pas des centaines de millisecondes et un démarrage de runtime. Le trade-off, c'est l'environnement : un sous-ensemble d'API standards du web, des plafonds CPU stricts, pas de système de fichiers — un outil différent, pas un upgrade gratuit, couvert honnêtement dans l'entrée edge. ## Cas d'usage courants où les cold starts comptent - **API interactives** — un humain regarde le spinner ; le p99 inclut la queue froide. - **Paiements et checkout** — sensibles à la latence et facturés en conversion. - **Connexion et émission de session** — le chemin de la première impression, souvent après des périodes d'inactivité. - **Endpoints à trafic clairsemé** — outils d'admin et API internes où presque chaque appel est froid. - **Là où ils ne comptent pas :** [jobs](/glossary/fr/jobs-en-arriere-plan/) en file, [webhooks](/glossary/fr/webhooks/), travail planifié — l'asynchrone absorbe la queue de façon invisible. ## Devriez-vous optimiser les cold starts ? Matrice de décision | Situation | Faites | | --- | --- | | Charges asynchrones/en file/planifiées | Rien — les cold starts sont invisibles ici | | Trafic élevé et régulier, interactif | Corrections dans le code ; mesurez avant de payer | | Trafic clairsemé, face à l'utilisateur | Instances minimales sur ce chemin — ou un backend toujours actif | | Runtime à VM (JVM/.NET), sensible à la latence | Snapshot-restore + mémoire d'abord | | Trafic en pics avec p99 strict | Capacité provisionnée dimensionnée au pic | | Logique façon gateway, utilisateurs mondiaux | [Runtimes edge à base d'isolates](/glossary/fr/edge-computing/) | | La plupart des backends d'app sur un BaaS | Déjà résolu — aucun scale-from-zero n'existe | ## Limites et trade-offs - **Les mitigations échangent de l'argent contre de la latence.** La capacité préchauffée est une facture permanente ; décidez par endpoint, pas pour toute la plateforme. - **Les warmers mentent aux dashboards.** Une fonction pinguée a l'air en bonne santé alors que chaque vrai pic de trafic fait toujours des cold starts au scale-out. - **L'austérité d'init a des limites.** Un lazy-loading agressif déplace la latence des cold starts vers les chemins de première utilisation — mesurez où vous l'avez déplacée. - **Les benchmarks vieillissent vite.** Les classements de runtimes et les chiffres des plateformes changent chaque année ; des chiffres périmés (et des pénalités réseau corrigées depuis longtemps) circulent encore — datez vos données. - **La métrique qui compte est la vôtre.** Les statistiques de pourcentage froid décrivent le trafic de quelqu'un d'autre ; seul votre p99 sous une charge proche de la production justifie de dépenser. ## Les cold starts 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. L'histoire des cold starts ici est une absence architecturale : [Cloud Code](/glossary/fr/cloud-code-fonctions-serverless/) s'exécute dans un backend toujours en exécution, donc il n'y a pas de moment de scale-from-zero — pas de course d'init, pas de pool chaud à gérer, pas de ligne de capacité provisionnée sur la facture — et la mesure des onglets de code montre ce que cela achète : un p50 et un p99 à portée de voix l'un de l'autre, à la première requête de la journée comme à la millionième. Le trade-off est celui nommé dans [BaaS vs. serverless](/glossary/fr/baas-vs-serverless/) : vous renoncez à la granularité de facturation par invocation en échange d'une latence constante et d'une base de données attachée — ce qui, pour les backends d'apps face à l'utilisateur, est généralement le versant du compromis que les utilisateurs perçoivent.