AI on Zwindler's Reflection

DevoxxFR 2026 - Récap du jeudi (jour 2)

Thu, 23 Apr 2026 18:00:00 +0200

Les résumés des 3 jours de DevoxxFR 2026

Deuxième jour de DevoxxFR 2026

Pour ce jeudi, j’ai raté les keynotes du matin (arrivé un peu tard), j’ai donc commencé par un tour des stands avant d’enchaîner avec les talks de la matinée. J’en ai profité pour récupérer des goodies pour les enfants au passage (:P).

Gérer vos tickets support avec de l’IA mais sans cramer la planète

Matthieu Vincent (Sopra Steria) et Philippe Charrière (Docker) ont présenté un talk sur un cas d’usage IA utile (gestion d’un service “support”), sans exploser les coûts infra.

Le message central : pas besoin d’un gros modèle partout. Selon le besoin, SLM/TLM (S ou T pour small ou tiny) peuvent suffire, à condition de bien cadrer mémoire, contexte et architecture.

Les points principaux :

Dimensionner le modèle sérieusement (poids, KV cache, activations), pas juste prendre “le plus gros”. Ca ne rentrera pas “sur le mac”.
Construire un RAG propre sur l’historique des tickets, avec embeddings et chunking seulement si nécessaire.
Ajouter une couche agentique légère pour orchestrer les actions/outils externes.

J’ai bien aimé que la démo utilise un JSON comme base vectorielle, ça rend très lisible et compréhensible le concept de vecteur et de calcul de distance. J’ai aussi bien aimé la très brève démo de “Docker Agents”, ce qui m’a décidé à enchaîner sur un talk à ce sujet l’après-midi.

Talk efficace, orienté pratique, avec une idée simple mais importante : pour ce type de besoin, “petit modèle bien outillé” bat souvent “gros modèle par défaut”.

L’Agentic Coding, nouveau territoire du Platform Engineering

Yankı Sesyılmaz et Julien Tanay (Doctolib) ont présenté un REX très concret sur l’adoption de l’agentic coding à l’échelle.

Le chiffre marquant : une vraie “task force” de 2 personnes dédiée à l’accompagnement de 600 profils tech, avec un passage assumé en mode agentic-first.

Ce que j’ai retenu :

Le sujet n’est pas juste “quel outil choisir”, c’est un vrai sujet de platform engineering.
Passer en agentic-first impose de revoir les workflows, de soigner le context engineering, de mettre en place une marketplace pour standardiser sans enfermer.
Leur approche tourne autour du Spec-driven Development (specs Markdown versionnées, lisibles humains + machines). Ils ont choisi OpenSpec pour garder un framework léger et adaptable.
Les plus gros utilisateurs de l’agentic sont les profils déjà habitués au context switching (et notamment les DevOps/SRE qui sont très transverses). On réduit la friction avec worktrees, dashboards d’agents et réduction des blocages humains.

Ils ont aussi partagé leur pipeline d’industrialisation outillage : veille, filtre valeur, revue sécurité, test avec AI champions, puis standardisation.

Enfin, les use cases “remote agents” étaient plutôt concrets : backlog de tickets, incidents de prod, migrations techniques, revue de code, avec orchestrateur, observabilité et guardrails pour cadrer le tout.

Talk intéressant, qui pointe les questions à se poser plus qu’il ne répond à comment les résoudre (:p).

Email at scale : comment on a survécu à 800M mails/an (et au DNS)

Julien Goullon et Julien Eyraud (Mirakl)

REX très solide sur un sujet qu’on sous-estime souvent : à ce volume, l’email devient un sujet de plateforme, pas un simple “service annexe”.

Ce que j’ai retenu :

Le contexte est massif : 300+ marketplaces, 170k vendeurs, 500 domaines d’envoi à migrer.
Leur nouvelle archi (Kafka + outbox + traitements asynchrones) a apporté du scale, mais a aussi exposé des effets de bord violents en incident (rebalancing, doublons, consumers bloqués).
Ils ont dû ajouter des garde-fous très concrets : circuit breaker, topics rapides/lents, déduplication Redis, observabilité/reporting.
La migration DNS/fournisseur est un chantier à part entière (SPF, DKIM, propagation, warm-up IP, suppression lists), avec beaucoup d’erreurs côté clients.

Le point le plus intéressant : ils ont investi dans l’outillage et l’autonomie client pour devenir proactifs, au lieu de rester en réaction permanente aux incidents.

Docker Agent - comment simplifier encore plus la création d’agents IA ?

Djordje Lukic et David Gageot (Docker)

Pas pu rentrer, même avec un peu plus de 10 minutes d’avance (maintenant un classique pour la salle Maillot). On m’en a dit du bien, je le mettrai dans la liste des replays.

Le mythe de la neutralité : quand la tech devient politique

Hugo Lassiège (eventuallycoding)

