DevLille 2026 : Comment l'IA et le pragmatisme bousculent l'ingénierie logicielle

Oubliez le vibe coding, les réunions non inclusives et les architectures réseau surdimensionnées. Cette semaine, notre équipe a posé ses valises au DevLille 2026. À l'heure où l'IA s'impose non plus comme un simple gadget de divertissement mais comme un véritable outil de production, nous avons passé au crible les conférences les plus marquantes du salon. Voici les enseignements que nous en avons tirés. 

Pourquoi personne n’aime relire ta Pull Request

Maxime CLEMENT

Nous avons tous déjà soupiré devant une Pull Request (PR) interminable. Lors de sa conférence, Maxime CLÉMENT nous rappelle qu'au-delà du partage de connaissances et de la qualité, une PR sert avant tout de documentation. Pourtant, la relecture est souvent douloureuse pour deux raisons majeures :

• Le manque de contexte : Un git diff montre ce qui change, mais jamais pourquoi. 
• Un ordre chaotique : GitHub trie les fichiers par ordre alphabétique, forçant à valider l'utilisation d'un composant avant même d'en découvrir l'implémentation. 

L'objectif est simple : le relecteur ne doit jamais deviner vos intentions. La solution ? Raconter une histoire.

Jusqu’ici je suis plutôt en phase avec le sujet et je m’y reconnais. Alors quelle solution peut régler ces soucis ?

Maxime présente alors la lecture de PR par commit. Chaque commit est comme un chapitre de notre histoire. Il décrit une étape de la PR.

Sauf que durant le développement, c’est difficile d’être linéaire, car on revient souvent sur un code écrit plus tôt car : Mince j’avais oublié de faire ceci, ou : Mince je n’avais pas pensé à ce cas. Alors il est nécessaire de restructurer notre historique git avec : git add -p et git rebase.

En se basant sur la mémoire de travail, l’idéal serait d’avoir seulement 5 à 7 commits pour une PR, et faire ce travail à la main est coûteux en temps.

La solution présentée est alors celle-ci:

Tout développer dans un commit WIP (Work In Progress) puis demander à l’IA de faire ce travail de réorganisation git à notre place. Ici Maxime (Développeur chez Docker) utilisait docker agent, qui lui permettait de run un agent dans son terminal et d’effectuer le travail.

Il est cependant nécessaire d’y ajouter des règles et un cadre pour que l’agent ne puisse pas run n’importe quelle commande pour arriver à ses fins (rm -rf / * 🤡).

Finalement, l’outil qui résout la problématique rapidement c’est l’IA, mais la vraie solution c’est le résultat final produit par l’IA. Définir une structure et une nomenclature de commits afin de créer cette histoire lisible pour nos collègues. Il est aussi toujours applicable de faire des PR aussi courtes que possible et ne pas hésiter à faire un sujet en plusieurs PR. Cela réduit le coût de l’IA, elle ne pas va trier 1000 additions et ne pas avoir des commits trop chargés

Cependant, je pense qu’il est important d’adopter ce style de lecture uniquement si c’est adopté par l’équipe. Car si celle-ci continue de lire le git diff mais jamais vos commits… À quoi bon écrire une histoire qui n’est jamais lue ?

Pourtant, cette vision occulte une vérité fondamentale : un commit est d’abord un outil pour le développeur, avant d’être un support pour les autres. Durant le dev, nos commits sont nos balises de sauvetage pour revenir en arrière si jamais on se perd. Est-il vraiment judicieux de sacrifier ce filet de sécurité au dépend de la relecture ?

La notion de coût en token de l’IA est évidemment également à prendre en compte sur le long terme.

Pourquoi les femmes partent elles de la tech

Vanessa CHODATON

Les nouvelles découvertes, l’économie mondiale, la géopolitique, la législation ; autant de facteurs qui impactent aujourd’hui le monde de la tech. Pour autant, s’il y a bien une chose dont il est agnostique, c’est le genre des personnes qui le compose. 22%. C’est le pourcentage de femmes qui occupent des emplois dans les professions numériques. Ce nombre croissant, porteur d’espoir, est malheureusement corrélé à une plus sombre réalité : 50% d’entre elles partiront avant leur 35 ans. 

“Le bug n'est pas dans le code ! J'ai enfin compris pourquoi 50% des femmes quittent la tech avant 35 ans”, c’est le titre de la conférence de Vanessa CHODATON, ingénieure logicielle depuis 10 ans, approchant elle-même de cette 35ème bougie. Elle nous propose de revenir sur son parcours afin de comprendre les raisons de cet exode. 

Pour Vanessa Chodaton, l’industrie de la tech souffre du syndrome du seau percé. Nous dépensons une énergie folle à recruter des femmes, à remplir le contenant à grands coups de campagnes de communication et de quotas de diversité. Mais tant que nous ne colmaterons pas les failles structurelles par lesquelles elles s'échappent, l'exode continuera.

La première de ces fuites, c’est notre système de valeurs, gangrené par un dangereux raccourci : confondre la vélocité et la compétence. C’est l’application pure et simple de la loi de Goodhart : à force de mesurer la performance d'un développeur à sa vitesse de livraison ou à son assurance en réunion, la mesure a cessé d'être bonne. On glorifie la posture au détriment de la maîtrise. Celui qui parle fort, qui s'impose avec une confiance absolue, souvent un homme, est présumé compétent. À l’inverse, pour les femmes, c’est trop souvent une présomption d’incompétence qui s'installe. Elles doivent constamment prouver ce que leurs homologues masculins n'ont qu'à affirmer.

