De retour de Cloud Nord 2026

Comme je vous l’avais annoncé en septembre, j’étais cette année à Cloud Nord, à Lille, pour y donner un talk “inédit” : “J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.”

Enchaînement un peu sportif pour moi, puisque la veille au matin j’étais encore à BDX I/O pour dédicacer mon livre (cf mon post précédent).

Direction ensuite Lille dans le train, puisque Cloud Nord, c’était le vendredi 30 octobre.

Pour ceux qui ne connaissent pas : Cloud Nord, c’est une conférence communautaire nordiste organisée par des bénévoles, historiquement très orientée cloud et devops (forcément), avec un programme dense, et 2-3 tracks en parallèle.

Et comme d’habitude, voici mon récap des talks que j’ai vus.

Keynote d’ouverture : IA, souveraineté et cloud

La journée a commencé par une keynote de Patrick Perrot, général à l’Inspection Générale de la Gendarmerie nationale. Un profil un peu inattendu pour ouvrir une conf cloud.

Avoir l’opinion d’un fonctionnaire sur la vision de ce qu’est la “souveraineté” (sous des prismes particuliers, ou plus généralement) était assez intéressant. Partir du mythe de la caverne de Platon pour se poser la question des dépendances qu’on a aux géants du web et aux états, en particulier dans l’IA, même open weight, était aussi un exercice intéressant.

“Vous croyez que c’est vous qui décidez par où vous passez quand vous planifiez un trajet avec votre GPS ? Pourtant, c’est déjà vieux, un GPS”

Les machines prennent déjà des décisions pour nous depuis longtemps. Et sur le fameux “humain dans la boucle”, sa réponse, assez cinglante : “je fais confiance à certains humains pour faire trop confiance, par facilité, à l’IA.”

Son opinion :

• Ne pas devenir un vassal technologique, il faut accélérer sur l’IA.
• Quand on choisit un fournisseur : que se passe-t-il s’il nous lâche ? (extraterritorialité des données, réversibilité…)
• Il faut désiloter : les réponses ne sont ni purement juridiques, ni purement techniques, ni purement sécurité. Il faut un panel de compétences.

Je ne suis pas certain de partager à 100% son opinion, mais la réflexion était très intéressante et bien menée. Bonne ouverture.

IA for Ops on Scaleway

À 9h50, Arnaud Gaches (Onepoint) est venu raconter comment il avait utilisé l’IA pour faire de l’ops sur Scaleway.

Note perso : je ne le dirai jamais assez, JAMAIS de dark theme sur une prez en conf 😆.

Arnaud revenait sur un projet entamé en début d’année, avec une V1 déjà présentée dans une autre conférence.

Son postulat de départ “certains devs se vantent de ne plus faire de code, pourquoi on ne fait pas pareil, nous les ops ?”. Le cœur du talk : une infra montée en plusieurs versions, entièrement via des agents “mains en l’air”, humain dans la boucle juste pour valider des actions sensibles.

Cette V2 était une version plus aboutie, avec un focus plus orienté “sécurité d’abord”.

• un agent “orga” qui tourne sur le poste et qui détient les accès (orga, secrets, bucket d’état, IAM)
• un agent dédié à la landing zone pour le réseau + le VPC peering
• n8n, qui commence par demander à orga des droits supplémentaires, validé par l’humain (exemple)
• du finops ajouté au passage
• …

Je n’ai pas été surpris outre mesure par les retours d’Arnaud. Oui, Claude Code est capable de monter une infra relativement complexe et même de l’opérer dans une certaine mesure, en particulier si on fait appel à des produits managés. Claude est aussi assez bon pour croiser de multiples sources d’information pour trouver la root cause d’un incident.

En revanche, Arnaud le dit lui-même :

• l’agent a trop confiance dans la doc… qui peut elle-même avoir été hallucinée par une version précédente
• pas de prise de recul : il essaie de contourner les problèmes trop vite, avec un peu trop de zèle
• installation d’outils tiers sans qu’on lui demande

Ma take perso : je ne suis pas convaincu, on est loin des gains visibles pour la partie “dev”.

Construire une usine agentique pour faire de l’infra, même en managé, c’est encore assez casse-gueule (finops qui dérape très facilement, risques de sécurité assez violents), ça consomme un max de tokens (il a dû passer de Claude Pro à Claude Max car les agents parlent trop entre eux). Mais indubitablement, c’est possible.

“L’IA, c’est un collègue brillant qui revient de vacances… tous les jours.”

Coupable ! Le procès d’un container malveillant dans Kubernetes

À 11h55, quickie de Paul-Alexandre Chrétien (HoppR), sur le format d’un procès.

Le prévenu : une app volontairement vulnérable, qui cumulait les chefs d’inculpation : libs obsolètes, exécution en root, RCE, vol de credentials, dump de la prod. Bref, la VULNAPP dans toute sa splendeur.

Pour la “défense des victimes” (et l’accusation), une stack d’outils que j’ai trouvée bien ficelée :

• trivy-operator et ses CRD vulnReports pour le scan d’images
• Kyverno et ses validatingPolicies pour bloquer à l’admission
• Falco pour la détection à runtime
• Policy Reporter pour centraliser les outputs de trivy + Kyverno + Falco dans un même rapport

Un bon quickie dans lequel il a réussi à mêler slides et démo. Beau boulot pour un premier talk :).

Houston, on a un problème avec ETCD

