Codeurs en Seine 2024

Dev, cloud & sécu21 novembre 2024Rouen, Kindarena

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

Journée gratuite « par la communauté pour la communauté » à la Kindarena de Rouen, jeudi 21 novembre 2024 : keynotes du matin (Anne Boistard) et de la mi-journée (Sébastien Marie, Matmut), table ronde de clôture sur la sobriété numérique, 4 salles, formats conférence (50 min), quicky (15 min) et atelier (2 h) ; 25 sponsors. Pas de thème annoncé. Journée marquée par la neige, évoquée par plusieurs speakers.

Une journée gratuite très artisanale du code (code sale, SOLID, ADR, systèmes distribués, PDF, Rust/Wasm, webperf) où l'IA reste discrète et où reviennent deux fils rouges : tester dans les conditions réelles des utilisateurs (lecteur d'écran, téléphone à 200 €, production surveillée) et la responsabilité du numérique (accessibilité au-delà de la conformité, sobriété, design persuasif).

23 sessions résumées · 20 vidéos · mise à jour le mercredi 7 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme et page speakers officiels (archive codeursenseine.com) avec les descriptifs de 6 sessions, et 20 vidéos de l'édition publiées sur la chaîne YouTube Codeurs en Seine (déc. 2024 à mai 2025), toutes transcrites (transcripts automatiques). Lu en octobre 2026, soit près de deux ans après l'événement.

Limites : Aucun retour participant public trouvé : les résumés disent ce qui a été dit sur scène, pas ce qu'en a retenu la salle (seules les réactions audibles dans les vidéos en donnent une idée). Transcripts automatiques avec noms propres et chiffres parfois déformés, très dégradé pour le talk de Sophie Drouvroy. La keynote d'Anne Boistard, la table ronde sur la sobriété numérique, le talk sur la dette technique, un quicky et les 3 ateliers n'ont pas de vidéo. Audiences YouTube modestes (90 à 1 400 vues).

Synthèse globale

1. Une journée communautaire, gratuite et très « artisan du code »

