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.

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.

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.

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.

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.

Plusieurs dates importantes ont été annoncées :

• 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

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

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.

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.

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.

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.

Présentation par Thierry Leriche-Dessirier

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

Avec le temps, l’arrivée de frameworks devenus incontournables Symfony, puis plus tard Laravel a profondément structuré l’écosystème. Thierry explique avoir tenté de s’intéresser à Symfony il y a une dizaine d’années, mais que, compte tenu de son niveau PHP de l’époque, l’approche lui a semblé trop complexe. C’est dans ce contexte qu’il a cherché une alternative plus simple, plus directe, et qu’il a découvert Slim.

Contrairement à ce que l’on pourrait penser, Slim n’est pas un nouvel acteur : le projet existe depuis 2010, ce qui en fait un outil mature, stable et éprouvé, loin des effets de mode.

Le message central du talk est clair : Slim est un micro-framework au sens strict. Pour Thierry, Slim est même “presque uniquement” un routeur et c’est précisément ce qui fait sa force.

• Slim mappe des routes vers des handlers.

• Il propose une architecture légère, extensible via des middlewares.

• Il s’intègre naturellement dans l’écosystème PSR, en particulier PSR-7 pour la gestion des requêtes et réponses HTTP.

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

1. Une courbe d’apprentissage courte : on en fait rapidement le tour.

2. Une grande fiabilité : comme Slim fait peu de choses, il a eu le temps de les faire correctement, de manière performante et prévisible.

Thierry se décrit comme un profil “multi-casquettes” (développement, conception, rédaction…), travaillant sur plusieurs langages. Il revendique également une posture intéressante : malgré son expérience, il continue de se considérer comme débutant en PHP, et invite explicitement le public à challenger ses choix ou à corriger ses approximations.

Le talk n’a pas vocation à être exhaustif. Thierry précise qu’il va surtout présenter sa manière personnelle d’utiliser Slim, celle qu’il juge la plus naturelle pour démarrer et structurer un projet.

