MiXiT 2026 : on the road again !

Prélude

Les 16 et 17 avril 2026, direction Lyon pour la 15ᵉ édition de MiXiT, une conférence à part dans l’écosystème tech français, où l’on parle autant de code que d’éthique, autant d’architecture logicielle que d’architecture sociale.

MiXiT, ce n’est pas “juste” une conférence : c’est 2 jours, plus de 70 speakers, plus de 50 sessions, et près de 600 participantes et participants (je pense) réunis autour d’un objectif commun : faire avancer la tech… sans oublier les humains qui la fabriquent.

Ici, on croise des développeurs, des designers, des agilistes, des product managers, mais aussi des profils venus questionner notre industrie sous un angle différent : sociologie, écologie, accessibilité, diversité…

Car oui, MiXiT revendique depuis sa création en 2011 une ligne éditoriale forte : proposer une conférence accessible, inclusive et engagée, capable de faire dialoguer technologie, société et responsabilité.

De mon côté, j’y retournais pour la seconde fois en tant que speaker, après une première expérience en 2023 où j’avais eu le plaisir d’animer l’atelier “Lego Flow Game : le waterfall, le scrum et le kanban tu différencieras !” et une troisième fois en tant qu’attendee. Autant dire que revenir à MiXiT, c’est un peu comme retrouver une communauté qui te rappelle pourquoi tu as choisi ce métier.

Parce qu’ici, on ne vient pas seulement apprendre. On vient réfléchir. On vient questionner. On vient rencontrer.

Et quelque part entre deux talks et trois discussions passionnées, on se rappelle que la tech peut (et doit) être un levier de progrès… pour toutes et tous.

Pourquoi cette conférence est différente ? Parce qu’elle ne cherche pas uniquement à nous rendre meilleurs techniquement. Elle cherche aussi à nous rendre meilleurs… humainement.

Chapitre 1 : “L’intelligence artificielle générale n’aura pas lieu” – Thibault Prévost

La conférence commence fort avec une keynote d’ouverture qui pose immédiatement le décor : non, l’intelligence artificielle générale n’est pas une évidence, ni une trajectoire inéluctable. Et surtout, elle n’est pas une promesse neutre.

Ce qui m’a marquée dès les premières minutes, c’est l’ancrage historique de la technocritique. On pourrait croire que le scepticisme vis-à-vis de l’IA est récent, presque réactionnaire… mais en réalité, il accompagne l’IA depuis ses origines. Déjà dans les années 1950, avec les travaux autour de la machine de Turing, des voix s’élevaient pour questionner ce que signifiait réellement “penser” pour une machine. Autrement dit : l’emballement narratif autour de l’IA n’a jamais été uniquement une affaire technique, c’est aussi une affaire de récit.

Premier point d’alerte : l’anthropomorphisation de la machine. Plus on attribue des qualités humaines à un système technique, plus on risque l’effet miroir : la déshumanisation de l’humain. Si la machine “comprend”, “raisonne”, “décide”… alors l’humain peut être tenté de se déresponsabiliser, voire de se déqualifier. Après tout, pourquoi apprendre, pourquoi exercer son esprit critiuqe, si un système semble pouvoir produire une réponse instantanée ?

Ce glissement est d’autant plus problématique qu’il s’accompagne d’une bataille sémantique. Derrière les termes employés – intelligence, apprentissage, autonomie – il y a des stratégies d’influence. Parler d’“intelligence” artificielle plutôt que de “statistiques avancées” n’est pas anodin. La promesse d’une IA générale, capable de rivaliser avec l’intelligence humaine dans tous les domaines, reste aujourd’hui largement spéculative. Aucun indicateur tangible ne démontre l’existence d’un tel système, ni même un consensus sur sa faisabilité à court terme.

Ce qui se joue dépasse la technologie : on touche parfois à une forme de croyance. Certaines prises de position ne relèvent plus uniquement de l’analyse scientifique mais d’un imaginaire quasi religieux autour du progrès technologique. Comme si la puissance de calcul suffisait à résoudre des problématiques profondément humaines, sociales, politiques.

Un passage particulièrement frappant concerne l’obsession de mesurer l’intelligence humaine. L’histoire nous rappelle que ces tentatives ont souvent été liées à des dérives idéologiques : eugénisme, hiérarchisation des individus selon leur origine, leur genre, leurs capacités supposées. L’évocation du rôle de certaines institutions académiques, notamment dans la formalisation d’indicateurs d’intelligence, montre à quel point la notion même de “mesure” peut être chargée d’implicites culturels et politiques.

La promesse d’un futur piloté par une élite technologique fait écho à d’autres périodes historiques, notamment l’Angleterre victorienne, où la foi dans le progrès scientifique se mêlait à une vision très hiérarchisée de la société.

Un rappel essentiel : aucune technologie n’est neutre. Elle est le produit d’un contexte, d’intérêts, de rapports de force. Les biais que l’on observe aujourd’hui dans certains systèmes d’IA ne surgissent pas spontanément : ils prolongent des structures existantes – discriminations raciales, biais de genre, visions normatives du monde.

La keynote se termine sur une invitation à l’autocritique. Pas un rejet de la technologie, mais une responsabilité collective : questionner les récits que nous construisons autour d’elle, examiner les usages que nous encourageons, garder un regard lucide sur les promesses annoncées.

Une ouverture stimulante, qui rappelle que s’intéresser à l’IA, ce n’est pas seulement comprendre comment elle fonctionne, mais aussi comprendre ce qu’elle raconte de nous.

Lien vers la vidéo de Thibault - à venir

Chapitre 2 : “Dev & Ops : des clients comme les autres ?” - mon chapitre à moi - Fanny KLAUK

Reprendre le chemin des conférences après un an de pause, c’est un peu comme rouvrir un carnet qu’on avait laissé en plan : on sait pourquoi on l’avait refermé, mais on se demande si on va encore reconnaître son écriture. Pendant douze mois, j’ai troqué la scène pour les coulisses, organisé, accompagné, observé celles et ceux qui vivaient ces moments intenses de partage. Une parenthèse riche, nécessaire… mais qui a doucement ravivé l’envie de revenir raconter, à mon tour.

Cette année, c’était avec une nouvelle conférence, un sujet qui me suit depuis longtemps et qui, je crois, m’habite un peu plus à chaque mission : Dev & Ops : des clients comme les autres ? Une question presque naïve sur le papier, et pourtant si rarement posée dans nos organisations. On parle beaucoup d’expérience utilisateur, on investit du temps, de l’énergie, des frameworks entiers pour mieux comprendre les besoins métiers… mais qu’en est-il de celles et ceux qui conçoivent, maintiennent, déploient, supportent ces solutions ?

