Blog
  • Login

  • Connexion
  • Inscription
  • Blog

  • Articles
  • en
  • de

🔹 API Platform Conference 2025 : retour sur deux jours intenses autour de l’écosystĂšme Symfony et PHP

le 20 septembre 2025

L’édition 2025 de l’API Platform Conference s’est tenue les 18 et 19 septembre. Pendant deux jours, la communautĂ© Symfony, PHP et API s’est retrouvĂ©e autour de confĂ©rences, retours d’expĂ©rience et discussions passionnĂ©es.

đŸŽ€ Jour 1 – 18 septembre

🔑 Opening Keynote – KĂ©vin Dunglas

PrĂ©sentation des nouveautĂ©s d’API Platform 4.2, avec un focus sur l’automatisation, le support du temps rĂ©el (Mercure, SSE), et l’intĂ©gration des LLMs. Une vision claire de l’avenir de l’écosystĂšme.

🔑 Keynote de KĂ©vin Dunglas – 10 ans d’API Platform et une nouveautĂ© majeure

Pour cĂ©lĂ©brer les 10 ans d’API Platform, KĂ©vin Dunglas, son crĂ©ateur, est montĂ© sur scĂšne Ă  Lille avec une annonce de taille : une nouvelle fonctionnalitĂ© commune Ă  API Platform et FrankenPHP.

đŸ‘šâ€đŸ’» Un parcours communautaire et coopĂ©ratif

KĂ©vin a rappelĂ© ses multiples casquettes : mainteneur de Symfony et PHP, cofondateur de la coopĂ©rative Les-Tilleuls.coop, et initiateur de projets comme Mercure, FrankenPHP et plusieurs composants Symfony. Il a insistĂ© sur le modĂšle coopĂ©ratif de son entreprise, oĂč les dĂ©cisions sont prises dĂ©mocratiquement et les bĂ©nĂ©fices partagĂ©s.

🎂 Dix ans d’API Platform

  • Au dĂ©part, un simple bundle Symfony de 2000 lignes de code pour exposer une API REST.
  • Aujourd’hui : une bibliothĂšque complĂšte, utilisable avec Symfony, Laravel ou sans framework, avec prĂšs de 10 000 stars GitHub et prĂšs de 1000 contributeurs.
  • L’esprit du projet reste le mĂȘme : exposer des APIs modernes Ă  partir de simples classes PHP, tout en offrant un support multi-styles.

🌐 Support multi-API

API Platform permet aujourd’hui de gĂ©nĂ©rer automatiquement :

  • REST (Hydra, HAL, JSON:API)
  • OpenAPI (description machine-readable)
  • GraphQL
  • Async APIs avec Mercure et SSE

Cette capacitĂ© Ă  unifier plusieurs styles d’API avec le mĂȘme code reste une force unique du framework.

💡 La nouveautĂ© : gRPC avec FrankenPHP

La grande annonce concernait l’arrivĂ©e de gRPC dans l’écosystĂšme.

  • gRPC (créé par Google) est un protocole haute performance basĂ© sur Protocol Buffers et HTTP/2.
  • Avantages : communication fortement typĂ©e, rapide, efficace, adaptĂ©e aux microservices, Ă  l’IoT et aux systĂšmes critiques.
  • Jusqu’ici, PHP ne pouvait pas servir de serveur gRPC (limitation technique).

👉 GrĂące Ă  FrankenPHP, Ă©crit en Go, il devient dĂ©sormais possible :

  • d’écrire des extensions en Go pour FrankenPHP,
  • de crĂ©er un serveur gRPC qui dĂ©lĂšgue la logique mĂ©tier Ă  des workers PHP,
  • de combiner le meilleur des deux mondes (Go pour la performance rĂ©seau, PHP pour la logique applicative).

Un prototype d’extension FrankenPHP gRPC est dĂ©jĂ  disponible sur le GitHub de KĂ©vin.

📈 Perspectives

  • GĂ©nĂ©rer automatiquement les fichiers proto Ă  partir des entitĂ©s API Resource.
  • IntĂ©grer gRPC directement comme format supportĂ© par API Platform.
  • Faciliter l’interopĂ©rabilitĂ© entre PHP, Go, et d’autres langages.

đŸ€ Une communautĂ© avant tout

KĂ©vin a conclu en rappelant que la vĂ©ritable force d’API Platform, c’est sa communautĂ© : contributeurs, formateurs, dĂ©veloppeurs. Il a aussi rendu hommage Ă  Ryan Reza, contributeur majeur rĂ©cemment disparu, et appelĂ© Ă  soutenir sa famille via une collecte.

📌 En rĂ©sumĂ©

La keynote d’ouverture a cĂ©lĂ©brĂ© 10 ans d’innovation et de communautĂ© autour d’API Platform, tout en annonçant une Ă©volution majeure : âžĄïž l’arrivĂ©e de gRPC dans l’écosystĂšme via FrankenPHP. Une avancĂ©e qui rapproche encore Symfony, Laravel et le monde PHP du futur des APIs modernes.

⚡ Performance

  • 180 000 requĂȘtes par seconde expliquĂ© simplement – Xavier Leune Un talk didactique qui a dĂ©taillĂ© les techniques derriĂšre une performance extrĂȘme : gestion fine des connexions, choix d’architecture rĂ©seau, et importance du runtime.

Performance réseau et concurrence en PHP

(kern, IO non bloquante, TCP/TLS, HTTP/2/3, DNS, fork & partage mémoire)

Bonjour — je suis Xavier Leune. Aujourd’hui on va parler de choses trĂšs concrĂštes : comment gĂ©rer efficacement des milliers de requĂȘtes depuis PHP, pourquoi le CPU se comporte comme il se comporte, et quelles techniques utiliser pour Ă©viter de se retrouver face Ă  un mur de connexions.

Contexte : pourquoi on perd du temps CPU quand on attend des réponses

Quand vous faites beaucoup de requĂȘtes rĂ©seau, la majoritĂ© du temps c’est attente (IO) — et pas de vrai calcul. Pourtant, dans un script synchrone classique vous pouvez voir beaucoup de cycles CPU consommĂ©s simplement Ă  tourner dans une boucle qui poll l’état des IOs : on fait false, false, false encore et encore. RĂ©sultat typique : on a 10 secondes de temps rĂ©el mais on en consomme 20s de CPU cumulĂ©es, parce que des boucles tournent en pure perte.

Kernel / IO non bloquante : libérez le CPU

La solution consiste Ă  laisser le kernel (ou la runtime) gĂ©rer l’attente plutĂŽt que de spinner en userland. Deux approches :

  • Polling naĂŻf : boucle active qui vĂ©rifie sans pause → coĂ»te cher en CPU.
  • Select / epoll / kqueue : on attend que le kernel signale une IO prĂȘte. En PHP, utiliser l’équivalent (select, stream_select, ou libs/event) rĂ©duit drastiquement les itĂ©rations et le temps CPU : on passe de milliers d’itĂ©rations Ă  quelques dizaines.

ConcrÚtement : remplacer une boucle while (!done) { check(); } par un select qui réveille le script quand il y a des évÚnements à traiter.

Attention au plafond : l’établissement des connexions

Établir une connexion TCP coĂ»te : ressources systĂšme, sockets, handlers, etc. Si vous ouvrez 2k, 4k, 8k connexions en peu de temps, vous risquez :

  • backlog plein cĂŽtĂ© serveur → SYN qui n’est jamais pris en charge ;
  • timeouts cĂŽtĂ© client (5–15s) parce que la connexion n’a jamais Ă©tĂ© complĂ©tĂ©e ;
  • erreurs visibles uniquement Ă  l’échelle (timeouts, refus, drop).

Conseil : throttlez le nombre de connexions en cours — par exemple limiter Ă  N connexions simultanĂ©es et n’en lancer de nouvelles que quand une libĂšre sa place. Montez progressivement N en fonction du comportement rĂ©el.

TLS (HTTPS) : une étape coûteuse supplémentaire

AprĂšs le handshake TCP, TLS ajoute des aller-retour (handshake) et du calcul crypto. Ça augmente la latence d’établissement. Si vous multipliez connexions courtes chiffrĂ©es, le coĂ»t par requĂȘte monte fortement.

  • Si possible, rĂ©utilisez les connexions (connection pooling / keep-alive).
  • Si vous devez ouvrir beaucoup de connexions, comptez le coĂ»t TLS et testez avec votre charge rĂ©elle.

DĂ©corrĂ©lation connexions ↔ requĂȘtes : multiplexing & protocole

