Le blog

Ce qu'il faut retenir du Forum PHP 2022 - partie 2

Publié le 19 octobre 2022

Après avoir publié un premier retour, voici la suite des conférences qui nous ont marquées au Forum PHP 2022.

Papa et Maman nettoient l’internet

Spécialistes de l’éco-conception, Hélène Maître-Marchois et Mathieu Marchois, les deux fondateurs de la coopérative Fairness, nous proposent un talk très instructif sur ce thème. Le binôme nous permet d’avoir le point de vue d’Hélène, en tant que Scrum Master / Product Owner, qui s’est donné comme mission “de rendre les devs fiers du produit sur lequel ils travaillent”, ainsi que du point vue technique de Mathieu, développeur Symfony féru de DDD et d’architecture hexagonale. Leur objectif du jour est de nous donner envie de nettoyer Internet à leurs côtés, car cela est devenu primordial.

L’impact du numérique représente actuellement 4% des émissions de CO2 dans le monde et augmente de 10% chaque année. Cela est en grande partie liée à la fabrication des terminaux utilisateurs, très peu recyclés, malgré une durée de vie très courte, du fait des exigences de plus en plus fortes demandées par les applications et sites internet.

C’est 70 à 80% du web qui est chargé dans nos applications et qui n’est pas ou très peu utilisé au quotidien.

En cinq ans, une page web est passée de 500Ko à plus de 2Mo, avec une augmentation de 311% du nombre des requêtes. Il est pourtant possible d’obtenir très vite des gains en réfléchissant un peu à ce que l’on charge. Pour Hélène, c’est un travail combiné du PO et des UX designers de réfléchir à un design efficace et le moins gourmand possible. Il faut parler d’éco-conception avec les clients dès la naissance du projet pour trouver des solutions à des besoins sporadiques qui vont pourtant impacter 100% des utilisateurs et augmenter significativement l’impact écologique de l’application. En ligne de mire : les requêtes multiples dès la page d’accueil, les trackers…

Ensuite Mathieu nous parle des choses à mettre en place côté technique, en se basant notamment sur le livre “Ecoconception web : les 115 bonnes pratiques”, de Frédéric Bordage, devenu référence de la norme ISO 14062, proposant des axes d’amélioration backend, frontend, et infra.

Tout d’abord, faire un état des lieux et mettre en place des mesures, pour ainsi suivre l’évolution des métriques au fil des changements. Pour cela de nombreux outils existent, plutôt orientés performances (PageSpeed, web.dev, Blackfire, Datadog…) ou d’autres plutôt orientés impact environnemental (Ecoindex, GreenFrame, Scaphandre, Carbonalyser, Greenspector…).

Ces outils ne mesurent pas la même chose, il est intéressant de comprendre ce qu’ils font afin de les combiner pour pouvoir agir de manière efficace.

Pour illustrer cette démarche plus concrètement, voici par exemple quelques points de vigilance à avoir sur vos projets :

  • Attention à la CI, qui consomme beaucoup de RAM et de CPU : optimisation avec la parallélisation, éviter les traitements inutiles et redondants, utiliser le cache… En plus de ça une CI qui prend beaucoup de temps ça fait perdre beaucoup de temps aux devs.
  • Faire du sur-mesure plutôt que du CMS trop lourd pour un besoin simple.
  • Optimiser les requêtes aux bases de données, récupérer uniquement les données nécessaires, ajouter des indexes, de la pagination…
  • Favoriser le request collapsing : regrouper les appels vers des services distants.
  • Utiliser la version la plus récente d’un langage.
  • Etc.

Merci à Hélène et Mathieu pour ce talk très intéressant qui nous permet de nous questionner sur notre responsabilité dans l’impact du numérique sur l’environnement et de réaliser qu’il n’est pas forcément difficile de mettre en place des choses permettant de réduire l’impact de nos projets, d’autant plus que ces améliorations profiteront également aux utilisateurs finaux.

Compte-rendu rédigé par Marion.

Revue de code : on n’est pas venu pour souffrir !

Anne-Laure De Boissieu nous parle de l'étape si cruciale et tant redoutée de la revue de code. Après avoir travaillé chez Elao dans des équipes de deux ou trois devs, elle rejoint Bedrock où le travail s’effectue en équipe de ±9 personnes… La revue de code s'avère pourtant aisée grâce aux systèmes et techniques mises en place.

