✨ SyliusCon 2025 : l’écosystème Sylius atteint sa pleine maturité

le 20 octobre 2025

SyliusCon 2025 a confirmé que l’écosystème Sylius est désormais un acteur majeur du paysage e-commerce open source. Construit sur la base solide de Symfony, Sylius poursuit sa montée en puissance technique, tout en s’ouvrant à de nouveaux horizons : scalabilité cloud, expérience développeur modernisée et intégration croissante de l’intelligence artificielle.

Le programme dense de cette édition révèle un cadre professionnel, orienté production et efficacité. Loin des effets d’annonce, les conférences ont mis en avant des sujets concrets : migration, performance, automatisation, et IA pragmatique.

Sylius 2024–2025 : communauté, produit, et cap sur le B2B, par Mikołaj Król

Communauté & écosystème

  • Année record de meetups (même hors Europe) et de participations aux conférences : la stratégie est claire — renforcer les liens IRL.
  • 15 nouveaux partenaires rejoignent l’écosystème (avec un partenaire leader en France).
  • Arrivée (retour) d’un CTO, Simon, contributeur de la première heure.
  • Coup de chapeau aux key contributors et aux bénévoles qui entretiennent le cœur open-source.

Rythme produit & versions

  • 30 releases publiées sur l’année (sécurité + features).
  • Sylius 1.x : dernière année en 2025, fin de support en 2026 → cap recommandé sur Sylius 2 (outils d’accompagnement prévus).

Doc-First & extensions officielles

  • Virage documentation-first : écrire le manuel avant la feature pour accélérer l’adoption et la qualité.
  • CMS officiel (UX dev & éditeur simplifiés) et Wishlist désormais plugins Sylius maintenus.
  • Standard MCP (agent commerce) : premiers pas concrets pour acheter via agent dans Sylius — sujet stratégique à suivre.
  • Refonte du process de plugins : nouveau squelette, pipeline plus lisse, test-app dédiée pour vérifier les plugins sur plusieurs versions (Sylius 1 & 2).

Front & DX

  • Boilerplate React/PWA connecté à l’API Sylius pour raccourcir les projets headless.

  • Store Wizard : génération d’une démo/POC en minutes (données + habillage), boostée à l’IA — utile pour les avant-ventes.

  • Nouveaux modules :

    • Request for Quotation (RFQ) pour le B2B ;
    • Made-to-Order / Web-to-Print pour les produits personnalisés/fabriqués à la commande.

Focus B2B : « Elasto »

  • Lancement d’un accélérateur B2B (UX revue, pricing avancé, intégrations, gros catalogues testés ~600k SKU).
  • Démo publique disponible + démo live sur le stand.

Feuille de route 2026

  • Marketplaces : accélérateur dédié (features modernes, DX soignée).
  • B2C Fashion pack : démarrage express pour les cas mode.
  • IA pour devs : bibliothèques + contextes pour accélérer créations, migrations et maintenance.
  • Installation de plugins/thèmes depuis l’admin, et refonte du Sylius Store pour mieux monétiser thèmes/plugins (appel aux créateurs).

À retenir pour Darkwood

  • Si vous démarrez ou migrez : anticipez Sylius 2 ; utilisez la test-app et les accélérateurs (B2B/à venir Marketplace & Fashion).
  • Pour les avant-ventes : Store Wizard permet de poser un POC convaincant en quelques minutes.
  • Côté offres : pensez RFQ et Made-to-Order si vos parcours l’exigent.
  • Si vous éditez des extensions : fenêtre d’opportunité avec l’admin d’installation et la refonte du Store.

Message clé : Sylius consolide sa base (docs, plugins officiels, DX), accélère le B2B avec un produit vitrine (Elasto) et prépare 2026 autour de Marketplaces, B2C packs, IA dev et distribution d’extensions depuis l’admin.

De la maintenance maîtrisée à l’échelle cloud

La conférence de Mathias Arlaud sur la gestion des obsolescences a donné le ton : le couple Symfony/Sylius arrive à maturité. L’heure n’est plus à la course aux versions, mais à la planification raisonnée des montées de version. Les dépréciations deviennent des jalons de roadmap, non plus des freins.

