En tant que quelqu’un né au début des années 1990, je dis souvent que ma génération a été la dernière à ne pas être née dans le cloud.

J’ai commencé ma carrière chez Dailymotion, qui exploitait à l’époque deux datacenters et son propre Autonomous System. Tout était on-premise, avec toutes les contraintes que cela implique sur le software delivery, le réseau et la gestion du stockage. Les outages étaient moins abstraits mais plus difficiles à atténuer : il n’y avait pas de capacité de scaling infinie, dupliquer les données entre sites était un vrai débat de coût, et quand quelque chose cassait à 3h du matin, nous étions seuls.

Le cloud et les containers sont devenus populaires pendant que j’y travaillais. Comme chaque grand changement technologique, cela a apporté son lot de discussions, de désaccords et de nouveaux défis. Progressivement, notre stack d’infrastructure est devenue hybride et de nombreuses fonctionnalités ont été released dans le cloud car plus rapides en pratique. Finalement, Dailymotion a migré son infrastructure vers le cloud, et j’ai suivi le mouvement.

Quand le cloud a tout repris

Le vrai déclic est arrivé quand les premières primitives du cloud ont commencé à être combinées en offres PaaS. Soudain, on pouvait shipper un web service avec une database qui scale automatiquement ses ressources et une storage virtuellement illimitée derrière. À cet égard, les premières specs de l’architecture Cedar de Heroku étaient bluffantes.

D’un coup, shipper une idée de 0 à la production en une seule journée semblait possible. Les startups n’avaient plus besoin de construire des fondations d’infrastructure physique, le cloud et les containers en particulier en avaient fait le problème de quelqu’un d’autre.

Tout semblait léger et facile, confirmant que « cloud computing » était définitivement le bon nom.

Les coûts du cloud à l’époque

Avec la loi de Moore plus vivante que jamais, soyons honnêtes : une fois qu’on adopte des architectures cloud-native (autoscaling, spot instances, etc.) et qu’on cède à l’abondance de crédits gratuits payés par l’argent des VC, le cloud semblait même un peu moins cher.

Même aujourd’hui, avoir la plus petite instance chez Scaleway ou GCP reste très bon marché :

Prix on-demand dans la région standard la moins chère, hors taxes. Prix à août 2026.

Le coût des abstractions

De plus en plus de managed services

Pour être juste, la plupart des managed services apportent une vraie valeur : managed databases, message queues, object storage, serverless functions, plateformes d’observabilité. Ils évitent aux équipes d’opérer une infrastructure complexe et leur permettent de se concentrer sur le shipping produit. Le trade-off est double : ils sont systématiquement plus chers que de faire tourner l’équivalent soi-même, et chacun d’entre eux renforce le vendor lock-in. Chaque managed service que vous adoptez est une abstraction supplémentaire dont vous dépendez, une autre API à laquelle votre code est couplé, et une chose supplémentaire qui serait douloureuse à remplacer. Les providers le savent, et leur pricing le reflète.

Kubernetes est génial pour une multitude de raisons, mais il n’est pas gratuit. Pour une application single-node, ça n’a aucun sens. Pourtant, vous payez pour le control plane, les managed add-ons, la stack d’observabilité, et la liste sans cesse croissante de services dont votre provider veut que vous dépendiez. Chaque nouveau managed service est une ligne de facture supplémentaire que vous ne pouvez pas facilement retirer.

De plus en plus cher

Selon Gartner, les dépenses des utilisateurs finaux en services de cloud public ont augmenté de 595,7 milliards de dollars en 2024 à un forecast de 723,4 milliards en 2025, soit une hausse de 21% d’une année sur l’autre. Le marché global du cloud computing est passé de 156,4 milliards de dollars en 2020 à 912,77 milliards en 2025.

Ce n’est pas qu’une croissance d’adoption : les providers cloud ont augmenté leurs prix de manière très significative au fil des années. Le Producer Price Index du U.S. Bureau of Labor Statistics suit des augmentations mensuelles dans les services de traitement de données, et TechTarget rapporte que la tendance d’inflation du cloud ne montre aucun signe d’arrêt.

Des facturations cryptiques

C’est vraiment difficile de savoir ce qu’on paie. Vraiment difficile.

Une seule facture cloud peut comporter des centaines de millions, parfois des milliards, de lignes de données. Un Amazon Cost and Usage Report est trop volumineux pour être chargé dans Excel en une seule fois ; Amazon découpe son rapport mensuel en de nombreux fichiers séparés. Bon courage pour les comprendre. En fait, certaines entreprises de FinOps ont été créées presque exclusivement pour vous aider à naviguer dans vos coûts !

Plus de 20% des organisations disent n’avoir que peu ou pas d’idée du coût des différents aspects de leur business par rapport au cloud (CloudZero, State of Cloud Cost 2024). Difficile à dessein, peut-être ?

Et le fun dans tout ça ?

Appeler des APIs, se sentir parfois déconnecté du monde physique réel. Pire : en tant qu’employé, ne pas toujours prêter attention à la facture, devenir dépendant des ressources illimitées.

Pour moi, le fun résidait ailleurs : build de software, création de features et génération de valeur pour nos clients et l’entreprise avec des gens formidables !

Être orienté impact ≠ être contre le fun

Une curiosité qui démange

J’ai eu la chance de témoigner d’innombrables exemples de personnes parlant avec passion de leurs homelabs, des choses qu’elles aimaient construire chez elles et de la puissance que cela avait. Qui n’a pas ? Nous connaissons tous au moins une personne faisant l’éloge de Proxmox, NixOS, ou… de son tout nouveau homelab IA !

