Planning BreizhC@mp 26

Le code compile, la suite de tests est au vert et la CI a validé le déploiement. Pourtant, en production, c'est le crash inexpliqué, la faille silencieuse ou le fameux comportement indéfini (Undefined Behavior). La safety d'une application va bien au-delà de la simple gestion de la mémoire. À travers un format Lab interactif de 2 heures, ce module vous propose de traquer les anomalies de conception à travers une multitude d'écosystèmes : Go, Python, C/C++, Bash, JS, Java, ... N'importe quel téléphone ou ordinateur avec une connexion internet suffira. Rassurez-vous : il n'est pas nécessaire de maîtriser la syntaxe de tous ces langages. Un bagage général devrait suffire. De plus, une partie des snippets projetés ne sont pas des cas d'école théoriques, mais de véritables bugs issus de la production. Certains même reconnaîtront le cas d'origine, les autres devront le découvrir par l'analyse statique. Le concept : la portion de code incriminée est projetée. Votre mission consiste à trouver la faille structurelle (Data races, Typestate invalide, erreurs de concurrence temporelle) puis à cliquer directement sur le segment coupable via l'application web du Lab. L'expérience s'adapte à votre niveau d'engagement : participez en mode passif/anonyme depuis le fond de la salle en accumulant des points sur l'application, ou installez-vous aux premiers rangs pour un mode interactif où vous pourrez prendre le micro et expliquer techniquement la nature du bug identifié. Venez affûter votre œil face aux limites sémantiques de nos outils quotidiens.

Les ateliers d’accessibilité remplissent rarement les salles, et les conférences sur l’accessibilité numérique restent souvent théoriques : on parle du “pourquoi”, rarement du “comment”. Dans cet atelier, nous allons changer ça. Le manque de pratique empêche les développeurs et développeuses de progresser. Tester un site avec un lecteur d’écran ou au clavier paraît complexe. Pourtant, il existe des méthodes simples pour apprendre ensemble. Pendant l’atelier, nous corrigerons en direct un site e-commerce volontairement inaccessible, en mob programming. Nous expérimenterons les tests, les outils et les corrections pas à pas. Que vous soyez dev front, dev généraliste ou novice en accessibilité, vous repartirez avec : - une méthode pour pratiquer l’accessibilité numérique en équipe - une vision concrète de “ce qui compte vraiment” - et la preuve que démarrer l’accessibilité, ce n’est pas si compliqué

L'IA générative ne se contente pas de bousculer nos outils ; elle redéfinit l'architecture même de notre pensée. En quelques mois, nous avons basculé du plaisir de l'écriture à une posture de supervision permanente. Mais cette accélération a un prix que nous ressentons chaque jour : le plaisir du craft qui s'efface, des compétences qui risquent de s'atrophier faute de friction et la charge cognitive d'un métier devenu gestion de flux. À travers nos deux regards, nous vous proposons une exploration lucide de cette transition. Nous chercherons ensemble comment continuer à aimer ce métier quand l'IA en modifie jusqu’à l’essence, et comment ancrer durablement nos savoirs dans un monde de raccourcis permanents. Notre ambition est de partager avec vous des pistes pour rester des artisan·es aux commandes, et non de simples opérateur·ices.

Fini les listes de mots de passe à retenir et les oublis stressants ! Grâce aux passkeys, il devient possible de se connecter de façon sûre et rapide, sans compromis sur la sécurité. Cette conférence explique simplement ce que sont les passkeys et comment différents scénarios de passkeys fonctionnent. Au programme : une présentation des standards derrière les passkeys et des concepts techniques fondamentaux, ainsi que des exemples concrets pour comprendre le fonctionnement de plusieurs types d'implémentation des passkeys (clé matérielle YubiKey, téléphone, Windows Hello…), accompagnés de démonstrations. Vous découvrirez les points forts de ces technologies (simplicité d’usage, robustesse face au phishing…), les contextes les plus adaptés à chaque type de passkey, mais aussi leurs limites et les questions à se poser avant de les adopter. Rejoignez-nous pour entrevoir un quotidien numérique plus simple, sans avoir à jongler avec des mots de passe !

MDP (pour Medical Data Platform) est le premier service à avoir été extrait du monolithe historique de Doctolib, marquant ainsi une transition architecturale vers une infrastructure davantage distribuée. Cette conférence détaille notre parcours de migration des données médicales, où la stabilité de l'environnement de production et l’expérience utilisateur ont été des enjeux cruciaux. Cette migration nous a permis d’améliorer l’expérience développeur, de découpler les données fonctionnelles des données médicales et de mettre en place une structure de base de données unifiée pour les données médicales saisies à la fois par les praticiens et les patients. Nous aborderons les choix techniques effectués, les défis organisationnels rencontrés liés à la mise en place de nouveaux processus de déploiement, ainsi que les obstacles rencontrés sur « le terrain ». Cela inclut des incidents en production, des débats sur la façon de valider la qualité des nouveaux services et plus globalement la transition vers la philosophie « You build it, you run it ». La présentation propose un retour honnête sur les succès et les échecs rencontrés lors de cette migration, offrant des enseignements concrets aux équipes envisageant des changements architecturaux similaires.

Vous connaissez les gros tableaux, les dashboards et les pages web lourdes… mais avez-vous déjà essayé de pousser un site web en full DIV et CSS jusqu’au point de faire tourner un jeu vidéo ? Pas de three.js, pas de unity, seulement du html, du vrai ! Au départ, je pensais devoir me battre contre le navigateur: perfs instables, rendu fragile… et à me perdre dans une complexité ingérable côté code. Je me trompais. Pendant 3 ans, mon projet a été l’une des aventures les plus fun et gratifiantes de ma carrière, et aujourd’hui, il a donné naissance à un jeu complet, dont la démo a déjà été testée sur Steam par plusieurs milliers d’utilisateurs. Dans ce talk, je partagerai mon expérience sur tous les aspects de la création, avec un focus sur ce que les développeurs web peuvent en tirer : - Les ponts techniques et créatifs entre sites web et jeux vidéo. - Les challenges techniques rencontrés, mais aussi leurs solutions et leurs limites. - Des astuces CSS/HTML puissantes et souvent méconnues. - La gestion d’un projet long terme, du développement au lancement sur Steam, marketing inclus. Dans ce talk vous allez réaliser que le web est plus puissant que vous ne le pensez et que créer vos jeux sans bibliothèques externes est non seulement possible, mais aussi très accessible. Lancez-vous… le web est prêt à vous suivre !

Envie de découvrir un framework qui démarre en un éclair, consomme trois fois rien et simplifie la vie des développeurs de microservices ? Bienvenue dans cet atelier 100% pratique consacré à Micronaut, le framework JVM pensé pour la performance, la modularité… et la sérénité en production. Pendant deux heures, nous construirons une application complète intégrant plusieurs interfaces : - une API REST, - une consommation/production Kafka, - une persistence via base de données, Nous plongerons ensuite dans la réalité du terrain : 👉 quelles difficultés rencontre‑t‑on lorsqu’on vient de frameworks plus classiques comme Spring ? 👉 pourquoi certaines habitudes ne fonctionnent pas ici ? 👉 quelles limitations et pièges faut‑il anticiper ? 👉 et surtout : en quoi les choix techniques de Micronaut changent‑ils la donne (performance, GraalVM, légèreté, prédictibilité…) ? Cet atelier s’adresse autant aux curieux qu’aux développeurs expérimentés souhaitant se faire un avis sur Micronaut… et si cela pourrait devenir un allié de choix dans leurs futures architectures. Venez les mains sur le clavier : on code, on teste, on compare, et on repart avec une application fonctionnelle et un regard neuf sur un framework qui gagne à être connu.

Marre d'utiliser Docker comme un simple lanceur de containers ? 🤔 Vous pensez avoir fait le tour de la question avec un docker run et un docker-compose up qui fonctionne "plus ou moins" ? Venez donc (ré-)apprendre à dompter les baleines ! Cette université est faite pour les développeurs et les SRE qui veulent passer au niveau supérieur. Repartons des bases et allons explorer les fonctionnalités méconnues qui transformeront votre workflow : * Compose, ce chef d'orchestre de génie : Découvrez le pouvoir caché des fichiers docker-compose.yml pour mettre en musique vos microservices et orchestrer des applications multi-conteneurs sans effort. * Buildx, le couteau suisse de la construction d'images : Dites adieu aux builds lents et bonjour aux images multi-architectures et aux caches partagés. Nous explorerons la puissance de docker buildx, notamment sa commande bake pour compiler plusieurs images simultanément avec une simple configuration, comme un chef préparant un festin de containers ! * Multi-stage builds, le Saint Graal du build : Réduisez la taille de vos images de 90 % et faites rougir votre CI/CD. Rejoignez-nous pour (re)découvrir que Docker est bien plus qu'un simple outil, c'est une philosophie, et que vos applications méritent un style qui va bien au-delà de la ligne de commande.

Tout le monde pense que la "Clean Architecture / Architecture Hexagonale" se fait uniquement côté Back. Dans cet atelier, nous allons vous montrer que cela fonctionne également côté Front. Et oui, Redux n'est pas le Silver Bullet des applications front-end. Et oui, Les Stores ne sont pas toujours obligatoires, mais ceci est une autre histoire ! On va coder ensemble une petit App Front pour voir comment mettre en place cela. Take away : Comprendre et manipuler les concepts. Architecture Logicielle Stratégie de Tests

La recherche sémantique promet une révolution : pertinence contextuelle et compréhension du langage naturel en quelques lignes de code seulement. Sur un notebook ou un POC, c'est magique. Mais que se passe-t-il lorsque votre index dépasse le milliard de vecteurs ? La magie cède rapidement la place à la brutalité de l'ingénierie : explosion de la latence, coûts d'infrastructure incontrôlés et défis liés à la RAM. Dans cette présentation, nous laissons le buzz marketing à la porte et plongeons dans les entrailles d'Elasticsearch et d'OpenSearch à très grande échelle. Nous aborderons comment : - Architecturer vos clusters pour gérer un milliard d'embeddings sans flancher. - Optimiser le compromis critique entre précision et latence. - Réduire les coûts en utilisant des stratégies de quantification et de chunking intelligent. Si vous devez passer d'une recherche sémantique « Hello World » à une production massive, cette session est votre guide de survie.