Talk dense et assez courageux sur un sujet qu’on évite encore dans les conférences tech, par peur de se faire étiqueter souverainiste peut être ? (alors que pas du tout).

Ce que j’ai retenu :

Le discours “la technologie est un outil neutre, tout dépend de l’usage” est commode, surtout pour les big techs. Mais un système peut définir ou suggérer son propre usage — une arme reste une arme.
Le numérique n’est pas “virtuel” : il structure concrètement l’accès au monde (transports, paiements, information), et ses biais ont des effets réels (ex. reconnaissance faciale moins performante sur les personnes non blanches au Royaume-Uni).
Les GAFAM sont en avance, mais aussi massivement subventionnés par des fonds publics — ce n’est pas uniquement le fruit du marché libre.
La souveraineté ne signifie pas l’autarcie. Être maître de ses choix sans subir de pressions extérieures, c’est possible dans un cadre d’interdépendance.

La citation qui m’a le plus parlé :

J’espère qu’on est en train de vivre notre effet Sputnik, qu’on appellera peut-être l’effet Trump.

Les exemples concrets sur ce qui se passe quand on se fâche avec les États-Unis (la CPI coupée de ses outils bureautiques, le juge coupé de toute interaction avec le monde) ou sur des déclarations comme “la technologie permettra d’éliminer le vote” (Peter Thiel) remettent bien les enjeux en perspective.

Talk que j’ai bien aimé.

Mise : un multi-outil pour votre poste de Dev & Ops

Rémi Verchère (Gravitek) parle d’un sujet que j’ai découvert avec la sortie des nodes de type Linux chez Clever Cloud il y a quelques mois (cf mon article sur le sujet). Le talk adresse un problème très concret : quand on jongle entre plusieurs projets, versions d’outils, variables d’environnement et scripts maison, ça devient vite le bazar.

Ce que j’ai retenu :

mise.toml permet de figer les versions d’outils par projet et de les installer simplement.
Le système de tasks (avec dépendances) permet de structurer les workflows build -> test -> deploy.
Bon support de l’environnement de dev (variables, venv Python, etc.).
Côté sécurité, il y a des briques utiles (checksum, cosign, lockfiles).

Un outil que je vais clairement creuser, surtout pour réduire la friction sur les context switches Dev/Ops.

Soirée meet-and-greet (version courte)

J’ai brièvement croisé quelques personnes pendant le meet-and-greet, mais j’ai rapidement dû filer au meetup Staff 42 qui commençait juste après. Pas eu le temps de passer à The Voxx, mais ça avait l’air bien, comme d’habitude.

Meetup Staff 42

Quelques sujets abordés pendant la soirée :

Comment naviguer dans l’ambiguïté — et trouver les bons problèmes à résoudre.
Le rôle Staff n’est pas fixe : on navigue entre différents archétypes (dans la définition qu’en donne le livre sur le staff engineering) selon les semaines et les contextes.
Super pouvoir identifié : savoir communiquer / avoir la liberté d’amener de l’innovation.
Il est difficile de devenir Staff sans avoir fait plusieurs entreprises et découvert plusieurs cultures.

Bonne soirée, discussions enrichissantes. On a fini par un dîner ensemble.

DevoxxFR 2026 - Récap du mercredi (jour 1)

Wed, 22 Apr 2026 18:00:00 +0200

Les résumés des 3 jours de DevoxxFR 2026

Premier jour de DevoxxFR 2026

C’est reparti pour DevoxxFR, avec un mercredi bien dense, orienté IA le matin, puis des formats plus diversifiés l’après-midi.

Je pose ici mon récap “à chaud” du jour 1.

L’IA au service du bien commun : agir avec raison dans l’incertain

Laurence Devillers (Sorbonne Université / CNRS) a ouvert la matinée avec une keynote sur les mythes autour de l’IA et sur la nécessité de garder une posture critique.

Un axe central de sa présentation : l’IA peut amplifier nos capacités, mais elle n’est ni neutre, ni magique, ni responsable. Elle aide à la décision en agrégeant des volumes de données inaccessibles à un humain, mais elle ne remplace pas le jugement.

Parmi les idées marquantes :

Le “boom IA” ne commence pas en 2022, l’histoire remonte loin.
L’AGI reste lointaine, notamment sur les dimensions de cognition “système 2”.
Les biais sont structurels (langues, données d’entraînement, cadrage des usages).
Le coût de l’IA est réel, même quand l’interface semble “gratuite”.
L’anthropomorphisme est un piège : un modèle n’a ni responsabilité morale, ni expérience vécue, ni sentiments.

J’ai trouvé que l’intervention aurait pu être intéressante, malgré le côté cours magistral (qui peut rebuter, mais qui a son intérêt), mais l’ensemble était beaucoup trop dense. Beaucoup de concepts ont été enchaînés très vite, avec peu de temps pour creuser chaque point. C’était peu “lisible”.

Les échecs à l’ère de l’intelligence artificielle

