Vue d’ensemble de la conférence
Le Day 2 de Laracon EU a gardé le même ton pragmatique que le Day 1, avec un accent encore plus fort sur les workflows de livraison. La journée a enchaîné outillage frontend (Inertia v3), discipline d’architecture, dynamique NativePHP, culture du shipping en production, contraintes data réelles, refactorisation orientée parallélisme, puis panel final à fort signal avec l’équipe Laravel.
Le fil rouge est net : les outils accélèrent l’implémentation, mais la qualité durable dépend toujours de la structure, des contrats typés, de la clarté opérationnelle et des boucles de feedback en production.
Partie 1 - Joe Tannenbaum sur Inertia v3 et le workflow frontend
Thème
Rendre le frontend plus simple, plus léger et plus intelligent, sans perdre le contrôle.
Résumé
Joe a ouvert le Day 2 avec une démonstration très concrète d’Inertia v3. Son message est simple : Inertia v2 avait ouvert la voie avec l’asynchrone, et v3 pousse plus loin en réduisant la friction sur le setup, le SSR, les requêtes HTTP et l’ergonomie globale.
Le point clé est le convention over configuration. Les chemins de setup les plus courants sont simplifiés, tout en gardant des possibilités d’override explicites. Il a aussi insisté sur l’amélioration de l’expérience SSR locale et sur un noyau plus léger grâce au retrait de dépendances devenues inutiles.
Autre axe fort : les requêtes non-visit, la sécurité de typage et les mises à jour optimistes côté UI. L’objectif est de rendre les apps plus réactives et plus lisibles, avec moins de boilerplate.
Le talk a gardé une approche réaliste côté adoption : migration incrémentale, compatibilité là où nécessaire, et gains progressifs sur le code frontend existant.
Points clés
- Inertia v3 se concentre sur trois objectifs : simpler, slimmer, smarter.
- Le setup convention-first réduit la complexité sans bloquer les personnalisations.
- SSR et gestion des requêtes sont plus fluides au quotidien.
- Les optimistic updates améliorent fortement la perception de vitesse.
- Wayfinder + patterns typés renforcent le contrat backend/frontend.
- La migration peut se faire progressivement, sans rupture brutale.
Partie 2 - Wendell Adriel sur le “puzzle mindset”
Thème
Construire des applications avec des pièces composables, typées et remplaçables.
Résumé
Wendell a proposé une approche “puzzle builder” : penser les systèmes comme un assemblage de petites pièces, avec responsabilité claire, interfaces explicites et comportement prévisible. Dans l’ère IA, cette clarté devient encore plus importante, car elle aide à la fois les humains et les agents.
Son cadre repose sur quatre principes : responsabilité unique, connexions standardisées (typage fort), tests en isolation, et pièces faciles à remplacer. Du backend au frontend en passant par l’infra, le même raisonnement s’applique.
Il a aussi couvert les dérives fréquentes. Trop d’abstraction peut faire plus de mal que de bien, et un DRY poussé à l’extrême crée souvent de la complexité fragile. Dans bien des cas, un code simple et lisible bat une architecture “théoriquement parfaite” mais difficile à maintenir.
Sa recommandation pratique : commencer par renforcer les types et les contrats, puis refactoriser progressivement là où la douleur est réelle.
Points clés
- Penser classes/composants/services comme des pièces bien délimitées.
- Le typage fort standardise les connexions entre pièces.
- Tester en isolation avant de composer des flux plus larges.
- Préférer des actions/controllers ciblés aux classes “fourre-tout”.
- Éviter l’over-engineering basé sur des besoins hypothétiques.
- En workflow IA, un contexte clair donne des résultats plus fiables.
Partie 3 - Shane Rosenthal sur la dynamique NativePHP
Thème
Transformer une idée “improbable” en workflow produit reproductible.
Résumé
Shane a prolongé l’histoire NativePHP avec une perspective très builder : les ambitions plateforme deviennent réelles quand on livre en continu, qu’on réduit la friction d’entrée et qu’on garde une boucle de feedback active avec la communauté.
Le talk a mélangé direction technique et trajectoire produit. NativePHP n’est pas présenté comme un gadget, mais comme une voie pratique pour permettre aux développeurs Laravel de livrer des apps mobiles natives avec des outils familiers.
Il a aussi insisté sur la réalité du moment : les pratiques de développement assisté par IA bougent vite, et l’outillage doit suivre. Les guidelines, plugins et workflows doivent évoluer en même temps que les usages.
Le message global est celui d’un chantier long terme : baisser les barrières, rester aligné avec l’écosystème Laravel, et avancer vers un niveau app-store avec exécution continue.
Points clés
- NativePHP évolue du concept audacieux vers un usage concret.
- L’open source et le feedback communauté sont centraux.
- Les workflows s’adaptent activement au coding agentic.
- L’objectif est la livraison réelle, pas la démo isolée.
- La régularité d’exécution reste la meilleure réponse au scepticisme.
- La familiarité Laravel accélère l’adoption.
Partie 4 - Pete Heslop sur le service design hors tech
Thème
Beaucoup de réponses UX existent déjà hors du logiciel.
Résumé
Pete a relié hospitalité, événementiel et conception produit logiciel. Son point central : de nombreux problèmes “digitaux” sont en réalité des problèmes de service design, déjà maîtrisés depuis longtemps dans des environnements opérationnels exigeants.
Il a montré comment les systèmes intentionnels, les rituels d’équipe et la clarté des rôles produisent des expériences fiables, même sous stress. En software, cela correspond à des processus qui survivent aux handoffs, à la croissance d’équipe et au turnover.
Un point fort du talk : transformer des règles en rituels utilisables. Une règle dépend trop souvent de son auteur; un rituel partagé crée de la robustesse dans la durée.
Ce talk a apporté une perspective transversale précieuse : au-delà des frameworks, c’est la qualité de l’expérience de bout en bout qui fait la différence.
Points clés
- L’UX est d’abord du service design, pas uniquement de l’UI.
- L’hospitalité offre des patterns réutilisables pour le software.
- Un process ne scale que s’il devient rituel d’équipe.
- La fiabilité sous pression se conçoit, elle n’arrive pas par hasard.
- Les équipes tech gagnent à observer des contextes réels exigeants.
- Une meilleure chorégraphie opérationnelle améliore directement le produit.
Partie 5 - John Drexler sur le shipping “day one”
Thème
Livrer tôt et souvent est une stratégie technique, pas un slogan.
Résumé
John a défendu un biais production très fort : la valeur d’un logiciel se vérifie en prod, pas dans les documents ni dans la certitude locale. Son talk reformule le “we must ship” comme une discipline d’ingénierie fondée sur les boucles de feedback, l’ownership et la réalité opérationnelle.
Il oppose deux mondes : le confort du “mind palace” (où tout semble cohérent en théorie) et la production (où les hypothèses sont testées). À mesure que générer du code devient facile, ce n’est plus l’implémentation qui est rare, mais la capacité à opérer un système fiable.
La recommandation est claire : réduire le temps entre idée et validation en production, sans lâcher les garde-fous qualité. Les équipes qui apprennent plus vite de l’usage réel prennent de meilleures décisions produit.
Ce talk s’aligne parfaitement avec la journée : les outils accélèrent, mais seule la réalité production tranche.
Points clés
- Le vrai métier reste de faire fonctionner le logiciel en production.
- La cadence de shipping est un avantage d’ingénierie.
- L’IA réduit le coût de génération, pas le coût de responsabilité.
- Le feedback prod doit piloter les décisions produit/architecture.
- Réduire la boucle idée -> comportement validé en réel.
- Miser sur le professionnalisme opérationnel, pas le volume brut.
Partie 6 - Daniel Colborn sur les imports et la réalité data
Thème
La complexité data reste plus dure que la génération de code.
Résumé
Daniel a partagé un war story centré sur les imports et les flux data en conditions réelles. Son constat est direct : générer du code est de plus en plus facile, mais dompter des données de production reste un problème difficile.
Il a mis en lumière l’écart entre implémentation locale “propre” et réalité terrain : gros fichiers, entrées imparfaites, échecs partiels, retries, et cas limites opérationnels. Ces sujets demandent des décisions architecture pragmatiques, pas seulement de l’élégance.
Le talk touche aussi à l’identité de l’ingénieur à l’ère IA : certaines métriques historiques de “bon dev” bougent, mais la capacité à raisonner système, data et fiabilité devient encore plus déterminante.
La leçon rejoint les autres sessions du jour : pour créer un avantage durable, il faut investir dans les pipelines data, la lisibilité opérationnelle et l’apprentissage continu en production.
Points clés
- Les workflows data sont un cœur de complexité moderne.
- Les imports réels échouent de façons non “propres”.
- Retry, observabilité et flux défensifs sont indispensables.
- L’IA accélère l’écriture, pas la maîtrise des données réelles.
- Le bon engineering devient davantage “systems thinking”.
- La robustesse pragmatique bat l’élégance fragile.
Partie 7 - Marcel Pociot sur la refactorisation orientée parallélisme
Thème
Le parallélisme devient un levier concret dans les workflows modernes.
Résumé
Marcel a exploré l’évolution des pratiques de développement et l’intérêt croissant d’une refactorisation pensée pour le parallélisme. Avec l’accélération des outils agentiques, les architectures doivent absorber plus de changements et de charge de façon sûre.
Son angle est très pratique : refactor to parallel n’est pas un slogan, c’est une réponse à des contraintes de throughput. Une meilleure décomposition, des frontières plus nettes et une concurrence mieux pensée réduisent les goulots d’étranglement.
Il rappelle aussi un point essentiel : écrire moins de code “à la main” ne réduit pas la responsabilité sur la cohérence système. Au contraire, la vitesse de génération augmente le coût d’une architecture floue.
Le talk s’inscrit dans la logique générale du Day 2 : les systèmes parallélisables se conçoivent explicitement, ils n’émergent pas par hasard.
Points clés
- La vitesse de sortie augmente, l’architecture doit suivre.
- Un design parallel-friendly réduit les bottlenecks sériels.
- Refactoriser sert aussi le throughput, pas seulement la lisibilité.
- Les agents amplifient le besoin de frontières système claires.
- La discipline de review reste critique avec génération accélérée.
- Décomposition intentionnelle = gains perf + maintenabilité.
Partie 8 - Panel Laravel (Taylor Otwell, Jess Archer, Joe Dixon, Joe Tannenbaum)
Thème
Livraison continue, choix pragmatiques et cap produit clair.
Résumé
Le panel final a donné une vision très concrète du fonctionnement actuel de l’écosystème Laravel, côté open source comme côté produits. Les sujets ont couvert les routines d’équipe à grande échelle, l’usage quotidien de l’IA, les choix de stack frontend, l’état de PHP, le rythme de release, et les compromis d’architecture.
Message récurrent : la valeur est livrée en continu. Les “grosses” releases semblent plus modestes parce qu’une partie majeure des nouveautés sort désormais tout au long de l’année, sur plusieurs surfaces (framework, outils, plateforme).
Autre point fort : pragmatisme avant dogme. Les choix Livewire/Inertia, JS/TS, patterns de structuration dépendent du contexte équipe et du produit à livrer.
Le signal global est solide : l’écosystème Laravel s’élargit en gardant la productivité développeur comme principe central.
Points clés
- Le modèle Laravel privilégie la livraison continue.
- Open source et produits évoluent désormais à plus grande échelle.
- L’IA est intégrée comme levier pratique du quotidien.
- Les choix de stack sont contextuels, pas idéologiques.
- L’état de PHP est perçu comme robuste et durable.
- Le cap reste le même : réduire la friction entre idée et livraison.
Annexe - Points issus des pauses/livestream (court)
Les interviews de pause ont confirmé trois tendances:
- Les toolmakers optimisent l’intégration workflow, pas seulement les features isolées.
- Les équipes agence/produit se recentrent sur feedback production et réalité data.
- La dynamique communautaire continue d’accélérer l’adoption Laravel.
Ces segments ont apporté un contexte terrain complémentaire aux talks.
Synthèse finale
Le Day 2 confirme que l’ingénierie Laravel moderne devient une discipline système. Le code se génère plus vite, mais la valeur durable vient de la structure, de la clarté des contrats, de la qualité opérationnelle et de la vitesse d’apprentissage en production.
Les équipes qui internalisent ce modèle auront le plus de levier dans l’ère IA : moins de complexité accidentelle, plus de feedback utile, et une capacité de livraison robuste face au changement.
L'enregistrement vidéo en EN sur Youtube : Laracon EU Amsterdam 2026 Day 2.