Forum Ouvert du Mardi 02 Septembre 2025

  • Sujet : Forum ouvert
  • Meetup
  • Format : Forum ouvert
  • Nombre de participants : 21

Sujets

Session 1: 19h15 - 20h

Piéger les gens dans le changement

  • C’est très facile d’aller contre le changement et rapidement délétaire
  • La situation compliquée est quand tout le monde ne s’accorde pas à constater un problème
  • Je dois alors accepter de me mettre à risque. Il peut etre bon d’avoir des contre-mesures pour sa sérénité perso.
  • J’impulse naivement un début de changement (un commit par exemple), le but est d’observer les réactions. Cela me permet d’identifer les pour/neutre/contre.
  • En focalisant sur les contre, je peux écouter et comprendre les craintes. J’essaie de lever ces craintes avec des propositions où je “risque” beaucoup. La clef c’est d’avoir suffisament de “pour” et surtout de ne pas crystaliser les remarques négatives (même non liées à ce sujet).
  • Question : faut il convaincre surtout les personnes de pouvoir ? Oui mais ce n’est pas forcement le CxO. Il faut tenter de comprendre les dynamiques de pouvoir et de craintes interpersonnelles.
  • Strategie: proposer 4 choses differentes en acceptant de ceder sur 3 d’entre elles pour introduire une nouveaute sur les quatre.

On a testé Ink pour avoir la joie de faire des Flexbox dans le terminal avec React

Pas de notes

La façon de développer une application a changé ces dernières années…

…(NodeJs a révolutionné l’approche du développement, loin de Java ou .Net). Cette révolution a changé qui peut développer et comment c’est développé. Quelle qualité de code attend-on aujourd’hui ? Quelle est la place des notions craft ? Merci.

  • Résumé :
    • Qualité prise de conscience
    • Recherche de vélocité sur l’écriture de nouvelles fonctionnalité
    • FE assez jeune. Les gens se cherchent.
    • Évolutions d’Angular par exemple, avec des solutions personnelles plutôt que des libs.
    • Qualité sur la durée.
    • Code FE découplée :
      • visuel et graphique (vu par le client) est le plus important
      • Etat / Mémoire optimisé
    • Développement FE métier à part entière.
    • Les métriques de productivités sont maintenant présentes. La productivité se mesure aujourd’hui. Un code de mauvaise qualité se voit par ces métriques.
    • Recrutement attirer des dév. Techo à la mode : faire cargo cult.

Le frontend web est devenu une application à part entière…

…qui gère un état, se synchronise avec le backend, utilise un énorme stack, etc. Combien d’entreprises pourraient remplacer Typescript, React, Vue ou Angular par un stack plus simple ? Technologies alternatives : JSDoc, HTMX, …

Pas de notes

Hackez vos apprentissages avec le système de Leitner

  • Contexte : apprentissage accéléré pour la certification AWS Developer Associate

  • Découverte de la méthode via la Memory Box de Fabien Olicard

  • Cette méthode utilise les flashcards

  • Un outil populaire : Anki

  • Le workflow : découvrir le cours en vidéo, puis cours avec slides -> IA avec consignes -> flashcards avec Anki

  • Faire pondre le prompt par l’IA elle-même

  • Une question rapide, une réponse courte, apprendre les 2 côtés de la carte

  • David Louapre, science étonnante en parle :

  • https://www.youtube.com/@ScienceEtonnante

  • https://www.youtube.com/watch?v=RVB3PBPxMWg

  • La pratique est dure à battre : sandboxes, free tier

  • L’écriture de la flashcard contribue à l’apprentissage

  • Fellienne Hermans https://www.felienne.com/

  • “How to teach programming (and other things)?” https://www.youtube.com/watch?v=g1ib43q3uXQ

  • The Programmer’s Brain par Felienne Hermans : https://www.manning.com/books/the-programmers-brain

  • Multi-modal : par plusieurs canaux (audio, visuel, …) -> ¿ flashcards physiques ?

  • Expliquer au canard

  • Méthode zettelkasten, zettelnotes

  • Évocation d’un système avec Obsidian par Marc Bouvier et Aurélien Mino, apprendre en enseignant

  • https://everlaab.com/methode-zettelkasten-comment-prendre-des-notes-utiles/

  • REX de Youssef en tant que mentor d’Open Classrooms allant dans ce sens (digression : il faut compter 2,5 ans pour la formation au lieu de l’année annoncée)

  • Être proactif afin de ne pas avoir à apprendre dans l’urgence : lire 1/2 heure par jour, en tournant avec 3 livres : un pour le court terme, un pour le moyen terme, un pour le fun

  • Recommandations du livre the Pragmatic Programmer

    • lire un livre par mois
    • apprendre un nouveau langage (vraiment différent) par an
    • gérer ses connaissances comme un portefeuille d’actions : voir ce qui est à la hausse, à la baisse, quoi apprendre, quoi laisser tomber, …

  • Agile Technical Practices Distilled (Pakt) par Pedro M. Santos, Marco Consolaro and Alessandro Di Gioia : https://www.packtpub.com/en-de/product/agile-technical-practices-distilled-9781838980849