Même logique du côté de la performance. Erwin Hofman a démontré comment Chrome DevTools, enrichi d’un assistant IA intégré, simplifie désormais le débogage des Core Web Vitals. La performance devient un indicateur métier à part entière.

Et lorsque Gracjan Józefczyk évoque la scalabilité de Sylius sur le cloud, le message est clair : l’ère du e-commerce cloud-native est pleinement ouverte. Containers ECS, base Aurora, S3 + CloudFront, SQS : Sylius prouve sa capacité à tenir des charges massives, tout en restant un framework open source. FrankenPHP y joue un rôle clé, modernisant la chaîne de déploiement et d’exécution PHP.

Sylius peut encaisser des pics massifs (ex. milliers de commandes/heure, voire plus) à condition de traiter la scalabilité comme une discipline : base de données pensée lecture/écriture, exécution conteneurisée, CDN pour les assets lourds, et observabilité + tolérance aux pannes. Le cas d’usage “lancement de jeux vidéo” sert de stress test (volumétrie AAA).

Contexte & problématique

Question cliente typique : “Sylius peut-il tenir 6 000 commandes/heure ?”

Bench mental via l’industrie gaming (Elden Ring, Zelda, Cyberpunk…) : les sorties AAA créent des pics planétaires (millions de ventes en quelques jours).

Conclusion : ce niveau de charge existe il faut s’y préparer by design.

Architecture recommandée (AWS en exemple)

Base de données (Aurora/RDS)

Vertical scaling simple (RAM/CPU/storage) + read replicas en horizontal scaling.

Pattern read/write split (Doctrine/Symfony) : opérations écriture sur le primaire, lectures massives sur les réplicas (indexation, recherche, analytics).

Failover automatique : en cas de panne du primaire, une réplica prend le relais (minimise l’incident au lieu d’un restore snapshot coûteux).

App Sylius conteneurisée

Déploiement ECS (ou K8s) avec Auto Scaling : x instances aux heures de pointe, ↓ la nuit.

Séparation des rôles : containers HTTP vs workers (Messenger/cron).

Blue/green / canary : routage d’un pourcentage de trafic vers la V2; rollback instantané via le load balancer.

Distribution de contenu & latence

S3 + CloudFront pour assets/ téléchargements lourds (ex. jeux 100+ Go) → trafic déporté du serveur applicatif, cache edge proche des clients (Sydney, NY, etc.).

Gestion des images via Flysystem / LiipImagine + adaptateurs S3/CloudFront (changement config, pas de refactor massif).

Sécurité & réseau

App & DB en subnets privés; seul ALB/CloudFront exposé publiquement.

Infrastructure as Code

Terraform/CloudFormation en Git : PR, revue, traçabilité ; tout le monde comprend et peut faire évoluer l’infra (pas d’“admin sorcier”).

SLA et coût de la panne

99% de disponibilité = ~2 j 15 h 36 min d’arrêt/an → pertes sur pics de commandes.

Le cloud coûte mais coûte moins qu’une indisponibilité au mauvais moment.

Mise en œuvre côté code (Symfony/Sylius)

Doctrine multiple connections (primary/replicas) + hints “read-only”.

Images/FS : FilesystemInterface (Flysystem) → switch S3/CloudFront sans changer le code métier.

Sylius Docker-ready (docker-compose), transposable en prod (ECS/K8s).

Message clé

Sylius “vole” très bien dans le cloud si l’on découple lecture/écriture, qu’on autoscale l’app, et qu’on externalise le statique/lourd au CDN. Le goulot n’est pas Sylius en soi, mais l’architecture que vous lui donnez.

Ressource bonus

Gracjan ouvre un cours gratuit “Can Swans Fly?” : déployer Sylius sur AWS avec Terraform (blueprints, pas-à-pas).

CMS, API, Mobile : Sylius s’intègre dans tous les environnements