À ce biais de posture s'ajoute le poids invisible mais bien présent des biais de genre et d'apparence. Une expertise sans cesse questionnée, des remarques infantilisantes ou de micro-agressions quotidiennes finissent par créer un environnement toxique. Pour Vanessa, la conclusion est simple : la rétention des femmes passe par le leadership.

Colmater le seau, c'est d'abord former les leaders et les managers actuels à instaurer un cadre véritablement safe. Mais c'est aussi, de manière plus systémique, ouvrir grand les portes de ces postes décisionnels aux femmes. C'est précisément au moment où leur carrière devrait décoller que le plafond de verre se transforme en impasse, poussant la moitié d'entre elles à quitter définitivement la tech avant 35 ans.

Face à ce système, Vanessa Chodaton nous invite aussi à une forme de responsabilité personnelle : apprendre à affirmer ses limites et à refuser le jeu de la sur-performance permanente. Douter, prouver, supporter, tous ses efforts supplémentaires s’accumulent, nous rappelant étrangement un concept qui nous est bien familier : la dette psychologique.

Tout comme une dette technique que l’on refuse de rembourser finit par paralyser un projet, accumuler les doutes, devoir prouver sa valeur chaque matin et supporter le poids des biais crée une dette mentale invisible. Jour après jour, la charge augmente, le vase se remplit. Et un jour, souvent à l’approche des 35 ans, le vase déborde. Ce jour-là, ce n'est pas le code qui crash. C'est la professionnelle qui s'en va.

Le bug n’est définitivement pas dans le code, il est dans notre culture du delivery. Il est temps d'ouvrir une pull request sur nos comportements.

ClaudeCode.proTips(20, minutes=20).run()

Erwan Gereec

“20 minutes, 20 astuces. 1 mission : transformer votre manière de travailler avec Claude Code et vous faire gagner en productivité.” Voici le pari mené par Erwan dans cette conférence. Pari plutôt réussi étant donné que je ressors de mon côté avec une liste de commandes que je ne connaissais pas forcément et qui pourrait vous être utile.

Si vous débutez, celles-ci vous seront vite indispensables :

• /init — analyse la codebase et initialise le CLAUDE.md, le point de départ du context engineering
• /powerup — tutoriel interactif qui balaie les possibilités de l'outil
• /clear — réinitialise la fenêtre de contexte sans fermer la session
• /context — affiche précisément l'état de votre fenêtre de contexte

Et pour les habitués, vous connaissez celles-là ?

