Mientras la industria discute si la IA aumenta la productividad de los ingenieros, se ignora el verdadero cambio: la transformación del talento. Diseñadores, gerentes de producto y equipos de operaciones ahora contribuyen directamente al código. Esto redefine el propósito de los equipos de plataforma: ya no se trata solo de acelerar a los ingenieros, sino de permitir que todos desarrollen de forma segura y sin fricciones. En Alan, una aseguradora de salud, adoptamos este cambio con "Everyone can build". En solo dos trimestres, se integraron en producción más de 200 PRs de usuarios no ingenieros: diseñadores implementando mejoras en UI y equipos de operaciones optimizando herramientas internas. No es una prueba de concepto, sino una transformación productiva impulsada por IA que redefinió nuestra cultura de desarrollo. Esta sesión revela el modelo que nos permitió lograr la adopción total de IA en la organización y reconstruir nuestra plataforma de ingeniería para esta nueva realidad.

Passez-vous votre journée en réunion ? Est-il possible de bâtir une entreprise à succès, réglementée et en croissance rapide, en remettant en question la hiérarchie et les rituels de gestion traditionnels ? Alan est une compagnie d'assurance maladie qui sert plus de 30 000 entreprises et 1 million de membres en France, en Espagne, en Belgique et au Canada. Ce qui nous rend vraiment uniques, c'est que nous avons atteint plus de 700 employés sans managers traditionnels et avec pratiquement aucune réunion récurrente. Ce modèle, notre avantage concurrentiel, est ainsi que nous gérons une compagnie d'assurance réglementée à grande échelle, tous les jours. Dans cette présentation, je vous emmènerai au cœur de ce modèle radical et partagerai : L'organisation sans hiérarchie classique : Comment nous avons remplacé les managers par des coachs et séparé le leadership opérationnel du développement individuel. La culture de l'écrit et asynchrone : Comment les décisions sont prises de manière transparente dans Slack, GitHub et Notion, et non dans des salles de conférence. L'appropriation (ownership) distribuée : Comment 700 personnes fixent leurs propres objectifs et se tiennent responsables sans contrôle descendant (top-down). Les systèmes qui permettent l'échelle : Les rituels et les mécanismes qui font fonctionner ce modèle au quotidien. Nos leçons apprises : Ce que nous avons mal fait, ce que nous sommes encore en train de perfectionner, et pourquoi ce modèle n'est pas pour tout le monde. Cette présentation partagera la vérité honnête – ce qui fonctionne, ce qui ne fonctionne pas – et offrira des principes concrets que vous pourrez appliquer à votre propre organisation pour gagner en rapidité et en transparence.

What if you cannot trust your tests? With more and more developers working on our monolith, we have a strong CI to deliver code into production: our goal is to deliver meaningful features to our customers with quality code and a stable platform. But some tests started failing randomly and this spread quickly through our codebase. Test failures block our CI and this leads to a huge waste of time and frustration when the application isn’t actually broken. We’ll explore the importance of tests, common errors that can lead to test flakiness, and strategies we have put in place to mitigate it.

Vos tests vous mettent en colère ? Vous empêchent-ils d'itérer rapidement ? De plus en plus de développeurs travaillent sur notre monolithe et certains tests ont commencé à échouer de manière aléatoire et cela s'est propagé rapidement dans notre base de code. Comme notre objectif principal est de fournir des fonctionnalités significatives à nos clients avec un code de qualité et une plateforme stable, les échecs de test bloquent notre CI. Cela entraîne une énorme perte de temps et de la frustration lorsque l'application n'est pas vraiment cassée. Ce problème était connu depuis un moment… Mais personne ne voulait s'y attaquer; le cacher sous le tapis était plus facile. Et coder des fonctionnalités est bien plus gratifiant que de corriger des tests buggés ! Au cours de cette conférence, nous verrons des exemples concrets des raisons pour lesquelles nos tests n'étaient pas satisfaisants et la manière dont nous les avons corrigés, avec des stratégies à la fois techniques et humaines.

