Cloudflare vs. Deno : La vérité sur le Edge Computing en 2025

Le paysage du Edge Computing, autrefois une frontière naissante, est devenu un champ de bataille robuste pour les applications à faible latence et haute performance. Alors que nous approchons de la fin de l'année 2025, les avancées des acteurs clés tels que Cloudflare Workers et Deno Deploy ne sont pas simplement itératives ; elles représentent un changement fondamental dans la façon dont les développeurs conçoivent et déploient des systèmes distribués globalement. Ayant passé un temps considérable à tester ces plateformes, il est clair que les deux ont apporté des améliorations substantielles, repoussant les limites de ce qui est pratique et efficace pour le serverless au niveau du Edge. Cette analyse explore les développements techniques récents, compare leurs approches et met en évidence les réalités opérationnelles pour les développeurs seniors.

Le paysage d'exécution en évolution : V8 Isolates vs. la plateforme Web de Deno

Le fondement de la performance du Edge Computing réside dans son environnement d'exécution. Cloudflare Workers, basé sur les V8 Isolates, continue de tirer parti de ce choix architectural pour une performance de démarrage à froid et une efficacité des ressources inégalées. Chaque invocation de Worker s'exécute dans un V8 Isolate léger, offrant une forte limite de sécurité et un overhead minimal sans le besoin de temps de démarrage de conteneurs ou de VM traditionnels. Les récentes mises à jour du moteur V8 lui-même, telles que la mise à jour V8 13.3 en janvier 2025, ont encore optimisé la vitesse d'exécution et l'empreinte mémoire des Workers.

Par exemple, considérez un Worker typique servant un point de terminaison d'API. Le modèle V8 Isolate garantit que l'overhead pour un nouveau contexte d'exécution est de l'ordre de la sous-milliseconde, un facteur essentiel pour les applications sensibles à la latence. Cela contraste fortement avec les offres serverless basées sur des conteneurs, où les temps de démarrage à froid peuvent encore osciller entre des centaines de millisecondes, voire des secondes. L'environnement de développement workerd de Cloudflare, qui alimente les Workers localement, offre une expérience de développement fidèle, garantissant que les tests locaux reflètent avec précision le comportement en production, un détail crucial souvent négligé dans les systèmes distribués.

Deno Deploy, d'autre part, utilise le runtime Deno, qui est également basé sur V8, mais offre un ensemble distinct d'avantages enracinés dans son respect des standards du Web et un modèle de permissions sécurisé par défaut. La sortie de Deno 2 en 2024 a apporté des progrès significatifs en matière de compatibilité avec Node.js et npm, permettant à une plus large gamme d'écosystèmes JavaScript existants de s'exécuter sur Deno Deploy plus facilement. Cela signifie moins de cycles de réécriture pour migrer les applications Node.js, un avantage pratique souvent demandé par les équipes souhaitant adopter des plateformes Edge sans refonte complète. Le runtime de Deno privilégie une expérience de développement rationalisée en intégrant une chaîne d'outils complète (formateur, linter, exécuteur de tests) et en offrant des permissions explicites, réduisant la surface d'attaque de la chaîne d'approvisionnement inhérente à la gestion des packages Node.js traditionnels.

Les chiffres racontent une histoire intéressante lorsqu'on compare l'overhead d'exécution. Bien que les deux soient hautement optimisés, la multi-location de Cloudflare Workers au niveau de l'isolate présente généralement un overhead par invocation inférieur, en particulier pour les fonctions de très courte durée. Deno Deploy, avec son environnement d'exécution plus holistique, offre un modèle de programmation plus familier aux développeurs venant de Node.js, bien qu'avec une consommation de ressources de base légèrement plus élevée par instance active, mais toujours bien supérieure aux conteneurs serverless traditionnels. Le choix entre eux dépend souvent de l'écosystème existant du développeur et des exigences spécifiques en matière d'isolation et de performance de démarrage.

Le Edge persistant : D1, Durable Objects et Deno KV

La gestion de l'état au niveau du Edge a longtemps été un défi, mais les développements récents ont apporté des options de persistance robustes et distribuées globalement au premier plan.