• /compact — compaction ciblée (on garde l'API développée, on jette les explorations) plutôt que compression aveugle
• /simplify — lance plusieurs agents en parallèle pour simplifier la structure du code
• /effort — ajuste la profondeur de raisonnement du modèle
• /insights — rapport d'analyse de vos sessions pour repérer pertes de temps et optimisations
• /fork & /resume — tester plusieurs implémentations en parallèle sans perdre sa progression

Pourquoi j’ai arrêté de “viber” avec l’IA (et pourquoi vous devriez faire de même)

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

Parmi la multitude de talks, il y en a un qui a particulièrement résonné avec notre quotidien de développeurs: “Le vibe coding est mort, vive le spec coding”, présenté par Aurélien Allienne.

Si vous utilisez ChatGPT, Claude ou Copilot au quotidien, oubliez les promesses magiques: on va voir comment on passe du simple gadget à un vrai outil de production.

Pour bien comprendre, Aurélien a proposé une chronologie super pertinente qui pose le décor. Tout commence en janvier 2025. Andrej Karpathy (l’ancien ponte d’OpenAI et Tesla) lâche un mot qui va devenir viral: le “vibe coding”. L’idée ? On décrit ce qu’on veut en langage naturel, on pose ses pieds sur le bureau, et on laisse l’IA coder. C’est une promesse séduisante, qui fait rapidement le buzz sur les réseaux et suscite un engouement général, et tout le monde veut en être. Le problème ? Dans la vraie vie, en production, ça ne marche pas.

Aurélien a testé cette méthode sur plusieurs projets réels en utilisant Claude Code comme pair-programmer principal sur une stack solide (React, TypeScript, Go, Cloud Run). Son constat est sans appel : chaque fois qu’il a “vibé”, il a payé.

• Hallucinations architecturales
• Refactorings fantômes qui cassent tout.
• Perte totale de contexte dès qu’un fichier dépasse les 300 lignes

La punchline à retenir : L’agent IA ne comprend pas votre projet. Il se contente de prédire la suite de caractères la plus probable.

Alors, on jette l’IA à la poubelle ? Surtout pas. Mais on change de méthode. Ce qui fonctionne, c’est l’inverse exact du feeling: la spécification stricte.

Pour industrialiser son workflow, Aurélien n’a pas cherché un outil magique. Il a découpé sa propre manière de travailler en étapes, et il a construit ces étapes via des agents IA. Sa philosophie m’a d’ailleurs beaucoup marqué : il faut traiter les IA comme de vraies personnes qui sont d'excellents exécutants ; et pour une bonne exécution, il faut des consignes militaires.

Voici la boîte à outils du développeur en 2026 pour dompter l’IA:

• Le PRD (Product Requirement Document) : Pour poser les contours fonctionnels clairs avant la première ligne de code.
• Le DESIGN.md : Le fichier qui encode le design system (couleurs, typo, composants). Sans lui, l’IA réinvente l’identité visuelle à chaque prompt.
• Le CLAUDE.md : La mémoire persistante du projet pour que l’IA sache toujours où elle met les pieds.
• Les slash commands & un justfile : Pour automatiser le build, les tests, le déploiement et industrialiser les tâches répétitives.

Au-delà de la théorie, le talk était brillant dans sa structure. Mais le vrai point fort, c’était la démo en live. Voir le spec programming en action, en temps réel, permet de réaliser que ce n’est pas juste une idée théorique: c’est un workflow redoutablement efficace.

On réalise que le vrai métier de développeur aujourd’hui n’est plus d’aligner des lignes de code. Notre valeur ajoutée c’est d’écrire des specs suffisamment parfaites pour qu’un agent puisse coder à notre place sans se planter.

Que vous utilisiez Claude Code, Cursor ou GitHub Copilot, les principes restent les mêmes. On a tout à gagner à adopter cette rigueur dans nos projets pour maximiser l’usage de nos outils d’IA sans y perdre notre santé mentale (et notre base de code).

IA et bonnes pratiques: Nom de Zeus, on savait déjà tout ! 

Nathan Castelein

Je dois vous avouer que j’attendais cette conférence avec impatience, et je n’ai pas été déçue ! Dès le départ, Nathan fait une entrée fracassante, tout droit sorti de sa DeLorean, débarquant en 2026 après un saut temporel depuis 2024. En le voyant échanger avec son IA préférée sur les “révolutions” du moment (découper les tâches, contextualiser, itérer…), j’ai tout de suite souri : pour lui comme pour nous, ces concepts n’ont absolument rien de neuf. 

Ce qui m’a profondément marquée dans son voyage dans le temps (du DDD jusqu’à une conférence de l’OTAN en 1968), c’est le soulagement que cela procure. Nathan m’a fait réaliser que l’IA ne nous oblige pas à réinventer nos métiers, mais qu’elle nous offre enfin le prétexte parfait pour appliquer rigoureusement les fondamentaux de l’ingénierie logicielle que l’on connaît déjà. 

Entre storytelling ultra-rythmé et humour, j’en suis ressortie avec une vraie prise de conscience : adopter l’IA avec discernement, c’est d’abord transformer nos vieux réflexes méthodologiques en super-pouvoirs d’aujourd’hui, tant pour le code que pour l’humain.

Handicap invisible : et si l’IA nous aidait à rendre nos réunions (enfin) efficaces ?

Anaïs Moulin

La semaine dernière, nous avons eu le plaisir d’assister à la conférence de notre collègue Anaïs, Product Owner, sur un sujet aussi essentiel que discret : l’accessibilité en réunion face au handicap invisible. Loin d’une simple discussion théorique, Anaïs nous a offert un retour d’expérience personnel, pragmatique et rempli d’astuces directement applicables. Et comme souvent dans la tech, l’IA pourrait bien changer la donne.

L’éléphant (invisible) dans la pièce

Anaïs a commencé son talk en partageant son expérience : malentendante d’une oreille, un handicap totalement invisible qui transforme une conversation de groupe en véritable défi. Cette situation est loin d’être isolée. Le saviez-vous ? Selon l’APF France handicap, plus d’une personne sur sept est concernée par un handicap invisible en France.

Statistiquement, cela signifie que dans chaque équipe, dans chaque réunion, une personne a peut-être des difficultés que nous ne soupçonnons pas. En tant que PO, Anaïs passe jusqu’à 80% de son temps en réunion. Elle a identifié quatre obstacles majeurs qui dégradent non seulement l’accessibilité, mais aussi la productivité de tous :

1. Le manque de support visuel : Une information 100% orale est volatile et difficile à assimiler.
2. Le bruit et l’acoustique : L’open-space ou les salles mal insonorisées forcent à un effort de concentration épuisant.
3. La perte de contexte : En hybride, qui n’a jamais perdu le fil d’une discussion sans support textuel pour se raccrocher ?
4. La prise de parole non-inclusive : Quand le format ne permet pas à tout le monde de s’exprimer sereinement.

Retour aux fondamentaux : les piliers d’une réunion inclusive

Avant même de parler de technologie, Anaïs nous a rappelé quelques règles d’or, pleines de bon sens mais trop souvent oubliées.

1. Préparer (vraiment) ses réunions Fini les 15 premières minutes passées à se demander pourquoi on est là. Chaque invitation se doit d’avoir un titre et un ordre du jour clairs, ainsi que le contexte et les liens vers la documentation (tickets Jira, specs, etc.).

2. Utiliser un support visuel (simple !) Nul besoin d’un PowerPoint de 50 slides. Un partage d’écran du backlog, une démo en direct ou même quelques captures d’écran suffisent à ancrer la discussion dans le concret.

3. Animer la prise de parole avec bienveillance - Parler posément et articuler. - Répéter les questions posées par l’audience pour que tout le monde ait le même niveau d’information. - Multiplier les canaux de participation : fonction “lever la main”, chat, emojis… Chacun peut ainsi contribuer à sa manière.

4. Soigner son équipement Un bon micro et l’activation de la caméra ne sont pas des gadgets. Ils permettent de transmettre et de recevoir des informations non verbales (expressions, lecture labiale) cruciales pour la compréhension.

L’IA : l’accélérateur d’accessibilité que nous attendions

C’est ici que le talk a pris une tournure passionnante pour nous, techies. Comment l’IA peut-elle nous aider à appliquer ces bonnes pratiques sans effort ?

1. Sous-titres et transcription en temps réel Les outils comme Teams ou Google Meet le font déjà très bien. Les sous-titres automatiques permettent de surmonter la fatigue auditive, de suivre dans un environnement bruyant ou de ne pas perdre une miette d’une phrase complexe. Mieux encore, la transcription intégrale libère tout le monde de la prise de notes et garantit une trace écrite fidèle.

2. Préparation et synthèse de contenu Des outils comme NotebookLM peuvent ingérer des documentations projet volumineuses et en extraire des résumés ou des points clés. Idéal pour préparer un ordre du jour pertinent ou pour qu’un participant puisse rattraper son retard.

3. Aide à la rédaction de comptes-rendus La tâche la plus redoutée devient un jeu d’enfant. En fournissant la transcription à un assistant comme Claude ou Gemini, on peut obtenir en quelques secondes un compte-rendu clair, structuré, avec un plan d’action et les prochaines étapes.

Ce que nous retenons : un bénéfice pour tous

L’enseignement principal de la conférence d’Anaïs est puissant : en cherchant à rendre une réunion plus accessible, on la rend plus claire, plus structurée et donc plus productive pour chaque participant.

Les pratiques d’accessibilité ne bénéficient pas qu’aux personnes en situation de handicap. Elles profitent au collègue qui travaille dans un open-space bruyant, à celui dont la connexion internet est instable, ou tout simplement à toute personne qui apprécie des échanges clairs et efficaces.

L’IA, en automatisant les tâches les plus fastidieuses (prise de notes, rédaction de CR), ne fait pas que renforcer l’accessibilité ; elle nous redonne du temps pour nous concentrer sur l’essentiel : l’échange et la collaboration.

Un grand merci à Anaïs pour ce partage d’expérience authentique et inspirant, qui nous rappelle que la technologie est avant tout un formidable outil au service de l’humain.

Et si on arrêtait de "récupérer" des données ? La révolution Local-First au DevLille 2026

Benjamin Legrand

Parmi la multitude de talks passionnants, il y en a un qui propose un véritable séisme méthodologique pour notre quotidien de développeurs web : “Et si on arrêtait de 'récupérer' des données ? et qu'on les synchronisait plutôt”, présenté par un intervenant de chez Onepoint Nantes.

Si vous utilisez des architectures classiques client-serveur et que vous en avez marre de jongler avec des promesses asynchrones, des states complexes et des éternels spinners de chargement, ce talk apporte des réponses concrètes. On va voir comment passer de la traditionnelle requête d'API à la révolution du Local-First et des moteurs de synchronisation

Le problème : L'architecture web traditionnelle est à bout de souffle

Pour bien comprendre, l'orateur a rappelé une vérité douloureuse. Quand on démarre un projet, on fait "comme d'habitude" : un client front (SPA en React, Angular, Svelte ou Vue) interroge un serveur distant (via REST ou GraphQL) qui lui-même tape dans une base de données hébergée dans le cloud.

Mais dans la vraie vie, ce modèle traditionnel se heurte à trois murs invisibles :

1. La latence réseau : Notre cerveau perçoit la lenteur dès 300 millisecondes. Or, faire voyager un paquet de données entre chez nous et un serveur situé en Californie prend facilement 150 ms. Ajoutez à cela les pertes de paquets ou les connexions mobiles instables, et l'expérience s'effondre.
2. Le manque de résilience : Débranchez votre Wi-Fi ou entrez dans un tunnel, et votre application web favorite se fige ou crash instantanément.
3. La complexité infernale du code front-end : Pour compenser ces faiblesses réseau, les développeurs passent 80 % de leur temps à gérer manuellement de multiples états d'asynchronisme (`isLoading`, `isError`, `data`), à coder des squelettes d'interfaces et des spinners pour faire patienter l'utilisateur, ou à tenter désespérément de synchroniser plusieurs onglets ouverts sur la même session. 

La solution : Le paradigme "Local-First"

Plutôt que d'aller chercher la donnée à l'autre bout du monde à chaque clic, l'approche Local-First propose l'exact inverse : considérer la base de données locale installée sur l'appareil de l'utilisateur comme la source de vérité principale. 

Pour transformer l'expérience utilisateur, cette philosophie s'appuie sur quatre piliers essentiels au quotidien :

• Zéro barre de chargement : L'interface lit et écrit directement dans la base locale. C'est instantané.
• Le réseau devient optionnel : L'application reste pleinement fonctionnelle en mode hors-ligne.
• Travail multi-appareils : Les données de l'utilisateur se synchronisent de manière transparente sur tous ses écrans.
• Collaboration en temps réel : Plusieurs personnes peuvent éditer les mêmes documents sans blocages ni redoutables erreurs “409 Conflict”.

La boîte à outils du développeur moderne pour dompter la synchronisation

Mettre en œuvre une telle architecture en 2026 n'a plus rien d'une utopie théorique. L'orateur nous a dévoilé les briques technologiques qui rendent ce workflow redoutablement efficace :

• La base de données dans le navigateur : Grâce à WebAssembly (WASM), on peut aujourd'hui faire tourner de vrais moteurs de bases de données ultra-rapides directement chez le client, comme SQLite WASM ou PG-lite (une version légère de PostgreSQL).
• Les Live Queries : Via des outils comme ElectricSQL, Dexie ou Zero, l'interface utilisateur s'abonne à la base locale. Dès qu'une donnée change en base, l'IHM se met à jour automatiquement. La base de données locale devient l'état (le state) de l'application !
• Le moteur de synchronisation : Ce composant s'installe en tâche de fond (via des Web Workers pour ne pas bloquer l'interface et des Service Workers pour la mise en cache offline). Son rôle ? S'occuper du transport et s'assurer que la base locale et le serveur central fusionnent leurs modifications dès que le réseau est disponible.
• Les CRDTs (Conflict-free Replicated Data Types) : C'est la formule mathématique magique derrière la collaboration temps réel (comme sur Figma, Trello ou Linear). À l'instar de Git qui fusionne des branches de code, les librairies comme Y.js permettent de fusionner des données modifiées de façon indépendante et d'aboutir à un état final identique, de manière totalement automatique, déterministe et sans conflit.

