Forum PHP 2025 : entre immersion technique et exploration des tendances à venir

Pourquoi on a aimé :

Une rétrospective éclairante et, surtout, une feuille de route très concrète pour les prochaines versions (7.4 puis 8). On retient la poussée continue sur l’ergonomie dev (Maker), l’ouverture aux runtimes modernes (FrankenPHP), et des workflows plus expressifs.

Ce qu’on retient :

• Maker bundle toujours plus complet (make:auth, etc.) pour générer rapidement les bases d’un projet. Lien GitHub
• FrankenPHP s’installe comme un runtime “citoyen de première classe” dans l’écosystème Symfony. (Convergence vue aussi côté API Platform.) Speaker Kévin DUNGLAS
• Workflow & Enums. La communauté pousse depuis longtemps pour mieux typer places/transitions avec des Enums ; c’est discuté publiquement depuis 2021 et revient régulièrement sur la table. À date, la doc officielle ne déclare pas (encore) “Enum partout” dans Workflow, mais on surveille les avancées annoncées pour 7.4/7.5. symfony.com

Et pour nos projets ?

• Cap sur la v7.4 puis v8 : tenir nos projets au goût du jour est primordial pour nos équipes. Les tests de compatibilité et l’adaptation de nos composants/projets avec la dernière version sont d’ores et déjà prévus. Nous pourrons ainsi exploiter toutes les nouveautés de Symfony notamment sur les composants Maker et Workflow.
• Veille sur FrankenPHP : Nous utilisons déjà FrankenPHP pour certains de nos projets internes et prévoyons également de tester le mode worker afin de mesurer les différences de latence et consommation avec le mode FPM. Speaker Kévin DUNGLAS

Pourquoi on a aimé :

On utilise API Platform au quotidien : la 4.2 clarifie la frontière Parameters ↔ Filters et rend la documentation/validation d’API plus explicites.

Ce qu’on retient (très actionnable pour nous) :

• Passage des ApiFilter historiques à des QueryParameter/HeaderParameter déclaratifs : meilleure séparation entre les notions de documentation, validation, requête et schéma JSON. API Platform
• Nouveaux filtres (dont OrFilter, FreeTextQueryFilter) et amélioration d’OpenAPI/JSON Schema. soyuka.me
• Performance & FrankenPHP évoquées comme axes forts côté runtime. Speaker Kévin DUNGLAS

Et pour nos projets ?

• Plan de migration : remplacer nos anciens ApiFilter par des #[QueryParameter] explicites, et d’introduire OrFilter / FreeTextQueryFilter là où les besoins métiers le justifient. Cela permettra de simplifier notre code en retirant des surcharges désormais inutiles.
• Doc/validation OpenAPI : profiter de cette séparation plus nette pour documenter précisément nos critères de recherche dans OpenAPI, avec à la clé un meilleur DX pour les développeurs et une meilleure qualité pour les tests et QA.

Pourquoi on a aimé :

Une alternative simple aux grosses applications front (SPA) :
On peut améliorer l’expérience utilisateur progressivement, en partant d’un HTML classique, puis en ajoutant des attributs HTMX pour rendre les pages plus dynamiques.
Le tout en restant dans notre stack habituelle : templates Twig et contrôleurs Symfony.

Ce qu’on retient.

• HTMX = du HTML “augmenté” via des attributs hx-* (hx-get, hx-post, hx-trigger, etc.) pour obtenir une UX plus fluide sans framework front complexe.
• Intégration simple avec Twig et les contrôleurs Symfony existants.
• Slides et démo publiques pour rejouer les exemples. damienalexandre.fr

Et pour nos projets ?

• Utiliser HTMX + Twig sur des écrans ciblés.
  Par exemple : formulaires, listes interactives, petites interactions locales où une SPA complète serait disproportionnée.
• Définir des guidelines DX autour de HTMX.
  Mettre en place des conventions pour les attributs hx-*, documenter les bonnes pratiques, et garder un œil sur la dette JS pour ne pas “reconstruire une SPA cachée”.

Pourquoi on a aimé :

Nous faisons déjà beaucoup de SQL “bas niveau” : ce talk nous a donné des patterns modernes à (ré)adopter CTE, window functions, LATERAL JOIN notre coup de cœur à tester rapidement pour remplacer des boucles PHP/N+1 et mieux exploiter PostgreSQL. slides

Ce qu’on retient :

