Vous construisez du serverless ? Voici ce qu'on ne vous dit pas.

Temps de lecture : 5 minutes Ambiance : Un café avec un pote qui bosse dans le cloud

---

Soyons honnêtes

Le serverless, ça semble magique. Vous écrivez du code, vous déployez, et paf, magie. Pas de serveurs. Pas d'ops. Juste de la fonctionnalité pure.

Et puis vous essayez. Et votre premier utilisateur attend cinq secondes à cause d'un démarrage à froid. Ou votre fonction s'arrête au bout de quinze minutes. Ou la facture cloud arrive et vous vous étouffez avec votre café.

Voici le truc : Le "serverless" n'est pas une seule et même chose.

Il y a le serverless AWS Lambda (celui où AWS fait tout pour vous). Et il y a le serverless sur Kubernetes (celui où vous avez plus de contrôle mais aussi plus de responsabilités).

Et le langage de programmation qui fonctionne parfaitement sur l'un va complètement vous détruire sur l'autre.

Laissez-moi vous montrer ce que je veux dire à travers cinq projets réels que vous pourriez construire.

---

Projet 1 : Le petit bot qui va checker un truc toutes les heures

Ce que c'est : Un petit truc qui se réveille toutes les heures, va checker une base de données, et envoie un message sur Slack. C'est tout. Il dort le reste du temps.

Ce qui se passe réellement : Rien pendant 59 minutes. Puis il s'anime pendant deux secondes. Puis retour au dodo.

La bonne décision : Mettez ça sur AWS Lambda. Écrivez-le en Python ou Node.js.

Pourquoi : Parce que les départs à froid n'ont pas beaucoup d'importance ici. Quelques centaines de millisecondes de délai ? On s'en fiche. Le bot envoie juste un message Slack.

Ce que les gens font de travers : Quelqu'un dit : "Utilisons Rust pour les performances !" Rust est incroyable. Mais pour un bot qui tourne deux secondes par heure ? Vous ne verrez jamais la différence. En revanche, vous galèrerez à trouver quelqu'un d'autre qui connaît Rust quand cette personne partira.

La vérité : Utilisez l'outil simple. Gardez les outils sophistiqués pour les problèmes difficiles.

---

Projet 2 : La page de paiement qui prend cher tous les lundis matin

Ce que c'est : Le tunnel d'achat d'un site e-commerce. La semaine, c'est calme. Mais tous les lundis à 9h, dix mille personnes cliquent sur "acheter" en même temps. Si la page met plus d'un quart de seconde à répondre, les gens partent acheter ailleurs.

Ce qui se passe réellement : À 8h59, zéro fonction tourne. À 9h00, le raz-de-marée arrive. Les premiers utilisateurs déclenchent des départs à froid. Ils attendent. Certains se cassent.

La bonne décision : AWS Lambda aussi, mais avec Node.js plutôt que Python.

Pourquoi : Node.js démarre plus vite. On parle de 50ms contre 200ms. Cette différence compte pour le premier utilisateur du lundi matin.

Ce que les gens font de travers : Un spécialiste des données dit : "J'adore pandas, utilisons Python !" Pandas est génial pour l'analyse. Mais le charger ajoute une demi-seconde au démarrage. Votre premier utilisateur du lundi est timeout. Vous perdez la vente.

La vérité : Les départs à froid sont invisibles jusqu'à ce qu'ils vous coûtent de l'argent. Là, vous ne pensez plus qu'à ça.

---

Projet 3 : Le processeur vidéo qui tourne deux heures d'affilée

Ce que c'est : Une plateforme où les gens uploadent des vidéos 4K. Votre système les compresse, ajoute un watermark, et génère une miniature. Chaque vidéo prend entre vingt minutes et deux heures à traiter.

Ce qui se passe réellement : AWS Lambda a un timeout strict à quinze minutes. Votre job de deux heures meurt en plein milieu.

La bonne décision : Serverless sur Kubernetes (avec Knative ou OpenFaaS par exemple). Cela permet d'exécuter des fonctions qui prennent des heures. Cela permet aussi d'attacher des GPU si vous en avez besoin pour encoder plus vite.

Pourquoi : Parce que quinze minutes ne suffisent pas. Vous avez besoin d'heures. Kubernetes ne regarde pas votre montre.

Ce que les gens font de travers : Quelqu'un dit : "Réécrivons l'encodeur vidéo en Rust pour des performances max." Non. FFmpeg a été optimisé par des centaines de personnes pendant trente ans. Vous ne ferez pas mieux. Appelez FFmpeg depuis le langage que vous voulez.

La vérité : Parfois, le bon outil est celui qui est un peu ennuyeux et qui fonctionne.

---

Projet 4 : Le détecteur de fraude qui doit répondre en millisecondes

Ce que c'est : Un processeur de paiement qui vérifie chaque transaction contre cinquante règles métier, trois APIs externes, et un cache. Il doit répondre "fraude ou pas fraude" en moins de 80 millisecondes. Les banques sont auditées là-dessus. Les régulateurs surveillent.