SecNumCloud est aujourd’hui la plus haute référence en matière de sécurité pour les services cloud en france, mais ses exigences peuvent sembler complexes, notamment lorsqu’il s’agit des accès d’administration. Dans ce talk, nous partagerons notre retour d’expérience concret sur la conception et la mise en place d’un poste d’administration sécurisé permettant à nos équipes d’exploiter et d’administrer la plateforme tout en respectant les exigences SecNumCloud de l’ANSSI. À travers un retour d’expérience terrain, nous expliquerons nos choix techniques, les contraintes rencontrées, les erreurs commises et les solutions mises en place. Pas de théorie abstraite : du pragmatique et du vécu. Nous aborderons les grands principes (séparation des usages, durcissement, traçabilité, contrôle des accès), l’architecture retenue, les compromis réalisés et les bénéfices concrets pour les équipes. Ce talk ne prétend pas être une interprétation officielle du référentiel : nous ne sommes ni experts ni auditeurs SecNumCloud. Il s’agit d’un retour d’expérience honnête et opérationnel, destiné à démystifier SecNumCloud et à montrer qu’il est possible d’allier sécurité forte et efficacité opérationnelle.

La gestion des coûts est un enjeu majeur sur les plateformes Cloud. Sans une approche rigoureuse, l’élasticité et la flexibilité promises peuvent rapidement se transformer en dépenses imprévisibles. RCA utilise le service managé Kubernetes EKS d’AWS. Afin de gérer les variations de charge des applications, nous avons déployé KEDA pour ajuster automatiquement le nombre d’instances en fonction de l’activité des utilisateurs et des périodes de la journée. Dans une optique FinOps, le dimensionnement des nœuds est optimisé via Karpenter, garantissant ainsi une adéquation au plus juste entre les ressources allouées et les besoins des applications. En combinant ces solutions avec une stratégie hybride de facturation avec des instances Spot et des instances réservées en fonction des environnements, nous maximisons l’efficacité tout en réduisant les coûts. Lors de cette présentation, nous vous partagerons nos astuces et nos difficultés sur l'intégration de ces outils sur AWS dans une approche FinOps.

GAFAM, dépendance, données personnelles livrées au plus offrant ; Bienvenue dans la matrice. Moi, j'ai choisi la pilule rouge. Une idée, beaucoup d'huile de coude. Et quelques mois plus tard : une infra déclarative, résiliente, indépendante, qui m'appartient vraiment et qui respecte mes données. Apprendre, mettre les mains dans le cambouis, construire une base pour de futurs projets ou sortir de la matrice... Les raisons sont nombreuses pour se lancer dans le self-hosting. Pour ma part, c'était un peu tout à la fois ! Que vous soyez dev curieux ou ops en quête d'un terrain de jeu personnel. Refaites avec moi tout le chemin pour passer (après maintes soirées debug et autres prises de tête) d'une idée pas si farfelue à une infra redondante, observable, sécurisée, avec une dizaine de services en production. Le genre d'architecture qu'on retrouverait en entreprise. Au programme : virtualisation avec Proxmox, orchestration avec Kubernetes, Talos et ClusterAPI, GitOps avec ArgoCD et Gitlab, IaC avec OpenTofu, gestion des secrets avec SOPS et Infisical, OS immutables avec NixOS et CoreOS. Et une touche de loki et grafana pour lier le tout. Vous repartirez avec le fruit de mes tentatives, apprentissages et galères. Tout ce qu'il faut pour démarrer votre propre homelab cloud-native ; Et je l'espère, l'envie de vous lancer dans cette aventure aussi passionnante qu'elle est pleine d'embûches !

Alors que la Developer Experience s'immisce timidement dans les réflexions techniques et managériales de nos organisations, notre Ops Experience, elle, est encore trop souvent oubliée. Pire, lorsqu'on construit une solution technique basée sur une plateforme interne, que l'on doit respecter des jalons, améliorer la qualité du code, la fiabilité des tests, automatiser les process,... nous, Dev et Ops, restons des ressources au service des autres équipes métiers de l'entreprise, considérés comme un centre de coût à optimiser. Et si on inversait ce prisme ? Que se passerait-il concrètement si on se considérait nous-mêmes comme des utilisateurs, voire des clients, avec nos besoins, nos irritants et nos attentes, souvent différentes ? Au travers de ce retour d'expérience, je vous propose de penser nos expériences Dev & Ops, comme on pense l'expérience utilisateur. Je vous parlerai des techniques pour comprendre et améliorer le quotidien des équipes de réalisation et traiter nos plateformes internes comme un produit. Je vous emmènerai dans un monde mêlant techniques de marketing (Design Thinking, expérience utilisateur...), d'industrie (Value Stream Mapping, Kaizen...) et de psychologie (Communication Non Violente, sécurité psychologique...). Venez (re-)découvrir des techniques actionnables pour transformer vos DevEx et OpsEx en commençant par le plus simple : considérer Dev et Ops comme des clients précieux dont il faut vraiment écouter les besoins !

On a l'impression qu'avec chaque version de Java il y a de plus en plus de Garbage Collectors (GCs) avec de plus en plus d'options. On entend des phrases cryptiques telles que "Oh trop bien ZGC est devenu générationnel alors que Shenandoah ne l'est pas" ou "T'as vu chez Netflix ils ont réduit leurs tail latencies avec ZGC". Du coup on se pose tout plein de questions: * qu'est-ce qu'ils racontent ? * ZGC c'est quoi ? * si ce ZGC est si magique, pourquoi il y a d'autres GCs dans Java, hein ? * pourquoi on ne parle toujours que des différents GCs de Java mais jamais pour Go ou JavaScript ? chez Java ils ne sont pas capables d'en choisir un ? * et en natif, on a besoin d'un GC ? Dev Java ou simples curieuses et curieux, tout le monde est bienvenu. On va repartir des bases, en commençant il y a 30 ans lors de la création de Java jusqu'à maintenant pour comprendre pourquoi on a toujours besoin d'un GC et pourquoi ce n'est pas un problème résolu (comme l'API Collection). On fera aussi un tour des GCs, de leurs évolutions, de pourquoi on en est arrivé là, de leurs forces et de leurs faiblesses. (spoiler alert: ZGC n'est pas le GC qui les remplacera tous) À l'issue de ce talk vous saurez quand utiliser quel GC afin de trouver le plus adapté à chaque projet, chaque application, chaque environnement.

Existe-t-il quelque chose de pire qu’un bug vicieux ? Oui : un code legacy inefficace ! Non seulement sa maintenance nous terrifie, mais il exige toujours plus de ressources et alourdit notre empreinte carbone. Et si l’IA venait à la rescousse ? Comment peut-elle nous aider à convertir un vieux projet legacy vers une technologie plus frugale en énergie ? Nous explorerons deux pistes : • convertir un code source écrit dans un langage énergivore vers un langage plus performant ; • détecter, mesurer et optimiser les "hotspots" d’un projet existant. Enfin, nous verrons si l’opération en vaut la peine : avons-nous réellement économisé plus d’énergie avec notre code optimisé que celle dépensée par l’IA pour y parvenir ? Préparez-vous à découvrir comment l’IA peut transformer votre legacy en code plus performant et plus respectueux de l’environnement !

Dans la plupart des jeux vidéo modernes, un “replay” n’est pas une vidéo mais une simple liste d’événements : les inputs des joueurs, quelques événements système et un état initial minimal. Pour revoir une partie, le moteur ne fait “que” tout rejouer dans l’ordre et reconstruit ainsi l’intégralité de la session. 🎮📜 Côté backend, l’event sourcing applique exactement la même idée : au lieu de stocker uniquement l’état courant, on enregistre la chronologie des décisions métier (events) qui ont mené à cet état. On peut alors “remonter le temps” pour débuguer un bug tordu, auditer un comportement étrange, ou reconstruire un système sur une nouvelle architecture. Dans ce talk, on partira de cas concrets côté jeux (replays, rewind, killcams) pour expliquer pas à pas : - comment fonctionne un système de replay basé sur un log d’événements, - en quoi ce modèle diffère d’une approche CRUD classique, - ce que l’event sourcing reprend de cette idée pour nos SI. Je montrerai un mini-système de replay dans un petit jeu ainsi qu’un exemple d’event store côté backend (Java/TypeScript), sans masquer les limites : coût de relecture, complexité, tooling… 🎯 Public cible : dévs backend / fullstack, architectes, curieux d’architecture qui aiment les métaphores vidéoludiques 💾 Plan proposé 1 - “Un replay, ce n’est pas une vidéo” Comment les jeux enregistrent une partie : log d’événements + état initial. Démo simple : rejouer une partie en réinjectant les inputs dans une boucle de jeu. 2 -De la partie au système : introduction concrète à l’event sourcing Modèle CRUD vs modèle “flux d’événements rejoués”. Notions d’event store, projection/lecture, relecture d’événements. 3 - Cas d’usage réels : debug, audit, résilience Time-travel debugging, audit, reconstruction d’état / migration. 4 - Limites, pièges et conseils pragmatiques Coût de la relecture, snapshots, complexité pour les équipes, tooling et quand ne PAS utiliser l’event sourcing.

Vous en avez assez de voir vos Tests Unitaires passer... alors que votre application plante en production ? Fatigué de devoir adapter des dizaines de mocks à chaque refactorisation ? Il est temps de passer aux Tests d'Intégration ! Dans ce codelab, nous explorerons comment tester efficacement une application Spring Boot en simulant les dépendances externes : * WireMock pour simuler vos appels API, * Testcontainers pour tester une vraie base de données dans un environnement isolé, * LocalStack pour reproduire vos intégrations AWS. Repartez avec une application plus robuste, des tests plus fiables… et moins de surprises en production !

Dans nos métiers, la dette technique est sans doute la chose la plus frustrante, éprouvante et coriace contre laquelle nous devons lutter. Bien sûr, il existe des bonnes pratiques : refactoriser, viser la simplicité avec KISS, éviter de trop anticiper avec YAGNI afin de limiter cette dette au maximum. Et pourtant, on n’y vient jamais vraiment à bout. Pire encore, elle continue de s’accumuler même lorsque nous les appliquons, comme une fatalité. Et si ces mêmes bonnes pratiques ne faisaient parfois qu’empirer le problème au lieu de le résoudre ? La dette technique peut n’être que la partie visible de quelque chose de plus profond : la dette de design accidentelle. Un problème bien plus complexe, donnant lieu à des logiciels spaghettis et à des microservices en « monolithe distribué », dont nous sommes souvent à l’origine sans même nous en rendre compte. Dans cette conférence, nous explorerons les mécanismes de la dette de design et ses impacts, conséquents sur notre architecture, nos processus, notre organisation, et même notre business. À travers des exemples concrets, nous verrons comment la détecter, analyser sa profondeur et agir avant qu’elle ne s’ancre durablement.

