⭐️ Meetup AFUP Paris Décembre 2025

der 18. Dezember 2025

IMG_4123.jpg

Le mardi 16 décembre 2025, l’antenne AFUP Paris organisait son dernier meetup de l’année dans les locaux d’Algolia, au cœur du 8ᵉ arrondissement. Une soirée placée sous le signe de la simplicité architecturale et de la performance, avec deux conférences complémentaires : l’une centrée sur un framework PHP minimaliste, l’autre sur les enjeux concrets du cache dans des applications à fort trafic.

Un rendez-vous communautaire au cœur de l’écosystème PHP

Comme à son habitude, l’AFUP a réuni une communauté variée de développeurs et développeuses PHP : profils juniors, confirmés, architectes, freelances et salariés, venus échanger autour de pratiques terrain. L’événement, gratuit et ouvert à toutes et tous, a permis d’illustrer des problématiques très actuelles : choisir le bon niveau d’abstraction et tenir la charge quand le succès arrive plus vite que prévu.

Voici une version rédigée et structurée du contenu de l’article pour la présentation d’ouverture du meetup, fidèle au discours de Thomas, mais reformulée pour un article de blog clair, fluide et professionnel.

Introduction du meetup : actualités de l’AFUP et vie de la communauté

Par Thomas Durion.

Pour ouvrir ce dernier meetup AFUP Paris de l’année, Thomas D. a commencé par rappeler le rôle central de l’AFUP et partager les principales actualités de l’association, avant de présenter le programme de la soirée.

L’AFUP, pilier historique de l’écosystème PHP

Créée en 2001, l’AFUP (Association Française des Utilisateurs de PHP) œuvre depuis plus de vingt ans à la promotion de PHP et de son écosystème. L’association anime aujourd’hui une quinzaine d’antennes locales à travers toute la France, permettant aux membres de participer à des événements même lorsqu’ils sont en déplacement ou en vacances une manière conviviale de découvrir d’autres communautés locales.

À Paris, l’antenne organise un meetup par mois, hors période estivale, avec une ligne éditoriale volontairement large : PHP bien sûr, mais aussi bases de données, DevOps, agilité, architecture, et même front-end. Ces rencontres se prolongent systématiquement par un moment informel autour d’un apéritif, favorisant les échanges entre participants.

Une communauté ouverte et inclusive

Thomas a rappelé un point essentiel de l’ADN AFUP : tout le monde a quelque chose à partager, quel que soit son niveau d’expérience. L’association recherche en permanence :

  • des speakers, débutants ou confirmés,
  • des lieux pour accueillir les meetups,
  • des sponsors pour soutenir l’organisation (nourriture, boissons, logistique).

Pour accompagner celles et ceux qui souhaitent se lancer, l’AFUP propose plusieurs programmes de mentorat gratuits :

  • mentorat PHP,
  • mentorat pour le public speaking, destiné aux personnes qui souhaitent apprendre à présenter un sujet en conférence ou en meetup.

Les prochains rendez-vous AFUP

Plusieurs dates importantes ont été annoncées :

📅 Prochain meetup AFUP Paris

  • 8 janvier

  • Chez Believe, secteur Paris-Nord / Saint-Ouen

  • Introduction par Sophie Bopuy sur PHP chez Believe

  • Deux talks au programme :

    • intelligence artificielle
    • choix et conception d’architectures

🍻 Le Super Apéro AFUP

  • 11 mars
  • Événement national, organisé simultanément dans toutes les antennes AFUP
  • Les détails seront communiqués ultérieurement 👉 Pour rester informé : suivre l’antenne AFUP Paris sur Meetup et LinkedIn

Un Linktree est également disponible, regroupant :

  • les liens vers les réseaux,
  • un sondage permettant aux membres de proposer des thèmes ou formats de talks.

AFUP Day 2026 : une journée de conférences

Thomas a également évoqué l’AFUP Day, prévu le 22 mai, à :

  • Paris
  • Bordeaux
  • Lille
  • Lyon

Il s’agit d’une journée complète de conférences, avec un line-up déjà finalisé, qui sera dévoilé début janvier. Les dernières places à 65 € HT sont encore disponibles avant un changement de tarif. L’événement recherche également des sponsors, et un dossier dédié est disponible pour les entreprises intéressées.