Le débat CMS réunissant Sulu, DegDitor et Monsieur Biz a montré la vitalité de l’écosystème : Sylius ne cherche plus à tout faire, mais à bien s’interfacer. Le headless commerce trouve enfin son équilibre entre flexibilité et robustesse.

Côté mobile, la présentation de Dominique De Vasconcelos, Célia Maure et Jérôme Caluory sur le déploiement d’une application B2B connectée à l’API Sylius illustre parfaitement cette ouverture : une même base, plusieurs interfaces, et une cohérence d’expérience utilisateur sur tous les canaux.

L’intelligence artificielle, utile et intégrée

SyliusCon 2025 a surtout marqué une rupture dans la manière d’aborder l’IA. Finie la fascination pour les modèles géants, place aux intégrations utiles.

Avec Nicolas Potier et Sabrine Ferchichi, l’IA conversationnelle s’invite dans le commerce : un assistant shopping intégré à WhatsApp montre comment Sylius peut s’ouvrir au conversational commerce.

Magda Sadowska a poursuivi cette vision avec une approche orientée développeur. L’intégration de Codex et du Model Context Protocol (MCP) permet de simplifier la documentation, d’accélérer la recherche et de fluidifier la collaboration. L’IA n’est plus une feature gadget, mais un moteur de productivité intégré.

Voici un résumé prêt à intégrer dans l’article de blog Darkwood du talk de Magda Sadowska (“L’IA et Sylius : un partenariat prometteur”) :

L’IA chez Sylius : pas une baguette magique, un multiplicateur

Thèse

Chez Sylius, l’IA n’est ni imposée ni “auto-pilot” : c’est un outil mesuré qui augmente une petite équipe (≈20 pers.) pour livrer mieux et plus vite. On mesure d’abord, on adopte ensuite, on garde ce qui prouve sa valeur.

Principes d’usage (qui marchent vraiment)

  • Contexte riche > modèle : objectifs, fichiers, contraintes, critères de “done well”.
  • Planning mode (30 s) avant de briefer l’IA → moins d’allers-retours.
  • Petits périmètres + reset fréquent du contexte.
  • Rubber-ducking : l’IA comme clarificateur (expliquer un code inconnu, journal de changements).
  • Jamais obligatoire : la diffusion se fait par démos courtes et “repeatable wins”.
  • Seniors posent gardes-fous; juniors explorent et trouvent des patterns utiles.
  • Rappel lucide : des études montrent que les seniors peuvent être ralentis par l’IA → on cible les bons cas (code inconnu, onboarding, recherche, traduction/explication).

4 initiatives concrètes boostées par l’IA

  1. MCP (Model Context Protocol) pour Sylius

    • “USB-C de l’IA” : un agent peut appeler des outils réels de la boutique (ex. passer commande).
    • En cours : couche d’intégration MCP pour guided setup (paiements, taxes, shipping), troubleshooting (“pourquoi le checkout échoue en FR ?”), CRM/PIM, taux live, labels…
    • KPI visés : moins de clics admin, démos plus rapides, audit logs clairs des actions d’agent.

  2. Store Wizard (générateur de démos)

    • Génère en heures une démo Sylius (catalogue, visuels, structure) à partir d’un brief.
    • A inspiré l’installation de plugins & thèmes via UI (PoC validé).

  3. Packs de contexte IA pour migrations 1.x → 2.x

    • Contextes “riches” (BC breaks, checklists, hooks, API) que l’IA utilise pour suggérer des changements et pointer les risques.
    • Le dev reste au volant ; objectif : débloquer vite plugins & projets.
    • Publication prévue de hints de compatibilité plugins + partage des contextes d’upgrade.

  4. Refonte de la doc (2.x)

    • Migration assistée par IA (repo + anciennes docs + règles internes) vers une doc plus accessible, à jour (hooks, APIs) et mieux inter-liée (Symfony, API Platform).

Aussi, côté marketing & recherche

  • L’IA sert au landscaping, à la veille (pricing, changelogs, qualité docs), au cross-linking — toujours revue humaine à la clé.

