Nos actualités
Sunny Tech 2025 : ce qu’il ne fallait pas louper !
La 6ème édition de Sunny Tech a tenu sa promesse : deux jours de veille technologique de qualité, à deux pas de nos bureaux Montpelliérains. Une dizaine de collaborateurs de Bpifrance ont participé à cette conférence tech où sont intervenus des speakers de qualité.
Retour sur Sunny Tech 2025 : deux jours d’inspiration et d’innovation à Montpellier
L’édition 2025 s’est ouverte sur une keynote inspirante de Jean-Baptiste Kempf, créateur de VLC, qui nous a relaté sa success story sous l’angle de la souveraineté numérique.
Lien vers le replay : https://www.youtube.com/watch?v=PpfUn2m4OGA
Testy Tech
En tant que Tech Lead du Shared Service Tests, notre reporter Christophe Leroux a participé à Sunny Tech 2025 avec une mission précise : identifier des retours d’expérience et des bonnes pratiques pour perfectionner nos méthodes et pratiques courantes. Les sessions consacrées aux tests ont capté toute son attention, offrant à la fois des remises en question constructives et des validations rassurantes de nos orientations actuelles.
Il nous raconte tout !
La conférence « Tester, c’est tricher », animée par Antoine Caron et Jules Poissonnet, a exploré les fondamentaux du test logiciel. Elle a remis en cause certaines doctrines établies, comme la pyramide des tests ou l'importance du coverage, pour recentrer la discussion sur la réelle valeur des tests. Cette approche pragmatique incite à repenser notre stratégie en évitant une vision trop quantitative ou trop axée sur les outils.
Enseignements :
- ⏱️ Temps d'exécution des tests : Il est crucial de maîtriser le temps d'exécution des tests. Par exemple, l’utilisation des mocks dans les tests d'interface, comme avec Playwright mocking, permet un meilleur contrôle.
- 📚 BDD avec Cucumber : Le Behavior-Driven Development (BDD) améliore la lisibilité et la maintenabilité des tests. Chez bpi, l'utilisation du langage Gherkin est déjà une pratique courante.
- 🛠️ Qualité de la “Testbase” : Il est important de soigner votre testbase aussi rigoureusement que votre codebase. Par exemple, en JavaScript, eslint-plugin-vitest peut aider à traquer les tests sans expect.
- 🔍 Tests de mutation : Les tests de mutation complètent la métrique de couverture de code. Bien qu’ils puissent être coûteux, ils garantissent la validité des tests.
- 💰 Économie de CI : Il est possible d’économiser du temps sur la CI en arrêtant les tests dès le premier échec détecté, comme avec l'option --bail en JavaScript.
- 📋 Stratégie de test formalisée : La stratégie de test doit être formalisée en se concentrant sur les axes de stabilité, conformité, intégrité et reproductibilité.
Lien vers le replay : https://youtu.be/cxUvNNSKYK0?si=4GdcUCAsa2p6Cl9D
L’atelier « Tester dans l’Hexagone » m'a offert une opportunité de mise en pratique des tests dans le cadre du DDD. En mob programming, nous avons exploré le TDD, le DDD et l’architecture hexagonale, avec un accent particulier sur la testabilité du design et l’utilisation des TestContainers. Cette immersion pratique a été idéale pour confronter nos convictions à la réalité du code et réaffirmer l'importance de la conception pour offrir un bon niveau de testabilité.
Flaggy Tech
🎯 Fun with Feature Flags : maîtriser l’activation dynamique des fonctionnalités
C'est Damien Sans qui a ecouté Léonor et Mathieu de Sopra Steria, livrer une présentation aussi technique que pragmatique sur les Feature Flags, ces leviers puissants pour piloter les fonctionnalités en production. Voici les enseignements clés à retenir.
🚀 Qu’est-ce qu’un Feature Flag ?
Un Feature Flag ) permet d’activer ou désactiver dynamiquement une fonctionnalité dans une application, sans redéploiement. Contrairement au Canary Deployment, il n’y a qu’une seule version de l’application, mais des comportements différents selon les utilisateurs ou les contextes.
🧩 Trois types de flags à connaître
- Release Flags : pour activer une fonctionnalité une fois prête, souvent en trunk-based development.
- Experimentation Flags : pour tester une feature sur un segment d’utilisateurs (ex. : bêta-testeurs, régions).
- Operational Flags : pour gérer des comportements techniques comme l’affichage d’une page de maintenance.
🛠️ Les outils testés : Unleash et Flipit
- Unleash : robuste, mature, avec des SDK pour tous les langages. Intégré à GitLab, il facilite la gestion des flags via une interface ou une API. Il permet de définir des environnements (dev, test, prod) et des stratégies de déploiement.
- Flipit : plus léger, open source, avec une API GRPC. Il permet de créer plusieurs applications gratuitement, mais reste jeune et moins complet.
🔄 Open Feature : la standardisation en marche
Open Feature est une spécification en incubation chez la CNCF. Elle vise à normaliser l’usage des Feature Flags et à faciliter le changement de provider sans refactorisation. Elle introduit :
- Le provider (moteur de Feature Flag)
- Le contexte d’évaluation (ex. : user ID, IP)
- Les hooks (actions avant/après l’évaluation)
🎯 Fonctionnalités avancées
- Segmentation : ciblage d’utilisateurs selon des critères (navigateur, ID, rôle…).
- Variants : au-delà du simple true/false, on peut renvoyer des valeurs différentes selon le segment (utile pour l’A/B testing).
- Observabilité : intégration avec OpenTelemetry pour suivre les performances et comportements liés aux flags.
⚠️ Les pièges à éviter
- Accumulation de flags : trop de flags non nettoyés complexifient la maintenance et les tests.
- Imbrication excessive : des dépendances entre flags peuvent créer des matrices de configuration ingérables.
- Absence de monitoring : sans observabilité, les tests en production perdent leur valeur.
- Interfaces trop techniques : les utilisateurs métiers peuvent être perdus sans UI adaptée. La gestion des accès (RBAC) est souvent réservée aux versions payantes.
✅ Bonnes pratiques
- Maintenance régulière : suppression des flags obsolètes à chaque sprint.
- Tests unitaires et d’intégration : utiliser des mock providers pour simuler les comportements.
- Séparation des environnements : éviter de mélanger test et prod dans les mêmes configurations.
- Documentation et gouvernance : suivre les flags avec des outils adaptés pour éviter les fichiers Excel bricolés.
- Mesurer, mesurer, mesurer : les Feature Flags doivent s’inscrire dans une logique métier, avec des métriques claires (temps de parcours, taux de clics, etc.).
🧠 En conclusion
Les Feature Flags ne sont pas qu’un gadget pour développeurs. Bien utilisés, ils permettent aux équipes métiers de piloter les fonctionnalités, d’expérimenter en conditions réelles, et d’optimiser l’expérience utilisateur. Mais cela nécessite rigueur, outils adaptés, et une vraie stratégie d’observabilité.
SecuTech
🛡 Anatomie d'une faille
Une faille dans la supply chain, restée invisible pendant ~3 ans, sujet qui a passionné David Donès qui nous relate l'histoire ici !
Tout commence lorsqu’un développeur PostgreSQL remarque un délai de 300 ms sur ses connexions SSH, sur l’ensemble de son parc de VM de test. Intrigué, il décide d’enquêter.
Le mainteneur d’OpenSSH, seul valideur et débordé (volontairement) par les commits à valider, finit par confier les clés du projet à un contributeur très actif depuis 2 ans : JiaT75.
🔍 Bilan final : une faille dans OpenSSH
- Le daemon Linux charge une bibliothèque système qui appelle xz-utils.
- La charge malveillante est invisible sur les postes de développement, uniquement présente côté serveur.
- Le certificat de l’attaquant est installé dans OpenSSH, permettant un accès toujours autorisé.
- Par chance, la faille est découverte juste avant les releases semestrielles des distributions Linux.
📚 Une histoire incroyable, documentée ici :
👉 Attaque de XZ Utils par porte dérobée – Wikipédia [https://fr.wikipedia.org/wiki/Attaque_de_XZ_Utils_par_porte_d%C3%A9rob%C3%A9e]
Conclusion
Sunny Tech 2025 a été une nouvelle fois l’occasion de se former, de partager et de repenser nos pratiques. Les sessions sur les tests logiciels ont particulièrement retenu notre attention, en rappelant que la qualité ne s’improvise pas, mais se construit avec pragmatisme et innovation.
Un grand merci aux organisateurs et aux intervenants pour ces deux jours riches en apprentissages. Merci également à Bpifrance de nous offrir ce temps utile pour travailler la veille techno.
Technologies associées


