DevFest Perros-Guirec 2025
Thème : Mieux développer : quels outils et pratiques pour créer du logiciel de qualité ?
Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de octobre 2025 →
Une journée mono-track sur la qualité logicielle vue comme une affaire de sens et de pragmatisme : nommer, modulariser, typer, rendre accessible et observable, avec en fil rouge l'idée que l'IA ne dispense pas des développeurs qui savent ce qu'est un bon code.
10 sessions résumées · 10 vidéos · mise à jour le mardi 29 septembre 2026 · synthèse à compléter
Sources lues et limites de cette synthèse
Corpus : Programme officiel (site Code d'Armor, Conference Hall), transcripts automatiques des 10 vidéos de la playlist officielle publiée le 14 décembre 2025 (mot d'introduction, 8 talks, présentation du challenge Ada Lovelace), deux articles Medium du speaker Pierrick Blons repérés sur son sujet. Huit recherches web menées en septembre 2026, soit un an après l'événement.
Limites : Aucun retour de participant n'a été trouvé : les résumés disent ce qui a été dit sur scène, pas ce que la salle en a retenu. Les transcripts sont des sous-titres automatiques (noms propres parfois déformés), et les chiffres cités par les speakers n'ont pas été vérifiés. Le mot de clôture n'a pas été filmé.
Synthèse globale
1. La qualité comme affaire de sens, pas de dogme
Le thème « Mieux développer » a été traité moins comme un catalogue de bonnes pratiques que comme une recherche de sens. Stéphane Prohaszka (Ledger) résume la dette à des modules qui ne savent plus dire à quoi ils servent ; Pierrick Blons (Payfit) veut que le langage métier, aligné en event storming, se lise dans les types ; Frédéric Bouchery (CCM Benchmark) juge un code d'abord à ce qu'il dit faire, puis à ce qu'il fait vraiment. Trois talks, trois échelles (architecture, modèle, ligne de code), une même idée : un code de qualité se comprend sans aller lire ce qu'il y a derrière.
2. Évoluer par petits pas plutôt que tout refaire
La journée a plaidé contre le grand soir. Prohaszka refuse la réécriture from scratch et les PR géantes, et préfère extraire module par module avec des tests posés d'abord autour du code endetté. Cédric Clavier (SII) conseille de partir d'un monolithe propre et stateless, puis de le découper avec le strangler fig si la charge le justifie. Alain Buzacarro (Instinct Pioneer) transpose la même logique au management : des estimations en fourchette qu'on resserre, et de petites expérimentations communes pour sortir des blocages « modèle contre modèle ».
3. L'IA en toile de fond, sans enthousiasme naïf
Aucun talk n'était consacré à l'IA, mais elle revient partout. Buzacarro range « plus besoin de développeurs » parmi les absurdités récurrentes de l'IT. Bouchery raconte une app de quiz générée par agent qui a épuisé ses crédits et accumulé code mort et duplications, avant de conclure qu'on a « encore besoin des développeurs ». Côté accessibilité, Hannah Issermann et Isabelle Chanclou (Orange) jugent l'IA utile pour les alternatives d'images ou les sous-titres, mais jamais sans relecture humaine. À l'écran de Pierrick Blons, Copilot a d'ailleurs tantôt anticipé la démo, tantôt dérapé.
4. Au-delà du code : utilisateurs, production, organisation
Le programme a élargi la qualité à ce qui entoure le code. L'accessibilité est présentée comme une obligation légale durcie en 2025, mais surtout comme un gage de code mieux structuré (Orange). Sébastien Ferrer (OVHcloud) rappelle que la qualité se mesure aussi en production : restaurer le service d'abord, loguer utile, « développez vos applications comme si vous alliez les maintenir, parce que c'est le cas ». Christophe Milon (Eco-Compteur), fondateur du sponsor, décrit l'holacratie comme un « OS » d'organisation fait de rôles transparents. La présentation du challenge Ada Lovelace a rappelé le faible nombre de femmes dans la salle.
5. Tensions et points de débat
Le quick and dirty fait débat. Buzacarro et les speakers d'Orange le rejettent ; Bouchery l'admet au démarrage d'un produit, car des entreprises trop soucieuses de propreté se sont fait doubler. Les questions de la salle ont aussi bousculé les speakers : l'écart de productivité « 10x » opposé au discours collectif de Buzacarro, la keynote jugée trop tournée vers les managers, le goto défendu à partir du noyau Linux face à Bouchery, et la coordination entre équipes, peu abordée par Clavier. Enfin, plusieurs talks ont débordé (Blons a dû accélérer la fin de sa démo, Prohaszka s'en est excusé).
6. Une journée communautaire et les biais du corpus
Ce DevFest mono-track reste une affaire de territoire : association bénévole, 97 propositions de talks, élus et technopole présents à l'ouverture, beaucoup de participants fidèles. Cette synthèse repose uniquement sur les transcripts automatiques des vidéos et sur le programme : aucun retour de participant n'a été trouvé en ligne. Elle dit donc ce qui a été dit sur scène, pas ce que la salle en a retenu.
Actions concrètes citées
- Donner une fourchette plutôt qu'un chiffre quand on estime, pour éviter le biais d'ancrage, et la resserrer à mesure qu'on apprend (Alain Buzacarro).
- Désendetter un code par modularisation progressive, PR après PR, est plus sûr que la réécriture from scratch (Stéphane Prohaszka, Ledger).
- Poser des tests unitaires autour du code endetté avant de le modifier, même si c'est ingrat (Stéphane Prohaszka, citant Michael Feathers).
- Commencer par un monolithe bien découpé et à services stateless ; migrer ensuite vers les microservices avec le pattern strangler fig si le besoin de scalabilité se confirme (Cédric Clavier, SII).
- Utiliser des types « brandés » et des smart constructors en TypeScript pour que le compilateur refuse les états impossibles (Pierrick Blons, Payfit).
- Tester l'accessibilité avec Wave, axe ou HeadingsMap, mais savoir que les outils automatiques ne voient pas tout (tailles en px, info portée par la seule couleur, listes non sémantiques) (Hannah Issermann et Isabelle Chanclou, Orange).
- En incident, restaurer le service d'abord, enquêter ensuite ; loguer avec des champs structurés et envelopper les erreurs pour savoir où elles naissent (Sébastien Ferrer, OVHcloud).
- Préférer WET à DRY : tolérer une duplication, n'abstraire qu'au troisième cas d'usage (Frédéric Bouchery).
- Faire respecter des conventions de nommage par l'analyse statique (ex. une fonction
is/hasdoit renvoyer un booléen dans PHPStan) (Frédéric Bouchery).
Session par session
Vendredi 3 octobre
Session▶ vidéo + transcript
Mot d'introduction
Président de Code d'Armor, Erven Léon — maire de Perros-Guirec, Estelle — Technopole Anticipa
- 5e édition, organisée par l'association bénévole Code d'Armor (valeurs : « apprendre, partager, rencontrer »), avec Eco-Compteur comme sponsor principal et le soutien de partenaires institutionnels.
- Thème « Mieux développer », présenté comme « un thème de revendication presque » ; 97 propositions de talks reçues pour un seul track, sélection équilibrée entre contenu, diversité d'expérience, de genre et de technologies.
- Nouveautés : boutique vendue à prix coûtant, gommettes sur les badges pour lancer les discussions, stickers à collectionner, page LinkedIn de l'association ; vaisselle réutilisable plutôt que jetable.
- Le maire relie l'édition au patrimoine local (palais des congrès brutaliste classé, première association loi 1901 de protection des sites à Ploumanac'h, naissance de la LPO à Perros-Guirec) ; la Technopole Anticipa annonce un CTF ouvert à tous et le concours Solutions for Good.
- Prochaine édition annoncée pour le 2 octobre 2026.
Keynote▶ vidéo + transcript
L'ignorance, ce fléau auquel fait face le tech leader
Alain Buzacarro — Instinct Pioneer
- Keynote d'ouverture, « sans code », présentée comme un témoignage de tech leader : « je suis ignorant et irrationnel » (Kahneman, Dunning-Kruger, Argyris, Tribal Leadership de Dave Logan).
- Cinq absurdités vécues en IT : exiger la précision des estimations (une estimation « par définition, c'est faux », cf. Waltzing with Bears), croire le quick and dirty rentable, les solutions miracles (changer de CRM, conseils de cabinets de stratégie), fantasmer que la GenAI remplacera les développeurs, tout faire en même temps (démonstration par la limite du WIP).
- Pourquoi ça persiste : on apprend peu du passé (Brooks, 1975), on confond complexe et compliqué, le travail tech est invisible et le mindset du développeur, proche du joueur, est incompris (ne jamais l'interrompre).
- Réponses proposées : transparence et vulnérabilité (donner une fourchette plutôt qu'un chiffre, exemple d'un budget annoncé entre 250 000 et 750 000 €), clubs de lecture en comité de direction, coresponsabilité radicale et petites expérimentations communes plutôt que « modèle contre modèle ».
- Lectures conseillées : The Phoenix Project, Accelerate, The Goal, Team Topologies.
- En Q&A, un participant pousse sur les écarts de productivité « 10x » : le speaker les reconnaît et en tire l'absurdité du jour-homme comme unité ; « la vélocité, on l'observe, on la décrète pas ». À un autre qui trouve le talk orienté managers, il répond que le développeur a la responsabilité d'agir sur les estimations.
Conférence▶ vidéo + transcript
Comment transformer une dette technique en opportunité ?
Stéphane Prohaszka — Ledger
- Retour d'expérience d'architecte sur l'extraction des intégrations blockchain (« coin modules ») du code de Ledger Live (TypeScript, Electron et React Native, open source) pour les partager.
- Deux signes de dette : l'équipe ne suit plus les bugs, et on ne peut plus extraire un pan fonctionnel tant il est intriqué ; ici, une dépendance cyclique entre le module de comptes et le « bridge ».
- Méthode : redonner du sens aux modules (inspiration onion et clean architecture), déplacer les fonctions mal placées, extraire la partie générique avec le pattern décorateur pour ne pas changer les signatures, et éviter le big bang (pas de PR à 1 000 fichiers).
- Consolidation : maîtriser les exports du package, TypeScript strict, injection de dépendance d'un « signer » pour découpler la communication avec le device ; tests unitaires posés d'abord autour du code endetté (Michael Feathers), qui ont aidé à diagnostiquer vite une régression.
- Rebondissement : les projets qui motivaient l'extraction ont été abandonnés, mais l'équipe B2B (Ledger Vault), qui avait forké ce code, est devenue l'utilisatrice ; le résultat est une couche qui absorbe l'hétérogénéité des blockchains.
- Conclusion : « désendetter, c'est plus facile et plus sûr que de repartir from scratch » ; si un module a plus d'une réponse à « à quoi sert-il ? », il est déjà trop complexe.
Conférence▶ vidéo + transcript
L'accessibilité numérique : un atout incontournable
Hannah Issermann — Orange, Isabelle Chanclou — Orange
- Un produit est accessible s'il est utilisable par tous, quels que soient les aptitudes, le matériel et le réseau, en autonomie, confidentialité et sécurité ; le handicap est situationnel (chiffres cités : plus de 20 % de la population française vit avec une déficience).
- Cadre légal durci depuis juin 2025 selon les speakers : davantage d'organisations concernées, six organismes de contrôle au lieu d'un, sanctions cumulables ; obligations de schéma pluriannuel, formation, amélioration et déclaration d'accessibilité.
- Démo pas à pas : attribut
lang,titleunique, régions et titres,alt(vide si décoratif), contrastes, tailles en rem pour le zoom texte, masquage accessible (visually-hidden), listes sémantiques,aria-labelsur bouton-icône ; outils Wave, axe, HeadingsMap, WCAG Contrast Checker et lecteur d'écran. - Point clé : plusieurs défauts (px, info portée par la couleur, listes) ne sont pas détectés par les outils automatiques. Les surcouches d'accessibilité vendues comme magiques sont déconseillées.
- Bénéfices revendiqués : inclusion, compétence rare et recherchée, code mieux structuré, SEO, image de marque, moindre coût de maintenance.
- En Q&A sur l'IA : utile pour les alternatives d'images ou les sous-titres, mais jamais sans relecture humaine ; un participant conseille des consignes d'accessibilité dans les fichiers de configuration de son assistant de code. Rappel : « no ARIA is better than bad ARIA ».
Conférence▶ vidéo + transcript
Monolithes vs. Microservices : choisir la bonne architecture pour votre projet
Cédric Clavier — Groupe SII
- Le monolithe promet rapidité et simplicité (un déploiement, transactions simples) mais vieillit mal : dépendances entremêlées, redéploiement et retest de tout, scalabilité grossière.
- Les microservices promettent une scalabilité fine et dynamique, des déploiements fractionnés avec rollback, l'isolation des pannes (« un peu douteuse ») et une innovation facilitée, au prix d'un orchestrateur, d'un broker, d'observabilité, de factures cloud difficiles à prévoir (FinOps) et de cohérence des données à gérer.
- Critères de choix : taille de l'équipe (« beaucoup de temps à écrire du YAML » si on est deux), délai avant mise en prod, diversité des domaines métier (DDD), profils de charge, SLA critiques.
- Mises en garde : les nanoservices, et la confusion entre microservices et cloud.
- Conseil central : un monolithe bien écrit (couches séparées, pas de god objects, services stateless) vit mieux et se découpe ensuite via le strangler fig ; « on peut faire des microservices absolument dégueulasses ».
- En Q&A : le polyglottisme est un atout, mais à doser dans une petite structure ; la coordination entre équipes passe par le versioning d'API.
Lightning talk▶ vidéo + transcript
Holacratie & gouvernance distribuée chez Eco-Compteur
Christophe Milon — Eco-Compteur (Quanteo Group)
- Session inscrite au programme comme « Quicky : découverte d'Eco-Compteur » par le fondateur du sponsor (comptage de piétons et cyclistes, 220 personnes, 55 pays selon le speaker).
- Critique de l'organigramme pyramidal, hérité du militaire : il décrit mal les personnes aux fonctions multiples et toute réorganisation y devient un déplacement de personnes.
- L'holacratie (Brian Robertson), pratiquée depuis près de dix ans : des cercles et des rôles avec raison d'être et redevabilités, visibles de tous dans un logiciel (exemple d'un directeur financier qui tient 46 rôles, dont DPO ou pédagogie financière).
- La gouvernance évolue en réunions codifiées où un facilitateur, distinct du leader de cercle, garantit que chaque proposition va au bout.
- Le plus dur pour le fondateur : s'interdire de se mêler des rôles des autres (« au début, c'était l'enfer ») ; ceux qui naviguaient bien dans le flou sont moins à l'aise dans cette transparence.
- En Q&A : décision et attribution des rôles, charge régulée par le leader de cercle, salariés actionnaires dans le cadre de la transmission de l'entreprise.
Conférence▶ vidéo + transcript
DDD tactique avec TypeScript
Pierrick Blons — Payfit
- Rappel : le DDD est d'abord stratégique (comprendre le bon problème avec les experts métier) avant d'être tactique ; le Blue Book d'Eric Evans peut se lire en commençant par la fin.
- Cas fil rouge : un SaaS de satisfaction client, modélisé en domain storytelling puis en event storming pour aligner le langage qui doit apparaître dans le code.
- Refactoring en live d'un contrôleur NestJS/Prisma défensif : types brandés (un email n'est pas une URI), smart constructors pour les value types (une note entre 1 et 10), découplage du body HTTP.
- Entités et unions discriminées (enquête planifiée, démarrée, terminée) pour que seul un état valide accepte un feedback ; agrégat et repository garants de la cohérence ; domaine pur, séparé de l'infrastructure.
- Message : « faites du compilateur un allié », il donne un feedback plus rapide qu'un test unitaire. La démo a débordé et Copilot a parfois anticipé ou dérapé à l'écran.
- Le speaker renvoie à ses articles Medium sur le sujet (primitives, value types).
Session▶ vidéo + transcript
Présentation du challenge Ada Lovelace
Organisatrices et jury du challenge Ada Lovelace (Orange, ENSSAT)
- Constat posé sur scène : peu de femmes dans la salle, et de moins en moins de lycéennes vers les filières scientifiques et informatiques depuis la réforme du bac.
- Le challenge Ada Lovelace, lancé à Lannion vers 2016 : deux jours où des lycéennes développent un site web après une dizaine d'heures de cours, coachées par des étudiantes de l'IUT et de l'ENSSAT, jugées par des femmes de l'industrie locale.
- Extension à Vannes et Quimper ; les lauréates se voient offrir un stage d'une semaine chez Orange (Arduino, App Inventor), et une ancienne participante, aujourd'hui apprentie ingénieure, témoigne que ça l'a confortée dans son choix.
Conférence▶ vidéo + transcript
Troubleshooting en production : quand chaque incident devient une enquête !
Sébastien Ferrer — OVHcloud
- Récit d'un développeur qui n'avait « jamais touché de prod » en dix ans et rejoint une équipe qui maintient 50 à 60 projets : comment se forger une intuition sur des systèmes qu'on ne connaît pas.
- Le run comme astreinte de jour : morning check très visuel, tri humain des tickets et des priorités (P5 à P1), métriques TTA et time to restore service, et rôle de point de contact de l'équipe.
- Deux approches de root cause analysis : par l'historique (rapide mais trompeuse) et le drill down (rigoureux, formateur). Mais d'abord : restaurer le service, l'enquête peut attendre le lendemain.
- Trois cas vécus : sortir deux pods malades du load balancer à 3 h du matin, relever un rate limiter face à un client trop gourmand, découvrir grâce au champ
pod_idqu'un pod était tombé ; puis post-mortem et 5 Why. - Bonnes pratiques : « développez vos applications comme si vous alliez les maintenir, parce que c'est le cas » ; logs à champs structurés (ni manque ni bruit), alertes Prometheus, error wrapping en Go, packages communs, linter.
Conférence▶ vidéo + transcript
Écrivez-vous du code sale ?
Frédéric Bouchery — CCM Benchmark
- Conférence de clôture, ouverte sur une expérience de vibe coding : une app de quiz générée par agent qui a brûlé ses crédits d'IA, accumulé code mort et duplications, et que le speaker a dû reprendre à la main ; il cite des études (non sourcées sur scène) sur plus de bugs et une maintenabilité dégradée.
- Thèse : « vous êtes votre futur legacy » ; la propreté est relative (langage, époque, équipe) alors que le sale fait davantage consensus, d'où l'idée de le traquer plutôt que de viser un code propre dogmatique.
- Symptômes : un code qui ne fait pas ce qu'il dit (un
fetchqui renvoie void, unexistsqui renvoie une entité), les commentaires qui compensent, les noms courts ou surchargés, les méthodes trop longues (subitisation), les god classes, les paramètresoptions, les booléens à trois états, les négations. - Remèdes : early return, suppression des
else, WET plutôt que DRY, builders, analyse statique (PHPStan) et design testing pour tester l'écriture du code ; attention au code zombie. - Nuance revendiquée : « je préfère un code pas trop sale qui fonctionne qu'un code propre qui fonctionne pas » ; le quick and dirty peut être rationnel au démarrage.
- En Q&A : le goto a des usages légitimes (noyau Linux, code compilé de Symfony) ; l'IA ne remplacera pas les développeurs tant qu'elle ne sait pas maintenir ce qu'elle génère.
Sessions sans retour trouvé (1)
- Mot de clôture (organisateurs, non filmé)
Sources
- Programme officiel (archives Code d'Armor) (nouvel onglet) ↗
- Appel à conférences (Conference Hall) (nouvel onglet) ↗
- Playlist YouTube DevFest Perros-Guirec 2025 (chaîne Code d'Armor) (nouvel onglet) ↗
- Annonce de l'événement (Technopole Anticipa) (nouvel onglet) ↗
- Pierrick Blons, « Primitives: Tactical DDD with TypeScript » (speaker) (nouvel onglet) ↗
- Pierrick Blons, « Value types: Tactical DDD with TypeScript (part 2) » (speaker) (nouvel onglet) ↗
- Blog de Sébastien Ferrer, articles « Run! » et « Be a resilient developer » (speaker) (nouvel onglet) ↗
- Posts LinkedIn : aucun retour participant trouvé (seulement l'annonce de billetterie de Code d'Armor) (nouvel onglet) ↗