Historique :

  • HTTP/1.x : une requĂȘte = une connexion (ou limitĂ© pipelining) → beaucoup de connexions.
  • HTTP/2 : multiplexing sur une seule connexion (plusieurs streams), ordre indĂ©pendant, rĂ©duit nombre de connexions.
  • HTTP/3 (QUIC) : sur UDP, connexion plus lĂ©gĂšre, support TLS intĂ©grĂ©, conception pour rĂ©seaux mobiles Ă  latence & pertes Ă©levĂ©es.

Conséquences pratiques :

  • Avec HTTP/2, on rĂ©duit le nombre de connexions et on augmente fortement le dĂ©bit de requĂȘtes/s sur un serveur bien configurĂ©.
  • Avec HTTP/3, on gagne en rĂ©silience sur rĂ©seaux instables, latence rĂ©duite dans certains scĂ©narios mobiles, mais les implĂ©mentations cĂŽtĂ© client <-> serveur peuvent encore ĂȘtre moins matures que HTTP/2 selon les stacks.

TCP: retransmission & head-of-line blocking

Avec TCP (fiable), si un paquet perd la troisiĂšme rĂ©ponse, TCP rĂ©transmettra tout le bloc concernĂ© — ce qui peut bloquer d’autres rĂ©ponses multiplexĂ©es si on n’a pas un protocole plus moderne (QUIC/HTTP3). D’oĂč l’intĂ©rĂȘt d’utiliser QUIC pour certains cas (latence mobile, pertes) — mais attention : implĂ©mentations et outils serveur-client doivent ĂȘtre matures.

DNS et répartition de charge client-side

Si votre domaine a plusieurs enregistrements A (ou plusieurs backends), la façon dont vous rĂ©solvez l’IP influe votre distribution de charge :

  • RĂ©solution DNS Ă  chaque requĂȘte peut aider Ă  augmenter la diversitĂ© des destinataires (round-robin).
  • RĂ©solution mise en cache cĂŽtĂ© client peut concentrer la charge sur un seul backend.
  • Parfois bisquer la rĂ©solution DNS (faire votre propre rotation) permet de rĂ©partir la charge.

Astuce pratique : prĂ©-resolvez les IP des backends, construisez vos requĂȘtes sur ces IP pour forcer le round-robin client-side si nĂ©cessaire.

Mesures & comparaisons : HTTP/1 vs HTTP/2 vs HTTP/3 (résumé)

Observations classiques sur tests de charge :

  • HTTP/1 : Ă©norme nombre de connexions, faible RPS par socket, CPU client Ă©levĂ©.
  • HTTP/2 : beaucoup moins de connexions rĂ©elles, trĂšs haut RPS (milliers → dizaines de milliers).
  • HTTP/3 : parfois meilleur sur mobiles/liaisons instables ; en pratique les rĂ©sultats varient selon implĂ©mentation, mais conceptuellement permet d’éviter certains blocages TCP.

Conclusion : HTTP/2 est souvent le meilleur compromis pour la plupart des charges serveur→navigateurs / API, sauf cas mobile/latence extrĂȘme oĂč HTTP/3 peut aider — testez.

Monter en CPU cÎté client : fork / parallel / pcntl

Parfois vous voulez utiliser pleinement le CPU client (tests de charge, traitements lourds). Options en PHP :

  • pcntl_fork (process fork) : crĂ©ation de processus enfant ; simple, robuste ; attention aux ressources partagĂ©es (sockets, DB).
  • parallel (extension) : exĂ©cution parallĂšle dans threads lĂ©gers (si disponible).
  • pthreads (deprecated / non-CLI), autres solutions OS-level.

Important : aprĂšs un fork, ne pas partager les mĂȘmes connexions ouvertes (sockets, DB handles) entre parent & enfant sans prĂ©cautions — ça casse les flux. Deux approches :

  1. Ouvrir la connexion aprĂšs le fork : chaque process a son propre socket/DB.
  2. Fermer et rĂ©ouvrir la connexion dans l’enfant : safe et simple.

Communication entre process : mémoire partagée

Quand on fork, il faut un moyen de synchroniser / communiquer :

  • Shared Memory (shmop / SysV shm / ext-shm) : crĂ©er une zone mĂ©moire partagĂ©e pour lire/Ă©crire strings, Ă©tats, etc. Utile, simple.
  • SĂ©maphores / files / sockets Unix : alternatives selon besoin.

Pattern classique :

  • parent crĂ©e la mĂ©moire partagĂ©e (ftok + shmget),
  • enfant Ă©crit pĂ©riodiquement,
  • parent lit / attend (poll / sleep) ;
  • cleanup Ă  la fin.

Ressources Ă  surveiller & bonnes pratiques

  • Limiter crĂ©ations de connexions simultanĂ©es (throttle).
  • RĂ©utiliser connexions (keep-alive, pools).
  • Utiliser select/epoll en mode IO non bloquante — ne pas spinner.
  • Tester TLS cost (handshake) : mesurer l’impact sur latence.
  • Surveiller backlog serveur : augmenter somaxconn ou config serveur si besoin.
  • AprĂšs fork, rĂ©ouvrir les connexions cĂŽtĂ© enfant.
  • PrĂ©-resoudre / gĂ©rer le DNS si vous voulez rĂ©partir la charge client-side.
  • Mesurer : CPU client, CPU serveur, RPS, latence p95/p99, erreurs/timeouts.

Démo & résultats (récapitulatif)

  • Script synchrone naĂŻf (200 concurrents, 1 000 requĂȘtes → serveur lent) : CPU client trĂšs Ă©levĂ©.
  • MĂȘme script utilisant select / wait : CPU client fortement rĂ©duit, itĂ©rations de boucle divisĂ©es par >100.
  • Ajout de throttling sur Ă©tablissement de connexion : baisse des timeouts et des erreurs.
  • Test comparatif HTTP/1 vs HTTP/2 vs HTTP/3 : HTTP/2 donne le meilleur throughput sur notre bench – HTTP/3 intĂ©ressant mais variable selon stack.

OĂč trouver le code et continuer

Tout le code de dĂ©monstration et les scripts sont disponibles sur GitHub (rĂ©pertoire liĂ© Ă  la prĂ©sentation) — vous pouvez cloner, exĂ©cuter les benchs et ajuster les paramĂštres pour votre infra.

Conclusion

  • La concurrence rĂ©seau efficace, ce n’est pas seulement ouvrir plus de connexions : c’est utiliser le kernel pour les IO, limiter les connexions simultanĂ©es, rĂ©utiliser les ressources, et adapter le protocole (HTTP/2/3) au contexte.
  • Quand vous montez la charge, observez les signaux : backlog, timeouts, CPU client/serveur, erreurs de rĂ©seau, et ajustez votre architecture.

Merci — si vous avez des questions je suis là aprùs la session, et le code est en ligne sur GitHub.

  • API Platform, JsonStreamer and ESA for a skyrocketing API – Mathias Arlaud Mise en avant du streaming JSON pour rĂ©duire la consommation mĂ©moire et booster la vitesse de rĂ©ponse des APIs Ă  grande Ă©chelle.

  • Scaling Databases – Tobias Petry Exploration des stratĂ©gies de scaling des bases : sharding, rĂ©plication, optimisation des indexes. Une piqĂ»re de rappel sur le rĂŽle central de la base de donnĂ©es dans la performance.

đŸ—ïž Retours d’expĂ©rience et architecture

  • API Platform in PrestaShop, a walk in the park? – Johathan LeliĂšvre Retour concret sur l’intĂ©gration d’API Platform dans un environnement e-commerce existant. DĂ©fis : compatibilitĂ©, performance et migration progressive.

  • API Platform x Redis – ClĂ©ment Talleu PrĂ©sentation des usages de Redis avec API Platform pour accĂ©lĂ©rer cache, sessions et file d’attente de jobs.

  • Design Pattern, le trĂ©sor est dans le vendor – SmaĂŻne Milianni Un talk conceptuel : comment les patterns enfouis dans nos dĂ©pendances influencent nos architectures et comment mieux les exploiter.

  • Et si on utilisait l’Event Storming dans nos projets API Platform ? – GrĂ©gory Planchat DĂ©monstration de l’Event Storming comme mĂ©thode collaborative pour concevoir des modĂšles riches et cohĂ©rents.

La quĂȘte de la “vĂ©ritĂ©â€ en systĂšmes distribuĂ©s

Le talk de Rob Landers (Engineering Manager, Fintech) — mis en article

TL;DR

  • La “vĂ©ritĂ©â€ en logiciel = faits prouvables → source of truth (base de donnĂ©es) + prouver (application).
  • Le cache accĂ©lĂšre
 et introduit des mensonges s’il est mal pensĂ© (clĂ©s incomplĂštes, invalidations hasardeuses, pollution transactionnelle, race-to-stale).
  • Les effets externes (e-mail, paiements, webhooks) ne participent pas Ă  vos transactions. Solution : outbox + message bus + idempotency.
  • Le sharding multiplie les vĂ©ritĂ©s et dĂ©truit vos garanties (transactions, joins, migrations). À Ă©viter tant que possible.
  • Objectif : des caches cohĂ©rents, des effets fiables, des systĂšmes dignes de confiance quand (pas si) la panne survient.