Laurent Fressinet (grand maître international, ex-coach de Magnus Carlsen) a proposé un format très pédagogique sur la co-évolution entre joueurs d’échecs et machines.

Le récit repart de la défaite de Kasparov contre Deep Blue, puis montre la rupture introduite par AlphaZero : moins de “règles codées à la main”, plus d’auto-apprentissage massif.

Ce que j’ai trouvé particulièrement intéressant, c’est le changement de posture chez les joueurs :

L’IA n’est plus seulement un adversaire, elle devient un outil d’analyse.
Elle pousse à revisiter des intuitions établies.
Le niveau global (des humains) monte parce que les méthodes d’entraînement changent.

Un bon talk “hors bulle tech” qui ramène à une idée utile pour nos métiers : on peut utiliser l’IA pour progresser, pas seulement pour accélérer. L’important est de s’adapter.

Sous le capot d’une base de données analytique

Sylvain Wallez (Elastic) a fait un deep dive très réussi sur ES|QL, le langage de requêtes “pipe” d’Elastic, et surtout sur son moteur d’exécution.

Le talk couvrait très bien la chaîne complète :

Parsing (grammaire ANTLR).
Plan logique (résolution des champs, types, sources).
Optimisations successives (pushdown de filtres, column pruning, simplifications d’expressions).
Mapping vers plan physique (répartition entre planner node et data nodes).
Optimisations locales avant exécution.

J’ai bien aimé la clarté des explications sur le modèle distribué/colonnaire/vectorisé, et sur la manière dont le query planner “réécrit” la requête de manière itérative pour gagner en performance.

Le contenu était avancé, mais très accessible dans la forme. C’est le genre de talk qui donne l’impression d’avoir tout compris sur le moment, tout en sachant qu’il y a encore beaucoup de complexité sous le capot.

Créer un jeu vidéo avec GitHub Copilot en 3h

Après une pause dej à papoter avec beaucoup de monde : session prévue de 13h30 à 16h30 (Neuilly 253), avec Xavier Noya, Arthur Magne et Tug Grall.

Seul format long que j’avais calé ce jour-là. Trois heures, c’est un gros investissement dans un agenda Devoxx, mais aussi l’occasion de vraiment pratiquer sur du développement IA spec-driven, au lieu d’enchaîner les talks.

Au final, je n’ai pas pu rentrer dans l’atelier (salle déjà pleine) malgré plus de 10 minutes d’avance. Frustrant.

Ce raté a au moins eu un effet positif inattendu : ça m’a poussé à sprinter vers l’amphi Maillot pour le talk suivant.

⌛ Et si on débuguait notre rapport au temps ?

Albane Fagot-Veyron (BPCE SI) — amphi Maillot.

Après m’être fait recaler de l’atelier GitHub Copilot, j’ai donc dû courir pour tenter d’attraper ce talk. Dix minutes d’avance n’avaient pas suffi pour l’atelier, l’amphi Maillot était bondé lui aussi, j’y croyais pas trop. Je fais partie des trois derniers (sur plusieurs centaines de personnes) à avoir eu une place. Ça valait le coup de forcer.

Albane travaille depuis deux ans sur ce sujet (elle a commencé à s’y intéresser après avoir fait un TEDx, mais elle connaissait un peu le sujet, on avait échangé par message en 2024 sur la semaine de 4J, sujet important pour elle à l’époque). Le point de départ : notre rapport au temps peut devenir une vraie source de souffrance, et elle-même a traversé des cycles d’épuisement liés à ça.

Le talk était structuré en trois axes : comment fonctionne notre rapport au temps, les pièges que l’on a créés collectivement, et comment agir à l’échelle individuelle et organisationnelle.

Ce que j’ai retenu :

Le temps perçu n’est pas le temps réel. Enfant, le temps s’écoule lentement (tout est nouveau) ; adulte, il s’accélère. La maladie ralentit la perception. L’activité aussi.
On vit dans une société de l’accélération (Hartmut Rosa) : on remplit les espaces vides, on compresse le temps, on multitâche. Et on paie un prix fort : le context switching coûte jusqu’à 40 % de productivité, et laisse le cerveau épuisé en fin de journée au point que “la seule chose que j’arrive à faire, c’est scroller”. Je vois très bien ce qu’elle veut dire…
L’IA devait nous “faire gagner du temps” — et pourtant, les travaux exposés à l’IA constatent +3h15 de travail par semaine en moyenne. Là encore, je me retrouve à 100% dans ce constat. Je n’ai pas l’impression de travailler “moins” avec l’IA, au contraire.
Le mode réseau par défaut du cerveau (le “temps de rien”) est crucial. Sans lui, pas de récupération cognitive réelle. Le takeaway principal : sanctuariser 5 minutes par jour, en silence, sans distraction.
À l’échelle collective : interroger la culture de l’organisation, ses rythmes induits, pas juste ajouter de la flexibilité en surface.

