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. Voici un récapitulatif talk par talk, pour garder une trace complète des enseignements de l’événement.

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.

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.

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.

• 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.

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 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.

• 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.

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.

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.

• 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.

Voici une version claire, structurée et prête à prononcer du talk de Xavier Leune (FR). J’ai réorganisé le discours, clarifié les idées techniques, et gardé les démonstrations et conseils pratiques — tout en conservant le ton pédagogique.

(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.

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.

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.

É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.

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.

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.

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.

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.

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.

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.

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.

• 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.

• 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.

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.

• 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.

• 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.

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

• 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.

• 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.

• 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.

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";

• 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.

• 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.

• 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).

• 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.

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

• Compensating actions : on “annule” en avançant (ex. remboursement).

• Idempotence côté consommateur de webhooks aussi (déduplication par clé).

• 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.

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.

• 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.

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.

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

“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

• 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.

• 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.

• 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.

• 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.

• 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).

• 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 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.

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.

• 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.

• [ ] 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.

Voici une version claire et prête à prononcer du talk de Florian (FR), avec une trame qui colle à ce qu’il raconte, des passages “démo” synthétisés, et des punchlines mémorables.

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

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 😉

• 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.

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.

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

# 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).

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.

• 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.

1. Pas d’Accept-Encoding → false

2. Accept-Encoding: gzip + compression Off → false

3. Accept-Encoding: gzip + compression On → "gzip"

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.

• 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.

• 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 ✨).

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.

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.

• 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é.

• 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é.

Super, voici le compte rendu rédigé du talk d’Antoine Bluchet (Soyuka) — “API Platform 4.2”.

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

• ~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.

• 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).

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.

• 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.

• 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).

• 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.

• 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 😉)

• 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.

• 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).

• 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.

• 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.

• 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.

• 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.

• 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.

Tu veux que je te génère une check-list de migration 4.1 → 4.2 (paramètres, schemas, perf) + exemples d’annotations prêts à copier-coller ?

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

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é).

• 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.

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).

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.

• 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.

• 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.

• 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).

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.

• 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.

Voici une version prête à prononcer (avec titres de slides) du talk de Fabien Potencier sur “LLMs, agents et l’avenir des APIs”. J’ai gardé le ton pragmatique et les exemples concrets.

• 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 😉

• 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.

• 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).

• 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”.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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).

• 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).

• 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…).

• 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.

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.

• 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 !

• 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.

• 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.

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

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.

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.

• 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.).

• 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

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).

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.

| 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) |

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.

• 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).

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. 🚀

# 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

• 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.

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.

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.