Qu’est-ce que la “vĂ©ritĂ©â€ pour une application ?

  • Philosophiquement floue, en logiciel on la construit :

    • Seau de faits = base de donnĂ©es (source of truth).
    • Provant ces faits = votre application (logique mĂ©tier, invariants).
  • Si vous pouvez rester Ă  ce modĂšle simple (App ↔ DB), restez-y.

L’inĂ©vitable cache

  • Pression perf → “On met un cache et tout ira mieux.”
  • Oui
 jusqu’au jour oĂč le cache contredit la DB et fait diverger le systĂšme.

Les 4 piÚges classiques du cache (et comment les éviter)

a) Clés incomplÚtes (key collision)

Anti-pattern

$key = "bookstore.revenue.$year";        // manque storeId !
return $cache->remember($key, fn() => calcRevenue($storeId, $year));

Fix : encoder toutes les dépendances dans la clé.

$key = "bookstore.$storeId.revenue.$year";

b) Invalidations impossibles

  • Si votre clĂ© encode le quoi mais pas le qui/quand, vous ne savez pas quoi invalider lors d’un changement.
  • Solution : tags/groupes. Exemple : taguer par store:$id et year:$year, puis invalider par tag.

c) Pollution transactionnelle

  • Vous Ă©crivez dans le cache avant COMMIT.

  • Si la transaction rollback, le cache diffuse un mensonge (valeur non validĂ©e).

  • RĂšgle d’or : Ă©crire/invalidater le cache aprĂšs COMMIT.

    • ImplĂ©mentez un cache transaction-aware (hooks post-commit).
    • Ou dĂ©placez la “couche cache” cĂŽtĂ© DB (matĂ©rialisations/index/plan de requĂȘtes) pour bĂ©nĂ©ficier des propriĂ©tĂ©s ACID.

d) Race-to-stale

  • T1 met Ă  jour DB + invalide → T2 recharge l’ancienne valeur entre inval et commit → cache obsolĂšte.

  • Mitigations :

    • Ordonner “COMMIT → invalidate/write” (hooks post-commit).
    • Verrous/versions (ETags, versions d’objets) dans le cache.
    • TTLs courtes + cache-aside robuste.

Check-list cache

  • [ ] ClĂ©s = toutes les dĂ©pendances (user, locale, filtres, feature flags
).
  • [ ] Invalidations par tags/groupes.
  • [ ] Écritures cache post-commit uniquement.
  • [ ] Tests de concurrence (race conditions).
  • [ ] ObservabilitĂ© (hit/miss, taux de stale, latences).

Les effets externes : vérité hors transaction

Le problĂšme

  • Paiements, e-mails, webhooks, APIs tierces : pas dans votre transaction.
  • Effet irrĂ©versible (e-mail envoyĂ©), Ă©tat invisible jusqu’au commit, retries non contrĂŽlĂ©s.

Le pattern qui marche

  1. Outbox (dans votre DB) : avant de “publier”, Ă©crivez un message en base dans la mĂȘme transaction que vos donnĂ©es mĂ©tier.
  2. Message bus (ex. Symfony Messenger avec transport Doctrine) lit l’outbox aprĂšs commit, exĂ©cute l’effet, marque succĂšs/Ă©chec.
  3. Idempotency keys cĂŽtĂ© fournisseur (paiement, e-mail) : au moins une fois → une seule application de l’effet.
flowchart LR
  A[App] -- Tx begin --> DB[(DB)]
  A -->|write data + outbox| DB
  DB -->|COMMIT| Q[Outbox Reader / Messenger]
  Q --> S[Service externe]
  S --> Q --> DB

Bonus

  • Compensating actions : on “annule” en avançant (ex. remboursement).
  • Idempotence cĂŽtĂ© consommateur de webhooks aussi (dĂ©duplication par clĂ©).

“Scalons Ă  l’infini” : pourquoi le sharding est (souvent) une fausse bonne idĂ©e

  • Plus de transactions globales (ou trĂšs cher).
  • Plus de joins inter-shards → dĂ©normalisation douloureuse.
  • Migrations longues et risquĂ©es (code long-lived multi-schĂ©mas).
  • ClĂ©s de cache Ă  Ă©largir (inclure shardId).
  • Recherche Ă  (rĂ©)inventer.
  • Horloge non unique (le “now” varie selon le shard).

Recommandation : Ă©puiser d’abord tout le vertical/horizontal sans shard (index, requĂȘtes, read replicas, partitionnement interne, caching cohĂ©rent, CQRS, projections/materialized views). Le sharding vient trĂšs loin dans la courbe.

Recette “vĂ©ritĂ© fiable”

  1. DB = source de vérité. Invariants en base, contraintes, transactions.
  2. Cache : dépendances complÚtes, invalidations pilotées, post-commit only, tests de course.
  3. Side-effects : Outbox + Bus + Idempotence (+ compensations).
  4. Observabilité : métriques cache (hit/stale), délais outbox, taux de retry, dead-letter queues, audit trail.
  5. Résilience : timeouts, backoff, circuite breakers, bulkheads.
  6. Tests : de concurrence (race), chaos lĂ©ger (dĂ©sactiver un nƓud cache, injecter latence).
  7. Ne pas shard-er tant que d’autres leviers existent.

Appendice — Anti-patterns & remùdes

  • if ($isAdmin) { 
 } if ($isCustomer) { 
 } → prĂ©fĂ©rer if 
 elseif 
 si exclusifs ; sinon explicitez les Ă©tats composĂ©s (FSM/invariants).
  • Écrire en cache dans une transaction → dĂ©placer l’écriture dans un hook post-commit ou un listener Doctrine.
  • Invalidations “à la main” → tags/groupes + “owner-ship” des clĂ©s par bounded context.
  • Bus sans idempotence → clĂ© dĂ©terministe (ex. UUID mĂ©tier) → at-least-once devient effectively once.
  • Webhooks non dĂ©dupliquĂ©s → table webhook_receipts(idempotency_key, received_at, status) + unique index.

Conclusion

La “vĂ©ritĂ©â€ n’est pas trouvĂ©e : elle est ingĂ©nierĂ©e. En posant des frontiĂšres claires (DB, cache, effets), en exigeant des engagements temporels (post-commit), et en traitant l’extĂ©rieur comme non fiable par dĂ©faut (outbox/idempotence), on construit des systĂšmes qui Ă©chouent sans s’effondrer — et qui disent le vrai, mĂȘme sous pression.

đŸ› ïž Outils et pratiques

  • Composer Best Practices 2025 – Nils Adermann Les recommandations actuelles pour gĂ©rer efficacement ses dĂ©pendances : contraintes de version, sĂ©curitĂ©, reproductibilitĂ© des builds.

🧰 Composer Best Practices 2025 — par Nils Adermann

“Beaucoup de bonnes pratiques n’ont pas changĂ© en 5–10 ans
 mais l’écosystĂšme, la sĂ©cu et nos outils, eux, bougent.” — Nils

🆕 Ce qui change (2025)

  • Adieu Composer 1 / API v1 de Packagist

    • Mettez-vous sur Composer 2 (obligatoire pour les updates ; Composer 1 ne sait plus rĂ©soudre via la v1).
    • Si vous ĂȘtes coincĂ©s, des proxies privĂ©s peuvent dĂ©panner
 mais la voie saine reste la migration.
  • Nouvelles menaces supply chain

    • Typosquatting et packages “hallucinĂ©s” par l’IA (noms inventĂ©s puis publiĂ©s par des attaquants).
    • Vigilance accrue sur ce que vous ajoutez dans composer.json.
  • Petites features qui changent la vie

    • composer update --minimal-changes : n’upgrade que le strict nĂ©cessaire pour rĂ©soudre un conflit.
    • composer update --patch-only : ne prendre que les patchs (x.y.z) — idĂ©al pour hotfix sĂ©cu.
    • composer update --bump (ou composer bump) : aligne vos contraintes composer.json sur les versions installĂ©es.
    • composer audit (auto-lancĂ© Ă  l’update) : dĂ©tecte les vulnĂ©rabilitĂ©s connues dans votre lock.

