Introduction

Le DevLille est un événement de deux jours dédié à la tech qui a lieu tous les ans à Lille. C’est un événement auquel je me rends maintenant depuis plusieurs années et je n’ai jamais été déçu. Cette année, j’ai décidé d’écrire un billet de blog sur les conférences que j’ai suivies et ce que j’en ai pensé. C’est parti !

Jeudi

Éloge de la simplicité - Frédéric Leguédois

Le traditionnel keynote d’ouverture abordait cette fois-ci les sujets de gestion de projet et de planification agile.

Le point principal que je retiens de cette conférence est qu’on ne devient pas “agile” en claquant des doigts et en renommant son planning en backlog.

Le présentateur expose sa perspective selon laquelle prédire l’avenir est une perte de temps. Ce sur quoi nous devons nous concentrer, c’est ce qui répond aux besoins de nos utilisateurs maintenant.

On a eu droit à une définition amusante de ce qu’est un planning : “Un planning, c’est ce qu’on est sûr de ne pas faire maintenant et qui sera faux à partir de demain.”

Bien que je sois assez séduit par cette définition, je me demande comment intégrer les besoins non fonctionnels dans cette approche. Je pense par exemple à la sécurité, à la maintenabilité ou aux performances de nos applications. Ces points servent également nos utilisateurs, même s’ils le font d’une manière peut-être plus indirecte.

Est venue ensuite la question de comment prioriser les sujets, en ironisant sur le fait que les estimations, à la fois de temps à investir et de bénéfices sur un sujet, étaient très peu fiables en général. Naturellement, le calcul de ROI s’approcherait plus de la divination que de la science, ce qui est, je pense, une très bonne manière de voir les choses.

La solution proposée était de prendre les problèmes les plus importants pour les utilisateurs et d’y apporter une des solutions les plus simples parmi les solutions proposées par les développeurs. J’ai une petite réserve sur ce dernier point : tout le monde conviendra qu’une solution plus simple est préférable à une solution compliquée. Mais d’expérience, la simplicité ne s’atteint pas au premier jet, il faut travailler plusieurs fois pour mieux comprendre le problème et venir avec des solutions plus élégantes. Sur ce point, je pense que les méthodes itératives prônées par le conférencier sont tout à fait pertinentes.

La conférence était très bien présentée et très agréable à suivre, avec une bonne pointe d’humour.

Et si on ouvrait le capot de PostgreSQL ? - Coenen Benjamin

Une présentation très technique, comme je les aime, mais qui tient en 45 minutes. L’idée ici était de comprendre comment PostgreSQL fonctionne sous le capot. Au menu :

• Comment ses fichiers sont structurés sur le filesystem
• Comment ses différents processus sont architecturés et communiquent entre eux
• Comment les requêtes sont exécutées
• Le modèle autour des transactions
• Le VACUUM
• Le WAL (pour gérer les crashs et la réplication)

Je ne vais pas entrer dans le détail de tous ces points ici, je vous invite vivement à regarder la VOD une fois qu’elle sera disponible. Je mettrai le lien ici quand ce sera le cas.

Un des points qui m’a questionné pendant la présentation est le fait que beaucoup de processus PostgreSQL sont là pour faire la synchronisation entre l’état en mémoire et l’état sur le filesystem. Ceci est fait pour des raisons de performance afin de ne pas devoir attendre une écriture disque à chaque requête.

Mais pourtant, PostgreSQL va écrire dans le WAL à chaque transaction, on a donc de toute façon une écriture disque. Je suis allé voir le présentateur pour lui poser la question.

La différence essentielle, c’est qu’écrire dans le WAL est moins coûteux car on écrit en continu dedans, tandis que les fichiers de données peuvent demander plus de temps pour être écrits.

Noms de domaines : la grande histoire des petites extensions - Benoît Masson et Théo Bougé

Une conférence sur le fonctionnement des TLD DNS. J’ai appris, par exemple, que les noms de domaine peuvent supporter des caractères non ASCII grâce à une petite transformation qui est donc transparente pour l’utilisateur.

On a pu évoquer le fait que certains TLD (Top Level Domain) que nous utilisons régulièrement correspondent en fait à des pays. Par exemple :

• .tv : Tuvalu (une île dans le pacifique)
• .ai : Anguilla (une île dans les caraïbes)
• .yt : Mayotte
• .rs : Serbie