Excellente speakeuse, sujet hyper pertinent. Un talk que j’avais besoin d’entendre, MERCI MERCI MERCI Albane.

(Je me suis donc accordé une petite pause silence)

Question pour un cluster Kubernetes : quiz sur Kubernetes et ses concepts

À 17h00, Aurélie Vache propose un quiz interactif pour tester (et challenger) ses connaissances sur Kubernetes et ses concepts fondamentaux.

Le format était intéressant, ponctué de démos, avec des questions piégeuses sur des comportements qu’on croit connaître “de base” : requests / limits dans le cadre des HPA, scheduling, effets de bord quand plusieurs paramètres se combinent, etc.

Même sur des sujets qu’on pratique tous les jours, ce genre de quiz remet bien en place et force à revalider ses réflexes.

Cerise sur le gâteau : sur 114 participant(e)s, j’ai gagné.

Récompense : une paire de chaussettes OVHcloud avec le logo “chat” des produits quantiques. Je valide.

Maternité dans la tech : du témoignage à l’action

À 17h50, Estelle Thou (Criteo) revient sur son vécu de la maternité dans le monde tech et propose des pistes d’action concrètes pour les équipes et les organisations.

Le talk aborde un angle qu’on devrait traiter bien davantage dans la tech : comment recruter plus de femmes, les fidéliser, et surtout éviter que la maternité soit vécue comme un frein de carrière.

Trois axes ressortent clairement :

Construire un environnement serein pour annoncer une grossesse (culture managériale, messages portés par le leadership, process RH lisibles et centralisés).
Mieux préparer le retour de congé maternité (1:1 avant départ, plan de retour, mentorat, reprise progressive).
Travailler les points structurels (écarts de salaire, biais de présentéisme, partage réel du congé parental, formation des managers à des situations sensibles).

Un message important : ces aménagements ne sont pas des “avantages”, mais des réponses à des besoins physiques, mentaux et organisationnels bien réels.

J’ai trouvé l’intervention très utile car elle va au-delà du témoignage : elle donne des leviers concrets pour les équipes et les entreprises.

Hallway track

J’ai vu, parlé avec ou croisé Annabelle, Antoine, Horacio, Laetitia, Aline, Rémi, Benoit, Nico (et plus largement le reste de la team Lectra), Alexandre, Aurélien, Mickael, Julien, Sébastien, Thierry, Olivier (x2), Jean Christophe, Fanny, Emmanuel… et sûrement d’autres gens que j’ai oubliés.

Comme d’habitude, les rencontres sont riches et intenses.

Soirée speakers

C’est la tradition, le mercredi soir c’est soirée speakers. Nous nous sommes donc tous retrouvés à 19h30 pour une soirée chill entre speakers.

L’occasion de rajouter de très longues discussions tech, de changer le monde et la société, et un peu de Kubernetes (quand même !) avec Quentin, Sébastien, Guillaume, Albane, Nicolas, Arnaud, Stefan, Marie, Estéban, Hugo, Houssem, Jean Philippe, Romain, Alex,

DevoxxFR - Récap du jeudi (jour 2)

Fri, 18 Apr 2025 08:00:00 +0000

Les résumés des 3 jours de DevoxxFR 2025

Deuxième jour de DevoxxFR 2025

Après une soirée qui a fini bien tard, j’ai eu un peu de mal à me lever ce jeudi matin. Grave erreur… arriver à 9h00, c’est louper à coup sûr les keynotes…

C’est parti pour le récap’ du jour 2 !

Langage, IA et propagande : la guerre des récits a déjà commencé

Vous l’avez compris, j’ai donc loupé la première keynote, qui était a priori très réussie. Qu’à cela ne tienne, plutôt que me tasser dans une salle d’overflow (certaines étaient pleines aussi de toute façon !), je suis allé faire le tour des sponsors à la place.

Néanmoins, c’est une session que je vais certainement regarder en replay.

Anatomie d’une faille - l’attaque xz utils

À 10h30, j’ai pu assister à une présentation qu’on m’avait déjà plusieurs fois recommandée.

Il faut dire qu’Olivier a fait un super travail sur son talk récapitulatif de l’attaque sur xz utils (la CVE de 2024, ciblant de manière indirecte openssh).

Olivier a bien planté le décor et ne s’est pas contenté d’une analyse technique. Je connaissais plutôt bien cette partie pour avoir lu pas mal d’articles sur le sujet, mais je n’avais pas creusé l’aspect social engineering pour pousser le maintainer Lasse Collin à donner les “clés du camion” à Jia Tan.

Un must à voir si vous avez vaguement suivi l’histoire et que vous voulez un récapitulatif complet en 45 minutes chrono.

Kubernetes : 5 façons créatives de flinguer sa prod

Mon talk du jour !! En amphi bleu en plus.

