Devoxx 2025

Le Devoxx 2025 a été une source d’inspiration pour plusieurs Ippons. Dans cet article, nous partageons nos retours d’expérience pour nourrir votre veille et vos réflexions autour des pratiques du développement logiciel.

Sommaire :

• L’intelligence artificielle n’existe pas
• Anatomie d’une faille
• À la découverte du Code Golf
• Comment allonger notre build nous a fait gagner du temps ?
• Marre des null en Java, découvrez nullaway
• Une revue de code qui traîne ?... Ship, Show, Ask
• The DDD Horror Picture Show

L’intelligence artificielle n’existe pas

De Luc JULIA

Pour la première keynote de ces trois jours de conférences, Luc Julia, co-créateur de Siri et expert reconnu de l’intelligence artificielle, s’est attaqué à une question que beaucoup se posent : « Qu’est-ce que c’est, l’intelligence artificielle ? »

L’IA : une boîte à outils, pas une entité pensante

Pour Luc Julia, l’IA n’est ni magique ni dotée d’intelligence réelle. C’est avant tout une modélisation mathématique, un outil mis à disposition des humains. Comme tout outil, il peut être utilisé à bon ou à mauvais escient. À l’instar d’un marteau — utile pour planter un clou, mais dangereux s’il est mal utilisé —, l’IA nécessite des règles, une éthique, et surtout une maîtrise humaine.

« Chaque outil est meilleur que moi dans un domaine précis, mais c’est moi qui décide ce que j’en fais. »

Une évolution, pas une révolution

Contrairement à l’idée reçue d’une rupture technologique brutale, Julia insiste : le Machine Learning, le Deep Learning et l’IA générative sont des évolutions, pas des révolutions. Ces technologies s’inscrivent dans une continuité, alimentée par l’accroissement des données disponibles et la puissance de calcul croissante.

L’exemple des chats : quand les données mènent la danse

Un exemple marquant évoqué durant la conférence concerne les débuts du machine learning : Le premier algorithme de reconnaissance d’image avait pour mission… de reconnaître des chats. Pourquoi ? Parce que les chats dominaient Internet, et donc les ensembles de données disponibles.

Résultat ? Pour atteindre 98 % de précision, il a fallu entraîner l’algorithme avec plus de 100 000 images. Un humain, lui, n’a besoin que de deux images pour atteindre 100 % de reconnaissance. La démonstration est claire : l’IA est puissante, mais fondamentalement différente de l’intelligence humaine.

Le cycle de la hype et le succès fulgurant du prompt

En s’appuyant sur le célèbre « cycle de la Hype » de Gartner, Luc Julia souligne que l’IA générative est la technologie la plus rapidement adoptée de l’histoire. Pourquoi ? Grâce à l’interface en langage naturel : le prompt.

Cette simplicité d’usage a démocratisé l’accès à une technologie complexe, mais elle ne doit pas faire oublier que :

L’IA ne pense pas, ne crée pas, n’innove pas.
Ce sont les humains qui définissent les instructions, l’IA ne fait que les exécuter.

Des enjeux majeurs à ne pas négliger

Luc Julia n’élude pas les risques liés à l’IA. Il en identifie plusieurs, aujourd’hui au cœur des débats :

• Propriété intellectuelle : qui est l’auteur d’un contenu généré ?
• Hallucinations et erreurs : l’IA peut produire des réponses fausses mais convaincantes.
• Jailbreaking : des tentatives de contourner les garde-fous des modèles.
• Impact environnemental : une empreinte carbone significative liée à l’entraînement des modèles.

Vers une IA hybride ?

Pour conclure, Luc Julia partage son rêve : celui de voir émerger une IA hybride, à la fois logique et statique, combinant la puissance du traitement algorithmique et les règles explicites.

Anatomie d’une faille

D’Olivier PONCET

Lors de sa conférence percutante, Olivier Poncet nous plonge dans les coulisses d’une attaque sophistiquée qui a fait trembler le monde de l’open source : celle de la faille XZ Utils, référencée CVE-2024-3094.

XZ Utils

XZ Utils est un ensemble de bibliothèques et d’outils largement utilisés pour compresser et décompresser des fichiers. Il est notamment exploité dans les processus de distribution des sources du noyau Linux, ce qui en fait une brique essentielle de la supply chain logicielle.
XZ Utils est un ensemble de bibliothèques et d’outils largement utilisés pour compresser et décompresser des fichiers. Il est notamment exploité dans les processus de distribution des sources du noyau Linux, ce qui en fait une brique essentielle de la supply chain logicielle.

