Jusqu’à l’AFUP Day 2025, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Minority report : optimisez votre expérience utilisateur avec du cache par anticipation Vous connaissez sûrement déjà le cache par expiration et celui par invalidation. Imaginez maintenant une stratégie de cache entièrement adaptée à vos besoins utilisateurs·trices et indépendante pour chacun·e d’entre eux. À partir de plusieurs cas d’usages d’un projet Symfony, voyons les étapes nécessaires pour établir différents parcours et prédire par personne, ou par groupe, les ressources à mettre en cache pour améliorer la réactivité de votre interface et proposer une navigation optimale.

La Comédie 16/05/2025 09:25-10:05

Pour toi, quelle est l’erreur la plus commune quand on met en place du cache dans une application ?

Pour moi l’erreur la plus commune est plutôt une erreur d’approche. Je pense qu’on a tendance à privilégier le cache sur des requêtes qui sont lentes et/ou gourmandes, ce qui est tout à fait légitime d’un point de vue infra et fluidité de notre application, mais c’est parfois au détriment de requêtes ou d’endpoints qui ne semblent pas poser problème en terme de temps de réponse mais qui sont joués beaucoup plus fréquemment.

Une requête jouée plusieurs milliers de fois augmente drastiquement la consommation de notre SGBD, alourdissant donc potentiellement les performances générales et surtout les coûts dans le cadre d’une BDD sur un modèle « pay as you go » (AWS, GCP…).
Idem côté applicatif, la sérialisation en JSON ou la construction d’une réponse HTML nécessite des ressources, et tout ce qui est alloué ici n’est pas disponible ailleurs. Gardons à l’esprit que notre application forme un tout.

Tu as une formation d’historien. Vois-tu des parallèles entre ce métier et celui du développement ?

Pas tellement non, je vois le métier de dev à mi-chemin entre le jeu de lego / bac à sable et une perpétuelle résolution de « casses têtes ». On rencontre des problématiques, des bugs, on cherche, on expérimente des choses et au final on a sûrement une décharge de dopamine quand on trouve une solution. Puis on recommence, nouveau besoin et nouvelle investigation, ou comment on peut optimiser notre première solution.

De mes (lointains) souvenirs de recherche en histoire, il me revient surtout de l’accumulation et de l’agrégation de données, on a des hypothèses sur des sujets historiques, des périodes ou des évènements et on va chercher à trouver de la matière qui pourrait confirmer (ou pas) nos premières impressions. Parfois l’hypothèse vient avec la recherche, on voit des pattern qui se dessinent et qui nous mettent sur des pistes. Mais le métier est très différent : l’histoire nécessite généralement de recouper de nombreuses sources (qui n’existent parfois plus), et la réponse est rarement aussi simple qu’un booléen. La démarche historique enseigne – je pense – la nuance et à se prévaloir de nombreux biais qui peuvent impacter notre travail : les sources peuvent contenir des erreurs, les témoignages étudiés peuvent se tromper ou mentir, et notre avis personnel peut influer.

Si je devais trouver des parallèles je pense que l’écriture et le temps consacré à la relecture seraient un bon point commun. Quand on programme, avant de le publier on doit prendre un moment pour se relire, pour rendre notre code facile à consulter et à comprendre, pour optimiser à la fois l’application mais aussi la syntaxe. Idéalement, on doit documenter notre travail pour les interventions futures. C’est un besoin aussi quand on écrit en histoire : être lisible.

À part le temps d’un lightning-talk lors du dernier Forum PHP, c’est la première fois que nous avons la chance de t’accueillir sur un événement AFUP. Mais nombreux sont tes collaborateurs et collaboratrices qui ont déjà conquis nos scènes. Est-ce que l’expérience de tes collègues te rassure pour cette première ?

Oui, je ne suis pas trop inquiet, le public tech des conférences PHP est généralement bienveillant et sympathique. À titre personnel j’ai assisté à de très nombreux talks ces 10 dernières années et je n’attend pas forcément des intervenant·e·s une aisance parfaite à l’oral (ce n’est pas notre métier). Je sais que tous les participant·e·s sont bénévoles et je trouve déjà top de prendre sur son temps libre pour écrire, mettre en page, et enfin monter sur scène pour un tel exercice. Je ne me mets donc pas trop de pression. Récemment j’ai eu l’occasion de parler lors de l’API Platform Con et un meetup PHP donc ça permet de relativiser un peu le stress de parler en public.

Chez Les-Tilleuls.coop depuis toujours, on incite au maximum les collègues à s’essayer aux conférences et à postuler là où ils/elles le souhaitent, l’entreprise nous donne des jours pour préparer nos talks, on peut bénéficier de l’aide des « habitué·e·s » et même répéter devant un public plus restreint et rôdé pour nous accompagner.

En plus, là je joue à domicile à Lille donc j’espère que ça va le faire !

Une conférence présentée par

Clément TALLEU

Programmeur PHP depuis une dizaine d'années chez Les-Tilleuls.coop, Clément est un habitué des Forum PHP auxquels il a participé à 5 ou 6 reprises toujours avec énormément de plaisir. Il a, années après années, pu suivre énormément de conférences sur des sujets variés qui furent toujours enrichissantes d'une manière ou d'une autre. Il a eu l'occasion de donner plusieurs talks en 2024, au cours de l'API Platform Conference, lors d'un meetup de l'AFUP et plus récemment lors d'un lighting talk au forum PHP. Sur un plan purement professionnel, Il fait principalement du PHP avec ou sans framework, un peu de JS et de GO. Il dispense parfois des formations et encadre des développeurs et développeuses juniors au sein de son entreprise. Il a travaillé pour beaucoup d'entreprises, petits comme grands comptes, associations, collectivités territoriales, mairies etc. Il a également créé un logiciel ATEXpert qui est un outil d'inspection d'usine qu'il commercialise depuis 2 ans avec un associé issu du monde de l'industrie.

Autres intervenants