🔐 Supply chain & sĂ©curitĂ©

  • Pourquoi tout le monde est concernĂ© MĂȘme un “petit” site collecte des donnĂ©es → cible potentielle (phishing, pivot, etc.).

  • Bonnes pratiques clĂ©s

    • ExĂ©cutez composer audit en CI et alertes si vulnĂ©rabilitĂ©s apparaissent aprĂšs dĂ©ploiement.

    • Ajoutez le metapaquet roave/security-advisories : empĂȘche d’installer une version vulnĂ©rable.

    • Utilisez un repository Composer privĂ© (Private Packagist / Nexus / Artifactory / Cloudsmith
) :

      • Miroir des artefacts (pas seulement les mĂ©tadonnĂ©es) → protĂšge contre suppression ou retag sauvage.
      • Point d’entrĂ©e fiable pour vos builds (moins de dĂ©pendance directe Ă  GitHub).
    • Ne retaguez jamais une version publiĂ©e : faites une nouvelle release.

    • Sponsorisez vos dĂ©pendances (composer fund), la PHP Foundation, etc. : c’est votre supply chain.

🧭 SĂ©mantique & contraintes (rappels utiles)

  • PrĂ©fĂ©rez ^ (caret) pour exprimer “compatible jusqu’à la prochaine major” :

    { "require": { "vendor/lib": "^1.2" } }  // [1.2.0, <2.0.0)
    
  • Multi-majors (souvent pour PHP) :

    { "require": { "php": "^8.1 || ^8.2 || ^8.3" } }
    
  • Exclure des versions cassĂ©es :

    { "require": { "vendor/lib": "^1.2, !=1.3.2, !=1.4.0" } }
    
  • StabilitĂ© : dev, alpha, beta, RC, stable (dĂ©duite du tag). Branches = dev-xxx.

🍮 Forks : temporaire vs permanent

  • Fork temporaire (hotfix urgent)

    • RĂ©fĂ©rencez le dĂ©pĂŽt VCS + alias pour faire croire Ă  1.2.3 :

      "repositories": [{ "type": "vcs", "url": "https://github.com/me/lib" }],
      "require": { "vendor/lib": "dev-fix as 1.2.3" }
      
    • ⚠ Vous n’aurez pas les mises Ă  jour amont automatiquement → surveiller et revenir upstream dĂšs que possible.

  • Fork permanent

    • Renommez le package (my/lib) et remplacez l’original :

      "replace": { "vendor/lib": "self.version" }
      
    • Publiez votre package (ex. Private Packagist) et retirez la source VCS du projet.

🎯 Mises Ă  jour maĂźtrisĂ©es

  • Partielles :

    composer update vendor/zebra --with-dependencies
    composer update vendor/zebra vendor/giraffe --with-all-dependencies
    
  • Limiter l’onde de choc :

    • --minimal-changes : garde les versions actuelles dĂšs que possible.
    • --patch-only : ne prend que les correctifs.
  • Bloquer le retour arriĂšre :

    composer update --bump
    
  • Automatiser :

    • DĂ©tecteurs/PRs : Dependabot, Renovate (attention aux Ă©carts) ; Nils a prĂ©sentĂ© Conductor (outil ciblĂ© PHP/Composer : exĂ©cute l’update dans votre CI, comprend les plugins/scripts, regroupe mieux les PRs).

đŸ§© Monorepos

  • Utilisez des repositories path pour lier vos libs locales (symlink dans vendor/) :

    "repositories": [
      { "type": "path", "url": "packages/*", "options": { "symlink": true } }
    ]
    
  • Modifier une contrainte dans une lib du mono → re-run composer update Ă  la racine.

🔒 Le rîle central de composer.lock

  • Le lock fige TOUT l’arbre (versions exactes + URLs).

  • Toujours committer composer.lock (pour les apps).

  • Conflits de merge volontaires (hash) → reset sur main, relancer la commande d’update exacte.

    • Astuce : collez la commande composer update 
 dans le message de commit PR.

🚀 DĂ©ploiement fiable (pipeline type)

  1. CI : composer install --no-dev --prefer-dist --no-interaction --no-progress
  2. composer check-platform-reqs (ou durant le build d’image)
  3. Dump autoload optimisé : composer dump-autoload -o
  4. Build artefact (archive / image Docker) incluant vendor/
  5. DĂ©ployer l’artefact (zĂ©ro update en prod) → mĂȘme code partout, pas de surprises.

⚡ Caching qui marche (CI)

  • Cachez le cache Composer (~/.composer/cache) et (optionnel) vendor/ :

    • Le cache Composer s’accumule (idĂ©al multi-branches/multi-jobs).
    • vendor/ court-circuite la dĂ©compression si l’état n’a pas bougĂ©.
    • En Docker, exploitez les layers et invalidez sur changement de composer.lock.

📝 Check-list “Composer 2025”

  • [ ] Composer 2 partout (+ API v2 de Packagist).

  • [ ] composer audit en CI + alerting sĂ©cu hors cycle d’update.

  • [ ] roave/security-advisories pour bloquer les versions vulnĂ©rables.

  • [ ] Repo Composer privĂ© pour fiabiliser les artefacts.

  • [ ] Updates frĂ©quentes (Renovate/Dependabot/Conductor), petites et rĂ©guliĂšres.

  • [ ] --minimal-changes, --patch-only, --bump dans votre routine.

  • [ ] Commit composer.lock et documenter les commandes d’update.

  • [ ] Caching cache Composer (+ vendor/ selon contexte).

  • [ ] Ne retaguez pas ; publiez une nouvelle version.

  • [ ] Soutenez vos dĂ©pendances (composer fund).

  • Étendre le serveur web Caddy avec ton langage prĂ©fĂ©rĂ© – Sylvain Combraque PrĂ©sentation des possibilitĂ©s d’extension de Caddy pour intĂ©grer des fonctionnalitĂ©s personnalisĂ©es directement dans le serveur.

  • Growing the PHP Core — One Test at a Time – Florian Engelhardt Un plaidoyer pour contribuer au langage via des tests unitaires ciblĂ©s. Chaque test compte pour renforcer PHP.

Devenir contributeur PHP
 en écrivant des tests

(et un peu d’histoire de 1993 à aujourd’hui)

👋 Introduction

Bonjour, je m’appelle Florian. Je travaille dans l’équipe Profiler chez Datadog, oĂč je construis un profiler continu pour PHP. Je contribue aussi Ă  l’open source : noyau PHP, PHPUnit, GraphQLite
 et je co-maintiens l’extension parallel (multithreading en PHP). Je fais tout ça
 en Ă©tant mariĂ© et papa de 5 enfants. MoralitĂ© : on trouve toujours un peu de temps pour contribuer 😉

🧒 PrĂ©-histoire perso

  • 1993 : premier PC (IBM PS/2, 286) + un livre “GW-Basic pour grands dĂ©butants” → premiers pas en code.
  • 1995 : je dĂ©couvre Internet, HTML/CSS/JS/Perl. On dĂ©ploie en FTP + F5.
  • 2000 : je rejoins une agence web en Allemagne. Deux Ă©quipes : JSP et PHP. On me met cĂŽtĂ© PHP. On me montre echo 1+1 → F5 → 2. Je rĂ©ponds : « Personne n’utilisera jamais ça. » 😅 Puis on me montre MySQL, du vrai code, des projets rĂ©els
 et je comprends enfin ce que fait un ingĂ©nieur logiciel toute la journĂ©e.

🧭 Pourquoi ce talk

En 25 ans de carriĂšre, PHP m’a tout donnĂ©. Je voulais redonner Ă  la communautĂ©, mais sans commencer par Ă©crire du C ou une RFC. J’ai dĂ©couvert PHP TestFest (Ă©dition 2017) : l’idĂ©e est simple — Ă©crire des tests pour PHP. Parfait pour apprendre le codebase et contribuer tout de suite.

🔧 Construire PHP & lancer la suite de tests

Compiler depuis les sources

git clone https://github.com/php/php-src.git
cd php-src
./buildconf
./configure
make -j$(nproc)
sapi/cli/php -v    # vérifie : PHP 8.x-dev

Exécuter les tests (en parallÚle)

# Depuis la racine du repo
make test          # séquentiel
# ou
php run-tests.php -j10
  • 18k+ tests, pass/skip/fail clairement listĂ©s.
  • Beaucoup de skip si des extensions ne sont pas compilĂ©es.
  • Rapport final avec stats et Ă©ventuels fails (Ă  investiguer).

đŸ§Ș PHPT : le format de test de PHP

Un test est un fichier .phpt en sections :

  • --TEST-- titre court (+ --DESCRIPTION-- si besoin)
  • --EXTENSIONS-- dĂ©pendances (ex : zlib)
  • --SKIPIF-- logique de skip (OS, rĂ©seau, etc.)
  • --FILE-- code PHP testĂ© (souvent var_dump)
  • --EXPECT-- sortie attendue
  • --CLEAN-- mĂ©nage (isolĂ© du --FILE--)

Tips : chaque section s’exĂ©cute en isolation → pas de variables partagĂ©es.

đŸ§© Exemple rĂ©el : tester zlib_get_coding_type()