Votre pipeline GitLab CI/CD est-il vraiment plus fiable que l'application qu'il déploie ? À partir de deux scénarios d'attaque réalistes, exfiltration de secrets via variables CI et compromission par merge request malveillante, cette session montre comment un attaquant exploite les mauvaises configurations les plus courantes, puis comment mettre en place des protections durables sans freiner les équipes. La CI/CD est devenue un composant critique du système d’information. Pourtant, sur GitLab, elle concentre encore trop souvent des variables sensibles, des permissions excessives et des règles d’exécution qui ouvrent la porte à des abus simples mais redoutablement efficaces. Dans cette session, nous partons de deux scénarios d’attaque réalistes observés autour de GitLab CI/CD : - l’exploitation de variables CI mal protégées pour exfiltrer des secrets, tokens ou credentials ; - la compromission d’un pipeline via une merge request malveillante, jusqu’à la publication d’artefacts corrompus ou l’introduction de code non maîtrisé dans la chaîne de livraison. L’objectif n’est pas de faire peur, ni de dérouler une checklist figée. À partir de trois années passées à sécuriser des pipelines GitLab en production, nous montrons surtout ce qui tient dans la durée : - les réglages GitLab qui réduisent réellement la surface d’exposition ; - les règles de gouvernance qui évitent les dérives sans bloquer les développeurs ; - les mécanismes de contrôle continu qui permettent de détecter les écarts avant qu’ils ne deviennent exploitables. Ensemble nous verrons comment repenser la sécurité GitLab CI/CD comme un système vivant : moins basé sur des audits ponctuels, davantage sur des garde-fous durables, mesurables et compatibles avec la réalité des équipes.

En architecture informatique, on sait concevoir un système capable de gérer différents types de requêtes qui soit clair et performant avec des temps de réponse prévisibles : découper en modules, définir les rôles, spécifier les interfaces, détailler les échanges, superviser, améliorer en continu... Et si on appliquait ce savoir à la conception... d'une DSI ? Durant ce talk, je vous partage mon expérience suite à la réorganisation d'une DSI : identifier les symptômes d'une mauvaise organisation, rechercher les causes premières, redécouper les équipes, définir leur rôle et leurs échanges, suivre les progrès, faire les ajustements. Au menu : agilité, DORA, Team Topologies, sens et bon sens !

Vous vivez dans la Matrice : un Bearer Token (access_token) vous donne l’accès à vos applications… mais si un Agent Smith l’intercepte ? Game over. Il a tous vos accès sans demande de mot de passe, pas de preuve de possession – vous avez donc juste une illusion de contrôle. Suivez le lapin blanc jusqu’à DPoP (Demonstration of Proof-of-Possession, RFC 9449) : vos tokens deviennent inséparables d’une clé privée. Prouvez que vous êtes L’élu, ou rien. Restons au pays des merveilles, et descendons avec le lapin blanc au fond du gouffre : * PKCE, la première barrière contre l’interception du code d’autorisation * Les failles critiques des bearer tokens * Comment DPoP fonctionne * Les pièges d’implémentation dans le monde réel où les Agents se cachent encore … pour montrer qu’il est temps de sortir de l’illusion que toute la sécurité est faite avec les bearer tokens. Pour devs, architectes et équipes sécu qui veulent arrêter de vivre dans le rêve bleu.

Bienvenue dans la Matrice. Un monde où les deadlines pleuvent, où les notifications remplacent les battements de ton cœur, et où la productivité est devenue la nouvelle réalité. Tu te crois libre, maître de ton code et de ton agenda ? 🧑‍💻 Et si tout cela n’était qu’une illusion soigneusement entretenue ? Dans ce talk, je vous invite à replonger dans votre cerveau, non pas pour sauver l’humanité, mais pour sauver vous-même. Car quelque part entre un sprint Jira et un visio Teams, beaucoup d’entre nous ont avalé la mauvaise pilule. 😵‍💫 En suivant la voie de Neo, on décodera ensemble les illusions du travail moderne — performance, perfection, disponibilité permanente — qui nous font glisser pas à pas vers le burn-out 🧠. Avec humour, anecdotes et auto-dérision, je vous montrerai les 10 programmes les plus dangereux de la Matrice du travail, et surtout comment en sortir… sans débrancher complètement. 🎤 Format et ton : Un talk énergique, fun, un brin philosophique — mélange de storytelling, d’interaction, de références pop-culture et de déclics concrets à appliquer dès le lendemain. Ni moralisateur ni soporifique : un miroir bienveillant pour tous les devs, managers ou freelancers coincés dans la simulation. 🎯 Plan du talk : 1️⃣ Bienvenue dans la Matrice du boulot — Pourquoi on ne voit pas les signaux du burn-out 2️⃣ Les 10 programmes toxiques — “Toujours dispo”, “travailler plus = valeur”, “ignorer les bugs physiques” 3️⃣ L’illusion du contrôle — Pourquoi le cerveau adore le stress (et comment il nous trompe) 4️⃣ Choisir la pilule rouge — Les vrais hacks pour se reconnecter au réel (sommeil, limites, déconnexion, sens) 5️⃣ Reload — Comment reprogrammer durablement son rapport au travail ⚡ Public : Développeurs, managers, indépendants, curieux du lien entre temps, code et santé mentale. Un talk pour rire, réfléchir et, peut-être, choisir enfin… la pilule rouge. 🔴

Chaque application naît propre. Quelques années plus tard, elle est devenue le monstre que personne ne veut toucher. Ce n'est pas une fatalité, ce n'est pas de la malveillance, c'est le cycle de vie naturel d'une application. Tout professionnel de l'informatique a ou aura la chance (ou la malchance) de travailler sur des projets récents comme en fin de vie ; avec peu d'utilisateurs comme des milliers ; sur des architectures propres comme sur des codebases que personne n'oserait ouvrir ! On va d'abord comprendre pourquoi nos applications ne sont pas éternelles, comment une codebase si propre et si performante se retrouve petit à petit sous perfusion. Pression produit, turnover, dépendances qui meurent, hotfixes qui s'accumulent… On nomme les coupables. Puis on passe aux antidotes : comment maintenir une application en bonne santé du début à la fin, et quand ce n'est plus possible, comment préparer la transmission dans les meilleures conditions ? Durant ce talk, vous allez pouvoir prendre du recul sur vos projets. À lire leur état de santé. Et surtout, à répondre à la vraie question : est-ce qu'on se bat pour la survie ou est-ce qu'on accompagne pour laisser place à autre chose ?

Les cartes servent généralement à visualiser des données. Mais que se passerait-il si elles pouvaient aussi simuler le monde réel, un peu comme dans Matrix, où le monde n’est qu’une simulation? Dans ce talk, nous verrons comment transformer une carte classique en jumeau numérique simplifié d’un territoire. L’objectif : créer un système capable d’intégrer des données, de les traiter et de simuler certains phénomènes (trafic, météo, flux urbains…). À travers une démonstration concrète, nous construirons pas à pas un mini jumeau numérique en utilisant des outils open source. Nous aborderons notamment : La gestion de données spatiales. La transformation et l’intégration de données spatiales. La visualisation interactive de carte. Les bases d’une architecture permettant de simuler un système territorial. L’objectif n’est pas de construire un modèle parfait, mais de montrer comment un développeur peut créer les fondations d’un système capable de représenter et de simuler le monde réel. Un voyage au croisement des SIG, de la data et de l’architecture logicielle… et une petite plongée dans la matrice géospatiale.

Vous avez fait un POC de Keycloak rapide et convaincant et vous pensez que le plus dur est fait ? Venez découvrir les 10 principaux pièges dans lesquels tombent régulièrement les équipes qui intègrent Keycloak. Sécurité, architecture, gouvernance, développement, exploitation... nos retours d'expérience couvriront la plupart des aspects d'un projet Keycloak. Vous repartirez avec quelques clés importantes pour anticiper les difficultés et réussir un déploiement durable et sécurisé.

Il y a cinq ans, j’ai lancé bénévolement une application de suivi de symptômes chroniques. À l’époque, c’était un projet utile, motivant, techniquement intéressant. Je n’avais pas vraiment anticipé ce que signifiait la faire vivre dans la durée. Aujourd’hui, elle compte 11 000 utilisateurs et tourne sur Android, développée en Angular et packagée avec Ionic Capacitor. Dans cette conférence, je parlerai un peu de l'app en elle-même mais surtout de ce que ces cinq années m’ont appris : maintenir seul une application utilisée quotidiennement, gérer la dette technique qu’on crée sans s’en rendre compte, absorber les évolutions Android, corriger des bugs qui n’existaient pas la veille… et faire face à un incident critique lié aux permissions et à l’accès aux fichiers qui m’a obligé à revoir certaines certitudes. Je parlerai aussi de la partie invisible : répondre aux mails, gérer les bêta-testeurs, rassurer, expliquer, prioriser, dire non. Parce qu’une application, bénévole ou non, ce n’est pas juste de la tech. C’est une responsabilité. Un retour d’expérience honnête sur ce que représente vraiment un projet mobile qui dure : l’investissement, l’engagement, et tout ce qu’on n'imagine pas avant de cliquer sur “Publier sur le Play Store”.

On attend du Techlead qu’il sache. On vient le voir pour chaque décision : relecture de code, décision d'architecture, arbitrage produit, debug complexe, médiation d'équipe... Et plus il est compétent, plus il est sollicité ! Le paradoxe ? Sa valeur crée sa surcharge. Et si le rôle du TechLead n’était pas d’avoir les meilleures réponses… mais de poser les meilleures questions ? Le questionnement puissant est une compétence centrale en coaching mais quasiment absente de la culture technique. Alors permettez-moi de vous offrir cet angle nouveau qui pourrait vous permettre de : - réduire la charge cognitive du TechLead, - faire émerger des solutions plus solides, - responsabiliser sans imposer, - et d'éviter les dépendances invisibles Un sujet pour celles et ceux qui veulent faire grandir leur impact sans s’épuiser.

