Retours sur Lyon Craft 2025

La 3ème édition du Lyon Craft, organisée par le Meetup Software Crafters Lyon, a été un succès. On ne change pas les habitudes gagnantes, surtout en termes d’organisation ! La conférence a été annoncée mi-février pour mi-avril, et les 150 places ont été vendues en quelques semaines, bien avant que le programme ne soit dévoilé. Bravo à tous les organisateurs, intervenants et contributeurs !

Voici un résumé de mes notes prises lors de l’événement, en attendant les captations.

L’IA dans vos projets : un peu, beaucoup, pas du tout ?

Par Marie-Alice BLETE

Mes notes

Marie-Alice a débuté par une démonstration interactive d’un site e-commerce basique, en explorant comment l’IA pourrait le booster. Au fil des idées, quatre catégories d’usage ont émergé :

• Interaction directe : L’utilisateur interagit avec un LLM, comme dans le cas d’un chatbot.
• Transformation d’input : Un input utilisateur est envoyé à un LLM qui le transforme pour améliorer une fonctionnalité, comme la recherche.
• Génération autonome : Le système et le LLM interagissent sans intervention humaine, par exemple pour générer des descriptions de produits.
• Interaction complexe : Tous les acteurs (utilisateur, LLM, système) collaborent pour des fonctionnalités avancées, comme un agent de shopping.

Mais qu’est-ce qu’un agent ? Selon le Framework LangChain, un agent est un modèle IA avec des objectifs et des capacités, interagissant de manière autonome avec son environnement via des API.

Cependant, l’utilisation de l’IA comporte des risques :

• Effet de mode : Vouloir intégrer l’IA partout sans justification.
• Erreurs et biais : Hallucinations, biais, erreurs possibles.
• Coûts : Coûts liés au fournisseur du LLM, à l’implémentation et à la maintenance.
• Complexité : Un agent omnipotent peut devenir une boîte noire, avec un couplage fort des fonctionnalités, rendant le système difficile à maintenir et à faire évoluer.

Pour réduire ces risques, Marie-Alice propose d’utiliser des LLM en squads : un agent "routeur" redirige les requêtes vers des agents spécialisés. Cela permet de créer des systèmes intermédiaires plus modulaires.

L’estimation du développement avec des LLM est complexe. Les incertitudes sont nombreuses : fine-tuning, changement de modèles, avancées technologiques rapides. Les tests unitaires traditionnels ne sont pas adaptés aux LLM, en raison de leur part d’aléatoire. On se concentre donc sur des tests de comportement global.

Ce que j’en retiens

Le sujet est captivant, surtout pour ceux qui découvrent le concept d’agent et cherchent des idées pour intégrer l’IA dans leurs projets. J’aurais aimé que la partie sur les tests, l’exploitation et le monitoring des LLM soit plus approfondie. Peut-être lors d’une prochaine conférence !

The choice must go on, mais le bon de préférence

Par Céline LOUVET

Mes notes

Pour faire le bon choix, il faut d’abord définir ce qu’est un projet réussi. Du point de vue du décideur, cela signifie respecter le budget, les délais et satisfaire les besoins. Idéalement, cela inclut aussi une équipe heureuse et un projet maintenable.

Chaque année, un organisme publie un “Chaos Report” analysant les échecs et les facteurs de réussite des projets. Parmi les causes d’échec, on trouve :

• Manque d’implication des utilisateurs.
• Spécifications incomplètes ou changeantes.
• Manque de soutien du management.
• Incompétence technologique (l’équipe n’est pas formée).
• Technologie immature.
• Besoins flous.

Céline partage plusieurs techniques pour éviter ces écueils :

• Les 5 Pourquoi : Comprendre le véritable besoin en posant plusieurs fois la question "pourquoi".
• Éviter le biais du problème XY : Ne pas introduire de nouvelles solutions ou besoins annexes.
• Considérer les contraintes : Budget, temps, réglementation, spécificités contextuelles.

Pour le couple budget/temps, il est crucial de distinguer trois phases : mise en place, maintenance, situations de crise. Cela permet de mieux évaluer les coûts réels.
En prenant en compte ces différents éléments, on casse très vite le mythe du “ça sera moins cher de le développer en interne plutôt que de prendre un abonnement à tel outil”. Si l’on compte un TJM à 500 €, 2 développeurs à plein temps pendant 1 trimestre nous donneront une solution à 60 k€, auquel il faudra rajouter le temps de maintenance nécessaire.

Céline propose également de construire un techradar pour visualiser les technologies utilisées dans l’entreprise et leur niveau d’adoption :

• Adopt : Technologies maîtrisées et recommandées.
• Trial : Technologies non maîtrisées mais recommandées.
• Assess : Technologies à tester.
• Hold : Technologies à éviter ou à utiliser avec précaution.

Les objectifs sont multiples :

• Avoir une vision globale sur ce qui se fait au sein de l’entreprise.
• Suivre son existant.
• Aide au choix pour les nouveaux projets.
• Ne plus revenir sur quelque chose qui a été abandonné.

Les Golden path ou Paved road sont des boîtes à outils (documentation, template...) facilitant l’adoption des technologies recommandées.