// Un avant-goût de simplicité : adieu fetch, bonjour la réactivité !

const list = useQuery(
  db.select().from('albums').where(artists.genre.eq('Rock'))
);
return (
  <ul>
    {list.map(album => <li key={album.id}>{album.title}</li>)}
  </ul>
);

Ce n'est pas une balle en argent (Silver Bullet)

Pragmatique, le talk a bien mis en évidence qu'il ne faut pas appliquer cette architecture à l'aveugle. 

• Quand foncer ? C'est la solution rêvée pour les outils collaboratifs, l'édition de documents, les applications de productivité, la gestion de données personnelles (calendriers, budgets) ou encore les back-offices complexes contenant de longs formulaires d'édition.
• Quand l'éviter ? Pour tout ce qui touche à l'e-commerce, aux systèmes de paiement ou aux applications bancaires, où une autorité centrale forte et une validation serveur immédiate restent indispensables.

De plus, ce modèle déplace une grande partie de la logique métier côté client et redéfinit la sécurité (qui s'applique désormais au niveau des règles de synchronisation plutôt que sur des routes d'API classiques).

Que retenir ?

Le vrai métier de développeur évolue. En adoptant le Local-First, nous simplifions radicalement notre code front-end en éliminant la complexité de l'asynchrone réseau pour le déléguer à des moteurs robustes. Notre valeur ajoutée se déplace vers la modélisation de données résilientes et réactives.