On ne va pas mentir, l’amphi bleu, c’est quand même une sacrée scène et même pour un speaker non débutant, ça fait quelque chose (d’ailleurs, j’ai entendu Rachel Dubois dira à peu près la même chose un poil plus tard dans la journée).

Coutumier des retours d’expérience d’incidents sur Kubernetes, en particulier des erreurs liées au GitOops (j’ai fait une typo, mais je la laisse volontairement parce que c’est rigolo), j’avais envie de sortir un peu des sentiers battus et d’évoquer cinq anecdotes ayant conduit à des incidents en prod (ou quasiment) qui soient peu communes.

Je ne pensais pas avoir de temps pour des questions et finalement, j’ai eu presque 10 minutes d’échange avec le public. Inattendu, mais enrichissant.

Voilà les slides :

Kubernetes : 5 façons créatives de flinguer sa prod 🔫

Et après l’effort, le réconfort !

TDD et IA

Après mon talk, j’ai voulu souffler (comme je le fais d’habitude) et je me suis isolé le temps de reprendre mon énergie. Pas de bol, j’ai laissé le temps filé et je suis arrivé deux minutes trop tard à l’entrée de l’amphi Maillot et j’ai vu la porte se fermer DEVANT moi.

Un peu deg’, car j’avais très envie de voir mon ancien collègue et ami Benoit Prioux et son talk TDD et IA.

Je ne résiste cependant pas à republier (avec son accord) le sketchnote de mon amie Ane :

Encore un replay à regarder 🙃.

Dans les coulisses des géants de la Tech !

À 13h30, Rachel Dubois, experte product ayant travaillé pour ou en contact avec plusieurs grosses licornes tech, a partagé des insights sur les problématiques “produit” et l’importance de mesurer l’impact business de ce qu’on code.

Elle a insisté sur le fait que mouvement n’est pas la même chose que le progrès et que les ingénieurs doivent être au cœur de l’innovation.

Grosso modo, ça a beaucoup parlé de mesure d’impact des features codées, de feature flipping, d’expérimentations lives sur des grandes populations, de design systems pour faciliter les créations de “variants” de l’UI/UX.

C’était plein de bon sens, mais je n’ai pas non plus été hyper surpris, notamment sur la partie “technique”. Mais peut-être que c’est parce que Deezer faisait mieux les choses que la moyenne ?

Point que je note quand même, Rachel a insisté sur le fait que les ingénieurs ne sont pas des prestataires lambda et que tech == business. Et ça, même dans une belle boite tech, c’est un peu difficile à rentrer ça dans certains crânes.

Pause sponsors

N’ayant pas de talks que je voulais absolument voir juste après, j’ai décidé de faire le tour des sponsors.

J’ai eu des discussions intéressantes avec des gens de chez Sonatype, Couchbase et Mirakl.

On a finalement assez peu parlé de leur business et échangé sur un peu tout et rien. C’était agréable de ne pas être vu comme un prospect :). Ou a minima, que je ne l’aie pas ressenti.

Question pour un container

À 17h00, j’ai participé à un quizz rigolo réalisé par Sherine Khoury et Aurélie Vache sur les containers et la spec OCI.

Bon, ayant eu faux à la 2ème ou 3ème question (dans ce genre de quizz, les formulations sont parfois ambigües), je savais que c’était mort donc j’ai laissé tombé xD.

Mais j’ai regardé les démos et écouté les explications, c’était intéressant !

Infisical : Le meilleur ami des devs pour des secrets bien gardés !

Encore un gros regret : j’ai aussi loupé le talk de Julien Briault sur Infisical…

J’ai encore trop discuté, on ne peut pas tout faire (voir plus bas…).

Panel Staff 42

À 19h00, j’ai assisté à un panel de staff (et principal) engineers.

Les panelists ont discutés de la manière de trouver l’impact par rapport au produit et au business, et aussi de comment un contributeur individuel peut continuer à évoluer sans devenir staff.

C’était intéressant d’avoir plusieurs points de vue, les panelistes travaillant dans des entreprises très diverses et avec plusieurs niveaux de maturités par rapport aux ladders Staff+ (notamment en France).

Petites citations “random” :

N’attendez pas qu’on vous sollicite pour faire des feedbacks. Donnez-en sans attendre qu’on vous le demande.

Être staff, est-ce que ce n’est pas un peu être psy ? Écouter les gens, trouver les problèmes qu’ils / elles ne voient pas.

Il faut valoriser le rôle de staff sans imposer aux gens de devenir staff pour évoluer en salaire.

On a terminé par une question un peu complexe qui n’a (a mon sens) pas été répondue.

On demande aux gens de chercher la visibilité, en interne et parfois aussi en externe, s’ils veulent devenir staff (ou plus). Mais comment on fait pour garder l’équité avec ceux qui font bien leur travail pendant leurs heures, mais n’ont pas de temps (car on les charge trop ?) pour chercher cette visibilité durant les heures de travail ?