Cette présentation a évoqué le rôle central de l’ICANN (Internet Corporation for Assigned Names and Numbers), qui pose quand même question. Même si c’est une structure à but non lucratif, cela reste une structure américaine qui possède un pouvoir existentiel sur le web.

Le bug n’est pas dans le code ! J’ai enfin compris pourquoi 50% des femmes quittent la tech avant 35 ans - Vanessa Chodaton

Une présentation super intéressante sur quelques “bugs” qui peuvent rendre l’atmosphère dans la tech hostile aux femmes, mais pas seulement. En partant de cette statistique qui dit que 50 % des femmes quittent la tech avant 35 ans.

Les 4 bugs cités étaient :

• Confondre vélocité et compétence, c’est-à-dire ne pas prendre en compte tout le travail invisible comme aider un de ses collègues, le mentorat ou même les revues de code.
• Les biais, particulièrement ceux de genre où l’on attribue une présomption de compétence aux hommes et d’incompétence aux femmes.
• Les environnements toxiques qui comportent les micro-agressions, le manque de respect et la tolérance aux profils toxiques.
• La responsabilité personnelle où, à force de devoir prouver, de douter et de vouloir tenir bon, on peut s’épuiser.

C’était éclairant et je vais tenter de garder ces éléments en tête autour de moi pour promouvoir un espace de travail le plus agréable possible. J’ai beaucoup aimé la conclusion :

*“On ne quitte pas la tech parce qu’on ne l’aime plus, mais parce qu’on en a marre de se battre.”

Pourquoi personne n’aime relire ta Pull Request - Maxime Clément

Vaste sujet que les revues de pull requests. Cette conférence consistait à évoquer quels sont les éléments d’une bonne PR pour faciliter la revue.

Le point saillant étant que les PR doivent raconter une histoire à celui qui va la relire, en faisant un nombre de commits raisonnable mais qui découpent la PR en plusieurs arcs dans cette histoire. Ceci est faisable notamment en utilisant les rebases pour réécrire l’historique afin de le rendre clair et linéaire.

Ce sont déjà des pratiques que je m’efforce de mettre en œuvre, mais je pense que j’y prêterai une attention toute particulière après cette conférence.

Le tout avec des analogies intéressantes et quelques résultats de psychologie, c’était très instructif.

Le vibe coding est mort, vive le spec coding - Aurélien Allienne

Est venu ensuite le segment IA de ma journée. Je ne suis pas un gros utilisateur d’IA et je trouve que cette technologie pose énormément de questions en termes de sobriété et de souveraineté. Mais je souhaitais en apprendre plus sur ces pratiques.

La prémisse de la conférence était la suivante : le vibe coding est peut-être acceptable pour un projet de week-end, mais difficile à maintenir dans le temps et peut engendrer de grosses failles de sécurité.

Pour répondre à ces difficultés tout en profitant du pouvoir de l’IA, le présentateur propose le spec coding, c’est-à-dire se concentrer exclusivement sur la spécification et pas sur le code. Tout ceci en utilisant un workflow bien défini dont chaque étape est importante : Planifier / Produire / Évaluer / Consolider, avec une démo à la clé.

Pour être honnête, je n’ai pas bien compris en quoi cette approche protégeait des failles de sécurité, car à la fin, c’est bien le code qui est exécuté. Si jamais vous y étiez et que vous avez mieux compris que moi, n’hésitez pas à me le partager.

ClaudeCode.proTips(20, minutes=20).run() - Erwan Gereec

Une compilation d’astuces pour l’utilisation de Claude Code. Je ne suis pas utilisateur de l’outil (ni d’un équivalent d’ailleurs), mais malgré tout, les explications étaient claires et je me les note dans un coin pour quand je regarderai ce genre d’outil.

Cela m’a quand même donné envie de tester ce genre d’outil pour me faire mon propre avis, en gardant en tête les réserves que j’ai citées plus haut.

Déployer souvent, stresser moins : feature flags en prod critique - Marion Chineaud et Elise Souvannvong

J’ai enchaîné sur cette conférence qui évoquait les différentes stratégies pour permettre de déployer du code régulièrement sans impacter les utilisateurs avec une fonctionnalité qui ne serait pas prête. Tout ça à l’aide de feature flags. C’est une pratique que j’ai découverte en lisant “The DevOps Handbook” et que j’ai pu expérimenter, et je confirme que c’est vraiment une bonne manière de déployer de manière sécurisée.

Les présentatrices évoquaient différents types de flags pour différentes cibles (PM, dev, ops) puis différentes manières de les implémenter, soit en configuration à charger au démarrage, soit en base de données par exemple.

