Who Run The Tech 2024 : Ce que les dev’ de la Cool Team ont appris

Nos développeurs ont ainsi pu tester le degré de leur savoir sur différents domaines allant de la cybersécurité aux pratiques du craft, en passant par des approches de code pure, de conception, d’organisation du travail. Parce que c’est aussi, et surtout ça, le métier de dév, c’est entraîner sa curiosité, cultiver la remise en question de ses acquis, et nourrir ses compétences auprès de ses pairs.

Erwan, Florence et Marie vous proposent un top 5 des conférences auxquelles ils ont pu participer tout au long d’une journée d’événement comptabilisant pas moins d’une trentaine de conférences, quickies et ateliers. On va vous parler des choses qu’on a apprises, celles qui nous ont marquées et ce qu’on compte faire de ces nouveaux savoirs dans notre métier de tous les jours.

Erwan, notre Cool ingénieur, a assisté à la conférence d’Alex Palma, développeuse font-end chez Zenika Brest, portant sur la Jamstack.

De quoi on parle ?

La Jamstack, acronyme de Javascript API Markup, est une approche, une architecture utilisée pour construire des sites web. Elle a été créée en 2015 par Mathias Biilmann, PDG de la firme de cloud computing Netlify.

L’objet de la conférence mettait en lumière l’obsolescence critiquée de cette architecture. Décrite comme « trop vieille » et « plus adaptée » par les développeurs, notamment face aux évolutions du secteur (les sites ultra personnalisés et très dynamiques), ou à l’apparition de frameworks plus modernes comme Next.js, entre autres.

Qu’est-ce qu’on a appris ?

Aujourd’hui, la Jamstack est encore massivement utilisée, sans que cette étiquette soit forcément collée sur ses lignes de code. C’est une pratique qui est entrée dans les fondements du développement front-end, pour en faire complètement partie. Elle permet notamment de travailler sur un front autonome et autosuffisant, permettant de créer des applications réfléchies sous l’angle de l’écoconception.

La désuétude n’est pas une caractéristique de la Jamstack qui reste pertinente pour des projets relativement simples et statiques, comme des sites vitrine, des landing pages, ou la création de blogs. L’approche se révélera moins adaptée pour des projets interactifs, où le dynamique est omniprésent.

Qu’est-ce qu’on va appliquer ?

L’adage « Être statique par défaut et appliquer de la complexité s’il faut » est une pratique intéressante mise en avant par Alex qui propose de profiter de la Jamstack pour ce qu’elle a à offrir d’efficace et de stable, à savoir minimiser les couches successives de dynamismes quand il n’y a pas d’objectif concret.

Nos deux développeuses Florence et Marie sont pu participer à l’atelier proposé par Jacqueline Rwanyindo, Ingénieure logiciel, chez Ippon Technologies abordant la pratique du TDD.

De quoi on parle ?

Le TDD est une pratique Craft qui permet de concevoir des logiciels par itérations successives très courtes. Chaque itération est réalisée grâce à la résolution d’un problème dédié, via l’exécution de tests, et la prise en compte de feedback. Le code n’est créé qu’en dernière étape, et a pour vocation d’être le plus simple possible.

L’une des pratiques les plus courantes, et les plus répandues en TDD, est le « Baby Steps », expliqué lors de l’atelier via la réalisation du kata FizzBuzz. 

Qu’est-ce qu’on a appris ?

Le kata met en lumière l’importance de la rédaction de tests en amont de la rédaction du code. Prévoir ses tests permet de :

• Alléger la charge mentale
• Organiser son travail
• Gagner du temps pour produire un code de qualité, puisque cette réflexion force les développeur.eures à anticiper les anomalies

 Qu’est-ce qu’on va appliquer ?

La rédaction de listes de tests est une pratique que l’on compte appliquer dans nos méthodologies, suivant deux temporalités : en phrase de conception et en phase de développement (production de code).

Nous étions plusieurs membres de l’agence à assister à cette conférence, quelque peu intrigués par le titre et encore plus par le contenu. Dorra Bartaguiz, CTO chez Arolla, a magiquement transformé l’utilisation du « feature flip » en une liste de do’s and dont’s, pour finalement ne nous donner qu’une seule et bonne raison d’utiliser cette fonction : éviter de le faire. Malin.

 De quoi on parle ?

Le Feature flipping est un mécanisme permettant d’activer, ou désactiver une fonctionnalité directement en production, sans avoir à re-déployer du code.

Qu’est-ce qu’on a appris ?

Le feature flipping s’avère parfois problématique. On le déploie pour contrer les conséquences d’un code mal conçu, pour activer/désactiver un bout code non terminé, ou activer/désactiver une fonctionnalité qui vient d’être livrée, mais qui ne correspondrait pas à la demande du client.

Dorra Bartaguiz a créé cette conférence dans le but de désamorcer la mauvaise utilisation du feature flip, mais aussi et surtout, d’améliorer son utilisation chez les dévs.

Elle a présenté différentes méthodes de mise en action du feature flip, qui sont courantes, et plus ou moins saines comme :

