Alors ? C’était comment ce premier DevFest Lyon ? (la suite)

L’équipe HoppR au Devfest lyon

Pour faire suite à l’article de Michaël sur la très bonne première édition du DevFest Lyon, nous vous présentons deux autres talks auxquels nous avons pu assister et qui nous ont marqué.

Chaos Monkey : et si Netflix révolutionnait aussi la résilience de vos applications ?

Écrit par Anaïs

Illustration style synthwave aux néons violets montrant un singe holographique débranchant un câble serveur, ouvrant une faille numérique glitchée. Au premier plan, des ingénieurs surveillent calmement la situation, protégés par un bouclier énergétique bleu. Titre : CHAOS MONKEY.

En ce début décembre 2025, impossible d’y échapper : la sortie de la saison 5 de Stranger Things fait vibrer les réseaux.

Mais saviez-vous que Netflix, en plus de captiver des millions de spectateurs, a aussi révolutionné la façon dont on teste la robustesse des applications ?

Rencontre avec le Chaos Monkey, un outil né dans les coulisses du géant du streaming, et qui pourrait bien sauver votre infrastructure du prochain “Démogorgon” technologique…

Quand Netflix inspire la résilience IT

Lors du DevFest Lyon 2025, Erwan Le Tutour a présenté le Chaos Engineering, une pratique inspirée de Netflix.

L’idée ? Provoquer des pannes contrôlées (coupures réseau, latences, arrêts de serveurs) pour détecter les faiblesses d’un système avant qu’elles ne deviennent critiques.

À l’origine, Netflix utilisait le Chaos Monkey, un outil interne pour tester la résilience de son infrastructure de production face à des millions de requêtes. Aujourd’hui, des solutions comme le Chaos Monkey for Spring Boot permettent à tous les développeurs d’intégrer cette approche, en simulant des scénarios chaotiques pour renforcer leurs applications. (Cliquez ici, pour les curieux!)

Pourquoi adopter le Chaos Engineering ?

Les systèmes modernes sont de plus en plus complexes, distribués et interconnectés. Dans ce contexte, la question n’est plus si une panne va survenir, mais quand.

Le Chaos Engineering permet de :

  • Détecter les points de fragilité avant qu’ils n’impactent les utilisateurs.
  • Améliorer la réactivité des équipes en situation de crise.
  • Renforcer la confiance dans l’infrastructure, même face à l’inattendu.

Malheureusement personne n’est à l’abri, comme l’attestent les événements récents (AWS/Cloudfare)

Alors, prêt à lâcher un Chaos Monkey dans votre environnement pour en tester la solidité ? 🐒💥

Pour conclure cet article : bien moins technique que l’excellent article de Michael (et que celui qui arrive juste après !), ce retour reflète surtout mon regard côté business. Même si je ne suis pas développeuse, c’est justement ce genre de conférences qui me permet de mieux comprendre les enjeux tech du quotidien de mes collègues.

Développer un opérateur Kubernetes en Java : Challenge Accepted !

Écrit par Maxime

Illustration isométrique style tech-fantasy. Une développeuse injecte une énergie lumineuse orange, générée par du code Java et Quarkus, dans une machine Kubernetes géante en forme de gouvernail qui organise des conteneurs logiciels. Au sol, un panneau 'GO LANGUAGE ONLY ZONE' est brisé. Le titre en haut indique : 'JAVA OPERATOR: CHALLENGE ACCEPTED

Si vous travaillez dans l'écosystème Cloud Native, vous avez forcément ressenti cette pression implicite : pour faire du Kubernetes sérieusement, il faut faire du Go. C'est le langage de l'orchestrateur, c'est le langage de la plupart des outils, et par extension, on finit par croire que c'est le seul choix viable pour étendre son cluster.

J'ai assisté à une conférence qui tord le cou à cette idée reçue, et je pense qu'elle mérite votre attention si votre équipe est majoritairement composée de développeurs Java.

Dans son talk "Développer un opérateur Kubernetes en Java, challenge accepted !", Stéphane Phillipart s'attaque à un sujet souvent intimidant : les Opérateurs.

Pourquoi ce talk est important