Ce que Darkwood retient

  • Mesurer > “hype” : on garde ce qui réduit cycle-time, bugs et frictions éditeur.

  • Investir dans le contexte améliore plus la qualité que changer de modèle.

  • Cas d’or pour nous :

    • Démos POC accélérées (Store Wizard),
    • Guided setups via MCP (paiements/shipping prêts à l’emploi),
    • Upgrades Sylius 2.x assistées (packs de contexte),
    • Docs/procédures clarifiées par l’IA.

Roadmap côté Sylius

  • Étendre MCP (config, troubleshooting, guidage).
  • Remplacer les outils IA qui ne conviennent pas; standardiser les contextes utiles.
  • Publier guides de compatibilité et partager les contextes d’upgrade avec la communauté.

Message clé de Magda : l’IA n’a pas changé l’équipe — elle a changé la façon d’orchestrer le travail. Pas de magie, mais des pratiques qui transforment de bonnes idées en résultats.

Enfin, Andrzej Michałowski et Mike Korba ont exploré le futur de la personnalisation via les Large Behavioral Models (LBM), ces systèmes capables d’interpréter les comportements utilisateurs avec la même finesse que le langage. L’hyper-personnalisation devient mesurable, contextualisée, et réellement actionnable.

Andrzej Michałowski a ouvert sa conférence en retraçant 12 ans d’évolution de la personnalisation, depuis les systèmes de recommandation classiques jusqu’aux architectures unifiées temps réel. Chez Synerise, sa société, plus de 1,8 milliard de messages personnalisés et 4,6 milliards de recommandations sont générés chaque mois via e-mail, SMS, push et WhatsApp. L’idée centrale : la personnalisation n’est plus un module marketing, mais un système d’orchestration des interactions client.

  1. Les trois piliers de la personnalisation moderne

La donnée toujours à jour. Synerise a conçu sa propre base orientée behavioural data, capable d’exécuter les segmentations à la volée (décision en 10–20 ms).

L’IA pas comme substitut, mais comme amplificateur. L’IA permet de combiner des signaux simples (nom, points fidélité) avec des prédictions complexes (propension, churn, produits probables).

L’exécution tout doit être unifié : données, contenu, canaux et CRM dans une même plateforme, avec automatisation low-code et suivi omnicanal.

  1. Large Behavioral Models : l’après-LLM

Andrzej a introduit le concept de Large Behavioral Models (LBM) :

Des modèles fondamentaux entraînés non sur le langage, mais sur les comportements.

Comme les LLM prédisent le mot suivant, les LBM prédisent la prochaine action client : clic, achat, visite. Une fois le modèle de base construit, il devient trivial de créer des modèles spécialisés par cas d’usage (recommandation, churn, scoring) en quelques heures, au lieu de plusieurs semaines. Les résultats de Synerise dépasseraient déjà ceux des travaux similaires publiés par Meta et DeepMind.

  1. Un cas réel : Decathlon Pologne

L’exemple présenté était parlant : le site Decathlon.pl personnalise en temps réel l’intégralité de l’expérience :

Bannières dynamiques selon les propensions d’achat ;

Catégories, marques et produits adaptés à la session ;

Recommandations panier et pages produits contextualisées ;

Emails et push alignés avec le parcours global. Chaque interaction ajuste instantanément les recommandations, prouvant la faisabilité d’une personnalisation de session à grande échelle.

  1. Le plugin Synerise x Sylius

En conclusion, Andrzej a annoncé la sortie d’un plugin Synerise pour Sylius, permettant de :

Synchroniser automatiquement les données clients et produits ;

Exploiter la personnalisation dès l’installation ;

Capteur en temps réel les événements (transaction, panier, visite) ;

Déployer des scénarios multi-canaux sans code.

  1. Vers le Behavioral CMS

Enfin, il a présenté un nouveau concept : le Behavioral CMS, un système de contenu entièrement headless qui s’appuie directement sur les données comportementales pour générer et personnaliser le contenu sans intégration manuelle. Ce CMS permet de centraliser le contenu, le CRM et les données produits pour une expérience toujours fraîche, cohérente et contextuelle.