Et c’est encore plus vrai quand on demande de l’engagement en dehors des heures de travail (BBL, meetups le soir, conférences le week end).

C’est un point tricky et je n’ai pas plus de réponse.

Meet and greet / réseautage tout au long de la journée

Aujourd’hui, j’ai loupé plusieurs talks qui m’intéressaient, tout simplement parce que j’ai été absorbé par des discussions passionnantes avec de nombreuses personnes, rencontrées pour la première fois pour certaines, ou de vieux copains/copines.

Merci en particulier à Fanny, Erwan, Paul, Olivier, Pierre, le mystérieux “DarkSidious” (hihi), mais aussi Quentin, Geoffrey, Jean-Philippe, Loïc, Mickaël, Mazlum, Cécile et surement d’autres personnes que mon cerveau fatigué par deux jours de confs aura malheureusement zappé (désolé).

C’était vraiment top :-).

DevoxxFR - Récap du mercredi (jour 1)

Thu, 17 Apr 2025 12:00:00 +0000

Les résumés des 3 jours de Conférence Tech 2025

Premier jour de Conférence Tech 2025

Comme vous l’avez peut-être vu (j’ai abondamment communiqué sur les réseaux 🙃), après quasiment un an sans conférence en tant que speaker, me revoilà sur “les planches”, à DevoxxFR !

Evidemment, vous vous en doutez, j’en ai profité pour voir un max de confs, comme à mon habitude ;-).

C’est parti pour le récap’ du premier.

L’IA n’existe pas

Luc Julia a ouvert la journée (dans un amphi bleu blindé) avec un exposé acide et décalé sur l’évolution de l’IA. Selon lui, il n’y a pas de révolution, mais plutôt une évolution continue depuis les années 50-60, puis 90-2000.

Nous en France, les révolutions, on connait et c’est pas ça.

Le titre est un rappel au fait que l’IA générative manque de créativité et que les IA omnipotentes d’Hollywood n’existent pas. Il faut toujours un humain derrière.

Luc a également abordé des problématiques comme la propriété intellectuelle, en citant des cas où l’IA générative open source Stability diffusion a produit des images avec des watermarks Getty Images clairement visibles, et un peu les problématiques environnementales, avec des chiffres complètement bidons (dommage).

Github Copilot

À 11h35, j’ai assisté à une démonstration de Github Copilot, réalisée par Kim-Adeline Miguel et Sandra Parlant en particulier sur les dernières fonctionnalités.

Les deux speakeuses ont montré le chat en mode immersif, le changement de modèle, la configuration des instructions personnalisées. N’ayant pas encore utilisé Copilot (oui oui…), ça donne envie d’essayer.

J’ai été plutôt impressionné par la capacité de Copilot à faire des revues de code sur les PRs et la même chose sur les analyses de sécurité.

Ne perdez plus vos photos de vacances (ou tout autre fichier important)

Mon talk du jour !!

C’était un sujet qui me tient assez à cœur et ça s’est très bien passé. J’ai eu de bons retours, notamment avec des discussions assez riches qui ont suivi.

Je suis vraiment content, j’ai déroulé comme je voulais. J’ai eu des suggestions pertinentes et je postulerai à nouveau (peut-être) ailleurs :).

Les slides :

Ne perdez plus vos photos de vacances 🔥🏠🔥 (ou tout autre fichier important)

Comment nous avons transformé les Restos du Coeur en Cloud Provider

À 13h30, (mon ancien collègue) Julien Briault et Stéphane Trognon nous ont raconté comment ils ont contribué à transformer les Restos du Cœur en véritable fournisseur de cloud.

De l’organisation initiale chaotique à une infrastructure professionnelle, ils nous ont partagé un voyage de transformation, du “DC au WC” jusqu’aux 3 DCs multi AZs from scratch gérés par 11 bénévoles.

Ils utilisent désormais OpenStack avec Kubernetes, et plus globalement des solutions open source pour la plupart de leurs besoins. Ils ont même développé des solutions spécifiques, comme des systèmes de monitoring pour les chambres froides qui coûtaient avant ça “un pognon de dingue” (ça, c’est moi qui le dit).

Ce projet est vraiment un coup de cœur (pun intended) que je suis depuis longtemps (j’avais déjà vu un autre talk de Julien qui en parlait).

Grâce à leur approche d’éco-conception et à l’utilisation d’équipements de récupération, ils ont réussi à économiser des millions ~~d’euros~~ de repas distribués, tout en fournissant des services essentiels permettant de s’affranchir d’AWS (en particulier dans le contexte géopolitique actuel).

Ca marche dans mon .devcontainer

À 17h00, j’ai assisté à une présentation sur les devcontainers par Benoit Moussaud.

J’ai souri quand il a commencé en plantant le décor en disant qu’il avait dû re-travailler sur Windows en étant embauché par Microsoft et que c’était la galère (il ne l’a pas dit comme ça, mais ceux qui font du WSL ont compris).