Je recommande de jeter un œil à cette conférence si jamais c’est quelque chose que vous ne pratiquez pas, ça change la vie !

De pionnières à invisibles : où sont passées les femmes dans l’informatique ? - Chloé Masse

J’adore les conférences techniques, mais aussi les conférences sur les sujets sociétaux en lien avec la tech. Celle-ci était une bonne manière de retracer l’histoire des grandes contributions féminines à l’informatique. Je dois bien avouer qu’à part Ada Lovelace, je ne connaissais pas les noms de ces pionnières comme Grace Hopper, Margaret Hamilton ou Alice Recoque.

La présentatrice fait le constat qu’à l’époque où la programmation était vue comme une tâche ingrate, c’était surtout les femmes qui y étaient affectées. Tandis que quand elle est devenue prestigieuse, ce sont les hommes qui s’y sont mis.

Puis elle a évoqué le sujet très juste de l’absence de représentation féminine dans nos métiers, qui ne pousse pas vraiment à visibiliser les femmes.

Ça m’a donné envie de creuser un peu plus l’histoire de ces femmes afin d’avoir une vision plus juste de ce qu’a été l’histoire de l’informatique.

Vendredi

Concevons nous toujours des applications pour les humains ? - Johnathan Meunier et Julien Gaudet

Le deuxième jour a commencé avec cette présentation d’un futur où l’on passerait par un agent quasiment pour tout organiser dans notre vie. Dans ce monde là, les interfaces utilisateurs (UI) perdraient en utilité, potentiellement remplacées par des serveurs MCP.

On a pu faire un détour par les sujets de dépendance aux GAFAM, de souveraineté et même la question de la place que l’on veut vraiment laisser à ces agents dans nos vies. J’ai particulièrement aimé ce passage qui est, je trouve, souvent passé sous silence au profit de la question de l’efficacité de ces outils.

L’un des arguments qui a été exposé est un que j’ai déjà entendu plusieurs fois, qui est le suivant : maintenant, on “coderait” en markdown, avec un LLM qui générerait du code source qui, lui-même, serait compilé vers du code machine. Un genre de : .md => .js => .c => .asm

Pour ma part, je pense que la réalité est un peu plus complexe, déjà par le fait que le résultat d’un compilateur est déterministe, alors que celui d’un LLM ne l’est pas. En plus de ça, il me semble intéressant de garder la connaissance et la maîtrise des étapes intermédiaires. Connaître son runtime JS permet d’écrire un code plus performant, et s’intéresser aux résultats du compilateur en Go ou en Rust peut être crucial également.

Une expérience de pensée intéressante en tout cas. On se donne rendez-vous dans le futur pour voir où tout cela nous mènera.

Garder les clés de ses données : Le chiffrement au service de la souveraineté - Aeddis Desauw

Une présentation des trois produits de gestion de clés chez OVH autour des HSM (Hardware Security Module) :

• Le Dedicated HSM où l’on loue son propre HSM : une solution chère et qui demande de maîtriser l’objet et l’interface du fabricant. C’est la solution qui donne le plus de contrôle au client.
• Key Management Service (KMS) : une solution complètement managée qui donne accès, via une API, à des clés qui sont stockées sur des HSM totalement gérés par OVH. La solution la plus simple, mais qui est moins performante et offre moins de segmentation.
• Managed HSM : une solution en cours de développement avec des HSM mutualisés mais qui sont eux-mêmes segmentés. OVH gère l’administration de ces boîtiers et offre une interface PKCS#11 qui permet de s’abstraire de la couche “fabricant” et qui offre de meilleures performances car on réserve une “fraction” du boîtier. Un bon entre-deux.

Très intéressant, et présenté par un membre du collectif CHATONS d’hébergeurs alternatifs. Si vous ne les connaissez pas et que vous vous intéressez à l’informatique libre, allez jeter un œil.

Et si votre database était la queue qu’il vous fallait ? - Julien Lampin

Le dernier talk de la matinée a évoqué une idée qui peut choquer au premier abord : utiliser sa base de données comme message broker. Le sujet principal, c’est de dire qu’il faut une solution adaptée à nos besoins. Parfois, Kafka, RabbitMQ ou Pub/Sub peuvent être overkill pour ce que l’on cherche à faire.

Avec quelques exemples de code basés sur MongoDB, le présentateur nous a montré comment on pouvait implémenter facilement tout un tas de propriétés avec une structure de table (ou de collection dans le cas de MongoDB) bien choisie.