Pour rappel, un opérateur est ce qui permet d'automatiser la gestion d'applications complexes dans Kubernetes. Jusqu'à récemment, la documentation et les exemples étaient quasi exclusivement en Go. Pour une équipe Java, cela voulait dire : apprendre un nouveau langage et une nouvelle toolchain juste pour écrire de l'outillage.

Ce que Stéphane démontre brillamment, c'est que cette barrière n'a plus lieu d'être.

Le cœur de sa présentation repose sur le Java Operator SDK. Loin d'être une solution de bricolage, il montre que l'outillage est désormais mature. Ce que j'ai particulièrement apprécié dans sa démarche, c'est le pragmatisme. Il ne s'agit pas de faire du Java pour le plaisir de faire du Java, mais de capitaliser sur les compétences existantes des équipes. Pourquoi forcer des experts JVM à écrire du Go médiocre alors qu'ils pourraient écrire du code Java robuste et testable ?

De la théorie au code

La conférence n'est pas qu'une suite de slides théoriques. On passe rapidement au concret avec du live coding. On y voit la création d'un opérateur, la gestion de la boucle de réconciliation (le cœur du réacteur de Kubernetes) et le déploiement.

Il aborde aussi implicitement un point qui fait souvent peur aux Ops : la lourdeur du Java. En combinant le SDK avec des frameworks modernes comme Quarkus (souvent utilisé pour la compilation native), on obtient des opérateurs légers, rapides au démarrage et peu gourmands en mémoire. L'argument de la performance du Go ne tient plus vraiment la route face au Java moderne.

Mon avis

Si vous êtes un développeur ou développeuse Java et que vous regardez Kubernetes comme une boîte noire réservée aux Ops ou aux développeurs Go, prenez une heure pour regarder ce talk disponible sur YouTube via d’autres conférences.

Il dédramatise complètement le développement système sur Kubernetes. C'est une excellente ressource pour convaincre votre CTO ou votre Lead Tech qu'il est possible d'industrialiser vos déploiements sans changer toute votre stack technique.

En conclusion : l’innovation se partage, surtout au DevFest Lyon !

Notre participation à cette première édition du DevFest Lyon a été une véritable source d’inspiration. Entre le Chaos Engineering, qui nous rappelle que la résilience se construit en osant tester nos limites, et la démonstration que Java a toute sa place dans l’écosystème Kubernetes, ces conférences ont confirmé une chose : l’innovation naît souvent là où on ne l’attend pas.

Chez HoppR, nous sommes convaincus que partager ces retours d’expérience, ces outils et ces bonnes pratiques est essentiel pour faire progresser toute la communauté tech. C’est pourquoi nous avons mis en place une véritable culture de l'apprentissage continu.

En interne, cela se traduit par nos Maker Days : des journées dédiées où nos consultant.es sortent de la production pour tester de nouvelles technos (comme ce fameux Chaos Monkey !), prototyper ou approfondir des concepts complexes. C'est notre laboratoire R&D, et c'est ce qui permet à nos équipes de rester à la pointe.

Mais nous sommes convaincus que le savoir ne doit pas rester cloisonné. Nous avons donc transformé ces retours d’expérience et cette expertise terrain en un catalogue de formations concret et pragmatique. Que vous soyez une entreprise cherchant à faire monter vos équipes en compétences ou un développeur avide d'apprendre, nous partageons ce que nous maîtrisons au quotidien.

➡️ Découvrez nos programmes de formation HoppR

Alors, prêt à libérer votre propre Chaos Monkey ou à développer votre premier opérateur Kubernetes en Java ?

N’hésitez pas à nous faire part de vos retours, de vos questions, ou à nous rejoindre pour en discuter lors de nos prochains événements !

Un grand merci à l’équipe du DevFest Lyon pour l’organisation de cet événement, et à tous les speakeuses et speakers pour leurs présentations inspirantes.

À l’année prochaine pour de nouvelles découvertes !

À propos des auteurs

Maxime Deroullers

Maxime Deroullers

Anaïs Cousin

Anaïs Cousin

Cet article vous a inspiré ?

Vous avez des questions ou des défis techniques suite à cet article ? Nos experts sont là pour vous aider à trouver des solutions concrètes à vos problématiques.