đš 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 :
- Ouvrir la connexion aprĂšs le fork : chaque process a son propre socket/DB.
- 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
etyear:$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.
- Ordonner â
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
- Outbox (dans votre DB) : avant de âpublierâ, Ă©crivez un message en base dans la mĂȘme transaction que vos donnĂ©es mĂ©tier.
- Message bus (ex. Symfony Messenger avec transport Doctrine) lit lâoutbox aprĂšs commit, exĂ©cute lâeffet, marque succĂšs/Ă©chec.
- 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â
- DB = source de vérité. Invariants en base, contraintes, transactions.
- Cache : dépendances complÚtes, invalidations pilotées, post-commit only, tests de course.
- Side-effects : Outbox + Bus + Idempotence (+ compensations).
- Observabilité : métriques cache (hit/stale), délais outbox, taux de retry, dead-letter queues, audit trail.
- Résilience : timeouts, backoff, circuite breakers, bulkheads.
- Tests : de concurrence (race), chaos lĂ©ger (dĂ©sactiver un nĆud cache, injecter latence).
- Ne pas shard-er tant que dâautres leviers existent.
Appendice â Anti-patterns & remĂšdes
if ($isAdmin) { ⊠} if ($isCustomer) { ⊠}
â prĂ©fĂ©rerif ⊠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
(oucomposer bump
) : aligne vos contraintescomposer.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 dansvendor/
) :"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.
- Astuce : collez la commande
đ DĂ©ploiement fiable (pipeline type)
- CI :
composer install --no-dev --prefer-dist --no-interaction --no-progress
composer check-platform-reqs
(ou durant le build dâimage)- Dump autoload optimisĂ© :
composer dump-autoload -o
- Build artefact (archive / image Docker) incluant
vendor/
- 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é (souventvar_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 envoieAccept-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
- Pas dâ
Accept-Encoding
âfalse
Accept-Encoding: gzip
+ compression Off âfalse
Accept-Encoding: gzip
+ compression On â"gzip"
Les piĂšges rencontrĂ©s (et ce quâils apprennent)
-
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).
-
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 injecterHTTP_ACCEPT_ENCODING=gzip
au démarrage du process de test.
- Modifier
-
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)
- Fork
php-src
,buildconf && configure && make
. php run-tests.php -j8
pour un premier run.- Ouvrez Codecov/couverture â repĂ©rez du rouge simple (switch/return).
- Ăcrivez 1
.phpt
:--ENV--
,--EXTENSIONS--
,--FILE--
,--EXPECT--
. make test TESTS=path/to/your-test.phpt
.- 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
(+ interfaceOperationMutator
) 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)
- CrĂ©ation dâune app via template sur Laravel Cloud (rĂ©gion Frankfurt).
- DĂ©ploiement initial â app accessible en PHP-FPM.
composer require laravel/octane
, ajout dâune route « runtime » pour exposer lâinfo dâexĂ©cution.- Push â auto-deploy (build container, publish).
- Flip the switch : activer Octane dans lâinterface â redeploy.
- 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 formatYYYY-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 (pasuserId
ici etauthor_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
vsCompletedAt
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 mainextension=âŠ
: 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 simplepi install
dans votre projet permet Ă Pi de scanner votrecomposer.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)
-
Déclarer vos besoins (dans le README et/ou via
composer.json
:ext-âŠ
). -
Développeur
pi install # installe toutes les extensions demandées par le projet php -m | grep redis
-
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.