🧩 En résumé

Andrzej Michałowski replace la personnalisation dans un cadre global :

Des données comportementales unifiées, des modèles fondamentaux entraînés sur l’action humaine, et une exécution omnicanale automatisée.

Sylius devient ainsi une brique au sein d’une architecture data-centrée, où l’IA ne remplace pas le marketing, mais le rationalise.

Un développement plus fluide, plus propre

L’ergonomie développeur (DX) progresse aussi. Loïc Frémont et Estelle Gaits ont présenté un Sylius Grid modernisé basé sur les nouveaux attributs PHP #[AsGrid], #[AsFilter] et sur Symfony UX LiveComponent, pour un back-office réactif sans JavaScript sur-mesure.

De son côté, Stephan Hochdörfer a rappelé l’importance d’un environnement de développement reproductible avec DDEV : plus de divergences de configuration, moins de friction entre équipes.

Voici un résumé éditorial (prêt à coller dans l’article Darkwood) du panel CMS : Johannes Wachter (Sulu), Filippo Maria Tasca (DegDitor), Jacques Bodin-Hullin (Monsieur Biz), avec la perspective Sylius CMS (core).

CMS & Sylius : choisir l’outil au bon niveau de complexité

Problème de départ

Vous lancez une boutique, l’équipe marketing demande « on peut éditer juste ce petit bloc ? » → on a besoin d’un CMS. Le panel pose la bonne question : quel CMS pour quel contexte (taille d’équipe, importance du contenu, contraintes e-commerce) ?

ADN des solutions (pourquoi elles existent)

  • Sulu (Johannes – Sulu CMS) Né dans le DACH (DE/AT/CH) : multilingue/multi-portail de naissance, symfonique, pensé « content application platform ». Double pilier : socle technique robuste + UX éditeur très soignée.
  • DegDitor (Filippo) Parti du besoin des marchands (ex-Shopify, luxe/fashion) : productivité front et liberté éditeur (live preview, drag-drop, clonage), découplage front/back pour itérer vite.
  • Monsieur Biz CMS (Jacques) Écosystème plugins CMS 100% Sylius (éditeur riche, homepage, menu, pages) : flexibilité dev, zéro synchro côté boutique, DX simple pour ajouter des blocs « maison ».
  • Sylius CMS (vision core – Nico) Plugin minimal et simple : base compréhensible par n’importe quel dev Symfony/Sylius, extensible sans friction. Volontairement non-exhaustif : si le contenu devient stratégique, montez en gamme.

Ce que chacun fait “le mieux”

  • Sulu : internationalisation & multi-site au cordeau, UX éditeur avancée, perfs front, et écosystème “enterprise” (ERP, PIM, intégrations).
  • DegDitor : productivité front (front dev autonomes), expérience éditeur moderne (live preview, blocs clonables). Idéal quand le contenu “raconte” le produit (lookbooks, éditos, landing).
  • Monsieur Biz : flexibilité pragmatique à l’intérieur de Sylius, mise en place très rapide, safe by design pour les non-tech, tout en laissant les devs créer des UI blocks sur mesure.
  • Sylius CMS : simplicité et time-to-value mini pour des besoins basiques (quelques pages/blocs), parfait pour démarrer et prototyper.

Pour qui / quand ?

  • Petites équipes, contenu “nice to have” (B2B, peu d’éditorial) → Sylius CMS (starter), puis Monsieur Biz si besoin de blocs riches.
  • Marques “content-driven” (mode, luxe, storytelling, nombreuses landing) → DegDitor (autonomie front + UX éditeur).
  • Environnements “enterprise” (multi-pays, ERP/PIM, workflows éditoriaux, forte équipe contenu) → Sulu (CMS spécialisé, découplé, scalable).

Règle pratique : mesurez la taille de l’équipe contenu plutôt que la taille du catalogue. Plus l’édition/approbation/SEO pèsent lourd, plus un CMS spécialisé s’impose.