About to finish my first year in my company, I caused not one but two incidents in production in one hour! Despite the tense moment, it was a huge learning. No one ran with their arms in the air, shouting at each other, nor began to look for culprits. Conversely, a close-knit team that helps each other reestablished the production as quickly as possible by collectively acknowledging the error made. How do we manage a production incident with peace of mind? an upstream quality process (code review, sandbox environment, functional review ...) a process for detecting and reporting incidents clear roles and responsabilities on incident management a post-mortem and concrete actions to avoid a repeating similar incident In this conference I will explain how to reduce and improve the management of your incidents and you will leave with the keys to apply this in your teams.

Sur le point de finir ma première année dans mon entreprise, j'ai provoqué pas un mais deux incidents en production en une heure ! Malgré le moment de tension, cela a été une énorme source d'apprentissage. Personne a couru les bras en l'air en criant les uns sur les autres ni s'est mit à chercher des coupables. À l'inverse une équipe soudée et qui s'entraide a réétabli la prod au plus vite en reconnaissant collectivement l'erreur commise. Comment arrive-t-on à gérer un incident en production en toute tranquilité ? un processus de qualité en amont (revue de code, un environnement de sandbox, une revue fonctionnelle) un processus de détection et déclaration des incidents un responsable de gestion des incidents et des responsables par équipes un post-mortem et des action concrètes pour éviter la reproduction de l'incident Dans cette conférence je vous expliquerai comment réduire et amériliorer la gestion de vos incidents et vous repartirez avec les clés pour appliquer cela dans vos équipes.

Comment collaborer dans une entreprise alors que le nombre de développeurs ne cesse d'augmenter ? Quels outils pour installer une vision commune au delà des visions individuelles ? Nous somme aujourd'hui plus de 150 développeurs qui construisons ensemble un produit. Un des piliers de notre entreprise est l'autonomie, nous souhaitons que nos ingénieurs soient autonomes sur la prise des décisions de façon à ce qu'il n'y ait pas un petit groupe de personnes qui bloque notre capacité à délivrer. Cependant si on laissait chaque développeur prendre des décisions tout seul nous pourrions vite créer une forte dette technique qui nous empêcherait de continuer à développer des fonctionnalités. Pour répondre à cela nous avons créé deux initiatives : les RFC (Request for Comments), semblable à ce que l'on peut voir pour le langage PHP et les CoP (Community of Practice) organisés autour de centres d'intérêts (backend, devOps, DDD ...). Cette organisation nous permet d'avoir des discussions techniques, d'en garder un historique et d'avoir une vision commune. Je vous raconterai comment cette organisation nous aide au quotidien à collaborer et vous repartirez avec les clés pour mettre cela en place dans vos équipes.

Deadlines, besoins produit, pression forte et fonctionnalités à livrer : nos projets ont besoin de nous ! L'amélioration du quotidien se perd dans un second plan, alors qu’elle a un impact majeur sur l'augmentation de notre productivité et la qualité et maintenabilité de notre code. Constatant que nous voulions augmenter notre confort de travail, nous avons, depuis plus d'un an, mis en place des réunions techniques bi-hebdomadaires pour prendre le temps de discuter de notre plateforme et nos outils, au-delà des fonctionnalités. Chaque membre de l'équipe contribue ainsi à améliorer son expérience de travail et notre produit. À travers notre vécu, nos erreurs et des exemples techniques concrets, repensez vous aussi au développement de votre produit.

Développeuse junior : première semaine. Mes collègues m'ont forcée à déployer ma première feature sur 6play ! Malgré un petit frisson, tout s'est bien passé, grâce aux outils et bonnes pratiques qui nous guident. Ce n'était que le début ! Depuis, je gère l'infrastructure de mon projet. Je choisis mes bases de données, caches, mécanismes de stockage, ressources… En prenant en compte leur coût, les modes de backups ou les compétences dans nos équipes. Et je suis libre d'expérimenter avec n'importe quel service que je voudrais tester. En un an, je suis passée de "simple développeuse" à quelqu'un qui a conscience de sa plateforme, qui monitore son code et est responsable de sa production. Comment ai-je vécu cette transition ? Comment ai-je grandi en tant que développeuse ? Vous aussi, profitez de votre nouvelle liberté : devenez DevOps !