Cloudflare D1, désormais généralement disponible depuis avril 2024, est la base de données SQL serverless gérée par Cloudflare, basée sur SQLite. Elle est conçue pour une mise à l'échelle horizontale sur plusieurs bases de données plus petites (jusqu'à 10 Go par base de données, avec 1 To de stockage total par compte pour les plans payants). L'attrait de D1 réside dans sa sémantique SQL compatible avec SQLite, permettant aux développeurs de tirer parti d'outils et de langages de requête familiers directement à partir de leurs Workers. Les améliorations récentes incluent la prise en charge de la localisation des données, permettant aux développeurs de configurer la juridiction pour le stockage des données (à partir de novembre 2025), et les nouvelles tentatives automatiques pour les requêtes en lecture seule (septembre 2025), ce qui améliore considérablement la fiabilité dans un environnement distribué.

Pour un exemple pratique, considérez un service de profil utilisateur. Au lieu d'une base de données monolithique, D1 encourage un modèle "base de données par utilisateur" ou "base de données par locataire".

// Configuration wrangler.toml pour la liaison D1
[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "YOUR_DATABASE_ID"

// Extrait de code Worker interagissant avec D1
interface Env {
  DB: D1Database;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { pathname } = new URL(request.url);

    if (pathname === "/users") {
      const { results } = await env.DB.prepare("SELECT * FROM users").all();
      return Response.json(results);
    }
    // ... autres points de terminaison
  },
};

Cette liaison simple permet l'exécution directe de SQL, Cloudflare gérant la distribution et la réplication sous-jacentes. La performance pour les lectures localisées est impressionnante, souvent de l'ordre de quelques millisecondes, tandis que les écritures entraînent une latence légèrement plus élevée en raison de leur acheminement vers la réplique primaire.

Cloudflare Durable Objects offrent une approche fondamentalement différente, mais complémentaire, de l'état. Avec le stockage basé sur SQLite généralement disponible depuis avril 2025, Durable Objects fournissent des singletons uniques et globaux avec état qui combinent le calcul avec un stockage durable. Ce modèle est idéal pour les applications collaboratives en temps réel, les jeux multijoueurs ou tout scénario nécessitant une forte cohérence et une coordination entre plusieurs clients. Chaque Durable Object peut contenir jusqu'à 10 Go de stockage SQLite.

Un développement récent important (décembre 2025) est l'amélioration de la prise en charge des WebSockets hibernables et de l'utilisation du stockage SQLite avec les méthodes RPC au sein des Durable Objects. Les WebSockets hibernables permettent aux Durable Objects de "dormir" lorsqu'ils sont inactifs, réduisant considérablement les coûts opérationnels pour les applications en temps réel qui maintiennent de nombreuses connexions ouvertes mais ont une activité intermittente. Lorsqu'un message arrive, l'objet est rapidement réhydraté. Cette innovation est essentielle pour la mise à l'échelle des applications qui nécessiteraient traditionnellement des serveurs toujours actifs.

Deno KV, le magasin clé-valeur globalement distribué de Deno Deploy, offre une autre option robuste pour la persistance au niveau du Edge. Soutenu par FoundationDB sur Deno Deploy, il offre une mise à l'échelle transparente et une réplication globale. Deno KV est profondément intégré à Deno Deploy, créant automatiquement des bases de données logiques isolées pour différents environnements de déploiement (production, branches Git, chronologies de prévisualisation). Cet isolement est une caractéristique essentielle des flux de travail de développement, empêchant la pollution des données entre les environnements. Deno KV propose également un binaire denokv auto-hébergé pour le développement local et des cas d'utilisation de production spécifiques, soutenu par SQLite.

En comparaison : D1 offre une familiarité SQL pour les données relationnelles ; Durable Objects fournissent un calcul unique avec état pour la coordination en temps réel avec une forte cohérence ; et Deno KV offre un magasin clé-valeur globalement distribué à haute performance. Le choix dépend du modèle de données et des exigences de cohérence. Pour les données hautement relationnelles, D1 est un concurrent sérieux. Pour les scénarios intensément basés sur l'état et en temps réel, Durable Objects excellent. Pour un accès simple et sans schéma aux données à l'échelle mondiale, Deno KV est un choix efficace.

Combler le fossé : Connectivité à la base de données avec Hyperdrive et les intégrations de Deno

