Retour sur le Devoxx 2026

Comme chaque année, plusieurs d’entre nous, chez Néosoft, ont eu la chance d’assister à Devoxx France. Voici un résumé des talks qui m’ont le plus marqué.

Le futur du logiciel libre pour toi, moi et… les IAs

Alex Snaps, maintainer open source de longue date, partage avec nous sa vision sur ce : que l’IA change vraiment pour le logiciel libre. Je suis d’avis que cela s’applique globalement aussi à nos projets de développement en entreprise.

L’état des lieux

Alex nous rappelle d’abord que le logiciel libre repose sur un principe : « scratch your own itch » — on crée d’abord un projet open source pour résoudre son propre problème. Contribuer « parce que c’est cool » n’est pas une bonne raison et les projets initiés pour de « mauvaises raisons » ne font pas long feu.

Les PR sont un contrat social entre les contributors et les maintainers. Elle ne se résume pas à du code : les contributors doivent démontrer leur compréhension du problème. Les PR sont alors des argumentations pour justifier les choix d’implémentation, les compromis acceptés, et pourquoi cette solution mérite d’intégrer le projet. La confiance se construit lentement, mais c’est elle qui fait vivre un projet sur le long terme.

Ce que l’IA perturbe

L’IA promet de supprimer la complexité accidentelle, celle qui vient de nos outils et de nos processus. Mais Alex alerte sur plusieurs dérives déjà observées :

• Il parle de PR creuses : il cite l’exemple d’une PR de 10K LoC, entièrement générée par Claude, dont tous les tests étaient verts… sauf que ceux-ci ne testaient rien.
• L’asymétrie des coûts : le coût d’écriture du code a chuté avec l’IA, mais le coût de relecture reste le même. Résultat : les maintainers sont submergés de PR.
• Le « vibe coding » : on livre de plus en plus vite, mais on n’essaie plus de comprendre ce qu’on livre. Alex compare ça à une forme d’addiction — la dopamine fournie en soumettant des PR fait oublier qu’il faut tout d’abord bien comprendre le contexte du projet.
• Il donne un dernier exemple : le programme de bug bounty est stoppé pour le projet curl, l’IA réussissant à générer des PR faisant croire qu’elle corrigeait des bugs fantômes.

Le problème du dev junior

L’IA peut donner aux juniors l’illusion d’atteindre un niveau d’expertise trop vite. On croit maîtriser un sujet parce que l’outil produit du code qui compile et passe les tests, mais sans avoir traversé la « vallée du désespoir » qui forge la vraie compréhension du code. Le cerveau n’a jamais eu le temps d’apprendre à comprendre.

Ce qui n’a pas changé

Alex conclut par : les valeurs du logiciel libre — transparence, responsabilité, propriété partagée — n’ont pas changé. Le métier de dev non plus : il faut d’abord comprendre le problème, puis proposer des solutions, tout en faisant des compromis et communiquer avec d’autres dev. Ce qui change, c’est qu’il faut être plus rigoureux dans notre usage de l’IA. Même les contributions « creuses » ont souvent une bonne intention à l’origine — c’est à la communauté de savoir guider plutôt que de rejeter l’usage de l’IA.

Explorer un domaine en profondeur grâce aux publications scientifiques

Cyrille Martraire nous a embarqués dans un exercice qu’on fait rarement : lire des papiers académiques pour mieux modéliser nos domaines métier à partir de la littérature scientifique.

Désacraliser la lecture académique

Le secret, nous dit Cyrille, on ne lit pas un papier en entier. Il suffit de lire seulement l’abstract (ou presque), qui contient à lui seul 70% de la valeur — tout y est spoilé.

Pour aller plus loin dans la compréhension, il propose une méthode progressive, lire :

• l’abstract et la bibliographie, pour capter l’idée et les références,
• l’introduction et les related works, le résumé des épisodes précédents, où l’on trouve souvent notre ubiquitous language,
• la conclusion et les discussions, les résultats et limites,
• les méthodes et les expérimentations, uniquement si on a besoin d’aller plus loin.

C’est un Pareto 80/20 : avec les deux premiers points, on a déjà l’essentiel.

Un exemple concret

Cyrille illustre avec un cas métier : la location de vans et l’optimisation tarifaire d’un stock fini. En partant de Wikipedia (yield management) puis en remontant vers les publications, il a trouvé des survey papers qui résument l’état de l’art, identifié des bounded contexts, et découvert plusieurs modèles concurrents — exactement ce que préconise DDD : disposer d’au moins trois modèles avant de choisir.

Le message est pragmatique : les publications scientifiques ne sont pas réservées aux chercheurs. Elles sont une source sous-exploitée pour quiconque cherche à modéliser un domaine complexe.

