Planning BreizhC@mp 26

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é

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.

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.

Depuis une dizaine d’années, les animations web ont profondément transformé notre manière d’interagir avec les interfaces numériques. Qu’il s’agisse de transitions fluides, de micro-interactions ou d’effets de défilement, elles sont devenues un langage visuel à part entière. Ces animations enrichissent l’expérience utilisateur, attirent l’attention, facilitent la compréhension… et parfois, en font trop. Mais derrière cette légèreté apparente se cachent des enjeux plus profonds : performance, accessibilité, sobriété numérique. Une animation mal pensée peut ralentir un site, exclure des utilisateurs sensibles aux mouvements, ou simplement détourner l’attention du message. À l’inverse, une animation bien conçue peut guider, apaiser, clarifier — sans surcharger. Aujourd’hui, dans ce talk, je vous propose un voyage à travers les bonnes pratiques, les outils CSS modernes, et les choix de design qui permettent de faire bouger nos interfaces… sans les alourdir.

Vous utilisez Diffie-Hellman des dizaines de fois par jour sans le savoir : à chaque connexion HTTPS, à chaque message chiffré sur Signal. C'est cet algorithme qui permet à deux parties d'établir un secret commun sur un canal non sécurisé — sans jamais se l'échanger. Après avoir implémenté une version basique sur un projet, j'ai eu envie de partager ce que j'y ai compris. On explorera ensemble cette implémentation : comment ça marche, pourquoi ça tient, et quelles améliorations les implémentations plus complexes y apportent. Le thème de la session est algorithmique : on laisse les maths théoriques et la cybersécurité de côté.