Découverte de l’agilité en vrai.

  • Suite d’une discussion entamée à l’AG mercredi dernier.

  • Je découvre les sprints dans mon nouveau poste. Et avec eux les story points, l’engagement à l’aveugle et la course à l’urgence. J’aimerais confronter mon regard neuf à vos techniques de sioux pour se préserver dans un premier temps et peut-être plus tard interroger.

  • Noter les points d’étonnement tant qu’on est dans la découverte.

  • Proposer de réaliser une rétrospective

  • Faire des retours quand c’est possible pour faire évoluer les règles si elles sont à questionner

  • Beaucoup de cérémonies et d’outils qui finalement ne sont pas productifs

  • Absurdité : Au final tout le monde s’en fout ?

  • https://fr.wikipedia.org/wiki/Culte_du_cargo

  • “The term “cargo cult” is widely used negatively as a metaphor outside anthropology. Usage often relates to the ideas of desire (particularly for wealth and material goods) and relatedly consumerism and capitalism, ritual action and the expectation of rational results from irrational means.[25] Richard Feynman used the term to describe situations where people focus on superficial aspects of a process without understanding the underlying principles – he specifically cautioned against “cargo cult science”, warning that adopting the appearances of scientific investigation without a self-critical attitude will fail to produce reliable results.[26]: 338  “Cargo cult programming” was popularized as computing slang to describe the inclusion of code that serves no purpose in a program, indicating a lack of understanding of the program structure by the programmer.[27] Lindstrom noted in 2013 that users of the term have stretched the definition to such a degree that it has become a general pejorative for “almost anything that some critic depreciates”.[28]”

  • Loi de Parkinson : https://fr.wikipedia.org/wiki/Loi_de_Parkinson

  • Mithridatisation : https://fr.wikipedia.org/wiki/Mithridatisation

  • Le seul potentiel intérêt des estimations = les discussions que ça fait émerger dans l’équipe

Dilemme, d’un côté trouvez dommage que les entreprises n’internalisent pas ou peu les compétences en développement, de l’autre faire de la presta.

Pas de notes

J’ai un problème avec le principe même du DDD, qui consiste à faire TOUT transiter dans le Domain. …

… La plupart du temps, une grosse partie du boulot du backend est de faire du pur CRUD, qui donne un rôle de passe plat au Domain et qui pollue beaucoup la logique métier. Est-ce que je suis seul dans ce cas ?

  • Mon probleme: DDD m’impose a proposer un domain qui gere de la logique metier pure avec des ports/adpaters pour faire transiter de les requetes.
  • Mon backend devient un distributeur de donnees (un repository?) et me force a passer par plusieurs couches avant de toucher un metier qui serait tres (trop) simple.
  • Test unitaire = un cas metier qui est gerer par une methode dediee de mon domaine.
  • Si on procède CRUD-style on se retrouve vite à avoir des mocks partout, et à tester le système de mock plutôt que le code métier
  • Clarification du terme “domaine”, les invariants impactent le domaine, c’est plus qu’un data model glorifié
  • CRUD-style : on perd un temps fou à comprendre comment on est arrivé à l’état courant (ex : fiche client archivée versus fiche client active : ce n’est pas la même classe et on ne peut donc pas faire les mêmes choses)

Mentoring, accompagnement, supervision. Différences et approches.

  • Samman method: https://sammancoaching.org/
  • Definir la posture influe sur l’impact (e.g. CTO qui ne peut pas accompagner individuellement vs un simple dev qui ne peut pas faire d’archi)
  • Monter dans les rôles facilite “d’imposer des idées (e.g. Tech lead, CTO) => confiance/rapport à l’autorité
  • On peut tenter de ne pas mettre de veto, ça bloque dans tous les cas:
    • veto : pas d’adhésion
    • laisser passer : potentiel soucis
  • Proposer une idée : une simple proposition, qu’elle soit (com)prise ou non, possibilité de revenir dessus si une expérience à pu donner un nouvel éclairage
  • Tenter de comprendre pourquoi un(e) collègue pousse une idée de manière insistante, voir s’il y a un vrai angle mort ou une autre solution

Rétrospective

  • Bonne session
  • Un mini-couloir
  • Faire des sessions de durées différentes sur une même soirée ?
  • Certains sujets sont préparés, d’autres pas du tout, avoir des créneaux de 45 ET de 20 minutes permettraient de les dispatcher

ROTI

  • 2/5 : 1
  • π/5 : 1
  • 4/5 : 8
  • 4.38465/5 : 1
  • 4/5 : 1
  • 5/5 : 3
  • 5+/5 : 1
forum-ouvert