L'écosystème mûrit à toute vitesse et se structure. Que vous construisiez un prototype ultra-rapide en local avant de penser à votre infrastructure, ou que vous cherchiez à offrir une expérience "instant-feel" à vos utilisateurs, le Local-First n'est plus le futur du développement web : c'est déjà notre présent.

IA et Legacy : Comment reprendre le contrôle d’un projet grâce à des agents spécialisés

Jordan NOURRY et Benjamin Lacroix (Shodo)

Ce projet legacy. Vous savez, celui que personne ne veut toucher. Celui où chaque commit est une prière et où l’on vous dit : « Surtout, ne casse rien, mais ajoute-moi cette feature pour demain. » Le rêve ? Tout jeter et repartir de zéro. La réalité ? On doit faire avec. Stabiliser, et vite.

À travers un retour d’expérience pragmatique, deux développeurs nous ont partagé leur journal de bord pour s’attaquer à une application musicale devenue trop complexe pour évoluer. Loin du discours marketing, ils nous ont montré comment utiliser une suite d’agents IA pour transformer une corvée en un défi technique maîtrisé.

La Stratégie : Une équipe d’agents IA spécialisés

L’objectif n’est pas de remplacer le développeur, mais de l’augmenter. Pour cela, l’équipe a décomposé le problème en 4 grandes phases, chacune pilotée par un agent expert.

Phase 1 : La “Discovery” pour cartographier l’inconnu

Avant de toucher à quoi que ce soit, il faut comprendre. Un agent “analyste” a été déployé pour réaliser une cartographie complète du projet. En analysant la base de code sous le prisme du Domain-Driven Design (DDD), il a pu extraire la logique métier, identifier les incohérences de vocabulaire (ubiquitous language) et reconstituer les parcours utilisateurs en naviguant de manière autonome dans l’interface. En parallèle, il a analysé la dette technique, identifiant les dépendances à risque et les versions obsolètes. Selon les intervenants, ce travail a été réalisé 4 à 5 fois plus vite qu’une approche manuelle.

Phase 2 : Co-construction de la cible avec un “Agent Architecte”

Une fois l’existant cartographié, un “agent architecte” a agi en “sparring partner” avec les développeurs pour définir la stratégie de migration. Nourri des rapports de la phase de discovery, il a challengé l’équipe avec des questions pertinentes (« Le SEO est-il important ? »), proposé des hypothèses de migration (comme le Strangler Fig Pattern) et aidé à produire une feuille de route claire, orientée vers la livraison de parcours utilisateurs complets.

