Aller au contenu

DevLille retour sur l'édition 2026

2 jours de conférences dans le nord, DevLille c'est l'occasion de croiser des speaker de talent et d'assister à plusieurs talks de qualité. Retour sur l'édition de 2026.

Logo du devLille pour l'édition 2026
Le logo du devLille

Qu'est-ce que le DevLille ? 

Le DevLille, anciennement Devfest Lille, est un événement tech communautaire dédié à la communauté lilloise. Historiquement, l'événement était organisé dans un programme Google de grande envergure et présent un peu partout à travers le monde. Aujourd'hui, le groupe organisationnel a voulu s'émanciper de ce programme pour organiser un événement local avec des valeurs fortes environnementales, d'accessibilité et d'échange.

Le DevLille est une occasion unique de partager et d'échanger autour des technologies web, cloud, sécurité et bien d'autres thématiques pendant 2 jours.

Cette année, nous sommes 4 sfeirians à y être présents comme speakers, et voici notre retour sur cette édition.

Jour 1

Keynote d'ouverture : Éloge de la simplicité par Frédéric Leguédois

Frédéric sur la scène du devLille 2026

Ce talk défend une vision de l’agilité fondée sur l’adaptation plutôt que sur la prédiction. Frédéric critique les organisations qui consacrent une énergie considérable à produire des plannings, des estimations et des prévisions alors que, dans le développement logiciel, l’avenir reste largement imprévisible.

Selon lui, la priorité ne devrait pas être de prévoir ce qui sera fait dans plusieurs mois, mais d’améliorer en continu le produit.
Pour savoir quoi développer, il suffit d’échanger avec les utilisateurs afin d’identifier leurs problèmes les plus importants et de les traiter en priorité.

La solution proposée repose sur des itérations courtes, des solutions simples et des retours fréquents des utilisateurs.
L’agilité n’est donc pas une nouvelle façon de planifier, mais un changement de paradigme : accepter l’incertitude, apprendre en agissant et placer l’empathie envers les utilisateurs au cœur des décisions.

À l'origine, l'agilité, c'était plus de simplicité, plus de légèreté, moins de bureaucratie, des échanges directs entre les développeurs et les utilisateurs.

Failure MUST be an option par Olivier Breda

Dans ce talk, Olivier Breda explique que toutes les erreurs ne se valent pas. Certaines sont évitables et doivent être corrigées, mais d’autres sont au contraire indispensables pour apprendre, innover et progresser. Dans des environnements complexes comme le développement logiciel, l’objectif ne doit pas être de supprimer toute erreur, mais de comprendre leur nature et d’en tirer des enseignements.

Il insiste également sur l’importance de la sécurité psychologique au sein des équipes. Lorsque les collaborateurs peuvent signaler leurs erreurs, leurs difficultés ou leurs inquiétudes sans craindre d’être blâmés, les problèmes deviennent visibles plus tôt et peuvent être traités avant de dégénérer. À l’inverse, une culture de la peur pousse les équipes à masquer les difficultés jusqu’au moment où il est trop tard.

Le message central est qu’une organisation performante ne cherche pas des coupables, mais favorise l’apprentissage continu. En analysant les échecs, en encourageant l’expérimentation et en créant un climat de confiance, les équipes deviennent plus résilientes, plus innovantes et mieux armées pour faire face à l’incertitude.

Peu importe votre niveau d'expérience, peu importe votre niveau de compétence, il y a des choses comme ça qui arrivent et qui malheureusement vont pas toujours bien marcher.

Le vibe coding est mort, vive le spec coding par Aurélien Allienne

Ce talk remet en question le vibe coding, popularisé par un tweet d'Andrej Karpathy, qui consiste à laisser l'IA générer du code sans réellement le relire ni le comprendre. Aurélien montre que cette approche, acceptable pour un projet personnel ou un prototype, devient dangereuse en production : baisse de la qualité du code, multiplication des duplications, failles de sécurité, hallucinations des modèles et sentiment de productivité souvent démenti par les études.

Plutôt que d'abandonner l'IA, Aurélien propose un changement de paradigme : passer du vibe coding au spec coding. L'idée est de faire des spécifications la véritable source de vérité du projet. En structurant le travail autour d'un PRD, de règles non négociables, d'étapes explicites et d'une documentation vivante, l'IA devient un assistant capable de produire du code de qualité tout en restant sous le contrôle du développeur. Il illustre cette approche avec son propre workflow et un plugin inspiré des méthodes Spec Kit, BMAD et Compound Engineering.

La conclusion est sans appel : le vibe coding a vocation à disparaître dans les projets professionnels au profit d'une collaboration plus rigoureuse entre l'humain et l'IA. Pour Aurélien, l'avenir du développement ne repose plus sur le code comme artefact principal, mais sur des spécifications versionnées, enrichies au fil du temps et utilisées pour guider les agents d'IA. L'objectif n'est pas de remplacer les développeurs, mais de leur permettre de garder la maîtrise des décisions tout en tirant parti de la puissance des modèles.

