Retour sur l'Agile Tour Bordeaux 2025

Les 30 et 31 octobre 2025 a eu lieu l'édition annuelle de l'Agile Tour à Bordeaux. Cette année encore Wanteeed était dans la place, représenté par David, Laurent et Christophe ! Cet article regroupe notre feedback à tous les 3.

La description de David : "Cette année je me suis rendu pour la première fois à l'agile tour de Bordeaux. C'est un évènement orienté agilité (si si) qui se tient dans les locaux d'Ynov, une école privée d'informatique, situés place Ravezies. Au programme: des conférences, workshops, des échanges plus libres, du café et des chocolatines. Le tout moyennant une inscription effectuée en 2 minutes pour environ 0€ TTC".

Bien sûr, comme tout cycle de conférences, différentes activités se déroulent en parallèle et il faut donc choisir son programme.

Voici quelques-unes des présentations auxquelles nous avons assisté :

Model Mitosis : ne plus se tromper entre les microservices et le monolithe

par Julien Topçu et Josian Chevalier

Conférence sous la forme d'une conversation/atelier de refacto entre deux architectes sur un parcours de recherche de train puis réservation.

Problème : tout le code de la réservation a réemployé / a été mélangé avec les modélisations métier de la recherche, ce qui introduit des couplages indésirables entre les deux et les empêche de scaler indépendamment.

Au terme de la conférence, des domaines conceptuels forts émergent, tels que Search et Booking, qui implémentent chacun leurs propres versions de concepts initialement mélangés, comme "SpaceTrain".

Mélangés car du point de vue humain, dans les deux cas on parle de SpaceTrain, donc la tentation est forte de mettre tout le code relatifs aux space trains dans les mêmes fichiers, mêmes objets. Mais sur le plan fonctionnel, comportemental, ce sont deux choses différentes.

La démarche, l'objectif et les concepts abordés viennent très largement du Domain-Driven Design. On peut trouver des vidéos de précédentes sessions (par ex ici).

Coach agile, métier d'avenir ou en voie de disparition

par Rachel Dubois

Après un âge d'or des coachs agiles où tout le monde les recherchait sans comprendre pourquoi ni mesurer leur impact (au nom de la sacro-sainte évidence de la transformation digitale), plus personne n'en veut. Notamment avec l'arrivée d'outils IA qui s'occupent de toutes les tâches sans plus-value d'expertise.