Collaboration & UX éditeur

  • Sulu : l’IA est vue comme un moteur de fonctionnalités dans l’UI (boutons, champs, recherche), pas seulement un chat.
  • DegDitor : front–first, éditeur React avec live preview, contrôle fin de ce que l’éditeur peut modifier (garde-fous via YAML des blocs).
  • Monsieur Biz : éditeur riche modulaire + prévisualisation (en cours d’amélioration), sécurité côté plateforme ; on n’expose pas l’éditeur à casser le front.
  • Sylius CMS : sobre par choix l’UX dépend beaucoup de comment le dev l’étend.

IA & automatisation (positions assumées)

  • Sulu : intègre l’IA dans l’UI (SEO assisté, optimisation de contenu) + prépare une plateforme AI “provider-agnostic” (clé, prompts, RGPD, multi-fournisseurs) pour les agences.
  • DegDitor : expérimente traductions, génération de contenu, pages via YAML, et pont Figma → blocs (esquisse → composant).
  • Monsieur Biz : vise l’IA pour accélérer la création de nouveaux UI blocks (MCP/LLM pour scaffolder).
  • Sylius CMS : ne poursuit pas l’IA “éditeur” en standard (choix stratégique : laisser les spécialistes s’en charger).

Coût total de possession (TCO)

  • Sulu : OSS, pas de licence ; exige des devs Symfony expérimentés ; s’exécute du VPS au cloud scalable (K8s, functions).
  • DegDitor : licence ~2 500 € one-off par domaine primaire (+ 4 sous-domaines), starter pack pour réduire le time-to-market ; après création des blocs, peu de back-end requis.
  • Monsieur Biz : installation rapide (Composer) ; parfait pour juniors sur la création de blocs ; coût d’adoption faible si déjà sur Sylius.
  • Sylius CMS : MIT, coût = apprentissage + personnalisation ; idéal pour démarrer petit.

Reco Darkwood (grille de décision express)

  • Besoin immédiat, équipe réduite, 5–10 pages → Sylius CMS.
  • On veut rester dans Sylius mais muscler l’édition → Monsieur Biz CMS.
  • Front réactif, marketing exigeant, beaucoup de templates → DegDitor.
  • Multi-site, multi-langue, gros workflows & intégrations → Sulu.

Idée force : commencez intégré (coût marginal), montez en spécialisation quand l’équipe contenu grandit et que le contenu devient un levier business (SEO, storytelling, campagnes).

Voici un résumé prêt à intégrer dans l’article de blog Darkwood du talk de Ksenia Zvereva (“Cadrer, itérer, livrer”) :

Cadrer, itérer, livrer : le kit de survie produit pour équipes tech

La thèse

Arrêtez d’empiler des features et de courir derrière les urgences : cadrez le problème, limitez l’appétit (temps), shippez petit et souvent, puis itérez avec des signaux réels. Le but n’est pas “plus de code”, mais plus d’impact.

Les 3 gros pièges à éviter

  • Sur-engagement fonctionnel : scope qui gonfle, dates qui glissent.
  • Résistance au changement : incapacité à intégrer des insights marché en cours de route.
  • Validations tardives : on code sur des suppositions non testées.

Principes directeurs (à appliquer par toute l’équipe, pas seulement le PO)

  1. Mindset produit partagé : devs, design et PO co-détiennent l’outcome (pas seulement l’output).
  2. Outcomes > Output : priorisez l’effet business/utilisateur, pas la quantité de tickets.
  3. Shape avant de coder : clarifiez problème, contraintes, pitch → puis solution.
  4. Définir l’“appétit” : “Combien de temps sommes-nous prêts à investir ?” → temps fixe, scope flexible.

Techniques pragmatiques

  • Prototypage rapide (heures, pas jours) : maquettes cliquables pour valider parcours et hypothèses avant le build.
  • Cycles dédiés (ex. 6 semaines) : out-of-cycle (shaping/betting) → in-cycle (build focus, pas de distractions) → cool-down (retours, dette, “petits plus”).
  • T-shirt sizing (S/M/L/XL) : langage d’effort commun, meilleure prévision de charge.
  • Feature flags / déploiement incrémental : livrer en prod sous drapeau, activer 2–5–10 % → mesurer → élargir ou rollback en 2 clics.
  • Pré-mortem (30–45 min) : lister avant le go-live ce qui peut casser (DB, latence, sécurité, LB), et poser des parades simples.