En préparant ce talk, j’ai repensé à toutes ces discussions avec des équipes brillantes mais fatiguées, engagées mais parfois contraintes de naviguer dans des environnements qui ne sont pas pensés pour elles. J’ai repensé aux plateformes internes vécues comme des obligations plus que comme des produits, aux process subis plus qu’améliorés collectivement, aux irritants qu’on contourne faute d’espace pour les exprimer.

Sur scène, j’ai partagé ce mélange de convictions, de retours d’expérience et de pistes concrètes : Design Thinking pour mieux comprendre les besoins internes, Value Stream Mapping pour visualiser les frictions, Kaizen pour avancer pas à pas, Communication Non Violente pour remettre de la qualité dans nos interactions… autant de ponts possibles pour considérer enfin les Dev et les Ops comme des utilisateurs à part entière.

Et puis il y a eu les regards pendant la conférence. Les hochements de tête. Les sourires un peu entendus quand certaines situations faisaient écho. Les discussions juste après, celles où l’on sent que quelque chose résonne parce que l’on parle de vécu, pas seulement de théorie. Ces moments où l’on se dit que oui, ce sujet mérite sa place, qu’il touche quelque chose d’essentiel : la manière dont on prend soin de celles et ceux qui fabriquent nos systèmes.

Je suis sortie de cette session avec ce mélange très particulier d’émotion et d’énergie. Touchée par les retours, reconnaissante des échanges, et surtout pleine d’envies nouvelles pour continuer à créer des passerelles entre pratiques produit, culture d’amélioration continue et réalités du quotidien des équipes techniques.

Finalement, reprendre le circuit des conférences, ce n’était pas seulement revenir sur scène. C’était revenir avec une conviction encore plus forte : améliorer l’expérience Dev & Ops, ce n’est pas un luxe méthodologique, c’est une condition pour construire des organisations durables, humaines… et un peu plus agréables à vivre, chaque jour.

Spécial merci à Aurélie, Stéphane, Sofia, Sonia et Albane pour leur présence à cette première de ma nouvelle conf : votre soutien compte énormément, encore plus quand il s’agit de se lancer (ou se relancer) dans l’aventure du partage.

Pour me suivre sur les réseaux, ça se passe sur LinkedIn : fanny-klauk
Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 3 : Science, design, code : tout savoir sur le dark mode – Simon Mercier et Antoine Candy

Le dark mode… sujet presque philosophique tant il touche à nos habitudes, nos environnements de travail, notre fatigue visuelle… et nos préférences personnelles (team dark ici 🙋‍♀️).

Ce qui m’a frappée dès le début de la conférence, c’est le rappel historique : à l’origine, l’écriture verte sur fond noir était tout simplement… la solution la moins chère. Les premiers écrans reprenaient cette esthétique pour des raisons techniques plus que pour des raisons de confort visuel.

Puis arrive le skeuomorphisme : cette volonté d’imiter le monde physique dans les interfaces numériques. Le papier est clair, l’encre est sombre, donc nos interfaces deviennent noir sur fond blanc. C’est rassurant, familier, presque chaleureux. On parle d’affordance : l’objet numérique suggère son usage par analogie avec le réel.

Mais alors… lequel est le meilleur ?

Une étude comparative sur la lisibilité entre les deux modes montre que le light mode reste plus efficace pour repérer les fautes. Plusieurs variables entrent en jeu : taille de police, âge de la population testée… Mais dès que l’on change le contexte d’utilisation (par exemple dans un environnement peu lumineux) le dark mode reprend l’avantage.

Autre point intéressant : l’exposition prolongée à un thème clair pourrait augmenter le risque de myopie, tandis que certaines pathologies comme la cataracte rendent la lecture plus confortable en dark mode.

Conclusion intermédiaire assez forte : ne pas proposer de dark mode peut devenir une forme de discrimination.

