La Duck Conf 2025

Dev, cloud & sécu19 mars 2025Paris, Parc floral de Paris8e édition

Thème : De l'archi à toutes les sauces : sous contrainte, pimentée d'orga, applicative, code d'infrastructure et code augmenté par l'IA

Site archivé (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de mars 2025 →

« La duck conf, au parc floral, le 19 mars 2025 », site officiel archivé. Veille de La Grosse Conf (OCTO). Trois salles (Nemo, Atlantide, Neptune), 11 talks et un atelier DDD. Replays : playlist YouTube « La Duck Conf 2025 - les replays » (https://www.youtube.com/playlist?list=PLXlbmbYadKH5d5aKO2mNaH787kBDwXRU4).

Une édition d'architecture pragmatique et sans dogme : iframes avant Module Federation, monolithe modulaire avant microservices, Brownfield avant refonte, moins de tests mais mieux ciblés, plateformes conçues comme des produits, avec l'IA traitée en assistant à piloter plutôt qu'en révolution.

11 sessions résumées · 11 vidéos · mise à jour le jeudi 8 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel (site laduckconf.com et capture Wayback de février 2025), édito du site, article d'annonce du blog OCTO (19/02/2025) et transcripts automatiques des 11 replays YouTube publiés entre le 31/03 et le 14/04/2025 (un par talk, l'atelier « Infra as code, as code » inclus).

Limites : Aucun retour de participant trouvé : les résumés reflètent ce qui a été dit sur scène, pas la réception par le public. Sous-titres automatiques bruités (noms propres et chiffres parfois incertains, signalés). L'atelier DDD n'a ni replay ni compte-rendu ; aucune séance de questions-réponses n'est captée, sauf pour l'atelier Infra as code.

Synthèse globale

1. Le pragmatisme contre le dogme des patterns

Fil rouge de la journée : un pattern n'est pas une obligation. InVivo démarre ses micro-frontends en iframes, la « bonne réponse » face à une salle qui votait Module Federation, et renonce assumément au déploiement indépendant (Julien et Martins). Chantalou recommande le « Majestic Monolith first » plutôt que MACH d'emblée. Mazure supprime environ les trois quarts de ses tests sans perdre de couverture. Bertrand et Dousset acceptent un SI hétérogène pendant la migration événementielle. Point commun : partir du problème et de l'organisation, pas de la technologie à la mode.

2. Conway partout : l'architecture se joue dans l'organisation

Le programme annonçait « de l'archi pimentée d'un peu d'orga » (édito) et la loi de Conway revient dans plusieurs talks. Ahnine en fait son sujet : cartographie domaines × équipes × actifs, règles Team Topologies, découpage par ubiquitous language. Julien et Martins justifient le micro-frontend par des équipes métier responsables du back au front. Landreau compare Team Topologies et two-pizza teams, Lesik invoque les équipes plateforme pour la DevEx. Chez Yubo, le premier chantier est organisationnel (data engineering dans l'infra, infra dans les kick-offs) avant d'être technique (Robert).

3. Les plateformes, des produits à concevoir avec prudence

Trois talks se répondent. Landreau pointe les pièges : coûts non linéaires, services qui passent « sous l'eau » du cloud, wrapper anti lock-in qui appauvrit, fonctionnalités sans consommateur. Robert montre l'inverse réussi à petite échelle : tout en CRD et templates, une application créée par un paramètre, l'infra reconstructible from scratch. Gahat et Fontaine proposent des couches d'abstraction où le développeur peut coder « sur la couche la plus pertinente », avec une limite : plus on vise de clouds, plus l'abstraction commune rétrécit. Lesik ajoute le point de vue de l'utilisateur : un portail interne peut devenir une « usine à gaz » pour une petite équipe.

4. L'expérience développeur et la charge cognitive

Le développeur, « espèce menacée » selon l'édito, est au centre de plusieurs talks. Lesik rappelle les 84 minutes de code par jour et le coût des interruptions ; Laurent y renvoie pour souligner le poids cognitif du code généré par l'IA. Landreau prend le contre-pied : « méfiez-vous de la réduction de la charge mentale » quand elle sert à faire produire des juniors sans les faire progresser. Mazure traite le même sujet sous l'angle des tests : une boucle de feedback passée de 12 minutes à 10 secondes.

5. L'IA, assistant à piloter plutôt que révolution