Et c’est justement cette importance stratégique qui a attiré l’attention d’un attaquant… ou plutôt, d’un adversaire patient, rusé, et redoutablement organisé.

Les objectifs de l’attaque : rien de moins que le pouvoir

L’attaque visait trois objectifs clairs :

• Compromettre la supply chain de Linux, en infectant un composant utilisé dans la compilation de logiciels critiques.
• Affaiblir le daemon SSH, pierre angulaire des connexions distantes sécurisées.
• Et, selon les mots d’Olivier Poncet : « devenir le maître du monde » — ou du moins, en prendre une sacrée longueur d’avance.

Les protagonistes d’un scénario digne d’un thriller

• La cible : Lasse Collin, mainteneur historique de XZ Utils.
• L’attaquant : Jia Tan, développeur qui s’est progressivement imposé dans la communauté du projet. Derrière ce nom, peut-être un hacker solitaire, peut-être un groupe entier.
• Le héros inattendu : Andres Freund, ingénieur chez Microsoft, qui a repéré l’anomalie par pur hasard… et sauvé la situation à temps.

Une attaque menée avec méthode et patience

Olivier Poncet détaille les quatre étapes clés de cette attaque digne des meilleurs films d’espionnage :

1. L’ingénierie sociale : L’attaquant s’est fait passer pour un contributeur bienveillant, gagnant peu à peu la confiance de la communauté — et surtout celle de Lasse Collin.
2. L’ingénierie technique : Une fois intégré au projet, il a introduit subtilement du code malveillant, visant notamment le daemon SSH.
3. Le déploiement : L’attaque a été planifiée sur plusieurs mois, preuve d’une stratégie de long terme.
4. La détection : C’est finalement un coup de chance monumental qui a permis à Andres Freund de remarquer un comportement suspect — évitant une catastrophe à grande échelle.

Cette histoire est plus qu’une simple faille : c’est une démonstration concrète des dangers que représente une supply chain compromise, et du rôle que chacun peut jouer, volontairement ou non, dans la sécurité globale du numérique.

À la découverte du Code Golf

De Sonia SEDDIKI

Lors d’un Lunch Talk aussi insolite que divertissant, Sonia nous a présenté une discipline à contre-courant des standards du développement logiciel : le Code Golf.

Le Code Golf, c’est quoi ?

Le Code Golf est une pratique qui consiste à résoudre un problème de programmation en utilisant le moins de caractères possible.

Oubliez la lisibilité, les bonnes pratiques, le clean code ou le SOLID : ici, l’objectif est d’écrire le code le plus court possible, quitte à en faire une abomination syntaxique.

Cette discipline un peu décalée trouve ses origines sur des forums comme StackExchange qui englobe des forums tech comme StackOverflow et d’autres beaucoup moins tech.

Un FizzBuzz en C version minimaliste

Pour illustrer ce concept, Sonia a présenté une compétition de code golf visant à implémenter le célèbre kata FizzBuzz mais avec quelques contraintes:

• En langage C
• Et surtout… en moins de 71 caractères

On est passé d’une implémentation classique, claire et pédagogique, à :

main(i){while(printf("%i\r%s%s\n",i++,i%3?"":"Fizz",i%5?"":"Buzz")-9);}

Et pour ne rien arranger, le résultat du programme peut varier selon le GPU utilisé. De quoi faire frissonner n’importe quel tech lead.

Un exercice intellectuel, pas du code de production

Sonia a bien insisté sur un point essentiel : « Ce type de code n’a rien à faire en production ! »

Le Code Golf, c’est avant tout un jeu, un défi, un entraînement cérébral pour celles et ceux qui aiment tordre le langage, repousser les limites du compilateur, ou simplement impressionner leurs pairs lors d’un meetup.

Mais ce n’est pas parce que c’est fun que c’est utile pour vos applications métiers. À la moindre tentative de pull request avec ce type de code, vous risquez de vous faire “golfer” par vos collègues.

Comment allonger notre build nous a fait gagner du temps ?

De Éric LE MERDY & Vincent GALLOY

Lors de cette conférence au titre surprenant, les deux intervenants nous ont partagé un retour d’expérience contre-intuitif : en rallongeant leur temps de build, ils ont... gagné du temps.