Pour citer quelques exemples, on peut avoir envie de mettre en place une Dead Letter Queue, c’est-à-dire l’endroit où vont les tâches qui ont échoué. On peut facilement modéliser ça en ajoutant un statut spécifique dans notre table de tâches. Pas forcément besoin d’un message broker.

J’ai trouvé ce point de vue intéressant, et la conférence se termine sur un tableau récapitulatif des cas d’usage où utiliser sa BDD peut être intéressant et les cas où il faut absolument l’éviter, par exemple si on a besoin d’un ordering strict, dans ce cas Kafka reste le roi.

EcoScore A ou E : où se situe vraiment votre API ? - Emmanuel Peru

Aujourd’hui, la tech représente environ 4 % des émissions de gaz à effet de serre (GES), et ce n’est pas avec l’avènement de l’IA que ces émissions vont se réduire.

On a commencé par voir un certain nombre de chiffres sur les émissions de l’industrie. Par exemple, le fait que la consommation d’énergie est équitablement répartie entre la production des terminaux et leur utilisation. Pour d’autres types de sujets environnementaux (eau, matières premières), c’est surtout la production des terminaux qui est le principal problème. Mais le présentateur a rappelé très justement qu’il ne faut pas s’y tromper : l’augmentation de la puissance de calcul (et donc de la pollution) de nos machines vient aussi du fait que nos applications sont de plus en plus gourmandes.

S’en est suivie la présentation de deux frameworks pour évaluer le caractère énergivore de nos applications, à savoir API Green Score et EROOM. Le problème de ces méthodes de calcul, c’est qu’elles sont très différentes et se font en remplissant des tableurs. Le présentateur a donc fait une démo de l’outil sur lequel il travaille : zats-greenscore, qui permet de faire ce travail de manière un peu plus agréable.

C’est une bonne chose que ce genre de considérations soit pris en compte, surtout dans une industrie où l’on ne parle que de l’IA en ce moment, en ne s’embarrassant pas trop des impacts environnementaux et sociétaux de cette technologie.

Il semble cependant qu’il existe encore bien d’autres méthodologies de calcul. Vu de ma fenêtre, cela va demander encore un peu de temps avant que ces manières de faire soient un peu standardisées.

Reprenez le contrôle de votre plateforme data face aux géants américains - Jonathan Fritsch et Nathan Leclercq

On enchaîne ensuite avec une présentation sur comment faire sa plateforme data sans les géants de la tech américains, en partant d’une analogie très parlante entre un brasseur qui externaliserait sa production de bière à une société américaine et qui, donc, perdrait le contrôle de la recette et des prix.

L’idée était de montrer que construire une stack data est possible avec ses propres machines, des outils open-source et des compétences ops. Pour ça, les présentateurs se sont basés sur des protocoles et des outils open-source plutôt que des services. Ainsi, là où une plateforme data classique sur Google Cloud Platform (GCP) va ressembler à un mélange de BigQuery, Composer, Cloud Storage, etc., on va pouvoir faire sensiblement la même chose (avec un peu plus d’effort certes) avec des outils comme k3s, Airflow, Minio ou Garage pour la partie S3, le tout managé par Ansible.

Bien sûr, il faudra des compétences ops pour se lancer dans un tel projet et il faut prendre en compte le coût de maintenance des serveurs dans les calculs. Cependant, même en les prenant en compte, ils peuvent être largement inférieurs aux tarifs proposés par les cloud providers américains classiques.

Au-delà des coûts, l’expérience peut être intéressante pour se protéger du Cloud Act qui permet aux autorités américaines d’accéder à nos données, même celles hébergées en Europe. Et si jamais on n’a pas les compétences ops pour être aussi radical, on peut aussi juste se diriger vers du cloud français ou européen comme OVHCloud, Scaleway ou Clever Cloud.

DevGreenOps : Passer du sprint à l’endurance énergétique avec Decathlon x Greenspector - Olivier Philippot, Ludovic ROLAND et Nathalie OTTE

On retourne dans le thème de l’efficacité énergétique avec une présentation conjointe de Décathlon et Greenspector. Il s’agissait ici d’un retour d’expérience sur l’utilisation de l’outil pour tenter de mesurer l’efficacité énergétique de l’application mobile Décathlon sur Android.

