Le partage de connaissances : un atout durable 

Dans le domaine du développement, la valeur d'une expertise se mesure à sa capacité à être transmise. Nous vous proposons de voir ou revoir l'intervention de Jonathan Van Belle, l'un de nos Linkers Belges, captée lors du Forum PHP 2025.

À l'occasion des 30 ans de la technologie, Jonathan est monté sur la scène de l'AFUP pour aborder un sujet qui reste au cœur des préoccupations des équipes backend : la fiabilité des processus asynchrones.

Une problématique au cœur de la performance 

Dans son talk « Jobs, queues & events : anatomie des erreurs courantes et pistes de résolutions », Jonathan décortique les mécanismes invisibles mais critiques des applications web modernes.

Si vous travaillez sur des environnements PHP à fort trafic, les questions soulevées dans cette vidéo vous sont certainement familières :

• Comment réagir quand les workers s'arrêtent sans prévenir ?
• Quelles stratégies pour débloquer des files d'attente ?
• Comment diagnostiquer efficacement l'origine d'une panne ?

Visionner l'intervention 

Que vous ayez manqué l'événement ou que vous cherchiez des pistes d'optimisation pour vos projets actuels, nous vous proposons de visionner le replay de cette intervention technique :

Pour aller plus loin : 5 questions à Jonathan

En marge de sa conférence, nous avons posé quelques questions à Jonathan pour approfondir sa vision du métier et des architectures PHP.

1. PHP fête ses 30 ans et a atteint une maturité impressionnante. Pourtant, on constate que la gestion de la mémoire et des ressources reste un point de douleur fréquent sur les projets. Selon toi, est-ce un problème de formation ou une complexité inhérente aux architectures modernes ?

Dans un système moderne, avec un certain niveau de complexité, peu importe la technologie utilisée, l’optimisation de la mémoire et des autres types de ressources finit toujours par se poser.

En PHP particulièrement, la mémoire n’est pas toujours simple à appréhender, notamment à cause de la structure des données qui est cachée par le langage lui-même, sans compter certaines librairies courantes qui ne facilitent pas du tout la tâche.

En réalité, le souci de l’optimisation des ressources a toujours existé, que ce soit à l’époque d’Apollo ou aujourd’hui. La différence est qu’actuellement, la direction du travail est orientée vers davantage de fonctionnalités, le plus rapidement possible, là où auparavant les contraintes de ressources constituaient une barrière critique.

2. Tu insistes beaucoup sur l'utilisation des générateurs (yield) et des flux (streams). Pourquoi ces mécanismes natifs sont-ils encore trop souvent sous-estimés par rapport à l'ajout de RAM brute, et quel est leur impact réel sur la scalabilité ?

Ces deux mécanismes sont ce que l’on appelle des coroutines. Il s’agit de mécanismes permettant de lancer, suspendre et reprendre certaines activités. Malheureusement, leurs cas d’usage sont souvent méconnus et les implémentations natives concrètes dérivent tellement de ce principe que les streams et yield, n’ont pas encore vraiment été intégrés par les développeuses et développeurs.

À la base, ces coroutines sont des mécanismes qui n’ont pas été développés pour de la scalabilité de type cloud, mais plutôt pour un usage local, en distribuant le travail sur les nombreux cœurs d’un CPU ou à travers plusieurs processus. Dans le but de distribuer mais aussi d'optimiser certains aspects, tel que  la mémoire. Comme souvent en informatique, on redécouvre les mêmes mécanismes que l’on modernise régulièrement.

Lorsqu’on parle de scalabilité de type cloud, cela va donc jouer sur plusieurs tableaux. C’est avant tout une question de choix architectural, en fonction de l’endroit où l’on souhaite placer le curseur, de l’équipe dont on dispose, des technologies utilisées, etc. Cela joue énormément.

La raison pour laquelle j’ai insisté sur ces mécanismes, c’est que lorsqu’on utilise des workers, bien les gérer permet de faciliter le travail de scaling, qu’il soit horizontal ou vertical. Cela permet une meilleure distribution des ressources. L’ajout de RAM brute peut certes résoudre certains problèmes, mais on ne peut pas en ajouter à l’infini. D’ailleurs, au vu de l’actualité, la gestion de ce coût risque de devenir critique.