L'idée : investir dans l'automatisation pour réduire le travail manuel

Leur approche repose sur un constat simple mais souvent négligé : le temps passé à corriger manuellement des erreurs, à résoudre des conflits ou à maintenir une cohérence de code coûte bien plus cher que quelques minutes de build supplémentaires.

En automatisant certaines étapes dans le processus de build, l’équipe a pu fluidifier le travail des développeurs au quotidien. Voici quelques-unes des pratiques mises en place :

Ce qui a été automatisé

• Mise à jour automatique des dépendances : Fini les PRs bloquées par des packages obsolètes ou des failles connues. Tout est tenu à jour de manière proactive par des outils tels que Renovate ou Open-Rewrite.
• Plugin de formatage : L’utilisation d’un outil de formatage standardisé a permis d’éliminer les conflits de style dans les PRs, souvent sources de conflits inutiles.
• Règles personnalisées avec PMD et ArchUnit : l’idée générale est claire : intégrer des règles de qualité spécifiques à l’architecture du projet directement dans le build, pour prévenir les dérives structurelles.
• Analyse de compilation et nettoyage des dépendances : Grâce à des outils comme maven-dependency-analyzer, les dépendances inutiles sont identifiées et supprimées, allégeant le projet et améliorant sa maintenabilité.

JIDOKA : détecter les défauts le plus tôt possible

En toile de fond de cette démarche se trouve un principe issu du LEAN : JIDOKA. Ce pilier fondamental encourage la détection des erreurs dès leur apparition, plutôt que de les laisser polluer le pipeline jusqu’à la production. Mieux vaut un build long, mais fiable, qu’un build rapide qui laisse passer des erreurs coûteuses.

Un paradoxe productif

Ce talk nous rappelle que l’optimisation ne se résume pas à la vitesse brute. Parfois, ralentir certaines étapes techniques permet d’accélérer le travail global, en réduisant les frictions humaines et les erreurs subtiles mais chronophages.

Marre des null en Java, découvrez nullaway

De Alexandre NAVARRO

Lors d’un Tool-in-Action de 30 minutes, Alexandre Navarro nous propose une bibliothèque pour dire au revoir aux NullPointerExceptions bien connues de Java. Il s’agit de la bibliothèque open source NullAway, développée par Uber.

Alexandre a commencé par rappeler l’impact des NPE, en citant notamment le créateur des références null, Tony Hoare, qui avoue lui-même que c’était peut-être une erreur à un milliard de dollars. Alexandre nous fait d’abord part de bonnes pratiques pour éviter au maximum les NPE.

Optional<String> optionalName = Optional.ofNullable(getName())
		.orElse("default name");

• Utiliser la classe Optional : on peut par exemple utiliser Optional pour éliminer les null. Bien que cette syntaxe nécessite de la rigueur dans son utilisation, elle est assez efficace :
• Utiliser des instances immuables et les constructeurs : utiliser des constantes initialisées via leurs constructeurs permet d’éliminer les NPE. Par contre, si on utilise les builders, attention aux champs oubliés… Des alternatives à Lombok, comme jilt, permettent l’usage des StagedBuilder.
• Valider les entrées au plus tôt : en vérifiant les variables au plus tôt possible (avec Jakarta par exemple), on évite des NPE plus tard !
• Utiliser des instances neutres ou empty : il vaut mieux privilégier des listes vides plutôt que null par exemple.

Des langages plus récents ont d’ailleurs éradiqué les NPE en supprimant… les null. Rust par exemple, où la notion de null pointer n’existe pas, et Kotlin qui utilise le marqueur ? pour distinguer les valeurs nullable et non-nullable.

Le cœur de la présentation s’est focalisé sur NullAway, une annotation processor intégrée à Error Prone (projet maintenu par Google). Il s’appuie sur les annotations JSpecify comme @Nullable et @NonNull pour vérifier les NPE à l’étape de compilation. JSpecify est un projet maintenu par de grands noms comme Google, JetBrains, Meta, Microsoft…

public int getLength(@NonNull String text) {
    // Compile car `text` n'est pas nullable
	return text.length();
}

public int getLengthKo(@Nullable String text) {
	// Ne compile pas car `text` peut être null
	return text.length();
}

public int getLengthOk(@Nullable String text) {
    // Vérification obligatoire du null !
	return text != null ? text.length() : 0;
}

