DevQuest Niort 2025 : notre sélection des meilleures conférences

Retour sur DevQuest Niort 2025

Les équipes Néosoft ont eu l’occasion de participer au DevQuest Niort les 5 & 6 juin dernier. Pour cette 2ème édition donjons et dragons, « le premier rassemblement des devs Niortais » a tenu toutes ses promesses. 

Vous n’avez pas pu assister au DevQuest Niort 2025 ? Vous ne savez pas par quel replay commencer ? Dans cet article, Romain, Hugo, Mathieu et Carl reviennent sur les conférences qui les ont marqués, partagent leurs enseignements et livrent leurs retours sans filtre. De quoi revivre les meilleurs moments de cette édition…

Keynote | Le bien-être : le nouvel enjeu du software development ?

par Geoffrey Graveaud

Le DevQuest Niort 2025 s’est ouvert avec une keynote particulièrement marquante sur un sujet trop souvent relégué au second plan : le bien-être au travail. Geoffrey Graveaud y a livré une intervention lucide, documentée et engagée, posant une question essentielle : est-ce qu’optimiser le bien-être de ces employés ne serait pas l’une des clés de réussite des entreprises ?

Dès les premières minutes, il s’appuie sur une étude Gallup révélatrice : la France affiche un taux d’engagement au travail parmi les plus faibles d’Europe (seulement 8%), avec trois fois moins de profils moteurs que dans la majorité des pays occidentaux !
Son premier constat : le manque de proximité avec le management. Il pointe du doigt une question qu’il a très peu (surement trop peu) entendu de la part des managers : “De quoi as-tu besoin pour travailler ?”

Autre constat fort : l’environnement professionnel est devenu source de stress sous la pression d’une compétitivité effrénée. À cela s’ajoute l’impact des interruptions incessantes sur la qualité du travail. Ayant moi-même occupé un poste de lead developer pendant deux ans, je l’ai vécu au quotidien : les sollicitations se multiplient, et une tâche d’une heure peut facilement s’étirer à cause de pertes de concentration répétées. Rapporté à des projets sur plusieurs semaines, c’est un gouffre en productivité.

Geoffrey a alors introduit la notion de flow state (“être dans la zone”), cet état de concentration optimale dans lequel l’on est pleinement immergé dans sa tâche. Un état fragile, d’autant plus avec toutes les sollicitations que nous pouvons vivre. Il partage un exemple inspirant : dans l’une des organisations qu’il a accompagnées, les après-midis étaient sanctuarisés – aucune sollicitation ni réunion n’y était permise, afin de préserver la concentration des équipes. Toutes les interactions étaient cantonnées au matin. Un choix organisationnel simple, mais redoutablement efficace.

En 2025, il est étonnant — et en réalité un peu triste — que la recherche du bien-être ne soit toujours pas considérée comme un fondement naturel du travail. Cette keynote nous invite à être les portes parole de ces constats.

Pair et mob programming : ensemble, on va plus loin

par Alan Duchene

Ce talk avait pour objectif de mettre en lumière les bénéfices du pair programming. Alan Duchene a notamment expliqué en quoi cette méthode de travail collaborative peut réellement améliorer la qualité des développements, renforcer la cohésion d’équipe, et faciliter l’intégration des nouveaux membres, tout en apportant des gains de productivité et de compréhension partagée du code.

Le pair programming c’est quoi ?

Le pair programming – ou son extension, le mob programming – consiste à faire travailler deux développeurs ensemble sur une même tâche, souvent devant un seul et même poste de travail. Quant au mob programming, il s’agit d’une déclinaison à plus grande échelle, où trois personnes (ou plus) collaborent simultanément sur le même développement. Cette manière de coder à plusieurs permet de partager en direct les idées, de confronter les points de vue, de prendre des décisions collectivement et de réfléchir ensemble à la meilleure manière de concevoir une fonctionnalité.

Les différentes méthodes de pair programming

Il existe plusieurs modalités de pair programming, chacune ayant ses spécificités. La première, sans doute la plus connue, est celle dite du Driver/Navigator. Dans cette configuration, une personne – le « driver » – est en charge d’écrire le code, tandis que l’autre – le « navigator » – suit l’avancement, propose des améliorations, fait des retours immédiats, et pense à plus haut niveau, ce qui permet un enrichissement mutuel en temps réel. Cette méthode a pour intérêt de court-circuiter le processus de peer-review traditionnel, car une première relecture est déjà intégrée dans le processus.

Une autre variante est le Ping-Pong Programming, qui repose sur une dynamique d’échange plus actif : l’un des deux développeurs travaille sur l’implémentation d’une fonctionnalité, pendant que l’autre conçoit simultanément les tests unitaires associés. Une fois cette première boucle effectuée, les rôles s’inversent.

