Programme
Et si l'on scénarisait nos fixtures ?
Les fixtures sont souvent utilisées pour générer des données, servant ainsi de fondation pour les tests fonctionnels et le développement.
Il est possible de générer les objets un à un. Cependant, qu'en est-il lorsqu'on a un système complexe utilisant une machine à état, de nombreux fichiers et de l'envoi de mail ?
Pourquoi ne pas exploiter ce mécanisme pour initier nos objets et les faire évoluer au sein de l'application ?
Cette présentation proposera un retour d'expérience sur un parcours complet, allant de l'outillage de génération de données à l'écriture de scénarios applicatifs, sans négliger aucune étape pour maîtriser vos données.
La lucidité comme architecture
En 2014, nous réalisons un projet de billetterie en ligne sous Symfony 2. L’objectif est simple : unifier plusieurs flux France Billet pour un client local. Puis le projet grandit vite. En quelques années, il devient la base technique d’une branche entière de France Billet, équipe plus de 150 sites, et gère un gros volume de transactions mensuelles.
Sur le papier, tout fonctionne. En pratique, les premières fissures apparaissent : lenteurs, erreurs aléatoires, difficultés de déploiement, incompréhensions avec les clients et le donneur d’ordre. Et surtout, une dette technique qui grossit silencieusement.
Pourquoi ? Parce que nous avons voulu “faire bien” avant de “faire juste”. Nous avons mis en place une architecture en microservices là où un monolithe aurait été plus sain. Nous avons adopté le DDD dans un contexte où la clarté et la simplicité auraient été préférables. Nous avons cherché à spécialiser nos couches techniques… sans jamais remettre en question nos fondations :
- Avons-nous une QA fiable et automatisée ?
- Avons-nous un monitoring en temps réel ?
- Avons-nous une infrastructure résiliente ?
- Nous voulons un code « élégant », mais est-il simple et efficace ?
Au fil des années, nous avons traversé six versions majeures de Symfony, migré entre plusieurs solutions — Sonata eCommerce, puis Sylius, puis API Platform — en poursuivant sans relâche “la bonne architecture”, parfois au détriment du bon sens.
Ce talk raconte cette traversée : celle d’un projet qui a grandi plus vite que son équipe, et d’une équipe qui a appris à se regarder en face. Comment nous avons su demander de l’aide, accueillir un audit, nous remettre en cause et relancer un plan d’action concret pour reprendre le contrôle — sans tout réécrire.
C’est aussi une réflexion plus intime sur la lucidité : sur le sentiment désagréable qui nous saisit quand on réalise les erreurs accumulées, et sur la nécessité de l’affronter. Car tant qu’on ne traverse pas cette étape, il est impossible de voir clairement et d’avancer efficacement.
Une histoire honnête sur le décalage entre l’intention et la réalité, entre la théorie et le terrain. Et surtout, une réflexion sur ce qui fait vraiment la solidité d’un projet Symfony à long terme : pas la sophistication, mais la lucidité.
Evolutionary Architecture : Comment éviter la prochaine "Grande Réécriture"
"On va tout réécrire, ça prendra 6 mois." Un an plus tard, le projet est abandonné, l'équipe est épuisée, et le code legacy a continué d'évoluer. Cette histoire vous semble familière ? Il existe une meilleure approche.
L'Evolutionary Architecture est une discipline qui permet de faire évoluer continuellement votre système sans jamais avoir besoin de tout jeter.
L'architecture n'est jamais finie. Les besoins changent, les technologies évoluent, l'équipe grandit. Comment construire une architecture qui s'adapte sans nécessiter de grandes réécritures ?
Ce talk explore les Fitness Functions, les Architecture Decision Records (ADR), les tests architecturaux, et les stratégies de migration progressive pour faire évoluer votre code en continu.
Ce que nous aborderons :
- Implémenter des Fitness Functions pour protéger votre architecture
- Écrire des ADRs efficaces qui servent vraiment
- Migrer progressivement sans "Big Bang Rewrite"
- Mesurer la qualité architecturale objectivement
- Convaincre le management d'investir dans l'évolution continue
- Éviter les erreurs fatales de refactoring
À la découverte d'Accelerate 2026
Vos déploiements s’éternisent, vos releases se bloquent sur des validations sans fin ? Il est temps de casser tout ce qui vous ralentit. Grâce aux enseignements d’Accelerate, découvrez comment mesurer et améliorer concrètement la performance de vos équipes PHP. À travers les métriques DORA, des pratiques CI/CD modernes et une culture d’expérimentation continue, apprenez à transformer vos pipelines en leviers de delivery rapide, fiable et durable. Libérez votre flow, accélérez votre impact. En tant qu'expert et conférencier reconnu sur le sujet, je vous partagerai également des retours d'expérience sur le sujet.
J'ai testé pour vous : le composant Cache de Symfony couplé à Redis
Lors d'une mission récente, j'ai dû mettre en place un serveur Redis de cache. L'objectif principal de ce cache était de stocker des données afin de ne pas avoir à aller les chercher en base et ainsi éviter de trop la solliciter, tout en profitant de temps de réponses améliorés. Rien de nouveau concernant l'utilisation d'un cache donc. Cependant j'ai eu l'occasion de faire quelques découvertes notamment concernant le composant Cache de Symfony, les différentes manières de l'utiliser, ainsi que ses limites.
Je souhaite donc proposer un talk qui permet de démystifier ce composant, de montrer ce qu'il permet, les fonctionnalités qu'il apporte, mais aussi ce qu'il ne permet pas (et qu'il faut donc faire autrement). Pools, tags, invalidation, embarquons pour un voyage dans le cache avec Symfony et Redis.
Migrations : C'est une question d'hygiène !
Les migrations de nos outils de développement et d’infrastructure sont la hantise de nos business et de nos backlogs. Elles sont synonymes de tunnels de développement à rallonge, de risques incontrôlés et de "feature freeze" qui frustrent le business. On les repousse, on les redoute, jusqu'au jour où elles deviennent une urgence absolue...
Et si l'erreur n'était pas la migration elle-même, mais la façon dont nous l'abordons ? Dans ce talk, nous verrons comment transformer ces montagnes en une série de toutes petites collines. L'idée ? Ne pas attendre la date butoir et la pression de nos managers.
Dans ce talk, nous explorerons comment instaurer une "hygiène de vie" technique continue : des actions ciblées appliquées au quotidien, qui prépare le terrain sans paralyser la vélocité et les nouvelles features. Après tout, c’est comme pour le ménage, un peu tous les jours, c’est beaucoup plus agréable et simple à entretenir !
Le code, c’est la partie facile
On forme les devs à écrire du code propre, à maîtriser les frameworks et à résoudre des bugs complexes. Mais très peu apprennent à travailler avec des humains : comprendre un client stressé, collaborer avec un chef de projet, gérer les désaccords ou adapter sa communication.
De développeur à CTO, j’ai découvert que le code n’est que la partie visible du métier. Ce qui fait vraiment la différence, ce sont les compétences invisibles : comprendre les dynamiques d’équipe, les profils de personnalité, et savoir situer son rôle dans la chaîne de décision.
Dans ce talk, nous explorerons :
- la hiérarchie des erreurs (pourquoi toutes les erreurs ne se valent pas selon le niveau de responsabilité) ;
- le modèle DISC, un outil simple pour décoder nos comportements et ceux des autres ;
- et comment ces notions peuvent transformer la communication au sein d’une équipe technique.
Ce talk s’adresse à tous les devs qui veulent mieux comprendre leur environnement — pour moins subir et mieux collaborer dans un monde où le code n’est finalement… que la partie facile.
Retour vers le monolithe
Quand je suis arrivé chez Click&Boat, on avait du legacy et une grande ambition : migrer vers une stack technique plus moderne. Au programme : • des applications natives, • un front Angular, • des microservices — plein de microservices, • des backend Symfony
Trois ans plus tard, on peut dire qu’on a bien avancé… mais pas tout à fait dans la direction prévue. On a aujourd'hui : • pas d'applications natives (ou presque) • zéro microservice (on les a tous tués), • du Twig avant Angular, • et un grand monolithe Symfony “by the book”.
Dans cette conférence, je raconterai pourquoi on a décidé de faire ce virage à 180°, à contre-courant de tout ce qu’on lit sur le web, pourquoi c’était le bon choix pour nous et aussi comment faire accepter ces changements. À la clé : plus de productivité et de meilleures perfs en prod.
Faire battre les cœurs avec le mécénat de compétences
L'histoire commence par un spot radio de 60 secondes : un matin de septembre 2023, Arnaud Labenne, CEO de la PME bordelaise Dotsafe, entend parler pour la première fois de Sauvlife. Après deux ans d'expérience, il partage avec vous son retour.
Les maux des mots
À l’heure où la santé mentale entame une reconnaissance dans le domaine de la maladie, où les publicités sur le sujet prolifèrent sur nos écrans, il semble juste de préciser les nombreux freins intrinsèques à chacun•e pour appréhender sa propre santé mentale. Après 35 ans de travail au sein d’un établissement médico-social dans lequel j’étais extrêmement investie, mon équilibre salarial s’est effondré, au moment précis d’un changement de direction. Accepter de reconnaitre les signaux faibles n’est pas automatique, cependant dans le cas contraire il peut mener au burnout. Toute personne se convainc d’en posséder un certain savoir, que se passe-t-il derrière ces portes et comment les identifier ? Voyons ensemble comment se créer ses propres clés pour améliorer la qualité de vie et les conditions de travail (QVCT) et s’approprier, chacun•e, la part qui nous incombe.