Autre argument non négligeable : le dark mode consomme moins d’énergie (notamment sur écrans OLED). Et pour la lecture de code, les contrastes colorés sont souvent plus efficaces sur fond sombre (raison pour laquelle beaucoup d’IDE proposent un thème sombre par défaut.

Alors… comment choisir ?

Le thème de l’application ? pas forcément suffisant. L’environnement d’utilisation ? difficile à prévoir. Le profil utilisateur ? trop variable.

La réponse est finalement assez simple : proposer les deux modes, et laisser l’utilisateur choisir.

Simple sur le principe… mais pas si simple à implémenter.

Première idée naïve : inverser noir et blanc. Sauf que les autres couleurs ne suivent pas forcément, et les ombres utilisées pour créer de la profondeur deviennent incohérentes.

Une approche plus rigoureuse consiste à travailler la hiérarchie des surfaces : par exemple en jouant sur l’opacité d’un carré blanc sur fond noir. Résultat plus structuré… mais parfois un peu triste visuellement.

Les couleurs porteuses d’information doivent rester lisibles : idéalement plus claires en dark mode. Les outils de calcul de contraste sont indispensables pour respecter les normes WCAG AA avec un ratio supérieur à 4.5.

Petit tips design : arrêter de raisonner uniquement en Hexa ou RGB et privilégier le HSL (Hue Saturation Lightness), plus intuitif pour ajuster la luminosité sans casser l’harmonie globale. Figma propose d’ailleurs de bons outils pour travailler ces variations.

Autre subtilité : teinter légèrement les gris vers la couleur principale du thème ou vers sa couleur complémentaire permet d’éviter l’effet “gris neutre triste”.

Puis arrive la question du passage du design au code.

On pourrait penser qu’un simple tableau de correspondance de couleurs suffit. Mais attention aux noms ! Si le “white” du light mode devient deux couleurs différentes en dark mode… tout casse.

La solution : utiliser des design tokens comme source unique de vérité (single source of truth).

On retrouve ici des notions proches du design atomique :

• les atomes : éléments simples
• les molécules : assemblages plus complexes
• les particules : encore plus fin, équivalent aux variables (couleur, radius, typographie, espacements…)

Deux niveaux de référentiels apparaissent :

• primitives : ce que c’est (une couleur, une taille…)
• component-specific : où c’est utilisé

On parle alors de surfaces, primary, on-primary… mais surtout on ajoute une question essentielle : pourquoi cette valeur existe ?

Résultat : un système robuste, évolutif et scalable.

Côté code (exemple en React), même logique : si toute la gestion du thème se fait directement dans les composants, la moindre modification globale devient un enfer.

Alors que si le thème est correctement abstrait via des tokens… changer l’ambiance générale devient presque easy peasy.

Un rappel qui semble évident après coup : le dark mode n’est pas juste une inversion de couleurs, c’est un véritable système de design.

Et surtout… un choix qu’on devrait toujours laisser à l’utilisateur.

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 4 : Avatars, avatrices : cassons les codes ! – Fanny Lignon

La keynote de début d’après-midi par Fanny Lignon nous emmène dans un voyage critique au cœur de nos imaginaires vidéoludiques.

Premier constat : beaucoup de personnages masculins… et encore trop peu de personnages féminins. L’exemple qui ouvre la réflexion paraît presque anodin : Pacman et Miss Pacman. Une déclinaison féminine qui ne change finalement pas grand-chose au rôle initial… si ce n’est l’ajout d’un nœud et d’un rouge à lèvres.

On avance dans le temps avec Metroid : surprise, le héros est une héroïne ! Une révélation intéressante… jusqu’à découvrir que terminer le jeu en moins d’une heure permet de la voir apparaître en bikini. La femme comme récompense. Difficile de ne pas penser à Mario et Peach : sauver la princesse reste un classique. Oui mais… Peach est rarement jouable, excepté dans Super Princess Peach. Et encore : une arme principale réduite à un parapluie, et des pouvoirs basés sur ses émotions. Colère, joie, tristesse… difficile de ne pas y voir un stéréotype persistant.

Même lorsque Peach revient en 2024 avec Showtime, on retrouve une mise en scène très codifiée : costumes à endosser, rubans magiques, étoiles à gagner… La question posée est simple et efficace : quelle différence entre sauver le monde avec Mario et sauver un spectacle avec Peach ?

Conclusion intermédiaires : le jeu vidéo progresse… mais peut mieux faire.

Autre point abordé : la question du sexisme, qu’il soit hostile ou dit “bienveillant”. Dans GTA V par exemple, certains comportements sont présentés comme humoristiques ou anecdotiques… mais restent du sexisme.

Côté représentation visuelle, difficile de passer à côté des corps hypersexualisés : Chun-Li qui n’a pas droit à un kimono, Lara Croft dont le look et les cris dans l’effort ont longtemps été caricaturaux. Cas particulier avec Bayonetta : ici, la performance du féminin est poussée à l’extrême, presque comme une mise en scène consciente du stéréotype.

Mais les stéréotypes ne concernent pas que les femmes. Du côté masculin, on retrouve une masculinité très militarisée, sur-musclée, souvent peu expressive émotionnellement.

Depuis une dizaine d’années pourtant, les choses évoluent. Kratos (God of War) apprend à verbaliser ses émotions (oui, vraiment). Ellie (The Last of Us) ou Maxine proposent des personnages féminins aux corps plus réalistes, vêtues simplement, avec une profondeur psychologique plus riche.

Tout n’est pas encore parfait : Stellar Blade a par exemple fait parler de lui pour un personnage dont le corps a été modélisé directement à partir d’une mannequin. Mais certaines réussites existent, comme Horizon et son héroïne crédible, compétente, complexe.

Quid de la représentation LGBTQ+ ? Elle reste encore rare, souvent cantonnée à des personnages secondaires caricaturaux voire antagonistes. Des jeux comme Les Sims permettent cependant d’incarner des identités variées. Dans The Last of Us Part II, Ellie est homosexuelle sans que cela soit un choix optionnel. Tell Me Why propose quant à lui un personnage transgenre jouable, ce qui reste encore trop rare.

La question finale posée par Fanny Lignon ouvre des perspectives intéressantes : comment faire autrement ?

Pourquoi ne pas choisir au début du jeu qui se fait enlever… et qui part sauver l’autre ? Pourquoi ne pas déplacer le regard, comme le propose l’artiste Woman in Games avec le projet Gender Swap ?

Et surtout : à quand une héroïne d’âge mûr, non blanche, enrobée… bref, différente des standards actuels ?

Un sujet qui dépasse largement le jeu vidéo : il s’agit d’ouvrir les imaginaires, de proposer plus de diversité, et donc plus de tolérance.

Une keynote qui pousse à regarder autrement les personnages que l’on incarne… et ceux que l’on ne voit pas encore.

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 5 : Comprendre Kubernetes de manière visuelle – Aurélie Vache

Quand on parle de Kubernetes, il y a souvent deux réactions : soit on hoche la tête d’un air entendu (oui oui bien sûr, les pods, les nodes, tout ça…), soit on ressent une légère crispation intérieure à l’idée d’essayer de comprendre comment tout cela fonctionne réellement.

Bonne nouvelle : Kubernetes peut s’expliquer simplement. Encore mieux : il peut s’expliquer visuellement.

C’est justement tout l’objectif de la conférence proposée par Aurélie Vache, que j’avais déjà eu l’occasion de voir par le passé… et qui a su évoluer avec de nouvelles mises à jour toujours aussi pédagogiques.

Tout commence en 2020, pendant le confinement. Une question simple : comment représenter un pod pour le rendre compréhensible ? Réponse : une Pokéball. Et honnêtement… difficile de faire plus parlant.

Ce qui rend la démarche particulièrement efficace, c’est qu’elle ne se limite pas à une seule manière d’apprendre. Sketchnotes, vidéos, livre… chacun peut choisir le format qui lui correspond le mieux pour s’approprier les concepts.

Kubernetes est présenté comme un chef d’orchestre. Il ne joue pas de musique lui-même, mais il coordonne l’ensemble des instruments pour produire quelque chose d’harmonieux. Ici, les instruments sont les ressources : machines, conteneurs, services…

Et les partitions ? Ce sont les fichiers YAML (oui, ceux qui nous donnent parfois envie de vérifier deux fois l’indentation).

On avance pas à pas dans les concepts :

• le node, la machine qui héberge
• le pod, plus petite unité déployable
• le deployment, pour gérer la réplication
• les replica sets, pour maintenir l’état souhaité
• les selectors, pour relier les bons éléments entre eux

Puis on découvre progressivement ce qui se passe en coulisses :

• API Server, le point d’entrée
• Scheduler, qui décide où lancer les pods
• Kubelet, qui s’assure que tout tourne correctement
• les services, pour exposer les applications
• les notions de liveness et readiness, pour savoir si tout fonctionne vraiment (et pas juste “ça a l’air d’aller”)
• les namespaces pour organiser
• les resource quotas pour éviter qu’un projet ne monopolise tout
• les jobs et cronjobs pour automatiser
• les configmaps et les secrets… qui ne sont pas si secrets que ça 😅

Le parcours est progressif, visuel, et rend l’univers Kubernetes beaucoup moins intimidant qu’il peut l’être au premier abord. On comprend mieux comment les différentes briques interagissent et surtout comment éviter certains pièges classiques lorsqu’on commence.

Petit clin d’œil également à des outils de l’écosystème comme Rancher ou Pulumi, qui viennent compléter l’expérience.

On ressort de cette conférence avec une vision d’ensemble claire des concepts clés, et surtout avec la sensation que Kubernetes est finalement accsesible… à condition d’avoir les bonnes métaphores.

Merci Aurélie pour cette mise à jour toujours aussi efficace 🙏

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 6 : Le FastPass vers la prod : construire une plateforme qui libère les équipes, pas qui les contraint – Jérémy Planckeel et Fabien Verdier

Voilà un talk qui me parle particulièrement, moi qui ai parlé de frictions quotidiennes dans l’expérience des devs et ops.

Jérémy et Fabien nous proposent un retour d’expérience chez Energypool qui part d’une situation assez classique : quelques applications (6 au départ), une vision globale maîtrisée… puis l’accélération. Objectif : livrer 50 applications par an. Et là, les limites du modèle historique apparaissent très vite.

Le fonctionnement initial ressemble probablement à beaucoup d’organisations : les développeurs modifient un monolithe, un release manager fige une version, puis viennent les phases de tests en préprod avant le passage en production. Sur le papier, ça semble structuré. Dans la réalité : des délais longs, des dépendances multiples entre équipes, et surtout… des retours en arrière complexes et coûteux.

Le fameux time to market qui s’étire dangereusement.

L’enjeu devient alors évident : modulariser (moduler ?) l’existant pour accélérer les livraisons.

Ce qui m’a marquée dans ce retour d’expérience, c’est la bascule vers une autonomie forte des équipes. Aujourd’hui, chaque équipe est responsable de ses releases, via un tracker partagé. Le rôle de release manager évolue : il ne disparaît pas complètement, mais se transforme pour continuer à observer les déploiements et assurer une cohérence globale.

Plus personne ne bloque la livraison d’une autre équipe. Et ça change tout.

Pour accompagner ce mouvement, la plateforme apporte un cadre commun :

des pratiques harmonisées et documentées un catalogue de workflows standards l’observabilité et la sécurité intégrées directement dans les applications déployées (notamment via Grafana) Résultat : une application peut passer en production en moins d’une semaine.

Le gain en fluidité est assez impressionnant : les équipes sont autonomes les délais de livraison sont réduits les équipes livrent quand elles en ont besoin (et pas quand le train de release passe)

Mais évidemment, ce type de transformation ne se fait pas d’un claquement de doigts.

Parmi les étapes clés : le recrutement d’experts Kubernetes l’abandon de Jenkins au profit de GitHub Actions la mise en place d’un tracker pour déclarer les mises en production et surtout la définition d’un golden path commun (Python, Java, Spring…) Aujourd’hui, la majorité des applications tourne sur Kubernetes.

Et c’est probablement là l’un des points les plus intéressants du talk : la technologie n’est pas la partie la plus difficile.

Le véritable enjeu, c’est l’accompagnement au changement.

Nouvelle organisation, nouveaux outils, nouvelles responsabilités… Kubernetes, par exemple, bouleverse certaines habitudes très ancrées (comme le fait de se connecter en SSH sur une instance pour “voir ce qu’il se passe”).

Pour faciliter cette transition : mise en place d’un environnement de formation et de test création d’une communauté de pratiques pour partager les retours d’expérience et surtout une équipe dédiée à la plateforme… au service des développeurs

J’ai particulièrement aimé l’idée que la plateforme ne doit pas contraindre, mais libérer. Et pour cela, il faut observer en continu l’expérience développeur pour affiner le fameux golden path.

Comment mesurer les gains ? Grâce aux métriques DORA, qui permettent d’objectiver l’amélioration de la performance des équipes (fréquence de déploiement, lead time, taux d’échec…).

Et la suite ? Encore plus d’automatisation, notamment autour de Terraform.

Un talk très concret, qui rappelle qu’une plateforme interne réussie n’est pas seulement une stack technique… c’est un produit, pensé pour ses utilisateurs : les développeurs.

Et finalement, la question clé reste simple : est-ce que votre plateforme accélère vos équipes… ou est-ce qu’elle les ralentit ?

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 7 : L’indépendance des médias… indés – David Dufresne

Comment résumer une keynote pour laquelle on n’a quasiment pas pris de notes ? Peut-être parce que, justement, il fallait surtout écouter. Ou plutôt accepter de se laisser emmener dans un récit qui ne suivait pas vraiment le chemin attendu d’une keynote “classique”.

David Dufresne ne déroule pas un plan en trois parties bien structurées avec takeaways bien rangés dans un coin de slide. Il raconte. Il tangente. Il bifurque. Il revient en arrière. Il partage des fragment d’histoire personnelle, de journalisme, de combats, de doutes aussi.

Et finalement, le propos s’installe presque malgré lui : que devient l’information quand ceux qui possèdent les médias possèdent aussi une partie du débat public ?

Le pitch annonçait la couleur : brutalisation des débats, concentration des médias dans les mains de quelques milliardaires, nécessité d’organiser la riposte.

Rien que ça.

Le cas d’école présenté : Au Poste, média indépendant créé il y a cinq ans pour “mettre un peu de trouble dans l’ordre médiatique dominant” (merci Jacques Rancière pour la punchline). Une formule qui résume assez bien l’intention : déplacer légèrement le centre de gravité, faire exister d’autres récits, créer des espaces où la parole peut prendre plus de temps que celui d’un plateau télé minuté.

Ce qui frappe dans cette keynote, c’est la multiplicité des formats évoqués : du journalisme “traditionnel” au live Twitch, en passant par des moments presque performatifs (on retiendra notamment cette histoire de contrat déchiré en direct dans l’émission C ce soir). On est loin de la posture neutre et distanciée qu’on associe parfois au journalisme.

Ici, l’engagement est visible.

Et quelque part, ça fait écho à beaucoup d’autres sujets abordés pendant la conférence : reprendre du contrôle, questionner les systèmes dominants, expérimenter d’autres manières de faire.

Créer un média indépendant aujourd’hui ne consiste pas seulement à publier du contenu. C’est aussi interroger :

• qui finance ?
• qui décide ?
• qui parle ?
• qui est entendu ?
• et dans quelles conditions ?

La promesse d’Internet était celle d’une démocratisation de la parole. Dans les faits, les plateformes ont aussi recréé des logiques de concentration, d’algorithmes, de mise en avant de certains discours plutôt que d’autres.

Alors comment exister sans devenir soi-même dépendant d’un système qui pousse à produire toujours plus, toujours plus vite, toujours plus clivant ?

Une des pistes évoquées par Dufresne : accepter la lenteur, la conversation longue, l’exploration. Le live devient alors un espace de respiration, un moment où la pensée peut se construire sans être immédiatement réduite à un extrait de 30 secondes partageable sur les réseaux.

Cela demande une forme de courage éditorial… et une certaine prise de risque.

Car l’indépendance a un coût : économique, bien sûr, mais aussi en visibilité, en confort, en stabilité.

Au fond, cette keynote n’apportait pas tant des réponses que des invitations à réfléchir :

quelle place souhaitons-nous laisser aux médias indépendants ? sommes-nous prêts à les soutenir ? quel rôle pouvons-nous jouer, individuellement, dans la diversité des voix ?

Pas de call-to-action tonitruant pour conclure, mais plutôt une sensation diffuse : celle que l’écosystème médiatique, comme l’écosystème tech, gagne à rester pluraliste, imparfait, parfois chaotique… mais vivant.

Et peut-être que “mettre un peu de trouble” est finalement une condition nécessaire pour éviter que tout ne devienne trop prévisible.

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 8 : Wikipédia a 25 ans : de l’utopie numérique au pilier du savoir commun – Rémy Gerbet

Deuxième journée, keynote d’ouverture. Le genre de moment où l’on se pose encore avec son café à la main, l’esprit un peu embué par les échanges de la veille, mais déjà prêt à replonger. Et quel meilleur sujet pour démarrer que Wikipédia ? Un objet du quotidien tellement banal… qu’on en oublierait presque à quel point il est extraordinaire.

Rémy Gerbet nous rappelle d’abord que derrière Wikipédia, il y a tout un écosystème : Wikimedia France, association créée en 2004 pour soutenir non seulement l’encyclopédie libre, mais aussi de nombreux projets de partage de la connaissance. Parce que Wikipédia n’est pas “juste un site”, c’est une infrastructure du savoir commun.

Consulter, modifier, contribuer. Trois verbes simples qui résument une philosophie entière.

Petit vertige de chiffres :

• 200 millions de pages, toutes langues confondues
• 24 milliards de pages vues par mois
• 10ème site le plus consulté en France… et probablement le premier avec un objectif non commercial

Quand on y pense, c’est assez fou : un projet collaboratif, ouvert, maintenu par des bénévoles, qui rivalise avec les géants du web.

Retour rapide dans le temps : le premier wiki apparaît en 1995. Wikipédia, elle, naît le 15 janvier 2001 en anglais, rapidement suivie par l’allemand, le catalan puis le français. Le .org arrive en 2002, marquant déjà une volonté d’inscrire le projet dans une logique d’intérêt général.

Ce qui frappe toujours avec Wikipédia, c’est la diversité de ce qu’on peut y trouver. Des articles extrêmement pointus, d’autres plus légers, parfois surprenants… et les débats éternels : faut-il dire chicon ou endive ? quelle est la véritable composition de la pantoufle de Cendrillon ? Oui, même les sujets les plus inattendus trouvent leur place.

Petit moment suspendu avec “Listen to Wikipedia”, cette expérience qui transforme les contributions en une symphonie sonore. Chaque modification devient une note. Une manière presque poétique de matérialiser l’activité constante de la communauté.

Car oui, derrière l’apparente fluidité, il y a une organisation très structurée. Les administrateurs sont reconnus par leurs pairs pour leur travail de validation et de correction. Un système de confiance progressive, où la légitimité se construit par la contribution.

Mais l’équilibre reste fragile.

L’arrivée massive de l’IA pose de nouvelles questions. Les contenus de Wikipédia sont largement utilisés pour entraîner les modèles… sans que Wikipédia soit toujours citée en retour. À terme, cela pourrait signifier : moins de visites, moins de contributeurs, moins de financements, et donc potentiellement moins de qualité.

Autre sujet sensible : les contributions générées par IA. Certaines versions linguistiques, comme Wikipédia anglophone, sont très strictes sur le sujet. La version française semble un peu plus ouverte, à condition que le travail de vérification humaine reste présent. Mais une vraie question se pose : avons-nous les moyens de relire des pages générées en quelques secondes ?

Le combat principal reste pourtant inchangé : lutter contre la désinformation et les tentatives de manipulation.

Le nombre de contributeurs actifs baisse légèrement mais régulièrement. Beaucoup participent désormais via de petites contributions : correction de fautes, micro-modifications… un soutien précieux qui soulage les contributeurs les plus investis dans la modération.

Contribuer, c’est aussi s’exposer. Pressions, désaccords, tensions… Wikimedia propose même un soutien psychologique pour accompagner certains contributeurs. Un aspect auquel on ne pense pas forcément lorsqu’on clique sur “modifier”.

Et pour célébrer les 25 ans de Wikipédia, Wikimania se tiendra à Paris. Une belle occasion de rappeler que derrière chaque article se cache une communauté bien réelle.

Ce que je retiens de cette keynote : Wikipédia n’est pas seulement un site que l’on consulte par réflexe. C’est un commun numérique fragile, qui repose sur un équilibre subtil entre technologie, engagement bénévole et confiance collective.

Et peut-être que la meilleure façon de remercier Wikipédia… c’est encore d’y contribuer !

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 9 : Il était une fois le code : du Clean Code au Narrative Code – Sandrine Banas

Petite joie personnelle en arrivant à cette conférence : Sandrine Banas est une collègue CGI ! Et comme souvent dans ce genre d’événement, on se dit qu’on va assister à une présentation technique… pour finalement en ressortir avec une réflexion presque philosophique sur notre manière d’écrire du code.

Pendant longtemps, nous avons combattu le code spaghetti : des architectures difficilement lisibles, des responsabilités mal définies, des méthodes interminables… puis est arrivé 2008 et la parution de Clean Code de Bob Martin. Une révolution pour toute une génération de développeurs : nommage explicite, responsabilité unique, abstraction, interfaces… bref, une volonté de rendre le code lisible, maintenable, presque élégant.

Mais depuis… notre écosystème a énormément évolué : microservices, IoT, cloud, serverless, conteneurisation, green IT… et avec ces évolutions, une question apparaît : et si le Clean Code n’était plus toujours suffisant ?

Car appliqué de manière trop dogmatique, il peut aussi amener ses propres travers :

• multiplication des abstractions
• fragmentation excessive du code
• augmentation de la charge cognitive
• impact potentiel sur les performances (overhead mémoire, CPU…)
• exemples parfois datés par rapport aux langages modernes

Certains patterns historiques peuvent aujourd’hui être remplacés par des fonctionnalités natives de langages récents (par exemple le pattern matching en Java plutôt que certaines implémentations du Strategy pattern).

L’idée n’est pas de jeter Clean Code aux oubliettes, mais plutôt de comprendre qu’il est né dans un contexte technique donné… qui a évolué depuis.

L’un des moments marquants de la conférence repose sur ce rappel simple mais puissant : nos abstractions existent avant tout pour nous, humains.

Nous n’écrivons pas naturellement en 0 et 1. Nous traduisons. Nous racontons. Nous structurons.

Autrement dit : nous écrivons déjà des histoires… sans toujours en avoir conscience.

Sandrine fait alors référence à Christopher Booker, qui explique que toutes les histoires de la littérature peuvent se résumer à seulement 7 grands récits universels.

Et dans le code ?

Dans l’écosystème Java, elle observe que de nombreux projets reposent en réalité sur quelques types d’histoires récurrentes :

• archivage : stockage de données, exposition via API REST
• transformation : calculs métier, enrichissement de données
• protection : sécurité, validation, règles d’accès
• nettoyage : logs, purge, droit à l’oubli
• delivering : exposition vers l’extérieur, communication entre systèmes

Une fois ce prisme narratif adopté, le code devient plus lisible… presque plus naturel.

Comme un livre agréable à lire dépend de sa typographie, de sa structure, de ses chapitres, notre code bénéficie lui aussi :

• d’un nommage cohérent
• d’un formatage lisible
• d’une organisation logique des packages
• d’une documentation utile
• d’une gestion claire des erreurs

Sandrine part d’un exemple de code legacy Java difficile à lire et introduit la notion de chunk : une unité cognitive de compréhension et de mémorisation du développeur et de la développeuse.

Notre cerveau retient plus facilement des ensembles cohérents que des suites d’instructions isolées.

Simplifier et regrouper permet donc :

• de mieux comprendre
• de mieux mémoriser
• d’identifier plus rapidement les incohérences
• de repérer plus facilement les bugs

Elle propose plusieurs niveaux de granularité, inspirés de la narration : actions, scènes, chapitres, table des matières… auxquels on peut associer tantôt instructions, tantôt méthodes ou classes, packages…

Un point intéressant : au-delà de 7 chunks dans une méthode, on commence à oublier les premiers. Le découpage devient alors essentiel.

Les critères de découpage proposés :

• longueur (éviter les méthodes interminables)
• responsabilité (une étape claire de l’histoire)
• simplicité

Autre analogie parlante : les variables deviennent les personnages de notre récit.

Trop de personnages ? l’histoire devient confuse. Personnages en double ? duplication inutile. Personnages sans rôle clair ? charge cognitive inutile.

On évite donc les variables superflues, et on veille à ce que chaque élément porte une responsabilité claire dans la “scène” où il intervient.

Mention spéciale pour la métaphore dramatique : on tue les personnages en trop 😱

Alors Clean Code vs Narrative Code : opposition ou complément ? Le message final est nuancé : le Narrative Code ne remplace pas Clean Code.

Le Clean Code sert la technique. Le Narrative Code sert la compréhension humaine.

Et surtout : il ne s’agit pas d’appliquer ces principes partout sans réfléchir.

Le contexte reste roi.

Mais cette approche apporte un angle intéressant : écrire du code, ce n’est pas seulement structurer de la logique… c’est transmettre une histoire à la prochaine personne qui devra la lire.

Et cette personne… c’est souvent nous-mêmes quelques mois plus tard.

Une conférence qui fait prendre du recul sur nos pratiques quotidiennes et qui rappelle que derrière chaque ligne de code, il y a une intention de communication.

Et finalement… quoi de plus humain que de raconter des histoires ?

(Sandrine a également écrit un livre sur le sujet — je note de creuser !)

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 10 : Le futur du développeur : IA, compétences et obsolescence ? – Estéban Soubiran & Julie Mouveroux

Salle comble. Littéralement. Le genre de salle où l’on sent immédiatement que le sujet touche quelque chose de profond. Peut-être même un peu sensible.

Parce que oui, parler du futur du développeur à l’ère de l’IA, c’est forcément venir titiller quelques inquiétudes. Et probablement encore plus chez celles et ceux qui viennent tout juste de terminer leurs études et qui ont choisi cette voie avec enthousiasme… et quelques projections d’avenir.

Le point de départ posé par Estéban est volontairement radical : et si, à titre personnel comme professionnel, on cherchait à ne plus écrire une seule ligne de code ? Jusqu’où peut-on pousser l’expérience ? Peut-on vraiment être remplacé ?

Question provocatrice… mais qui a le mérite de forcer la réflexion.

Pour comprendre ce qui change, encore faut-il revenir à la définition même du métier de développeur : résoudre des problèmes complexes à l’aide d’outils et de logiciels.

Or, aujourd’hui, l’IA sait déjà faire une partie de cela. Elle produit du code vite, parfois très vite. Beaucoup plus vite que ce que nous sommes capables d’absorber.

Mais à condition que… la spécification soit claire, que le contexte soit précis, que les critères d’évaluation soient définis, que la cohérence d’ensemble soit maintenue, que quelqu’un prenne la responsabilité finale. Bref : que le travail de réflexion soit bien fait en amont et en aval.

Le code devient moins cher à produire, mais la compréhension, elle, ne s’accélère pas au même rythme.

Un concept m’a particulièrement marquée : après la dette technique… voici la dette cognitive.

En accélérant la production, on réduit le temps passé sur beaucoup d’indicateurs traditionnels. Mais ce temps “gagné” se paie ailleurs : dans la compréhension du système, dans la capacité à maintenir, dans la qualité des décisions prises.

On déplace simplement le goulet d’étranglement.

Moins sur la capacité à écrire du code. Plus sur la revue, la QA, la qualité des tickets, les arbitrages produit, la capacité des équipes à absorber ce flux.

L’IA accélère. Partout. Et les endroits où cela coinçait déjà… coincent encore plus vite.

Autre point intéressant : le fameux vibe coding.

Parce que c’est facile. Parce que c’est rapide. Parce qu’on a l’impression de produire immédiatement quelque chose de tangible.

Mais avec un coût potentiel élevé : bugs, failles, incohérences… et parfois une illusion de maîtrise.

Car si l’on ne produit plus soi-même, comment continue-t-on à apprendre ? Comment développe-t-on son intuition technique ? Comment évalue-t-on la pertinence de ce qui est généré ?

L’IA produit plus vite que nous ne comprenons.

Et cela pose aussi une question très concrète : comment fait-on monter en compétence les juniors si toutes les premières tâches sont confiées à l’IA ?

Ces tâches qui, historiquement, servaient de terrain d’apprentissage. Ces petits problèmes qui permettent de construire progressivement une vision d’ensemble.

Déléguer sans discernement reviendrait à donner du pouvoir d’action sans capacité d’analyse.

Or, ce discernement reste profondément humain.

Pouvoir expérimenter. Tester. Comprendre pourquoi cela fonctionne… ou pas. Garder un esprit critique. Être capable de dire “cela ne me semble pas cohérent”.

Une idée évoquée que j’ai beaucoup aimée : la vigilance émerveillée vis-à-vis de l’IA.

Continuer à s’émerveiller des possibilités… tout en restant vigilant sur la compréhension.

Parce que nous n’avons pas tous le même besoin ni le même niveau d’usage : entre utilisation ponctuelle et intégration complète dans son quotidien, il existe tout un spectre.

Le point de repère proposé : revenir régulièrement à la question “et si c’était moi qui devais le faire ?”

Non pas pour tout refaire manuellement. Mais pour s’assurer que l’on conserve la capacité de comprendre, décider et arbitrer.

Finalement, cette conférence ne répond pas vraiment à la question “le développeur va-t-il disparaître ?”.

Elle invite plutôt à se demander : quelle part de notre métier voulons-nous déléguer… et laquelle souhaitons-nous continuer à cultiver ?

Merci Estéban et merci Julie de loin 🙏

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 11 : Déployer souvent, stresser moins : feature flags en prod critique – Marion Chineaud et Elise Souvannavong

On a tous déjà fait ça : attendre que “tout soit prêt” avant de merger. Un peu comme attendre d’avoir écrit tout un chapitre avant d’oser relire la première phrase… sauf que côté code, plus on attend, plus on accumule du risque.

Le constat posé par Marion et Elise est assez simple : le merge rare est un faux ami. Plus la branche vit longtemps, plus elle diverge, plus le moment du merge devient stressant. Et quand on travaille à plusieurs, ça devient même une petite course : vite, je merge avant d’avoir à rebase.

On se retrouve alors avec des features énormes, difficiles à relire, diffficiles à tester… et difficiles à rollback.

Leur proposition : changer de logique.

Passer d’un développement par grosses fonctionnalités à une approche par petites itérations, avec du trunk-based development. L’idée est presque contre-intuitive au départ : tout ce qui est mergé part en prod.

Oui oui.

Mais pas forcément activé.

Et c’est là qu’entrent en scène les feature flags.

Un feature flag, c’est un interrupteur dans le code. On déploie la fonctionnalité en production… mais on décide plus tard si elle doit être visible ou active.

Ce découplage change complètement la manière d’appréhender le delivery :

• on peut merger plus souvent
• on réduit le stress lié au déploiement
• on peut rollback sans redéployer
• on découpe mieux les sujets
• on estime plus facilement

Bref, on reprend un peu de contrôle sur le chaos ambiant.

Techniquement, la mise en place peut être très simple :

un flag défini dans la configuration (par exemple dans un fichier yaml), injecté dans l’application via un bean… puis un simple if dans le code.

Pour séparer proprement la configuration du code, on peut passer par une approche GitOps et livrer la configuration comme du code, par exemple via ArgoCD.

Spring Cloud permet aussi de rafraîchir la configuration dynamiquement via proxy… même si attention, tous les cycles de vie ne sont pas compatibles (certains crons notamment).

Et si une action manuelle est nécessaire (un POST pour rafraîchir la config par exemple), Argo peut aussi l’automatiser.

En pratique, plusieurs stratégies existent pour activer ou désactiver un flag :

• via une Pull Request sur la configuration
• via une interface d’administration (dev toggles)
• via un endpoint exposant l’état des flags

L’important est d’éviter qu’un déploiement nécessite forcément la présence d’un développeur.

Un bon flag, c’est un flag pilotable.

Tous les flags ne servent pas le même objectif.

Release flags Ce sont les plus courants. Ils permettent aux développeurs de merger souvent, tout en gardant la possibilité d’activer la feature plus tard.

Ops flags Ils permettent d’adapter dynamiquement le comportement de l’application en fonction de la charge ou de dépendances externes incertaines. Typiquement : activer une fonctionnalité seulement si le volume de données reste acceptable.

Experiment flags (A/B testing) Lorsqu’on hésite entre deux solutions métier, plutôt que de choisir arbitrairement… on teste sur une partie de la population. Encore faut-il monitorer correctement pour savoir quelle option fonctionne le mieux.

Un conseil donné pendant le talk : éviter de multiplier les variantes en parallèle. Sinon, bon courage pour interpréter les résultats.

Shadow mode Particulièrement utile sur des domaines critiques ou à forte tolérance zéro erreur.

On fait tourner deux versions en parallèle et on compare les résultats avant de basculer définitivement. Très pratique pour des calculs backend… beaucoup moins pour de l’interface.

Inconvénient : un coût doublé temporairement et une complexité supplémentaire à maintenir.

Canary release Quand on touche à quelque chose de très critique (refonte d’infra + refonte fonctionnelle par exemple), on peut déployer progressivement :

1. les beta testeurs
2. la majorité des utilisateurs
3. les clients sensibles ou importants

Une montée en charge progressive, contrôlée… et rassurante.

Le piège : la dette technique des flags Parce que oui, il y a un revers à la médaille : les flags s’accumulent.

Et lorsque plusieurs flags interagissent entre eux, la complexité explose rapidement. Le nombre de cas de test augmente de manière exponentielle… et le code devient difficile à lire.

Tous les flags n’ont pas vocation à rester :

• les release flags doivent disparaître une fois la feature validée
• les experiment flags aussi
• seuls les ops flags sont destinés à rester dans la durée

Le conseil simple mais efficace : créer un ticket de nettoyage dès la création du flag. Et commenter le code.

Oui, vraiment.

En résumé, les feature flags ne sont pas juste un outil technique. Ils changent la manière de collaborer, d’estimer, de livrer et de gérer le risque.

Ils permettent de :

• réduire la taille des changements
• diminuer le stress lié au déploiement
• faciliter les rollback
• expérimenter plus sereinement
• mieux maîtriser l’impact en production

Mais comme souvent en ingénierie : plus de flexibilité implique plus de discipline.

Sinon, on remplace le stress du merge… par le stress du cleanup.

Un grand merci à Marion et Elise pour ce talk très concret, directement applicable, et qui donne envie de revoir sa stratégie de livraison dès lundi matin 🙏

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 12 : Pas de managers, pas de réunions, pas de problèmes ? – Sofia Lescano Carroll

On a toutes et tous connu ces journées hachées menu : des réunions qui s’enchaînent, parfois utiles, parfois beaucoup moins… avec cette impression persistante de ne pas avoir eu une minute pour réellement avancer.

La conférence de Sofia Lescano Carroll (Alan) part justement de ce constat simple : trop de réunions tue la décision… et parfois même la responsabilité.

Chez Alan, cela fait maintenant une dizaine d’années qu’un modèle organisationnel assez radical s’est installé autour de trois piliers très concrets : confiance, transparence et responsabilité. Dit comme ça, cela peut paraître presque banal. Mais la mise en pratique, elle, l’est beaucoup moins.

Premier point qui interpelle : tout passe par l’écrit et l’asynchrone. Pas de discussions en aparté dans un coin de Slack, pas de décisions prises à la machine à café qui ne seraient connues que de quelques personnes. Même un café informel se fait dans un channel dédié (#coffee). L’idée ? Si l’information est un pouvoir, autant la partager largement.

Autre élément assez marquant : une transparence radicale. Les salaires sont communiqués en interne… et même en externe. L’objectif n’est pas la provocation, mais l’alignement : limiter les biais, faciliter la compréhension des trajectoires et rendre les décisions lisibles.

Mais alors, sans managers, comment ça fonctionne ?

Sofia nous rappelle les responsabilités classiques d’un manager :

• accompagner les personnes (trajectoire RH, santé psychologique, feedback)
• assurer le delivery produit
• améliorer les process et gérer les situations de crise

Chez Alan, ces responsabilités ne disparaissent pas… elles sont réparties.

Un Alaner (nom donné aux collaborateurs) évolue ainsi dans un environnement composé de plusieurs rôles complémentaires :

• un crew lead pour le delivery
• un coach pour le développement personnel
• les autres Alaners pour la performance collective

Et ces rôles ne sont pas figés : n’importe qui peut devenir crew lead ponctuellement. Même logique côté coach, qui n’est pas un supérieur hiérarchique mais une personne choisie, avec laquelle la relation peut évoluer.

Un rôle supplémentaire existe : le Deputee, qui coordonne plusieurs crews et peut prendre certaines décisions RH.

Ce qui change vraiment, c’est la distribution de la capacité de décision.

Chaque Alaner dispose des éléments nécessaires pour contribuer, challenger et décider. Tout n’est évidemment pas lu par tout le monde : chacun s’abonne aux sujets qui le concernent pour pouvoir faire un point hebdomadaire sur ce qui a fonctionné… ou moins bien fonctionné… et adapter son propre plan d’action.

Une synthèse globale est ensuite partagée à l’échelle de l’entreprise, dans un format court (15 minutes), pour conserver une vision d’ensemble sans retomber dans l’effet tunnel des réunions à rallonge.

Résultat : très peu de meetings récurrents :

• un point d’équipe de 30 minutes
• un 1to1 avec son coach

Le reste des interactions se fait de manière ciblée : pair-programming, échanges sociaux (#café), discussions écrites pour favoriser l’apprentissage collectif.

Un principe revient souvent dans la conférence :

“Si ce n’est pas écrit, ce n’est pas décidé.”

L’écrit devient un outil d’alignement, mais aussi de mémoire collective. Et dans un environnement remote, inclusif et fortement documenté, cela facilite également la recherche d’information… y compris avec l’aide de l’IA.

Côté prise de décision, la logique est assez pragmatique : plus une décision est réversible et à impact limité, plus elle peut être prise rapidement et individuellement. Si l’impact est plus important, on sollicite des avis… mais la responsabilité finale reste à la personne qui a initié la discussion (via GitHub par exemple).

Tout n’est pas parfait pour autant.

Ce modèle n’est clairement pas fait pour tout le monde :

• l’onboarding peut être déroutant
• la quantité de documentation peut donner l’impression de se perdre
• savoir donner et recevoir du feedback devient une compétence clé
• l’autonomie demande de la maturité

Mais les enseignements que l’on peut en tirer sont nombreux, même sans adopter le modèle tel quel :

Quelques takeaways que je retiens :

• écrire immédiatement permet souvent… de trouver la solution soi-même
• partager l’information permet d’aligner plus vite
• dissocier développement personnel et position hiérarchique ouvre de nouvelles perspectives
• la confiance accordée aux collaborateurs est souvent à la hauteur de la responsabilité qu’on leur donne

Finalement, pas de managers, pas de réunions, pas de problèmes ?

Probablement pas. Mais peut-être moins… et surtout autrement.

Lien vers les slides - à venir
Lien vers la vidéo - à venir

Chapitre 13 : place à Mixteen

Dernier temps fort de cette seconde journée pour moi, car le train vers Tours m’attend…

La grande scène accueille Mixteen, un moment toujours à part dans la conférence. Ici, pas de keynote sponsorisée ni de live coding ultra pointu, mais des jeunes – enfants comme adolescents – venus partager leurs premières expériences de programmation.

Le principe est simple : donner l’opportunité à des jeunes de découvrir le code autrement que par un simple exercice scolaire. Ils expérimentent, créent, testent… et surtout prennent plaisir à voir leurs idées prendre vie. Jeux, animations, petits programmes : les projets présentés témoignent d’une vraie curiosité et d’une belle créativité.

Ce qui frappe, c’est la diversité des approches. Certains ont découvert Scratch, d’autres ont déjà mis les mains dans des langages plus “classiques”. Derrière ces réalisations parfois simples se cache un vrai travail d’apprentissage : comprendre la logique, structurer sa pensée, tester, se tromper, recommencer.

L’exercice de présentation sur la scène du grand amphithéâtre n’est pas anodin. Monter sur scène devant plusieurs centaines de personnes demande une bonne dose de courage, quel que soit l’âge. Et pourtant, toutes et tous se sont prêtés au jeu avec enthousiasme, expliquant leur démarche, leurs idées et parfois même leurs difficultés.

Mixteen rappelle que la tech n’est pas qu’une affaire d’experts. Donner accès au code dès le plus jeune âge, c’est ouvrir des portes : celles de la compréhension du monde numérique, mais aussi celles de la création.

Un très beau moment, inspirant et rafraîchissant, qui montre que la relève est déjà là. Et qu’elle a visiblement pris beaucoup de plaisir à coder… ce qui est probablement le plus important.

Clap de fin… et quel plaisir !

Le moins que l’on puisse dire, c’est que cette édition de MiXiT a tenu toutes ses promesses ❤️ Des échanges riches, des découvertes, des rencontres, des retrouvailles… et ce sentiment toujours aussi particulier de faire partie d’une communauté profondément humaine et inspirante.

Un immense merci à toute l’équipe d’organisation qui a fait un travail absolument formidable. Que l’on soit speaker ou attendee, on se sent accompagné, encouragé, soutenu, bichonné même… et cela fait toute la différence. Deux jours intensses, fluides, riches en découvertes et en partages : derrière cette apparente simplicité se cache une quantité impressionnante de travail, d’attention et de passion.

Ravie d’avoir pu (re-)croiser les chemins et les discussions de Stef, Ambre (ou Alexandre ?!), Titimoby, Sonia, José, Hubert, Ane, Aurélie, Sandrine, Sofia, Nicolas, Charline, Thibaut, Nathan, Albane, Simon et Antoine… et même Rémi qui était là en pensée grâce aux slides d’Aurélie 😉

Et bien sûr, merci à toutes celles et ceux que j’ai croisé au détour d’un couloir, d’un café, d’un déjeuner ou d’un talk. Ces discussions improvisées, ces éclats de rire, ces réflexions partagées sont souvent ce qui fait la vraie richesse d’une conférence.

Je repars avec des idées plein la tête, de l’énergie pour les mois à venir… et l’envie de continuer à contribuer, apprendre et partager à vos côtés.

Merci, merci, merci 🙏

PS : J’ai peut-être fait des fautes, écrit des bêtises => je vous invite à m’en faire part pour améliorer mon contenu, par PR ou par mail.