L'IA n'a qu'un talk dédié, le dernier de la journée, et une des quatre tendances de Chantalou. Chantalou chiffre le gain des assistants de code à 10 à 15 % (« avec des pincettes »), inégal selon la séniorité, et voit peu de révolution architecturale côté applications (« des appels d'API »). Laurent réussit en direct une appli Python inconnue avec Cursor, mais montre aussi les ratés : contexte perdu, règles métier absentes, démo qui cale. Les deux convergent : mêler craft et IA, garder des seniors dans les équipes et ne pas « se faire piloter par l'IA ». Lesik mesure Copilot sur son propre ticket : une demi-journée gagnée, sans effet sur la satisfaction.

6. Faire évoluer l'existant sans big bang

Plusieurs talks défendent la migration incrémentale face à la refonte. Il y a le Brownfield « Docteur House » avec façade et front headless (Chantalou), la bascule Vue 2 vers Vue 3 fragment par fragment (InVivo), l'inversion d'un référentiel en événements pour les seules nouvelles applications (Bertrand et Dousset) et la reprise d'une base de tests héritée (Mazure). Côté front, Jacquemin rappelle que des correctifs CLS et INP simples, sur le site existant, pèsent directement sur le référencement et le chiffre d'affaires.

7. Tensions et limites du corpus

Quelques points restent débattus sur scène : le test end-to-end branché sur la recette, risqué selon l'équipe de Mazure ; la perte du déclaratif quand l'infra devient du code (questions-réponses de l'atelier) ; les gains de DevEx ou d'IA mesurés sur un seul ticket, que Lesik juge elle-même subjectifs. Les retours manquent : aucun post de participant ni compte-rendu n'a été trouvé. Tous les speakers sauf deux (Landreau d'AWS, Robert de Yubo) sont d'OCTO ou co-présentent avec OCTO. Ce corpus reflète donc le discours de l'organisateur, sans la réception par le public.

Actions concrètes citées

  1. Choisir la technologie la plus simple qui débloque la migration : InVivo a démarré ses micro-frontends en iframes pour éviter le big bang, puis est passé à Module Federation une fois mûr.
  2. Partir d'un « Majestic Monolith » modulaire découpé par domaines et n'extraire microservices ou headless que sur besoin (Chantalou).
  3. Écrire une stratégie de test qui dit aussi ce qu'on ne teste pas ; tester les fonctionnalités, pas les implémentations, et supprimer des tests sans culpabiliser (Mazure).
  4. Aligner équipes et domaines métier avant de toucher à l'architecture : un domaine par équipe, un seul domaine complexe par équipe (Ahnine, d'après Team Topologies).
  5. Ne livrer aucune fonctionnalité de plateforme sans une équipe prête à la consommer ; se placer sur ce qui est spécifique à l'entreprise, pas sous la ligne de flottaison du cloud (Landreau).
  6. Traiter l'infrastructure comme un produit : templates, CRD et abstractions qui expriment l'intention, avec des couches ouvertes aux développeurs (Yubo, Gahat et Fontaine).
  7. Rendre l'architecture implémentée visible par des conventions de nommage et un script qui génère le schéma réel, puis comparer à la cible (Bertrand et Dousset).
  8. Aller voir dès maintenant ses Core Web Vitals dans le CrUX : les correctifs CLS et INP sont souvent simples (Jacquemin).
  9. Protéger le flow des développeurs, qui ne codent que 84 minutes par jour selon l'étude citée, en réduisant la charge cognitive extrinsèque (Lesik).
  10. Utiliser l'assistant de code en gardant la main : il produit vite mais doit être recadré comme un développeur junior (Laurent).

Session par session

Mercredi 19 mars

Conférence▶ vidéo + transcript

Les pièges des plateformes : apprenez à les reconnaître et à les éviter

Jean-François Landreau — AWS, auteur de Platform Strategy

  • Talk d'ouverture, tiré de son expérience avant AWS (éditeur de logiciels de finance de marché dès 2007, puis grande entreprise régulée).
  • Piège 1, le buzzword : « plateforme » est mal défini. Remèdes : la métaphore du châssis commun automobile et une définition par catégorie (marketplace, plateforme business type SAP, cloud, plateforme de développement interne). Il préfère les « economies of speed » aux économies d'échelle.
  • Piège 2, le coût n'est pas linéaire : quatre « sauts » (une équipe colocalisée, d'autres équipes, toute l'entreprise à l'international, l'ouverture à l'extérieur). Tant que le self-service n'est pas mûr, il faut compenser par l'humain.
  • Piège 3, le positionnement face au cloud : si vos services passent « sous l'eau » des services managés, la plateforme perd sa valeur. Le wrapper anti lock-in au plus petit dénominateur commun prive de l'innovation du fournisseur et des certifications des développeurs.
  • Méfiance envers la « réduction de la charge mentale » : une organisation pyramidale où les juniors produisent vite sur la plateforme ne les fait pas progresser ; il défend une organisation en diamant où les seniors coachent.
  • Règle retenue : « Ne délivrez aucune fonctionnalité qu'un client n'est pas prêt à consommer. »
  • Lecture critique : il reconnaît que son poste actuel chez AWS teinte le propos.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Le micro-frontend décomplexé : les dessous d'une migration incrémentale et itérative