Pour celles et ceux qui ne connaissent pas bien les CDE (pour cloud development environments), cela permet de créer des environnements complets de développement dans des containers, ce qui est extrêmement utile pour l’onboarding, la gestion des versions et des outils, ainsi que pour l’isolation entre l’environnement du laptop et l’environnement spécifique au projet.

La démo s’est bien passée, avec la création d’un devcontainer qui clone le repository dans le container. Dans la spécification, on peut aussi ajouter des “features” pour customiser l’environnement, comme ajouter Vegeta pour du load testing.

Le côté “automagique” de l’injection des credentials Git de l’utilisateur dans le devcontainer a été aussi abordé, mais ça soulève autant de questions que de réponses…

Cependant, il n’y a pas de support pour Windows, GPU, ou private endpoints via GitHub Codespace.

Burrito est un TACoS : une alternative open-source à Terraform Cloud

À 17h50, j’ai découvert Burrito, une alternative open-source à Terraform Cloud, qui adresse plusieurs soucis de l’IaC, en particulier avec Terraform.

Luca et Lucas (ahah) nous ont présenté Burrito, leur opérateur Kubernetes inspiré d’ArgoCD, offrant des fonctionnalités de réconciliation, détection de drift pour terraform.

Clairement, je me suis tout de suite retrouvé dans leurs constats des faiblesses de terraform et j’ai été séduit par leur approche.

Burrito est compatible avec Terraform, Terragrunt et Opentofu, et exécute terraform plan/apply dans un container Kubernetes.

Ils ont parlé ouvertement des challenges qu’ils ont rencontrés à l’échelle :

Problématiques I/O pour le téléchargement des providers et des binaires.
Problématiques CPU avec des plan/apply très réguliers.

Pour y répondre, ils ont implémenté un caching de provider et des fenêtres de synchronisation pour gérer 800 layers Terraform en parallèle. Pour la suite, ils envisagent d’ajouter du polling, l’autodiscovery, le RBAC, et l’intégration de plugins (Checkov, Terracost).

J’ai eu une discussion très intéressante par la suite avec tous les deux, c’était très sympa.

Diner des speakers

La soirée s’est terminée par un diner des speakers, où j’ai pu parler avec pas mal de gens :)

Impossible de citer tout le monde (j’ai beaucoup parlé XD), mais j’ai particulièrement apprécié parler avec Olivier, Marie, Alice & Théotime, Jean-Christophe, Aline, Thierry, et aussi Erwan, pendant cette soirée :).

Bon… on avait faim… alors, on a dû finir par un MacDo 💀.

Générer ses images Stable Diffusion sur Ubuntu 22.04

Tue, 03 Jan 2023 07:15:00 +0000

L’IA et le retour de la vengeance

Ce n’est pas la première fois que je parle de machine learning sur le blog. La première fois, j’avais testé pour le fun de selfhost AIDungeon 2, un jeu de rôle où l’histoire est générée par l’“““IA”””.

A l’époque, j’essayais de jouer à AIDungeon sur l’application web disponible en ligne mais le site était très souvent down, car, à cause de l’engouement pour le jeu et son côté hyper ludique / technophile, l’auteur avait reçu une facture cloud de quelques dizaines de milliers de dollars (et c’était pas trop prévu).

Heureusement, le jeu étant (à l’époque) complètement open source, j’avais eu l’idée de faire un guide pour le lancer soi-même (enfin, fallait quand même un GPU avec 8 Go de VRAM)…

Et depuis l’an dernier, l’IA revient sur le devant de la scène.

Non, je ne vais pas parler de ChatGPT mais de DALL-E 2. Il faut bien le reconnaitre, a bluffé plus d’une personne. Et Dall-e n’étant pas open source, il n’a pas fallu bien longtemps pour que des alternatives open source voient le jour (avec des résultats souvent moins impressionnant mais quand même).

Sauf que… rebelote, les serveurs en ligne sont leeeeeents. Ca serait cool si on pouvait lancer ça en local.

Ca tombe bien, j’ai une machine avec Ubuntu 22.04 et une carte graphique NVidia RTX 3080 hors de prix sous mon bureau 😏😏😏.

Note: vous avez besoin d’une machine avec un GPU avec au minimum 4 Go de VRAM (sinon ça sera en mode CPU et ça sera extrêmement lent), de minimum 20 Go d’espace disque pour le modèle et les dépendances et d’un compte sur HuggingFace.com pour récupérer le modèle Stable Diffusion.

Installer les mises à jour et les prérequis

La première chose à faire dans tout bon guide est évidemment de tout mettre à jour.

sudo apt-get update
sudo apt-get upgrade

Normalement sur Ubuntu 22.04 vous devriez avoir Python 3 installé par défaut, il nous faut la version 3.9 ou 3.10 avec les venvs.

sudo apt install python3.10 python3.10-venv