Contexte

  • PHP peut compresser la sortie automatiquement si zlib.output_compression=On et le client envoie Accept-Encoding.

  • La fonction zlib_get_coding_type() renvoie :

    • false si pas de compression,
    • "gzip" / "deflate" selon l’algorithme que PHP utilisera.

Idées de cas à tester

  1. Pas d’Accept-Encoding → false
  2. Accept-Encoding: gzip + compression Off → false
  3. Accept-Encoding: gzip + compression On → "gzip"

Les piĂšges rencontrĂ©s (et ce qu’ils apprennent)

  1. Headers déjà envoyés

    • Si on affiche quelque chose avant de changer l’INI, PHP envoie les entĂȘtes → on ne peut plus changer la compression.
    • Solution : bufferiser les sorties (stocker dans une variable, ne pas echo trop tĂŽt).
  2. Superglobales copy-on-write

    • Modifier $_SERVER['HTTP_ACCEPT_ENCODING'] en userland ne modifie pas la valeur interne utilisĂ©e par le moteur.
    • Solution : utiliser la section --ENV-- du .phpt pour injecter HTTP_ACCEPT_ENCODING=gzip au dĂ©marrage du process de test.
  3. Attention Ă  la sortie

    • Avec compression active, la sortie devient
 binaire gzip.
    • Solution : capturer, changer l’INI, puis Ă©mettre la sortie attendue claire pour l’--EXPECT--.

RĂ©sultat : test final robuste, intĂ©grĂ© (Ă  l’époque PHP 7.3), et couverture gagnĂ©e sur des branches non testĂ©es.

🎁 Ce que j’ai appris en chemin

  • Les superglobales ($_SERVER, $_GET, $_POST
) sont copy-on-write → l’original interne reste immuable.
  • ini_set() n’est pas “magique” : aprĂšs envoi des entĂȘtes, il est parfois trop tard pour changer un comportement qui devait ĂȘtre dĂ©clarĂ© dans la rĂ©ponse HTTP.
  • Il existe des trĂ©sors cachĂ©s : en fouillant la couverture, j’ai (re)dĂ©couvert ZipArchive, etc.
  • Le format PHPT n’est pas rĂ©servĂ© au core : PHPUnit sait aussi les exĂ©cuter — utile pour tester un SAPI/CLI ou un binaire.

🚀 Pourquoi vous devriez Ă©crire des tests pour PHP

  • Vous stabilisez l’écosystĂšme pour tous.
  • Vous apprenez le moteur pas Ă  pas, sans Ă©crire une seule ligne de C.
  • Vous devenez
 contributeur·rice PHP (et ça, c’est classe ✹).

Par oĂč commencer (checklist 5 minutes)

  1. Fork php-src, buildconf && configure && make.
  2. php run-tests.php -j8 pour un premier run.
  3. Ouvrez Codecov/couverture → repĂ©rez du rouge simple (switch/return).
  4. Écrivez 1 .phpt : --ENV--, --EXTENSIONS--, --FILE--, --EXPECT--.
  5. make test TESTS=path/to/your-test.phpt.
  6. PR petite, ciblĂ©e, explications claires → merge plus facile.

đŸ§‘â€đŸ’» Mot de la fin

On ne fait pas ça parce que c’est facile, on le fait parce qu’on croit que ça va ĂȘtre facile
 et on apprend en route. Merci — et si vous avez des questions, je suis lĂ  !

  • MongoDB : Demandez-en plus Ă  votre base de donnĂ©es – JĂ©rĂŽme Tamarelle Tour d’horizon des fonctionnalitĂ©s avancĂ©es de MongoDB (agrĂ©gations, requĂȘtes complexes) dans un contexte API.

đŸ§‘â€đŸ’» FrankenPHP Ă  l’honneur

  • Comment Clever Cloud a repensĂ© sa maniĂšre de dĂ©ployer des applications PHP avec FrankenPHP – Steven Le Roux & David Legrand Retour d’expĂ©rience sur l’intĂ©gration de FrankenPHP dans un PaaS. Gains en efficacitĂ©, simplicitĂ© et performances.

  • FrankenPHP en production, migration d’un site e-commerce – LoĂŻc Caillieux Cas rĂ©el de migration d’un projet vers FrankenPHP. DonnĂ©es chiffrĂ©es sur les performances et retour sur la stabilitĂ©.

💡 Autres talks marquants

  • Mercure, SSE, API Platform et un LLM Ă©lĂšvent un chat(bot) – Mathieu Santostefano ExpĂ©rimentation d’un chatbot en temps rĂ©el avec Mercure et API Platform, enrichi par un LLM.

  • How API Platform 4.2 is Redefining API Development – Antoine Bluchet (Soyuka) PrĂ©sentation en dĂ©tail des nouveautĂ©s de la 4.2 : nouveaux filtres, amĂ©liorations DX, meilleure scalabilitĂ©.

🎉 10 ans d’API Platform & sortie de la 4.2 (live on stage)

« La release part juste aprĂšs le talk — le Wi-Fi me joue des tours. » — Antoine

🚩 RĂ©tro 4.0 → 4.2

  • ~600 commits, ~200 000 lignes modifiĂ©es ; ~300 issues ouvertes dont 2/3 closes.
  • Merci Ă  Les-Tilleuls.coop pour le sponsoring temps plein d’Antoine.

đŸ§© MĂ©tadonnĂ©es : dĂ©clarer & modifier plus simplement

  • Nouvelle dĂ©claration en PHP (en plus des attributs/YAML), portĂ©e depuis Symfony.
  • Mutateurs ciblĂ©s : AsResourceMutator / AsOperationMutator (+ interface OperationMutator) pour ajuster une opĂ©ration/un resource sans usine Ă  gaz (pratique pour le Serious Bundle).

🔎 Filtres, enfin dĂ©couplĂ©s (doc ↔ transformation ↔ validation ↔ SQL)

Historiquement, un filtre mélangeait description, stratégie SQL, etc. En 4.2, on sépare les responsabilités :

  • Documentation :

    • JsonSchemaFilterInterface — dĂ©clare le schema d’un paramĂštre (type infĂ©rĂ© → coercition/validation automatique cĂŽtĂ© PHP).
    • OpenApiParameterFilterInterface — paramĂštres OpenAPI (peut surcharger le JSON Schema).
  • Filtrage : interfaces de stockage inchangĂ©es (ORM/ODM/ES
).

    • Les filtres deviennent de simples callbacks, sans DI, qui reçoivent des paramĂštres typĂ©s.

🧭 ParamĂštres HTTP unifiĂ©s

  • Nouveaux attributs Parameter (query) & HeaderParameter (header) avec options avancĂ©es (type, tableau, formats, coercition
).
  • On dĂ©clare les paramĂštres sur l’opĂ©ration, indĂ©pendants des propriĂ©tĂ©s d’entitĂ©.
  • Free-text query q= (façon Hydra) out-of-the-box.
  • Filtres composites possibles, fermant de trĂšs vieux tickets historiques.

🔗 Paramùtres de chemin “intelligents”

  • Link extends Parameter + provider dĂ©diĂ© pour rĂ©soudre une ressource liĂ©e (ex. company injectĂ©e comme entitĂ© prĂȘte Ă  l’emploi dans le provider).

📜 OpenAPI & JSON Schema : plus lĂ©ger, plus propre

  • Mutualisation des schĂ©mas : un schema de base + enrichissements (JSON-LD, JSON API, 
) par $ref → −30 % de taille sur de grosses specs, moins d’I/O.
  • ⚠ Si vous testiez la forme exacte des schĂ©mas, attendez des diffs (la validation fonctionnelle reste identique).
  • Nouveau validateur plus strict/Ă  jour ; nombreuses incohĂ©rences corrigĂ©es.

⚡ Performances : FrankenPHP en worker mode, chiffres à l’appui

  • Bench NGINX/PHP-FPM vs FrankenPHP (config “sweet spot” optimisĂ©e).
  • Sans worker : Ă©quivalent. Avec worker : +RPS, latence Ă·2 sur page Sylius.
  • Message clĂ© : activez le worker mode. (Et allez chambrer ceux qui ne l’ont pas fait 😉)

đŸ§± State Options : liens et sous-ressources
 sans douleur

  • Pour des sous-ressources spĂ©cifiques, un callback dĂ©diĂ© donne un WHERE clair et Ă©vite les gros graphes automatiques.

  • Entity-class magic modernisĂ© avec Symfony ObjectMapper :

    • Votre API shape n’a plus Ă  Ă©pouser l’entitĂ© Doctrine.
    • On annote avec #[Map] pour dĂ©crire les correspondances (ex. firstName+lastName → username).
    • Mapping bidirectionnel propre et maintenable.