En effet, le développement est parfois un milieu compétitif, où l'on peut se sentir en besoin de prouver ses compétences parfois agressivement ; mais cette attitude peut causer une souffrance chez l'autre.

Or une bonne relecture améliore les relations dans l'équipe, permet de se former soi-même et les autres, favorise le partage des connaissances et la responsabilité du code. Elle demande à la fois de l'empathie et du pragmatisme ; il ne s'agit pas d'identifier le code à celui ou celle qui l'écrit, mais de le voir comme une construction commune de l'équipe. Idem pour les erreurs qui doivent être gérées, non comme une défaillance personnelle, mais plutôt comme une opportunité pour apprendre et se perfectionner.

Anne-Laure insiste sur l’importance des outils permettant de ne pas polluer les relectures avec des problèmes de coding style (linters, reformat auto) ou de tests manquants (analyse du coverage des diff). Elle propose également l'utilisation des conventional comments, afin de prioriser et contextualiser les retours (en utilisant des mots clés comme suggestion, praise, nitpick, etc). Mais de permettre surtout le dialogue, le mentorat, voire l'émergence de questions plus profondes sur les fonctionnalités ou la pratique plus générale du code.

Elle conclut en évoquant le concept d'Egoless programming à travers une recommandation de lecture : ?The psychology of computer programming, de Gerald Weinberg.

Compte-rendu rédigé par Élise.

FrankenPHP, dans les entrailles de l’interpréteur PHP, de machines virtuelles et des threads

Après Mercure et Vulcain, Kévin Dunglas a remis le couvert et nous a présenté une monstruosité affectueusement nommée FrankenPHP.

Parti du constat que les applications PHP souffraient de l’absence du support du cloud native, souvent contournée grâce à l’utilisation conjointe d’un conteneur PHP et de celui d’un serveur Web tiers (Apache, Nginx, Caddy…), ce qui engendre une grande complexité, il a décidé de soigner le mal à la racine et de proposer cette fois un serveur tout-en-un écrit en Go, contenant à la fois PHP et un serveur Caddy. FrankenPHP propose un mode worker qui permet de ne booter qu’une seule fois l’application, de la garder en mémoire et de ne réinitialiser que le contexte de la requête afin de gagner en performance, il propose aussi un support natif du nouveau statut 103 Early Hint et inclut Mercure pour la communication en temps réel avec le front.

Encore au stade expérimental, FrankenPHP permettrait à terme de simplifier le déploiement de nos applications PHP en production avec un conteneur unique pour les gouverner tous.

Pour plus d'informations, rendez-vous sur ses slides.

Compte-rendu rédigé par Jérôme.

Piochons dans les pratiques de DDD, programmation fonctionnelle and co pour notre bien à tous

Benjamin Rambaud nous propose dans son talk de nous inspirer des pratiques du DDD et de la programmation fonctionnelle, pour les intégrer dans notre code. Il revient sur certains concepts les plus connus, et qui peuvent facilement être intégrés dans un projet existant ou un nouveau projet.

Il nous propose de nous inspirer des différentes philosophies de développement et d’architecture pour piocher des éléments qui permettent d’améliorer la communication, la testabilité ou la qualité d’un projet.

Par exemple, le concept d’Ubiquitous Language harmonise le vocabulaire utilisé par tous les acteurs d’un projet et améliore la compréhension du projet et la communication. L’architecture hexagonale avec des ports / adaptateurs, isole la logique et le domaine du monde extérieur.

Il nous invite également à profiter du fait que PHP est un langage multi-paradigme et qu’il ne faut pas hésiter à utiliser le paradigme adapté à notre besoin, en s’appuyant par exemple sur les outils et principes proposés par la programmation fonctionnelle : les fonctions pures, les value objects, l’immutabilité, ou les fonctions anonymes.

Le Domain-Driven Design est une philosophie permettant de résoudre des problèmes dans des domaines complexes, en modélisant le domaine de la façon la plus riche et la plus explicite possible, afin d’améliorer la compréhension du métier de tous. Il y a beaucoup de notions et de patterns tactiques proposés pour l’implémenter, mais l’objectif central reste d’isoler le domaine. Le reste des choix techniques est secondaire.