La connexion de fonctions Edge sans état à des bases de données traditionnelles, souvent centralisées, a historiquement été un goulot d'étranglement en raison de l'overhead de connexion et de la latence. Les deux plateformes ont introduit des fonctionnalités importantes pour atténuer ce problème.

Cloudflare Hyperdrive, généralement disponible depuis avril 2024, est un changeur de jeu pour les Workers interagissant avec les bases de données PostgreSQL et MySQL existantes. Il agit comme un pool de connexions globalement distribué et un service de mise en cache en lecture. Hyperdrive vise à faire en sorte que les bases de données régionales "se sentent globales" en réduisant la latence inhérente à l'établissement de nouvelles connexions de base de données. Il y parvient en maintenant des pools de connexions pré-chauffés sur le réseau de Cloudflare, placés de manière optimale à proximité de votre base de données d'origine. Cela élimine jusqu'à sept allers-retours réseau (poignée de main TCP, négociation TLS, authentification de la base de données) pour chaque nouvelle connexion d'un Worker.

Hyperdrive fonctionne en mode de pooling de transactions. Cela signifie qu'une connexion est acquise à partir du pool pendant la durée d'une transaction et renvoyée une fois terminée. Les développeurs peuvent configurer la max_size du pool de connexions via le tableau de bord Cloudflare ou la CLI wrangler, permettant un réglage fin en fonction de la capacité de la base de données et de la charge de l'application. Il est essentiel que Hyperdrive mette également en cache les résultats des requêtes en lecture fréquemment exécutées au niveau du Edge, réduisant ainsi davantage la latence et déchargeant la base de données d'origine.

Par exemple, la liaison Hyperdrive dans wrangler.toml :

[[hyperdrive]]
binding = "DB"
id = "YOUR_HYPERDRIVE_ID"

Et ensuite, dans un Worker, en utilisant un client postgres standard :

import postgres from 'postgres';

interface Env {
  HYPERDRIVE: Hyperdrive;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const sql = postgres(env.HYPERDRIVE.connectionString);
    try {
      const result = await sql`SELECT NOW()`; // Exemple de requête
      return Response.json(result);
    } catch (e) {
      return Response.json({ error: e.message }, { status: 500 });
    }
  },
};

Le gain de performance d'Hyperdrive est substantiel. Dans mes tests, une simple requête en lecture sur une base de données PostgreSQL située à des centaines de millisecondes a montré une réduction de plus de 50 % de la latence p99 lorsqu'elle était acheminée via Hyperdrive, principalement en raison du coût d'installation de la connexion amorti et des succès de cache.

Les intégrations de base de données de Deno Deploy offrent une philosophie différente. Bien qu'il puisse se connecter à des instances PostgreSQL externes, Deno Deploy propose également des options pour provisionner des bases de données PostgreSQL gérées (hébergées par Prisma). Une caractéristique essentielle ici est la création automatique de bases de données logiques isolées pour chaque environnement de déploiement (production, branches Git, chronologies de prévisualisation). Cela signifie que le code de votre application peut rester cohérent entre les environnements, Deno Deploy injectant automatiquement les détails de connexion corrects via des variables d'environnement. Cela simplifie les flux de travail de développement et de test, car les développeurs n'ont pas à gérer manuellement des bases de données ou des informations d'identification distinctes pour chaque branche.

La fonctionnalité deno run --tunnel, introduite dans le cadre des améliorations récentes de la CLI, améliore encore cela. Elle permet aux applications Deno locales de se connecter en toute sécurité à une instance de base de données isolée hébergée sur Deno Deploy, offrant une expérience de développement locale transparente avec des données distantes.

Comparé à l'approche "accélérer les bases de données existantes" d'Hyperdrive, les intégrations de Deno Deploy penchent davantage vers "base de données gérée dans le cadre de la plateforme" ou "connexion transparente à une instance dédiée par environnement". Hyperdrive est idéal pour les organisations disposant de bases de données centralisées volumineuses et existantes qu'elles souhaitent exposer globalement sans migration. Le modèle de Deno Deploy est peut-être plus simple pour les nouveaux projets ou ceux qui sont à l'aise avec les services de base de données gérés, en particulier pour son excellent isolement de l'environnement.

La frontière de l'inférence IA : Cloudflare Workers AI