Xavier Julien — InVivo Digital Factory, Brandone Martins — OCTO Technology

  • REX sur Aladin.farm (InVivo), SPA Vue.js née en 2018 : environ 40 développeurs front passés dessus, un mois d'onboarding avant la première merge request, des développeurs qui ont peur de toucher au front, alors que la quinzaine de microservices back ne posait pas de problème.
  • Contraintes : migrer de Vue 2 à Vue 3 avant fin 2024, sans big bang ni gel des développements, et préparer une plateforme multimarque.
  • Principes : un fragment par domaine métier, une équipe par fragment, des contrats d'interface stables (« Si ce contrat d'interface n'est pas stable, c'est qu'on a raté notre découpage »), lien explicite avec la loi de Conway. « Il y a le mot micro, mais pensez plutôt macro » : découpage vertical d'abord.
  • Sondage dans la salle : majorité pour Module Federation ; la bonne réponse était les iframes, seules compatibles avec une appli CommonJS sans big bang. Module Federation est venu ensuite, une fois tout migré.
  • Jalons : POC en novembre 2023, premier micro-frontend en prod un mois plus tard, 11 en 2024, puis passage progressif à Module Federation.
  • L'app shell garde l'état partagé, le support (monitoring, analytics) et le routing, avec des contrats d'événements en postMessage.
  • Choix assumé de ne pas déployer les fragments indépendamment (un seul conteneur Nginx) : on peut laisser de côté un principe du pattern si l'organisation n'en a pas besoin.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Déjouer les pièges de Conway dans l'agilité à l'échelle

Samuel Ahnine — OCTO Technology

  • Point de départ : un program board de PI planning SAFe aux dépendances en « plat de spaghetti ». « C'est la structure de mon organisation qui va l'emporter. »
  • Paradoxe de l'échelle : les petites équipes fonctionnent, mais leur multiplication sur un legacy couplé fait exploser les interactions, la latence et les coûts.
  • Cas client : une société de jeux en ligne d'environ 500 personnes, cinq ans après son passage à Scrum ou Kanban : équipes surchargées, effets de bord, livraisons de plus en plus lentes.
  • Méthode : manœuvre de Conway inversée, Event Storming Big Picture pour faire émerger les domaines, puis une cartographie OCTO en trois dimensions (domaines, équipes, actifs techniques). Elle révèle un monolithe de base de données central et deux composants dont le savoir était perdu.
  • « Police des domaines » tirée de Team Topologies : un domaine n'a qu'une équipe ; une équipe gère 2 ou 3 domaines simples mais un seul domaine compliqué ou complexe. Le découpage suit les ruptures de l'ubiquitous language (« partie » de poker au sens tournoi ou partie unitaire).
  • Cible : quatre stream-aligned teams, une équipe complicated-subsystem (gains et fraude), une équipe plateforme « instance de jeu ». La collaboration est gardée là où un composant n'a pas pu être découplé.
  • Limite reconnue : « Tous les modèles sont faux, certains sont utiles » ; aucun chiffre de gain, hormis des délais de livraison raccourcis après le partage de la base.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Tests pragmatiques : comment (presque) arrêter les tests automatisés ?

Antoine Mazure — OCTO Technology

  • Projet de tunnel de vente repris sans passation : environ 9 lignes de test par ligne de code, des tests qui agissent comme des cadenas plutôt que comme un filet. Une évolution TVA estimée à 2 jours n'était pas finie au bout de 2 semaines.
  • La stratégie de test se documente comme l'architecture : elle dit quoi tester, quoi ne pas tester, et reste propre à chaque projet.
  • « Tester les fonctionnalités plutôt que les implémentations » : des tests d'orchestration sur les use cases, puis des tests ciblés sur le code complexe ou sensible (prix, sécurité). Pas de tests sur les getters ni les mappers un pour un.
  • Environ 600 tests end-to-end remplacés par un seul parcours end-to-end par progiciel (Pareto), branché sur la recette pour détecter les contrats d'interface qui changent sans prévenir. Ce choix a été débattu dans l'équipe (risque de flakiness).
  • Bilan annoncé : environ trois quarts des tests supprimés, couverture identique à 1 % près, boucle de feedback de 12 minutes à 10 secondes.
  • Message : « Des tests, on peut les supprimer sans forcément culpabiliser », mais le pragmatisme ne vient qu'après avoir maîtrisé les règles. Il qualifie lui-même la métrique en lignes d'imparfaite.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Infrastructure as a Template : 84M d'utilisateurs avec une équipe de 5 personnes