🛒 Cas rĂ©el (Sylius + JSON-LD / schema.org)

  • Exposer une fiche produit conforme schema.org en JSON-LD alors que l’entitĂ© Sylius ne matche pas.
  • Provider qui lit Sylius → ObjectMapper qui remappe → Serializer qui Ă©met le JSON-LD.
  • Retour du profiler API Platform (content-negotiation, provider, serializer, etc.) pour voir oĂč part le temps (souvent la sĂ©rialisation).

đŸ§” JSON Streamer intĂ©grĂ© : sĂ©rialiser plus vite les gros payloads

  • IntĂ©gration du Symfony JSON Streamer (+ TypeInfo) pour JSON et JSON-LD.

  • Principe : schĂ©ma prĂ©-calculĂ©, Ă©criture en streaming caractĂšre par caractĂšre.

  • Gains mesurĂ©s : jusqu’à +32 % RPS dans les tests d’Antoine (plus l’objet est gros, plus ça gagne).

  • Activation : option d’outil json_stream: true.

    • ⚠ Exige des propriĂ©tĂ©s publiques (sinon, restez sur le Serializer classique).
    • Pour creuser : talk dĂ©diĂ© de Mathias Arlaud.

🧡 Laravel : couverture fonctionnelle en flùche

  • Depuis l’intro l’an dernier : ~124 PR & ~100 issues traitĂ©es.
  • 80–90 % des features API Platform dĂ©sormais opĂ©rationnelles cĂŽtĂ© Laravel (dont HTTP cache).
  • Merci aux top contributors Laravel. Et dĂ©ploiement sur Laravel Cloud prĂ©sentĂ© par Joe Dixon.

đŸ§Ș DisponibilitĂ© & compatibilitĂ©

  • 4.2 : release juste aprĂšs le talk (une bĂȘta existe).
  • Breaking change principal : forme des JSON Schemas (pas le fond).
  • Defaults OpenAPI ajustĂ©s (peu de risque d’impact).
  • ParamĂštres : ne sont plus expĂ©rimentaux — adoptez-les.

đŸ›Łïž Roadmap vers 5.0

  • DĂ©prĂ©cier #[ApiFilter] au profit du systĂšme de paramĂštres (migration assistĂ©e : script & compat conservĂ©e longtemps).
  • Étendre le JSON Streamer Ă  d’autres formats ; retours & tests bienvenus.
  • Poursuivre la maturation ObjectMapper (Symfony) via usages concrets dans l’écosystĂšme.

✋ À retenir (version TL;DR)

  • ParamĂštres unifiĂ©s (typĂ©s, documentĂ©s) + filtres dĂ©couplĂ©s ⇒ DX et prĂ©cision.

  • OpenAPI plus lĂ©ger et strict.

  • FrankenPHP (worker) ⇒ vrai boost perfs.

  • ObjectMapper ⇒ API propre mĂȘme si vos entitĂ©s ne le sont pas.

  • JSON Streamer ⇒ gros payloads plus rapides.

  • Laravel : ça y est, on y est (presque) feature-par-feature.

  • How Laravel Cloud Uses FrankenPHP in Production – Florian Beer Focus sur la synergie entre Laravel Cloud et FrankenPHP.

🚀 Contexte

Florian Beer (Ă©quipe infra Laravel Cloud) a expliquĂ© comment la plateforme zero-ops lancĂ©e en fĂ©vrier permet de dĂ©ployer une app Laravel « en une minute » (connexion GitHub/GitLab/Bitbucket → Deploy → URL publique). L’objectif : aucune gestion d’infra cĂŽtĂ© client (servers, containers, scaling, rĂ©seau
 tout est gĂ©rĂ©).

⚙ Octane, l’exĂ©cution longue durĂ©e

  • Sans Octane : Laravel tourne sur PHP-FPM, l’application boote Ă  chaque requĂȘte.
  • Avec Octane : l’app boote une fois et reste en mĂ©moire ; les requĂȘtes sont servies par un worker longue durĂ©e.
  • Octane supporte plusieurs serveurs ; Laravel Cloud a choisi FrankenPHP.

đŸ§© Pourquoi FrankenPHP ?

FrankenPHP (sur base Caddy) apporte :

  • HTTP/2 & HTTP/3, Early Hints, TLS auto,
  • un worker mode performant,
  • une intĂ©gration simple dans l’écosystĂšme Laravel/Octane.

En pratique sur Laravel Cloud, activer Octane = basculer sur FrankenPHP (et revenir sur PHP-FPM si besoin).

🎬 DĂ©mo live (pas Ă  pas)

  1. CrĂ©ation d’une app via template sur Laravel Cloud (rĂ©gion Frankfurt).
  2. DĂ©ploiement initial → app accessible en PHP-FPM.
  3. composer require laravel/octane, ajout d’une route « runtime » pour exposer l’info d’exĂ©cution.
  4. Push → auto-deploy (build container, publish).
  5. Flip the switch : activer Octane dans l’interface → redeploy.
  6. La route « runtime » montre désormais FrankenPHP comme runtime.

💡 Avertissement : en mode workers, surveiller les fuites mĂ©moire cĂŽtĂ© code applicatif (responsabilitĂ© client). La plateforme facilite l’activation mais ne « garbage-collecte » pas votre logique mĂ©tier.

đŸ—ïž Sous le capot de Laravel Cloud

  • La plateforme maintient deux familles d’images Docker :

    • PHP-FPM (classique),
    • FrankenPHP (Octane).
  • Le pipeline prend votre repo, build l’image, la pousse et attache le service au rĂ©seau public.

đŸ€ Perf & collaboration

  • Collaboration directe avec KĂ©vin Dunglas pour optimiser FrankenPHP sur une large variĂ©tĂ© de workloads (du side-project au SaaS Ă  fort trafic).
  • RĂ©sultat : gains sensibles de performance dĂ©jĂ  observĂ©s cĂŽtĂ© clients.

✅ Enjeux & bonnes pratiques

  • Quand basculer sur Octane/FrankenPHP ?

    • I/O intensif, latence critique, endpoints chauds, Web/API trĂšs frĂ©quentĂ©s.
  • Points d’attention :

    • État global & singletons (bien rĂ©-initialiser entre requĂȘtes),
    • Connexions (DB, cache) gĂ©rĂ©es proprement dans le cycle de vie worker,
    • ObservabilitĂ© (metrics, memory usage par worker).

🧭 Message clĂ©

Sur Laravel Cloud, Octane + FrankenPHP s’active en un clic. Vous conservez la simplicitĂ© du zero-ops, tout en profitant du runtime moderne et du worker mode pour des perfs au rendez-vous.

  • Help! My Tech Skills Have an Expiration Date – Helvira Goma RĂ©flexion sur l’obsolescence rapide des compĂ©tences et comment rester pertinent dans un secteur en mutation constante.

đŸŽ€ Jour 2 – 19 septembre

🔑 Keynotes

  • Nicolas Grekas : Ă©tat de Symfony, nouvelles features et feuille de route.
  • Fabien Potencier : vision long terme de Symfony et mise en avant des composants liĂ©s Ă  l’IA.

1) Pourquoi ce talk ?

  • Le monde de l’IA bouge si vite que ce que je dis aujourd’hui sera peut-ĂȘtre obsolĂšte demain.
  • Objectif : comprendre comment les LLMs et les agents changent notre façon de concevoir des APIs.

Qui ici utilise un LLM pour coder (presque) tous les jours ? Qui n’a jamais appelĂ© une API ? Essayez 😉

2) C’est quoi un “agent” ?

  • DĂ©finition (Anthropic, rĂ©sumĂ©e) : un modĂšle qui utilise des outils en boucle.
  • SchĂ©ma mental : Prompt → choisit un outil → observe → rĂ©-itĂšre → produit un rĂ©sultat.
  • Outils possibles : navigateur web, SDK/API, exĂ©cutable local, fonction maison

  • Important : Ă  la fois “humain” et “machine” : planifie, a de la mĂ©moire, prend des initiatives, mais reste un programme.

3) 30 ans d’interfaces : du site web à l’agent

  • AnnĂ©es 90 : sites pour humains (HTML pur, puis CSS/JS).

  • CLI : pour devs/ops.

  • APIs : machine-to-machine (mashups !), internes ou publiques, avec attentes d’exhaustivitĂ© et de dĂ©terminisme.

  • NouveautĂ© : les agents interagissent avec tout :

    • Websites (scraping / browsing tool),
    • CLI (via MCP servers),
    • APIs (via SDKs ou HTTP direct).

4) APIs actuelles : parfaites pour des programmes, pas pour des agents

  • Inputs/outputs stricts (OpenAPI/JSON), erreurs via HTTP status (400, 422, 429
).
  • Pour des applis dĂ©terministes, c’est parfait : en cas d’erreur
 un humain corrige le code.
  • Mais un agent doit s’auto-rĂ©tablir : il lui faut des pistes d’action, pas juste “400 Bad Request”.

