Planning BreizhC@mp 26

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”

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.

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 ?