Je ne vais pas dire que je suis venu à Cloud Nord juste pour voir ce talk, mais on va dire que j’étais VRAIMENT motivé. Alexandre Burgoni et Pierre Zemb, tous deux chez Clever Cloud, sont venus parler d’etcd, du consensus distribué, et de pourquoi les gros acteurs finissent par réécrire leur propre implémentation.

Vous le savez, j’ai pas mal testé le Kubernetes managé de Clever Cloud (voir partie 1 et partie 2), qui a justement la particularité d’utiliser une réécriture de la partie etcd (sur Foundation DB). C’était donc un sujet que j’avais particulièrement envie de creuser.

Vraiment un talk excellent, sur les différents protocoles de consensus dans les infra distribuées, les problématiques que l’implémentation d’etcd a sur les performances de certaines opérations, quelques bugs “rigolos”, récents ou non.

Tout ça pour arriver au constat que non, à l’échelle, on ne peut pas faire proprement du kube (managé) avec etcd. Et c’est la raison pour laquelle les grands cloud providers ont tous fini par réécrire leur propre implémentation d’etcd pour passer à l’échelle.

Pour développer ça sereinement, ils ont fait énormément de simulation déterministe, assisté à grands coups d’IA en cas de divergences entre leur implem et etcd vanilla, une approche très inspirée de la façon dont FoundationDB lui-même a été testé.

Petite question que je n’ai pas pu m’empêcher de poser à la fin :

“Est-ce que vous avez trouvé des bugs d’etcd avec la simulation, ou est-ce que vos LLMs ont reproduit les bugs actuels pour être 100% compliant ?” 😄

Malheureusement non (pour l’instant).

Merci Pierre pour les discussions pendant le dîner des speakers (j’avais été un peu spoil en amont).

Platform Engineering à l’échelle de Decathlon, ce qu’on a appris en 5 ans

À 14h, Christophe Furmaniak (Decathlon) pour un REX sur 5 ans de platform engineering. La promesse de départ : des environnements en 20 minutes ; le défi réel : l’expérience développeur.

Je ne sais pas trop quoi penser de ce talk.

Objectivement le travail de l’équipe platform engineering chez Decathlon est titanesque, pas de doute là-dessus.

Cependant, ce que Christophe vend comme de la complexité nécessaire (une grosse stack terraform, avec plusieurs versions du moteur en // selon les équipes, des bots qui proposent des mises à jour automatiques parce que sinon il y a des retardataires, 1000 projets sur GCP au point qu’on ne sait plus qui est responsable de quoi, ou s’il faut nettoyer un projet) me paraît être de la complexité accidentelle.

Cependant, je reconnais bien volontiers que je ne travaille pas dans des contextes similaires.

Talk que j’aurais voulu voir en même temps : “Construire un Data Center dans son garage” (Aeddis Desauw, OVHcloud)

Pause avant ma conf

J’avoue avoir fait l’impasse sur le créneau de 15h45.

J’étais dans la salle pour “A la croisée de la DevEx et de GitLab” mais j’ai rien écouté : j’avais prévu 2 pi, donc un de secours pour mes démos. Et justement le pi de secours était cramé (base bbolt de containerd HS).

Donc j’étais content d’avoir un peu de temps pour fix ça (à l’arrache 😅).

J’ai mis Kubernetes dans 512 Mo de RAM. Et il restait de la place pour DOOM.

16h40, salle Amphi St Louis : mon talk, celui que je ne donnerai a priori qu’une seule fois.

Le pitch, pour ceux qui n’étaient pas là : faire rentrer Kubernetes sur un Raspberry Pi Zero 2 W (512 Mo de RAM, 20 $).

Une grosse partie du talk repose sur toute l’optimisation de Raspberry Pi OS Lite (la distrib officielle pour le pi zero, affreusement pas optimisée), mais aussi en jouant avec des recoins moins connus de Linux (notamment KubeSolo, que j’avais présenté dans Sysops Pratique).

Et en conclusion, le stress test le plus sérieux qui soit : Does it run DOOM ?

La réponse est oui, on a pu lancer DOOM, jouer en VNC, et même scaler DOOM à 9 replicas, en live, devant une 50aine de personnes.

J’ai eu des supers questions à l’issue du talk, et après. Merci à tous les présents.

Fin de journée

Pour clôturer la journée, le dernier créneau proposait deux quickies, dont “Maintenir une app bénévole : Tech, galères et résilience” de Seb Ferrer (OVHcloud). Je regrette de ne pas y être allé, car j’avais envie de voir si j’avais gagné au quizz du matin.

(Spoiler : le leaderboard a bougé après cette photo… je n’ai donc rien gagné 😆.)

L’avantage, c’est que ça m’a permis d’avoir des chouettes discussions dans les couloirs avec des gens qui ont vu mon talk et qui ont apprécié :).

Remerciements

Comme toujours, un immense merci à l’équipe d’organisation de Cloud Nord et à tous les bénévoles et une mention particulière pour m’avoir contacté au dernier moment pour remplacer un speaker défaillant. J’espère que le remplaçant était à la hauteur 😄.

Ces journées de conf, c’est aussi et surtout les rencontres dans les couloirs. Merci à tous les gens croisés, que ce soit au speaker dinner, dans les couloirs, ou à l’after. Cette fois, j’ai parlé à tellement de monde que c’est sûr que je vais en oublier donc je vais discrètement éluder la liste pour une fois ;-)

Merci :)