Bien que j’aimais voir la passion de ces personnes, en tant qu’ingénieur très orienté impact et productivité, je ne comprenais pas l’impact concret de tous ces homelabs. De plus, je trouvais que payer un provider pour gérer ça à ma place était un soulagement ! Pas besoin de vérifier la facture d’électricité, pas de problème de connectivité à atténuer, pas de configuration réseau complexe, juste de la capacité de calcul pure sans le tracas. Cela ressemblait à se débarrasser d’une complexité inutile pour se concentrer sur la livraison de valeur.

Je suis resté curieux et appréciatif, mais j’ai opté out pendant 15 ans.

Finalement, un besoin

Un projet récent (bouine), un cache HTTP open-source sur lequel je travaille, nécessitait une puissance de calcul, de la RAM et de la connectivité significatives. J’avais besoin de CI runners self-hosted, y compris pour faire tourner des benchmarks et des stress tests. J’avais besoin d’une VM stable pour héberger un site de documentation. Et je voulais faire tourner un petit modèle d’IA pour build des features « intelligentes ».

J’ai commencé à regarder les prix et j’ai pris une machine Elastic bare-metal chez Scaleway. C’était tellement plus rapide que les instances cloud ! J’avais oublié à quel point les vCPUs ne sont définitivement pas des CPUs. Tellement bon marché pour ce qu’on obtient ! Pourtant, les instances dont j’avais besoin restaient super chères pour avoir le nombre de CPUs et la quantité de RAM nécessaires.

Puis soudain, ça m’a frappé : et si j’achetais un serveur pas cher ?

Première vérification sur ServerMall.

L’investissement

Un Dell R640 reconditionné (10SFF) était la réponse :

• CPU : 2 × Intel Xeon Silver 4214 (12C, 2.20GHz) — 24 cores, 48 threads
• RAM : 4 × 32GB DDR4 RDIMM 2400MHz — 128GB au total
• Storage : RAID Dell PERC H330 Mini, 2 × 240GB SSD en RAID1 + 1 × 1TB SSD
• Management : iDRAC Enterprise
• Power : Double alimentation 750W
• Pas de GPU pour l’instant (bientôt)

Autour de 3 000 €. Un investissement unique qui aurait couvert peut-être trois mois de capacité cloud équivalente.¹

Beaucoup de fun !

Et voilà ce dont personne ne vous avertit : c’est fun. Profondément, véritablelement fun.

Ça a commencé par l’unboxing, je ne consomme pas beaucoup de tech, donc c’était déjà un thrill. Puis le premier boot, le bourdonnement des ventilateurs, l’interface iDRAC qui s’allume.

Soudain, je me posais des questions que je n’envisageais pas dans le cloud : est-ce que je devrais run un cluster HPC Kubernetes directement, ou des VMs Proxmox avec Kubernetes à l’intérieur ? RAID1 ou RAID0 pour les disques OS ? Quelle configuration dans iDRAC pour le remote management ?

Puis vint l’apprentissage de Proxmox, et réaliser à quel point j’avais oublié de choses sur la virtualisation, l’allocation de ressources, et la satisfaction tranquille de voir une VM migrer d’un node à l’autre sans perdre de connexion.

Lancer des load tests intenses et voir la machine les gérer sans problème, pas de throttling, pas de noisy neighbors, pas de facture surprise en fin de mois. Juste de la capacité déterministe et possédée.

Partager l’accès via Tailscale avec des amis pour collaborer sur des projets. Voir ma facture GitHub Actions diminuer en remplaçant des cloud runners par les miens. Le genre de fun que je n’avais pas ressenti depuis mes débuts chez Dailymotion.

Connaissances et contraintes

Je promets que je ne vais pas me vanter de ma configuration Proxmox, mais je prends maintenant du plaisir à la fine-tuner, à améliorer l’allocation de ressources, la resiliency, et à automatiser la maintenance.

Je (ré)apprends aussi beaucoup de choses sur les contraintes spécifiques du hardware et du réseau, ainsi que de nouvelles choses comme iDRAC, les stratégies de consommation électrique, et la satisfaction tranquille d’un serveur bien racké.

Il est important de mentionner également que l’IA a rendu beaucoup de ces défis faciles à relever. Elle est devenue un bon sparring partner et guide tout au long de ce parcours. Bien qu’il soit toujours possible et recommandé d’apprendre via des livres et des vidéos, il est devenu vraiment simple de combler les lacunes de connaissances nécessaires pour opérer son homelab.

Mon instinct pro-risque en ferait même un choix immédiatement viable après la phase de POC/Pitch d’une startup, purement grâce à l’IA.

Et maintenant ?

Je vais rack la machine très prochainement dans un datacenter DC2Scale. Pas chez moi, pour trois raisons :

1. Ma copine me fera à juste titre remarquer que le bruit et la chaleur de ce sweet 1U ne sont pas les bienvenus à la maison
2. Je veux en apprendre plus sur l’opération dans des datacenters, dans des conditions thermiques et réseau optimales, et peut-être avec plusieurs machines
3. Plus tard, j’aurai probablement envie d’apprendre à opérer un Autonomous System, mais c’est une autre histoire

Je posterai probablement d’autres articles pour partager plus de choses sur ce sur quoi je travaille. Rejoignez le mouvement, amusez-vous à expérimenter ! Faites-moi confiance, nous sommes nombreux à avoir oublié à quel point c’est fun.