Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

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é.

Bordeaux Ynov Campus 22/05/2026 10:05-10:45

Suite à cette expérience, que diriez-vous à vos vous du passé ?

Pour éviter les mauvais choix, je dirais à mon moi du début : si tu as un problème, il y a de fortes chances que ce ne soit pas un problème technique, mais un problème de méthodologie ou un problème organisationnel.
Pose-toi des questions simples :

• As-tu un système de monitoring efficace ? Es-tu capable de voir simplement et rapidement les erreurs sur ta solution ?
• As​-tu un système de déploiement efficace ? Es-tu agile ? Peux-tu déployer rapidement ?
• As-tu une QA ? Si oui, as-tu une QA qui te sert à quelque chose ? 😁
• Pratiques-tu l’intégration continue ? Utilises-tu des features flags ? Combien de fois déploies tu par semaine ? Même, par jour ?

Puis, à mon moi qui a déjà effectué beaucoup de mauvais choix, je dirais : tu connais certainement déjà la solution, tu sais quoi faire. Fais-toi confiance. Ton problème n’est pas de ne pas savoir quoi faire, mais de ne pas savoir comment le faire.

Qu’est-ce qui vous a motivé à partager cette expérience lors de votre première conférence ? Y a-t-il eu un événement ou une rencontre qui a influencé cette décision ?

Déjà, c’est un cas d’école. Après être passé par ce genre de situation, on se dit que c’est bateau, mais on retrouve ce genre de situation bien plus souvent qu’on ne le pense. JoliCode ne dira pas le contraire, ils le voient au quotidien.
Dans le cadre de l’intervention de Bastien et de JoliCode, nous avons mis toute la méthodologie et l’organisation en place pour améliorer la situation, et nous avons épuré la dette technique. À partir de là, en discutant avec lui, nous avons réalisé qu’au delà de l’aspect dette technique au sens large, il y a une dimension intime intéressante à raconter.
Le genre de situation dans laquelle nous nous sommes retrouvés est trés inconfortable d’un point de vue émotionnel. Et ce sentiment peut paralyser, fausser l’analyse et le jugement, puis entrainer des mauvaises décisions qui empirent encore la situation.

Comment savoir si l’on est lucide ?

Le triptyque monitoring, CI/CD et QA est déjà un excellent test.

• Une QA utile permet de savoir si le système fonctionne avant le déploiement.
• Le monitoring permet de savoir ce qu’il se passe après.
• Le CI/CD permet d’agir rapidement entre les deux.
  Sans ces trois piliers, on ne travaille pas vraiment : on suppose. Voire, on espère. D’ailleurs, Bastien nous l’a répété pendant des mois et des mois : « arrête de supposer ».

Être lucide, c’est se poser les bonnes questions : est-ce que mon problème est vraiment technique ? Est-ce que mon code n’est pas trop complexe ?
Être lucide, c’est accepter que nos décisions passées ne sont pas des erreurs honteuses, mais des décisions qu’il faut savoir assumer et corriger. D’autant plus facilement si on a des bons outils et la bonne méthode.

Une conférence présentée par

Joel GOMEZ CABALLE

Joël est développeur web depuis 2001. Il a fondé sa société en 2007, avec laquelle il a créé une plateforme de téléchargement de musique. En 2011, il a fusionné sa société avec l'agence Aropixel, où il a rejoint son associé actuel, lui aussi issu du monde de la musique. À partir de 2012, ils ont commencé à utiliser Symfony, un framework sur lequel ils se sont spécialisés. Ils réalisent des applications métier pour tout type d’activités, et plus particulièrement pour le domaine culturel. Ils ont notamment conçu un système de billetterie racheté et utilisé depuis plusieurs années par la branche B2B de France Billet (Fnac Darty). Ils assurent également toute la communication exécutive et les outils digitaux du festival Garorock.

Bastien JAILLOT

Bastien, spécialisé sur les situations qui ne sentent pas bon : profession "pompier du code". Quand il ne dépanne pas des projets inconnus, jl est architecte logiciel / expert pour de très belles entreprises où il intervient sur des architectures qui peuvent monter en centaines de serveurs. Il a cofondé jolicode et, si ses calculs sont bons, c'est la 4321423e fois qu'il intervient pour l'AFUP

Autres interviews