Mantra de livraison

Ship à 70–80 %, mets-le devant de vrais utilisateurs, apprends et itère. La “GA” n’est pas une fin, c’est un flux d’amélioration continue.

Ce que Darkwood retient

  • Cadence > performance héroïque : une équipe gagne par cadence maîtrisée et risque maîtrisé.
  • La qualité vient du cadre (shape, appétit, flags), pas d’un sprint “magique”.
  • Ces pratiques s’appliquent tel quel aux projets Sylius/Symfony (flags, cycles, sizing) et réduisent drastiquement les dérapages.

Mini check-list (30 jours)

  • Instituer shape doc (1 page) pour tout sujet > 2 jours.
  • Adopter T-shirt sizing dans le backlog courant.
  • Mettre en place 1 feature flag de bout en bout (CI/CD → activation progressive).
  • Planifier un cycle focus (2–6 semaines) + cool-down dédié.
  • Tenir 1 pré-mortem avant le prochain go-live.

Voici un résumé prêt à intégrer dans l’article Darkwood du talk de Loïc Frémont & Estelle Gaits (“Pole position sur la grille”) :

Sylius Grid : DX turbo, live UX et découplage total

L’idée clé

Le Grid Bundle devient un data grid universel (Sylius 1 & 2) : moins de YAML/boilerplate, plus d’attributs PHP, de fournisseurs de données custom (sans Doctrine) et une UX réactive avec Symfony UX Live Components. Résultat : des back-offices rapides, modulaires, et prêts pour des cas non-e-commerce.

Les nouveautés qui comptent

  • Générateur make:grid : fonctionne désormais avec n’importe quelle classe PHP (plus seulement des entités Doctrine).

  • Attributs

    • #[AsGrid(...)] : déclare provider, resourceClass, name ; méthode __invoke() à la place de buildGrid() (SRP, code plus net).
    • #[AsFilter(...)] : type de form Symfony, template Twig, alias de filtre — tout est co-localisé dans la classe.

  • Providers sans DB : démo avec OpenF1 (trois pas : vide → données en dur → API). Le provider applique les criteria (ex. country) et sert les objets au grid.

  • Navigation “grids reliés” : actions qui pré-filtrent une autre grille (ex. bouton “Team radios” → grille déjà filtrée par pilote).

UX réactive (expérimental)

  • Remplacement des Twig blocks du grid par un Live Component (via Twig hooks).
  • Pagination, changement de page/limit, filtres → sans rechargement.
  • Plusieurs grids sur une même page, chacun pré-filtré.
  • Composants live fournis pour filtres select, string, tabs (mise à jour “as-you-type”).

Ce que ça change pour nous (Darkwood)

  • Back-offices sans JS custom : #[AsGrid]/#[AsFilter] + Live Components suffisent dans la majorité des cas.
  • Sources hétérogènes (API, fichiers, services internes) sans Doctrine : idéal pour les écrans d’ops/transverse.
  • Moins d’état côté front, plus de clarté côté PHP (attributs, providers, templates localisés).

Mini check-list d’adoption

  • Migrer un grid existant vers #[AsGrid] + __invoke().
  • Extraire un provider pour une source non-DB.
  • Créer un filtre custom avec #[AsFilter] (type + template).
  • Relier deux grids via action + criteria.
  • Activer le Live Component sur un écran (pagination & filtres sans reload).

En bref : le Grid Bundle 1.14 met la DX en pole position et ouvre la voie à des admin panels réactifs et API-first – avec Sylius comme châssis, quel que soit le moteur de données.

DDEV pour des environnements dev Docker… sans la douleur, pas Stephan Hochdörfer (BitExpert)

Pourquoi DDEV ?