Comme beaucoup de français, tu as peut-être juré de ne plus jamais utiliser la langue de Shakespeare une fois le bac terminé ! Mais… tu as choisi l’informatique… GAME OVER! Je suis américaine native et formatrice en anglais depuis 20 ans pour le public français. Beaucoup de mes stagiaires se sentent “nul en anglais”, enfermés dans cette INFINITE LOOP de la cuisine de Brian parce qu’ils n’ont pas retenu toute la liste de verbes irréguliers! Il est encore temps de faire un BREAK de ses peurs et RESTART sur de bonnes bases. En effet la cuisine de Brian, l’ancienne méthode d’enseignement qui s’appuie beaucoup sur l’apprentissage par coeur, est beaucoup trop étroite pour développer ta créativité… pour coder… pour t’exprimer… t’ouvrir de nouvelles portes ! Si tu n’as pas réussi à retenir ne serait-ce que la moitié de la liste de verbes irréguliers, ou tu n’as pas réussi à bien faire la différence entre I was going, I went, et I have gone, ce talk est pour toi! Bonne nouvelle, ce n’est pas forcément de ta faute et il existe d’autres méthodes très efficaces pour y remédier… Je vais donner quelques astuces et bons plans qui ont fait leurs preuves avec mes stagiaires et qui permettent d’avancer efficacement en anglais au quotidien. Et après, promis Brian will EXIT ;)

L'annotation @Transactional de Spring semble simple en apparence : on l'ajoute sur une méthode et magie, nos opérations deviennent transactionnelles ! Mais derrière cette simplicité se cachent des mécanismes complexes qui, mal compris, peuvent conduire à des bugs subtils et des problèmes d'intégrité de données. Dans ce talk, nous décoderons ensemble les subtilités de @Transactional pour comprendre comment Spring gère réellement vos transactions et pourquoi certains patterns échouent là où d'autres réussissent. À travers des exemples concrets et des cas d'usage réels, vous découvrirez les mécanismes internes de Spring et développerez une intuition solide pour éviter les pièges les plus fréquents.

Dans le premier projet dans ma carrière professionnelle en tant que développeur, les membres de l’équipe ont souvent changé durant la durée de vie du projet d’une douzaine d'années. Étant arrivé vers la fin du projet, j’ai pu rapidement comprendre les choix techniques du projet, et apprécier la qualité de maintenabilité de la base de code. Très peu de dettes de connaissances étaient présentes car tous les changements étaient bien retranscrits en utilisant une pratique de commits atomiques au sein de l’outil de versionning Git. Dans mon projet actuel, les développeurs n’utilisent pas cette même pratique. Les difficultés sont donc multiples. Ma présentation a pour but de faire un retex sur les gains et la mise en place de cette pratique de commits atomiques Voici ce que vous apprendrez dans la conférence: Définir ce qu'est un commit atomique et les types de changements rencontrés Structuration du commit: Choisir une convention de nommage des commits. Utilisation de la nomenclature de commit conventionnels S'attacher au “pourquoi” plutôt qu'au “quoi” “comment” dans le message de commit Réécrire son historique Git avec le rebase interactif A la fin de cette conférence, les spectateurs pourront eux mêmes appliquer cette méthode et en tirer les bénéfices suivants Tracer et documenter des choix techniques sans utiliser des commentaires directement dans le code Réduire le temps passer à faire des relectures & le nombre de commentaires pour comprendre la visée de certains changements Identifier plus rapidement l’introduction de bugs au sein du code avec l’utilisation de la commande “git bisect”

Le "1 Billion Row Challenge" a poussé Java dans ses derniers retranchements. Mais Node.js, souvent réduit à son rôle "single-threaded", a-t-il les épaules pour relever ce défi ? Je vous propose un voyage au cœur de la compréhension du runtime. Nous partirons d'une implémentation naïve pour la reconstruire brique par brique. Au programme : éviter le Garbage Collector, maîtriser le Zero-Allocation, et orchestrer Worker Threads et Shared Memory ou encore utiliser WebAssembly. Venez découvrir comment transformer du JavaScript classique en une solution haute performance, grâce à des concepts applicables bien au-delà de ce challenge.

Cette conférence est issue d'une histoire vraie, où j'ai du écrire un moteur de règles qui doit pouvoir modifier le contenu d'un document JSON en utilisant un DSL maison 🍜 exposé par une API REST 😅 Lors de la première tentative, nous étions parti sur l'utilisation du langage Kotlin, à base de KFunction, de KParameters, d'introspection, qui s'est révélée être un enfer. C'est en discutant de mes déboires avec un collègue qu'il m'a dit: "mais en fait c'est un AST ton truc 💡". L'AST, Abstract Syntax Tree est une structure de données permettant de représenter un programme, exactement ce que l'on cherche à accomplir pour notre moteur de règles, mais ça je ne le savais pas ! Le lendemain, il m'envoyait un scratch IDEA de 40 lignes représentant bien mieux le coeur de notre futur moteur que mes innombrables fonctions génériques de haut niveau et mon code impossible à maintenir. C'est pas clair ? Alors venez, on redéveloppe from-scratch le coeur du moteur avec Kotlin en quelques lignes de code, en illustrant le concept de ce fameux AST.

Jointures et agrégats : deux piliers du SQL qui, malgré leur symétrie fonctionnelle (passer d’un enregistrement à plusieurs, ou inversement), cachent des mécanismes et des pièges radicalement différents. Les jointures vous jouent des tours ? Doublons inattendus dans vos résultats paginés, choix cornélien entre INNER ou LEFT JOIN… Et côté agrégats, les classiques SUM, MAX ou MIN ne suffisent plus ? Découvrez comment exploiter les window functions, les CUBE/ROLLUP/GROUPING SETS, et même les agrégats avancés de PostgreSQL (JSON, XML) pour transformer vos requêtes en outils ultra-puissants. Si vous utilisez SQL, cette conférence vous donnera les clés pour écrire du SQL expressif et "moderne". Prêt à passer à la vitesse supérieure ?

Aujourd'hui, on prend conscience de l'importance de la cybersécurité. Le moindre piratage peut causer des pertes importantes, tant au niveau image que financier. Les premiers acteurs de la sécurité sont les développeurs. Avec une vision basée sur la seule protection des SI, ils n'envisagent pas les possibilités de l'attaquant. Ne faudrait-il pas changer ce fonctionnement et passer dans la peau de l'attaquant pour élargir notre vision de la cybersécurité ? Comme le dit le dicton : "ce sont les braconniers qui font les meilleurs gardes-chasse" 😉 Chaque développeur devrait coder avec en tête : "comment je pourrais bien casser ça ?" Devenir hacker c'est revenir aux basiques (modèle OSI, algorithmie...) et accroître sa polyvalence. Au cours de ce talk, nous allons voir pourquoi la cybersécurité embarquée dans les équipes de développement est un atout majeur pour les projets, et quelles compétences doivent être apprises afin d'acquérir une maîtrise complète des systèmes d'information en place. L'objectif est qu'en sortant, vous soyez convaincu qu'il est essentiel de "penser au hack de son code" au moment même de son écriture, et que vous soyez armés pour proposer une correction 💪

Après vous avoir présenté mon CPU 8-bit sur breadboard, ma carte graphique VGA et après avoir joué de la trompette à la keybote de fin, je reviens pour présenter mon Apple à moi toujours sur breadboard et pour toujours plus de surprise ;) Nous allons découvrir comment pas à pas on peut partir d'un simple transistor et arriver à un ordinateur digne de l'Apple de Steve Wozniak. Nous allons également redécouvrir les premiers standards et protocoles comme le fameux RS-232 (communication série).

On est en 2026 et l'authentification par mot de passe est toujours largement utilisée. Mais bon, il faut que les utilisateurs arrêtent d'utiliser "toto" ou "azerty"... Alors je vais faire comme d'habitude et imposer un mot de passe de 10 caractères avec 1 majuscule, 1 minuscule, 1 chiffre et 2 caractères spéciaux comme ça je serai tranquille... Êtes-vous sûr·e de vos pratiques ? Êtes-vous prêt·e à confronter vos intuitions à la réalité mathématique ? Dans cette conférence, nous allons creuser le sujet d'une "bonne" politique de mots de passe, bien comprendre ce qu'est un mot de passe dit "robuste" ou "complexe" et voir des concepts clés pour critiquer objectivement la gestion de ceux-ci dans un SI. Nous mènerons une réflexion progressive et illustrée afin de bien appréhender et s'approprier ces concepts. L'objectif est de tordre le cou aux pratiques contre-productives, aux intuitions erronées et autres fausses bonnes idées. Cette conférence s'adresse à toutes personnes créant ou utilisant un SI : développeuses, chef de projet, directrice de SI, architectes, responsables de produit, MOA, utilisateurs...

"On va mettre un cache, ça ira plus vite." Cette phrase a déjà coûté des nuits blanches à bien des équipes. Le cache est souvent introduit comme une "optimisation" rapide à mettre en place. En réalité, il transforme profondément le comportement d'un système : cohérence éventuelle, données obsolètes, effets de bord distribués... et bugs impossibles à reproduire. Aujourd'hui, ces mêmes défis réapparaissent dans les architectures intégrant des LLMs, avec l'émergence de modèles comme le *semantic caching*. Partons ensemble pour un voyage pragmatique dans le monde du cache : - ce qu'est réellement un cache (et ce qu'il n'est pas), - les principaux patterns de caching et leurs compromis, - les anti-patterns classiques qui transforment une application rapide en cauchemar opérationnel, - un arbre de décision pour choisir la bonne stratégie. Cette session vous donnera les outils pour construire des systèmes rapides et prévisibles, et vous aidera à ne plus jamais considérer le cache comme un simple détail d'implémentation.

Generative Pre-trained Transformer, GPT. 3 lettres et une architecture simple qui a changé le monde, comme le vol d'un papillon déclenche un ouragan. Pourtant, la majorité d'entre nous n’ont pas eu l’occasion de soulever le capot et se contentent de vivre dans la Matrice. Si même nous les devs, on ne comprend pas comment ça marche, qui le pourra ? microgpt d'Andrej Karpathy, c'est 200 lignes de Python pour un modèle GPT minimaliste mais complet, idéal pour comprendre la révolution IA. Je vous propose de les réimplémenter en TypeScript, notre lingua franca, en détaillant chaque fonction de l'algo sur lequel repose Gemini, ChatGPT ou même Claude. https://karpathy.github.io/2026/02/12/microgpt/

Fin 2025, nous avons mis en place un mécanisme de rate limiting sur nos APIs à l’aide de Spring Cloud Gateway. Début 2026, le business y voit une opportunité plus large : quotas journaliers, endpoints premium et facturation à l’usage. Nous avons du réagir et faire évoluer un mécanisme purement technique en une plateforme API beaucoup plus large : Gateway custom vs solution d’API Management sur étagère (Kong, Gravitee...) Quotas persistants vs limites court terme Gestion in-memory vs stockage Redis distribué Performance à 200 requêtes par seconde et 400k utilisateurs Observabilité interne vs exposition client Dans ce talk, nous décrirons la mise en place de notre rate limiting technique puis les dilemmes rencontrés en le transformant en plateforme API commercialisable