Mikael Robert — Yubo

  • Yubo, réseau social vidéo pour la Gen Z : environ 85 millions d'inscrits, environ 400 microservices, 11 technologies de bases de données, environ 40 clusters, des pics annoncés à 300 000 requêtes par seconde sur certaines bases.
  • Point de départ en 2021 : aucun automatisme, coûts « monstrueux », tout dans un seul Kubernetes. « Quand on a beaucoup de contraintes, ça pousse à innover ».
  • Étapes : intégrer le data engineering à l'infra et l'infra aux kick-offs de features, traiter le RGPD comme une solution (rétention automatisée), GitOps, un cluster de pilotage Argo, puis tout en CRD Kubernetes (une collection Mongo déclarée en quelques lignes de YAML), Config Connector à la place de Terraform.
  • Une nouvelle application se crée par un paramètre dans le template global, qui sert aussi de plan de reprise d'activité : l'infra se reconstruit from scratch.
  • Données : duplication assumée (une base par feature), CDC vers Kafka avec auto-guérison des consommateurs ; ML déployé en canary par un opérateur, MLflow comme registre.
  • Observabilité : dual shipping Datadog et VictoriaMetrics, environ 30 To de logs par jour, sampling pour réduire la facture analytics.
  • « Les outils n'ont pas d'importance, c'est les patterns qui vont autour qui sont importants. » Chiffres tirés d'un transcript automatique, certains incertains.
Voir sur YouTube (nouvel onglet) ↗

Atelier▶ vidéo + transcript

L'infra as code, as code

Sébastien Gahat — OCTO Technology, Ulysse Fontaine — OCTO Technology

  • Talk suivi d'un live coding (1h30 au programme). Thèse : le code d'infra ressemble à une liste de courses ; il doit exprimer une intention lisible. « L'infra c'est un produit. Un produit ça se code. »
  • Leviers : l'intention dans les tickets et le code, une interface unifiée pour les utilisateurs (CLI, YAML, CRD, portail), un but atteint vite puis du désendettement, une boucle rapide déployer et supprimer.
  • Couches d'abstraction inspirées du modèle OSI : portail, manifeste à trous, use case (CI/CD), repository qui encapsule les règles ops, provisioning (Terraform, API cloud, Crossplane). « Autorisez-vous à coder sur la couche la plus pertinente. »
  • Démo : une CLI « duck » en TypeScript avec Pulumi (Automation API) qui déploie un conteneur sur Scaleway ; la règle « pas de tag latest » devient un test unitaire sans appel API. Un participant relève que la vérification par chaîne rejetterait aussi latest-v1.
  • Même use case décliné sur GCP et AWS Fargate, avec un avertissement : plus on multiplie les clouds, plus l'abstraction commune se restreint.
  • Questions-réponses : faisable avec des modules Terraform ; la perte du déclaratif freine l'adoption, d'où la proposition de mixer le déclaratif pour le stable et le code pour ce qui bouge.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

L'architecture continue par la pratique

Pierrette Bertrand — OCTO Technology, Pierre-Jean Dousset — OCTO Technology

  • Dialogue à deux voix sur un système de gestion des urgences. « L'architecture continue consiste à faire évoluer rapidement et sans rupture les SI au fur et à mesure des besoins. » Quatre défis : alignement, maîtrise, design sans rupture, ownership.
  • Alignement : une phrase de vision technique co-construite par tous les acteurs tech, des drivers d'architecture avec un curseur par driver (plus il est haut, plus on investit dans la vérification).
  • Maîtrise : l'architecture implémentée dérive de la cible. Plutôt qu'une live doc par APM, des conventions de nommage des variables d'environnement et un script « Python et des grep » génèrent le schéma réel.
  • Design sans rupture : un référentiel devenu goulot est inversé en publication d'événements (RabbitMQ, transactional outbox, idempotence) ; seules les nouvelles applications migrent. « On s'autorise à avoir une situation hétérogène », « sans rupture mais pas sans complication ».
  • Ownership : l'architecte décide le moins possible, accepte le « good enough », ne se met jamais sur le chemin critique et cherche à se rendre dispensable ; le tech lead porte le contexte et la qualité.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Du Chaos au Flow : faut-il miser sur la DevEx ?

