Planning BreizhC@mp 26

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.

"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/

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 😉

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.