Codeurs en Seine 2024 occupe la Kindarena de Rouen le 21 novembre, sur 4 salles, avec conférences de 50 min, quickies de 15 min et ateliers de 2 h. Aucun thème n'est imposé. Le programme est dominé par le métier de développeur au quotidien : code sale (Frédéric Bouchery), SRP (Julien Libert), generators JS (Nicolas Remise), ADR et systèmes distribués (Sébastien Lecacheur), internes du PDF (Frédéric Bisson), web components en Rust (Igor Laborie), Compose vers Kubernetes (équipe Compose de Docker). Plusieurs speakers notent la forte présence d'étudiants (Sébastien Marie ; Benoit El Amrani, à qui l'on a annoncé 30 % de la salle). Côté entreprises, on trouve des acteurs normands (Matmut, DARVA, MAIF) aux côtés d'indépendants et de spécialistes venus de toute la France.

2. L'IA, présente mais pas au centre

À l'inverse de l'édition 2025, l'IA générative reste en marge. Iana Iatsun parle de machine learning classique en production : 70 % des modèles jamais déployés, tableau de bord obligatoire, baseline sans ML. Ayoub Alouane l'aborde sous l'angle géopolitique (connectivité africaine, finance, militaire). Xavier Quesnot montre un générateur de Terraform par IA tout en reconnaissant qu'elle ne fera « pas 100 % du travail ». Quand la salle interroge Frédéric Bouchery sur l'IA, il se dit « très déçu » de la génération de code mais pousse ses équipes à s'y former. Le sujet le plus « futuriste » est quantique, pas génératif : Sébastien Marie (Matmut) présente une expérimentation de recuit quantique pour la tarification automobile, sans résultat encore annoncé.

3. Tester dans les conditions réelles des utilisateurs

C'est le fil rouge le plus net entre des talks qui ne se citent pas :

  • Emmanuel Pelletier fait tester la salle écran éteint avec NVDA : la solution « propre » selon les règles casse la vocalisation, la « sale » marche partout.
  • Jean-Pierre Vincent rappelle que le développeur exécute son JavaScript 5 à 10 fois plus vite que ses utilisateurs et conseille d'acheter des téléphones à 200 €.
  • Iana Iatsun décrit un modèle qui se trompe en production sans que personne le sache, faute de monitoring.
  • Sébastien Lecacheur dit qu'un système distribué est « toujours partiellement dégradé » et raconte des pannes causées par des horloges désynchronisées.

Le message commun : les référentiels, les benchmarks de laboratoire et les schémas d'architecture sont nécessaires mais trompeurs si l'on ne regarde pas le terrain.

4. Accessibilité : au-delà de la conformité

Deux talks, l'un le matin, l'autre l'après-midi, convergent. Pour Sophie Drouvroy, consultante elle-même malentendante, une conformité RGAA n'est « qu'une photo » prise sur un échantillon : le service se juge sur tout le parcours, PDF, captchas et service client compris, à l'approche de la directive européenne de 2025. Emmanuel Pelletier arrive au même point par la technique : l'accessibilité est « tout ou rien » sur le parcours critique, e-mails compris, et rien ne remplace un test d'une demi-heure avec une personne en situation de handicap. Benjamin Cavy apporte un argument de développeur : les sélecteurs Playwright fondés sur l'arbre d'accessibilité rendent aussi les tests plus robustes.

5. Responsabilité du numérique : sobriété et design persuasif

La fin de journée est plus politique. Youen Chene constate que l'écoconception « n'accroche pas » chez les développeurs, parce que référentiels et outils ont été conçus sans eux et pour le web de contenu. Il cite des initiatives plus concrètes : W3C Web Sustainability Guidelines, outils Boavizta, mesure sur Kubernetes. La table ronde de clôture sur la sobriété numérique n'a pas été filmée. Marcy Ericka Charollois élargit au design persuasif et au « techno-autoritarisme » des plateformes, devant une salle qui se dit en « majorité écrasante » manipulée par son smartphone. Le ton est donné dès l'ouverture avec la keynote non filmée d'Anne Boistard (Balance Ton Agency) sur les environnements de travail toxiques.

6. Tensions et critiques

  • Talks commerciaux : le quicky Diagram as Code tourne au pitch produit ; le talk Jamstack de Benoit El Amrani aligne des statistiques peu sourcées ; le live coding Scrapoxy, donné au pied levé pour remplacer un absent, assume d'enseigner le contournement des antibots (un participant y dénonce la discrimination des navigateurs libres).
  • Chiffres invérifiables : le talk militant sur le design persuasif cite de nombreux pourcentages sans toujours en donner la source.
  • Honnêteté sur les limites : plusieurs speakers nuancent eux-mêmes leur propos. Igor Laborie déconseille Rust/Wasm aux débutants, Frédéric Bisson qualifie son benchmark PDF de « vision très biaisée », Nicolas Remise admet ne pas avoir mesuré les performances, l'équipe Docker reconnaît trois échecs avant Compose Bridge.

7. Vie de l'événement et biais du corpus

La journée est marquée par la neige : Frédéric Bouchery la remarque en direct, Benoit El Amrani s'inquiète de rentrer à Toulouse en voiture, Sébastien Lecacheur remercie en soirée ceux qui sont restés « malgré les conditions météo ». La salle reste participative (sondages à main levée, cris de « banzaï », questions nourries pour Iana Iatsun ou Youen Chene), et les organisateurs rappellent les QR codes de feedback. Le corpus repose uniquement sur les vidéos : aucun retour écrit de participant n'a été trouvé, les vidéos les plus vues plafonnent autour de 1 400 vues, et la keynote d'ouverture, la table ronde, les ateliers et deux sessions restent sans contenu au-delà du descriptif.

Actions concrètes citées

  1. Tester ses pages avec un vrai lecteur d'écran (NVDA, VoiceOver) comme on teste dans un navigateur : certaines solutions « propres » selon le RGAA cassent la vocalisation, l'attribut title est peu fiable (Emmanuel Pelletier).
  2. Simplifier le parcours plutôt que le rustiner : un code de vérification sans majuscules est plus accessible et meilleur pour tous (Emmanuel Pelletier).
  3. Tester la webperf sur un téléphone à 200 € : le développeur exécute le JavaScript 5 à 10 fois plus vite que ses utilisateurs ; réduire le bundle a fait passer un INP de 270 à 145 ms (Jean-Pierre Vincent).
  4. Préférer WET (write everything twice) à une abstraction hâtive, et faire bloquer en CI les règles de nommage par l'analyse statique (Frédéric Bouchery).
  5. Le SRP, c'est « une seule raison de changer », donc un seul acteur : dupliquer du code identique quand il sert deux acteurs différents (Julien Libert).
  6. Tracer chaque choix technique dans un ADR qui documente le pourquoi, pas le comment ; au-delà de quatre options, la question est mal posée (Sébastien Lecacheur).
  7. Dans un système distribué, limiter dans le temps et dans l'espace (timeouts, pagination), rendre les API idempotentes et synchroniser les horloges (NTP) (Sébastien Lecacheur).
  8. Un modèle de ML en production a besoin d'un tableau de bord (disponibilité, qualité des données, performance, KPI) et d'une baseline sans ML pour prouver sa valeur (Iana Iatsun).
  9. Une conformité RGAA est une photo à un instant T : l'accessibilité se juge sur tout le service, avec des utilisateurs en situation de handicap (Sophie Drouvroy, Emmanuel Pelletier).

Session par session

Jeudi 21 novembre

Keynote▶ vidéo + transcript

Informatique Quantique, premiers cas d'usages concrets

Sébastien Marie — Matmut (DSI/CTO)

  • Keynote de mi-journée, assumée didactique (« je sais pas qui vous a puni pour vous mettre le quantique après le déjeuner ») : quantification, superposition, mesure, intrication (expériences d'Alain Aspect), qubit, sphère de Bloch, portes quantiques.
  • Deux familles de machines : les ordinateurs universels à portes, encore très bruités (« dans 5 à 10 ans »), et les recuits quantiques (annealers), disponibles aujourd'hui, qui s'arrêtent sur l'état d'énergie minimale et servent à l'optimisation combinatoire (exemples cités : aérodynamique chez BMW, molécules de batteries chez Mercedes). Il souligne la présence d'acteurs français.
  • Cas Matmut : la tarification automobile (ratio sinistres sur cotisations, 60 ans d'historique de véhicules) bute sur un clustering trop coûteux ; reformulé en QUBO et envoyé à un recuit quantique, il sert à re-simuler les exercices 2021-2022 pour comparer avec le machine learning classique. Pas de résultat annoncé.
  • Pistes suivantes : tri des 5 millions de sociétaires, analyse d'images satellite (arbres près des murs porteurs), détection de fraude via réseaux bayésiens. Projet aidé par l'État à condition de publier les résultats.
  • Q&R : la menace sur RSA (algorithme de Shor) est réelle mais pas immédiate, il faudrait « quelques millions de qubits » contre « quelques milliers » aujourd'hui ; les données chiffrées volées seraient déjà revendues en attendant. Les exécutions sont répétées « 1000, 2000, 3000 fois » et lues statistiquement.
  • Deuxième vidéo la plus vue de l'édition (~1 200 vues).
Voir sur YouTube (nouvel onglet) ↗

Keynoted'après le programme

Comment réparer les codes du travail ?

Anne Boistard — Balance Ton Agency

  • D'après le descriptif officiel, pas de vidéo publiée.
  • Keynote d'ouverture de la fondatrice de Balance Ton Agency (compte Instagram suivi par 250 000 personnes selon la page speakers) : comment créer des environnements de travail inclusifs dans la tech.
  • Annonce de mesures concrètes que les équipes peuvent déployer pour prévenir les comportements toxiques et favoriser le respect au quotidien.

Table ronded'après le programme

Table ronde : Sobriété Numérique

Vincent Villet — Publicis Sapient, Emmanuel Assié — Webaxys, Youen Chene — WebVert, Pierre Beyssac — Eriomem, Arnaud Lemercier — Wixiweb, Estelle Henrion — AshStudio

  • D'après le descriptif officiel, pas de vidéo publiée.
  • Table ronde de clôture : leviers concrets pour réduire l'empreinte carbone des services numériques, à destination des développeurs, designers et responsables techniques.
  • Objectif affiché : distinguer les mesures réellement impactantes des fausses bonnes idées.
  • Youen Chene l'annonce dans son talk précédent comme le moment où l'on vérifiera « si ça sert à quelque chose » de faire de l'écoconception.

Conférence▶ vidéo + transcript

Reconnaître un code sale

Frédéric Bouchery — CCM Benchmark (groupe Figaro)

  • Lead dev et architecte avec 41 ans de code, il part d'une idée : on écrit pour l'humain qui reprendra le code (« vous êtes votre futur legacy »). La propreté est relative et datée (syntaxe alternative de PHP, goto ajouté en PHP 5.3), mais on s'accorde plus facilement sur ce qui est sale.
  • Symptômes passés en revue : code qui ne fait pas ce qu'il dit (un fetch qui retourne void, un exists qui renvoie l'entité), commentaires inutiles (« le code c'est comme les blagues, si on doit l'expliquer c'est qu'il est mauvais »), variables trop courtes ou trop chargées de sens, méthodes et classes surchargées (il invoque la subitisation, environ 5 éléments), complexité cyclomatique, paramètres optionnels qui s'accumulent, else et négations, ternaires ambigus.
  • Contre l'abstraction hâtive, il préfère WET (write everything twice) au DRY : attendre un troisième cas avant d'abstraire, et se méfier du flag qu'on ajoute.
  • Outillage : analyseurs statiques avec des règles bloquantes (avec PHPStan, une méthode is/has/exists doit retourner un booléen, un get un objet ou une exception), SonarQube, détecteur de copier-coller, sans excès. « Je préfère un code pas trop sale qui fonctionne qu'un code propre qui ne fonctionne pas. »
  • Final : un fichier vide présenté comme le « code parfait », invitation à la simplicité.
  • Q&R : une question sur le singleton, qu'il admet avoir fait planter ; sur l'IA, il se dit « très déçu » de la génération de code mais pousse ses développeurs à s'y intéresser ; un participant note que Copilot imite le code existant. Vidéo la plus vue de l'édition (~1 400 vues).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Live-Coding : Devenez un ninja du Web Scraping avec Scrapoxy !

Fabien Vauchelles — Scrapoxy

  • Talk donné au pied levé en ouverture de la salle A, pour remplacer un speaker absent (d'après l'URL du programme, le créneau prévoyait un talk de Benjamin Cavy sur les feature flags). Vingt ans de scraping, auteur de Scrapoxy, routeur de proxys open source développé depuis 8 ans.
  • Comment un antibot vous repère : adresse IP (data center ou résidentielle, incohérence avec le fuseau horaire), empreintes TCP et TLS (JA3), ordre des en-têtes HTTP (« quatre lignes de code […] ça bloque 80 % des bots »), empreinte JavaScript (GPU, polices, WebRTC), comportement (souris, enchaînement des pages). Le tout alimente un score de réputation et du machine learning.
  • Les antibots craignent surtout les faux positifs : il cite ses propres billets de train impossibles à acheter sous Linux.
  • Méthode incrémentale pour ne pas « écraser une mouche avec un tank » : régler le scraper (Scrapy), puis proxys data center, navigateurs headless (Playwright, Puppeteer), proxys ISP, résidentiels ou mobiles, navigateur maison, enfin services payants. Pour les très gros sites, il faut désobfusquer le code de l'antibot (Babel), qui embarque désormais des machines virtuelles JavaScript.
  • Q&R : pas d'antibot open source à sa connaissance, une solution commerciale coûte « minimum 10 000 € par mois » ; un participant dénonce la discrimination des navigateurs libres. Selon lui, 80 % des usages sont la veille de prix : « tout le monde se scrape ».
  • Talk ouvertement tourné vers le contournement des protections ; prolongé par un atelier de 2 h l'après-midi.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Cycle de vie de l'IA : réussir sa mise en production

Iana Iatsun — IA Parle

  • Docteure en traitement d'image (2014), elle met des modèles en production dans une institution financière. Le talk porte sur l'apprentissage automatique classique, pas sur l'IA générative.
  • Le cycle de vie est raconté comme une recette de cuisine (collecte, préparation, apprentissage, service par API), illustré par un modèle de reconnaissance de fleurs : en production, il reçoit des photos de chats et répond n'importe quoi, sans que personne le sache.
  • Elle cite le chiffre de 70 % des modèles jamais déployés, pour trois raisons : données, sujets non techniques (gouvernance, organisation) et déploiement. D'où le MLOps, avec des outils cités comme Kedro ou Neptune.
  • Monitoring en pyramide : disponibilité du serveur, qualité et distribution des données, performance du modèle, puis KPI métier. Image retenue : rouler en Mercedes sans tableau de bord.
  • Conseils : retours utilisateurs, déploiement automatisé, et une baseline sans ML pour vérifier la valeur ajoutée. « Une fois qu'il est en prod, le travail commence juste. »
  • Q&R nourries (une vingtaine de minutes) : fine-tuning ou entraînement de zéro, Kaggle pour débuter, ne jamais mettre de notebook en production (les dépendances sont autant de vulnérabilités), distillation teacher/student contre la latence, rapprochement des data scientists et des développeurs.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Les bonnes pratiques suffisent-elles à faire fonctionner nos sites avec un lecteur d'écran ?

Emmanuel Pelletier — développeur web, spécialiste accessibilité

  • Conférence voulue accessible (la salle répond en levant la main et en criant « banzaï »). Constat de départ : presque tout le monde teste dans un navigateur, quasiment personne avec un lecteur d'écran, y compris dans des équipes sensibilisées.
  • Cas 1, démonstration écran éteint avec NVDA : un <br> dans « République française » coupe la vocalisation. La solution « propre » (spans en display block) échoue sous NVDA et JAWS, parce que NVDA lit le CSS ; la solution « sale » role="presentation" marche partout. Les bonnes pratiques « c'est pas dogmatique ».
  • Cas 2 : l'attribut title, doublé comme l'exige le RGAA, est lu deux fois ou pas du tout selon le lecteur et le mode de navigation (VoiceOver ne le lit qu'après une pause). Il renvoie à a11ysupport.io, l'équivalent de « Can I use » pour les lecteurs d'écran.
  • Cas 3 : un code de vérification avec majuscules, que les lecteurs n'annoncent pas par défaut. Les astuces (texte masqué visuellement) cassent le copier-coller ; la vraie solution est de supprimer les majuscules, ce qui sert tout le monde. En test, une utilisatrice aveugle expérimentée pensait qu'il était impossible de distinguer les majuscules.
  • Leçons : l'accessibilité est « tout ou rien » sur le parcours critique (e-mails compris), utiliser un lecteur d'écran ne fait pas de quelqu'un un expert de l'outil, et il faut tester avec des personnes handicapées plutôt qu'attendre l'audit annuel.
  • Q&R : les SPA cassent vite les bases fournies par les frameworks ; les normes sont un compromis « le moins pire » entre outils divergents et évoluent (le critère de validité W3C a été retiré).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

React / Next vs INP : le clash

Jean-Pierre Vincent — expert webperf indépendant

  • L'INP (réactivité après un clic, seuil de 200 ms, pris en compte par Google depuis 2024) face aux frameworks JS qu'il audite chez ses clients : Angular, Next, Nuxt, Svelte.
  • Cas d'un site de luxe en Angular : cascade de chargement parfaite sur desktop, mais un mauvais LCP chez les vrais utilisateurs, car l'image attend que les animations Angular démarrent. Sur un Samsung S8, il faut une seconde rien que pour lire 2 Mo de JavaScript.
  • Le 75e percentile des mobiles est à peine deux fois plus puissant qu'il y a cinq ans, l'équivalent d'un iPhone 6S. Le développeur exécute le JavaScript 5 à 10 fois plus vite que ses utilisateurs.
  • Révélation du monitoring de terrain (API Long Animation Frames, quatre clients) : les gens cliquent n'importe où pendant l'hydratation, même sur des zones non interactives, et l'INP est mesuré quand même. Sur un site Svelte, le bundle est passé de 1,7 Mo à 700 Ko et l'INP de 270 à 145 ms.
  • Recettes : aider le tree-shaking (barrel files, dépendances ESM, design system importé en entier), SVG en fichiers plutôt qu'en composants, hydratation différée et conditionnée, server components ou islands, pas de CSS-in-JS à l'exécution (sur une application Lit, 80 % du temps JS servait à interpréter du CSS).
  • Migrer vers React 18 a réduit les rendus de 162 à 40 sur un projet, sans garantie générale. Conseils : RUM et Total Blocking Time, métriques métier, un vrai téléphone à 200 € branché en USB. Q&R : pour un site e-commerce ou de news, privilégier le rendu serveur ; le throttling de Chrome est utile mais peut tromper.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Systèmes distribués, pour le meilleur et pour le pire

Sébastien Lecacheur — Odigo

  • Architecte chez Odigo (relation client multicanale, ~3 milliards d'interactions par an), il dit regretter les applications monolithiques simples de ses débuts, mais rappelle pourquoi on distribue : scalabilité, latence (serveurs vocaux déployés en Asie), fiabilité, coûts, organisation des équipes. Il distingue fiabilité et résilience.
  • Point de départ : les illusions classiques de l'informatique distribuée (réseau fiable, latence nulle, bande passante infinie…). « Le réseau c'est le vilain. »
  • Patterns de communication, avec des anecdotes : connexions persistantes (Cassandra à 100 ms faute de pool), services stateless avec sondes live et ready, cache à justifier (il « n'aime pas ça », jitter aléatoire à l'invalidation), « limiter dans le temps et dans l'espace » (timeouts, pagination pour le client qui arrive avec 40 000 utilisateurs), retries avec backoff et idempotence, mode dégradé, circuit breaker, messages asynchrones.
  • Données : réplicas en lecture, partitionnement (consistent hashing), outbox pattern, sagas avec compensation, modifications concurrentes (ETag, compare-and-swap, deltas). Anecdote : des erreurs 401 en série causées par des horloges désynchronisées, d'où NTP partout et un seul fuseau horaire.
  • Exploitation : logs centralisés, traces distribuées avec OpenTelemetry, quotas et isolation des clients, « même contre soi-même ». Conclusion : un système distribué est toujours « partiellement dégradé ».
  • Q&R : la réplication master-master est déconseillée (conflits) ; timeouts et retries sont paramétrés par l'exploitation, conseillée par les développeurs.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Construire un registre de choix d'architecture avec les ADR

Sébastien Lecacheur — Odigo

  • Second talk du même speaker, en fin de journée (« merci d'être venu rester malgré les conditions météo »). REX de cinq ans d'ADR chez Odigo, nés de quatre irritants : culture de l'oral, mêmes questions qui reviennent, départs de ceux qui savaient, développement incrémental qui produit des choix incohérents.
  • Un ADR léger : une seule décision, un format simple (Markdown), titre formulé comme une question, date, statut, contexte, décision, conséquences. Odigo y ajoute un porteur, les parties prenantes, les facteurs de décision et les options écartées avec leurs avantages et inconvénients.
  • Processus : identification, brainstorming, ateliers, consensus, puis présentation au forum d'architecture. Statuts : brouillon, proposé, accepté, remplacé, abandonné. Une fois accepté, l'ADR est immuable ; on en écrit un nouveau qui le remplace.
  • Trajectoire d'outillage : Markdown dans le dépôt (adr-log, Log4brains), puis Confluence pour tout le produit, puis Jira et Confluence à l'échelle de l'entreprise, où les cycles de décision s'allongent.
  • Bénéfices : source de vérité unique, transparence, adhésion aux choix, communication asynchrone, et le plaisir de répondre par un lien (« tu n'as qu'à lire la doc »). Difficultés : trouver des porteurs, suivre les statuts, et l'ADR n'aide pas à décider, il trace.
  • Astuces : documenter le pourquoi et pas le comment ; au-delà de quatre options, on mélange plusieurs questions ; proposer une solution « moche » pour provoquer la discussion. Q&R : le product marketing participe comme partie prenante ; les décisions imposées d'en haut sont tracées aussi ; les RFC sont une alternative.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Techno-Autoritarisme et design persuasif : quels risques pour nos libertés ?

Marcy Ericka Charollois — Merci Marcy / The Safe Place

  • Point de départ personnel : la suppression de son compte Twitter à l'été 2023 et une « retraite numérique ». À main levée, une « majorité écrasante » de la salle dit se sentir manipulée par son smartphone et juge que « c'est foutu d'avance ».
  • Le design persuasif comme ingénierie du désir, du choix (et de son illusion), de l'urgence artificielle et de l'engagement ; modèle Hook (déclencheur, action, récompense, investissement) ; Tristan Harris en repenti.
  • « La tech, c'est complètement politique » : Hedy Lamarr et les technologies duales, rapport de l'OTAN sur l'utilisateur devenu vecteur de propagande, figures messianiques des patrons de la tech (Musk, Zuckerberg, Holmes), techno-féodalisme (Varoufakis), réseaux sociaux comme « troisième lieu ». Algorithmes qui amplifient la division.
  • Droits menacés : vie privée, expression, autonomie (scoring de la CAF documenté par La Quadrature du Net), droit de manifester, santé mentale des adolescents (familles qui assignent TikTok).
  • Pistes : moins se dévoiler, supprimer les applis toxiques, aider ses proches à débunker, « éduquer son algorithme », aller sur Bluesky, s'appuyer sur le DSA et Pharos, et côté conception des nudges positifs. Elle avoue ne pas avoir de conclusion stable, sinon éteindre son smartphone, « le geste le plus révolutionnaire ».
  • Lecture critique : talk militant, nombreux chiffres cités oralement (47 %, 64 %, 210 à 400 consultations par jour…) dont les sources ne sont pas toujours précisées. Démarrage en retard.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Plongée au cœur des PDF

Frédéric Bisson — développeur web

  • Pourquoi encore le PDF en 2024 : un seul fichier, l'archivage, la signature. Son poids vient surtout des images, et les compresseurs en ligne abîment les images, la conformité PDF/A et les métadonnées.
  • Histoire (projet Camelot en 1990, PDF 1.0 en 1993, format ouvert en 2008, PDF 2.0 qui apporte peu) puis anatomie : objets, table des références croisées, trailer, langage graphique postfixé hérité de PostScript, flux filtrés. Un PDF peut être entièrement ASCII, et les mises à jour incrémentales permettent de retrouver d'anciennes versions.
  • Gisements d'optimisation : chaînes hexadécimales réécrites en littérales, minification (45 octets inutiles sur 148 dans un exemple), précision absurde (couleurs à cinq décimales), métadonnées XMP, hinting des polices, images dupliquées ou rognées (PowerPoint et Impress n'ont pas la même stratégie), sauvegardes d'état graphique inutiles.
  • Compression : prédicteurs empruntés au PNG, Zopfli compatible avec Deflate, flux d'objets, et un cumul prédicteur, RLE et Flate qui ramène un dégradé de 256 Ko à 134 octets sans perte.
  • Il a trouvé et fait corriger un bug de PDF.js sur les chaînes hexadécimales. Son side project en Haskell réduit la spécification PDF 1.7 de 32 Mo à 12 Mo sans toucher aux images, ce qu'il qualifie lui-même de « vision très biaisée ».
  • Q&R : minification, coût mémoire des images masquées contre rognées, suppression des objets écrasés par les mises à jour.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Créer des expériences utilisateur optimales avec des architectures web modernes

Benoit El Amrani — Pickbeam

  • Pourquoi l'UX compte : statistiques de rebond et de conversion, Core Web Vitals (LCP, INP, CLS) et Web Almanac 2024, selon lequel seuls 38 % des sites mobiles passent les seuils ; le poids des pages aurait été multiplié par 155 en 27 ans.
  • Trois âges du web : le « build » (2000-2010), le « build vs buy » (SaaS, API, CMS headless, no-code, 2010-2020), puis le « build and buy » composable.
  • Glossaire du jargon, dont il retrace l'étymologie : Jamstack (Netlify, 2016, redéfini en 2022), découplage, headless, pré-rendu, CSR, SSR, SSG, ISR, composable, MACH Alliance.
  • Outils : générateurs (Next, Astro, Nuxt, Hugo), plateformes (Vercel, Netlify), CMS headless par API (Storyblok, Contentful, Strapi, WordPress headless) ou basés sur Git (Tina, Decap). Le choix dépend de qui édite, du budget et de l'hébergement des données.
  • Bénéfices revendiqués : performance (41 % des sites statiques passent les Core Web Vitals), modularité, autonomie du marketing. Cas Smashing Magazine (800 ms à 80 ms, +31 % de trafic SEO) et Calendly (pages créées 10 fois plus vite).
  • Talk de vulgarisation au ton assez promotionnel, chiffres peu sourcés ; une seule question (sur le serverless).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Et si on écrivait nos Web Components en Rust ?

Igor Laborie — Vector 8

  • Développeur backend Rust, il commence par un rappel des web components natifs (custom elements, shadow DOM, attributs et événements custom) sur un compteur écrit en TypeScript, puis cite Lit.
  • Live coding Rust vers WebAssembly : ownership et borrowing (« une fois qu'on a compris ça, on a compris 80 % 90 % de Rust »), wasm-bindgen, web-sys, gloo. Il bute sur l'absence d'héritage (contournée par une classe JS anonyme), sur le cycle de vie de l'écouteur d'événements et sur la mutabilité intérieure (Rc et Cell). Le compilateur devient un « pote de pair programming ».
  • Version confortable avec Dioxus (inspiré de React, RSX, signaux, multi-plateforme) et la bibliothèque dioxus-web-component qu'il a écrite.
  • Bilan honnête : le Wasm de Dioxus est lourd (ses slides en Dioxus pèsent 600 Ko) ; « pas une bonne idée de faire du web assembly quand vous connaissez pas encore Rust » ; l'écosystème UI reste embryonnaire. Selon lui, Rust devient plus rapide que TypeScript au-delà de deux semaines de développement. Il l'a utilisé sur un vrai projet d'entreprise.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Compose to Kube, same player shoot again

Guillaume Lours — Docker, Nicolas de Loof — Docker

  • Duo de l'équipe Compose de Docker (« à peu près l'intégralité de l'équipe engineering »), sur la tension entre développeurs sous Compose et Ops sous Kubernetes. À main levée, beaucoup font du Kube en production, presque personne en dev : « Kube […] pour le dev c'est juste l'horreur ». Ils citent des CI qui vérifient que Compose et les manifests Kube déclarent le même nombre de ports.
  • Ils reconnaissent les échecs passés (Kompose, Compose on Kubernetes, Compose vers ECS) : trop rigides, alors qu'il y a « autant de variantes que d'utilisateurs ».
  • Nouvelle approche Compose Bridge : le compose.yaml est transformé en manifests Kubernetes par des transformers, de simples images Docker contenant des templates Go, chaînables, avec overlays Kustomize, génération de chart Helm et attributs x- pour les besoins spécifiques. Démo dans Docker Desktop, qui propose désormais un cluster multi-nœuds.
  • Démo de personnalisation : remplacer le secret en base64 (moqué) par une référence à Vault. Quelques ratés de live coding, dépannés par la salle.
  • Message : faire écrire les transformers par les Ops une fois pour toutes. Q&R : l'outil est minimal, toute la logique est dans les templates ; le sens inverse (Kube vers Compose) est bien plus difficile.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Pourquoi les devs et l'éco-conception cela n'accroche pas ? Les devs sont-ils climato-sceptiques ?

Youen Chene — WebVert

  • Un « coup de gueule » : très peu de talks « green » dans les grosses conférences tech. Il bouscule ses propres préjugés (les développeurs seraient-ils climatosceptiques ?).
  • Biais français : avec une électricité très peu carbonée (environ 52 g de CO2 par kWh le jour de sa capture, contre 386 en Allemagne), l'enjeu en France est le matériel importé. Mais la culture de l'optimisation s'est perdue vers 2013 : « ça rame, on rajoute des machines ».
  • Ce qui ne marche pas pour les devs d'applications métier, majoritaires dans la salle à main levée : référentiels (RGESN) faits sans développeurs, outils de mesure pensés pour le web de contenu (« mesurer l'humidité avec un thermomètre »), études comparant des langages sans leurs frameworks, communication carbone des clouds. Il raconte avoir été « le seul dev » dans un groupe de travail ministériel.
  • Ce qui émerge : W3C Web Sustainability Guidelines (septembre 2024), API et scanner cloud de Boavizta, sondes de mesure pour serveurs physiques et Kubernetes, outils de simulation de parcours, bibliothèque Zotero de Boavizta, initiative de Tristan Nitot pour rendre le logiciel deux fois plus rapide tous les deux ans.
  • Q&R : la haute disponibilité reste un devoir (« si tu redondes pas […] c'est une faute professionnelle »), l'obsolescence logicielle relève de la régulation (étude allemande citée : 30 % des téléphones sortent du parc en un an, dont la moitié pour incompatibilité logicielle), et il faut agir à son niveau.
  • Le speaker participe aussi à la table ronde de clôture.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Le paradoxe du web invisible : un site web conforme n'est pas forcément un service accessible

Sophie Drouvroy — So Accessible

  • Consultante en accessibilité, elle-même malentendante et appareillée ; elle demande qu'on répète les questions de la salle, une illustration concrète de son sujet.
  • Paradoxe 2025 : la directive européenne étend l'obligation d'accessibilité (e-commerce, banques, transports, médias) alors que la plupart des sites déjà concernés ne sont pas conformes.
  • La conformité RGAA est une photo à un instant T, sur un échantillon de pages ; les outils automatiques n'en couvrent que 20 à 30 %. Exemple : un site métropolitain déclaré pleinement conforme en 2022 qui propose en 2024 un PDF non accessible.
  • Cas d'usage hors interface : captchas (vidéo sur une caissière qui demande de « sélectionner les vaches »), délais de formulaire, erreurs non localisées, publicité, formation, service client par téléphone.
  • Vers une accessibilité de service : référentiel Opquast, design inclusif (handicap permanent, temporaire ou situationnel), inventions nées du handicap devenues universelles, tests avec des personnes handicapées, formation de tous les métiers. L'accessibilité « pas qu'un pourcentage ».
  • Transcript automatique très dégradé : résumé à prendre avec prudence.
Voir sur YouTube (nouvel onglet) ↗

Conférenced'après le programme

S'endetter pour Se Développer : Stratégies d'Investissement en Dette Technique

Ludovic Lefebvre — Peaksys

  • D'après le descriptif officiel, pas de vidéo publiée.
  • La dette technique vue comme un prêt bancaire bien maîtrisé : un levier pour accélérer l'innovation, notamment pendant la recherche du product-market fit.
  • Quand et comment la contracter, ses types, avantages et risques, et des stratégies pour la gérer et la rembourser dans un cadre agile.

Lightning talk▶ vidéo + transcript

Playwright : tester vos applications devient un jeu d'enfant

Benjamin Cavy — MAIF

  • Quicky de 15 min, démo live quasi sans slides sur Izanami, une vraie application open source de la MAIF, plutôt que sur une application d'exemple.
  • Il recommande des sélecteurs fondés sur l'arbre d'accessibilité (getByRole, getByLabel) : les tests survivent à un changement de bibliothèque de composants et garantissent un premier niveau d'accessibilité.
  • Le codegen, qui l'a fait « tomber amoureux » de l'outil, enregistre les actions, mais le code produit doit être nettoyé. Autres points montrés : API à base de promesses (plus simple selon lui que la grammaire de Cypress), mode UI avec snapshots, bouchon d'API en erreur 500, test de régression visuelle.
  • Applaudissements à la fin, malgré quelques ratés de démo.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Vous ne connaissez pas le S de SOLID !

Julien Libert — Evoliz

  • Quicky de 15 min d'un lead développeur. Beaucoup de développeurs autour de lui, et même ChatGPT, se trompent : le SRP ne veut pas dire « une classe fait une seule chose » mais « un module doit avoir une et seulement une raison de changer », c'est-à-dire un seul acteur (reformulation de Robert C. Martin en 2017).
  • Exemple de la classe Employee de Clean Architecture : une méthode partagée modifiée pour la paie casse le reporting des RH. Il fallait dupliquer ce code dès le départ, même identique. Le second effet d'une classe à plusieurs acteurs : les conflits de merge entre équipes.
  • Solution : éclater en classes par acteur, éventuellement derrière une façade ; gains en lisibilité, testabilité et nombre de bugs. Fini « il restait 12 secondes ».
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Les generators, simplifier le traitement des flux de données

Nicolas Remise — DARVA

  • Quicky de 15 min. Contexte : un gros volume quotidien de documents MongoDB à transformer ; l'équipe a écarté un ETL du marché au profit de scripts JS, mais l'API stream native est « relativement vieillissante en terme de développeur expérience ».
  • Il redécouvre les generators (function*, yield, protocoles iterator et iterable) : chaque étape (lecture, parsing, enrichissement, formatage, log) devient un générateur, chaînés par deux petits utilitaires.
  • Bénéfices annoncés : briques plug and play, logique métier séparée de l'exécution, chaîne configurable par variables d'environnement, style fonctionnel. Il annonce des performances équivalentes aux streams tout en admettant « j'ai pas fait une benchmark ».
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Une image vaut mille mots ? Zoom sur l'approche « Diagram as Code »

Xavier Quesnot — GetCaaS

  • Quicky de 15 min. Problème posé : schéma d'architecture cloud dessiné à la main, IaC à écrire, coût et carbone à estimer, documentation oubliée. À main levée, la salle fait plus de Terraform que de CloudFormation.
  • Le talk tourne vite à la démo du produit maison (nom mal transcrit) : import d'un compte AWS, génération de Terraform par une IA, estimation du coût et du carbone, documentation Markdown. Il assume que l'IA ne fera « pas 100 % du travail ».
  • Q&R : prix SaaS par utilisateur ; carbone calculé avec la base de l'ADEME plutôt qu'avec les chiffres des clouds (« Amazon qui veut nous faire croire qu'ils sont une forêt »).
  • Lecture critique : surtout un pitch commercial, peu de fond sur le diagram as code en général.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

L'IA en Afrique : Comment Rebondir ?

Ayoub Alouane — Adsevio Group

  • Quicky de 15 min (débordé à 18) sur la souveraineté face à la course à l'IA, chiffres de PIB à l'appui (l'Afrique entière pèserait à peu près comme la France). Avec ChatGPT, nous n'aurions selon Žižek que « la version décaféinée » de l'IA.
  • La « vraie » IA serait en finance (Aladdin de BlackRock, dont il reconnaît ne pas avoir pu confirmer tous les chiffres) et dans le militaire (boucle OODA, drones, vol Iran Air 655, l'Ukraine présentée comme « première guerre de l'IA »).
  • Pour l'Afrique, le frein est la connectivité (26 % de pénétration d'Internet en Afrique centrale et de l'Est contre 66 % en moyenne mondiale) ; usages porteurs : agriculture, santé, éducation par SMS.
  • Salle interactive (questions « qui connaît… ? »). Il annonce un livre à paraître. Transcript coupé à la fin.
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (5)

  • Comment l'utilisation de l'IA impacte-t-elle la triche et la lutte anti-triche dans les jeux vidéo (Mehdi Lorente, étudiant, quicky)
  • Atelier : Développer avec l'IA, et si c'était aussi simple qu'ajouter une librairie ? (Stéphane Philippart, Thierry Chantier — OVHcloud)
  • Atelier : Devenez un expert en Anti-Ban et Web Scraping en 2h (Fabien Vauchelles — Scrapoxy)
  • Atelier : Vivez l'expérience d'une modélisation orientée Domain Driven Design (Bruno Boucard — OCTO Technology)
  • Devenir organisateur et/ou bénévole pour Codeurs en Seine (quicky)

Sources