Ce qui se passe réellement : Vous avez 200 000 lignes de code Java existant, remplies de règles complexes. Vous ne pouvez pas réécrire ça. Mais un Java standard met 8 secondes à démarrer. Votre première transaction de la journée sera timeout.

La bonne décision : Serverless sur Kubernetes, mais avec une version spéciale de Java appelée GraalVM. Elle compile votre code Java en un binaire natif qui démarre en 150 millisecondes au lieu de 8 secondes.

Pourquoi : Parce que vous gardez votre code existant. Pas de réécriture. Pas de projet de six mois. Juste une façon plus rapide d'exécuter ce que vous avez déjà.

Ce que les gens font de travers : "Utilisons Java standard sur Kubernetes." Java standard met 8 secondes à démarrer. Votre détecteur de fraude va rater les premières transactions à chaque passage à l'échelle. Ça représente de l'argent réel perdu à cause de la fraude.

Autre erreur : "Réécrivons tout en Go." C'est un projet de six mois avec un risque élevé de casser les règles métier. Votre équipe va vous détester.

La vérité : Moderniser est souvent meilleur que réécrire. Gardez le code qui fonctionne. Rendez-le juste plus rapide au démarrage.

---

Projet 5 : Le capteur d'usine qui vit avec presque pas de mémoire

Ce que c'est : Un petit ordinateur dans une usine. Mille capteurs envoient des données toutes les deux cents millisecondes. L'ordinateur valide les données, les agrège, et les envoie vers le cloud. L'ordinateur n'a que 4 Go de RAM au total.

Ce qui se passe réellement : Chaque milliseconde compte. Les pauses du ramasse-miettes sont inacceptables. La mémoire est extrêmement limitée.

La bonne décision : Serverless sur Kubernetes léger (comme K3s) tournant en périphérie. Écrit en Rust.

Pourquoi : Rust utilise presque pas de mémoire. Il n'a pas de pauses de ramasse-miettes. Il démarre instantanément. Il a été construit pour ce scénario.

Ce que les gens font de travers : "Je connais Python, je peux apprendre Rust sur le tas." Rust a une courbe d'apprentissage brutale. Il faut six mois pour devenir vraiment productif. Votre usine ne peut pas attendre six mois.

La vérité : Rust est génial mais difficile. Trouvez quelqu'un qui le connaît déjà. La courbe d'apprentissage est réelle.

---

Tableau récapitulatif — Quel langage pour quel projet

---

Alors, comment réfléchir à votre propre projet ?

Posez-vous une seule question :

"Quand ce truc se réveille de zéro, à quelle vitesse doit-il répondre ?"

Si la réponse est "quelques centaines de millisecondes, ça va" → Vous êtes chez AWS Lambda avec Python ou Node.js. C'est la plupart des projets. La vie est belle. Restez simple.

Si la réponse est "moins de 100ms, mais j'ai du code Java existant" → Vous êtes sur le territoire GraalVM sur Kubernetes. Vous gardez votre code. Vous avez juste besoin de l'exécuter plus intelligemment.

Si la réponse est "moins de 10ms et j'ai 4 Go de RAM au total" → Vous êtes chez Rust sur Kubernetes en périphérie. Amenez un spécialiste systèmes. C'est le truc difficile.

Si la réponse est "je m'en fiche, ça tourne deux heures" → Vous êtes dans la zone "tout est possible". Choisissez le langage que vous voulez. Assurez-vous juste que votre plateforme n'a pas de timeout.

---

Guide de choix : plateforme et langage

---

La chose que j'aurais aimé qu'on me dise plus tôt

La plupart des projets ressemblent au premier. Le bot Slack. L'API simple. Vous pouvez utiliser Python ou Node.js sur Lambda et ça marche très bien.

Mais les projets qui échouent — les détecteurs de fraude qui ratent des transactions, les équipements en périphérie qui manquent de mémoire, les pages de paiement qui timeout le lundi matin — ceux-là échouent parce que quelqu'un les a traités comme le premier projet.

Ils ont utilisé l'outil simple pour un problème complexe. Ils n'ont pas pensé aux départs à froid. Ils n'ont pas réalisé que leur choix de langage comptait.

Adaptez l'outil au problème. Pas à la mode.

---

Dernière pensée

Si vous construisez quelque chose, commencez par vous demander comment ce truc se comporte quand personne ne l'utilise.

Est-ce qu'il dort ? Est-ce qu'il se réveille vite ? Est-ce qu'il doit rester chaud tout le temps ?

Les réponses à ces questions vous en diront plus que n'importe quel article sur le "meilleur" langage.

Maintenant, allez construire un truc cool.

---

Vous avez aimé ? Nous aidons les gens à choisir les bons outils pour les bons problèmes sur Quopa.io. Passez dire bonjour.