Enfin Benjamin nous conseille vivement, au travers d’un exemple concret reposant sur l’implémentation d’une fonctionnalité au sein de Drupal, de ne pas nous battre contre le framework, mais plutôt de travailler à isoler notre métier du framework, de la façon que l’on souhaite, en utilisant des principes piochés au sein de la programmation fonctionnelle, du DDD ou d’autres principes. Le fait de connaître son framework permet de sortir de l’usage généralement très orienté RAD qu’il propose par défaut et de l’utiliser de la meilleure façon pour notre besoin. L’objectif étant d’obtenir du code simple, explicite, que l’on peut typer et tester facilement.

Benjamin conclut en nous invitant à tester d’autres langages proposant des approches différentes afin de nourrir nos imaginaires.

Compte-rendu rédigé par Marion.

Sortir du cadre

Dans cette conférence, notre coopérateur Robin Chalas, membre de la core-team Symfony, nous partage son expérience pour adapter notre framework PHP préféré, Symfony, et le modeler à notre usage.

Même si cela s’adapte bien sûr à tous les frameworks. Dans cette conférence, il nous passe en revue la configuration par défaut proposée par Symfony dans ses dernières versions, et la possibilité qui nous est offerte de la modifier, ou non, et de l’intérêt que cela peut avoir. Les deux gros dossiers principaux étant src et config.

S’il est possible de changer la structure des dossiers racines (en dehors du nom du répertoire config), cela n’a généralement pas d’intérêt de casser ce standard facile à comprendre par tous les développeurs car inspiré de Unix, sauf en cas de contraintes infra.

En revanche, il est possible et il est même encouragé d’ajouter des fichiers et dossiers pour organiser le code, notamment isoler les outils de QA, ou les configurations de déploiement infra, en évitant de tomber dans l’excès et sans oublier de documenter d’éventuelles pratiques peu communes.
Robin nous a ensuite passé en revue le contenu du répertoire config, l’occasion de réexpliquer le fonctionnement de Symfony Flex, le plugin Composer qui ajoute lui-même la configuration nécessaire au core de Symfony et aux bundles tierces, et réalise également les mises à jour vers les nouvelles versions (grâce à composer recipes:update).

Robin nous rappelle aussi à quel point le framework doit s’adapter à nos besoins et non l’inverse, et qu’il faut absolument éviter de laisser la technique empiéter sur nos besoins métiers. En évitant notamment les structures de répertoire orientées pure technique, sans possibilité de comprendre le métier à la première lecture sans entrer dans le détail.

Au fil de ses versions et de sa maturité, le framework Symfony nous permet d’avoir cette souplesse de configuration, avec de moins en moins de contraintes de nommage, notamment grâce aux évolutions du langage PHP dont Symfony tire le meilleur profit pour améliorer notre quotidien de développeur·euse.

Finalement un talk très en lien avec celui de Benjamin Rambaud, qui nous invite à sortir du cadre, à ne pas se laisser aveugler par la proposition par défaut très “RAD” des frameworks, à s’ouvrir un peu l’esprit à d’autres architectures et méthodologies sans être obligé de l’embrasser dans sa totalité.

Compte-rendu rédigé par Marion.

Protégez votre application avec l’en-tête HTTP de sécurité “Content Security Policy”

Laurent Brunet nous présente les Content Security Policy, qui est une stratégie de sécurité permettant entre autres de se protéger de failles XSS. Elle consiste en un en-tête Content-Security-Directive(-Report-Only) qui définit des directives de sécurité séparées les unes des autres par des points-virgules. Il y a trois versions qui ont déjà été publiées.

Les CSP permettent d’éviter certaines menaces :

  • Les failles XSS : la directive “script-src” permet d’ajouter une liste blanche des scripts externes autorisés. En 2016, Google a publié une étude révélant que la liste blanche serait non sécurisée et propose une nouvelle façon de gérer les scripts en utilisant  “script-dynamic” en valeur de “script-src”i. 
  • Le clickjacking (une Iframe en transparence renvoyant sur un site malveillant)
  • On sécurise les protocoles 
  • On prévient le magecart ou formjacking (attaques permettant de récupérer les données d’un formulaire en créant par exemple des noms de domaines très similaires afin de récupérer des numéros de cartes banquaires). Pour contrer cela, on ajoute dans des bibliothèques des scripts récupérant des données de formulaire et on les envoie en Ajax sur de faux noms de domaine.

En complément, il nous recommande l’application https://csp-evaluator.withgoogle.com/ pour vérifier et valider ces politiques de sécurité ainsi que cette source