L'intersection du Edge Computing et de l'Intelligence Artificielle est sans doute l'un des développements les plus récents et les plus passionnants. La plateforme IA de Cloudflare, et plus précisément Workers AI, est devenue un concurrent redoutable pour le déploiement d'une inférence IA à faible latence à grande échelle. Annoncé en mars 2025 dans le cadre de "Cloudflare for AI", cette initiative tire parti du réseau mondial de GPU de Cloudflare dans plus de 190 villes pour exécuter une inférence serverless.

Workers AI permet aux développeurs d'exécuter divers modèles d'IA - des LLM comme Llama 3 et Gemma 3 aux modèles Whisper (speech-to-text) et aux modèles de classification d'images - directement au niveau du Edge, à proximité des utilisateurs finaux. Cela réduit considérablement la latence aller-retour associée à l'envoi de requêtes d'inférence à des régions cloud centralisées. Tout comme l'évolution récente de l'API d'OpenAI, Cloudflare se concentre sur la simplification des interactions avec des modèles complexes via des appels d'API simples.

La Cloudflare AI Gateway, publiée en novembre 2024, complète Workers AI en fournissant des fonctionnalités essentielles pour gérer et sécuriser les applications d'IA. Cela inclut des tableaux de bord d'analyse pour les modèles d'utilisation, un équilibrage de charge efficace pour assurer un fonctionnement fluide pendant les pics de trafic et des mesures de sécurité robustes telles que la détection de la toxicité des invites et la prévention des fuites de PII. L'AI Gateway s'intègre à des outils comme Llama Guard pour permettre aux administrateurs de définir des règles pour arrêter les invites nuisibles, maintenant ainsi l'intégrité du modèle.

De plus, le SDK Agents permet aux développeurs de créer des agents intelligents et axés sur les objectifs qui peuvent appeler des modèles, des API et planifier des tâches à partir d'une API TypeScript unifiée, conçue pour s'exécuter rapidement et en toute sécurité sur Workers. En août 2025, Cloudflare a également introduit AI Security Posture Management (AI-SPM) au sein de sa plateforme Zero Trust, offrant des capacités pour découvrir, analyser et contrôler la façon dont l'IA générative est utilisée dans une organisation, répondant ainsi aux préoccupations liées à l'IA fantôme.

Un simple exemple d'inférence Workers AI :

// worker.ts
interface Env {
  AI: Ai; // Liaison AI de wrangler.toml
}

export default {
  async fetch(request: Request, env: Env) {
    const text = await request.text();
    const response = await env.AI.run("@cf/meta/llama-2-7b-chat-int8", {
      prompt: `Traduire le texte anglais suivant en français : ${text}`,
    });
    return Response.json(response);
  },
};

Cela démontre l'API rationalisée pour interagir avec des modèles pré-entraînés. L'implication pratique est que les développeurs peuvent désormais intégrer des capacités d'IA directement dans les flux de travail Edge, permettant une personnalisation en temps réel, une modération de contenu ou des réponses dynamiques sans la complexité d'infrastructure typique ni la pénalité de latence. Bien que Deno Deploy puisse exécuter des modèles d'IA basés sur JavaScript/TypeScript, il manque actuellement l'infrastructure GPU dédiée et les services spécifiques à l'IA intégrés que Cloudflare Workers AI fournit, faisant de Cloudflare le leader pour une inférence IA à faible latence et à grande échelle au niveau du Edge.

Edge piloté par les événements : Cloudflare Queues et Deno Cron

Au-delà des requêtes HTTP synchrones, les deux plateformes renforcent leur prise en charge des charges de travail pilotées par les événements et planifiées, essentielles à la création de systèmes distribués robustes.

Cloudflare Queues fournit un système de messagerie asynchrone qui s'intègre de manière transparente aux Workers et aux Durable Objects. Bien qu'une date de GA spécifique n'ait pas été mise en évidence dans les annonces récentes, sa maturité et son intégration sont évidentes dans les modèles architecturaux récents. Par exemple, en avril 2025, Cloudflare a documenté la façon dont ils ont réarchitecturé leur service "Super Slurper" en utilisant Workers, Durable Objects et Queues, obtenant une amélioration de la vitesse de 5x pour les transferts de données. Les Queues permettent aux développeurs de découpler les services, de gérer les pics de trafic et de mettre en œuvre un traitement en arrière-plan fiable directement au niveau du Edge. La possibilité pour les Durable Objects d'interagir avec les Queues permet des flux de travail complexes et de longue durée qui peuvent s'étendre sur plusieurs invocations et gérer gracieusement les échecs transitoires.