Cette approche est illustrée par un cas réel : Profile4 (👉 https://profil4.com), une application orientée communication interpersonnelle et analyse comportementale, dont la partie web repose sur Slim. À cette occasion, un code promo “AFUP” permettait aux participants du meetup de bénéficier d’une réduction sur les tests DISC proposés par la plateforme.

L’installation se fait classiquement via Composer, avec l’ajout des dépendances nécessaires autour de PSR-7, puisque Slim s’appuie sur ces abstractions pour manipuler les requêtes et réponses HTTP de manière standardisée.

L’approche est volontairement pragmatique : on part d’un point d’entrée minimal, puis on enrichit l’application uniquement lorsque le besoin se fait sentir.

Le “Hello World” Slim correspond exactement à ce que l’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 explicite de l’application via run()

Thierry insiste sur un point important : run() ne déclenche l’exécution qu’à la toute fin, ce qui rend l’architecture plus souple et évite toute initialisation prématurée.

Slim supporte nativement :

• des routes complexes,

• des paramètres d’URL ({name}),

• la nomination des routes, essentielle pour éviter les URLs codées en dur, notamment lors des redirections.

Même si Slim permet techniquement d’écrire toute l’application dans un seul fichier, cette approche ne tient pas dès que le projet dépasse le stade du prototype.

Thierry propose une organisation simple et efficace :

• index.php comme point d’entrée minimal

• un fichier boot.php pour l’initialisation

• un fichier dédié aux routes

• un fichier dédié aux middlewares

• un espace dédié au container pour les dépendances

L’objectif est de conserver Slim comme une colonne vertébrale légère, tout en structurant le projet de façon saine et évolutive.

Pour éviter un empilement de closures, Thierry distingue deux patterns.

Une Action est une classe simple, généralement mono-responsabilité, exposant une méthode __invoke() appelée automatiquement par Slim. Ce pattern est idéal pour les pages simples (home, FAQ, pages statiques).

Dès que plusieurs interactions sont nécessaires (formulaire, validation, redirections…), un contrôleur devient plus adapté :

• getLogin() pour afficher le formulaire

• postLogin() pour traiter la soumission

Le mapping se fait explicitement dans la route. Thierry recommande notamment de factoriser des patterns courants comme le Post / Redirect dans ces contrôleurs.

Slim permet de créer des groupes de routes (par exemple /user/*) afin d’appliquer des comportements communs comme des middlewares.

Thierry souligne toutefois une friction connue : la gestion équivalente de /user et /user/ n’est pas triviale. En pratique, il lui arrive de déclarer la route en double. Il invite la communauté à partager une solution plus élégante si elle existe aujourd’hui.

Dès que l’on souhaite logger, rendre des templates ou sécuriser l’application, le container devient central.

Thierry montre comment y déclarer un logger (par exemple Monolog), injectable ensuite dans :

• les actions,

• les contrôleurs,

• les middlewares.

Les services sont instanciés à la demande, évitant de construire inutilement toutes les dépendances à chaque requête un problème qu’il avait rencontré avec ses anciens frameworks “maison”.

Slim est particulièrement à l’aise avec les middlewares. Thierry les décrit comme un oignon :

• les middlewares s’empilent autour du cœur (l’application),

• le dernier ajouté est le premier exécuté,

• après l’exécution de l’application, on “ressort” dans l’ordre inverse.

Il illustre plusieurs cas concrets :

• middleware de log “before” pour valider la configuration,

• middleware global pour enrichir les réponses HTML (headers, sécurité),

• middleware d’authentification appliqué à un groupe de routes, avec redirection vers une route nommée (login).

Slim n’impose aucun moteur de templates, mais s’intègre facilement avec plusieurs solutions.

Thierry présente Twig comme choix personnel :

• enregistrement du moteur et du dossier de templates dans le container,

• ajout du middleware de rendu,

• rendu des vues depuis les actions avec passage explicite des variables.

Il recommande également de centraliser l’injection des variables communes (utilisateur, permissions, contexte global) via héritage ou middleware, plutôt que de les répéter dans chaque action.

Le talk se conclut par un constat cohérent avec la philosophie de Slim :

• Slim est stable et 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 (y compris PHP 8.5).

• Il ne gère volontairement ni ORM, ni migrations : à vous de composer votre stack.

Thierry nuance néanmoins : en 2025, certains avantages historiques de Slim sont moins exclusifs. Les frameworks full-stack notamment Symfony ont beaucoup progressé sur la modularisation et les approches “light”.

Pour autant, lorsqu’on a un besoin clair routing, middlewares, injection propre, rendu simple Slim reste un choix direct, lisible et efficace.

• Slides LinkedIn : https://www.linkedin.com/posts/thierryler_slim-activity-7406987757400637440-lqyu/

• Slides SlideShare : https://fr.slideshare.net/slideshow/presentation-du-micro-framework-slim-a-l-afup-paris-dec-2025/284450607

• Article Programmez! (approche plus approfondie) : https://fr.slideshare.net/slideshow/a-la-decouverte-du-micro-framework-slim-4/284319183

• Posts PHP 8.5 (et article à venir dans le numéro hiver de Programmez!) : https://www.linkedin.com/posts/thierryler_%F0%9D%90%8B%F0%9D%90%9E%F0%9D%90%AC-%F0%9D%90%A7%F0%9D%90%A8%F0%9D%90%AE%F0%9D%90%AF%F0%9D%90%9E%F0%9D%90%9A%F0%9D%90%AE%F0%9D%90%AD%F0%9D%90%9E%F0%9D%90%AC-%F0%9D%90%9D%F0%9D%90%9E-%F0%9D%90%8F%F0%9D%90%87%F0%9D%90%8F-activity-7404814079187382272-oMrt

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.

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.

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.

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

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

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.

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

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

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

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

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.

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.

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

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

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

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.

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

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

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

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.

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.

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.