Compte-rendu rédigé par Quentin.

Une édition qui a tenu toutes ses promesses

Encore une fois, l'AFUP a fait preuve d'un extrême professionnalisme en proposant à sa communauté deux jours de conférences inédites avec des invité·e·s de renom. Rappelons qu'en complément à Amélie Deffrennes, leur salariée, l'AFUP est coordonnée uniquement par des bénévoles qui œuvrent sur leur temps libre diverses actions pour promouvoir le langage PHP. Notre coopérative est très attachée par cette association et compte parmi ses salarié·e·s plusieurs bénévoles qui l'accompagnent sur différents pôles.

Quant au Forum PHP en lui-même, il a répondu à toutes nos promesses que ce soit en tant que spectateurs·trices ou en tant que sponsor. Notre stand a eu de multiples visites, Antoine Bluchet a fait salle comble lors de sa démo programmée le vendredi et en parallèle, nous avons eu la chance d'animer un Twitter Space en direct permettant de tâter la température des participant·e·s sur les conférences en cours.

Merci encore une fois à l'AFUP pour cette belle édition et nous, on se donne rendez-vous la semaine prochaine à Łódź à l'occasion de la Sylius Con !

Les-Tilleuls.coop

Les-Tilleuls.coop

Mots-clésAfup, Forum PHP, PHP

\\n\\n\\n\\n

L’impact du numérique représente actuellement 4% des émissions de CO2 dans le monde et augmente de 10% chaque année. Cela est en grande partie liée à la fabrication des terminaux utilisateurs, très peu recyclés, malgré une durée de vie très courte, du fait des exigences de plus en plus fortes demandées par les applications et sites internet.

\\n\\n\\n\\n

C’est 70 à 80% du web qui est chargé dans nos applications et qui n’est pas ou très peu utilisé au quotidien.

\\n\\n\\n\\n

En cinq ans, une page web est passée de 500Ko à plus de 2Mo, avec une augmentation de 311% du nombre des requêtes. Il est pourtant possible d’obtenir très vite des gains en réfléchissant un peu à ce que l’on charge. Pour Hélène, c’est un travail combiné du PO et des UX designers de réfléchir à un design efficace et le moins gourmand possible. Il faut parler d’éco-conception avec les clients dès la naissance du projet pour trouver des solutions à des besoins sporadiques qui vont pourtant impacter 100% des utilisateurs et augmenter significativement l’impact écologique de l’application. En ligne de mire : les requêtes multiples dès la page d’accueil, les trackers…

\\n\\n\\n\\n

Ensuite Mathieu nous parle des choses à mettre en place côté technique, en se basant notamment sur le livre “Ecoconception web : les 115 bonnes pratiques”, de Frédéric Bordage, devenu référence de la norme ISO 14062, proposant des axes d’amélioration backend, frontend, et infra.

\\n\\n\\n\\n

Tout d’abord, faire un état des lieux et mettre en place des mesures, pour ainsi suivre l’évolution des métriques au fil des changements. Pour cela de nombreux outils existent, plutôt orientés performances (PageSpeed, web.dev, Blackfire, Datadog…) ou d’autres plutôt orientés impact environnemental (Ecoindex, GreenFrame, Scaphandre, Carbonalyser, Greenspector…).

\\n\\n\\n\\n

Ces outils ne mesurent pas la même chose, il est intéressant de comprendre ce qu’ils font afin de les combiner pour pouvoir agir de manière efficace.

\\n\\n\\n\\n

Pour illustrer cette démarche plus concrètement, voici par exemple quelques points de vigilance à avoir sur vos projets :

\\n\\n\\n\\n
  • Attention à la CI, qui consomme beaucoup de RAM et de CPU : optimisation avec la parallélisation, éviter les traitements inutiles et redondants, utiliser le cache… En plus de ça une CI qui prend beaucoup de temps ça fait perdre beaucoup de temps aux devs.
  • Faire du sur-mesure plutôt que du CMS trop lourd pour un besoin simple.
  • Optimiser les requêtes aux bases de données, récupérer uniquement les données nécessaires, ajouter des indexes, de la pagination…
  • Favoriser le request collapsing : regrouper les appels vers des services distants.
  • Utiliser la version la plus récente d’un langage.
  • Etc.
\\n\\n\\n\\n

