Alpes Craft 2026

J'ai eu la chance de participer cette année à Alpes Craft en tant qu'orateur. Voici quelques notes prises au grés des sessions auxquelles j'ai assisté ou que j'ai animé.

Emmanuel Gaill ot a donné une conférence d'ouverture de grande qualité et d'une grande pertinence, une réponse salutaire d'inspiration — oserai-je le dire — spinoziste aux injonctions à la performance et à la réification de notre époque ;

Adeline Mor el a partagé ses techniques pour lutter contre les pièges posés par nos biais cognitifs qui nous font perdre notre lucidité face au code ;

J'ai eu l'honneur de faciliter une session au format "Office hour" sur le sujet des techniques de test alternatifs, qui, grâce aux participants, a pris une toute autre direction que celle que j'avais envisagée. J'en parle plus en détail un peu plus loin.

J'ai par ailleurs eu le plaisir de présenter une conférence intitulée 7 langages en 7 minut es déjà expérimentée à la nuit des meetups de Nantes, un talk un peu fourre-tout, trop ambitieux et compliqué qui tente de tisser ensemble l'exploration de différents langages de programmation, l'apprentissage et la compréhension du fonctionnement des LLMs modernes et plus particulièrement de la différentiation automatique, et l'examen d'un usage critique de ces mêmes LLMs dans ce processus. J'espère avoir donné envie à quelques personnes d'explorer de nouveaux langages comme Forth, Haskell, Idris, OCaml ou Common Lisp !

Guillaume Saint-Étien ne a brossé un panorama de l'histoire de "l'informatique" et du code sous l'angle du pouvoir et de la loi, des premiers automates et automatismes tels que les machines Jacquard jusqu'à l'IA. Une fresque ambitieuse et un poil décousue qui mériterait une discussion plus approfondie et plus longue !

Enfin Jonathan Laure nt a animé une "office hour" consacrée au TDD et notamment à sa pratique propre, fondée sur une application stricte de la boucle Red-Green-Refactor et d u Transformation Priority Premi se. Des discussions intéressantes, mais il a manqué de temps et de pratique concrète sur du code "de production" pour que le débat puisse vraiment s'installer et les bénéfices de la proposition devenir plus claire. Même si je suis convaincu de l'importance des "baby steps" et bien évidemment du TDD proprement dit, le diable est dans les détails et les questions de l'articulation de cette pratique avec les contraintes du système développé, les choix et capacités de l'équipe, l'ensemble du cycle de vie du logiciel mériterait plus de temps.

Pour des raisons personnelles, je n'ai malheureusement pas pu assister à l'Open Space qui se déroulait le 6 juin ce que je regrette car tant de sujets et de questions eussent demandé d'être approfondies dans un cadre plus ouvert !

Techniques de tests alternatifs

J'ai tout d'abord proposé aux participants d'énumérer des questions ou des problèmes sur le sujet du ou des tests, voici la liste qui en est ressortie :

comment compléter les tests dynamiques qui exécutent le code par des tests statiques, des outils d'analyse ou de modélisation du code permettant d'extraire de la l'information et d'identifier des problèmes potentiels avant même d'exécuter le code,

comment articuler le TDD et la couverture de code, et dans le même esprit comment utiliser la couverture de code pour reconstruire des tests sur du code legacy ;

comment articuler le test entendu comme processus de vérification du logiciel par rapport à une "spécification" ou un modèle, et le test comme processus de recherche de problèmes, le premier étant la vision "développeurs" quand le second correspond plus à la vision "testeur",

vaut-il mieux tester les couches (ou composants) ou leur composition, et comment intégrer les deux approches,

comment éviter que les tests ne deviennent un frein au changement,

comment écrire des tests plus expressifs,

comment raccourcir la boucle de feedback des tests,

et enfin, comment éviter de tester autre chose que du code de "production".

Après un vote rapide à main levée, nous avons passé le reste de la session à creuser un peu plus la question 3, c'est-à-dire identifier des pistes, techniques, outils permettant de détecter des défauts, plutôt que de se focaliser sur la vérification:

il y a eu consensus sur l'importance d'intégrer très tôt dans les discussions sur le développement toutes les parties prenantes et notamment les testeurs/QA, de multiplier les points de vue avant même que la moindre ligne de code n'ait été écrite, pour lever des ambiguïtés ou des angles morts des solutions envisagées,

la technique "bien connue" des tres amig os propose un cadre pour appliquer ce principe,

on a souligné l'importance de valoriser cette compétence spécifique à trouver des problèmes, à se mettre à la place de l'utilisateur et ne pas adopter uniquement un point de vue de développeur,

ce qui implique d'identifier et détecter cette compétence lors du recrutement,

de toute évidence mettre le logiciel face aux utilisateurs est un bon moyen d'identifier des problèmes ce qui suppose de les impliquer en amont du processus de développement

la technique de l'Ex ample mappi ng est un outil léger pour construire avec les utilisateurs et experts métiers un "modèle" du logiciel et d'identifier les tests nécessaires,

ZO MBI ES est une mnémotechnique d'aide à l'identification des cas à tester, qui peut être utilement complétée par d'autres techniques de définition des cas de tests à couvrir telle que la pa rtition en classes d'équivalenc es ou le pa irwise (n-wise) testi ng,

le Pr operty-based testi ng est une technique relativement méconnue permettant d'améliorer la couverture des tests automatisés,

enfin j'ai signalé tout le bien que je pense de Bo mbad il qui permet d'appliquer le property-based testing aux applications web.

Nous avons manqué de temps pour explorer d'autres sujets ce qui n'est guère surprenant étant donné l'étendue et la complexité du domaine du test, dans ses deux dimensions de vérification et d'exploration. Pour finir, deux références ont été proposées:

Elaine J. Weyuker est connue pour avoir formalisé de manière axiomatique "l'adéquation" d'une suite de cas tests dans Ax iomatizing software test data adequa cy,

Ta king Testing Serious ly est un livre récent sur le test est plus particulièrement le "Test exploratoire" et l'approche "Rapid software testing" développée par Bach et Bolton.