Planning BreizhC@mp 26

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.

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.

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.

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 !