Enfin, dans un contexte de travail à distance, on peut mettre en œuvre une forme moins structurée de pair programming, souvent qualifiée d’unstructured. Celle-ci repose sur l’usage d’outils comme “Code With Me” de JetBrains, qui permettent à plusieurs développeurs de manipuler un même environnement de développement intégré (IDE) à distance, et donc de travailler simultanément sur le même code.

Les avantages du pair programming

Les bénéfices de ces pratiques sont nombreux :

• Elles permettent une amélioration notable de la qualité du code produit, grâce à une surveillance constante et à une réflexion collective.
• Elles favorisent le partage des connaissances et des bonnes pratiques, réduisant ainsi la dépendance à un unique développeur expert.
• Cela facilite aussi l’intégration des nouveaux arrivants.
• Enfin, ces méthodes renforcent la cohésion d’équipe en instaurant une culture de collaboration et d’écoute.

Mais ces pratiques ne sont pas exemptes de défis. Le premier d’entre eux est la fatigue cognitive. En effet, le fait de devoir être en interaction constante avec d’autres personnes peut entraîner une charge mentale importante. Le second défi concerne les désaccords. Il est inévitable que les opinions divergent lors de ces sessions collaboratives, et il faut alors savoir trancher rapidement. Enfin, le dernier point concerne l’ego. Tout développeur a son propre attachement à son code ou à sa vision, mais il est essentiel de savoir mettre cela de côté lors d’un exercice collaboratif.

Pour mettre en place efficacement ces pratiques, quelques conditions doivent être réunies :

• Définir clairement les objectifs de chaque session,
• Préparer l’environnement de travail,
• Mettre en place des timeboxes, c’est-à-dire des plages horaires délimitées permettant de rythmer les rotations,
• Réaliser des rétrospectives afin de tirer des enseignements, d’identifier les points de friction, et d’améliorer le dispositif.

Adopter le pair ou mob programming peut soulever des réticences, notamment liées au coût, mais les bénéfices sont tangibles. Pour un développeur, c’est une opportunité d’apprentissage accéléré, de déblocage rapide et de partage d’expertise. Pour une équipe, ces pratiques offrent des revues de code en continu, améliorent la qualité et la maintenabilité du code, tout en réduisant significativement le temps passé à débugger. Enfin, pour un manager, l’argument clé reste le coût global optimisé : meilleure qualité, livraisons plus rapides, partage de la connaissance, et une équipe plus résiliente face aux imprévus.

En somme, le pair et le mob programming ne sont pas de simples méthodes de travail, ce sont de véritables leviers pour transformer une équipe de développement, la faire monter en puissance, et instaurer une culture du logiciel de qualité, collaborative et durable.

Je malmène ton LLM en direct avec 10 failles de sécurités

par Gaëtan Eleouet

Dans sa présentation, Gaëtan Eleouet part du principe qu’un LLM (ex : ChatGPT, Mistral, Gemini, etc.) peut comporter des failles de sécurité comme toute autre type d’application.

Pour encadrer ces nouveaux risques, l’OWASP a récemment défini une catégorie spécifique dédiée aux LLM, dans laquelle elle recense les 10 vulnérabilités les plus fréquentes liées à ces modèles. Lors de sa conférence, Gaëtan a donc présenté ces failles à travers une démonstration concrète, conçue spécialement pour l’occasion, en utilisant un agent conversationnel fictif de gestion de bibliothèque nommé — avec humour — “Bibl-AI-thèque”. Cette mise en situation a mis en lumière les risques liés à une mauvaise sécurisation d’un LLM : fuite de données sensibles, abus d’autorisations, manipulation du modèle, ou encore récupération du prompt système.

Gaëtan a également insisté sur le fait que ces vulnérabilités évoluent rapidement, à mesure que l’usage des IA se généralise… comme en témoigne l’exemple récent d’une attaque sur GitLab, exploitant plusieurs de ces failles pour accéder à du code source privé.

Une conférence qui m’a donné envie de vérifier si notre propre IA, NéoGen, est bien conforme aux recommandations de l’OWASP.

L’invasion du HTML mutant

par Gaël Poupard

Sûrement la meilleure conférence que j’ai vue sur les deux jours, j’y suis allé sans grande conviction et finalement c’était très intéressant. Derrière un titre intriguant et une mise en scène originale, Gaël Poupard a su captiver la salle avec une conférence aussi drôle que technique. Le pitch ? Un développeur découvre un matin que son HTML a muté dans son dos, déformé par des scripts tiers et des pratiques douteuses… Une aventure à la fois fictive et tristement familière pour beaucoup.

Pendant 50 minutes, Gaël a mis en lumière les pratiques parfois « exotiques » de certains éditeurs de contenu ou CMS, qui injectent dynamiquement des attributs ou balises peu conventionnelles. Dans ce chaos HTML, MutationObserver devient l’allié du développeur pour regagner le contrôle et contenir l’« invasion ».