Merci à Hélène et Mathieu pour ce talk très intéressant qui nous permet de nous questionner sur notre responsabilité dans l’impact du numérique sur l’environnement et de réaliser qu’il n’est pas forcément difficile de mettre en place des choses permettant de réduire l’impact de nos projets, d’autant plus que ces améliorations profiteront également aux utilisateurs finaux.

\\n\\n\\n\\n

Compte-rendu rédigé par Marion.

\\n\\n\\n\\n

Revue de code : on n’est pas venu pour souffrir !

\\n\\n\\n\\n

Anne-Laure De Boissieu nous parle de l’étape si cruciale et tant redoutée de la revue de code. Après avoir travaillé chez Elao dans des équipes de deux ou trois devs, elle rejoint Bedrock où le travail s’effectue en équipe de ±9 personnes… La revue de code s’avère pourtant aisée grâce aux systèmes et techniques mises en place.

\\n\\n\\n\\n

En effet, le développement est parfois un milieu compétitif, où l’on peut se sentir en besoin de prouver ses compétences parfois agressivement ; mais cette attitude peut causer une souffrance chez l’autre.

\\n\\n\\n\\n

Or une bonne relecture améliore les relations dans l’équipe, permet de se former soi-même et les autres, favorise le partage des connaissances et la responsabilité du code. Elle demande à la fois de l’empathie et du pragmatisme ; il ne s’agit pas d’identifier le code à celui ou celle qui l’écrit, mais de le voir comme une construction commune de l’équipe. Idem pour les erreurs qui doivent être gérées, non comme une défaillance personnelle, mais plutôt comme une opportunité pour apprendre et se perfectionner.

\\n\\n\\n\\n

Anne-Laure insiste sur l’importance des outils permettant de ne pas polluer les relectures avec des problèmes de coding style (linters, reformat auto) ou de tests manquants (analyse du coverage des diff). Elle propose également l’utilisation des conventional comments, afin de prioriser et contextualiser les retours (en utilisant des mots clés comme suggestion, praise, nitpick, etc). Mais de permettre surtout le dialogue, le mentorat, voire l’émergence de questions plus profondes sur les fonctionnalités ou la pratique plus générale du code.

\\n\\n\\n\\n

Elle conclut en évoquant le concept d’Egoless programming à travers une recommandation de lecture : ?The psychology of computer programming, de Gerald Weinberg.

\\n\\n\\n\\n

Compte-rendu rédigé par Élise.

\\n\\n\\n\\n

FrankenPHP, dans les entrailles de l’interpréteur PHP, de machines virtuelles et des threads

\\n\\n\\n\\n

Après Mercure et Vulcain, Kévin Dunglas a remis le couvert et nous a présenté une monstruosité affectueusement nommée FrankenPHP.

\\n\\n\\n\\n

C’est au tour de notre coopérateur @dunglas de monter sur la scène du #ForumPHP pour nous présenter son nouveau projet : #FrankenPHP pic.twitter.com/JTvSxPnFpE

— Les-Tilleuls.coop (@coopTilleuls) October 14, 2022
\\n\\n\\n\\n

Parti du constat que les applications PHP souffraient de l’absence du support du cloud native, souvent contournée grâce à l’utilisation conjointe d’un conteneur PHP et de celui d’un serveur Web tiers (Apache, Nginx, Caddy…), ce qui engendre une grande complexité, il a décidé de soigner le mal à la racine et de proposer cette fois un serveur tout-en-un écrit en Go, contenant à la fois PHP et un serveur Caddy. FrankenPHP propose un mode worker qui permet de ne booter qu’une seule fois l’application, de la garder en mémoire et de ne réinitialiser que le contexte de la requête afin de gagner en performance, il propose aussi un support natif du nouveau statut 103 Early Hint et inclut Mercure pour la communication en temps réel avec le front.

\\n\\n\\n\\n

Encore au stade expérimental, FrankenPHP permettrait à terme de simplifier le déploiement de nos applications PHP en production avec un conteneur unique pour les gouverner tous.

\\n\\n\\n\\n

Pour plus d’informations, rendez-vous sur ses slides.

\\n\\n\\n\\n

Compte-rendu rédigé par Jérôme.

\\n\\n\\n\\n

Piochons dans les pratiques de DDD, programmation fonctionnelle and co pour notre bien à tous

\\n\\n\\n\\n