• CTE (WITH ...) pour découper et nommer des sous-requêtes complexes, au lieu de sous-selects imbriqués illisibles. WITH Queries (Common Table Expressions)
• RETURNING pour éviter les allers-retours PHP ↔ BDD, lorsqu’on a besoin des lignes modifiées.
• Window functions (row_number, lag, lead, …) pour des calculs analytiques élégants côté base. Window functions
• LATERAL JOIN, c’est le pattern SQL qui permet d’exécuter une sous-requête dépendante pour chaque ligne de la table principale, et ainsi remplacer des boucles PHP (N+1 requêtes) par une seule requête optimisée et déclarative.
• 2 sites pour progresser en PostgreSQL :
  • PSQL Tips
  • PostgreSQL Exercises

Et pour nos projets ?

• Introduire LATERAL partout où l’on fait du top-N ou de la recommandation par entité.
  Par exemple : top 3 opérations par utilisateur, recommandations par profil, etc. → objectif : zéro N+1 sur ces cas.
• Généraliser CTE + window functions dans nos vues complexes.
  Là où nous avons aujourd’hui plusieurs requêtes ou des sous-selects imbriqués, nous pourrons gagner en lisibilité et en performance.
• Exploiter systématiquement RETURNING sur nos requêtes d’écriture.
• Ajouter une check-list SQL dans nos PR :“Peut-on déplacer cette logique vers une CTE, une window function ou un LATERAL JOIN ?”

Pourquoi on a aimé :

Un rappel de notions et fonctionnements que nous utilisons quotidiennement.

Ce qu’on retient :

• Rappel du principe SOLID appliqués aux services et à la configuration.
• Injection de dépendances : les étapes de compilation et runtime dans Symfony.
• Les différents attributs Symfony en lien avec l’injection de dépendance.

Et pour nos projets ?

• Revoir certains services “historiques”.
  Identifier les services trop “gros” ou surchargés et envisager un découpage plus SOLID.
• Valider nos usages d’attributs d’injection.
  Vérifier que nous utilisons les bons attributs au bon endroit (performance, lisibilité, intention claire), en cohérence avec les recommandations de la conf.
• Mieux documenter le cycle de vie DI pour l’équipe.
  Partager une synthèse en interne pour que chaque développeur comprenne mieux ce qui se passe entre configuration, compilation et runtime.

Pourquoi on a aimé :

Dans le monde de l’IA générative, faire une démo ou un POC est devenu relativement simple. Là où ça se complique, c’est au moment de passer en production : réduire les hallucinations, faire respecter les consignes, maîtriser les coûts, éviter les abus…
François Zaninotto a remis l’accent là où il doit être : 90 % du travail sur les agents IA, c’est de l’évaluation et de l’itération, bien plus que du “prompt magique”.

Ce qu’on retient :

• Implémenter l’IA dans une appli (mobile ou web) n’est que le début : le vrai sujet, c’est “est-ce que l’agent répond vraiment correctement ?”.
• Il faut orienter l’agent au maximum : prompts bien pensés, exemples, consignes, mais aussi métriques et statistiques pour mesurer ce qu’il fait réellement.
• L’humain garde un rôle central : vérifier, annoter, corriger les réponses de l’IA reste indispensable.
• Retour d’expérience très concret :
  • utilisation d’un pattern stratégie pour configurer les comportements de l’agent,
  • conserver tous les tests (configuration + réponses) dans une base de données pour pouvoir comparer les versions et améliorer l’agent dans le temps,
  • ne pas hésiter à commencer avec les meilleurs modèles même s’ils coûtent plus cher, le but étant d’abord de prouver la valeur,
  • accepter que c’est un travail long et exigeant en data : il faut des jeux de tests, des scénarios, des métriques, des itérations successives.

Et pour nos projets ?

• Évaluation avant intégration.
  Avant d’envisager un agent IA sur un cas client, nous devons prévoir un jeu d’évaluation : prompts, entrées métiers typiques et réponses attendues. L’objectif est de mesurer la pertinence avant de brancher l’agent à un vrai workflow.
• Centraliser les tests IA.
  Les tests (prompts + réponses + configuration du modèle) doivent être stockés et historisés : base de données ou repository dédié. Cela permettra de comparer les versions d’agent entre elles, de suivre les régressions et d’objectiver les améliorations.
• Accepter que c’est un chantier au long cours.
  Mettre en place un agent “sérieux” nécessite :
  • du temps de configuration,
  • du travail de data (jeux de tests, exemples, contre-exemples),
  • et des boucles d’itération.
    C’est un vrai projet produit, pas juste une feature “IA” à cocher.
• Commencer petit, mais bien.
  Sur nos projets, cela signifie :
  • choisir un cas d’usage métier très ciblé,
  • le traiter avec un modèle de bonne qualité,
  • instrumenter métriques et logs dès le début,
  • puis seulement après, réfléchir à l’optimisation des coûts (modèle moins cher, cache, hybridation, etc.).