Ce mélange d’humour, de mise en scène narrative et de démonstration technique a fait mouche : c’était à la fois clair, fun, et directement actionnable.

Un Pixel, puis un autre : comment faire tourner DOOM sur une liseuse électronique

par Moustapha Agack

Rien que pour le titre, je savais que j’allais passer un bon moment. Dans ce talk, Moustapha Agack va expliquer étape par étape comment il va réussir à faire tourner Doom, ce jeu culte, sur une liseuse Kindle. Selon lui, faire un portage de Doom sur tout et n’importe quoi, fait partie intégrante de la culture internet. Quelques exemples improbables : le portage sur un thermomix, un réfrigérateur connecté ou encore un test de grossesse électronique !

Moustapha c’est un bidouilleur et il a voulu lui aussi porter sa contribution dans le monde des portages Doom. Ainsi il va nous expliquer étape par étape, via une démo live, comment il a réussi ce tour de passe-passe : faire tourner Doom sur une liseuse électronique. Sans connaissance approfondie en C ou en compilation, il a pu s’appuyer sur des ressources en ligne. Il a également partagé ces difficultés avec humour et dérision. Je vous invite a regarder le replay pour 50 minutes de divertissement assuré !

Mon DevQuest Niort 2025

Et parce que nous ne pouvions pas terminer cet article sans la plume enthousiaste de notre développeur tourangeau passionné… Carl nous partage (sans filtre) son retour d’expérience sur cette édition 2025. Entre coups de cœur, moments marquants et réflexions personnelles, il dresse un regard authentique sur l’événement :

Vous ne connaissez pas le S de Solid ! par Julien Libert

Ma très chère Responsable Marketing & Communication va encore me maudire, mais… DevQuest Niort c’est l’occasion de voir les copains, de discuter tech, et de voir des conférences : bref on socialise, on profite, on se forme. Ayant raté la conférence d’introduction pour cause de : les transports en commun c’est bien mais parfois pas top, j’irai droit au but :

“Vous ne connaissez pas le S de Solid ?” regardez le replay de cette présentation et vous saurez !
J’avoue avoir abordé cette conférence avec une certaine appréhension. Bah si j’avais dit et fait des bêtises ? Et bien non ! Le S de Solid, défini puis redéfini par Robert C. Martin (car ce n’est pas figé dans le marbre, ou gravé dans la roche), correspond au principe de responsabilité unique.

Ce principe doit être tourné, non pas tant en termes de code ou de métier, mais bel et bien autour des acteurs métier. Rhaaa des années que je le dis ! Merci Julien Libert de remettre l’église au milieu du village, ou plutôt les méthodes dans les bonnes classes. En d’autres termes, le copier-coller ce n’est pas si sale que ça, on ne factorise pas à outrance, on définit des comportements pour des acteurs : bref, une vraie bouffée d’oxygène.

Vers une Métrique DDD Continue : dépasser les limites de l’Event Storming par Loïc Broquet

Souvent quand j’entends Solid, je pense aussi à Domain Design Development, cela tombe bien “Vers une Métrique DDD Continue : dépasser les limites de l’Event Storming “ va me permettre d’approfondir mes connaissances. Lors de cette conférence, Loïc Broquet va nous présenter une série d’outils, dont un maison, permettant de voir la qualité du code “métier”. L’idée centrale : mesurer la qualité du langage ubiquitaire dans le code, grâce à un outillage basé sur l’AST et un lexique par bounded context. Résultat : un score DDD visualisable, utile pour dialoguer avec les métiers et guider les efforts de conception. Une approche que je compte expérimenter sur ma mission.

Une identité pour les fédérer toutes ! par Sébastien Ferrer

Mon gros gros gros love de cette édition fut : “Une identité pour les fédérer toutes !”. Même si, je dois l’avouer, c’est mon domaine métier (et ma passion), j’y allais pour répondre à une problématique : comment présenter simplement l’identité et fédérations qui vont souvent avec ? Bingo, en quelques minutes Sébastien Ferrer nous fait un rappel historique et technique, en s’appuyant sur SAML pour présenter la chose. Efficace comme un morceau de New York Hard Core, on va à l’essentiel. De l’histoire, des schémas, des explications simples (et c’est le mieux). Je vous invite à regarder et à diffuser le replay.

DevQuest Niort 2025 : à l’année prochaine ?

Vous l’aurez compris, pendant deux jours, nos développeurs ont exploré une multitude de sujets. On a appris, on a débattu, on a ri — parfois même les trois à la fois.

Cette diversité de contenus, l’ambiance conviviale et l’implication sans faille de l’équipe organisatrice font du DevQuest Niort un événement à part, ancré dans son territoire mais tourné vers l’avenir de la tech.

On se dit à l’année prochaine ?