DevFest Lille 2024 : highlights et conférences marquantes

Les 06 et 07 juin derniers se tenait la 7ème édition du DEVFEST Lille, au Grand Palais. En tant que partenaire de cet évènement, nous avons activement participé à ces deux jours de rendez-vous et conférences, à la rencontre des acteurs incontournables du marché qui, pour la première fois, s’étendait sur deux journées.

En effet, ce sont chaque année près de 1500 visiteurs qui profitent de cette occasion pour approfondir leurs connaissances sur les technologies émergentes, interagir avec leurs pairs et rencontrer les quelque 40 acteurs présents.

La promesse d’un programme conférencier riche a elle aussi été tenue avec près de 60 speakers pour 44 talks. Laquelle a été votre favorite ? Avez-vous pu assister à celle de Vivien Malèze sur OpenTelemetry ? On vous résume tout !

A travers un REX, notre Architecte Manager Senior Vivien Malèze a été sélectionné pour son talk sur OpenTelemetry le jeudi après-midi. Voici un résumé de son intervention :

OpenTelemetry (ou otel de son petit nom), c'est un framework d'observabilité qui permet de collecter les données de télémétries (logs, metrics, traces) et ensuite de les envoyer vers un backend de traitement de données. Plutôt que de rester dans la théorie et d'avoir un simple poc qui fonctionne, Vivien nous présente comment concrètement mettre en place cette solution pour un usage en prod ou tourne déjà environ 300 instances de microservices.

Il nous a notamment présenté le collecteur, un service fourni par otel qui permet de collecter, traiter et propager les données de manière centralisée. A travers un exemple, nous avons pu voir la puissance de cet outil et comment facilement tracer une requête, la lier à des logs, et l'analyser.

Pour finir, nous avons pu voir (enfin presque, merci l'effet démo) comment réduire l'impact de notre infrastructure via une mécanique d'auto-scalabilité basée sur les metrics fournies par Opentelemetry.

Nos Ippons qui ont également eu la chance d’assister à certaines conférences vous partagent leurs notes. Nous vous résumons nos 2 talks préférés : 

“Le produit entre la qualité et l'Over-Engineering” - Jihène Mejri (par Aymeric VANDEWOORDE)

L'objectif premier de la conférence est de présenter ce qu'est l'over-engineering ainsi que les pièges à éviter afin de limiter le développement de solutions trop complexes. Le sujet est introduit avec une analogie à l'automobile : une voiture est composée de composants fixes tels que les portes, les fenêtres ou les roues. L'over-engineering sur ce genre de véhicules serait de rajouter des parties non nécessaires à la voiture pouvant ainsi complexifier sa construction ou son utilisation. Par exemple, une voiture a 6 roues. Malgré que cela soit simple à détecter sur un engin mécanique, ce genre de comportement est plus difficile à détecter dans une application.

Quelques exemples d'over-engineering dans l'informatique :

• Mise en commun de code sans prendre en compte les logiques métier, par exemple via l'utilisation non pertinente de types génériques afin d'éviter la duplication : cela lie des fonctionnalités entre elles sans pour autant avoir un intérêt métier commun. Toucher à la fonctionnalité aura des impacts plus importants, voire non prévus.
• Sauvegarde inutile d'information en base de données pour prévoir des potentielles futures exigences.
• Stockage d'informations massives : complexifie les tâches de maintenance, migration et évolution de la base de données, en plus de générer des coûts de stockage.

Quand est-ce qu'on peut déterminer qu'une application est qualitative ?

Si l'on prend la définition de Wikipédia, la qualité logicielle serait de mesurer la capacité d'une application à correspondre aux exigences fonctionnelles (inscription, navigation, rendu des pages, fonctionnalités) ou non fonctionnelles (maintenabilité, fiabilité, sécurité).

Le problème de cette définition est que la qualité logicielle est présentée comme un rétroviseur : c'est une fois que l'application est utilisée qu'on peut la mesurer. Il faut donc absolument se rapprocher de la cible : si on développe un logiciel avec une charge prévue d'un million d'utilisateurs, mais qu'elle est au final utilisé par 50 d’entre eux, le produit aura coûté plus cher que ce qui était nécessaire. A l'inverse, cela rend l'application instable et génère de la maintenance.

Il existe des métriques permettant de contrôler cela, notamment le Triangle QCD (Qualité/ Coût / Durée) : 

• Si l'on garde en équilibre que la qualité et le coût, on va se retrouver avec un projet lent à développer.
• Si l'on garde en équilibre la qualité et la durée de développement, le projet va être coûteux.
• Si l'on garde en équilibre le coût et la durée de développement, le projet sera bâclé.

Cette métrique a été popularisée dans les années 90. De nos jours, on utilise un autre type de métrique : les métriques DORA (DevOps Research & Assessement), popularisées par une entreprise du même nom, rachetées par Google Cloud en 2018. Le but premier était de scanner les bonnes pratiques à instaurer dans une équipe afin d'améliorer ses performances tout au long d'un projet.

Deux facteurs principaux sont au cœur de ces métriques : la fiabilité et le rendement. La notion du coût est implicite car indirectement intégré dans cette balance. Celle-ci se base sur 4 métriques principales, 2 de rapidité (Fréquence de déploiement, Délai d'exécution des changements), et 2 de qualité (Délai moyen de rétablissement, Taux d'échec de chargement). Les études publiées montrent que 44% du temps alloué aux équipes poussant au maximum ces indicateurs était alloué au développement de nouvelles features, permettant ainsi d'utiliser leur temps de manière plus optimale afin de créer de la valeur ajoutée.

Référence pour approfondissement du sujet: Livre "Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations"

Les raisons qui poussent l'over engineering :

• Un manque d'objectif clair : beaucoup de retouches dues au fait que l'objectif n'est pas atteint.
• Une mauvaise priorisation des sujets : les ressources allouées aux sujets à forte valeur ajoutée sont ainsi fortement diminuées.
• Une mauvaise communication : cela multiplie la durée et l'intensité des échanges, générant beaucoup d'aller-retours pour des fois une petite incompréhension du sujet.
• De vagues échéances : trop de temps alloué retardera le projet
• Des délais irréalistes : bacle la qualité, génère des bugs ou des comportements non prévus ainsi que de la maintenance.

L'over engineering ne touche pas forcément que la technique. Si l’on prend une équipe avec une organisation complexe, les échanges deviennent de plus en plus longs (besoin de validation de plus de couches, nécessité d'allouer le temps de plus de personnes) et compliqués (perte d'informations en cours de route, besoin de s'assurer que plus de personnes comprennent la cible).