Vos APIs ont pris un peu de poids ? Elles consomment plus que nécessaire ? Pas de panique, on sort la boîte à outils pour leur faire un Green relooking ! Dans ce Tools-in-Action, nous appliquerons pas à pas le framework "API Green Score" sur une API réelle et existante, avec des outils open-source et des métriques concrètes. Le constat est simple : les APIs modernes sont souvent gourmandes. Le problème ? Pas le manque de principes, mais l’absence de règles mesurables et automatisées. En live, nous : - prendrons les mesures (payload, latence, cache), - calculerons le Green Score par endpoint, - mettrons en place des règles actionnables : compression GZIP/Brotli, champs partiels, allègement des données transférées, pagination obligatoire, … - automatiserons la non-régression (SonarQube, Spectral). Résultat ? Une API plus légère, plus rapide, et un impact environnemental réduit. Nous vous montrerons les gains en direct (avant/après) : trafic réseau réduit, latence stabilisée, cache optimisé. Et pour repartir avec du concret, un repo GitHub vous attend avec tout le nécessaire pour reproduire la démarche.

Vous vous êtes déjà demandé où en était une migration interne, ou l’adoption d’une pratique tech dans votre entreprise ? Peut-être même avez-vous déjà été celui ou celle qui a dû en faire l'évaluation et le suivi (fastidieux, manuel, vite obsolète, et souvent oublié) ? Ce talk vous propose une piste d'éclaircissement concrète : les **"policies"** techniques. Toute plateforme interne cherche à encourager et façonner certains "comportements" au sens large, tout en les rendant plus simples à adopter : maintenir ses dépendances à jour, définir des SLOs, appliquer des standards de tagging, migrer vers une nouvelle bibliothèque ou de nouveaux services, etc. Mais **la plupart de ces attentes restent implicites ou suivies manuellement**, transformant le suivi des progrès en simple ressenti plutôt qu’en métriques fiables. Et si nous explorions comment transformer ces attentes en policies (des règles explicites, vérifiables automatiquement) pouvant aider les plateformes à évoluer de "encourager les bonnes pratiques" à leur mesure concrète ? Nous verrons : - Quels types de comportements et standards peuvent être exprimés sous forme de policies - Comment les implémenter de manière dynamique et data-driven, avec des exemples d'outillage tels que Kyverno, Open Policy Agent, AWS Config, et d'autres - Comment les utiliser pour suivre migrations, conformité ou taux d’adoption - Comment obtenir des résultats partageables aux équipes et au leadership - Un bref retour d'expérience et des exemples tirés de notre application de ce concept chez PayFit À travers cette approche, une plateforme devient plus qu’un ensemble d’outils : un système vivant, observable, et capable de piloter le changement organisationnel.

Derrière les quelques lettres qui suivent un point – .com, .fr, .ai – se cache un univers riche de stratégies techniques, d’enjeux géopolitiques et de batailles commerciales. À l’approche du nouveau round de l’ICANN prévu en 2026 qui va autoriser de nouvelles extensions, il est temps de revenir sur les fondations techniques du DNS, ainsi que sur les grands épisodes de cette aventure méconnue. Des TLD historiques aux extensions détournées, des dramas autour du .web aux ambitions du Web3, nous explorerons l’évolution d’un système devenu central dans les logiques de souveraineté numérique et d’innovation commerciale. Une plongée dans les coulisses d’un Internet en perpétuelle transformation.

Dans le monde Java, nous sommes habitués à initialiser un projet avec de nombreux fichiers et répertoires. A tel point que des CLI ont vu le jour pour nous aider à créer les projets SpringBoot ou Quarkus par exemple. Vient ensuite le choix du "package manager" : Maven ou Gradle ? Et c'est seulement à partir de là que l'on peut commencer à développer puis exécuter son code 😅. Toutes ces étapes fastidieuses expliquent pourquoi, lorsque que l'on a besoin de faire un développement rapide de quelques lignes pour automatiser une action, on préfère d'autres langages à Java : Python par exemple. Et si je vous disais, qu'avec JBang, vous allez pouvoir rester avec votre langage préféré, Java, et développer une classe toute simple (avec des dépendances externes) en quelques secondes ! C'est le pari (spoiler : réussi) de JBang que je vous propose de découvrir durant une session de live coding. A vous les joies du scripting en Java !

Quand on jouait au loup dans la cour d’école, il y avait une règle tacite : “on touche pas son père” — on ne retouche pas celui qui vient de nous toucher, sinon la partie tourne en boucle. En code, beaucoup d’équipes finissent par appliquer la même règle à la classe mère : “ne touche pas au parent, tu vas tout casser”. Et c’est souvent le signe de bugs dans la Matrice : couplages implicites, effets de bord, overrides surprenants… et, au passage, des glissements progressifs vers des violations des principes SOLID. Dans cette session, je propose une autre approche : remplacer l’héritage utilisé pour partager du comportement par de la composition et de la délégation en Kotlin (by). L’idée est simple : au lieu d’empiler des responsabilités dans une hiérarchie de classes, on construit des services “en couches” (wrappers / décorateurs) qui ajoutent chacun un comportement précis, tout en déléguant le reste. À travers quelques refactorings “avant / après”, on verra comment cette approche rend les responsabilités plus explicites, facilite les tests, et permet d’évoluer sans créer de nouvelles classes de base ni de hooks implicites — avec une méthode de migration progressive, applicable sur une base existante.

Le monde des interfaces utilisateur entre dans une nouvelle dimension. Comme Neo face à la pilule rouge, nous devons faire un choix : rester dans le confort rassurant de la 2D ou entrer dans la matrix de l'XR. Mais comment s'affranchir des limites de l'écran sans renoncer aux outils que nous maîtrisons? Cette session vous révélera les enseignements tirés du prototypage et de la migration d'une application Android existante vers Android XR avec Jetpack Compose pour XR. Nous ira au cœur du code pour découvrir comment architecturer votre application et comment utiliser le composant Subspace, qui la gateway vers le monde XR, et comment exploiter les nouveaux composants tels que SpatialPanel, SpatialRow ou SpatialColumn pour construire vos interfaces XR. À l'issue de cette session, vous aurez un aperçu complet pour vos premiers pas en XR, des patterns éprouvés pour spatialiser vos applications Compose, et surtout, tout le nécessaire pour anticiper les obstacles qui vous attendent. Pilule bleue ou pilule rouge ? Il est temps de voir jusqu'où va le terrier du lapin XR 🕶️

Les bases de données orientées graphe sont un allié puissant pour représenter les connaissances et agir en acteur avisé. Dans cette session, je vous propose une mise en situation : Neo est bloqué dans la matrice face à ses redoutables adversaires. Grâce à une connaissance bien structurée du domaine dans lequel il est plongé, nous pouvons l'aider à s'échapper. Pour cela nous allons construire un graphe de connaissances. Ce sera l'occasion de vous proposer quelques grands principes de modélisation de graphe : quels sont les concepts du domaine, quelles sont les relations qui les lient, et comment leur donner de la sémantique pour résoudre notre problème ?

Tous les développeurs Java se sont un jour ou l’autre cassé les dents sur une NullPointerException en production. Il y a eu beaucoup de tentatives pour atténuer ce problème (annotations, Optional, …), couronnées de plus ou moins de succès. Dans ce Tool-in-Action, nous verrons comment JSpecify s’attaque au problème et ce qu’il apporte de plus par rapport aux autres annotations de null safety : analyse statique, intégration à Spring Boot 4 et interopérabilité avec Kotlin.

Hourra ! Neo à 50 ans et pour éviter qu'il ne rate sa vie, ses copains lui offrent une montre ! Pour ne pas être facilement tracable, cette montre sera entièrement DIY ! Du choix du microprocesseur à la conception du bracelet, de la boite en passant par l'écran, un firmware custom et à une deadline plus que serrée, venez découvrir les étapes de sa conception, puis ce qu'il a décidé d'en faire pour entrer dans la matrice.

Je veux vous parler de convivialité dans son sens qui n'implique ni vin ni fromage: celui théorisé par le philosophe Ivan Illich, qui permet d'étudier le rapport de l'Homme à ses outils. Bien que mort en 2003, sa philosophie reste assez moderne pour l'appliquer à l'outil qui nous questionne toutes et tous: l'IA générative. On commencera par expliquer le concept de convivialité au sens d'Illich au travers de l'analyse de différents outils, avant de se pencher plus en détails sur l'IA générative pour finir sur des conseils pratiques.

Vous aimeriez pouvoir ajouter des animations à votre front-end web afin de proposer une expérience plus fluide à vos utilisateurs mais vous êtes découragés par la complexité de la tâche ? Vous maîtrisez comme personne transitions CSS, keyframes et animations FLIP mais vous en avez marre de gérer les problèmes d'interface et d'accessibilité causés par cette technique ? Vous développez un site multi-pages full-stack plus traditionnel (rails, express, laravel...) et vous aimeriez améliorer la navigation entre les différentes pages de votre site ? Pour résoudre tous ces problèmes et plus encore, venez découvrir l'API viewTransition. Grâce à elle, vous pouvez déléguer au navigateur l'essentiel du travail d'animation et réaliser des transitions entre les différents états de votre application devient un jeu d'enfant, même entre des documents HTML différents (🤯) ! Au programme, je montrerai comment fonctionne cette API et quelles sont les meilleures pratiques pour l'utiliser dans tous les contextes. Nous verrons ensemble que l'API viewTransition permet de dépasser des obstacles jusqu'ici infranchissables dans le développement web !

