FlowCon 2026

Agile & Lean31 mars – 1 avril 2026Montrouge, Le Beffroi

Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de mars 2026 →

31 mars et 1er avril 2026, Beffroi de Montrouge. Environ 35 sessions sur 4 salles (Fast Flow, Feedback Loop, Limit WIP, Small Batch), réparties en pistes FLOW, TECH, PRODUCT et SUSTAIN. 3 keynotes : Chris Matts, Xin Yao, Pierre Masai. Talks en français et en anglais.

À FlowCon 2026, l'IA a été passée au crible du flux. Le constat revient de talk en talk : c'est un outil arrivé sans pratiques, qui amplifie les systèmes et les cultures en place, les bons comme les mauvais. Aucun intervenant ne propose de nouveau framework. Les réponses mises en avant sont le diagnostic de la nature du travail, la qualité des décisions collectives et les fondamentaux lean et sociotechniques : jidoka, standards, gemba, découplage.

17 sessions résumées · mise à jour le mercredi 30 septembre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel sur Sched (35 sessions). 17 pages de talks archivées sur flowcon.io/archives/2026, chacune avec son transcript brut (traduit automatiquement en anglais, y compris pour les talks donnés en français). Deux de ces pages proposent aussi une synthèse et une infographie de l'organisateur (Kalnik, Clavier), et deux autres une infographie seule (Provaglio, Matts). Les 17 transcripts ont été lus intégralement. Complément du 30/09/2026 : une dizaine de posts Mastodon (30 mars au 1er avril) de trois speakers, Thomas Clavier, Romeu Moura et Kenny Schwegler.

Limites : Les retours de participants restent quasi absents : aucun post LinkedIn ni article de blog post-événement n'a été trouvé au 30/09/2026 (seuls des posts d'annonce), et les quelques posts Mastodon intégrés viennent de speakers, pas du public. Les vidéos 2026 ne sont pas publiées sur la chaîne YouTube au 30/09/2026 (dernière playlist : 2025). Les résumés reposent donc sur ce qui a été dit sur scène, d'après des transcripts traduits automatiquement : erreurs fréquentes sur les noms propres, citations retraduites. 18 sessions, dont tous les ateliers, n'ont ni transcript ni retour.

Synthèse globale

1. L'IA vue à travers le flux : un amplificateur, pas une solution

Même dans les talks qui ne portaient pas sur l'IA, le constat revient sous des formes différentes : l'IA amplifie ce qui existe déjà.

  • Chris Matts parle d'un outil « arrivé sans pratiques ni problème à résoudre », qui aggrave les cultures de « failurship ».
  • Thomas Clavier y voit un « catalyseur de pratiques » qui produira beaucoup plus de code, mais pas plus de bon code.
  • Chez van Kelle & Schwegler, c'est un « bias echo » : l'IA, entraînée sur nos artefacts biaisés, renforce nos biais.
  • Pour Gharagozlou, sans transformation, l'IA « intensifie nos pratiques » et accélère la feature factory.
  • Andrea Provaglio classe l'« usage obligatoire de l'IA » parmi les symptômes de rigidité des organisations sous menace.

2. Des gains réels, mais modestes et mal mesurés

Les seuls chiffres issus du terrain sont prudents. Clavier mesure 15 à 30 % de gain, sans amélioration de la qualité, et relève une adoption très faible dans les grands groupes. Kalnik observe une migration de legacy 4 fois plus rapide, mais un gain moindre sur le build, et beaucoup d'attente dans le travail avec l'IA. Sur la mesure elle-même, Matts s'en prend à DORA utilisée pour comparer les équipes et au concept to cash. Il propose de mesurer la durée d'investissement et le coût du délai. Saint Etienne propose de détourner DORA et SPACE en indicateurs de ressenti. Aucun intervenant ne revendique de « 10x ».

3. Le lean comme mode d'emploi de l'IA

Plusieurs talks convergent pour dire que les outils lean sont les bons outils pour apprendre à travailler avec l'IA :

  • gemba sur les conversations avec l'IA, 7 gaspillages, standards et skills partagés, Monozukuri (Kalnik, Theodo) ;
  • jidoka, Andon et poka-yoke pour garder la main sur une production automatisée : « n'oubliez pas les poka-yoke et les Andon » (Masai) ;
  • garder une validation humaine et découper les contextes (Clavier).

Dans la salle, c'est la keynote jidoka qui a le plus circulé sur Mastodon : Thomas Clavier en a tiré un fil en direct et y a découvert le Jikotei Kanketsu, « absolument génial comme processus ».

Cet ancrage lean se retrouve au Lean Summit France 2026 (Bordas, Anavi). Il fait écho au passé de FlowCon, anciennement Lean Kanban France.

4. Mieux décider plutôt qu'appliquer une méthode