Actualités PHP et standards

Côté technique, plusieurs points ont été mentionnés :

  • Versions PHP : La cible recommandée est PHP 8.5, avec une tolérance pour PHP 8.4. La page officielle de support PHP, avec son code couleur, reste un excellent outil pour sensibiliser les décideurs.

  • PSR Response Interrupt : Une proposition de standard concernant les réponses HTTP est actuellement ouverte à la public review. Les contributions sont bienvenues, notamment pour les mainteneurs de frameworks ou de bibliothèques.

  • Certification PHP : La Zend PHP Certification (ZCE) a été relancée par Perforce. Une certification exigeante, parfois débattue sur son utilité, mais qui reste un exercice intéressant pour approfondir ses connaissances.

Présentation de la soirée et remerciements

La soirée s’est ensuite orientée vers le programme technique :

  • “Slim, le framework léger” par Thierry Leriche-Dessirier
  • “Donne-moi du cache” par Axel Venet

Thomas a encouragé les participants à remplir le sondage AFUP afin d’orienter les futurs talks, puis a remercié Algolia pour l’accueil et la prise en charge de l’apéritif.

Un représentant d’Algolia a ensuite brièvement présenté l’entreprise : une plateforme de recherche privée et ultra-rapide, intégrable via API, avec des clients PHP, Symfony et Laravel, et a rappelé que les locaux sont ouverts à l’accueil d’autres communautés tech parisiennes.

Une soirée placée sous le signe du partage

Entre annonces communautaires, actualités techniques et conférences de fond, cette introduction a parfaitement posé le cadre : une communauté ouverte, tournée vers le partage, la montée en compétences et l’échange de pratiques, dans une ambiance conviviale et accessible.

Slim : un framework PHP léger et assumé

Présentation par Thierry Leriche-Dessirier

Thierry Leriche-Dessirier a ouvert son intervention par un retour d’expérience personnel : lorsqu’il a commencé en PHP, l’écosystème des frameworks lui paraissait à la fois foisonnant et déroutant. Comme beaucoup, il a d’abord fait “ce qu’il fallait faire” à l’époque : écrire son propre framework, adapté à ses besoins, sans forcément suivre l’évolution du marché.

Avec le temps, l’arrivée de frameworks devenus incontournables Symfony puis Laravel a rebattu les cartes. Thierry raconte qu’il a essayé de s’intéresser à Symfony il y a une dizaine d’années… mais que, pour son niveau PHP de l’époque, la marche lui a semblé trop haute. C’est dans ce contexte qu’il a cherché une alternative plus simple, plus accessible, et qu’il est tombé sur Slim.

Slim n’a rien d’un nouveau venu : le projet existe depuis 2010, ce qui en fait un outil mature, stabilisé et éprouvé.

Slim, c’est quoi exactement ?

Le message principal du talk est clair : Slim est un micro-framework au sens strict, et pour Thierry, Slim est même “presque uniquement” un routeur.

  • Slim s’occupe de mapper des routes à des handlers.
  • Il fournit une architecture légère, extensible via des middlewares.
  • Il s’intègre naturellement dans l’écosystème PSR (notamment PSR-7).

Cette sobriété volontaire a deux conséquences pratiques :

  1. La courbe d’apprentissage est courte (on “fait le tour” rapidement).
  2. Comme Slim fait peu de choses, il a eu le temps de les faire très bien et de manière relativement légère.

Présentation du speaker et cas d’usage réel

Thierry se présente comme un profil “multi-casquettes” (développement, conception, rédaction), travaillant dans plusieurs langages. Il assume également un positionnement intéressant : malgré ses années de pratique, il continue de se considérer débutant en PHP, et invite le public à venir challenger ses choix ou corriger ses éventuelles approximations.

Le talk n’est pas un cours exhaustif : Thierry annonce qu’il va surtout présenter la manière dont lui utilise Slim dans un projet concret : Profile 4, une application orientée communication interpersonnelle, qui repose justement sur Slim pour sa partie web.

Installer Slim : minimalisme, mais standards

L’installation se fait classiquement via Composer, avec une recommandation d’inclure dès le départ les dépendances liées à PSR-7 (et outils associés), car Slim s’appuie sur ces abstractions pour manipuler Request/Response de manière standard.