Phase 3 : Implémentation assistée par un “Agent Développeur”

Le plan d’architecture, encore abstrait, a été confié à un “agent développeur Full-Stack”. Sa première mission fut de décomposer le backlog en tâches actionnables : création de composants d’interface, tâches CSS, etc. Ensuite, il a pris en charge la génération du code pour chaque story, en réutilisant les composants et le design system mis à sa disposition, assurant ainsi une cohérence technique.

Phase 4 : Évaluation continue par “l’Alligator”

C’est la clé de voûte du système. Pour garantir la qualité et contrôler la nature probabiliste de l’IA, un agent “évaluateur” (surnommé “l’Alligator”) a été mis en place. Après chaque génération de code, il compare un screenshot de l’ancienne et de la nouvelle version via des tests de non-régression visuelle (pixel perfect). Le rapport de “diff” visuel est immédiatement transmis à l’agent développeur, qui peut corriger les écarts en une seule itération. Cette boucle de feedback rapide allie la puissance de l’IA à la rigueur des tests déterministes.

Les points clés à retenir

• L’IA comme amplificateur : Elle prend en charge les tâches chronophages pour que les humains se concentrent sur la stratégie.
• La spécialisation des agents : Des agents experts dans un domaine sont plus efficaces qu’un agent généraliste.
• La co-construction est essentielle : L’IA propose, l’humain valide, oriente et décide.
• La boucle d’évaluation est fondamentale : L’intégration de tests déterministes est indispensable pour garantir la qualité.
• Un gain de temps significatif : La phase d’analyse et de planification a été réalisée en environ un sprint et demi.

Conclusion

Ce retour d’expérience montre une voie pragmatique pour moderniser le legacy. Il ne s’agit pas de laisser les clés à une boîte noire, mais de se construire une panoplie d’outils intelligents et spécialisés. En les orchestrant, on peut non seulement reprendre le contrôle de bases de code complexes, mais aussi y prendre plaisir. Une nouvelle forme d’ingénierie logicielle, collaborative et augmentée, est en train de naître.

Agent-First : la révolution qui redéfinit le développement front-end

Johnathan Meunier et Julien Gaudet

Le développement web a toujours été guidé par un principe simple : concevoir pour l’utilisateur. Mais que se passe-t-il lorsque cet utilisateur est un agent IA ? C’est la question provocatrice posée lors de la conférence “Concevons-nous toujours des applications pour les humains ?”.

Nous assistons à l’émergence d’une nouvelle catégorie d’utilisateurs. Oubliez le Mobile-First, le prochain virage de notre industrie est l’approche “Agent-First”.

L’accessibilité (a11y) : socle technique de l’IA

Pendant des années, l’accessibilité a été perçue comme une contrainte réglementaire. Demain, elle sera la condition sine qua non pour exister sur le web.

Un agent IA navigue sur une page comme un lecteur d’écran : il se fie à la structure sémantique du DOM. L’exemple de la réservation de sièges de cinéma présenté lors de la conférence est sans appel : enrichir ses éléments de balises aria-label permet à un agent IA de réserver une place de manière quasi instantanée et pertinente, là où il naviguait à tâtons sur une interface classique.

Les API sont-elles le nouveau front-end ?

Scraper le DOM a ses limites. L’optimisation ultime passe par des protocoles comme le MCP (Model Context Protocol). L’idée ? Fournir une API standardisée qui expose les fonctionnalités d’un service directement aux agents de l’OS (comme OpenClaw ou Gemini Spark), sans passer par l’interface visuelle.

L’interface graphique traditionnelle ne disparaît pas, mais elle devient optionnelle. Le “produit” brut, c’est l’API.

“Agentic Engineering” : le développeur comme chef d’orchestre

Cette transition transforme radicalement nos métiers. Nous glissons vers l’Agentic Engineering, où le rôle du développeur n’est plus d’écrire du code ligne par ligne, mais d’orchestrer une équipe d’agents IA spécialisés (PM, Dev, Testeur, Ops).

C’est l’occasion de réaliser une vérité assez amusante partagée par l’intervenant : au fond, les Product Owners ont toujours été les premiers à “vibe-coder” ! Ils décrivent un besoin, testent le résultat sans lire une ligne de code, et relancent la boucle de feedback. Aujourd’hui, avec des outils comme Claude Code ou Copilot, le développeur adopte une posture similaire en pilotant ses agents.

Cette vélocité inédite pourrait bien libérer l’agilité de ses rituels parfois trop rigides, pour nous recentrer sur la valeur : challenger et définir le besoin client.

Les défis éthiques et systémiques

Déléguer notre autonomie à des machines non déterministes n’est pas anodin. La conférence a alors introduit une autre punchline, tout aussi percutante : nous devons surveiller nos points de non-retour.

• Le point de non-retour doux : c’est la dépendance insidieuse (émotionnelle, financière) que nous développons envers ces outils. Un seuil pernicieux, franchi sans même s’en rendre compte.
• Le point de non-retour dur : c’est le moment, autrefois fictionnel, où l’IA dépasse l’intelligence humaine sur tous les plans (la fameuse “singularité”). Une échéance qui se rapproche à grands pas selon les experts.