Si on veut profiter de notre GPU, il va falloir passer par les pilotes officiels nvidia (et pas “nouveau”).

sudo apt-get install --no-install-recommends nvidia-driver-525 xserver-xorg-video-nvidia-525

Et surtout, il faudra absolument rebooter ensuite (sinon le GPU ne sera pas détecté).

Galères d’installation

Sur AIDungeon j’avais pété un plomb, car les dépendances pour tout ce qui est GPU + machine learning et Python sont très capricieuses…

Pour ce qui est de Stable Diffusion, à l’époque de la sortie j’avais trouvé la documentation pas ouffissime et j’avais abandonné assez vite. Jusqu’à il y a peu il y avait très peu de guides pour l’installer facilement sur sa machine.

La plupart des guides proposaient de le lancer sur des notebooks en ligne (donc hosté quelque part) et c’est pas du tout ce que je voulais.

Heureusement, je suis tombé sur ce post The simplest way to get started with Stable Diffusion on Ubuntu, qui parle d’un dépôt git github.com/lstein/stable-diffusion.

Sauf que ce guide proposait d’installer toutes les dépendances avec Anaconda et ne marche plus aujourd’hui (problèmes de dépendances python, encore…).

Heureusement, rebondissant sur le dépôt mentionné juste avant, je me suis rendu compte que le dépôt avait changé de nom et beaucoup évolué depuis l’article sur mendhak.com.

Le dépôt s’appelle maintenant github.com/invoke-ai/InvokeAI et dispose de scripts d’installation assez poussés et multi plateformes.

Récupérer l’installeur

On peut faire l’installation via les sources soit même (je donne des infos plus loin) mais le plus simple est de suivre le script d’installation, disponible dans les “releases” dans Github :

wget https://github.com/invoke-ai/InvokeAI/files/10254727/InvokeAI-installer-2.2.4-p5-linux.zip
unzip InvokeAI-installer-2.2.4-p5-linux.zip && cd InvokeAI-Installer/
./install.sh

Vous serez guidé lors du processus d’installation, c’est assez simple

Welcome to InvokeAI. This script will help download the Stable Diffusion weight files and other large models that are needed for text to image generation. At any point you may interrupt this program and resume later.

** INITIALIZING INVOKEAI RUNTIME DIRECTORY **
Select the default directory for image outputs [/home/zwindler/invokeai/outputs]: /home/zwindler/invokeai/outputs

[...]

A un moment on va vous demander de valider des licences (étape “3. Accept the license terms located here”). Il faut juste les lire sur le site et appuyer sur entrée pour continuer (j’avais pas compris au début…).

La dernière étape consiste à générer (ici) et donner au script un token en “read” sur votre compte Hugging Face. C’est assez simple et ça permet de télécharger automatiquement le dernier modèle de Stable Diffusion.

Lancer !

Une fois installé, on peut lancer le script invokeai/invoke.sh

L’important est que la ligne suivante apparaisse quand vous lancez le script (“cuda” et pas “cpu”)

>> Using device_type cuda

Ce qui est assez cool avec InvokeAI, c’est l’ajout d’une interface web pour faciliter vos générations, même s’il existe toujours un prompt terminal si vous préférez :

Do you want to generate images using the
1. command-line
2. browser-based UI
3. open the developer console
Please enter 1, 2, or 3: 1

A partir de là, vous pourrez générer autant de chats mignons que vous voudrez !

Have fun :D

Bonus : installation manuelle

Lors de ma première installation, j’avais oublié qu’il fallait absolument les drivers officiels nvidia pour faire du cuda sous Ubuntu (alors que j’avais eu le même problème pour AIdungeon 🤦). Le script se lançait en mode “CPU” et la génération de la moindre image prenait 5 minutes

* Initialization done! Awaiting your command (-h for help, 'q' to quit)
invoke> a cat
Generating: 0%| | 0/1 [00:00<?, ?it/s]>> Ksampler using model noise schedule (steps >= 30)
>> Sampling with k_lms starting at step 0 of 50 (50 new sampling steps)
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 50/50 [05:41<00:00, 6.82s/it]
Generating: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████| 1/1 [05:49<00:00, 349.51s/it]
>> Usage stats:
>> 1 image(s) generated in 349.99s
Outputs:
[1] /home/zwindler/invokeai/outputs/000001.3257807215.png: a cat -s 50 -S 3257807215 -W 512 -H 512 -C 7.5 -A k_lms

J’ai donc tâtonné et essayé d’installer l’outil “à la main”.

Si vous ne voulez pas utiliser l’installeur pour une raison ou pour une autre, vous pouvez donc aussi utiliser cette page de documentation.

J’ai essayé, ça marche (mais c’était pas mon problème).

Bonus : Vérifier que votre GPU est bien détecté

Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.cuda.is_available()
True
>>> torch.cuda.device_count()
1
>>> torch.cuda.get_device_capability()
(8, 6)