L’approche est volontairement pragmatique : on part d’un point d’entrée simple et on enrichit au besoin.

Le cœur de Slim : définir des routes

Le “Hello World” Slim ressemble à ce qu’on attend d’un micro-framework :

  • création de l’application via AppFactory
  • déclaration d’une route (GET, POST, etc.)
  • écriture du contenu dans la réponse
  • démarrage via run()

Thierry insiste sur un point : run() ne lance l’application qu’à la fin, ce qui rend l’architecture plus souple (et évite de “tout exécuter” trop tôt).

Slim supporte naturellement :

  • des routes plus complexes
  • des paramètres dans l’URL (type {name})
  • la nomination des routes, point essentiel pour éviter d’écrire des URLs en dur, notamment dans les redirections.

Mettre de l’ordre : séparer le bootstrap, les routes et les middlewares

Même si Slim permet de tout écrire dans un unique fichier, ce n’est pas un style viable dès qu’on dépasse le prototype.

Thierry propose une organisation simple et efficace :

  • index.php comme point d’entrée minimal
  • un boot.php pour orchestrer le démarrage
  • un fichier dédié aux routes
  • un fichier dédié aux middlewares
  • un espace dédié au container (pour les dépendances)

L’idée est de conserver Slim comme une “colonne vertébrale légère”, tout en structurant son application comme on le ferait sur un projet plus ambitieux.

Actions et contrôleurs : garder les handlers propres

Pour sortir du “tout en closure”, Thierry introduit deux patterns :

Les Actions

Une Action est une classe simple, généralement mono-responsabilité, avec une méthode __invoke() appelée automatiquement par Slim. C’est adapté aux pages “simples” (home, FAQ…) où il n’y a pas beaucoup d’interactions.

Les Contrôleurs

Dès qu’on gère plusieurs interactions autour d’un même domaine (par exemple un login), on passe plutôt sur un contrôleur avec plusieurs méthodes :

  • getLogin() pour afficher le formulaire
  • postLogin() pour traiter la soumission

Le mapping se fait au niveau de la route : on associe une URL à une méthode explicite du contrôleur. Thierry mentionne également un pattern très courant à factoriser côté contrôleur : Post / Redirect.

Groupes de routes et petite friction : le slash final

Slim permet de créer des groupes de routes (ex. tout ce qui commence par /user) afin d’appliquer des comportements communs (middlewares, règles, etc.).

Thierry souligne néanmoins une friction : la gestion “simple” de /user et /user/ (slash final) n’est pas, selon lui, triviale dans Slim. En pratique, il lui arrive de déclarer la route en double. Il invite d’ailleurs la communauté à partager une solution élégante si elle existe désormais.

Le container : injecter proprement des dépendances

Dès qu’on veut logger, templater, sécuriser, Slim devient intéressant via son container. Thierry montre un exemple typique : déclarer un logger (comme Monolog) dans le container, afin de pouvoir l’injecter dans :

  • actions
  • contrôleurs
  • middlewares

Point important : les entrées du container peuvent être instanciées à la demande (lazy-loading), ce qui évite de construire toute l’application et toutes ses dépendances à chaque requête “pour rien” un défaut qu’il attribue à ses propres frameworks “maison” d’autrefois.

Les middlewares : l’“oignon” Slim

Slim est très à l’aise avec les middlewares, qui permettent d’exécuter du code automatiquement autour d’une requête.

Thierry utilise une image parlante : les middlewares fonctionnent comme un oignon :

  • on empile des couches (middlewares) autour du cœur (l’application)
  • l’ordre d’exécution est inversé : le dernier middleware ajouté est le premier à s’exécuter
  • puis, après l’exécution du cœur, on “ressort” dans l’autre sens si le middleware continue après handle()

Il illustre plusieurs usages :

Middleware de log “before”

Un middleware simple, qu’il ajoute souvent au démarrage d’un projet, juste pour vérifier que la configuration fonctionne et tracer chaque passage.

Middleware pour enrichir le HTML (ex : CSP / meta / champs)