Nécessité pour les coachs de trouver leur réelle offre de valeur (spoiler alert : 95% n'en ont pas)

"It is not necessary to change. Survival is not mandatory." W. Edwards Deming

Une conférence clivante mais intéressante pour le regard extrêmement critique sur ce métier, ses praticiens et la mentalité de l'industrie du numérique.

Observabilité : impliquons les développeurs dès les premiers commits

par Aymeric Laleau

• Présentation générale de concepts de l'observabilité (métriques, logs, traces...)
• L'idée générale c'est que si on veut être capable de déterminer l'état d'un système, c'est mieux de mettre en place les outils au fur et à mesure et pas laisser un ops en bout de chaîne se débrouiller tout seul. Ca tombe bien, à Wanteeed on fait déjà ça!
• S'ensuit une démo accompagnée d'un listing d'outils pour l'observabilité. Certains connus (Datadog, ELK, ...) d'autres moins et plus ou moins gratuits/opensources/libres (en particulier Prometheus pour les metrics, Loki pour les logs, Joeger, pour le tracing, OpenTelemetry pour la collecte et Grafana comme dashboard).
• Quelques points de vigilance
  • bien tester les configs de levée d'alerte
  • ne pas en avoir trop
  • rendre les alertes exploitables
• Promeut une culture de l'observabilité avec notamment
  • définition des alertes qu'on souhaite lever dès la phase de conception
  • prévoir un temps d'analyse des dernières features
  • focus observabilité lors des post-mortem (en termes d'observabilité sur un incident, qu'est-ce qui a marché / pas marché / peut être amélioré ?)
  • standardisation de la visualisation et des données récoltées
  • nettoyage régulier des vieilles métriques
• Il est rentré assez en détail du SDK de OpenTelemetry pour collecter les données de manière unifiée et les exposer vers différentes interfaces (Grafana, Datadog...). OpenTelemetry est utilisé par tout un tas d'outils payants "complets". Toujours est-il qu'avec cette suite d'outils, normalement on est en mesure d'avoir une suite d'observabilité gratuite complète. A tester donc.

Product-Led Growth(PLG) kesako ? Retex de 4 ans de mise en pratique

• Kesako? En effet! Chez moi, PLG c'est le club multisport de ma ville, alors dans un contexte pro j'étais perdu mais en fait tout va bien!
• Product est à prendre au sens équipe produit et Product-Led Growth se conçoit en conjonction avec les concepts de Sales-Led Growth et Marketing-Led Growth:
• Sales-Led Growth: c'est un peu l'ancien temps, un commercial (qui n'a aucune idée des contraintes liées au développement logiciel) part seul avec son meilleur costume rencontrer un décisionnaire seul qui souhaite commander un logiciel sur-mesure (qu'il n'utilisera jamais et pour un métier qu'il ne connaît pas). Ils trouvent un accord. L'entreprise a vendu un logiciel et la croissance de l'entreprise est directement liée au travail du commercial.
• Marketing-Led Growth: c'est un modèle qu'on connaît très bien! L'idée n'est pas de vendre un logiciel sur mesure mais plutôt de créer un logiciel qui répond à une demande plus ou moins large et de le vendre via des campagnes de marketing externe. Etant donné les coûts engagés par de tels procédés, l'idée c'est d'essayer de convaincre des décisionnaires plus mid-level.
• Product-Led Growth: c'est un modèle un peu différent. L'idée ici c'est de vendre le logiciel aux utilisateurs finaux. En effet, depuis quelques temps avec des initiatives comme le BYOB, de plus en plus les utilisateurs peuvent choisir les outils qu'ils veulent pour travailler. Les entreprises sont prêtes à financer ces outils qui améliorent la productivité et le confort de ses employés.
• Le PLG cible donc des utilisateurs finaux ce qui a pour impact principal qu'il faut les convaincre d'acheter le produit. Une manière de faire c'est de penser dès le départ des fonctionnalités gratuites (free trail, freemium, etc...). C'est bien, ça fait de l'acquisition mais ce qu'on veut également c'est de la rétention (et du passage au payant). Pour cela, l'idée est de tout centraliser dans le produit:
• support utilisateur directement dans l'outil. On ne sort pas du soft pour aller sur une boîte mail ou un formulaire de contact!
• patch note dans l'outil également! On prévient l'utilisateur des nouvelles fonctionnalités (via des banières par exemple). Cela facilite l'accès à l'information et rend vivant le logiciel
• etc...
• On ne disperse pas l'audience et on essai de rendre l'outil le plus addictif possible. Pour cela, il faut penser à proposer des activités pour les différentes catégories d'utilisateurs (newcomer, regular, power user, advocate). Ces activités concernent leur niveau actuel mais doivent aussi leur permettre de transitionner vers un autre stade d'utilisateur. Par exemple, le produit peut présenter régulièrement des tips permettant de transformer petit à petit un regular user en power user.
• En travaillant avec cette approche, en ayant en tête la viralité/addictivité de l'app et bien qu'ayant travaillé sur une solution pro (exit le free trial/freemium), l'intervenant a constaté une bonne adoption de la part des utilisateurs.

On se calme et on boit frais en Agilité

Cette conférence, bien qu'intéressante est plutôt simple à résumer: l'agilité, c'est un mindset m'voyez, un état d'esprit, c'est pas la méthode à Gilles.

Je vais quand même développer (un peu!): l'agilité est régulièrement critiquée pour plein de raisons et un des soucis de fond c'est que lorsqu'on veut faire de l'agilité, comme on sait pas trop ce qu'on fait, bah on prend une méthode (lean, scrum, safe, ...) et on l'applique bêtement. Et à la fin, on se dit que ça marche pas si bien que ce que l'on espérait. Ca a fait dire à plein de gens depuis plus de 10 ans que l'agilité était morte.

Ce qui est proposé dans cette conférence c'est de voir les méthodes comme des toolbox dans lesquelles on va pouvoir piocher de sorte à construire un mode de fonctionnement qui nous correspond et fonctionne pour nous (ce qu'ont fait les boîtes derrière lean, scrum and co d'ailleurs). Scrum propose des sprints qui commencent par un planning et finissent par une démo? C'est une bonne idée, mais on est pas obligé de rester sur des durées de sprint fixes. Vous avez l'idée.

Souffrance au travail - comment l'industrie agile y contribue

Ici, nous avons un REX d'un ancien coach agile indépendant qui espérait améliorer les conditions de travail de ses collègues grâce à l'agilité et qui s'est rendu compte qu'au final il faisait parti du problème.

En quoi l'agilité crée de la souffrance au travail? Ou, plus précisément, en quoi les coachs agiles indépendants la créent? De plusieurs manières:

L'agilité est "déployée" dans les organisations le plus souvent à l'initiative de patrons ou managers relativement high level. Ce qui signifie que le sponsors de l'intervention n'en subiront pas les conséquences directes. Ils sont sponsors de l'initiative parfois pour de mauvaises raisons. Les collaborateurs subissent l'initiative dans un quotidien déjà compliqué.

Le coach agile, en mission, s'occupe de "sauver" l'entreprise en déployant, par automatisme, ses supers outils: sprint, démo, etc... Et s'en va avant même d'avoir pu constater le résultat à long terme de son intervention et sans avoir pris la peine de vraiment résoudre les soucis potentiels sous-jacents. Quand on a marteau, tout ressemble à des clous...

Résultat: des salariés qui se voient imposés un changement d'organisation du travail qu'ils n'ont pas demandé, sur laquelle ils n'ont pas trop leur mot à dire et qui ne résout pas leurs soucis au quotidien, option direction qui a engagé des sous pour cela et qui attend un retour sur investissement.

Face à ce constat, l'intervenant a changé de poste et arrêté d'être coach agile. C'était intéressant car les différents constats sont sourcés. La conférence était également plutôt frustrante: je partageais déjà dans une certaines mesure le constat de l'impuissance des agilistes à amorcer les changements nécessaires dans certaines organisations. De mon point de vue, cela vient du fait qu'on lui demande d'intervenir au sein d'une équipe pour que cette équipe soit agile dans une organisation qui ne l'est pas, ce qui crée effectivement du mal-être au travail. Cependant, j'espérais avoir avec cette conférence des pistes de réflexions sur de potentielles solutions à cela et je n'en ai pas eu.

Le paradigme perdu : L'homme au cœur de l'organisation

A la base c'est une conférence plutôt centrée sur le langage, le titre a été changé mais pas le contenu. L'idée c'est que toute entreprise est une organisation humaine. Les humains sont limités par leur perception et la "réalité" est en partie une construction de l'esprit liée aux échanges qu'ont les humains entre eux. Ces échanges passent par le langage, oral comme écrit. Il faut donc pas hésiter à être clair sur les mots qu'on utilise, en donner des définitions si besoin et ne pas hésiter à demander des définitions afin de mieux coopérer ou clarifier des situations (on a tous une définition différentes de "bienveillance" par exemple). De même, nous ne nous exprimons pas de la même manière à l'écrit et à l'oral. L'écrit peut sembler plus abrupte et il ne faut donc pas hésiter à repasser par de l'oral pour clarifier nos intentions.

Le tout avec des sources.

Comment décider ensemble ? – L’art de la décision en contexte agile

Une équipe agile est régulièrement amenée à prendre plein de décisions. Certaines sont simple à prendre, d'autres un peu moins et d'autres encore peuvent avoir des impacts sur toute l'entreprise. Cette disparité fait que l'équipe peut se retrouver plus ou moins régulièrement face à des difficultés pour trancher une question ou, du moins, pas mal de perte de temps. L'idée présentée est

• d'identifier clairement le type de décisions auxquelles l'équipe est confrontée.
• d'identifier des types de prises de décision (consensus, unanimité, décision par consensus éclairée par une exploration préalable, etc...) que l'équipe souhaite utiliser.
• enfin de mapper type de décision et mode de décision de sorte à avoir une méthodologie de prise de décision prédéfinie.

Sur le papier c'est intéressant, à voir s'il y a un intérêt à mettre cela en place dans ma petite équipe.