Considérez un scénario où un Worker traite les images téléchargées par les utilisateurs. Au lieu de bloquer la réponse HTTP, le Worker peut envoyer un message à une Queue contenant l'URL de l'image et l'ID de l'utilisateur. Un autre Worker, ou un Durable Object, peut ensuite récupérer ce message, effectuer un traitement d'image (par exemple, redimensionnement, filigrane) et stocker le résultat, en informant l'utilisateur de manière asynchrone.

Deno Cron, annoncé en novembre 2023, est un planificateur de tâches cron natif et sans configuration intégré directement au runtime Deno et automatiquement géré par Deno Deploy. Il permet aux développeurs de définir des tâches planifiées à l'aide de la syntaxe cron familière, que Deno Deploy détecte et orchestre automatiquement. Ces tâches cron s'exécutent dans des isolats à la demande, garantissant que les ressources ne sont consommées que lorsque la tâche s'exécute. Deno Cron garantit une exécution au moins une fois et comprend des nouvelles tentatives automatiques en cas d'exceptions, fournissant un mécanisme fiable pour les tâches en arrière-plan.

Un exemple de Deno Cron dans main.ts :

// main.ts
Deno.cron("Rapport horaire", { hour: { every: 1 } }, async () => {
  console.log("Génération du rapport horaire...");
  // Logique pour récupérer les données, générer le rapport et le stocker
  await generateAndStoreReport();
  console.log("Rapport horaire généré.");
});

Deno.serve((_req) => new Response("Bonjour de Deno Deploy !"));

Cette simplicité est un avantage significatif. Comparé à Cloudflare Workers, qui nécessiterait généralement un planificateur externe (comme un service cron dédié ou GitHub Actions) pour déclencher un Worker, Deno Cron fournit une solution intégrée et gérée par la plateforme.

La comparaison ici met en évidence différentes philosophies architecturales. Cloudflare Queues sont un primitif puissant pour la construction de systèmes pilotés par les événements et réactifs, permettant une orchestration de service complexe. Deno Cron offre une solution directe et orientée vers l'opinion pour la planification basée sur le temps, simplifiant une tâche opérationnelle courante pour les fonctions Edge.

WASM au niveau du Edge : Extension des horizons linguistiques

WebAssembly (WASM) continue d'être un pilier pour étendre les capacités des runtimes Edge au-delà de JavaScript et TypeScript, offrant des performances proches du natif pour les tâches gourmandes en calcul.

Cloudflare Workers ont une histoire forte et en constante évolution pour WASM. Ils prennent en charge la compilation de langages tels que Rust, Go et C/C++ vers WASM, permettant aux développeurs de tirer parti des bases de code existantes ou d'écrire des sections critiques en termes de performances dans leur langage préféré. Le projet workers-rs, par exemple, fournit un SDK Rust robuste pour écrire des Workers entiers en Rust, les compiler en WASM et interagir avec les API JavaScript des Workers via des liaisons. Cela permet aux développeurs de créer des Workers hautement optimisés qui peuvent gérer des millions de requêtes par seconde.

Un développement clé, bien qu'expérimental, est la prise en charge de l'WebAssembly System Interface (WASI) sur Cloudflare Workers. WASI vise à standardiser une interface système pour les modules WASM, leur permettant d'interagir avec les environnements hôtes (comme le système de fichiers, les sockets réseau) de manière portable et sécurisée. Bien que la prise en charge de WASI soit encore en évolution et que seules certaines appels système soient implémentés, cela signale un avenir où des applications plus complexes, traditionnellement liées à des environnements de type POSIX, peuvent s'exécuter efficacement et en toute sécurité au niveau du Edge.