Il montre un exemple volontairement pédagogique : modifier le body pour prouver que la réponse est bien passée par là l’idée étant que ce mécanisme sert souvent à appliquer des règles globales (headers, sécurité, etc.) plutôt que de copier-coller sur chaque page.

Middleware d’authentification sur un groupe de routes

Cas classique : protéger toutes les routes d’un groupe (ex. /user/*) en vérifiant une session, et rediriger vers une route nommée login via le route parser, plutôt que de hardcoder une URL.

Templates : Twig comme couche de rendu

Slim n’impose pas de moteur de templates, mais s’intègre facilement avec plusieurs solutions. Thierry présente Twig comme choix personnel :

  • enregistrement du système de rendu dans le container (view, moteur Twig, dossier templates)
  • ajout du middleware dédié au rendering
  • utilisation dans les actions : rendre un template + passer un tableau de variables

Il mentionne également une bonne pratique : dans une vraie application, on factorise l’injection de variables communes (utilisateur, permissions, URL, thème…) plutôt que de les répéter.

Conclusion : Slim fait peu… mais le fait bien

Le talk se conclut sur un constat cohérent avec l’esprit du projet :

  • Slim est stable, mature, et n’évolue pas de manière “agressive” car il est déjà au bout de ce qu’on attend d’un routeur.
  • Il est compatible avec les versions modernes de PHP, et reste facile à prendre en main.
  • Il n’a pas vocation à gérer ORM, migrations, etc. : à vous de composer votre stack.

Thierry nuance toutefois : en 2025, certains arguments historiques en faveur de Slim (légèreté, modularité) sont moins exclusifs, car les frameworks full-stack (notamment Symfony) ont progressé sur leur modularisation et leurs modes “light”. Mais pour un besoin clair un routeur, une architecture middleware, un rendu template et une injection propre Slim reste un choix simple, direct et efficace.

“Donne-moi du cache” : quand la performance devient critique

Présentation par Axel Venet

La seconde conférence de la soirée a pris la forme d’un récit pédagogique : l’aventure de “Brice of Paris”, entrepreneur passionné de glisse… mais installé à Paris. Surf et neige étant compliqués à monétiser sur place, Brice lance une activité de location de planches de paddle sur la Seine. Au départ, le trafic est faible. Puis la situation change brutalement : succès inattendu, afflux massif de visiteurs… et une question inévitable :

Est-ce que le site va tenir la charge ?

Pour répondre, Axel propose un chemin en plusieurs étapes, du plus bas niveau (PHP) au plus haut (HTTP), puis une conclusion essentielle : le cache n’est pas un “truc à activer”, c’est une démarche.

Le scénario : “Brice of Paris” et un site qui explose

Brice demande à un ami de lui développer un site “comme tous les clients” :

  • accessible, responsive,
  • performant et SEO-friendly,
  • pas cher,
  • et livré vite.

Le site existe : pages produits, prix, promotions… et surtout quelques calculs métier (ex : prix ajusté selon l’état des planches, réductions, etc.). Tant que le trafic est faible, tout va bien.

Mais quand “Paris devient une station balnéaire” (clin d’œil narratif), la charge grimpe. Et c’est exactement là que les problèmes apparaissent : latence, requêtes lourdes, ressources limitées, et parfois des temps de réponse qui se dégradent de façon spectaculaire.

Le terrain de jeu : un benchmark local, mais réaliste

Axel a construit une démo testable en local, pour simuler une montée en charge de manière reproductible :

  • Docker pour isoler l’environnement
  • Caddy (web server)
  • PHP-FPM (choix volontairement classique)
  • PostgreSQL
  • Symfony 7.4, PHP 8.4
  • Doctrine (ORM)
  • K6 pour les tests de charge (script en JavaScript)
  • Prometheus + Grafana pour visualiser les métriques

Point important : pour rendre les résultats parlants, le container PHP-FPM est volontairement limité à 1 CPU et 512 MB RAM. Une contrainte qui met immédiatement en évidence les limites… et l’effet des optimisations.

Niveau 1 : le cache “côté PHP” (OPcache, JIT, APCu, Realpath, Composer)

Axel commence par un rappel utile : avant même d’écrire une seule ligne de cache applicatif, PHP dispose déjà de plusieurs mécanismes.

OPcache : le levier principal

OPcache compile le PHP en opcode, évitant de reparser et recompiler à chaque requête. C’est souvent l’optimisation la plus rentable… à condition qu’elle soit bien configurée.

Deux fonctionnalités clés sont mises en avant :

  • Preloading : charger au démarrage un ensemble de scripts/classes en mémoire (Symfony fournit un fichier de preload en prod).
  • JIT (Just-In-Time) : compilation à la volée (souvent désactivée par défaut), utile dans certains scénarios mais à évaluer.

Axel insiste sur un point pratique : OPcache est excellent en prod, mais peut être pénible en dev si certaines options empêchent la détection des changements de fichiers (ex : désactiver la validation par timestamp).

APCu : une mémoire vive accessible au code

APCu fournit un store clé/valeur en RAM, très rapide. Contrairement à OPcache, il ne fait rien “tout seul” : il est utile si ton code/framework/bundle l’exploite.

Realpath cache

Cache interne à PHP qui accélère la résolution de chemins (utile dans des traitements fichiers intensifs).

Composer : optimiser l’autoload

Composer peut générer une classmap optimisée, et même utiliser APCu pour accélérer l’autoload. Certaines options (“authoritative classmap”) peuvent être très performantes, mais attention aux classes générées dynamiquement selon les projets.

Niveau 2 : le cache applicatif (PSR-6/PSR-16, adapters, warmup, tags)

Axel enchaîne sur le cache au niveau “application”, c’est-à-dire ce que l’équipe met explicitement en place.

Standards : PSR-6 vs PSR-16

  • PSR-6 : notion de cache pool + cache items (souvent rencontré via Symfony).
  • PSR-16 : interface plus simple “clé/valeur”.

Ces standards ne sont pas ennemis : des adaptateurs permettent l’interopérabilité.

Où stocker ?

Même avec une API standard, il faut un stockage :

  • Redis
  • APCu
  • filesystem
  • base de données
  • structures en mémoire PHP (selon cas)

Le choix dépend surtout des contraintes (latence, volumétrie, distribution, coûts).

Warmers / Clearers : préchauffer plutôt que subir le “premier hit”

Axel rappelle un point sous-estimé : les apps “chauffent” souvent au premier utilisateur. Symfony propose un mécanisme pour :

  • nettoyer proprement certains caches lors d’un cache:clear,
  • pré-remplir certains caches lors d’un warmup (éviter que le premier visiteur subisse le temps de calcul complet).

Tags : invalider par groupe

Le cache “intelligent” se joue souvent sur l’invalidation. Les tags permettent de regrouper des entrées cohérentes :

  • ex : toutes les promotions
  • ex : tout ce qui dépend d’un produit
  • ex : un fragment partagé par plusieurs pages

Et donc d’invalider “en bloc” quand une modification survient.

Observer avant d’optimiser : profiler + métriques

Une partie très concrète du talk : mesurer, pas deviner.

  • Symfony Profiler permet de voir les reads/writes cache, les pools utilisés, les hits/miss.
  • Avec Stopwatch, on peut instrumenter des étapes internes (ex : temps de récupération Doctrine, temps de formatage des données).

Le premier test de charge, dans un contexte peu optimisé (et même lancé en dev), montre un résultat typique :

  • une moyenne “pas honteuse”
  • mais des p95/p99 catastrophiques (des requêtes qui montent à plusieurs secondes)
  • et un objectif de latence non atteint (ex : “95% < 500ms” très loin du compte)

Ce point est important : une application peut sembler “fluide” à la main… et s’effondrer sous contrainte.

Doctrine : metadata, query cache, result cache… et second-level cache

Axel consacre ensuite un passage à Doctrine, sujet vaste et souvent mal maîtrisé dans ses subtilités.

Les caches Doctrine “classiques”

  • metadata cache : mapping entités → colonnes/relations
  • query cache : DQL → SQL
  • result cache : résultat d’une requête (à activer explicitement)

Le result cache est intéressant mais piège classique : si la requête contient des paramètres “instables” (ex : new DateTime()), la clé interne peut varier et conduire à un cache qui grossit de façon inattendue.

Axel partage un retour terrain très parlant : en préparant le talk, il a dû déterrer une vieille issue et diagnostiquer un cas où une clé semblait “identique”, mais où Doctrine construisait en réalité des clés internes différentes — ce qui provoquait des écritures répétées et une croissance non désirée.

Second-level cache

Différent du result cache : il cache les entités et leurs associations, avec une configuration par régions. Puissant, mais la stratégie d’invalidation peut devenir complexe : prudence sur les TTL trop élevés tant que le comportement exact n’est pas parfaitement maîtrisé et testé.

Niveau 3 : le cache HTTP (navigateur, proxy, CDN)

Après le cache “dans l’app”, Axel rappelle une évidence souvent oubliée :

Si la requête atteint ton serveur, même un hit cache consomme des ressources.

Le cache HTTP permet de stopper la requête avant l’application.

Deux grandes familles

  • Cache navigateur : assets, mais aussi pages entières selon contexte
  • Cache partagé : proxy/CDN (Varnish, Cloudflare…), capable de servir du HTML figé à très haute cadence

Avec Cache-Control, on contrôle les directives :

  • expiration (max-age)
  • revalidation (must-revalidate, no-cache)
  • stockage (no-store)
  • public/privé (attention aux pages personnalisées)

Axel glisse une précision utile : no-cache ne veut pas dire “ne cache pas”, mais “revalide”. Pour interdire le stockage, c’est no-store.

Fragments et pages composées

Pour les pages mixtes (parties communes + parties personnalisées), Axel évoque des techniques de fragmentation :

  • ESI (Edge Side Includes)
  • SSI
  • h-include (chargement côté client via JS)

Objectif : cacher agressivement ce qui est mutualisable, sans exposer des données personnalisées à un cache partagé.

Le vrai sujet : la stratégie (expiration, purge, coûts, risques)

La conclusion du talk est probablement la plus importante : le cache devient vite une usine à gaz si on le pousse sans méthode.

Axel partage un retour d’expérience en contexte média : à force de tags hyper granulaires (tag global + tag par entité), l’invalidation devient lourde, fragile, et coûteuse. La solution la plus robuste adoptée finalement : TTL courts + expiration plutôt que purge permanente.

Il mentionne aussi des problèmes réels qu’on rencontre à grande échelle :

  • “cache stampede” : 100k requêtes arrivent au moment où le cache expire, et toutes recomputent en même temps
  • arbitrage mémoire vs disque
  • pertinence : tout ne mérite pas d’être caché

D’où la phrase de synthèse proposée :

Trouver une bonne ration entre besoin, coûts et risques.

Et un cycle pragmatique :

  1. monitorer (mesures réelles)
  2. analyser (profiler, tests de charge)
  3. cibler (route critique business)
  4. planifier (petits incréments, objectifs réalistes)
  5. déployer
  6. mesurer l’impact, recommencer

Résultat : un gain massif… sur une machine contrainte

Avec les optimisations activées (OPcache/config prod, caches Doctrine, tuning Symfony, etc.), la démo montre un bond spectaculaire sur la charge supportée : sur la même machine limitée, la capacité monte à plusieurs centaines de requêtes/s, avec une nette amélioration des latences.

Le message final est clair : le cache peut multiplier la performance… mais uniquement si on mesure, si on choisit le bon niveau, et si on garde une stratégie simple.

Algolia, un cadre propice aux échanges techniques

L’événement s’est tenu chez Algolia, acteur reconnu de la recherche et de l’indexation en temps réel. Leur positionnement, centré sur la vitesse, la pertinence et la scalabilité, faisait écho direct aux thématiques abordées durant la soirée.

Au-delà des conférences, le lieu a favorisé les échanges informels autour d’un verre, prolongeant les discussions sur les choix technologiques, les retours d’expérience et les tendances actuelles du développement PHP.

Conclusion

Ce meetup de clôture 2025 a parfaitement illustré deux réalités du développement moderne :

  • tous les projets n’ont pas besoin d’un framework lourd,
  • la performance ne s’improvise pas, elle se conçoit.

Entre minimalisme assumé et optimisation pragmatique, cette soirée AFUP Paris a rappelé l’importance de choisir les bons outils au bon moment, tout en cultivant une réflexion collective sur la qualité et la durabilité des applications.

Un rendez-vous de plus qui confirme la vitalité de la communauté PHP parisienne.