Firebase Cloud Functions — qu'est-ce que c'est, déclencheurs et comment écrire des fonctions

Que sont Firebase Cloud Functions et comment fonctionnent-elles

Firebase Cloud Functions est une plateforme de calcul construite sur Google Cloud Functions (GCF), adaptée à l'écosystème Firebase. Les fonctions sont du code JavaScript ou TypeScript classique exporté d'un module et enregistré pour un type d'événement spécifique. Lorsqu'un événement se produit (par exemple, un utilisateur s'inscrit ou télécharge un fichier), Firebase Cloud Functions exécute le code correspondant en lui transmettant le contexte de l'événement.

L'architecture de Cloud Functions suit le principe de responsabilité unique : une fonction gère un type d'événement et effectue une opération atomique. Par exemple, la fonction sendWelcomeEmail est déclenchée lors de la création d'un nouvel utilisateur dans Firebase Authentication et envoie un email de bienvenue. Cet isolation simplifie le débogage, les tests et la réutilisation des fonctions dans différents projets.

Chaque fonction s'exécute dans un conteneur isolé avec un cycle de vie temporaire. Le temps d'exécution maximal par défaut est de 60 secondes (fonctions HTTPS — 9 minutes). Si une fonction ne se termine pas dans le délai imparti, la requête échoue avec une erreur 500. Pour les opérations de longue durée, utilisez Cloud Tasks ou Pub/Sub avec des tentatives. Les conteneurs peuvent être réutilisés pour des appels ultérieurs (keep-alive), ce qui réduit la latence des démarrages à froid après le premier appel.

Environnement d'exécution et versions de Node.js

Firebase Cloud Functions prend en charge plusieurs versions de Node.js : 18, 20 et 22 (recommandée pour les nouveaux projets). La version est spécifiée dans le champ engines du fichier package.json. Firebase CLI configure automatiquement l'environnement d'exécution en fonction de la version spécifiée. Important : Firebase Cloud Functions ne prend pas en charge l'exécution de conteneurs Docker arbitraires — l'environnement est strictement fixé par Google Cloud Functions.

Pour les nouveaux projets, Node.js 22 est recommandé, car il inclut les dernières optimisations V8, une meilleure prise en charge des modules ESM et la prise en charge de WebSocket au niveau de la plateforme. Si un projet utilise des dépendances compilées pour une version spécifique de Node (par exemple, des modules natifs C++), la compatibilité doit être vérifiée individuellement — tous les modules natifs ne se compilent pas dans l'environnement GCF.

Différence entre Firebase Cloud Functions et Google Cloud Functions

Firebase Cloud Functions est une surcouche de Google Cloud Functions avec le SDK Firebase préinstallé et l'intégration avec les services Firebase. Le développeur écrit du code à l'aide du SDK firebase-functions, qui fournit des déclencheurs typés pour tous les services Firebase. Google Cloud Functions est une plateforme de plus bas niveau où les déclencheurs sont configurés explicitement via Eventarc ou Pub/Sub.

La différence clé : dans Firebase Cloud Functions, un déclencheur est enregistré de manière déclarative via functions.firestore.document('path').onWrite(), tandis que dans Google Cloud Functions, il est configuré via Eventarc avec un filtrage par attributs d'événement. Firebase Cloud Functions est également livré avec le SDK Admin initialisé automatiquement avec les identifiants du compte de service du projet, offrant un accès complet à tous les services Firebase sans configuration supplémentaire.

Types de déclencheurs : quels événements sont pris en charge

Firebase Cloud Functions prend en charge 8 catégories de déclencheurs, chacune correspondant à un service Firebase ou Google Cloud spécifique. Un déclencheur est une condition qui, lorsqu'elle est remplie, invoque automatiquement une fonction. Le développeur ne gère pas directement le cycle de vie de la fonction : Firebase CLI enregistre le déclencheur dans Google Cloud Eventarc, et la plateforme cloud exécute la fonction lorsque l'événement se produit.

Les déclencheurs les plus populaires sont les déclencheurs Firestore : onWrite, onCreate, onUpdate, onDelete. Ils se déclenchent lorsque des documents dans les collections Firestore sont modifiés. La fonction reçoit des instantanés du document avant et après la modification, permettant de comparer les valeurs et de réagir uniquement à des changements spécifiques. Par exemple, lorsque le statut d'une commande passe de «en attente» à «expédié», une notification push peut être envoyée à l'utilisateur.

Les déclencheurs Authentication (onCreate, onDelete) se déclenchent lors de la création ou de la suppression d'un compte utilisateur. Ils sont utilisés pour initialiser les données utilisateur : créer un document utilisateur dans Firestore, envoyer un email de bienvenue, écrire dans les analytics. Note : la fonction ne peut pas annuler la création de l'utilisateur — elle s'exécute après que le compte a déjà été créé. Pour la pré-validation, utilisez les Blocking Functions disponibles sur Identity Platform.

Déclencheurs HTTPS et CORS

Les fonctions HTTPS (onRequest) permettent de créer des endpoints d'API REST complets accessibles via HTTP. Contrairement aux déclencheurs basés sur les événements, les fonctions HTTPS sont invoquées via une URL de la forme https://{region}-{project}.cloudfunctions.net/{functionName}. Il est important de configurer correctement le CORS si l'endpoint est appelé depuis un navigateur ou une application mobile. Le SDK Firebase n'inclut pas automatiquement les en-têtes CORS — ils doivent être ajoutés manuellement via un middleware.

Pour les clients mobiles (Android, iOS), le CORS n'est pas nécessaire car les clients HTTP natifs ne sont pas restreints par la politique Cross-Origin. Le CORS n'est pertinent que pour les requêtes web. Si votre fonction HTTPS est appelée à la fois depuis l'application et le web, ajoutez une gestion CORS universelle : res.set('Access-Control-Allow-Origin', '*') pour le développement ou une liste de domaines autorisés pour la production.

Planification avec Pub/Sub et Cloud Scheduler

Pour l'exécution périodique (tâches cron), utilisez une combinaison de Cloud Scheduler et Pub/Sub. Cloud Scheduler envoie un message à un sujet Pub/Sub selon un calendrier, et le déclencheur onPublish de Cloud Functions traite ce message. Firebase CLI ne prend pas en charge la syntaxe cron directe — le calendrier est configuré via la console Google Cloud ou Terraform au format unix-cron : 0 3 * * * (tous les jours à 3h00).

Exemples de tâches : newsletter quotidienne, nettoyage des données obsolètes, génération de rapports, synchronisation avec des API externes. Important : Cloud Scheduler est un service payant de Google Cloud (environ 2 $ par mois par tâche). Chaque déclenchement compte comme un appel de fonction distinct et est facturé aux tarifs standard de Cloud Functions.

Comment écrire et déployer des fonctions

Le développement de Cloud Functions commence par l'initialisation d'un projet via Firebase CLI : firebase init functions. Cette commande crée un répertoire functions/ avec un modèle index.js (ou index.ts), un fichier package.json et une configuration TypeScript (si sélectionné). Après l'initialisation, il suffit d'écrire une fonction, de l'exporter depuis le module et d'exécuter firebase deploy --only functions pour la déployer.

Chaque fonction est enregistrée en appelant la méthode de déclencheur appropriée. Exemple d'une fonction HTTPS : exports.helloWorld = functions.https.onRequest((req, res) => { res.send(«Hello !»); }). Firebase Functions utilise un modèle asynchrone : pour les déclencheurs basés sur les événements (non HTTPS), la fonction doit retourner une Promise. Firebase attend la résolution de la Promise avant de terminer le conteneur. Si une Promise n'est pas retournée, la fonction peut être terminée avant la fin des opérations asynchrones.

Le développement local se fait via la Firebase Emulator Suite, qui inclut un émulateur Cloud Functions. La commande firebase emulators:start démarre un serveur local avec des fonctions accessibles à l'adresse http://localhost:5001. L'émulateur prend en charge le rechargement à chaud lors des modifications de code et est totalement isolé de l'environnement de production, permettant des tests sans risque pour les données réelles.

Gestion des dépendances et de la configuration

Les dépendances de Cloud Functions sont gérées via package.json. Firebase installe uniquement les dépendances de production (dependencies, pas devDependencies). La taille du paquet de fonctions affecte le temps de démarrage à froid : il est recommandé de minimiser le nombre de dépendances. La dépendance firebase-admin est préinstallée pour le SDK Admin Firebase — il n'est pas nécessaire de l'ajouter manuellement.

Les données confidentielles (clés API, jetons) ne doivent pas être stockées dans le code de la fonction. Utilisez functions.config() pour stocker la configuration : firebase functions:config:set stripe.key=«sk_...». Les valeurs sont chiffrées et disponibles à l'exécution via functions.config().stripe.key. Pour les configurations sérialisées volumineuses, utilisez Google Cloud Secret Manager.

Gestion des erreurs et journalisation

La journalisation dans Cloud Functions se fait via console.log, console.warn et console.error. Tous les journaux sont automatiquement collectés dans Google Cloud Logging et sont disponibles dans la console Firebase (Functions > Logs). Pour une journalisation structurée, utilisez les bibliothèques winston ou pino, qui prennent en charge le formatage JSON et les niveaux de journal.

La gestion des erreurs est cruciale pour la fiabilité : une exception non gérée dans une Promise termine la fonction avec une erreur, après quoi Firebase réessaie automatiquement avec un backoff exponentiel. Le nombre de tentatives est configurable : de 0 à l'infini. Pour les déclencheurs basés sur les événements, il est recommandé d'activer les tentatives pour garantir que chaque événement soit traité même en cas de défaillances temporaires des services externes.

Démarrage à froid et mise à l'échelle

Le démarrage à froid (cold start) est le délai lors du premier appel d'une fonction après une période d'inactivité, lorsque le conteneur avec le code est chargé et initialisé à nouveau. Selon la documentation Firebase (2026), un démarrage à froid prend de 200 ms à 2 secondes selon la taille du paquet, le nombre de dépendances et la région. Pour l'interface utilisateur, un délai supérieur à 1 seconde est perceptible et peut affecter l'expérience utilisateur.

Moyens de minimiser le démarrage à froid : minimiser les dépendances, utiliser TypeScript compilé en CommonJS, réduire la taille du paquet de fonctions, définir un nombre minimum d'instances actives. Firebase Cloud Functions v2 (2e génération) permet de définir minInstances — le nombre minimum de conteneurs chauds toujours prêts à traiter les requêtes. Le maintien des conteneurs chauds entraîne des frais pour le temps d'inactivité.

La mise à l'échelle de Cloud Functions se fait automatiquement : à mesure que le volume de requêtes augmente, Firebase crée de nouveaux conteneurs. Par défaut, le nombre maximal d'instances parallèles est de 3000 (quota du projet Google Cloud). Chaque instance traite une requête à la fois. Si une fonction est rapide (moins de 100 ms), une instance peut traiter jusqu'à 10 requêtes par seconde, offrant un débit de pointe allant jusqu'à 30 000 requêtes par seconde par projet.

Configuration de minInstances et maxInstances

minInstances est un paramètre qui réserve un nombre spécifique de conteneurs et les maintient chauds. Il est recommandé pour les fonctions HTTPS critiques où la latence de démarrage à froid est inacceptable. Par exemple, pour un endpoint d'authentification, définissez minInstances : 1. maxInstances limite le nombre maximal d'instances parallèles, utile pour empêcher une croissance incontrôlée des coûts lors de pics soudains de trafic.

La configuration se fait dans le code : functions.runWith({ minInstances : 1, maxInstances : 10 }). Important : minInstances augmente le coût car les conteneurs fonctionnent en continu. Pour les projets de test, minInstances doit être désactivé. Pour la production, minInstances est recommandé pour toutes les fonctions HTTPS publiques et 0 pour les déclencheurs basés sur les événements où un délai de 1 seconde n'est pas critique.

Régions de déploiement

La région de déploiement affecte la latence pour les utilisateurs finaux et le coût du trafic sortant. Firebase Cloud Functions est disponible dans plus de 30 régions Google Cloud. Pour les applications mobiles, choisissez la région la plus proche de votre public cible : us-central1 pour les Amériques, europe-west1 pour l'Europe, asia-east2 pour l'Asie. La région ne peut pas être modifiée après le déploiement sans redéployer la fonction.

Le changement de région se fait via le paramètre region dans le code : functions.region('europe-west1'). Toutes les fonctions d'un même fichier peuvent avoir des régions différentes. Pour les projets globaux, il est recommandé de déployer des fonctions dans plusieurs régions et d'utiliser Cloud Load Balancing pour distribuer le trafic, bien que pour la plupart des applications mobiles, une seule région soit suffisante si elle est correctement choisie.

Exemples de code pour Firebase Cloud Functions

Examinons des exemples pratiques de Cloud Functions en TypeScript. Le code utilise le SDK Firebase Functions v2 (2e génération) avec la syntaxe des modules ES. Les exemples incluent le traitement d'un événement de création d'utilisateur, la génération d'une vignette lors du téléchargement d'une image et un endpoint HTTPS simple pour une API REST. Toutes les fonctions sont asynchrones et retournent une Promise pour la terminaison correcte du conteneur.

Avant d'exécuter, assurez-vous que Firebase CLI est mis à jour vers la version 13+ : npm install -g firebase-tools. Les fonctions v2 nécessitent le plan tarifaire Blaze. Initialisation : firebase init functions avec TypeScript sélectionné.

Traitement de l'inscription d'un utilisateur

Le premier exemple — la création d'un document dans Firestore lors de l'inscription d'un nouvel utilisateur. La fonction est déclenchée par l'événement auth.user().onCreate et écrit un profil de base dans la collection users/{uid}. Cela garantit que chaque utilisateur inscrit dispose d'un document avec les champs nécessaires.

import * as functions from "firebase-functions"
import * as admin from "firebase-admin"

admin.initializeApp()

export const createUserProfile = functions.auth
    .user()
    .onCreate(async (user) => {
        const profile = {
            email: user.email,
            displayName: user.displayName ?? "User",
            createdAt: admin.firestore.Timestamp.now(),
            role: "free",
            avatarUrl: null,
        }

        await admin.firestore()
            .collection("users")
            .doc(user.uid)
            .set(profile)

        console.log(`Profile created for ${user.uid}`)
    })

La fonction createUserProfile est asynchrone — elle retourne une Promise que Firebase attend avant de se terminer. Si l'écriture dans Firestore échoue (par exemple, en raison de permissions insuffisantes), la fonction sera automatiquement réessayée (si la tentative est activée). Le champ role avec la valeur «free» permet d'implémenter les restrictions du forfait gratuit directement dans les règles de sécurité Firestore en comparant resource.data.role avec le niveau d'accès requis.

Génération de vignettes lors du téléchargement d'images

Le deuxième exemple — un déclencheur Storage pour générer automatiquement une vignette après le téléchargement d'une image. La fonction crée une copie réduite de 200x200 pixels et la sauvegarde dans le chemin du fichier d'origine avec le préfixe thumb_. Le traitement d'images utilise la bibliothèque sharp, qui prend en charge tous les formats courants et fonctionne dans l'environnement Node.js sans dépendances système.

import * as path from "path"
import * as os from "os"
import * as sharp from "sharp"

export const generateThumbnail = functions.storage
    .object()
    .onFinalize(async (object) => {
        if (!object.contentType?.startsWith("image/")) return

        const filePath = object.name!
        const thumbPath = filePath.replace(
            /(\.\w+)$/, "_thumb$1"
        )

        const bucket = admin.storage().bucket()
        const tempDir = os.tmpdir()
        const tempFile = path.join(tempDir, path.basename(filePath))

        await bucket.file(filePath).download({ destination: tempFile })
        await sharp(tempFile)
            .resize(200, 200, { fit: "cover" })
            .toFile(tempFile.replace(/(\.\w+)$/, "_thumb$1"))

        await bucket.upload(tempFile.replace(
            /(\.\w+)$/, "_thumb$1"
        ), { destination: thumbPath })
    })

La fonction generateThumbnail vérifie le Content-Type de l'objet et ignore les non-images, économisant ainsi des ressources. Pour utiliser sharp, la dépendance doit être ajoutée à package.json. La vignette est créée avec le paramètre fit : «cover», qui recadre l'image à partir du centre en un carré de 200x200 pixels. Après la création, la vignette est téléchargée à nouveau dans le même bucket avec un nom modifié.

Endpoint HTTPS pour une API publique

Le troisième exemple — une fonction HTTPS implémentant un endpoint d'API REST pour vérifier l'état du serveur. La fonction accepte une requête GET et retourne du JSON avec des informations sur l'état des services Firebase connectés au projet. Cet endpoint est utile pour la surveillance et les systèmes externes qui doivent vérifier la disponibilité du backend avant d'envoyer des données.

import * as express from "express"

const app = express.Router()

app.get("/status", async (req, res) => {
    try {
        const db = admin.firestore()
        await db.collection("_health").doc("check").get()
        res.json({ status: "ok", timestamp: Date.now() })
    } catch (error) {
        res.status(503).json({ status: "error", message: error })
    }
})

export const api = functions.https.onRequest(app)

La fonction api utilise express Router pour le routage, ce qui est pratique lors de la création de plusieurs endpoints dans une seule fonction. La vérification de santé écrit dans Firestore dans la collection _health, permettant de vérifier simultanément la disponibilité de Firestore. Pour la production, il est recommandé d'ajouter une authentification de requête via une clé API ou un jeton Firebase Auth pour éviter les abus de l'endpoint public.

Cas d'utilisation typiques dans les applications mobiles

Cloud Functions sont le plus souvent utilisées pour des tâches qui ne peuvent pas ou ne doivent pas être effectuées sur le client : envoi de notifications push, génération d'aperçus d'images téléchargées, intégration avec des systèmes de paiement externes, modération de contenu, synchronisation de données entre Firebase et des services tiers. Le modèle sans serveur rend ces tâches économiques : vous ne payez que pour le temps d'exécution réel du code.

L'intégration avec les systèmes de paiement est un scénario typique pour les applications avec achats intégrés. Cloud Functions reçoit un webhook du fournisseur de paiement (Stripe, PayPal), vérifie la signature de la requête, met à jour le statut de l'abonnement dans Firestore et envoie une confirmation à l'utilisateur. Tout le code s'exécute sur le serveur sans risque de falsification des données sur le client. Selon la documentation Stripe (2026), le traitement du webhook prend moins de 500 ms.

La modération intelligente de contenu utilise un déclencheur Storage de Cloud Function pour vérifier automatiquement les images téléchargées via Google Cloud Vision API. La fonction envoie l'image à l'API Vision pour détecter le contenu non sécurisé (violence, contenu pour adultes) et, si le seuil est dépassé, supprime le fichier et notifie l'administrateur. Ce scénario est essentiel pour les applications UGC avec des galeries d'utilisateurs.

L'agrégation de données — Cloud Functions comme remplacement des compteurs Firebase Realtime Database. Au lieu de lire et d'écrire un compteur sur le client (ce qui entraîne des conditions de concurrence), utilisez un déclencheur onWrite Firestore pour des mises à jour atomiques de champs agrégés. Par exemple, une fonction compte le nombre de likes d'un article chaque fois qu'un document est ajouté ou supprimé dans la sous-collection /posts/{postId}/likes/{userId} et met à jour le champ likesCount dans le document parent.