Benjamin Rambaud nous propose dans son talk de nous inspirer des pratiques du DDD et de la programmation fonctionnelle, pour les intégrer dans notre code. Il revient sur certains concepts les plus connus, et qui peuvent facilement être intégrés dans un projet existant ou un nouveau projet.

\\n\\n\\n\\n

Il nous propose de nous inspirer des différentes philosophies de développement et d’architecture pour piocher des éléments qui permettent d’améliorer la communication, la testabilité ou la qualité d’un projet.

\\n\\n\\n\\n

Par exemple, le concept d’Ubiquitous Language harmonise le vocabulaire utilisé par tous les acteurs d’un projet et améliore la compréhension du projet et la communication. L’architecture hexagonale avec des ports / adaptateurs, isole la logique et le domaine du monde extérieur.

\\n\\n\\n\\n

Il nous invite également à profiter du fait que PHP est un langage multi-paradigme et qu’il ne faut pas hésiter à utiliser le paradigme adapté à notre besoin, en s’appuyant par exemple sur les outils et principes proposés par la programmation fonctionnelle : les fonctions pures, les value objects, l’immutabilité, ou les fonctions anonymes.

\\n\\n\\n\\n

Le Domain-Driven Design est une philosophie permettant de résoudre des problèmes dans des domaines complexes, en modélisant le domaine de la façon la plus riche et la plus explicite possible, afin d’améliorer la compréhension du métier de tous. Il y a beaucoup de notions et de patterns tactiques proposés pour l’implémenter, mais l’objectif central reste d’isoler le domaine. Le reste des choix techniques est secondaire.

\\n\\n\\n\\n

Enfin Benjamin nous conseille vivement, au travers d’un exemple concret reposant sur l’implémentation d’une fonctionnalité au sein de Drupal, de ne pas nous battre contre le framework, mais plutôt de travailler à isoler notre métier du framework, de la façon que l’on souhaite, en utilisant des principes piochés au sein de la programmation fonctionnelle, du DDD ou d’autres principes. Le fait de connaître son framework permet de sortir de l’usage généralement très orienté RAD qu’il propose par défaut et de l’utiliser de la meilleure façon pour notre besoin. L’objectif étant d’obtenir du code simple, explicite, que l’on peut typer et tester facilement.

\\n\\n\\n\\n

Benjamin conclut en nous invitant à tester d’autres langages proposant des approches différentes afin de nourrir nos imaginaires.

\\n\\n\\n\\n

Compte-rendu rédigé par Marion.

\\n\\n\\n\\n

Sortir du cadre

\\n\\n\\n\\n

Dans cette conférence, notre coopérateur Robin Chalas, membre de la core-team Symfony, nous partage son expérience pour adapter notre framework PHP préféré, Symfony, et le modeler à notre usage.

\\n\\n\\n\\n

Salle comble pour notre coopérateur @chalas_r au #ForumPHP avec son talk « Sortir du cadre » ? pic.twitter.com/iI2jeCKVnp

— Les-Tilleuls.coop (@coopTilleuls) October 14, 2022
\\n\\n\\n\\n

Même si cela s’adapte bien sûr à tous les frameworks. Dans cette conférence, il nous passe en revue la configuration par défaut proposée par Symfony dans ses dernières versions, et la possibilité qui nous est offerte de la modifier, ou non, et de l’intérêt que cela peut avoir. Les deux gros dossiers principaux étant src et config.

\\n\\n\\n\\n

S’il est possible de changer la structure des dossiers racines (en dehors du nom du répertoire config), cela n’a généralement pas d’intérêt de casser ce standard facile à comprendre par tous les développeurs car inspiré de Unix, sauf en cas de contraintes infra.

\\n\\n\\n\\n

En revanche, il est possible et il est même encouragé d’ajouter des fichiers et dossiers pour organiser le code, notamment isoler les outils de QA, ou les configurations de déploiement infra, en évitant de tomber dans l’excès et sans oublier de documenter d’éventuelles pratiques peu communes.
Robin nous a ensuite passé en revue le contenu du répertoire config, l’occasion de réexpliquer le fonctionnement de Symfony Flex, le plugin Composer qui ajoute lui-même la configuration nécessaire au core de Symfony et aux bundles tierces, et réalise également les mises à jour vers les nouvelles versions (grâce à composer recipes:update).

\\n\\n\\n\\n