La deuxième ligne forte de l'édition porte sur la qualité des décisions :

  • cadrer le problème, distinguer problème et polarité, concevoir trois options, se méfier du resulting (Verschatse) ;
  • utiliser une checklist de débiaisage intégrée aux ADR, et lutter contre le faux consensus (van Kelle & Schwegler) ;
  • diagnostiquer la nature du travail avant de choisir un cadre, « le flow n'est pas une religion » (Le Marec & Bourguignon) ;
  • n'explorer aucune solution avant une représentation commune du problème (Romei) ;
  • ne pas transformer une description en prescription, qu'il s'agisse de modèles de maturité ou de checklists (Moura).

Autre signal du retour aux fondamentaux : un talk réhabilite ouvertement le cycle en V et le prédictif là où les contraintes l'imposent.

5. Le sociotechnique au premier plan : organisation, coordination, humains

  • Xin Yao le résume : « en logiciel, on déplace de l'information, pas de la matière ». Pour découpler le logiciel, il faut parfois mieux connecter les gens. Elle traite aussi les émotions face à l'IA comme des matériaux d'architecture.
  • Lassiège prédit que les entreprises AI-natives gagneront par l'absence de taxe de coordination, pas par l'IA.
  • Rohrer veut aligner valeur, organisation et technologie en même temps (« les trois ou rien »). Provaglio recommande de décentraliser la décision.
  • Côté soutenabilité humaine, Yadz évoque le burn-out et la santé mentale, Diallo l'autonomie durable et le droit à l'erreur, et Lassiège l'intensification du travail.