Il est important d’éviter le biais des coûts irrécupérables : ne pas réutiliser une technologie inadaptée simplement parce qu’on y a déjà investi du temps et des ressources.

Il n’existe pas de solution magique pour faire des choix. Si on a un doute, il faut tester, éventuellement avec un POC, et être prêt à changer si cela ne fonctionne pas. Il faut aussi garder en tête l’impact des choix sur la complexité obligatoire et accidentelle du projet.

Enfin, il est utile de créer des Decision Records (DRs) pour historiser les choix et leurs contextes, facilitant ainsi leur remise en question future.

Ressources partagées à l’occasion du talk.

Ce que j’en retiens

Rien de révolutionnaire, mais un bon rappel des concepts et des outils pour faire des choix éclairés. J’ai découvert qu’il est facile de créer un techradar avec les outils open source disponibles, notamment celui de Zalando mais d'autres exemples sont disponibles dans les ressources du talk.

Atelier EventStorming

Par Clément CASTRO, Vincent PINEL, Florent PELLET, Colin DAMON

Déroulement de l’atelier

Clément et Vincent ont présenté deux contextes métiers pour les groupes de travail. J’ai choisi le contexte réglementaire présenté par Clément : une solution pour un RSSI (Responsable sécurité des systèmes d’information) devant évaluer les risques des fournisseurs de services de l’entreprise.

L’objectif de l’Event Storming est de comprendre rapidement un processus métier en réunissant des experts et des personnes moins familières avec le sujet, souvent des développeurs. Clément jouait le rôle de l’expert, tandis que Florent animait l’atelier au sein de notre groupe.

Nous avons suivi plusieurs étapes, ponctuées de nombreuses discussions pour cerner le contexte métier :

• Lister les événements : Identifier tous les événements possibles dans le processus, conjugués au passé.
• Poser des questions : Noter les questions et les zones d’ombre pour y revenir plus tard.
• Organiser chronologiquement : Mettre en ordre les événements.
• Déterminer les causes : Pour chaque événement, identifier ce qui l’a déclenché (un autre événement ou une action).
• Identifier les acteurs : Déterminer qui est responsable de chaque action.
• Regrouper en “patates” : Créer des groupes fonctionnels d’événements et d’actions.
• Définir le type de domaine : Classifier chaque groupe en domaine core, support ou générique.

L’atelier s’est déroulé en collant des post-it sur un mur, chaque étape ayant sa couleur de post-it.

Il n’est pas nécessaire de suivre toutes les étapes pour tirer profit de l’Event Storming. La définition des événements et des questions est souvent la plus utile.

Ce que j’en retiens

L’Event Storming est un atelier très intéressant pour cartographier un processus métier, mais il peut être complexe à réaliser sans accompagnement. À plusieurs reprises, nous nous sommes embourbés dans la définition des événements, peut-être en partie à cause du manque de frontières claires sur ce qui devait être cartographié.

Les joies du CoD, la priorisation par la valeur

Par Damien CARBONELLI, Quentin ALLOIN

Mes notes

Damien et Quentin ont partagé l’évolution de leur entreprise : de 2009 avec une seule équipe tech et un produit simple, à 2025 avec 18 équipes et un produit complexe.

Avec cette croissance, la priorisation des tâches est devenue un défi. Le backlog technique est souvent dépriorisé face aux demandes business, augmentant la charge mentale des équipes tech.

Pour y remédier, ils ont adopté la technique du Cost Of Delay (CoD) : évaluer l’impact financier de retarder une tâche (ou "opportunité") d’un mois. Par exemple, une facturation manuelle coûte 1 k€/mois (2 jours par une personne sur une base de TJM à 500€), mais les erreurs potentielles peuvent entraîner des pertes bien plus importantes, augmentant ainsi la priorité de la tâche.

En estimant le CoD et le temps de développement, on peut calculer le CD3 (Cost of Delay Divided by Duration). Plus le CD3 est élevé, plus la tâche est prioritaire.

Cette méthode permet aussi de valoriser le travail sur la dette technique :

• Réduction du temps de montée en compétence des nouvelles recrues.
• Réduction du coût d’obsolescence.
• Gain d’efficacité avec de nouveaux outils ou migrations.

Chaque opportunité doit être associée à un contexte et des hypothèses d’estimation, permettant de reprioriser rapidement en cas de changement.

Damien et Quentin conseillent de démarrer avec une seule équipe ayant des problèmes de priorisation. L’équipe business fournit le CoD, et les équipes techniques estiment le temps. Les estimations doivent être rapides et approximatives, car c’est l’ordre de grandeur qui compte.

Le CoD peut être combiné avec d’autres méthodes comme les Opportunity Solution Trees (OST) et les Objectives and Key Results (OKR) pour explorer, organiser et suivre les opportunités. Ces méthodes permettent respectivement :

• D'explorer, organiser les opportunités et les solutions potentielles pour atteindre des objectifs produit.
• De définir des objectifs mesurables et à suivre leur progression.

Il faut cependant être vigilant face aux biais, notamment la loi de Goodhart : lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.

Ce que j’en retiens

La méthode de priorisation par le CoD est intéressante, mais je reste sceptique quant à la difficulté d’estimer systématiquement les coûts du délai et le temps de réalisation.