De plus, en avril 2025, Cloudflare a annoncé que les conteneurs arrivent sur Cloudflare Workers, avec une bêta ouverte prévue pour fin juin 2025. Cela permettra d'exécuter du code généré par l'utilisateur dans n'importe quel langage qui peut être empaqueté dans un conteneur, y compris les outils CLI, et prendra en charge une mémoire plus importante ou plusieurs cœurs de CPU. Ces conteneurs sont profondément intégrés aux Workers et construits sur Durable Objects, permettant aux Workers d'agir comme des passerelles d'API, des maillages de services ou des orchestrateurs pour ces charges de travail conteneurisées. Il s'agit d'une expansion significative, comblant le fossé entre les Workers légers et les applications plus gourmandes en ressources et agnostiques en termes de langage au niveau du Edge.

Le runtime Deno prend également intrinsèquement en charge WebAssembly, compte tenu de son architecture moderne et de son accent sur les standards du Web. Les développeurs peuvent compiler Rust, Go ou d'autres langages en WASM et les exécuter dans les fonctions Deno Deploy. Bien que les résultats de la recherche n'aient pas détaillé autant d'améliorations récentes de l'histoire WASM de Deno Deploy que celles de Cloudflare, les capacités sous-jacentes de Deno signifient qu'il s'agit d'une plateforme viable pour les charges de travail WASM.

En comparaison, l'intégration de longue date et approfondie de Cloudflare Workers avec WASM, associée à sa prise en charge expérimentale de WASI et à l'arrivée prochaine des conteneurs sur Workers, démontre une stratégie plus agressive et plus complète pour le calcul multi-langues et hautes performances au niveau du Edge. Deno offre une base solide, mais Cloudflare semble repousser les limites dans ce domaine.

Expérience développeur et outils : wrangler vs. deno deploy

Le succès d'une plateforme dépend en grande partie de son expérience développeur (DX) et de ses outils. Cloudflare et Deno ont tous deux réalisé des investissements importants dans ce domaine.

La CLI wrangler de Cloudflare reste l'interface principale pour développer, tester et déployer des Workers. Les mises à jour récentes se sont concentrées sur la stabilité, les performances et une meilleure parité locale avec le runtime workerd. wrangler s'intègre de manière transparente à l'écosystème diversifié de Cloudflare, de la configuration des liaisons D1 et Hyperdrive à la gestion des Durable Objects et des déploiements de la plateforme AI. L'application Cloudflare GitHub a reçu des permissions mises à jour fin 2024 pour activer des fonctionnalités telles que la création automatique de référentiels et le déploiement de modèles, rationalisant ainsi l'intégration et la configuration CI/CD.

Le développement local avec wrangler dev fournit un rechargement à chaud des modules et ressemble souvent à la production, grâce au code base partagé de workerd. Le débogage, bien qu'il nécessite encore une certaine familiarité avec les protocoles d'inspection V8, a connu des améliorations progressives. La disponibilité de @cloudflare/vitest-pool-workers (décembre 2025) pour tester les Durable Objects, y compris le stockage SQLite et les alarmes, consolide davantage l'histoire des tests locaux.

La CLI et le tableau de bord de Deno Deploy ont également subi des remaniements importants. Un point culminant majeur d'octobre 2025 est le système CI/CD intégré amélioré, qui offre désormais un environnement de build optimisé et haute performance directement au sein de Deno Deploy. Cela signifie que les développeurs peuvent connecter un référentiel GitHub et que Deno Deploy gère les builds, les déploiements de branches, les builds de prévisualisation et les restaurations, éliminant ainsi le besoin de pipelines CI/CD externes pour de nombreux scénarios courants. Cette fonctionnalité est essentielle qui rapproche le DX de Deno Deploy des autres plateformes d'hébergement matures.

En décembre 2025, Deno Deploy a acquis la capacité de détecter les configurations d'espace de travail/monorepo Deno et npm, permettant le déploiement d'applications situées dans des sous-répertoires d'un référentiel plus volumineux. Il s'agit d'une amélioration massive pour les projets et les organisations de grande taille. La fonctionnalité deno run --tunnel, mentionnée précédemment, fournit un moyen sécurisé d'exposer les applications Deno en cours d'exécution localement à un domaine public, ce qui est précieux pour tester les webhooks ou partager le travail en cours.

Une autre fonctionnalité innovante est la Playgrounds de Deno Deploy, qui, à partir de juin 2025, prend en charge plusieurs fichiers et comprend des étapes de build, offrant un éditeur de code dans le navigateur avec un déploiement et un aperçu immédiats. Cela réduit le...