Cette perspective ajoute une nouvelle dimension aux enjeux déjà vertigineux : 

• Économiques : Quel modèle pour le web sans publicité visuelle ? Quel impact sur le SEO quand les IA consomment le contenu sans générer de clics ? 
• Énergétiques : L’explosion de la demande de calcul face aux limites écologiques. 
• De confiance : La prolifération de contenus générés par IA qui nous pousse à douter du vrai plutôt qu’à croire au faux.

Notre responsabilité : garder un humain dans la boucle

Le futur du front-end n’est pas de faire disparaître les humains, mais de mieux concevoir pour eux à travers les machines. Pour réussir cette transition : 

1. Faites de l’accessibilité une priorité stratégique. 
2. Pensez vos fonctionnalités pour les agents (via des API/MCP clairs). 
3. Gardez un humain dans la boucle pour contrôler les comportements non voulus des IA.

Notre métier évolue : nous ne concevons plus des interfaces, mais des expériences. Et si votre database était la queue qu'il vous fallait ?

Julien Lampin

C’est souvent la même chose, un PM ouvre un ticket : "On a besoin de traitement asynchrone.", et avant même la fin de la phrase, on écrit "Kafka" ou RabbitMQ en solution. Réflexe conditionné. Stimulus-réponse. Sans question sur le volume, les contraintes d'équipe, la complexité réelle du besoin. 

C'est exactement cette mécanique que Julien Lampin est venu challenger au DevLille. Personnellement j’aime bien la simplicité et j’ai trouvé que ce qu’il disait avait du sens.

Le coût qu'on ne calcule jamais

Kafka est un outil exceptionnel - pour ce pour quoi il a été conçu. Le streaming massif, les millions d'événements par seconde, le fan-out vers des dizaines de consumers. Mais pour orchestrer des jobs métier - envoyer un email transactionnel, générer un PDF, déclencher une notification - c'est souvent un outil surdimensionné par rapport au problème réel.

Et derrière ce sur-dimensionnement, trois problèmes concrets qu'on accepte trop vite.

Le premier : le Dual-Write. On écrit en base de données, puis on publie sur le broker. Deux opérations distinctes. Si la seconde échoue après la première, l'état applicatif est incohérent - et on ne le sait pas forcément au moment où ça arrive. C'est le genre de bug qui dort tranquillement en production et se réveille un dimanche à 3h du matin.

Le deuxième : la charge infra. Un broker, ça se déploie, se configure, se monitore, se scale. C'est une expertise à maintenir, un composant de plus dans le système.

Le troisième, souvent le plus sous-estimé : l'observabilité. Quand une tâche disparaît dans le vide, comment on la retrouve ? Avec quels outils, quel accès, quelle courbe d'apprentissage ? Pour beaucoup d'équipes, la réponse honnête est : difficilement.

Le dogme qu'il fallait déconstruire

"Never use your database as a queue." Cette maxime a une vraie origine. Elle remonte à l'époque du polling naïf : des dizaines de workers qui martelaient la base toutes les secondes, sur des collections mal indexées, créant une charge folle. Dans ce contexte, l'avertissement avait du sens.

Ce contexte est largement dépassé. Mais le dogme, lui, est resté intact.

Ce que le talk propose, ce n'est pas de jeter les brokers à la poubelle. C'est d'arrêter de les déployer par réflexe, sans se demander si le problème à résoudre les justifie vraiment.

Ce que la base de données fait naturellement

Quand on modélise correctement une collection de jobs, plusieurs besoins émergent sans friction.

La priorisation ? Un champ priority et un tri. La déduplication ? Un index unique sur une clé fonctionnelle. Les retries avec backoff ? Un champ nextRetryAt mis à jour après chaque échec. Et pour le Dual-Write : le Transactional Outbox Pattern résout le problème à la racine. On écrit le job dans la même transaction que l'objet métier - MongoDB le supporte depuis la version 4.0 avec les replica sets. Si ça rollback, les deux rollbackent. L'atomicité de la base fait le travail.

L'observabilité, enfin. Tout le monde peut ouvrir MongoDB Compass ou lancer une requête :

db.jobs.aggregate([{ $group: { _id: "$status", count: { $sum: 1 } } }])
db.jobs.find({ status: "failed" }).sort({ updatedAt: -1 })

Les devs, les POs, les ops. Pas besoin d'un outil spécialisé ou d'un accès broker pour comprendre ce qui se passe. C'est une différence concrète quand il faut investiguer un incident à chaud.

Pour éviter que plusieurs workers traitent le même job, MongoDB permet de verrouiller atomiquement un document avec findOneAndUpdate - on filtre sur status: "pending", on passe à "processing" en une seule opération. Pas de race condition. Des bibliothèques comme Agenda.js (Node.js) ont formalisé ces patterns sur MongoDB depuis des années.

Où ça ne marche pas

L'intervenant n'a pas esquivé les limites. Pour du streaming à haute fréquence, du fan-out massif vers de nombreux consumers, ou des volumes de plusieurs millions d'événements par minute - non. La base de données n'est pas le bon outil. La question est de savoir si c'est vraiment votre cas, ou si vous vous préparez pour un futur hypothétique qui n'arrivera peut-être jamais.

