A la mi-mai s’est tenue la dixième édition de la conférence NewCrafts. Ippon y était et l’équipe qui a pu suivre les conférences et ateliers sur place a été enchantée de sa participation à cette conférence, moins connue que d'autres dans notre milieu. Voici notre retour d’expérience : pourquoi on aime cette conférence et ce qui nous a le plus marqué.
À deux pas de la Tour Eiffel, nous nous sommes retrouvés avec quelques centaines de personnes, animées par l’esprit Craft, pour deux journées intenses de conférences et d’ateliers. Les journées commencent et se terminent par une keynote. Entre celles-ci, c’est un marathon de conférences sur un format de 45 minutes ou, pour ceux qui le souhaitent, la possibilité de participer à des ateliers de plus de deux heures chacun.
Les présentations sont en anglais et la majorité des conférenciers sont européens ou nord-américains. L'événement regroupait cinquante conférenciers et conférencières aux profils très variés et avec une parité parfaite !
C’est une conférence qui s’adresse autant aux développeurs et développeuses, qu’aux testeurs/QA, architectes, product-owners, décisionnaires… en somme, toute personne susceptible d’intervenir sur un projet tech, intéressée par le Craft et curieuse ! L’un des points les plus marquants de NewCrafts, c’est la convivialité qui y règne. Ici, on interagit facilement avec les conférenciers et ses pairs. Cela en fait un moment idéal pour prendre du recul et s’interroger sur nos pratiques, nourrir son esprit et repartir avec plein de choses à creuser, lire ou essayer ! Une conférence NewCrafts réussie, c’est une conférence de laquelle on repart avec plus de questions que de réponses ;-)
Si l’on devait retenir en quelques mots nos deux jours à NewCrafts, on pourrait citer : communication, collaboration et apprentissage. C’est comme si un fil rouge s’était immiscé d’une présentation à une autre et qu’elles se faisaient écho les unes aux autres sur ces trois grands axes.
Faire un choix dans les présentations et ateliers était parfois difficile et nos agendas ont été bien remplis pendant ces deux jours. Certaines présentations ont retenu notre attention plus que d’autres. Voici le résumé et nos impressions sur quelques-unes des présentations qui nous ont le plus marquées : la mise en place d’IA Générative de Patrick Debois, la lecture de code de Marit van Dijk et la boîte à outils d’une lead QA, Lisi Hocke. Mais il est impossible ici de ne pas citer aussi la présentation de Woody Zuill sur l’échec de communication, celle d’Alberto Brandolini qui est revenu sur quelques fondements du DDD et la notion même de produit, ou encore celle de Léa Coston sur les difficultés que l’on rencontre dans une équipe de développement, notamment en tant que junior. Toutes avaient en commun ces trois mots clés : communication, collaboration et apprentissage.
Patrick Debois - From Pilot to Transformation : Embracing the Reality of Gen AI at Scale
L’ouverture de NewCrafts s’est faite avec Patrick Debois sur le sujet du moment, l’IA Générative. Pour ceux qui ne le connaissent pas, Patrick Debois est l’un des promoteurs du mouvement DevOps. Il est notamment l’un des auteurs de “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations” avec Gene Kim, John Willis, et Jez Humble.
Cette présentation était l’occasion de livrer un retour d’expérience sur les difficultés et les apprentissages liés à la mise en place d'applications ayant recours à l’IA générative. Il a mis le focus sur les quatre phases de leur mise en place et les défis à relever à chaque étape. Il en ressort des enseignements à la fois pour l’écriture de prompts, le choix des modèles, le choix des données pour entraîner ces mêmes modèles et l’orchestration de ces applications.
On commence évidemment par la construction et les difficultés liées à l'ingénierie du prompt. Il nous a partagé quelques-uns des enseignements acquis grâce à son expérience et met l’accent sur son apprentissage par essai-erreur.
Parmi ces enseignements, c'est la nécessité de penser en termes de séquences de prompt plutôt qu’en prompt isolé. Il est également nécessaire de contrôler le format de la sortie (par exemple un fichier au format json) et le cycle de tentatives si le résultat n’est pas correct. Il a mis en avant l’importance de tester différents modèles pour trouver celui qui est le plus adéquat. Un modèle ne répondra pas forcément à tous les problèmes auxquels on essaie d’apporter une solution et il est parfois plus judicieux de les combiner. Un modèle très grand ne sera pas la réponse à tous les problèmes car il peut être sur-paramétré et sous-entraîné. De petits modèles entraînés sur plus de données peuvent avoir des performances aussi bonnes qu’un grand modèle.
De ces expérimentations, il a également pu relever que des changements mineurs peuvent avoir beaucoup d'impacts. Un réglage fin du prompt donne de meilleurs résultats et il préconise l’utilisation de modèles déjà connus de l’industrie comme la Chaîne de Pensée. Il fait un parallèle intéressant avec le codage d’un logiciel et la nécessité de réécrire, refactorer régulièrement de nombreux prompts. Cette étape de remaniement est coûteuse, délicate et reste très artisanale. Et c’est là que son retour d’expérience dans le cadre de NewCrafts prend tout son sens. Il a également soulevé les difficultés pour basculer un prompt d’un modèle vers un autre et les stratégies possibles pour optimiser le prompt et éviter sa réécriture.
Dans un deuxième temps, Patrick Debois a abordé les problématiques de traitement des résultats et la génération augmentée de récupération (RAG) qui est le processus consistant à optimiser le résultat d'un grand modèle de langage (LLM). Les modèles sont nourris avec les données de l’entreprise, mais il est aussi nécessaire de s’assurer que la réponse apportée à l’utilisateur final sera cohérente avec l’entreprise responsable de l’application. Cette étape nécessite aussi des réglages fins.
Comme pour la construction, la mise en place du pipeline de livraison et la phase de test se sont faites par essai-erreur. Il a mis en avant la nécessité d’avoir des pipelines séparés pour la partie prompt, l’orchestration, l’API, la partie data et modèle avec un versioning d’artefact et pour chacun des environnements.
Concernant la partie test, l’enjeu est de déterminer quoi tester, comment tester. Les métriques utilisées s’organisent autour de quatre grands points (LangKit, outil open-source pour le monitoring de LLM) :
- la qualité du texte
- la pertinence du texte
- la sécurité et la confidentialité
- l’analyse des sentiments et de la toxicité
Concernant la partie opérationnelle, il a mis en avant les problématiques de monitoring de la qualité et le coût de fonctionnement de ces applications. Il a également évoqué les challenges à venir pour le fonctionnement de ces applications.
Pour conclure, ses différentes expériences lui ont permis de prendre du recul par rapport à notre industrie et sur les répercussions en termes d’organisation dans la conception de ce genre d’application. Il a évoqué avec un schéma qui se trouve ici, le fait que l’ingénieur IA se rapproche de plus en plus de l’ingénieur Fullstack et s’éloigne du chercheur scientifique. Même si pour le moment, la construction de ce type d’application reste très “DIY”, sa conclusion est qu’il nous faut dès maintenant nous préparer à construire nos capacités à maîtriser l’IA Générative pour acquérir une façon de penser différenciante.
Marit van Dijk - Reading Code
Marit van Dijk nous a parlé de lecture de code et nous a fait découvrir le club Reading Code. Une partie de sa présentation s’appuie sur l’ouvrage de Felienne Hermans - The Programmer’s Brain (éditions Manning). Le point de départ est un constat : on apprend tous à coder, mais pas à lire du code. Les développeurs et développeuses passent en moyenne 58% de leur temps à la compréhension de code source existant. Lorsqu’on ajoute de nouvelles fonctionnalités, que l’on souhaite apprendre un nouveau langage, une nouvelle librairie ou encore essayer de résoudre un bug, c’est la lecture de code qui est notre première activité.
Des études scientifiques démontrent qu’il est plus facile d’apprendre un langage ou des concepts lorsque lors de l’apprentissage, on a été exposés à la lecture d’exemples concrets et non pas uniquement aux concepts. Marit van Dijk a mis en lumière les grandes lignes de certains mécanismes de notre mémoire : mémoire court-terme, long-terme et mémoire de travail, tout en faisant un parallèle très parlant avec la RAM, le CPU et le processeur d’un ordinateur.
En ayant conscience de ces mécanismes, il est possible d’améliorer notre capacité de lecture, notre apprentissage et notre compréhension du code sur lequel nous sommes amenés à intervenir.
De là est née cette initiative du club de lecture de code. Marit van Dijk nous a présenté les grandes étapes de cet exercice. En présentiel ou en ligne, il est possible d’organiser en petit groupe une session de lecture. Dans un premier temps, la session peut se faire sur un extrait imprimé sur papier. Le club a également mis à disposition des outils pour faire l’atelier en ligne. Il n'est pas nécessaire de connaître le langage au préalable. L’exercice se découpe en plusieurs étapes avec, pour chacune, un temps personnel et une mise en commun. On commence par parcourir rapidement le code, puis on identifie les composants et leurs relations pour se faire une idée de la structure. Dans un troisième temps, on essaie d’identifier les lignes de code les plus importantes pour chacun, puis les concepts. La dernière étape vise à en extraire les concepts clés et ce que fait le code. On couvre ainsi les quatre dimensions de la lecture de code : la structure, le domaine, les concepts et le contexte.
L’idée est de collaborer et de s’enrichir de la perspective de ses pairs pour améliorer notre aptitude à lire du code. L’exercice est accessible à tous les niveaux et peut être un excellent outil d’onboarding. Contrairement à une revue de code où l’on est généralement dans une posture de jugement, on est là pour acquérir et partager des connaissances.
Lisi Hocke - Team Transformation Tactics for Holistic Testing and Quality
Lisi Hocke est lead QA et c’est avec son point de vue que l’on découvre les interactions et les difficultés qu’elle a pu rencontrer dans ses trois dernières équipes. Plus qu’un retour d'expérience, c'est véritablement une boîte à outils qu’elle nous a offerte. Son point de départ est la volonté d’avoir une démarche qualité et d’envisager le test de façon holistique.
Elle a rencontré, comme certainement beaucoup d’entre nous, les difficultés qu’une équipe de développement peut traverser : le manque de transparence, une mauvaise compréhension du système global sur lequel l’équipe agit, une mauvaise communication au sein de l’équipe ou avec celles qui les entourent, des connaissances silotées, l’inaction, l’évitement des conflits… et bien d’autres.
Le point de vue de Lisi Hocke est d’en faire une affaire d’équipe. Les bénéfices de cette posture sont nombreux : avoir une équipe plus forte, plus résiliente, un partage de connaissances et de compétences, plus de facilité pour l’équipe d’expérimenter… et bien d’autres. Mais malheureusement nous en sommes généralement loin !
Pour tenter de faire bouger les choses et d’améliorer la situation dans lesquelles Lisi Hocke s’est retrouvée, elle nous a livré quelques clés pour emprunter ce chemin. Il n’est pas nécessaire d’être dans une position de pouvoir pour impulser le changement et avoir cette influence sur ceux qui nous entourent. Un des éléments sur lequel elle a attiré notre attention est de penser en termes d’impact, plutôt que d’intention, car les risques d’erreurs et d'incompréhensions peuvent être grands.
Elle a également mis l’accent sur le temps nécessaire à cette transformation, car nous n’avons pas tous la même capacité d’adaptation au changement. Il est également important de choisir ses batailles et d’accepter les reculs potentiels. L’essentiel est d’oser essayer encore et encore.
Au fil des années et des équipes, elle s’est constituée une liste personnelle pour garder le cap dans sa recherche d’amélioration de la qualité, au sein d’une équipe. Elle tient en douze points, parmi lesquels :
- Les gens d’abord (People First)
- Rencontrer les gens là où ils sont
- Montrer plutôt que dire
- Un mot d’ordre : le partage
- Construire sur les dynamiques existantes
- Un peu mieux chaque jour…
Pour résumer, pour Lisi Hocke, sans une culture d’équipe forte il est difficile de mettre en place une vraie démarche de tests et de qualité. En étant unis, il est plus facile d’avancer pas à pas. L’amélioration de la qualité n’est pas un chemin solitaire et l’optimisme permet d’aller loin.
En conclusion
Participer à NewCrafts nous a permis de prendre du recul par rapport à nos pratiques et à notre quotidien. Nous avons pu découvrir des retours directs sur le front de l’IA Générative, ainsi que les challenges pour la mettre en place. Mais nous avons aussi, à travers les différentes présentations, entendu la voix de dizaines de confrères et consoeurs sur les difficultés techniques qu’ils rencontrent. Derrière la façade des challenges techniques, c’est véritablement des challenges humains qui occupent le devant de la scène avec la nécessité d’apprentissage, le partage des connaissances et la nécessité d’interactions efficaces avec les différentes parties prenantes qui participent à la construction de logiciels.
Pari réussi pour NewCrafts 2024 : nous en sommes repartis plein d’idées, de nouvelles perspectives, de nouvelles connaissances et l’envie de partager ce qui nous a fait vibrer !