NullAway est un outil très configurable, activable par package, ce qui facilite son intégration. Il est facile à mettre en place sur de nouveaux projets, et Alexandre nous fait part de son expérience où il a mis en place NullAway sur un projet legacy : c’est chronophage, mais faisable. De plus, l’outil ajoute un léger surcoût au temps de compilation (environ 20 % d’après son observation).

Même si vous annotez entièrement votre projet, il se peut que vous rencontriez encore quelques NPE à cause de dépendances qui n’ont pas encore migré sur NullAway. Mais bonne nouvelle pour les utilisateurs de Spring : le framework a annoncé bientôt migrer entièrement sur NullAway et les annotations JSpecify pour éradiquer les NPE. Voilà qui devrait faciliter l’intégration de NullAway dans nos projets Spring ! Une proposition est également en cours pour intégrer un système similaire directement dans le JDK lui-même, un peu comme le fait Kotlin.

Une revue de code qui traîne ?... Ship, Show, Ask

De Mohamed AIT ABDERRAHMAN

Qui n’a jamais connu l’enfer d’une revue de code qui s’éternise ? Mohamed Ait Abderrahman ouvre son talk en posant cette question et bien des mains se lèvent ! Pour éviter que la frustration ne s’installe, il nous présente une approche issue d’un article du blog de Martin Fowler, Ship / Show / Ask. Une stratégie pour allier les avantages de l'intégration continue (CI) et des Pull Requests (PR), tout en offrant plus d'autonomie aux équipes.

Le principe est le suivant : tous les changements ne nécessitent pas le même niveau d'attention. Selon leur nature, trois comportements sont possibles : Ship, Show ou Ask.

• Ship : envoyer directement en production

Quand un changement est simple, inutile d’alourdir le processus. Un bug trivial corrigé, un refactoring mineur, un ajout de documentation ou encore l’implémentation d’un code standard respectant les conventions du projet ? On merge directement dans la branche principale, à condition bien sûr que la CI soit verte.

Le bénéfice est immédiat : une intégration rapide, une branche principale toujours à jour et beaucoup moins de conflits à résoudre.

• Show : partager pour mieux progresser

Parfois, un changement est un peu plus important, mais on ne veut pas ralentir la livraison pour autant. Dans ce cas, on ouvre une PR, on laisse la CI faire son travail, puis on merge sans attendre de retour formel. La discussion arrive après : une séance de partage permet de recueillir avis, idées, suggestions d'amélioration.

Cette méthode est idéale lors de deadline serrée, de refactorings structurants ou tout simplement pour diffuser la connaissance au sein de l'équipe. L’avantage majeur ? Le feedback est donné sans mettre en pause le flux de travail et sans générer de tensions.

• Ask : demander une revue

Enfin, pour les évolutions critiques, comme de nouvelles fonctionnalités, refontes sensibles, accompagnement de profils juniors, on demande une revue approfondie, avec au moins une approbation avant le merge.

L’objectif du Ask est de détecter les problèmes au plus tôt, partager les décisions importantes et faire progresser l’équipe.

Et alors, ça marche ? Selon, Ait Abderrahman la pratique de Ship / Show / Ask transforme la dynamique d'équipe. On gagne plus de flexibilité et on réduit la frustration. Les revues obligatoires (Ask) deviennent rares. Et surtout, on évite les situations où les revues s’accumulent, générant rancœur et désengagement.

Mais attention, cette approche n’est pas magique. Elle fonctionne si elle répond à un besoin réel. Avant de se lancer, il faut se poser les bonnes questions :

• Le projet est-il assez mûr (et pas un simple POC) ?
• Les membres de l’équipe se font-ils mutuellement confiance ?
• Le niveau de qualité est-il suffisamment élevé pour autoriser une telle autonomie ?

Mohamed Ait Abderrahman insiste sur quelques piliers essentiels pour une adoption réussie :

• Responsabilité : chaque membre de l’équipe doit qualifier ses PR de manière pertinente
• Clarté : le type de PR (Ship, Show, Ask) doit être évident pour tout le monde
• Confiance et respect : envers les collègues, leurs choix techniques et leurs décisions

Cette approche démontre que la revue de code obligatoire n’est pas la seule manière de collaborer, récolter du feedback et diffuser le savoir. Le Pair/Mob Programming, bien qu’il n’ait pas été mentionné lors du talk, pourrait certainement faciliter la mise en œuvre du Ship / Show / Ask.