6. Tensions et questions ouvertes

  • Juniors et emploi. Clavier cite l'Insee (−3 % d'emplois dans le numérique entre 2023 et 2025, au détriment des moins de 29 ans). Dans la salle de Matts, un intervenant signale que des entreprises « AI-natives » recrutent à nouveau des juniors. Le sujet reste ouvert.
  • TDD et IA. Clavier parle d'un « TDD augmenté », Saint Etienne affirme que « le TDD by the book avec un agent, ça ne marche pas », et Masai range le TDD parmi les poka-yoke. Les positions divergent sur la place du test-first.
  • Thought leaders. La keynote de Matts appelait à « tuer les thought leaders » dans une conférence qui invite des speakers internationaux reconnus. Plusieurs d'entre eux l'ont reprise avec humour le lendemain (Masai, Schwegler).
  • Éthique et sécurité. Clavier (travail de modération, Cloud Act, attaques supply chain) et Yadz (travail précaire d'étiquetage) les jugent sous-traitées par les entreprises.

7. Biais et trous de cette synthèse

Cette synthèse repose surtout sur ce qui a été dit sur scène, d'après les transcripts publiés par l'organisateur et traduits automatiquement en anglais. Au 30/09/2026, aucun post LinkedIn ni article de blog post-événement n'a été trouvé. Les seuls échos de la salle sont une dizaine de posts Mastodon de trois speakers (Thomas Clavier, Romeu Moura, Kenny Schwegler) : ils confirment l'intérêt pour la keynote jidoka, le débat sur le shadow IT et la formule de Gien Verschatse sur la non-décision, mais ne disent rien du public. Les 18 autres sessions, dont tous les ateliers (DDD sans filtre, Théâtre Forum, Experiencing team flow, Roadmap Narrative…) et des talks attendus comme ceux de Daniel Vacanti et Matthew Philip, ne sont pas couvertes. Les vidéos 2026 ne sont pas encore en ligne sur YouTube.

Actions concrètes citées

  1. Ramener la conversation sur l'IA vers les pratiques et la valeur, pas vers l'outil. Faire parler les praticiens entre pairs plutôt que les thought leaders (Matts).
  2. S'attendre à des gains réels de 15 à 30 %, pas de 10x. Garder au moins une validation humaine et découper les contextes (Clavier).
  3. Former à l'IA sur le poste de travail : filmer ou relire les conversations avec l'IA, y chercher les gaspillages (jusqu'à 90 % d'attente) et partager standards et skills (Kalnik).
  4. Diagnostiquer la nature du travail (incertitude, instabilité, contraintes) avant de choisir une méthode, et composer un profil méthodologique plutôt que déployer un framework par réflexe (Le Marec & Bourguignon).
  5. Mettre des Andon et des poka-yoke dans la chaîne, y compris quand on code avec l'IA. Donner à chacun l'autorité d'arrêter (Masai).
  6. Soigner la décision : cadrer le problème, distinguer problème et polarité, concevoir trois options, faire un pre-mortem, ajouter une checklist de débiaisage aux ADR (Verschatse, van Kelle & Schwegler).
  7. Mener en parallèle une stratégie « survivre maintenant » et une stratégie « réussir demain », et décentraliser la décision jusqu'à la limite du sûr (Provaglio).
  8. Viser l'effet plutôt que le livrable : quantifier sa dette d'expérience, faire de la valeur perçue (le « delight ») une stratégie produit (Gharagozlou).
  9. Réduire la taxe de coordination : les entreprises « AI-natives » iront plus vite parce qu'elles sont plus petites, pas parce qu'elles utilisent l'IA (Lassiège).
  10. Traiter les émotions et les questions des équipes face à l'IA comme des matériaux d'architecture, par exemple l'exigence de traçabilité des décisions d'agents (Xin Yao).

Session par session

Mardi 31 mars

Keynote

First kill all the thought leaders

Chris Matts

Retours : Romeu Moura (speaker FlowCon, post Mastodon)

  • Keynote d'ouverture, présentée comme un talk sur des problèmes plutôt que sur des solutions. Sur scène, un « kanban » de quatre chaises : des volontaires de la value stream, du leadership et du coaching viennent témoigner.
  • L'IA est arrivée comme un outil, sans problème à résoudre ni pratiques établies. Dans un cycle normal, la pratique naît d'un besoin et l'outil vient après. Ici, il faut ramener la conversation vers la pratique et la valeur.
  • Communauté des besoins contre communauté des solutions : d'un côté les pionniers qui échangent entre pairs, de l'autre les thought leaders qui vendent une solution « absolue ». Ceux-ci « inventent des problèmes » (l'exemple de Listerine) et freinent la découverte collective des bons usages de l'IA, au point que les communautés Scrum, Kanban ou SAFe pourraient protéger leur territoire. « Il n'y a pas d'AI slop : les gens apprennent de nouvelles façons de travailler avec un nouvel outil » (traduit).
  • Mesure : il juge le concept to cash manipulable par la taille du backlog, et DORA « peut-être la métrique la plus toxique jamais développée » quand on s'en sert pour comparer des équipes. Il propose la durée d'investissement (de l'investissement au retour) combinée au coût du délai.
  • Culture : il oppose la culture de leadership au « failurship » (aversion au risque, sous-traitance pour avoir un coupable). L'IA amplifie les problèmes culturels existants.
  • Côté adoption, la valeur perçue est socialement construite : on change de pratique quand l'un de ses proches le fait, pas parce qu'une célébrité le dit.
  • Réactions de la salle : témoignages sur le shadow IT, la peur de ne plus avoir de place comme développeur, la perte de compréhension du code et le rôle des juniors. D'autres intervenants reprennent la keynote le lendemain (Masai, van Kelle & Schwegler).
  • Côté salle, le shadow IT a marqué : le matin même, Romeu Moura (speaker d'un autre talk) résume l'échange d'une pique, « “Je n'ai pas de problème de shadow IT”, dit la personne qui a clairement une solution de shadow IT » (traduit).

Conférence

From feature factory to delight factory

Roxana Gharagozlou — Bedrock Streaming

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Deux confusions persistantes, accélérées par l'IA : livrable contre effet (output contre outcome), et qualité contre accumulation de fonctionnalités. Elle critique les injonctions à utiliser l'IA mesurées par des KPI de volume et introduit la notion de « dette d'expérience ».
  • Cas des moteurs de réservation hôtelière : des fonctionnalités identiques sur le papier, mais des parcours cassés (tarif membre, création de compte, panier perdu). En travaillant tech, produit et design ensemble, son équipe a dépassé 40 % de conversion.
  • Elle distingue trois niveaux de delight (low, surface, deep : fonction et émotion réunies) et une équation de conversion désir × confiance × facilité, trois leviers qui se multiplient. Elle l'illustre par Apple Music (karaoké), Spotify (Wrapped) et Pokémon Go.
  • L'IA doit servir à croiser recherche utilisateur, tickets, avis, CRM et analytics pour trouver les déclencheurs d'adoption, pas à empiler des features.
  • « L'émotion n'est pas la cerise sur le gâteau, c'est une stratégie produit » (retraduit).
  • En Q&R : le delight en B2B, et une organisation fondée sur une équipe transverse garante et au moins 10 % de la roadmap consacrés au prospectif.

Conférence

Rinse-less brushing : une histoire de pratiques

Romeu Moura

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Le talk est annoncé « sans solution ». Point de départ : pourquoi les hôtels n'ont-ils presque jamais de dentifrice ? Parce que la grille d'étoiles a été construite en notant ce qu'on voyait dans les hôtels : une liste descriptive est devenue prescriptive.
  • Même tragédie dans les transformations : les modèles de maturité décrivent ce que font les bonnes équipes, puis deviennent des checklists imposées. « Interpréter ce qui décrit comme ce qui prescrit, c'est tragique » (retraduit).
  • Il file la métaphore du brossage de dents (dont le « rinse-less brushing ») pour montrer le consultant qui évangélise une micro-pratique dans des organisations à l'hygiène catastrophique.
  • Explication proposée : le nihilisme au sens de Nietzsche, compris comme un évitement de soi. Parmi ses mécanismes, l'activité mécanique (Heidegger), qui externalise nos choix dans des outils et des processus. Réclamer « juste la checklist », c'est encore de l'activité mécanique.
  • Seule invitation : le voir, en parler et prendre le temps de rétrospecter, en acceptant que ça fasse mal.
  • Session très interactive.

Conférence

Slow down to speed up your decision-making

Gien Verschatse — Aardling

Retours : Romeu Moura (speaker FlowCon, post Mastodon)

  • Constat : nous décidons mal, soit en rejetant une techno qui a échoué une fois, soit en répétant ce qui a marché ailleurs. Autre écueil, le « participation theater », où tout le monde participe mais personne ne décide.
  • Elle définit la décision comme un choix entre au moins deux options, avec une allocation irrévocable de ressources. Ne pas décider, c'est laisser le temps décider.
  • Le cadrage est l'étape la plus négligée. Il faut distinguer un problème d'une polarité, qui se gère au lieu de se résoudre (polarity map). On peut aussi rendre un problème non pertinent. Il faut éviter les énoncés qui contiennent déjà la solution (« comment passer aux microservices ? ») et les reformuler : paraphraser, réorienter, demander pourquoi.
  • Méthode : chercher l'information par la modélisation collaborative et s'arrêter quand elle ne fait plus changer d'avis. Concevoir trois options pour sortir du « nous contre eux ». Rendre les compromis visibles avec une liste « pro-con-fix ».
  • « Une bonne décision ne garantit pas un bon résultat » (traduit). Il faut se méfier du resulting, qui juge la décision à son résultat. Ce soin apporte clarté et cohérence, et c'est ce qui permet d'aller plus vite avec le temps.
  • Phrase retenue par la salle : « ne pas décider, c'est décider de laisser le temps décider à sa place » (traduit), citée en direct par Romeu Moura et relayée par la speaker.

Conférence

Soutenable et durable : trouve ta stratégie lundi avec le Doughnut produit

Yadz (Haja Rambelontsalama) — Platform product manager

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Talk expérientiel, où la participation est libre. La conférence devient une « planète » baptisée par la salle, avec des itérations courtes en direct : une chanson qui ne prend pas, un débrief, puis de nouvelles tentatives, pour illustrer le pivot.
  • Il salue les participants qui osent dire que ça ne marche pas, et dénonce le « ce n'est pas ton job » qui fait taire l'initiative (retraduit).
  • Il recadre l'objectif : viser 100 % d'adhésion n'est pas nécessaire. « Dire “pas encore”, c'est un acte de leadership » (retraduit). Il évoque aussi un burn-out vécu sur son premier produit : « la vraie valeur, c'est la santé mentale ».
  • Il applique le Doughnut de Kate Raworth au produit : des seuils minimaux et des plafonds à ne pas dépasser, par exemple trop peu d'innovation ou trop sans consolidation. Une stratégie qui ignore l'adoption humaine échoue, et produire plus vite avec l'IA ce que personne n'utilise reste du gaspillage.

Keynote

Sociotechnical Architecture – Finding Flow

Xin Yao

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Elle part du dev assisté par IA (spec, prompt, attente, review, re-prompt) : « créer donne de l'énergie, relire épuise » (traduit). Le risque est d'avoir un flux rapide de code sans se soucier de ce qui coule.

  • En logiciel, on déplace de l'information, pas de la matière : le flux de travail dépend du flux de compréhension. Elle s'appuie sur la rationalité limitée (review agentique le soir, « good enough ») et sur l'architecture comme compréhension partagée.

  • Sur le sociotechnique :

    • la manœuvre de Conway inversée échoue souvent ;
    • l'organisation est une forêt tropicale, le logiciel une Ferrari ;
    • elle distingue flow de livraison et flow génératif, où la valeur est aussi dans les liens.

    Paradoxe : « pour bien découpler le logiciel, il faut parfois mieux connecter les gens » (traduit).

  • REX dans une institution financière nordique organisée en 27 squads et 5 tribus, avec deux bloqueurs : la délamination entre stratégie et exécution, et la désintégration en silos avec OKR locaux.

  • Atelier chez un assureur sur l'architecture agentique des sinistres, en mêlant emotion/empathy mapping et ADR. L'impuissance d'un agent support face à un refus décidé par des agents IA a produit une exigence : tracer les décisions à travers les systèmes d'agents. Les émotions deviennent des matériaux d'architecture.

Conférence

Leading Through Disruption

Andrea Provaglio

Retours : aucun retour participant trouvé (d'après le transcript officiel et l'infographie de l'organisateur)

  • Il constate une « régression » des organisations depuis 5 ou 6 ans face aux disruptions : pandémie, géopolitique, IA et licenciements, générations, énergie.
  • Théorie de la « threat rigidity » : sous la menace, les organisations gèlent. Elles traitent moins d'information, renforcent le contrôle et reviennent à leurs habitudes. Il cite l'Agile, « conçu pour l'adaptation et transformé en outil de contrôle » (traduit).
  • Sondage en direct sur les symptômes de rigidité : contrôle, plus de réunions, gates punitives, usage obligatoire de l'IA, décisions HiPPO.
  • Mais les réponses sont souvent mixtes. Spotify et le travail de n'importe où ; Microsoft qui, le même mois, licencie 10 000 personnes et investit des milliards dans OpenAI.
  • Trois recommandations :
    • prendre conscience de sa rigidité ;
    • mener en parallèle une stratégie « survivre maintenant » et une stratégie « réussir demain », et protéger la seconde ;
    • décentraliser pouvoir et décision jusqu'à la limite du sûr, en visant l'alignement plutôt que les outils (« le but, c'est l'alignement, pas les OKR »).

Conférence

L'architecture vue par un dev de 2026

Guillaume Saint Etienne

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Il critique l'architecte en tour d'ivoire (frameworks, cérémonies, dashboards) et lui oppose un « Craft Architect » proche du terrain. Il rappelle que la built-in quality de SAFe a été oubliée.
  • « Pour l'IA, le code n'est que du contexte ; pour nous, humains, c'est une culture » (retraduit).
  • Retour d'expérience avec les agents :
    • les agents sont très bons pour écrire des tests ;
    • des pratiques autrefois hors de portée, comme le property-based testing ou le mutation testing, deviennent accessibles ;
    • « le TDD by the book avec un agent, ça ne marche pas » ;
    • il faut commencer par des specs ;
    • SpecKit s'est révélé décevant (verbeux, coûteux en tokens).
  • Il distingue trois dettes : technique, cognitive, et de contexte ou d'intention, cette dernière croissant avec les agents. Côté DevEx, il propose des indicateurs de ressenti plutôt que des objectifs (DORA et SPACE détournés, time to first deploy).
  • Il recommande une décision décentralisée : advice process, RFC, ADR (utiles aussi comme contexte pour les agents). Conclusion : des architectes non hiérarchiques, « l'ennemi, c'est la dette, pas le développeur ».

Conférence

Les sociétés AI natives : quand le code devient une commodité, que se passe-t-il ?

Hugo Lassiège — ex-cofondateur de Malt

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Il relativise la « fin des développeurs » : Fortran, SQL, MDA/UML et l'offshoring ont déjà changé le métier sans le faire disparaître. Le métier, c'est aussi tomber amoureux d'un problème et faire des compromis de design.
  • Il fait un parallèle avec le cloud : « une technologie s'adopte, une culture s'implémente » (retraduit). Après les entreprises « cloud native » viendront les entreprises « AI-natives ».
  • Le volume de code n'est plus un avantage concurrentiel : exemple d'un clone de LinkedIn produit par une seule personne, « SaaS apocalypse », build, buy or rent. Ce qui protège encore : données exclusives, effets de réseau, certifications, distribution.
  • Il alerte sur l'intensification du travail (disparition des pauses cognitives) et sur la surproduction.
  • Les entreprises AI-natives iront plus vite parce qu'elles n'auront pas de taxe de coordination, pas parce qu'elles utilisent l'IA, que tout le monde utilisera. Retour à la sobriété organisationnelle.
  • Les rôles convergent (des PM qui font des PR chez Alan) et le profil en T cède la place au profil « en râteau » : l'IA amplifie une connaissance existante, pas une connaissance absente.

Mercredi 1 avril

Keynote

Jidoka in Lean Engineering

Pierre Masai — Lean Institute Belgium, ex-DSI Toyota Europe

Retours : Thomas Clavier (speaker FlowCon, fil Mastodon en direct)

  • Jidoka est le pilier oublié du lean : « si vous ne faites pas jidoka, il est impossible de faire du lean » (traduit). Il présente son « ontologie du lean », issue de sa thèse. L'agile relève surtout du juste-à-temps. Il lui manque le Hoshin Kanri et la sécurité, et seule l'escalade des impediments ressemble à un Andon.
  • Aux origines, le métier à tisser de Sakichi Toyota, qui s'arrête quand le fil casse. L'idée profonde de jidoka est d'aider les gens : arrêter la ligne, c'est demander de l'aide. Une usine Toyota compte environ 2 000 appels Andon par jour, et l'objectif n'est pas zéro.
  • Le poka-yoke est préférable à l'Andon. Exemples en IT : clés de contrôle, linting, détection d'injection SQL, langages sans pointeur null, TDD.
  • Jikotei Kanketsu (qualité intégrée avec appropriation) : savoir juger soi-même la qualité et avoir l'autorité d'arrêter. Il conseille d'envoyer les devs faire de l'ops.
  • Il oppose le chief engineer Toyota, responsable du compte de résultat, au product owner « choisi parce qu'il est disponible ».
  • Sur l'IA : ces pratiques vaudront aussi. Un jeune qui code avec l'IA doit pouvoir tirer l'Andon. « Utilisez l'IA quand c'est pertinent, mais n'oubliez pas les poka-yoke et les Andon. »
  • Ce qu'en a retenu un participant : Thomas Clavier (lui-même speaker le même jour) a suivi la keynote en direct, « un sujet qui me passionne ». Il en garde une définition en trois temps (arrêter la ligne pour demander de l'aide, trouver la cause racine pour ne plus l'arrêter, détecter les défauts au plus tôt), les trois outils Andon, poka-yoke et Jikotei Kanketsu, et la comparaison lean contre agile projetée à l'écran. Sa découverte : « le Jikotei Kanketsu, c'est absolument génial comme processus ».

Conférence

Debiasing Your Software Design Decision-Making

Evelyn van Kelle, Kenny (Baas) Schwegler

Retours : Kenny Schwegler (speaker, fil Mastodon publié la veille du talk)

  • En modélisation collaborative, les biais se multiplient par le nombre de participants. En logiciel s'ajoute une boucle de renforcement : une décision biaisée devient un artefact (ADR, code, diagrammes) qui forme le modèle mental suivant. « Votre architecture enseigne aux équipes à quoi ressemble une bonne architecture » (traduit).

  • La prise de conscience ne suffit pas. Il faut des nudges, d'où une checklist en 5 points, chacun avec son biais et son antidote :

    • être prêt à décider (la « myopic misery » : noter son état) ;
    • élargir le cadre (biais additif, fixité fonctionnelle) ;
    • chercher un avis vraiment indépendant (excès de confiance, pre-mortem) ;
    • tester ses hypothèses (biais d'autorité : « et si un junior l'avait proposé ? ») ;
    • établir des règles simples (bikeshedding, portes réversibles, advice process).

  • Check collectif final contre le faux consensus : « de quoi auriez-vous besoin pour suivre ? » (Deep Democracy).

  • La checklist est publiée sur le DDD Crew et intégrée au template d'ADR chez DHL.

  • Côté IA :

    • biais d'autorité envers les algorithmes ;
    • effet de mode sur LinkedIn ;
    • « bias echo » : l'IA, entraînée sur nos artefacts biaisés, renforce la boucle.

    « Ni la confiance aveugle ni le rejet en bloc ne mènent à de bonnes décisions. »

  • En amont, sur Mastodon (speaker) : Kenny Schwegler résume l'idée des simple rules : la surcharge cognitive pousse le groupe à chercher la clôture au plus vite, d'où les débats de nommage qui évitent le vrai sujet (le « comportement de bord » de Deep Democracy). Sa règle à essayer : demander « qu'est-ce qui ferait de cette conversation une perte de temps ? » avant toute décision (traduit). Le 30 mars, il appelait aussi les talks IA à dépasser la vitesse : « les bons ingénieurs avec l'IA obtiennent des outcomes plus rapides, les autres un output plus rapide » (traduit).

Conférence

Les standards Lean pour guider les IA

Marek Kalnik — Theodo

Retours : Thomas Clavier (speaker FlowCon, post Mastodon publié pendant le créneau du talk, sans le nommer)

  • Constat : le potentiel est réel (tâche accélérée d'un facteur 7 avec Copilot, agents capables de tâches longues). Mais beaucoup de devs sont perdus, réduits à « regarder une barre de progression ». L'IA est probabiliste, « un logiciel qui n'est pas un logiciel, un humain qui n'est pas un humain ».

  • Inspiré du Monozukuri de Toyota (comprendre profondément son matériau), il propose trois axes : coder soi-même, faire du gemba, et adopter une démarche de recherche (prompts et modèles en parallèle). « L'usage de l'IA est une compétence qui s'apprend. »

  • Former sur le poste de travail (Job Instruction), pas en séminaire. On filme 5 minutes de travail avec l'IA et on les analyse avec les 7 gaspillages : l'attente représente jusqu'à 90 % du temps des vidéos.

  • « Ce que produit un développeur qui travaille avec l'IA, c'est une conversation avec l'IA » : on l'analyse (intention, contexte, bon outil). Autre enseignement : la qualité de la codebase conditionne la sortie. Il a établi une matrice d'environ 15 critères « AI-ready » ; les prompts récurrents deviennent des skills partagées, revues par PR.

  • Résultats :

    • une migration de legacy 4 fois plus rapide ;
    • moins d'impact sur le build, qui dépend de bonnes specs ;
    • un passage à l'échelle coûteux sur 600 personnes.

    En Q&R : IA ajoutée au recrutement et à l'évaluation, départs de réfractaires, standards relevés à chaque nouveau modèle.

  • Écho possible dans la salle : pendant le créneau du talk, Thomas Clavier publie sous #lean « un standard, c'est pas une recette de cuisine pour quelqu'un qui n'y connaît rien, mais un aide-mémoire pour l'opérateur qui a été formé ». Le post ne nomme pas la session ; le rattachement est déduit de l'horaire et du sujet.

Conférence

Autonomie durable : quand nos finances éclairent nos produits et nos équipes

Saïbatou Diallo — WAKILEE

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Un sondage live sur « ce qui vous rend autonome » place en tête la confiance, puis les compétences, la clarté, le budget et le mandat pour agir.
  • Son histoire : en 2018, un objectif d'indépendance financière à 45 ans. Il n'est pas atteint, mais elle a construit une « autonomie durable », un système qui tient dans l'incertitude, par un cycle apprendre, appliquer, feedback, ajuster.
  • Quatre lois transposées aux équipes : arbitrage (priorisation), risque (droit à l'erreur, expérimentation), feedback (boucle produit : « sans feedback, on construit une fiction ») et horizon (stratégie par horizons).
  • Cinq archétypes de comportement (l'écureuil, le saboteur, les montagnes russes…), commentés par la salle. Trois niveaux d'autonomie : individu, équipe, organisation. Une organisation qui veut des équipes autonomes sans leur laisser droit à l'erreur ni marge « peut rêver longtemps ».
  • Outil proposé : le portefeuille d'autonomie (capacité, sécurité, paris, vision, dépendances).

Conférence

Modern Enterprise Architecture: Architecting for Outcomes

Simon Rohrer — Saxo Bank, co-auteur de Sooner Safer Happier

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Son cadre ABCDE :
    • Aligner et rendre cohérents valeur, organisation et technologie : « les trois ou rien », avec une loi de Conway bidirectionnelle ;
    • Better value sooner safer happier, une scorecard équilibrée ;
    • C, une gouvernance continue et conversationnelle ;
    • D, du DevOps à l'échelle de l'entreprise ;
    • E, une architecture évolutionnaire.
  • Les architecture review boards sont un anti-pattern en mode produit. À la place : des conversations tôt, une gouvernance automatisée, des paved paths, une petite équipe centrale et une communauté de pratique.
  • L'architecte d'entreprise doit parcourir toute la boucle DevOps, run et observabilité compris.
  • Il faut consacrer 20 à 30 % du budget à rembourser la dette de complexité, technique et organisationnelle, sans exclure des ruptures ponctuelles (Strangler Fig). Chez Saxo, le point de départ était un monolithe distribué de plus de 1 200 services, avec sept ans de refactoring.
  • Sur l'IA : ses agents codent et il relit. Il ne croit pas à des équipes réduites à « un AI wrangler et un PO », et rappelle que « passer à l'IA » n'est pas un outcome.

Conférence

Le flow n'est pas une religion

Brieuc Le Marec — Sopra Steria Next, Sébastien Bourguignon

Retours : aucun retour participant trouvé (d'après le transcript officiel, de qualité médiocre)

  • Constat : dans la grande majorité des cas qu'ils observent, un modèle opérationnel est déployé par réflexe, dogmatiquement, sans regarder la nature du travail. Contre-exemple : la refonte du SI qualité d'un groupe de défense, passée en agile sur proposition du fournisseur, qu'ils ont sortie de crise en revenant à une gouvernance en cycle en V.
  • Il faut caractériser le travail selon trois facteurs : incertitude, instabilité et contraintes (contrats, régulation, legacy, experts rares). La nature « exploratoire » est aujourd'hui fréquente autour de l'IA.
  • Une boîte à outils plus large qu'on ne croit, en six familles : prédictif, agilité empirique, exploratoire/discovery, flow (Lean, Kanban), hybride, chaîne critique/TOC. Le diagnostic donne un profil méthodologique à composer, pas une méthode.
  • Ils l'ont testé sur deux cas réels, un cœur de SI assurance et une billettique de transport.
  • « Vous n'avez pas besoin de nouvelles méthodes, vous avez besoin d'un diagnostic » et « redonner un peu de sa gloire au prédictif » (retraduits).
  • En Q&R : un assureur vise 30 % de périmètres en mode produit sur trois ans et garde du V, du Scrum et du SAFe ailleurs.

Conférence

Du bruit au signal : le guide pratique de l'IA pour les développeurs

Thomas Clavier

Retours : aucun retour participant trouvé (d'après le transcript officiel et la synthèse de l'organisateur)

  • Recherche-action fondée sur une douzaine d'entretiens d'au moins 1 h 45 avec des « champions » de l'IA générative.
  • Gains mesurés : entre 15 et 30 % (business value, pull requests). Certains devs ont le sentiment d'un 10x que les mesures ne confirment pas. La qualité du code ne change pas.
  • L'adoption reste faible dans les grands groupes. Dans une ESN de 4 390 devs tous équipés d'une licence, 183 l'utilisent au moins une fois par mois et 6 dépensent plus de 200 $/mois.
  • Trois modes d'usage aux résultats équivalents : l'artisanat augmenté (agents conseillers), le TDD augmenté, et le dev qui orchestre des dizaines d'agents. Les agents remplacent de petites étapes, pas des rôles. L'IA est un « catalyseur de pratiques » qui amplifie le bon comme le mauvais.
  • Le métier se déplace vers la spec, l'analyse et les cas de test : la pyramide de tests devient un « diamant ». La documentation redevient cruciale.
  • Ce qui marche : les migrations de versions, les petits scripts, les contextes petits et maîtrisés.
  • Ce qui ne marche pas : une réécriture Windows Forms vers React qualifiée de « désastre total », des tests modifiés par l'IA pour passer, et des sujets de sécurité et d'éthique sous-estimés.
  • Il cite l'Insee : −3 % d'emplois dans l'informatique et le numérique entre 2023 et 2025, au détriment des moins de 29 ans.
  • Recommandations : garder le contrôle humain, « découper, découper, découper », réécrire ses skills et règles pour son propre contexte.

Conférence

EventStorming & Iterative Governance in Heavy Industry

Jacopo Romei — Scaling Tales

Retours : aucun retour participant trouvé (d'après le transcript officiel)

  • Session de clôture sous forme de récit : une mission de gouvernance chez un fabricant italien de cuves en acier d'environ 40 personnes, l'un des quatre acteurs mondiaux du marché.
  • Il posait trois conditions : tous les départements dans la même salle, cols blancs et cols bleus mêlés ; c'est lui qui mène ; des demi-journées seulement. Son offre en options était garantie « satisfait ou remboursé » (« on peut être bête si on a de l'optionnalité »).
  • Il a déroulé le cadre QUEST (Question, Envision, Select, Take) :
    • un EventStorming à 40, avec un Dot Game glissé au milieu pour introduire le lean sans le nommer ;
    • une priorisation des problèmes où le veto revient aux non-dirigeants ;
    • aucune solution avant une représentation commune du problème ;
    • des équipes transverses avec Popcorn Flow, puis un « marché des solutions » où le vote vaut engagement ;
    • des expérimentations de deux semaines.
  • Résultat : quelques mois plus tard, un mail spontané du dirigeant saluait l'enthousiasme et surtout des ouvriers qui « réfléchissent ».
  • Côté IA, les LLM sont utiles pour les phases divergentes. On peut aussi soumettre la photo d'un mur d'EventStorming pour faire ressortir les hotspots.

Sessions sans retour trouvé (18)

  • Strategic PlatformOps with Wardley maps (Andrey Adamovich)
  • Domain-Driven Design (DDD) sans filtre — atelier (Pierrick Blons & Maxime Sanglan-Charlier, Payfit)
  • Org Topologies from the trenches (Michael Voorhaen, Protime)
  • Infinity : structurer l'adaptabilité de votre organisation… durablement (Rafik Mekki)
  • L'IA pour lancer son produit — atelier (Thomas Babin, JBT Engineering)
  • How Rittal Builds Flow Across Mechanics and Software (Benjamin Igna)
  • Mind Your P's and Queues (Daniel Vacanti)
  • Reinertsen's Lottery and other Product Management Lessons (Matthew Philip)
  • Théâtre Forum : répliques inspirantes pour surmonter les micro-agressions de genre — atelier (Florence Chabanois)
  • Sécurité & IA (Mathieu Renard, Twisted Wires)
  • Comment la prospective peut embarquer un collectif vers un objectif commun ambitieux ? (Aurélie Gauthier)
  • Est-ce que la taille (des éléments de travail) ça compte ? (Sébastien Goodwin)
  • Talk the Talk and Walk the Walk: Living Ubiquitous Language Documentation (Chris Simon)
  • Experiencing team flow — atelier (Michel Grootjans, SmallSteps)
  • La DevEx, quand l'expérience compte (Lana Lesik, OCTO Technology)
  • Modelling Intelligence in Domain Driven Design (Hana Amiri)
  • Roadmap Narrative : de la confrontation à la progression utilisateur — atelier (Pascal Poussard & Christian Gossart, essensei)
  • L'art délicat de piloter 20 équipes sans se faire huer (Nicolas Nallet & Nicholas Suter, Believe)

Sources