5) Quand un agent se cogne Ă  vos erreurs

  • 400 / 422 / 429 : l’agent voit le code
 et devine (parfois mal) : champ manquant ? mauvais format ? rĂ©essayer plus tard ?
  • Mauvaise boucle : il tente, Ă©choue, googlise, relit la doc, retente
 → lent, coĂ»teux, non dĂ©terministe.
  • Pire : beaucoup de SDKs (ex. en Python) ne renvoient que le status code par dĂ©faut → le corps d’erreur dĂ©taillĂ© est perdu.

6) Faire des erreurs
 des conseils d’action

  • Dans la rĂ©ponse (pas seulement le code) :

    • titre du problĂšme + dĂ©tail exploitable,
    • lien vers une page spĂ©cifique (pas la doc racine),
    • proposition concrĂšte : “le champ date doit ĂȘtre au format YYYY-MM-DD”, “quantity ≀ 100”, “cet endpoint est dĂ©prĂ©ciĂ©, utilisez /orgs/{id}/projects”.
  • BĂ©nĂ©fices : moins d’itĂ©rations, moins de tokens, moins de coĂ»t, moins d’hallucinations.

Symfony supporte depuis longtemps la structuration d’erreurs (problùme JSON) : profitez-en pour standardiser vos payloads d’erreur.

7) Cohérence > intelligence

  • Les LLMs adorent la prĂ©dictibilitĂ© : choisissez un style et tenez-vous-y.

    • user_id partout (pas userId ici et author_id ailleurs).
    • Champs, noms d’URLs, formats : constance.
  • Sinon l’agent “devine”
 et se trompe.

8) Documentation “AX” (Agent eXperience)

  • UnifiĂ©e, Ă  jour, centralisĂ©e : Ă©vitez les pages pĂ©rimĂ©es et les exemples faux (les LLMs les recopient).

  • Pistes :

    • LLMS.txt (inventaire destinĂ© aux LLMs),
    • chaque page consultable en Markdown (les LLMs lisent le MD trĂšs bien),
    • guides de parcours (ex. “acheter un produit” : auth → panier → adresse → paiement),
    • documentez les erreurs possibles par endpoint, comment les rĂ©soudre, et fournissez des exemples corrects.

Un mauvais exemple dans le contexte peut “contaminer” les rĂ©ponses d’un LLM pendant des heures.

9) Minimisiez les allers-retours avec l’agent

  • Un call API : 10–100 ms ; un appel LLM : secondes.
  • Moins de tours = plus rapide, moins cher, plus stable.
  • IdĂ©e : exposez en plus de vos endpoints bas niveau quelques endpoints haut niveau orientĂ©s tĂąche (“checkout”, “export complet”, “provisionner un projet”), pour Ă©viter 5 appels quand 1 suffit.

10) Tester
 l’indĂ©terministe

  • Les agents ne sont pas dĂ©terministes. Pourtant il faut des tests :

    • tempĂ©rature basse, limites de tentatives, prompts plus contraints,
    • mĂ©triques (taux de succĂšs, latence, coĂ»ts) et dashboards,
    • acceptez le “gris” (scĂ©narios suffisamment bons).

11) Les tokens : lĂ  oĂč la facture pique

  • La facturation est au token (pas au caractĂšre).

  • Impacts surprenants :

    • mots courts anglais = 1 token ; français/accents/Unicode = souvent plusieurs ;
    • UUIDs & IDs alĂ©atoires → tokenisĂ©s trĂšs cher ;
    • category_id peut ĂȘtre 1 token selon le tokenizer, DoneAt vs CompletedAt ne change pas toujours la donne.
  • JSON verbeux coĂ»te cher ; Markdown structurĂ© est souvent plus “lisible” pour le modĂšle et moins tokenisĂ©.

  • Contexte long ≠ prĂ©cision : plus le contexte grandit, plus l’agent se brouille. Segmenter ce que vous exposez aux agents (MCP, sous-APIs).

12) CrĂ©dentiels & sĂ©curitĂ© : ne laissez pas l’agent jouer avec le feu

  • Jamais de secret dans un prompt.
  • PrĂ©fĂ©rez un proxy outillĂ© (ex. MCP server) qui dĂ©tient les clĂ©s, fait les appels, restreint les permissions.
  • Donnez Ă  l’agent des tokens scope-Ă©s (lecture seule, pĂ©rimĂštre minimal).
  • Cas 429 (rate limit) : dites quoi faire (“Retry-After: 3”, backoff conseillĂ©, quota par minute
).

13) Quelques “recettes” que vous pouvez appliquer demain

  • Erreurs actionnables + liens spĂ©cifiques ; uniformiser status/corps.
  • Deprecation : signaler dans la rĂ©ponse ET la doc ; proposer l’alternative.
  • Endpoints macro (tĂąches) en plus des micro.
  • CohĂ©rence des noms et formats.
  • Doc centrale en Markdown, indexĂ©e (LLMS.txt).
  • Limiter la verbositĂ© JSON, Ă©viter IDs gigantesques ; paginez.
  • IntĂ©grer un MCP server pour exposer proprement vos outils/SDKs aux agents.

14) De DX/UX Ă  AX (Agent eXperience)

Nous avons beaucoup progressĂ© en DX et UX. La prochaine marche est l’AX : concevoir des APIs comprĂ©hensibles, actionnables et prĂ©visibles pour des clients
 qui raisonnent.

Ce que vous faites pour les agents profite aussi aux humains : meilleures erreurs, meilleure doc, moins de friction.

Conclusion

  • Les agents utilisent dĂ©jĂ  vos APIs.
  • Aidez-les : moins d’allers-retours, erreurs qui guident, cohĂ©rence, doc exploitable, sĂ©curitĂ© maĂźtrisĂ©e.
  • L’avenir des APIs, ce n’est pas seulement machine↔machine : c’est machine-qui-raisonne ↔ service bien conçu.

Merci 🙏 — questions bienvenues !

đŸ—ïž Architecture et REX

  • 2025, an API Platform Odyssey – James Seconde Un panorama des Ă©volutions passĂ©es et futures d’API Platform.

  • Deploying API Platform on Laravel Cloud – Joe Dixon Exemple concret d’intĂ©gration et de dĂ©ploiement d’API Platform dans une plateforme Laravel Cloud.

  • Headless & Ă©volutive : concevoir une application dĂ©couplĂ©e avec API Platform et Vue.js – Nathan de Pachtere DĂ©monstration d’un projet headless avec API Platform comme backend et Vue.js comme frontend.

  • Une API multi-tenant sans encombres avec API Platform, Symfony et PostgreSQL – Mehdi Zaidi StratĂ©gies techniques pour gĂ©rer plusieurs clients sur une seule instance API, en s’appuyant sur PostgreSQL.

đŸ› ïž Outils et bonnes pratiques

  • Rendez vos devs front heureux grĂące Ă  la RFC 7807 – ClĂ©ment Herreman Comment normaliser les erreurs d’API avec la RFC 7807 pour une meilleure DX cĂŽtĂ© frontend.

  • Symfony et l’Injection de DĂ©pendances : du passĂ© au futur – Imen Ezzine Un historique et une projection sur l’évolution de l’injection de dĂ©pendances dans Symfony.

  • SystĂšme de types et sous-typage en PHP – Gina Peter Banyard PrĂ©sentation thĂ©orique et pratique du systĂšme de types en PHP, avec une mise en perspective acadĂ©mique.

  • PIE: The Next Big Thing – Alexandre Daubois Un aperçu d’une nouvelle proposition technologique susceptible de changer la maniĂšre de travailler avec PHP.

Pi : l’outil qui rĂ©concilie PHP et ses extensions

Vers un « composer pour les extensions », soutenu par la PHP Foundation

TL;DR

Installer, mettre Ă  jour et dĂ©sinstaller des extensions PHP sans douleur, avec gestion des dĂ©pendances, signatures, dĂ©tection de versions de PHP, intĂ©gration Ă  composer.json
 C’est exactement ce que Pi apporte. PensĂ© et financĂ© par la PHP Foundation, Pi s’appuie sur l’écosystĂšme Packagist pour les mĂ©tadonnĂ©es, automatise l’édition du php.ini, supporte GitHub privĂ©, Windows, Linux et macOS — et vise Ă  remplacer les usages historiques autour de PECL/pickle.

Pourquoi un nouvel outil pour les extensions ?