Le vibe coding est mort. Il y a le spec coding qui arrive.

IA11Y : L’accessibilité à l’ère de l’IA par Pierre Leclaire

Ce talk présente les relations entre l'intelligence artificielle et l'accessibilité du web. Pierre montre que les personnes en situation de handicap sont parmi les utilisateurs les plus actifs des outils d'IA, qui leur permettent de contourner de nombreuses barrières d'accès à l'information. Mais cette dépendance soulève aussi des limites importantes : hallucinations, biais, difficulté à vérifier les réponses et confiance parfois excessive accordée aux modèles.

À travers une démonstration, Pierre compare plusieurs sites web générés par IA avec différents niveaux de guidage. Plus les modèles disposent de documentation spécialisée et de contraintes d'accessibilité, meilleurs sont les résultats. Pourtant, même dans les meilleures conditions, les erreurs persistent : l'IA reproduit les mauvaises pratiques présentes sur le web et reste incapable de remplacer les tests réalisés avec de vrais utilisateurs en situation de handicap.

La conclusion est claire : l'IA est un formidable outil d'assistance, mais elle ne remplacera ni les développeurs ni les experts en accessibilité. Pour produire des applications réellement inclusives, il est indispensable de former les équipes, d'intégrer les bonnes pratiques dès la conception et de conserver une validation humaine.

L'IA est un supplément puissant, jamais un substitut.

Jour 2

Notre IA et nous contre le legacy : REX d'une reprise de contrôle assistée par Jordan NOURRY et Benjamin Lacroix

Dans ce talk, Jordan et Benjamin montrent que l’IA ne permet pas de moderniser un logiciel legacy simplement en lui demandant de « tout refaire ». Une approche naïve produit rapidement quelque chose qui ressemble à l’application d’origine, mais sans garantie sur les comportements, la qualité, les coûts ou même la compréhension du métier.
L’illusion du « one prompt, one application » se heurte vite à la complexité réelle des systèmes existants.

Ils défendent au contraire une approche d’ingénierie assistée par l’IA. Les agents sont utilisés pour analyser le fonctionnel, comprendre l’architecture, identifier les zones complexes, documenter le système et construire une stratégie de migration progressive.
L’IA accélère considérablement les phases de découverte et de planification, mais elle reste guidée par des pratiques éprouvées comme le DDD, les tests, le découpage en backlog et les migrations incrémentales.

Le message principal est que l’IA ne remplace pas l’ingénieur logiciel : elle amplifie ses capacités. Les projets de remédiation legacy réussis restent fondés sur la compréhension du métier, la maîtrise de la complexité et la validation continue des résultats.
La différence ne se fait pas par la génération automatique de code, mais par la capacité à combiner expertise humaine, méthodes de développement et agents IA spécialisés.

L’objectif, c’est de ne pas du tout s’oublier et de rester sur nos pratiques de software engineer, juste assistées par l’IA.

Déchaînez le Chaos : Tester la Résilience de Votre Application avec Chaos Monkey par Erwan Le Tutour

Les systèmes modernes sont de plus en plus complexes, distribués et imprévisibles. Face à cette réalité, une question se pose : comment s’assurer que votre application peut survivre à l’inattendu ?

C’est là qu’intervient le Chaos Engineering, une discipline qui consiste à introduire volontairement des perturbations pour tester la robustesse et la résilience des systèmes avant qu’un incident réel ne survienne.

Dans ce talk, nous explorerons comment Chaos Monkey for Spring Boot permet de simuler des comportements inattendus au sein de votre application Spring Boot .

Le chaos trouve toujours un chemin.

@Transactional : Facile à utiliser, difficile à maîtriser par Benoît Martin

Ce quicky permet de comprendre qu'une transaction spring peut/doit être configurée dans des cas spécifiques et complexes notamment avec les paramètres propagation et isolation.

La propagation permet de définir le comportement de la transaction lors d'un appel d'une méthode à une autre méthode.

Le paramètre d'isolation permet de gérer des transactions effectuées en parallèle et d'indiquer si les modifications des autres transactions sont visibles ou non par la transaction en cours.

ClaudeCode.proTips(20, minutes=20).run() par Erwan Gereec

Le titre de ce quicky promet 20 conseils en 20 minutes, soit un conseil par minute. Cette promesse est tenue avec des tips sur l'installation, la configuration, l'utilisation de certaines commandes ...

On y apprend que pour bénéficier des mises à jours quotidiennes de Claude Code automatiquement, il faut utiliser l'installeur natif d'Anthropic.

Erwan aide un utilisateur débutant à maîtriser Claude code avec la gestion du contexte

Dernier