En tant qu’actrices et acteurs de la Tech, nous nous pensons souvent comme des ingénieurs et ingénieures : rationnels, méthodiques, cherchant à améliorer nos produits et nos pratiques par l’intelligence collective. Nous parlons d’expérimentation, d’itération, de rigueur… bref, d’ingénierie. Pourtant, quand on observe nos échanges sur les réseaux sociaux ou dans nos réunions, on découvre un tout autre monde. D’un côté, un influenceur proclame que “tester est une perte de temps”. De l’autre, une experte affirme que le TDD est la clé de la robustesse logicielle. Un Scrum Master défend la vélocité en story points pendant qu’une développeuse revendique le noEstimates. Et au centre, les commentateurs tranchent : “tout le monde a raison, du moment que ça vous apporte de la valeur”. Et si, au fond, notre univers technique ressemblait plus à une pop culture qu’à une science appliquée ? Et si, derrière nos débats passionnés, se cachait une croyance partagée : celle que nos opinions valent des vérités ? Dans cette conférence, nous verrons comment nos comportements, nos biais et nos figures d’autorité ont transformé la Tech en un espace de croyances, parfois éloigné de sa nature d’ingénierie. Nous explorerons comment retrouver une posture plus critique et plus rigoureuse : - distinguer opinion, intuition et preuve scientifique - reconnaître nos défauts de posture en tant qu'observateurs / observatrices mais aussi bien en tant qu'expertes et experts (dualité anti-intellectualisme et gatekeeping) et comment réformer notre posture intellectuelle. - renouer avec l’esprit de la méthode scientifique, comme l’agilité l’avait initialement envisagé ; - sortir du relativisme confortable sans tomber dans le dogmatisme. Une invitation à réconcilier curiosité, esprit critique et humanité dans un métier qui n’a jamais été aussi "culturel" qu’aujourd’hui.

Pourquoi nos plateformes numériques se ressemblent-elles toutes (mêmes contenus, mêmes algorithmes) au point de ne former qu'une seule et même Matrice assoiffée de nos traces virtuelles ? En dépit de notre supposée liberté d’action, pourquoi sommes-nous en réalité prisonniers de systèmes et d’algorithmes qui ne sont ni neutres ni bienveillants ni émancipateurs et qui nous font, en réalité, travailler pour eux ? Plongez avec moi dans l’envers du décor pour comprendre l’Enshittification du web, ce lent déclin de plateformes géantes délibérément conçues au détriment de leurs utilisateurs — et qui ont brisé les 2 piliers du web moderne. Vous découvrirez peut-être l’origine de votre “digital fatigue”, ou bien vous pourrez identifier si vous aussi vous contribuez à "emmerdifier" le web. Et surtout, vous recevrez au travers de cette présentation, un Wake Up Call pour commencer à reprendre votre destinée en mains.

L’IA est incontestablement consommatrice de ressources. Mais puisque le mal est fait, pourquoi ne pas l’utiliser à bon escient pour réduire notre impact carbone ? Je l’ai mise à profit sur notre projet Zou pour optimiser les tests et la CI. Venez découvrir les résultats, c’est impressionnant.

Un SI moderne est souvent composé de nombreuses applications hétérogènes, portant chacune ses propres données. Comment dans ce cas vérifier la cohérence des données de ces différents référentiels, et centraliser une donnée fiable, notamment dans un but de reporting aux équipes métier ? Comment mettre en place une gouvernance des données, des tests de qualité sur ces données dans un contexte réparti ? Ce sont les questions que nous nous sommes posées, et auxquelles nous avons répondu par la création d'une plateforme de données utilisant la philosophie ELT (Extract, Load, Transform) basée sur l'orchestrateur Airflow, sur la brique de gouvernance OpenMetadata et sur DBT pour la gestion des transformations "as code", le tout déployé par Terraform sur Google Cloud. Lors de ce talk, nous partagerons notre retour d'expérience sur la création de cette plateforme : - Réflexions initiales et choix des briques technologiques - Prototypages de la solution et apprentissages - Industrialisation - État actuel de la plateforme et réflexions futures Nous zoomerons notamment sur les différentes briques techniques utilisées, sur notre compréhension de leur fonctionnement et sur nos retours d'utilisation. Nous expliquerons également comment nous avons cherché à rapprocher les pratiques Data, Dev, Ops et sécurité pour réduire le "time to insight" (le temps entre la génération d'une donnée et la mise à disposition d'analyses basées sur cette donnée) et augmenter le "data trust" (la confiance dans les données utilisées pour le reporting) tout en assurant la robustesse de la plateforme.

