Jusqu’à l’AFUP Day 2024, 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

Comment scaler une application PHP vieille de plus de 20 ans ... sans frozen zone ? Au cours de cette présentation, nous parlerons de notre architecture N-tiers, un élément fondamental de notre approche pour garantir un système à la fois évolutif et performant. Nous examinerons comment nous avons segmenté notre site en couches pour faciliter la maintenance, favoriser la scalabilité et simplifier les migrations tout en améliorant les performances. De plus, nous aborderons l'importance cruciale du cache HTTP (Varnish) dans la réduction de la charge serveur et l'amélioration de la réactivité de nos services. Vous découvrirez des outils essentiels tels que Blackfire, qui ont permis une analyse en profondeur et une optimisation efficace de notre code PHP. Enfin, nous partagerons notre approche de sensibilisation des devs aux enjeux de la performance, afin de prévenir les incidents.

I.U.T. Nancy-Charlemagne 24/05/2024 14:00-14:40

Tu occupes le poste d’architecte applicatif pour Boursobank, peux-tu nous expliquer ton rôle ? Ou, pour paraphraser un film, c’est une bonne position ça, architecte ?

Vous savez, moi je ne crois pas qu’il y ait de bonne ou de mauvaise situation. Moi, si je devais résumer mon rôle aujourd’hui avec vous, je dirais que c’est d’abord des rencontres. Des gens à qui l’on tend la main, peut-être à un moment où ils ne pouvaient résoudre un problème, ou avaient besoin de conseils ou d’accompagnement pour terminer un projet. Et c’est assez curieux de se dire que les hasards, les bugs et les projets forgent une destinée…

Parce que quand on a le goût de la chose, quand on a le goût de la chose bien faite, le beau code, parfois, on ne trouve pas la réponse sur stackoverflow, le grimoire qui vous aide à coder. Alors ça n’est pas mon cas, comme je disais là, puisque moi, au contraire je lance un debugger, un profiler; et je dis merci aux logs et aux métriques, je chante une ode à la performance, je danse le debug… Je ne suis que breakpoint !

Et finalement, quand des gens me disent « Mais comment fais-tu pour avoir cette technique ? », je leur réponds très simplement que c’est ce goût de l’amour d’aider et de former les autres, ce goût donc qui m’a poussé aujourd’hui à endosser le rôle de l’huile dans le rouage du développement de nos applications…

Peux-tu nous partager un défi majeur que vous avez rencontré lors de la mise à l’échelle de votre application et comment vous l’avez surmonté ?

Nous avons plusieurs défis majeurs, du fait de notre activité. Le premier est le fait que le trafic de nos applications connaît plusieurs pics au cours de la journée, au moment des différentes ouvertures de bourses.

Le second est que la performance et la résilience d’une application sur laquelle travaillent 70 devs avec plusieurs livraisons par jour est très sensible. Dans les deux cas, la recette est la même, beaucoup de métriques, des dashboards, des alertes, de la communication et surtout beaucoup de micro-optimisations.

En bourse, comme sur une application à fort trafic, il faut se rappeler que « les performances passées ne préjugent pas des performances futures. »

J’ai vu que tu étais à l’origine d’un petit manifeste contre les accronymes (je-suis-caca). D’où vient cette idée et pourquoi un tel nom ?

Dans l’informatique, et peut-être encore plus dans le domaine de la banque, on nage dans une mer d’acronymes, de sigles et d’anglicismes.

En soi, ce n’est pas un problème si on a l’assurance que toutes les personnes qui travaillent et vont travailler sur le projet sont bien au fait de la signification de chaque terme. Cependant, on remarque que, le temps passant, les produits changent de nom, et l’on se retrouve alors avec un acronyme dans le code qui fait référence à l’ancien nom d’un produit, mais que les équipes métier utilisent maintenant un nouvel acronyme pour le désigner. Un nouvel arrivant dans l’entreprise va alors avoir du mal à faire le lien et devra consulter une tierce personne, ou un glossaire, pour retomber sur ses pieds.

Mon idée est qu’il est souvent préférable de nommer les choses de manière explicite, pour éviter toute incompréhension pour la prochaine personne qui va passer sur notre code. Je peux être parfois pénible lors de la revue de code, mais dès que je vois un acronyme, je demande systématiquement à quoi il se réfère.

Pour la petite anecdote, il m’a fallu 5 ans avant que je comprenne ce que signifiait l’acronyme B.S.A dans notre code. Et si vous voulez en connaître la signification, vous pouvez toujours demander à mes collègues…

Une conférence présentée par

Arnaud LAHAXE

Arnaud, architecte applicatif chez BoursoBank, est un passionné du développement web. Il a débuté sa carrière en tant que développeur PHP il y a près de 15 ans. C'est un amoureux du code, privilégiant la simplicité, la robustesse et la maintenabilité, rejetant tout excès d'acronymes et de hype. Son engagement au quotidien se traduit par son souci constant d'améliorer les performances et la qualité des applications PHP de manière pragmatique. Il déploie son expertise avec modestie pour trouver des solutions efficaces. En dehors de l'univers du code, il partage aussi une passion pour la raclette, la bière et les jeux vidéos, reflétant sa préférence pour les choses simples et conviviales.

Autres intervenants