Dans le modèle d’hébergement traditionnel (EC2, DigitalOcean), vous louez un ordinateur. Vous payez 50 €/mois. Si personne ne visite votre site à 3h00 du matin, l’ordinateur reste inactif. Vous payez toujours. Si 100 000 personnes visitent le site à 10h00, l’ordinateur tombe en panne. Vous perdez des revenus.

C’est le dilemme de la planification des capacités. Vous devez strictement surprovisionner pour gérer les pics, ce qui signifie que vous payez trop cher 99 % du temps.

Serverless (FaaS) retourne le modèle. Vous ne louez pas d’ordinateur. Vous téléchargez le code. Vous payez par invocation.

0 visite = 0,00 €.
1 million de visites = AWS lance 1 000 fonctions simultanées. Vous payez exactement 1 million de secondes d’exécution.

Chez Maison Code Paris, nous utilisons le Serverless non seulement pour le coût, mais aussi pour la simplicité opérationnelle. Nous ne corrigeons pas les noyaux Linux. Nous ne faisons pas de rotation des clés SSH. Nous nous concentrons sur la logique.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Pourquoi Maison Code adopte d’abord le sans serveur

Nous traitons les infrastructures comme un passif et non comme un atout. Chaque serveur que nous gérons est un serveur qui peut tomber en panne. Notre philosophie « Scale-to-Zero » s’aligne sur le P&L de nos clients :

Efficacité : nous avons migré les tâches cron héritées d’un client d’un EC2 dédié à 100 €/mois vers Lambda. Le coût est tombé à 0,12 €/mois.
Résilience : lors du Black Friday, nos points de terminaison sans serveur ont atteint 5 000 exécutions simultanées sans un seul délai d’attente.
Focus : Nos ingénieurs passent 100 % de leur temps sur la logique métier (Prix, Panier, Paiement), et non sur l’orchestration Docker.

Architecture : modèles pilotés par les événements

Le sans serveur est préférable lorsqu’il est asynchrone. Bien que vous pouviez exécuter une API standard (GET /users), le véritable pouvoir réside dans Event Sourcing.

Le modèle de tampon (SQS + Lambda)

Scénario : Vous organisez une vente flash. 10 000 utilisateurs effectuent un paiement en 1 seconde. Si vous connectez Lambda directement à votre ERP (SAP/NetSuite), vous effectuerez une dDoS sur votre propre ERP. Il ne peut pas gérer 10 000 connexions.

Solution :

API Gateway : accepte la requête HTTP. Renvoie « 202 acceptés ».
SQS (Simple Queue Service) : stocke la demande dans une file d’attente. Il peut contenir des millions de messages.
Lambda : interroge la file d’attente. Il traite les messages à un rythme contrôlé (par exemple, 50 à la fois).
Résultat : Votre ERP reçoit un flux constant de commandes, pas un tsunami. L’utilisateur obtient une réponse rapide.

Gestion des échecs : la file d’attente des lettres mortes (DLQ)

Dans un serveur Node.js, si une requête plante, elle est perdue. Dans Serverless, nous configurons les Retries. AWS Lambda réessayera automatiquement une fonction asynchrone ayant échoué 2 fois. S’il échoue toujours (par exemple, un bug dans le code), il déplace l’événement vers une file d’attente de lettres mortes (DLQ). Les ingénieurs peuvent inspecter le DLQ, corriger le bug et « repiloter » les messages. Aucune donnée n’est perdue.

Le problème du démarrage à froid

Les ressources ne sont pas gratuites. Pour économiser de l’argent, AWS arrête votre conteneur s’il n’a pas été utilisé pendant environ 15 minutes. La requête suivante déclenche un Cold Start.

AWS alloue une microVM (Firecracker).
Télécharge votre code.
Démarre Node.js.
Exécute votre gestionnaire.

Latence : ~300 ms - 1 s (Node.js). ~3s (Java). Impact : Très bien pour les tâches en arrière-plan. Mauvais pour les API de paiement.

La solution : Vercel Edge Runtime (isolats V8)

Vercel (et Cloudflare Workers) ont introduit un nouveau runtime. Au lieu de démarrer un conteneur Node.js complet (VM + OS + Node), ils s’exécutent sur V8 Isolates. Il s’agit du même moteur qui exécute JavaScript dans Chrome.

Démarrage à froid : ~0 ms.
Limites : vous ne pouvez pas utiliser les API Node.js comme fs, child_process ou les binaires natifs.
Cas d’utilisation : Middleware, redirection d’authentification, buckets de tests A/B, géo-routage.

Le piège de la base de données : le pooling de connexions

C’est là que 90 % des débutants échouent. Une bibliothèque Postgres standard (pg) ouvre une connexion TCP. Dans un serveur monolithique, vous ouvrez 1 connexion et la partagez. Dans Serverless, chaque fonction est un conteneur isolé. Si vous disposez de 1 000 utilisateurs simultanés, vous ouvrez 1 000 connexions à la base de données. Postgres manque de RAM et plante. FATAL : les emplacements de connexion restants sont réservés.

Solution 1 : regroupement de connexions (PgBouncer) Un service middleware placé devant Postgres. Il contient 1 000 connexions client mais les mappe à 10 connexions DB réelles. DigitalOcean et AWS RDS Proxy en tant que service.

Solution 2 : bases de données HTTP De nouveaux fournisseurs de bases de données (Neon, PlanetScale, Supabase) proposent des API HTTP. Vous n’ouvrez pas de socket TCP. Vous fetch('https://db.neon.tech/query'). HTTP est sans état. Il évolue parfaitement avec Serverless.