Robin nous rappelle aussi à quel point le framework doit s’adapter à nos besoins et non l’inverse, et qu’il faut absolument éviter de laisser la technique empiéter sur nos besoins métiers. En évitant notamment les structures de répertoire orientées pure technique, sans possibilité de comprendre le métier à la première lecture sans entrer dans le détail.

\\n\\n\\n\\n

Au fil de ses versions et de sa maturité, le framework Symfony nous permet d’avoir cette souplesse de configuration, avec de moins en moins de contraintes de nommage, notamment grâce aux évolutions du langage PHP dont Symfony tire le meilleur profit pour améliorer notre quotidien de développeur·euse.

\\n\\n\\n\\n

Finalement un talk très en lien avec celui de Benjamin Rambaud, qui nous invite à sortir du cadre, à ne pas se laisser aveugler par la proposition par défaut très “RAD” des frameworks, à s’ouvrir un peu l’esprit à d’autres architectures et méthodologies sans être obligé de l’embrasser dans sa totalité.

\\n\\n\\n\\n

Compte-rendu rédigé par Marion.

\\n\\n\\n\\n

Protégez votre application avec l’en-tête HTTP de sécurité “Content Security Policy”

\\n\\n\\n\\n

Laurent Brunet nous présente les Content Security Policy, qui est une stratégie de sécurité permettant entre autres de se protéger de failles XSS. Elle consiste en un en-tête Content-Security-Directive(-Report-Only) qui définit des directives de sécurité séparées les unes des autres par des points-virgules. Il y a trois versions qui ont déjà été publiées.

\\n\\n\\n\\n

Les CSP permettent d’éviter certaines menaces :

\\n\\n\\n\\n
  • Les failles XSS : la directive “script-src” permet d’ajouter une liste blanche des scripts externes autorisés. En 2016, Google a publié une étude révélant que la liste blanche serait non sécurisée et propose une nouvelle façon de gérer les scripts en utilisant  “script-dynamic” en valeur de “script-src”i. 
  • Le clickjacking (une Iframe en transparence renvoyant sur un site malveillant)
  • On sécurise les protocoles 
  • On prévient le magecart ou formjacking (attaques permettant de récupérer les données d’un formulaire en créant par exemple des noms de domaines très similaires afin de récupérer des numéros de cartes banquaires). Pour contrer cela, on ajoute dans des bibliothèques des scripts récupérant des données de formulaire et on les envoie en Ajax sur de faux noms de domaine.
\\n\\n\\n\\n

En complément, il nous recommande l’application https://csp-evaluator.withgoogle.com/ pour vérifier et valider ces politiques de sécurité ainsi que cette source

\\n\\n\\n\\n

Compte-rendu rédigé par Quentin.

\\n\\n\\n\\n

Une édition qui a tenu toutes ses promesses

\\n\\n\\n\\n

Encore une fois, l’AFUP a fait preuve d’un extrême professionnalisme en proposant à sa communauté deux jours de conférences inédites avec des invité·e·s de renom. Rappelons qu’en complément à Amélie Deffrennes, leur salariée, l’AFUP est coordonnée uniquement par des bénévoles qui œuvrent sur leur temps libre diverses actions pour promouvoir le langage PHP. Notre coopérative est très attachée par cette association et compte parmi ses salarié·e·s plusieurs bénévoles qui l’accompagnent sur différents pôles.

\\n\\n\\n\\n

Quant au Forum PHP en lui-même, il a répondu à toutes nos promesses que ce soit en tant que spectateurs·trices ou en tant que sponsor. Notre stand a eu de multiples visites, Antoine Bluchet a fait salle comble lors de sa démo programmée le vendredi et en parallèle, nous avons eu la chance d’animer un Twitter Space en direct permettant de tâter la température des participant·e·s sur les conférences en cours.

\\n\\n\\n\\n

Merci encore une fois à l’AFUP pour cette belle édition et nous, on se donne rendez-vous la semaine prochaine à Łódź à l’occasion de la Sylius Con !

\\n\"","author":{"@type":"Person","name":"Les-Tilleuls.coop"},"publisher":{"@type":"Organization","name":"Les-Tilleuls.coop","url":"https://les-tilleuls.coop","logo":{"@type":"ImageObject","url":"/public/logo.svg"}},"image":"https://api.les-tilleuls.coop/wp-content/uploads/2022/10/vignette-forum-768x460.png","headline":"Ce qu'il faut retenir du Forum PHP 2022 - partie 2"}
Le blog

Pour aller plus loin