Lana Lesik — OCTO Technology

  • Sondage d'ouverture : combien de temps un développeur code-t-il par jour ? Réponse : 84 minutes (étude d'André Meyer citée de mémoire), prétexte à illustrer les biais cognitifs.
  • Ancienne psychologue, elle relie DevEx et sciences cognitives : charge cognitive (7 ± 2), environ 23 minutes pour revenir après une interruption, charge extrinsèque seule contrôlable, flow de Csikszentmihalyi.
  • Expérience personnelle sur un ticket de 5 jours, mesurée en productivité et en « happiness » : Copilot fait gagner une demi-journée ; l'IDP est refusé par son architecte (une « usine à gaz » pour une petite équipe) ; la plateformisation sur un train SAFe ramène à 3,5 jours ; le flow forcé sans réunions ramène à 3 jours mais l'isole.
  • « J'ai gagné en productivité, j'ai perdu en happiness. »
  • Cadre retenu : trois dimensions de la DevEx (boucles de feedback, charge cognitive, flow). DevEx reste un mot « hype » sans définition unique, qui n'a d'effet réel que porté par la direction.
  • Elle qualifie elle-même ses gains (environ 30 %) d'optimistes et très subjectifs.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Des millisecondes contre des millions d'euros

Léo Jacquemin — OCTO Technology

  • Fil narratif : le cousin « Polo » qui veut devenir numéro un de la peluche en ligne. Le référencement dépend désormais de métriques UX : « Plus que jamais l'UX, c'est pas seulement un délire de hipster. »
  • CLS : trois causes et leurs correctifs simples (dimensions des images ou aspect-ratio, bannières en position absolue, polices de repli ajustées).
  • INP (seuil de 200 ms) : un site qui ne réagit pas est perçu comme bugué. Cas de Polo : des dizaines de scripts de tracking synchrones au clic (400 ms au p75), corrigés en rendant la main au rendu (setTimeout sur l'analytics).
  • Biais du développeur : « ça marche sur mon iPhone », alors que la majorité des utilisateurs a des appareils moins puissants. Google mesure au p75 sur données réelles, publiques via le CrUX.
  • Pas de takeaway mais un « take action » : consulter le CrUX dès maintenant et faire corriger CLS et INP s'ils ne sont pas au vert. Le LCP n'est pas traité faute de temps.
  • Plusieurs chiffres (52 % du trafic sur le top 3, 95 % des sites sans problème d'INP) sont donnés de mémoire.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Coder une application inconnue en 30 min grâce à l'IA : buzz ou révolution ?

Nicolas Laurent — OCTO Technology

  • Talk de clôture en improvisation : sujet et langage tirés au sort par la curation. Résultat : une application Python qui dimensionne un tableau électrique selon la norme NF C 15-100.
  • Outil : Cursor en mode agent avec un modèle Anthropic (Claude 3.7 surchargé, bascule sur Claude 3.5). Environ 100 lignes générées en une minute, 230 en moins de 30 minutes, une appli console fonctionnelle : « plutôt un succès ».
  • Ce qui a raté : l'agent perd le fil (fichiers recréés à la racine), oublie l'environnement virtuel, n'ajoute aucune règle métier au départ et accepte un « robot aspirateur » hors énumération. La dernière saisie échoue : « bon, on s'arrête là ».
  • Ce qui a marché : ajouter la sortie du terminal ou une capture d'écran au contexte fait corriger les règles et la validation des entrées.
  • Bilan : démarrage rapide et code plutôt cohérent, mais gérer le contexte et le volume généré reste dur. « C'est comme un développeur un peu junior qui produit plein de code, mais qu'on doit en permanence recadrer » ; le risque est de « se faire piloter par l'IA ». Il cite une étude (41 % de bugs en plus avec Copilot) et Addy Osmani (les seniors en profitent plus que les juniors).
  • Trois messages : monter dans le train, mixer pratiques craft et IA, développer ses soft skills.
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (1)

  • Vivez l'expérience d'une modélisation orientée Domain-Driven Design (atelier, Bruno Boucard et Godefroy Clair, sans replay)

Sources