La conférence se clôture sur des solutions proposées afin de limiter l'over engineering : communiquer les objectifs clairement, définir des délais clairs et réalistes, adaptés à l'équipe mise en place, arrêter d'être dogmatique, suivre le principe YAGNI (you ain't gonna need it).

“Master Web Scraping: Devenez un ninja de la data extraction !” - Fabien Vauchelles (par Aymeric VANDEWOORDE)

La conférence est sous format live-coding, le but général étant d'expliquer ce qu'est le web scrapping, et de montrer par un exemple comment le mettre en place grâce à Scraproxy, ainsi que le type de difficultés potentiellement rencontrées.

Scraproxy est un outil open source (https://github.com/fabienvauchelles/scrapoxy) qui se comporte comme un proxy de proxy. Le présentateur nous met dans le contexte d'Isabella, une personne qui adore voyager. Elle souhaite au mieux préparer son voyage, mais ne veut pas aller sur chaque hôtel de son outil de voyage préféré. Elle souhaiterait donc que ce soit un outil qui aille, selon ses critères, rechercher les hôtels, leur prix, ainsi que les avis clients les plus récents.

Étant douée pour la programmation, elle décide de créer un script d'extraction de masse. Mais est-ce légal ?

La réponse est... ça dépend.

Pour rester dans la légalité, un déni de service ne doit pas être provoqué par l'extraction (surcharge du serveur dû à la multiplication des requêtes). Pour le vérifier : regarder le temps de latence du serveur. Si il augmente exponentiellement, il faut réduire la charge du site web. Il ne faut pas récupérer non plus de données à caractère personnel (se référencer à la RGPD). Il ne faut pas qu'une authentification soit nécessaire, la plupart des sites ont des termes & conditions qui sont acceptés à la création du compte.

Si tout est bon, alors il n'y a rien qui l'interdit.

Le déroulé d'une extraction :

Le but étant de réaliser un enchaînement de requêtes HTTP, reproduisant le cheminement d'un utilisateur, et en se basant sur les réponses serveur afin d'adapter les requêtes HTTP selon le nombre de résultats. Isabella va donc réaliser cela via l'aide d'un framework : Scrappy.

Scrappy est un framework open source développé en Python (https://scrapy.org/). Il est le framework le plus utilisé pour l'extraction de données de masse sur les sites web au vu de sa versatilité : il permet de gérer les accès concurrents, possède un parser HTML intégré, un système de retry intégré et bien d'autres fonctionnalités. Scrappy fait tourner des spiders, un spider étant toute la logique de code nécessaire pour aller chercher les données d'un site web en passant la DOM de la page.

La suite de la présentation est divisée par niveau de sécurité du site web : 

• Au premier niveau, le site n'a pas de protection, un simple parseur des classes CSS afin de récupérer les données.
• Le deuxième niveau ajoute des sécurités sur l'identité du navigateur. Quand on navigue sur un site web, des headers HTTP sont ajoutés selon l'OS de l'utilisateur et son navigateur. La simulation de ces headers par quelque chose d'existant permet de passer cette sécurité.
• Le troisième niveau est un blocage dû à une multiplication des requêtes en provenance d'une même machine. Il est donc nécessaire de rajouter un proxy. 

Qu'est-ce qu'un proxy ? Un proxy est un outil permettant de transférer les requêtes d'une source vers une autre en prêtant son identité (utilisation de son adresse IP). Ainsi, au lieu de voir des milliers de requêtes venant d'une adresse IP, il voit des milliers de requêtes venant de milliers d'adresses IPs différentes. Scraproxy est donc utilisé pour démarrer des "fermes de proxy". Une démonstration est fournie en allouant des proxys via AWS.

• Le quatrième niveau met en évidence un élément de la réalité : la plupart des fermes de proxy sont connues des sites webs, ainsi il leur est possible de mettre une protection empêchant ces plages d'adresses IP de requêter le serveur. Pour contourner le problème, il suffit de louer des adresses IP ISP : des adresses IP résidentielles. Ce sont donc des adresses IP de monsieur et madame Toutlemonde. Généralement, le coût est supérieur à celui d'une location de datacenters.
• Le cinquième niveau est une sécurité présente sur la plupart des sites web: une limite de requêtes par seconde par IP. Le seul moyen de détourner cela est d'y aller pas à pas afin de maximiser le nombre de sessions ouvertes par adresses IP à la fois.
• Le niveau 6 présente un nouveau type de sécurité: le fingerprint. Celui-ci envoie des informations propres à la machine à intervalles réguliers. S' il ne reçoit pas d'informations, la session est interrompue. Ces requêtes étant déclenchées par des scripts JS, il est nécessaire de, ce coup ci, utiliser un vrai navigateur.

Le présentateur nous introduit donc playwright (https://playwright.dev/), une librairie open-source permettant de simuler des clics utilisateurs sur un navigateur piloté grâce à cette librairie. Scrappy, ayant un module permettant l'utilisation de playwright, rend possible de naviguer avec, ce coup ci un vrai navigateur. Pour le serveur, il voit donc un utilisateur classique avec un navigateur ayant toutes les fonctionnalités de base dont l'exécution de script javascript.

• Le niveau 7 nous présente un problème de consistance : le serveur vérifie désormais que toutes les informations envoyées sont cohérentes, par exemple pour notre cas, que la session initiée correspond bien à la timezone des requêtes http. Il est maintenant nécessaire de s'assurer de la cohérence des informations envoyées pour tromper le serveur.
• Le dernier niveau présenté s'agit du chiffrement de la fingerprint initiée lors du niveau 6. Il faut donc rechiffrer la fingerprint "à la main". Pour ce faire, il faut parcourir les scripts JS qui sont disponibles dans le code source du site web visible côté client.

Le code est souvent offusqué: il va falloir le désoffusquer. Le but est de savoir ce qu'on envoie, et comment on le chiffre. L'exemple montré est une technique appelée le string concealing : il s'agit de chiffrer des chaînes de caractères, par exemple en Base64. En appliquant l'opération inverse sur une fingerprint récoltée préalablement, il est possible de voir ce que contient la fingerprint et d'ainsi reproduire le comportement du serveur et de le tromper en envoyant des données cohérentes.

Pour plus d'informations, vous pouvez retrouver cette démonstration directement via ce lien.

Replays et debriefs : 

Pssst : l’ensemble des replays du salon sont juste ici sur Youtube !

Nous vous donnons rendez-vous pour le prochain DEVFEST Nantes, auquel nous participons les 17 et 18 octobre prochains ! :)