Le processus qui nous a été présenté était assez clair et je lui trouve une similarité avec la façon dont on peut concevoir une suite de tests end-to-end. À savoir : identifier les chemins critiques, développer les tests qui passent par ces chemins, puis les jouer régulièrement de manière automatique, dans notre CI par exemple.

Dans le cas de Greenspector, j’ai compris qu’il était possible de le faire via leur propre DSL ou via une interface. J’aurais trouvé ça chouette que ça ne soit pas une DSL (Domain Specific Language), mais un langage généraliste comme ce que fait k6 de Grafana. Car si je dois écrire ces scénarios de tests une fois dans une DSL pour Greenspector, puis dans une autre pour mes tests end-to-end, ce n’est pas idéal. J’ai posé la question en fin de conférence, mais pour l’instant, ce genre d’intégration n’existe pas et n’a pas l’air prévu.

Malgré quelques petites difficultés liées au fait que ce scan Greenspector est joué en production et que, donc, des éléments externes (comme de l’A/B test) peuvent venir perturber la mesure, ils semblent avoir réussi à dégager quelques actions pour réduire l’empreinte de leur application, notamment en supprimant des SDK d’analytics redondants.

Dans tous les cas, je trouve que c’est une excellente chose que ce genre de sujet arrive sur la table et soit mis en avant. J’espère que ça va continuer et s’amplifier. Je note aussi que la méthode de calcul est différente des méthodes EROOM et API Green Score qu’on a vues dans la conférence EcoScore, ce qui montre que l’étape de standardisation n’est probablement pas encore arrivée. Merci aux présentateurs et présentatrices pour ce retour d’expérience très clair.

Qu’est-ce que OID4VP : le protocole derrière les portefeuilles numériques européens - Gilbert Djamena

Comme je devais partir, c’est le dernier talk auquel j’ai pu assister. J’ai fini ce DevLille sur cette introduction au protocole OID4VP pour OpenID for Verifiable Presentations. C’est un protocole qui répond au problème suivant : comment une personne peut prouver à un tiers qu’elle valide un critère (comme son âge) de manière sécurisée et sans partager de données sensibles comme sa carte d’identité.

On a eu droit à une présentation étape par étape de comment fonctionnait ce protocole, notamment du fait qu’il partageait une version hachée des champs présents sur le document initial (la carte d’identité, ou CNI par exemple) et permettait à l’utilisateur de valider quels champs devaient être exposés. Par exemple, vouloir partager son âge sans partager son prénom, alors que les deux sont disponibles sur une CNI.

Je me suis fait la remarque que ce genre d’approche pouvait être sensible aux attaques du type “store now, decrypt later”, où l’on récupère une donnée chiffrée qui a peu de chances de bouger dans le temps. Dans le futur, si l’algorithme qui protège cette donnée venait à être cracké, on pourrait alors accéder à la donnée alors qu’elle est encore pertinente.

J’ai posé la question au présentateur qui m’a expliqué que oui, c’était un problème, mais qu’une version du protocole ne se basant pas sur les SD-JWT (Selected Disclosure JWT) existait déjà et résolvait ce problème en envoyant uniquement les champs vraiment nécessaires.

Sur ce genre de présentation technique, il est bien sûr difficile de retenir chaque détail et il faudra que je m’y penche un peu plus dans le futur afin de bien avoir en tête ses enjeux.

Conclusion

Voilà pour cette édition. Je rajouterai le lien vers les vidéos une fois qu’elles seront disponibles.

J’ai été très content de participer. Globalement, j’ai appris pas mal de choses, sur PostgreSQL, les Top Level Domains et sur OID4VP. Les conférences sur les aspects plus sociétaux sur la place de la femme dans la tech m’ont donné envie de creuser un peu plus le sujet. Pour sortir de ma zone de confort, j’ai tenté d’aller à quelques conférences sur l’IA et je pense que je vais tenter de jouer un peu avec la CLI de Mistral pour voir si c’est possible de le faire de manière sécurisée (en tout cas sécurisée comme je le souhaite).

J’aurais aimé assister à la présentation sur Factorio. Étant moi-même un grand fan de Dyson Sphere Program, Satisfactory et en premier lieu Factorio, j’ai toujours trouvé qu’on pouvait tracer un parallèle fort entre l’organisation de ses services et l’organisation de son usine dans ces jeux. Je rattraperai ça dès que la VOD sera disponible ! En tout cas, ça a bien déchaîné le Discord.

Un gros merci aux organisateurs et aux bénévoles. À l’année prochaine !