Éloge de la simplicité

Frédéric Leguédois a livré un talk sans concession et plein d’humour sur ce qui dysfonctionne dans nos organisations « agiles », avec un message central : la simplicité n’est pas un idéal, mais une nécessité opérationnelle.

Le planning comme doudou organisationnel

Le constat est direct : un planning, c’est un amas d’informations inutiles aujourd’hui et faux demain ! C’est un imaginaire qui rassure, un « doudou organisationnel ». Le backlog n’est guère mieux s’il devient une projection du futur plutôt qu’un reflet de ce qu’on doit faire maintenant.

Frédéric cite : « Ne vous inquiétez pas de demain, il s’occupera de lui-même. »

Agir dans l’incertitude

Mais alors comment prioriser sans planning ? En allant voir les utilisateurs ! Quels sont leurs plus gros irritants ? On demande ensuite aux développeurs quelles solutions pourraient les atténuer — pas les résoudre complètement, les atténuer — avec des implémentations simples et rapides à mettre en place. On livre, on observe les retours, on ajuste.

Il nous rappelle que les projets sont dirigés par le ROI, calculé comme suit : gains estimés / coûts estimés. Or ces deux estimations vivent dans un contexte où la marge d’erreur est de 100% ! En contexte imprévisible, les prédictions relèvent davantage de la divination.

L’analogie des urgences

Il nous présente alors un endroit similaire à nos projets informatiques, imprévisibles, avec une organisation complexe et des enjeux vitaux, que nous connaissons tous : les urgences médicales. Personne ne sait quand il sera soigné, car la priorité est déterminée dynamiquement par la gravité. L’efficacité des urgences se mesure au taux de mortalité. Il nous démontre alors qu’il n’y a aucune corrélation entre performance et prévisibilité.

Le parallèle avec nos équipes est clair : une équipe autonome qui parle à ses utilisateurs et qui priorise en fonction de leurs besoins réels, sans dépendre d’un planning synchronisé avec dix autres équipes sur 3 mois. L’alternative à l’agilité à l’échelle, nous dit Frédéric, c’est tout simplement… l’agilité.

De développeur à hacker : savoir casser, c’est savoir protéger

Florian Toulemont, hacker éthique, a proposé un panorama accessible et concret de la cybersécurité, rappelant que la sécurité est aussi de la qualité.

Les chiffres qui font réfléchir

900 millions d’attaques dans le monde, 15 000 milliards de dollars de pertes l’an dernier. La cybersécurité est un enjeu majeur pour les entreprises, les gouvernements et les particuliers comme le montrent toutes les attaques réussies contre des entreprises que nous connaissons tous ou des sites gouvernementaux.

Les fondamentaux

Florian distingue trois axes d’attaque : la confidentialité, la disponibilité et l’intégrité des données. Côté défense, il rappelle l’importance des analyses SAST (statiques) et DAST (dynamiques) à intégrer dans nos CI, mais insiste : elles ne font pas tout. La sécurité doit être pensée dès la conception, c’est un critère de qualité.

Les vulnérabilités les plus courantes

Quelques cas concrets passés en revue et comment s’en prémunir :

• XSS (Cross Site Scripting) : injection de contenu dans une page web, provoquant ainsi des actions sur les navigateurs web visitant la page -> valider les inputs utilisateurs, utiliser les CSP
• IDOR (Insecure Direct Object References) : accéder à des ressources qui ne nous appartiennent pas, c’est ce qui s’est passé pour l’attaque de l’ANTS récemment -> vérifier les rôles et l’appartenance des objets sur chaque endpoint, éviter les ID incrémentaux dans les URL
• SSRF (Server-Side Request Forgery) : possibilité d’exécuter des requêtes sur lesquelles le hacker n’a pas le droit -> filtrer les URI appelables, sécuriser les serveurs même (surtout) en interne
• Forensic supply chain : attaquer indirectement l’organisation cible en compromettant d’abord les maillons les moins sécurisés -> vérifier les dépendances, mettre en place des cycles de mise à jour, être capable de rollback rapidement une version vulnérable

Le message clé

Trois choses à retenir : les enjeux sont majeurs, il faut remettre en question la sécurité de chaque implémentation, et surtout lever la main au moindre doute.

Ce que je retiens de cette édition

Devoxx 2026 a été marqué par une maturité nouvelle dans le rapport à l’IA. Moins de hype, plus de questionnements concrets : qu’est-ce que ça change pour l’open source ? Pour nos compétences ? Pour nos organisations ? Les talks les plus marquants n’étaient pas ceux qui parlaient de technologie, mais ceux qui nous invitaient à réfléchir à notre façon de travailler — lire des papiers académiques ou simplifier nos processus.