// Utilisation de Neon (Postgres sans serveur)
importer {neon} depuis '@neondatabase/serverless' ;

const sql = néon(process.env.DATABASE_URL);

exporter le gestionnaire de fonctions asynchrones (événement) {
  résultat const = attendre sql`SELECT * FROM utilisateurs`;
  return { corps : JSON.stringify(result) } ;
}

Gestion de l’état : il n’y a pas de mémoire

Sur un serveur normal, vous pouvez faire : laissez requestCount = 0 ; app.get('/', () => requestCount++); Dans Serverless, requestCount sera effectivement toujours 1 ou 0. Le conteneur est détruit après exécution. Les variables globales sont effacées.

Règle : Tous les états doivent être externes.

Données de session -> Redis.
Données utilisateur -> Base de données.
Téléchargements de fichiers -> S3 / Stockage Blob. N’écrivez pas dans /tmp (il disparaît). N’utilisez pas de variables globales.

Analyse des coûts : le point de bascule

Le sans serveur n’est pas toujours moins cher. Il a un « balisage » sur le calcul brut (~ 2x coût par cycle CPU par rapport à EC2). Les économies proviennent de 0 % de temps d’inactivité.

Faible trafic / Trafic intense : le sans serveur est 90 % moins cher.
Charge élevée constante : si vous avez un processus exécuté 24h/24 et 7j/7 (comme un serveur WebSocket ou un traitement de données important), EC2 est moins cher. Nous réalisons des audits TCO (Total Cost of Ownership) pour nos clients. Souvent, le coût opérationnel de la gestion d’EC2 (correctifs, sécurité) fait du sans serveur le gagnant, même pour des volumes plus élevés.

Code : Route de l’API Vercel (meilleures pratiques)

Nous structurons nos fonctions pour qu’elles soient testables, en séparant la logique du réseau.

// app/api/checkout/route.ts (routeur d'application Next.js)
importer { NextResponse } depuis 'suivant/serveur' ;
importer { createCheckout } depuis '@/lib/checkout' ; // Logique métier

// Le gestionnaire (couche réseau)
exporter la fonction asynchrone POST (requête : requête) {
  essayez {
    const body = wait request.json();
    
    // Valider l'entrée (Zod)
    si (!body.cartId) {
      return NextResponse.json({ error : 'Missing Cart ID' }, { status: 400 });
    }

    // Logique d'appel
    const url = wait createCheckout(body.cartId);

    return NextResponse.json({ url });
  } attraper (erreur) {
    console.erreur(erreur); // Journaux vers CloudWatch / Datadog
    return NextResponse.json({ error : 'Internal Error' }, { status: 500 });
  }
}

10. Observabilité : traçage distribué

Dans un monolithe, vous grep server.log. Dans Serverless, une requête d’utilisateur unique atteint API Gateway -> Lambda A -> SQS -> Lambda B -> DynamoDB. S’il échoue, où a-t-il échoué ? Vous ne pouvez pas récupérer les journaux de 5 services. Nous implémentons le Distributed Tracing (OpenTelemetry / AWS X-Ray). Nous transmettons un en-tête trace_id à chaque service. Cela génère un « Flame Graph » montrant exactement où le pic de latence s’est produit (par exemple, « Lambda B a pris 3 secondes parce que DynamoDB était en limitation »).

11. Le mythe du verrouillage du fournisseur

Les évaluateurs disent souvent : « Le sans serveur vous enferme dans AWS ». Vrai. Mais Docker vous enferme dans le noyau Linux. React vous enferme dans le DOM virtuel. Le verrouillage est inévitable. La question est : “Le verrouillage vaut-il la vélocité ?” Nous pouvons réécrire une fonction Lambda dans Go/Rust en 1 jour. Le coût de la migration loin du sans serveur est faible car les unités de code sont petites. Le coût de ne pas utiliser Serverless (gestion des flottes EC2) est élevé et continu.

13. Sécurité : moindre privilège (IAM)

Un Lambda = Un rôle. Ne donnez pas à votre Lambda « AdministratorAccess ». Si ce Lambda est compromis (injection de dépendances), l’attaquant est propriétaire de votre compte. Donnez-le : s3:GetObject sur bucket-a UNIQUEMENT. Ce modèle de sécurité granulaire est supérieur à un Monolith où l’ensemble du serveur a un accès root à la base de données. Des outils tels que SST (Serverless Stack) automatisent cette génération de stratégies : bucket.grantRead(lambda) génère automatiquement la stratégie IAM stricte.

14. Frameworks : Pourquoi nous utilisons SST

Raw CloudFormation est douloureux. Terraform est verbeux. Nous utilisons SST (Serverless Stack). Cela nous permet de définir l’infrastructure en TypeScript. Il permet le « développement Live Lambda » (proxy d’environnement local vers AWS). Vous définissez des points d’arrêt dans VS Code, atteignez un point de terminaison et il s’arrête à l’intérieur du Lambda exécuté sur AWS. C’est le seul moyen de développer Serverless de manière saine.

15. Conclusion

Les fonctions sans serveur sont le ciment de l’Internet moderne. Ils permettent aux ingénieurs frontend de devenir « Full Stack » sans avoir besoin d’un diplôme en administration Linux. Ils évoluent à l’infini. Ils ne coûtent rien lorsqu’ils sont inutilisés. Mais ils nécessitent une mentalité « apatride » disciplinée.

Vous payez pour une disponibilité inactive ?

Utilisez-vous un serveur à 100 € pour un travail qui prend 5 secondes par jour ? Engagez nos Architectes.