While the industry keeps debating whether AI makes engineers a bit more productive or a lot more productive, the debate misses the real shift. What's happening is a collapse of the talent stack: designers, PMs, ops… suddenly able to contribute directly to the codebase. And that changes the mandate for platform teams. It's no longer just about enabling engineers to go faster, but enabling everyone to build safely, responsibly, and with as little friction as possible. At Alan, a health insurance company serving over 1 million users in production across Europe, we embraced this shift head-on by launching "Everyone Can Build." In just two quarters, 283 pull requests from non-engineers were merged to production—from designers shipping UI improvements to operations teams enhancing internal tools. This isn't a proof of concept: it's a production-grade transformation powered by AI that has fundamentally redefined our development culture and what it means to be a platform engineering team. This session reveals the blueprint of how we achieved 100% AI adoption across our organization and rebuilt our engineering platform to support this new reality.

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.

Pendant que l'industrie continue de débattre pour savoir si l'IA rend les ingénieurs un peu ou beaucoup plus productifs, ce débat passe à côté du vrai changement. Ce qui se passe, c'est l'effondrement de la pile de talents : designers, PMs, ops… soudain capables de contribuer directement au code. Et cela change la mission des équipes plateforme. Il ne s'agit plus seulement de permettre aux ingénieurs d'aller plus vite, mais de permettre à tout le monde de créer de manière sûre, responsable et avec le moins de friction possible. Chez Alan, une compagnie d'assurance santé qui sert plus d'un million d'utilisateurs en production à travers l'Europe, nous avons pris ce virage de front en lançant « Everyone Can Build ». En seulement deux trimestres, 283 pull requests de non-ingénieurs ont été mergées en production : des designers livrant des améliorations d'interface aux équipes opérations améliorant leurs outils internes. Ce n'est pas une preuve de concept : c'est une transformation en production, portée par l'IA, qui a profondément redéfini notre culture de développement et ce que signifie être une équipe plateforme. Cette session dévoile comment nous avons atteint 100 % d'adoption de l'IA dans toute l'organisation et reconstruit notre plateforme d'ingénierie pour soutenir cette nouvelle réalité.

Do you spend your day in meetings? Is it possible to build a successful, regulated, and rapidly growing company by challenging traditional management hierarchies and rituals? Alan is a health insurance company serving over 30,000 businesses and 1 million members in France, Spain, Belgium, and Canada. What truly sets us apart is that we've grown to over 700 employees without traditional managers and with virtually no recurring meetings. This model, our competitive advantage, is how we run a large-scale, regulated insurance company every day. In this presentation, I'll take you to the heart of this radical model and share: The traditional hierarchy-free organization: How we replaced managers with coaches and separated operational leadership from individual development. The written and asynchronous culture: How decisions are made transparently in Slack, GitHub, and Notion, not in conference rooms. Distributed Ownership: How 700 people set their own goals and hold each other accountable without top-down control. The Systems That Enable Scalability: The rituals and mechanisms that make this model work day-to-day. Our Lessons Learned: What we did wrong, what we're still perfecting, and why this model isn't for everyone. This presentation will share the honest truth—what works, what doesn't—and offer concrete principles you can apply to your own organization to gain speed and transparency.

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.

¿Pasas el día en reuniones? ¿Es posible construir una empresa de éxito, regulada y en rápido crecimiento, cuestionando la jerarquía y los rituales de gestión tradicionales? Alan es una aseguradora de salud que da servicio a más de 30 000 empresas y 1 millón de miembros en Francia, España, Bélgica y Canadá. Lo que nos hace realmente únicos es que hemos superado los 700 empleados sin managers tradicionales y prácticamente sin reuniones recurrentes. Este modelo, nuestra ventaja competitiva, es la forma en que gestionamos cada día una aseguradora regulada a gran escala. En esta charla te llevaré al corazón de este modelo radical y compartiré: La organización sin jerarquía clásica: cómo sustituimos a los managers por coaches y separamos el liderazgo operativo del desarrollo individual. La cultura de lo escrito y lo asíncrono: cómo las decisiones se toman de forma transparente en Slack, GitHub y Notion, y no en salas de reuniones. El ownership distribuido: cómo 700 personas fijan sus propios objetivos y se responsabilizan sin control top-down. Los sistemas que permiten escalar: los rituales y mecanismos que hacen funcionar este modelo en el día a día. Nuestras lecciones aprendidas: lo que hicimos mal, lo que aún estamos perfeccionando y por qué este modelo no es para todo el mundo. Esta charla compartirá la verdad sin filtros —lo que funciona y lo que no— y ofrecerá principios concretos que podrás aplicar en tu propia organización para ganar en rapidez y transparencia.

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 !