Dans nos projets, installer une lib PHP est trivial (composer require 
). En revanche, installer une extension (Redis, MongoDB, Xdebug, PCOV, etc.) rime souvent avec :

  • dĂ©pendances systĂšme, ./configure && make && make install,
  • variations par OS/ABI/versions de PHP,
  • Ă©dition manuelle des fichiers INI,
  • cohĂ©rence fragile entre environnements CI/dev/prod.

Des initiatives ont tenté de lisser cette friction (PECL/pickle, Docker PHP Extension Installer), mais avec des limites : site lent et difficile à maintenir, absence de signatures généralisées, détection imparfaite des compatibilités PHP, couplage fort à Docker, etc.

Pi naĂźt de ce constat : apporter aux extensions l’expĂ©rience d’un Composer.

Pi en deux phrases

  • Ce que c’est : un gestionnaire d’extensions qui tĂ©lĂ©charge, construit (ou rĂ©cupĂšre des binaires quand c’est pertinent), installe et active automatiquement vos extensions PHP.
  • Ce que ça change : vous traitez vos extensions comme des dĂ©pendances de projet (mĂ©tadonnĂ©es Packagist, contraintes de version, intĂ©gration Ă  composer.json), mais avec l’intelligence nĂ©cessaire au monde des extensions (C/Rust/Go, compilation, DLL/SO, ABI, etc.).

Fonctionnalités clés

  • Installation simplifiĂ©e

    # Afficher ce qui est déjà installé par Pi
    pi show
    
    # Télécharger les sources en cache local
    pi download redis
    
    # Construire (configure/compile) selon votre plateforme
    pi build redis
    
    # Tout-en-un : download + build + installation + activation
    pi install redis
    
  • Mise Ă  jour automatique du php.ini Plus besoin d’ajouter Ă  la main extension=
 : Pi active l’extension dans la bonne configuration.

  • CompatibilitĂ©s intelligentes (PHP/OS/arch) Les auteurs d’extensions peuvent restreindre la compatibilitĂ© OS et dĂ©clarer les bornes min/max de PHP ; Pi bloque proprement ce qui ne correspond pas.

  • Signatures et vĂ©rifications Pi sait consommer les artefacts signĂ©s (ex. GitHub Releases) et vĂ©rifier l’intĂ©gritĂ© avant installation.

  • PrivĂ© & monorepo-friendly Ajoutez des repositories comme pour Composer : VCS, chemin local, Private Packagist, etc. — idĂ©al pour des extensions privĂ©es.

    pi repo add my-ext vcs https://github.com/acme/php-ext-foo.git
    
  • Lecture de composer.json Un simple pi install dans votre projet permet Ă  Pi de scanner votre composer.json (ex : require: { "ext-redis": "*" }) et d’installer toutes les extensions manquantes. đŸȘ„

  • DĂ©sinstallation propre

    pi uninstall xdebug
    
  • Support multi-PHP Installez pour un binaire PHP spĂ©cifique (utile en CI multi-matrices) :

    pi install pcov --with-php-path=/usr/bin/php8.3
    
  • Windows first-class Sur Windows, Pi rĂ©cupĂšre des DLL prĂ©compilĂ©es quand disponibles ; sur Linux/macOS, Pi compile par dĂ©faut (classique et fiable).

  • IntĂ©gration Symfony CLI Les habituĂ©s peuvent piloter Pi via :

    symfony pi install xdebug
    

OĂč sont les « packages » d’extensions ?

Pi s’appuie sur Packagist pour indexer les mĂ©tadonnĂ©es (nom, version, contraintes PHP/OS, sources, signatures, etc.). Les extensions compatibles Pi sont publiĂ©es sous un vendor dĂ©diĂ© (ex. packagist.org/extensions/...) ou via vos propres dĂ©pĂŽts. 👉 ConsĂ©quence : mĂȘmes rĂ©flexes que Composer (versionnage sĂ©mantique, ranges, dĂ©pĂŽts privĂ©s).

Flux de travail type (développeur & CI)

  1. Déclarer vos besoins (dans le README et/ou via composer.json : ext-
).

  2. Développeur

    pi install         # installe toutes les extensions demandées par le projet
    php -m | grep redis
    
  3. CI

    • Cachez le cache Pi et les artefacts de build pour accĂ©lĂ©rer.
    • Matrice OS × PHP : Pi gĂšre les diffĂ©rences de build et d’activation.
    • Évitez les apt-get/brew spĂ©cifiques Ă  chaque pipeline : Pi centralise.

Comparaisons rapides

| Besoin | PECL/pickle | Docker Ext Installer | Pi | | ------------------------------- | ----------- | -------------------- | -------------------------------- | | Installation locale sans Docker | Moyenne | Non | Oui | | Détection versions PHP/OS | Partielle | N/A (Docker) | Oui (métadonnées) | | Signatures & vérification | HétérogÚne | N/A | Oui | | Activation auto (php.ini) | Non | N/A | Oui | | DépÎts privés | Compliqué | Non | Oui (VCS, Private Packagist) | | Lecture composer.json | Non | Non | Oui | | Windows | Variable | Non | Oui (DLL) |

FAQ express

Existe-t-il un .lock par projet comme Composer ? Non. Une extension s’installe au niveau du systĂšme/du binaire PHP. Pi trace ce qu’il gĂšre (pi show) et respecte la version de PHP cible (--with-php-path). La reproductibilitĂ© se fait au niveau CI (matrice/os/versions) et via vos constraints.

Puis-je utiliser Pi avec des sources privĂ©es GitHub ? Oui : Pi lit GH_TOKEN et authentifie les tĂ©lĂ©chargements d’artefacts privĂ©s.

Des binaires précompilés sous Linux/macOS ? Par défaut non (compilation locale = robustesse ABI), mais oui sous Windows (DLL).

Pi remplace-t-il officiellement PECL/pickle ? Le processus d’adoption passe par RFC/vote cĂŽtĂ© PHP ; la direction prise vise Ă  recommander Pi comme voie privilĂ©giĂ©e. Dans tous les cas, vous pouvez l’utiliser dĂšs maintenant.

Bonnes pratiques à adopter dùs aujourd’hui

  • DĂ©clarez vos extensions dans composer.json ("ext-redis": "*"), et documentez les versions de PHP supportĂ©es.
  • Standardisez vos pipelines CI autour de pi install (plutĂŽt que des scripts OS-spĂ©cifiques).
  • Publiez des mĂ©tadonnĂ©es complĂštes cĂŽtĂ© extension : contraintes PHP/OS, signatures, instructions build.
  • Cachez le cache Pi en CI et fixez les versions d’extensions en prod (via tags stables).

Conclusion

Pi apporte enfin aux extensions PHP l’ergonomie et la fiabilitĂ© que Composer a offertes aux librairies : un workflow unifiĂ©, reproductible, scriptable, multi-plateforme — et taillĂ© pour les rĂ©alitĂ©s modernes (monorepos, privĂ©, CI, Windows).

Si vous avez dĂ©jĂ  dit « non » Ă  une extension parce que son installation semblait risquĂ©e ou chronophage
 rĂ©essayez avec Pi. Vous risquez surtout d’y prendre goĂ»t. 🚀

Annexes – aide-mĂ©moire des commandes

# Inventaire des extensions gérées par Pi
pi show

# Ajouter un dĂ©pĂŽt d’extension privĂ©
pi repo add my-ext vcs https://github.com/acme/php-ext-foo.git

# Télécharger les sources
pi download xdebug

# Construire selon l’OS/la version de PHP courante
pi build xdebug

# Installer et activer
pi install xdebug
pi install pcov --with-php-path=/usr/bin/php8.3

# Désinstaller
pi uninstall xdebug

🌍 SociĂ©tĂ©

  • OĂč sont passĂ©es les femmes de l’histoire de la tech ? 2.0 – Laura Durieux ConfĂ©rence inspirante mettant en lumiĂšre la place des femmes dans l’histoire et l’importance de l’inclusion dans la tech.

🎉 Clîture

Un discours fĂ©dĂ©rateur a conclu la confĂ©rence, mettant en avant l’importance de la communautĂ© et donnant rendez-vous pour l’édition 2026.

📌 Conclusion

Cette édition 2025 a été marquée par :

  • L’omniprĂ©sence de FrankenPHP, prĂ©sent dans la majoritĂ© des REX.
  • L’évolution rapide d’API Platform 4.2, tournĂ©e vers l’automation, la performance et le temps rĂ©el.
  • L’accent mis sur les bonnes pratiques : Composer, filtres API, gestion des erreurs, types.
  • Une communautĂ© qui continue d’innover, tout en portant des sujets humains et sociĂ©taux.

Un événement incontournable pour tout développeur qui souhaite rester à la pointe des technologies PHP et Symfony.

  • Plan du Site - Hello - Blog - Apps - Photos - Contact - - - - - Mentions lĂ©gales - Darkwood 2025, tous droits rĂ©servĂ©s