Avec cette stratégie, il ne s’agit pas seulement de gagner du temps mais aussi de cultiver une véritable dynamique de responsabilité, de confiance et d’apprentissage continu. Un changement profond d’état d’esprit qui semble mener vers des équipes plus sereines, plus efficaces, voire plus unies ? Cela fait rêver !

The DDD Horror Picture Show

De Pauline JAMIN et Thomas PIERRAIN

Le Domain-Driven Design (DDD) est un ensemble de tactiques et de stratégies destinées à réduire la complexité en ingénierie logicielle. Agrégat, Bounded Context, Domain Events… Le DDD regorge de concepts fascinants lorsqu’on les découvre. L’envie de les appliquer partout est alors très tentante. Le début d’un rêve qui vire au cauchemar ?

À travers leur talk, Pauline Jamin et Thomas Pierrain reviennent sur de vilains souvenirs : des agrégats sans invariant métier devenus sources d’effets de bord indésirables, des Bounded Contexts vampires ou encore une danse macabre d'événements trop interdépendants… De quoi donner des sueurs froides.

Prenons l’exemple du Bounded Context vampire. Poussés par une quête d’autonomie qui tourne à l’obsession, certains services en viennent à aspirer les données des autres en les stockant localement. Cela fragilise l’ensemble du système en créant un couplage qui nécessite une mise à jour au moindre changement. Pourtant, la vraie autonomie ne passe pas nécessairement par l’autarcie. Interroger les autres services au moment opportun pourrait bien être la solution la plus simple et la plus efficace.

« Corrélation n’est pas causalité »

Alors, comment en arrive-t-on à ces situations inconfortables ? Le DDD nous pousse-t-il inéluctablement vers ces travers ? Ou le problème se cache-t-il ailleurs ? Peut-être dans notre mise en pratique pleine de bonnes intentions… et d’illusions ? Entre effets de mode, optimisations prématurées, mimétisme naïf et distorsions des indicateurs, nous pouvons facilement sombrer dans le cargo cult.

Heureusement, Jamin et Pierrain nous livrent des pistes concrètes pour éviter ces horreurs. En voici quelques-unes :

• Explorer d’autres pratiques via notre veille tech pour secouer nos automatismes
• Chercher au minimum trois solutions pour un même problème
• Documenter ses choix (ADR – Architecture Decision Records) et ses expérimentations (tech radar)
• Appliquer le rasoir d’Ockham : commencer par considérer la solution la plus évidente (sans forcément la choisir mais au moins l’envisager)
• Clarifier la nature du problème : technique ou métier ?

Pour aller plus loin, Pauline Jamin et Thomas Pierrain nous recommandent d'explorer la théorie de la résidualité de Barry M. O'Reilly. Cette approche consiste à soumettre intentionnellement notre système à divers stress pour identifier les composants qui fonctionnent toujours, aka les résidus. Ces éléments résistants deviennent les fondations d'une architecture conçue pour naviguer efficacement dans l'incertitude et s'adapter aux changements imprévus.

The DDD Horror Picture Show a de quoi rendre humble. Ici, le DDD n’est qu’un prétexte pour aborder un travers bien humain : la tentation de complexifier à outrance. Il y a fort à parier qu’il réveillera quelques cauchemars dont vous avez été à la fois la victime et l’architecte. Mais ces erreurs ne sont-elles pas les jalons de notre progression ? Cette conférence est une belle invitation à prendre du recul avec ce rappel salutaire : la simplicité est essentielle.

Enfin, n’oublions pas que notre mission première reste de résoudre les problèmes des personnes pour qui nous concevons le logiciel, en collaboration étroite avec le métier, comme l’encourage le DDD. Observons, expérimentons et remettons en question nos outils – ainsi que nos biais – pour des nuits plus douces.

Sur ce, KISS (Keep It Simple, Stupid).

Références

• Devoxx France
• Null References: The Billion Dollar Mistake - Tony Hoare
• Null Safety in Spring applications with JSpecify and NullAway
• JEP draft: Null-Restricted Value Class Types (Preview)
• Ship / Show / Ask
• DDD stratégique vs. DDD tactique
• Qu’est-ce que le “cargo cult” dans le développement logiciel ?
• An Introduction to Residuality Theory : Software Design Heuristics for Complex Systems