• Trunk base developpement : Travailler sur le tronc commun du code, pas de branches
• Branch base development :  Utiliser une seule feature par branche, avec un merge en fin de développement
• Livraison partielle : Éviter l’effet tunnel pour réduire le cycle de vie des branches
• Activation selon contexte : Activer/désactiver selon des situations, des déclencheurs précis
• Dépendance externe : Activer/désactiver des fonctions selon les usages des utilisateurs finaux

Pour ne pas succomber à la solution de facilité, Dorra propose une alternative sécuritaire et pérenne : le Circuit breaker.

Qu’est-ce qu’on va appliquer ?

Même si, de base, la technique du feature flip est peu utilisée dans les principes de développement de nos Cool Devs, elle reste une méthode intéressante de part ce qu’elle révèle. Elle appuie l’importance de réfléchir avant de coder. Réfléchir sa conception est essentiel pour éviter l’abus du feature flip, qui en plus de rendre impossible la maintenance d’une application, ne permet pas de créer du code simple et clair.

La réflexion de la conception passe par le découpage des tâches en amont, l’implication du Métier et des Utilisateurs finaux, méthodo déjà largement inscrite dans nos principes de dev, mais qu’on peut étoffer grâce au mind mapping.

Nos trois développeurs ont assisté à la conférence de Hafsa Elmaizi, Développeuse Back-End chez SII, pour tenter d’en apprendre plus au sujet des pipelines CI/CD.

De quoi on parle ?

Un pipeline est une série d’étapes à suivre lorsqu’on déploie du code, qui permet de vérifier la qualité du code, sa sécurité et sa fiabilité. Les pipelines permettent également de déployer automatiquement le code sur un serveur.

Qu’est-ce qu’on a appris ?

Comprendre ses pipelines, c’est cool ! Savoir écrire ses pipelines, c’est encore plus cool ! Généralement pris en charge par les DevOps, la configuration de pipeline par les développeur.euses comporte de nombreux avantages :

• • Responsabilisation des équipes de développement sur le déploiement
  • Alignement des équipes de dev et devOps
  • Détection et résolution rapide d’erreurs de déploiement
  • Optimisation sur la qualité de code
  • Anticipation et adaptabilité en cas d’incident et autres

Grâce à cette compétence, on peut facilement :

• • Lancer des tests unitaires & d’intégration
  • Réaliser des tests de charge
  • Tester différents niveaux de sécurité (code, dépendance, etc.)
  • S’assurer des livraisons continues vérifiées

Qu’est-ce qu’on va appliquer ?

Des templates de configuration de pipelines existent et ils pourraient se révéler intéressants à étudier, dans le cadre de nos projets futurs.

Notre développeuse-to-be Marie a assisté à la conférence de Valérie Viet Triem Tong, Professeure en Cybersécurité à la CentraleSupelec, et chercheuse, sur les scénarii plus ou moins longs d’attaques sur des systèmes d’information.

De quoi on parle ?

Valérie Viet Triem Tong propose de plonger avec elle dans son sujet d’étude de prédilection, sujet auquel elle a déjà dédié 10 ans de sa carrière, les APT.

APT signifie « Advanced Persistent Threats », et désigne un attaquant avec un objectif, qui va prendre le temps nécessaire, parfois des années, pour s’infiltrer dans un SI. Les APT sont les attaques les plus difficiles à reconnaître et à anticiper. Ce type d’attaque étant très peu documentée du fait du protectionnisme des entreprises sur cette typologie de crise interne.

Qu’est-ce qu’on a appris ?

Malgré le manque de ressources et de data, un Cyber Kill Chain est créé en 2011, permettant d’identifier plusieurs étapes dans les attaques APT :

1. Entrée dans le SI par une des nombreuses entrées : à ce stade, l’attaquant ne sait pas vraiment où il se trouve, et doit donc « explorer » autour de lui
2. Propagation dans le réseau : prendre le maximum d’informations, jusqu’à trouver le service cible, souvent de manière visible
3. Il disparaît, travaille en parallèle pour simuler l’attaque grâce aux infos qu’ils a récupérées. Cette phase d’essai/erreur peut durer des semaines, mois ou années avant de produire une version « finalisée » d’intrusion
4. Il revient avec son attaque consolidée

Bien que les premiers modèles apparaissent, le manque de données réelles freine la recherche. En effet, une application attaquée sera très souvent immédiatement, ne permettant pas de garder une photo de l’instant T de l’attaque.

Pour remédier à cette pénurie, Valérie Viet Triem Tong lance un appel aux entreprises favorables à un travail avec son équipe, dans le but de faire avancer les recherches scientifiques pour faire évoluer le modèle, en collaboration avec Pirat/’) ;, son collectif de chercheur.euses.

Qu’est-ce qu’on va appliquer ?

Les conseils simples, mais efficaces, de Valérie sur les réflexes cybers accessibles :

– Changer son mot de passe régulièrement

– Éviter les doublons d’identifiants

– Mettre en place routine régulière de ces changements

Autant de pratiques que l’on souhaite enseigner de manière systématique à nos clients, comme un devoir professionnel, notre serment d’Hippocrate à nous.