Factorio est un jeu vidéo d'automatisation hautement addictif (croyez-en mes 400h de jeu). Le but est simple : le vaisseau spatial du joueur est échoué sur une planète extra-terrestre, il faut construire une fusée pour s'échapper, en utilisant toutes les ressources disponibles sur la planète. Le joueur construit alors une usine (d'où le nom du jeu) pour créer des matériaux de plus en plus complexes, jusqu'à pouvoir construire la fusée. Mais quel rapport avec la tech ? Architectures de code spaghetti, en couches et micro-services. Métriques, alertes, root-cause analysis. Scalabilité horizontale, verticale, load-balancing. Charge, débit, performance. Sécurité, firewalls, DDoS. On peut retrouver tous ces concepts dans le jeu. Ce talk, intégralement réalisé dans le jeu, reprend et illustre ces différents concepts qui sont au coeur de nos métiers. Pour les débutants, ce sera l'occasion de comprendre ces concepts fondamentaux. Pour les plus expérimentés, ce sera l'occasion de les voir illustrés en dehors d'un schéma d'architecture ennuyeux. The Factory Must Grow.

Je vais vous parler d'un gros projet, avec un métier complexe. La croissance du nombre de contributeurs a été aussi forte que rapide, mais son architecture logicielle n'a pas été maitrisée. Jusqu'au jour où la dette technique est apparue comme un problème majeur, qui freinait le développement du business, et qu'il a fallu se résoudre à traiter. Dans ce talk je vous expliquerai comment nous avons procédé, et décrirai les outils et méthodes mis en oeuvre pour réorganiser le code aussi bien que les équipes, tout en continuant à faire évoluer le produit. J'évoquerai aussi les difficultés rencontrées, car les embûches sont toujours nombreuses sur un chemin de ce type. Vous pourrez alors réutiliser ces outils et méthodes sur vos projets, afin de démêler votre propre plat de spaghettis.

Swiper vite, taper en mode JIT, réagir en quelques millisecondes (Oh, Schumacher!). On conçoit souvent nos jeux autour de gestes précis et avec un gameplay peu ou pas accessible. Alors qu'un geste, c'est juste une méthode d'entrée : ce n'est pas le gameplay. Et quand on confond les deux, on finit par exclure des joueurs sans même s'en rendre compte ! L'idée de ce talk, c'est de penser autrement : partir des intentions du joueur (attaquer, explorer, interagir) plutôt que du geste qu'il doit faire pour y arriver. Une fois qu'on sépare l'intention de l'input, on peut proposer plusieurs façons de jouer. L'accessibilité devient un choix de design, pas un patch qu'on colle à la fin. Pour illustrer tout ça, j'ai construit Echo Quest, un petit "RPG" narratif avec Flutter et Flame. Ce n'est pas le jeu de l'année mais la démarche est expérimentale ! On y explore une forêt, on résout des énigmes, on se bat au tour par tour. Et surtout, on peut y jouer au tactile, au clavier, ou à la voix : le jeu s'en fiche, il reçoit la même intention. On verra ensemble comment : * structurer son gameplay autour d'intentions plutôt que d'inputs * brancher plusieurs modes de contrôle sur la même logique de jeu * utiliser ce que Flutter nous donne déjà (Semantics, focus, UI adaptative) * tirer parti de l'architecture de Flame (composants, overlays) pour mixer game loop et widgets Flutter accessibles * synthétiser de l'audio spatial avec Web Audio API pour naviguer sans écran * ajuster le rythme et la difficulté pour que chacun puisse jouer à sa façon L'accessibilité dans le jeu vidéo, c'est souvent le truc qu'on ajoute "si on a le temps". Vous l'aurez compris, je ne suis pas dev de jeu vidéo... je suis une dev mobile, concernée par l'accessibilité qui s'est laissé tenté par les jeux vidéos en 2D. Ce talk propose de montrer l'accessibilité autrement, à travers un jeu.

REX complet du déploiement de l'IA générative à la DSI de SIPA/Ouest-France : gouvernance, RGPD, sécurité, choix d'outils, cadre d'usage, mesure des gains — et les erreurs qu'on ne referait pas. Sans bullshit, avec les cicatrices. --- Déployer l'IA générative dans une DSI ce n'est pas juste ouvrir un compte ChatGPT à tout le monde. C'est une démarche qui touche à la sécurité, au droit, à la culture d'entreprise, à l'architecture, et surtout… aux humains. À la DSI de SIPA/Ouest-France (groupe de presse, ~200 personnes dont 60 développeurs), nous avons construit de A à Z une démarche baptisée IA4IT : structurer l'adoption de l'IA générative par les équipes IT, de façon maîtrisée et mesurable. Ce qu'on va raconter Le contexte et l'histoire Comment on est passés d'un usage sauvage et dispersé à une stratégie cohérente. Les signaux faibles, les premiers accidents, le moment où on a décidé d'agir. Les problématiques qu'on n'avait pas anticipées RGPD : quelle donnée peut-on envoyer à quel modèle ? CLOUD Act et souveraineté : jusqu'où peut-on aller avec des outils US ? Responsabilité juridique sur le code généré SSI : surface d'attaque, prompt injection, exfiltration de données Les outils sélectionnés et pourquoi GitHub Copilot, Claude (Anthropic), Cursor — comment on a comparé, négocié les contrats, configuré les garde-fous. Et ce qu'on a refusé. Le cadre d'usage Le document qu'on a co-construit avec les équipes : données autorisées/interdites, règles de revue du code généré, niveaux de confiance par outil. Comment le faire vivre sans que ça reste lettre morte. Le déploiement à l'échelle Plus de 200 utilisateurs, gestion des coûts (spending caps, licences mixtes), onboarding, formation, résistances. Les gains mesurés Métriques DORA, retours qualitatifs. Ce qui a vraiment changé — et ce qui est plus compliqué à mesurer qu'on ne pensait. Les erreurs et ce qu'on referait différemment Les vraies : sur la gouvernance des coûts, sur la communication, sur le rythme d'adoption. Sans langue de bois. L'accompagnement et les bonnes pratiques Comment embarquer les tech leads, les managers, les réticents. Ce qui marche pour ancrer les usages dans la durée. Pour qui ? DSI, architectes, tech leads, engineering managers — toute personne qui doit prendre des décisions concrètes sur l'IA générative dans son organisation, pas juste en lire des articles.

Exposer une application Kubernetes au monde peut devenir un vrai casse tête 🧐. Nous avons d'un côté les API standards avec Ingress, service de `type=LoadBalancer`, voir même les NodePorts… et de l'autre, les APIs custom proposées par les Ingress Controllers et Service-Meshes très avancées mais non standard 😅 Après tant d'années de confusion, une nouvelle API, nommée Gateway API, arrive tout juste en v1.0 (🎉) pour contenter à la fois les développeurs et les opérateurs de cluster ou d'infrastructure 🤯! Nous découvrirons ensemble cette nouvelle API, ses fonctionnalités avancées et les implémentations qui vous permettrons de les utiliser dans votre cluster ⚡️!

"Il y a pas mal de décisions qui ont été prises dans mon entreprise que je ne trouve pas très éthiques, mais de là où je suis, je ne peux pas faire grand chose..." Vous souhaiteriez voir le monde du numérique devenir plus éthique mais vous considérez qu'à votre échelle, vous n'avez aucun impact ? Cette phrase vous parle ? Peut être l'avez-vous déjà prononcée ou entendue autour de vous ? Et si nous vous démontrions le contraire ? D'ailleurs, qu'est ce qu'on appelle "l'éthique" ? Quels sont les impacts de nos décisions quotidiennes ? Et comment faire pour que nos choix soient plus éthiques ?

En attente de mission, je lance mon side-project : serendipitech.fr J'avais l'idée générale : répertorier les conf' en France et proposer une alerte email à ceux qui le souhaite pour être prévenu des nouvelles dates, ouverture des billetteries ou CFP. OK. La stack je l'avais aussi, je voulais continuer d'avancer sur mes acquis : du Spring Boot avec Kotlin et Vue.js en front. Pour l'infra, je voulais mettre mon appli en Docker bien sûr, et un voisin avait un vieux serveur dans un placard, autant que ça serve. Installation d'Ubuntu. Hop, c'est bon. And now what ?! Goutte de sueur sur le front... je commence par quoi ? Le front ? Le back ? Installer Docker ? Acheter mon nom de domaine ? C'est quoi mon premier commit ? C'est quoi ma première feature ? Ahhh. Panique. Mais promis, ça n'a pas duré. J'ai réussi à me lancer. Envie d'en savoir plus ? De savoir si mon serveur à cassé et j'ai plutôt déployé proprement dans le cloud (spoiler : oui) ? Rex décomplexé d'un side project. Pour oser se lancer, prendre du recul sur les différentes briques d'une application et se poser les bonnes questions.

Avec les passkeys, l'authentification devient plus simple pour l'utilisateur qui n'a plus de mot de passe à retenir, tout en étant potentiellement plus sécurisée car les passkeys empêchent le phishing par nature. Mais comment ça marche exactement ? Dans cette présentation, nous décortiquerons ensemble les concepts associés (FIDO, WebAuthn, cryptographie asymétrique, challenge/réponse) puis nous implémenterons pas à pas une authentification par passkey pour illustrer comment ça fonctionne en pratique. Une session pratique pour comprendre pourquoi les passkeys ne sont pas “un mot de passe de plus”, mais un véritable changement de paradigme.

Nous mesurons le coût de l’IA générative en centimes par tranche de 1 000 tokens ou en millisecondes de latence. Mais chaque prompt s’accompagne d’une facture invisible, réglée en kilowattheures et en litres d’eau. À mesure que l’adoption de l’IA s’accélère, son impact environnemental devient une contrainte d’ingénierie majeure. Une seule interaction avec un LLM peut consommer jusqu’à dix fois plus d’énergie qu’une requête de recherche traditionnelle, tandis que le cycle de vie du matériel génère des niveaux record de déchets électroniques. Dans cette session, nous évaluerons le « véritable coût d’un token », en dépassant le battage médiatique pour analyser les données concrètes liées à l’entraînement et à l’inférence des modèles d’IA. Nous passerons ensuite des métriques aux solutions, en montrant que l’« IA verte » est bien souvent synonyme d’IA efficace et économiquement pertinente. Vous repartirez avec une boîte à outils pratique pour mieux gérer notre dépendance à ces modèles : apprendre à dimensionner correctement votre architecture, optimiser vos pipelines et mettre en œuvre des approches sensibles au carbone afin de construire une intelligence qui ne coûte pas la planète.

Vous utilisez uv, le super gestionnaire de packages Python ? Vous avez bien raison. Si vous faites des builds fréquents, vous voudrez éviter de télécharger les dépendances à chaque fois. Et au moment de construire une image docker de votre application, il faudra minimiser son contenu pour réduire la surface d'attaque et accélérer son transfert. Ça tombe bien, Astral a tout prévu pour ça au moyen d'options et de variables d'environnement dédiées ! Je vous ai déjà dit que c'était un super outil ?

> Le hasard fait bien les choses. Si on applique cette idée aux tests unitaires ou aux tests d'intégration, on peut rendre nos tests beaucoup plus imprévisibles et du coup trouver des problèmes que notre esprit n'aurait jamais osé imaginer ! Par exemple, récemment, j'ai découvert dans une bibliothèque de gestion de configuration, [un bug](https://github.com/gestalt-config/gestalt/issues/242) qui se produit lorsque la `Locale` est configuré en `AZ`. 🤦🏼‍♂️ Un autre exemple encore plus simple : ```java int input = generateInteger(Integer.MIN_VALUE, Integer.MAX_VALUE); int output = Math.abs(input); ``` Peut générer `-2147483648`... Ce qui est assez inattendu pour une valeur absolue ! 😉 Les tests aléatoires peuvent découvrir ces cas tordus... C'est ce que l'équipe elasticsearch a mis en place depuis plusieurs années à l'aide du framework [RandomizedTesting](https://labs.carrotsearch.com/randomizedtesting.html) pour tester tout le code Java. Ajoutez à ça de vrais tests d'intégration à l'aide de [TestContainers](https://java.testcontainers.org/modules/elasticsearch/) et vous aurez une approche complète pour des tests qui échouent régulièrement ! Après cette conférence, vous ne verrez plus jamais la fonction `random()` comme avant et découvrirez comment la (mal)chance peut vous aider ! 🍀

Les UUID sont partout, utilisés souvent machinalement comme identifiant. Revenons un instant sur leurs origines et ce qu'ils garantissent vraiment — l'unicité globale sans coordination, pratique, mais pas toujours le meilleur choix comme clé d'unicité. On explore ensuite quand les employer (ou pas) dans des bases de données et des systèmes distribués, avant de comparer les différents générateurs créant des arbitrages concret entre confidentialité et performance.

Dans nos métiers du numérique, où la technique évolue plus vite que nos plannings, le temps est souvent perçu comme un luxe inaccessible. Pourtant, nourrir notre curiosité, apprendre, expérimenter ou encore partager fait partie intégrante de notre développement professionnel. Et si, plutôt que de courir après ce temps, on apprenait à "tricher" un peu pour mieux l’utiliser ? Je vous propose une approche concrète, pragmatique et libératrice : consacrer 30 minutes par jour à soi. À la veille technologique, aux sides projects qui ne seront jamais terminés, à l’écriture d’articles ou de conférences, à l’amélioration de son espace de travail ou à la consolidation de son réseau professionnel. 30 minutes sans pression, mais avec rigueur. Un espace quotidien pour explorer, tester, échouer parfois, mais surtout progresser. Cette conférence partage un retour d’expérience, des conseils applicables dès demain, et une vision décomplexée de la montée en compétences continue. Objectif : entretenir la flamme de notre passion pour ce métier autant humain que technique.

"Trop de slop." "Usine à dette technique." "Ça marche pas sur les gros repos." On a tous vécu ça : on lance un agent IA sur un vrai projet, et le résultat est générique, inadapté, voire cassé. La réaction classique, c'est d'attendre des modèles plus intelligents. Mais le problème n'est pas l'intelligence du modèle, c'est ce qu'on lui donne à manger. Dans ce talk, je vous montre pourquoi le context engineering, la discipline de gérer ce qui entre dans la fenêtre de contexte d'un LLM, est la compétence la plus importante pour tirer parti des outils IA en développement. On verra : - Pourquoi les LLMs sont des fonctions stateless, et ce que ça implique concrètement - Ce qui bouffe le contexte avant même que l'agent commence à coder - La technique de compaction intentionnelle pour garder le savoir sans le bruit - Comment les micro-agents permettent de contrôler la qualité en isolant l'exploration - Le workflow Research → Plan → Implement qui garde chaque session dans la "smart zone" - Comment structurer un CLAUDE.md (ou équivalent) pour que l'agent démarre informé Ce talk s'appuie sur le travail de Dex Horthy (HumanLayer, 12-Factor Agents) et sur des exemples concrets tirés de mes propres expérience avec mon équipe. Pas de théorie abstraite : des techniques applicables dès lundi.

Les logs, l'observabilité, la viz', sur le papier ça se fait bien. Mais dans la réalité, c'est une autre paire de manches. De la collecte à l’indexation en passant par le nettoyage, nous explorerons les solutions mise en oeuvre dans le cadre d’une forge logicielle. Nous verrons comment Grafana nous à permis le parsing et l’exploitation des données. Et aussi comment ELK nous a aidé à assainir nos données pour éviter d’acheter des disques tous les 6 mois ! Sans oublier la mise en place de la stratégie d’alerting et d’uniformisation sur un parc de 350+ VMs. Avec ce rex, tu repartiras avec des patterns immédiats à appliquer (collecte, nettoyage, indexation), quelques pièges à éviter et des règles pragmatiques d’alerting pour faire de l’observabilité une habitude opérationnelle.

Tout motard redoute ce moment : arriver à l'emplacement de sa moto et ne trouver que… le vide. Cette mésaventure m'est arrivée non pas une mais deux fois ! Et chaque fois, la fin a été différente du scénario habituel. Pas de déclaration de vol sans espoir (ou presque), mais une chasse… à la machine. La dernière fois ? C'était pendant le DevFest 2024. Entre deux conférences, je me suis retrouvé embarqué avec la BAC de nuit pour récupérer mon bien. Mais comment "traque"-t-on réellement un véhicule en milieu urbain ? Dans ce talk, je vous propose un retour d'expérience sans filtre sur l'efficacité réelle des traceurs GPS. Nous ouvrirons le capot de ces petites boîtes noires pour comprendre la technologie qui les anime. Du hardware à l'application mobile, en passant par les réseaux cellulaires, découvrez comment la tech peut transformer une victime en enquêteur... et comment j'ai fini par voler ma moto aux voleurs !

Depuis des années, nous utilisons plusieurs environnements intermédiaires avant LA livraison en production. Mais en 2026, est-ce vraiment nécessaire ? Sommes-nous certains qu’un déploiement en recette nous garantit une livraison réussie en production ? Et si nous tentions le coup ? Et si nous bazardions tout pour ne conserver que la production ? Durant cette présentation, nous explorerons comment allier craft et ingénierie logicielle pour concevoir des architectures prêtes pour la production. Nous aborderons les meilleures pratiques, les outils et les stratégies essentiels pour minimiser les risques et maximiser l'efficacité.

Rust est connu pour être un langage très performant, très "bas niveau", très ardu à prendre en main, etc. Et si je vous disais que si tout ça est probablement vrai, ce n'est pas du tout le plus important ? Eh oui, Rust est selon moi le langage idéal pour développer des applications, parfois de très haut niveau, car il nous donne les moyens de modéliser des domaines métiers avec précision et simplicité. Parcourons-donc ensemble ce qui fait la richesse "applicative" de Rust ! 🦀 - Un système de types ultra-expressif, appliqué à des domaines métiers complexes. Voyons comment les Structs, le Pattern Matching et les Traits de Rust le rendent totalement compatible avec des approches haut-niveau comme l'Architecture Hexagonale ou le Domain Driven Design - Un écosystème de librairies applicatives solide, complet, et agréablement documenté. Venez avec moi parcourir la somptueuse documentation de librairies comme serde, actix-web, ou wiremocks, qui vont vous redonner envie d'écrire de la documentation technique, pour les devs et par les devs - Une manière de tester les applications qui n'a pas son pareil, et qui complémente superbement le langage afin de vous permettre de développer vos applications avec le meilleur filet de sécurité possible. Tests d'Intégrations, Mocks, Rust a tout du langage de haut-niveau pour délivrer le maximum de valeur. C'est un tour d'horizon qui changera, j'en suis sûr, votre perception de ce langage qui paraît tellement "orienté performance et optimisation mémoire" qu'on en oublie que c'est avant tout un langage très expressif. Et même si vous n'écrirez jamais une ligne de Rust, cette conférence devrait vous donner pas mal de tuyaux sur l'écriture moderne d'applications et ce qu'on est en droit d'attendre de nos écosystèmes de développement 😉

Quand une startup SaaS grossit vite, son infrastructure finit souvent par raconter son histoire : quelques VMs au début, puis du Kubernetes, puis des services auto-gérés un peu partout… jusqu’au moment où l’équipe passe plus de temps à maintenir la plateforme qu’à construire le produit. Chez PayFit, nous nous sommes retrouvés exactement dans cette situation. Notre plateforme reposait intégralement sur Kubernetes, y compris les aspects bases de données, middleware... avec évidemment beaucoup de "fait maison" dans le lot. Ça fonctionnait, mais de manière loin d'être idéale : soucis de sécurité, surcharge opérationnelle, manque d'autonomie des équipes produits, incidents à répétition... Nous avons donc entamé une transition progressive vers davantage de services managés et de serverless, aujourd'hui achevée avec succès. Dans ce talk, je vous propose un retour d’expérience concret sur cette évolution : - Pourquoi nous avons décidé de réduire notre part d’infrastructure auto-gérée - Comment nous avons migré progressivement sans tout réécrire - Ce que les services managés et le serverless changent vraiment au quotidien - Les gains… mais aussi les surprises et les compromis L’objectif n’est pas de vendre une architecture miracle, mais de partager ce que l’on apprend quand on essaie de sortir du “tout Kubernetes” pour aller vers plus de services managés, et comment cela peut aider une équipe plateforme à se concentrer davantage sur le produit que sur l’infrastructure.

À l’ère de la multiplicité des cadres réglementaires, du RGPD aux lois américaines en passant par DORA et NIS2, le choix d’un hébergeur cloud n’est plus une simple question technique, mais un enjeu stratégique de souveraineté et de conformité. Comment concilier innovation, sécurité, disponibilité et respect des textes dans un paysage juridique en constante évolution ? Cette conférence propose un guide opérationnel pour naviguer entre besoins techniques, exigences des régulateurs (CNIL, EDPB, etc.) et réalités du marché.

🛸 Après le crash de notre vaisseau sur une planète inconnu, Astro part secourir ses companions en danger dans le monde du GitOps! En repartant de la base du GitOps, de son idée fondatrice à son utilisation quotidienne, nous découvrirons les bonnes et mauvaise pratiques qui façonnent cet univers. Au travers d'exemples dans différents domaines (Kubernetes, infrastructure, secret management), nous verrons concrètement comment appliquer cette philosophie. Embarquons pour ce voyage interstellaire, accompagné de nos bots favoris 🤖, dans le monde du GitOps !

Quelques lignes de commandes suffisent aujourd'hui pour créer son cluster Kubernetes dans le cloud. On peut alors y déployer sa panoplie de Pods, Deployments, Services, etc. avec peu d'efforts (quoique beaucoup de YAML). Mais qu'en est-il des accès réseaux ? Comment restreindre les accès en entrée et en sortie de son cluster ? Comment contrôler les requêtes HTTP entre microservices ? Et comment sécuriser les données qui transitent entre ces microservices ? Dans ce talk, nous répondrons à ces questions avec Cilium, un plugin réseau pour Kubernetes. Cilium permet d'acheminer les paquets entre conteneurs, d'appliquer les politiques de sécurité réseau, de chiffrer les données en transit et bien plus. Il offre aussi divers outils visuels pour créer ses politiques de sécurité et comprendre ce qui se passe côté réseau [1, 2]. Au programme : - Une courte introduction aux réseaux de conteneurs à la Kubernetes. - Comment Cilium utilise eBPF pour faire la différence. - Sécuriser les accès IP, TCP, HTTP et autres en suivant les bonnes pratiques. - Chiffrer ses données applicatives sans sidecar ni prise de tête. [1] https://docs.cilium.io/en/latest/gettingstarted/hubble/ [2] https://editor.networkpolicy.io

Vos utilisateurs en ont marre d’attendre... Nos applications s’essoufflent sous le poids du polling et des loaders plus ou moins maîtrisés . Et si les Server-Sent Events (SSE) étaient la solution simple et légère que vous cherchez ? Les SSE permettent de basculer d’un modèle où le navigateur demande à un système ou le serveur murmure à son oreille. Ce changement de paradigme a de nombreux impacts sur l'architecture, le code, et même sur la conception de l’expérience utilisateur. Charline et Nicolas, Lead Tech Frontend et Backend, vous partagent leur retour d’expérience sur cette mise en place dans des cas d'usages réels. Dans des jeux multi-joueurs, ou dans des applications de gestion traditionnelles, ils vous montreront les cas d'usages concret, les gains et les pièges à éviter. Venez découvrir comment les SSE influencent votre code, de l'intégration aux frameworks Frontend, jusqu'à la séparation lecture/écriture côté backend. Vous verrez aussi comment cette approche fait évoluer la conception des échanges Front/Back et l'expérience utilisateur, tout en offrant de nouvelles possibilités...

L’équipe projet ayant réalisé le portail de l’audiodescription du Ministère de la Culture vient partager ses apprentissages concrets en matière d’accessibilité. Comment mener des tests utilisateurs auprès d’un public déficient visuel ? Quelles bonnes pratiques d’UX/UI mettre en place pour proposer une expérience accessible au delà du RGAA ? Quels défis en développement cela représente-t-il ? Présentation des ratés et réussites de chaque étape du projet, de façon illustrée par un cas réel !

On a toutes et tous été confronté•es, un jour, à devoir (ré)installer tout notre environnement de développement lors d'un changement de machine. Que ce soit par choix ou juste en mode "on-boarding" lors d'un changement de société, de mission, ... On a aussi, parfois, passé de longues heures pour comprendre quels outils installer pour proposer une PR ou MR dans un projet Open Source. Dans encore beaucoup d'autres cas, nous sommes vite confrontés à l'enfer de la configuration des outils et autres frameworks pour faire ce que l'on aime : développer. Et je ne vous parle pas des montées de versions et inter-dépendances 😅... Heureusement, il existe une solution à tous ces problèmes : les dev containers. Lors de ce tools-in-action, je vous propose de partir à leur découverte. La seule chose que je m'autorise à installer sur ma machine : Docker ! Le reste sera de la gestion de configuration pour que les outils, les frameworks et la gestion des versions et dépendances soit un non-évènement dans votre process de développement. Vous repartirez en sachant utiliser les dev containers mais aussi en sachant construire as-code votre stack de développement.

Vos collègues mettent longtemps à relire votre code ? Ou pire, vous avez l'impression qu'ils le valident sans l'avoir réellement regardé ? Sans doute que vos pull requests (PRs) sont trop conséquentes, et donc leur relecture difficile à caser dans un agenda chargé… Essayez de passer aux « stacked pull requests », qui permettent de faire relire votre travail progressivement, de façon incrémentale ! Je ne vous expliquerai pas comment découper vos commits – sujet trop vaste pour cette courte présentation – mais comment utiliser Git pour travailler sur plusieurs branches simultanément, chacune étant associé à une pull request différente. Avec ces quelques commandes simples, vous aurez le plaisir de revoir des commentaires et suggestions sur vos PRs !

Il y a un an, ma veille technologique ressemblait à ça : → Des dizaines d'onglets ouverts "à lire plus tard" → Des favoris qui prenaient la poussière → Une sensation constante de passer à côté de l'essentiel Aujourd'hui, j'ai un système qui transforme cette veille passive en apprentissage actif. Mon workflow complet : 1- Capture → Readwise (articles, vidéos, posts) 2- Podcasts → Snipd (avec transcription IA) 3- Livres → Kindle (highlighting automatique) 4- Centralisation → Obsidian (hub central) 5- Output → Articles de blog, talks, tutoriels Dans ce talk, je vous partage les différents outils que j’utilise au quotidien ce qui me permet d'écrire des articles de blogs ou des présentations.

Alors qu'ils ont radicalement bouleversé notre façon de concevoir le déploiements des applications, les containers sont aujourd'hui considérés comme un "commodité", un détail d'implémentation. Le runtime qui leur permet de tourner n'intéresse que les experts lors de débats enflammés autour d'une pinte. Pourtant les choses continuent d'évoluer. Si on pourrait croire que l'architecture de Docker n'a pas changé depuis 10 ans, en réalité de nombreux composants évoluent pour assurer performance, flexibilité et sécurité renforcée. Par ailleurs, de nouveaux besoins apparaissent: avec la déferlante des agents IA, être en mesure de fournir un environment sans restriction tout en préservant son système hôte est devenu une nécessité. Je vais vous présenter dans les grandes lignes les nouveautés de containerd 2.2 avant de m'attarder sur le tout nouveau projet NerdBox qui permet de gérer des sandbox à base de microVM avec la simplicité des containers ... et -- cerise sur le gâteau -- sans avoir besoin d'être root 🤩