Il faut aussi penser à l'archivage. Une collection de jobs qui grossit sans purge devient vite un problème de performance. Ce n'est pas insurmontable, mais ça se gère.

Ce qu'on retient

Le message est finalement simple : avant de déployer une nouvelle brique infra, se demander si l'outil déjà en production peut faire le travail. Souvent, la réponse est oui.

Un job queue en base de données, c'est transactionnel, observable, maîtrisé par toutes les équipes. Sur des projets où le débit asynchrone ne justifie pas un broker dédié, c'est souvent le choix le plus robuste. Pas le plus spectaculaire - mais la robustesse et le spectaculaire font rarement bon ménage en production.

Moderniser sans tout reconstruire : La stratégie du Micro-Frontend

Laurine Le NET

Septembre 2025, Laurine commence une nouvelle mission, et elle a hâte, car elle va pouvoir mettre en pratique toute l'expérience qu'elle emmagasine à chaque nouveau projet. En plus c'est du Angular, qui est en pleine renaissance actuellement, grâce aux nouveautés fraîchement sorties qui n'ont rien à envier à Vue et React. À elle les Signals, la nouvelle syntaxe, et Vite ! Elle démarre le projet, commence son exploration des fichiers, et là, stupeur ! Dans un dossier qui semblait caché, elle découvre des fichiers avec une syntaxe étrange.

« Ah oui oups, en fait notre application n'est pas tout en Angular, il y a de l'AngularJS également, c'est une application hybride... on a de vieilles librairies parce qu'il faut qu'elles soient compatibles avec AngularJS et le nouvel Angular, ... et on est coincés en Angular 15 parce qu'on a de vieilles librairies qu'on n'arrive pas à migrer. ».

Ce genre d'histoire, Laurine l'a vécu, on l'a vécu et on le vivra encore. Lors de cette conférence Laurine nous a partagé son cheminement, ses différents POCs et toutes les solutions qu'elle a dû déterrer pour faire cohabiter ces deux applications distinctes. Le fil conducteur ? Le Micro-Frontend, une architecture où chaque service front vit, s'exécute et communique de manière totalement autonome.

A travers les avantages et inconvénients, Laurine nous dresse un véritable arbre de décisions pour choisir la bonne architecture :

Avant le Micro-Frontend

• Solution : iframes ou Packages NPM agrégés
• Fonctionnement : Intégration via balise HTML standard ou dépendances partagées au build
• Avantages : Solution historique, simple au début
• Compromis / Inconvénients : Mauvaise UX, builds interminables et conflits de dépendances

2 Apps Angular

• Solution : Native Federation (ou Module Federation 2.0)
• Fonctionnement : Partage de bundle au runtime
• Avantages : Intégration routeur native
• Compromis / Inconvénients : Versions Angular strictes

2 Apps React

• Solution : Vite Module Federation (ou Module Federation)
• Fonctionnement : Partage de bundle au runtime
• Avantages : Adapté au build rapide de Vite
• Compromis / Inconvénients : Rigueur sur les versions de React

2 technos différentes (Sans pages partagées) - Via Gateway

• Solution : Gateway de routage
• Fonctionnement : Routage géré par l'infrastructure
• Avantages : Isolation totale (zéro conflit)
• Compromis / Inconvénients : Rechargement complet de la page

2 technos différentes (Sans pages partagées) - Via Single-SPA

• Solution : Single-SPA
• Fonctionnement : Chef d'orchestre dans le DOM
• Avantages : Switch d'app fluide via l'URL
• Compromis / Inconvénients : Cycle de vie des apps à adapter

2 technos différentes (Avec pages partagées) - Via Web Components

• Solution : Web Components
• Fonctionnement : Encapsulation dans une balise HTML
• Avantages : Injection simple et isolée
• Compromis / Inconvénients : Risque de collision des styles

2 technos différentes (Avec pages partagées) - Via Single-SPA

• Solution : Single-SPA (via Parcels)
• Fonctionnement : Encapsulation dans un objet standardisé exposant son cycle de vie
• Avantages : Flexibilité fine sur la page
• Compromis / Inconvénients : Setup lourd

A la fin, nous avons une vision éclairée sur les solutions actuelles à notre disposition et les compromis nécessaires pour chaque architecture. Laurine de son coté à choisi Single SPA, et vous ? Serez vous le prochain, au Daily, à négocier pour mettre du Vue 3 dans du React ?

Le mot de la fin : De l'exécutant à l'orchestrateur

En refermant les portes de ce DevLille 2026, une certitude s'impose : le rôle du développeur traverse une profonde période de mutation. Qu'il s'agisse de dompter l'IA par le spec coding, de moderniser du legacy avec des agents spécialisés, de simplifier nos infrastructures grâce aux bases de données locales (Local-First), ou de s'attaquer enfin à la dette psychologique qui pèse sur la diversité de nos équipes, la tendance n'est plus à la sur-complexification technique.

La tech de 2026 signe le grand retour aux fondamentaux de l'ingénierie logicielle : la rigueur de la conception, la clarté de la communication et l'accessibilité. Notre valeur ajoutée ne réside plus dans l'écriture mécanique de lignes de code, mais dans notre capacité à orchestrer des outils intelligents et à concevoir des expériences robustes pour les humains (et pour les machines).

Et vous, par quoi allez-vous commencer ? Partagez vos impressions en commentaires !