Né dans la communauté Drupal, DDEV est aujourd’hui un outillage open-source générique qui masque la complexité Docker pour le dev local. Idéal si l’équipe ne veut pas « parler Docker » au quotidien, tout en gardant ses bénéfices (isolement, reproductibilité, multi-projets).

Démo live (avec quelques imprévus 😉)

Stephan a lancé un projet from scratch :

  • ddev config → génère .ddev/config.yaml (nom du projet, type Symfony/Drupal/… , docroot, version PHP).
  • ddev start → construit une image par projet avec les bons UID/GID (fini les fichiers root).
  • ddev launch → ouvre l’URL locale (plus besoin de retenir des domaines).
  • Commandes intégrées : ddev console (alias de bin/console), ddev exec, ddev logs -s db, ddev import-db/export-db (agnostiques MySQL/PostgreSQL).
  • Commandes custom (ex. ddev bootstrap) pour chaîner Composer/Yarn/migrations — la « doc exécutable » de votre README.

Add-ons & services

Un registry d’add-ons permet d’ajouter Redis, OpenSearch/Elasticsearch, Varnish, etc. via ddev add-on get …. Stephan a montré comment empaqueter ses propres add-ons (ex. Algolia) avec dépendances entre services.

IDE & DX

Le plugin DDEV pour PhpStorm (maintenant maintenu par l’équipe DDEV) :

  • Autoconfigure PHP, Docker, PHPUnit, Xdebug (« xdebug on » et ça marche).
  • Met à jour les connexions DB/Redis du projet. Résultat : on code, pas on câble.

Web servers & stacks exotiques

Au-delà d’Apache/Nginx, DDEV sait tourner avec un web server générique :

  • Exemple montré : FrankenPHP (Dockerfile dédié + generic_webserver + daemon command).
  • DDEV peut aussi piloter bun.js, Spring Boot, etc. tant qu’un endpoint HTTP est exposé.

Sylius : test-app & plugins

Clin d’œil Sylius : Stephan a branché la test-app Sylius dans DDEV pour tester des plugins rapidement (env DB/Redis injecté, alias vendor/bin/console). Pratique pour maintenir un plugin sur Sylius 1 & 2.

Stopper proprement

  • ddev stop : arrête les conteneurs du projet.
  • ddev poweroff : coupe aussi les conteneurs globaux (traefik, ssh).

Ce qu’on retient pour nos projets

  • Onboardings accélérés : 4–5 commandes et un poste est opérationnel.
  • Moins d’erreurs humaines : images par projet, commandes aliasées, add-ons standardisés.
  • Meilleure qualité : scripts ddev = procédures reproductibles (CI/CD local).
  • Gains Sylius : test rapide de plugins, multi-versions, stacks B2B/B2C modulaires.

En bref : DDEV donne la puissance de Docker sans la friction — parfait pour des équipes e-commerce (Sylius, Symfony…) qui veulent livrer vite, propre, et sans chasser des ports ni des IDs de conteneurs. Ah, et oui… il avait des stickers 😄.

Cinq tendances de fond à retenir

  1. Upgrade-as-a-discipline : la montée de version devient un process piloté et mesurable.
  2. Cloud-native par défaut : conteneurs, messagerie, CDN et FrankenPHP comme socle de base.
  3. API orientées agents : une nouvelle génération d’API pensée pour interagir avec des agents autonomes.
  4. DX unifiée : Symfony UX + Sylius Grid refondu = back-office réactif sans complexité front.
  5. IA pragmatique : l’intelligence intégrée à la chaîne de valeur (doc, data, décision), pas seulement aux fonctionnalités visibles.

En conclusion

SyliusCon 2025 n’a pas seulement confirmé la solidité technique du framework ; elle a révélé une communauté mûre, structurée et consciente de ses enjeux. Sylius devient un socle stratégique, capable d’affronter la complexité du commerce moderne, sans sacrifier la qualité du code ni la liberté d’intégration.

La maturité de l’écosystème Sylius repose désormais sur trois piliers : standardisation, scalabilité et intégration intelligente.