3. Protéger un worker est crucial, mais il ne faut pas pour autant rendre le système "muet" face aux erreurs. Quel est ton conseil pour implémenter un Circuit Breaker qui protège l'infrastructure tout en remontant des alertes pertinentes sur les APIs tierces ?

Mon conseil est de rester pragmatique et de faire avec la technologie à votre disposition. Le Circuit Breaker est un pattern simple : il faut juste garder en tête ce que l’on désire protéger et comment réagit le système.

L'implémentation peut aller d’un simple flag dans un fichier ou une valeur en base, jusqu'à des systèmes dédiés très complexes. Néanmoins, comme tout mécanisme ajoutant de la complexité, il faut peser le pour et le contre.

J’ai tendance à faire au plus simple et à adapter la solution au cas par cas :

• Pour une API appelée intensément : je laisse le monitoring gérer le cas (sondes, logs d’erreur, métriques...). Si possible, le processus appelant ne sera même plus lancé.
• Pour une API appelée ponctuellement : je monitore la réponse et enregistre les cas d’erreur pour mettre un flag (fichier, système de clé-valeur avec timeout, …)

Ce sont deux exemples, mais cela donne une idée. Tout dépend de l'objectif : éviter de consommer des ressources inutilement, empêcher les erreurs en cascade ou protéger l'API du partenaire.

4. On parle souvent de code, moins du système d'exploitation. En quoi la maîtrise des signaux POSIX est-elle devenue une compétence indispensable pour garantir des déploiements sans interruption (Graceful Shutdown), notamment dans des environnements conteneurisés ?

Lorsqu'on demande à un conteneur de s'arrêter, il finit forcément par le faire. Mais prenons le cas de Docker : par défaut, il y a un délai (timeout) de 10 secondes avant l'arrêt forcé.

Imaginez un scénario avec 30 conteneurs liés les uns aux autres, attendant l'arrêt du précédent : si tous atteignent ce timeout, on peut théoriquement arriver à 300 secondes d'attente (5 minutes) !

En gérant correctement les signaux d’arrêt, l'ordre est transmis directement au processus principal du conteneur. L'arrêt est souvent bien plus rapide que le timeout. Au lieu d’attendre 5 minutes, le système s'éteint peut-être en 30 secondes, ce qui facilite grandement la reprise ou les déploiements.

Au final, cette maîtrise est indispensable : elle permet non seulement de gagner du temps, mais aussi de mieux comprendre le système pour optimiser le monitoring et le débogage .

5. Tu as évoqué l'intégration d'OpenTelemetry, qui semble encore manquer de maturité dans l'écosystème PHP actuel. Quelles évolutions attends-tu pour que cette technologie devienne le standard fiable d'observabilité que tout le monde espère ?

Du côté du langage PHP lui-même, il n'y a rien à attendre de particulier. C'est plutôt à l'écosystème d'accélérer l'adoption : les frameworks et les librairies populaires doivent intégrer OpenTelemetry nativement. Nous manquons aussi cruellement d'exemples d'implémentations propres et concrètes.

Le vrai point de friction vient d'OpenTelemetry : la documentation est un obstacle important. On y trouve beaucoup d'informations de très bas niveau, mais il manque une vision d'ensemble du fonctionnement.

Pour un développeur qui cherche à réaliser une intégration propre, en gérant correctement les ressources, la marche à suivre n'est pas claire. C'est un frein regrettable à l'adoption de cette technologie pourtant prometteuse.

La culture technique au sein du Groupe

Au sein du Groupe IT Link, nous mettons un point d'honneur à ce que l'expertise de nos collaborateurs ne reste pas isolée. En relayant cette conférence sur notre site, nous souhaitons valoriser la démarche de Jonathan : celle d'un ingénieur qui prend le temps d'analyser, de structurer son savoir et de le transmettre à la communauté.

C'est cet état d'esprit de progression continue et de partage qui anime nos équipes au quotidien !

Encore toutes nos félicitations à Jonathan !

‍