Les 12 et 13 juin derniers, une partie de l’équipe Ippon était au DevLille 2025. Deux jours intenses de conférences, de discussions passionnées et de (re)découvertes autour de la tech. Installés sur notre stand, nous avons aussi pris le temps d’assister à plusieurs talks, parfois techniques, d’autres fois décalés, mais toujours inspirants.
Nous vous avons préparé un condensé de ce qu’on a retenu : nos 11 conférences préférées, classées par thème, avec quelques pépites à creuser… ou à débattre autour d’un café. ☕👇
1. Développement au quotidien : frameworks, outils et bonnes pratiques
Développer une application mobile avec React Native : Pourquoi expo change la donne ?
Audrey Wech
Dans sa présentation, Audrey nous expose la décision prise par son entreprise de réaliser une refonte de leur application, passant de React Native à Expo, un framework React Native qui apporte son lot de solutions pour simplifier la vie du développeur. Et ce notamment grâce à EAS, la solution de CI de Expo qui permet, via GitHub Actions, d’automatiser la création de builds et le déploiement de ceux-ci sur les stores, mais également de pousser des mises à jour OTA (over-the-air) qui permettent de pousser sur les stores des nouveautés minimes sans repasser par les validations de stores. EAS est open source et possède une version gratuite limitée.
La transition vers Expo leur a permis de mettre en place des bonnes pratiques sur le projet - avec notamment l’ajout de tests - et leur a permis un gain de temps substantiel. Par exemple, le passage d’un chargement de l’application de quasiment 5 minutes en test à un chargement quasi instantané.
Déconstruire les framework js pour mieux réinventer le web
Nirina Rabeson
Et si, finalement, les frameworks js les plus utilisés aujourd’hui n'étaient pas toujours la bonne solution ? C’est le questionnement proposé par Nirina via un bingo développé en reprenant la base des frameworks utilisés aujourd’hui : composant, rendering, réactivité.
- composant : en simulant le fonctionnement de son code via un découpage par une fonction h (hyperscript) utilisé en JSX.
- rendering : une fonction quelque peu compliquée nous amènera à voir notre feuille de Bingo.
- réactivité : une fonction mount() nous permettra, lors du tirage d’un nouveau chiffre, de mettre à jour notre page de Bingo.
Nous voici donc avec un tout nouveau framework JavaScript entre les mains, avec des composants, du rendering et de la réactivité. Bien entendu, à ce niveau, celui-ci n’est pas capable de grand chose mais fait son travail de façon plus optimisé que React.
Pour finir, il est aujourd’hui important de savoir faire la part des choses lors du choix d’un framework pour un projet. Il devient de plus en plus important d’être multi framework et de savoir lequel choisir en fonction de son besoin.
Rendre ses tests concis et évolutifs grâce à JUnit 5 & cie
Juliette de Rancourt
JUnit 5 est un framework très apprécié et adopté par les développeurs Java. Mais savez-vous l’exploiter au maximum ? Connaissez vous les librairies permettant d’approfondir la pertinence de vos tests ?
Dans cette conférence, Juliette de Rancourt décortique les frameworks de test existant sur Java et explique comment améliorer des bases de tests en les rendant plus pertinentes pour le métier. Entre Junit, AssertJ, SpringBoot Tests et ApprovalTests, la customisation de nos tests nous permet de générer des tests unitaires concis, en utilisant des modules customisés pour l’initialisation de nos données de jeu. Un bon nommage des tests permet ainsi de générer des rapports de tests rapidement, lisibles par tous (même des personnes non techniques).
En rendant les tests indépendants de la stack technique utilisée, ceux-ci permet également de valider une non régression d’un comportement sur plusieurs implémentations de tests, en écrivant des tests génériques sur une interface.
Au vu du nombre de sujets et bonnes pratiques présentés, cette conférence est accessible à tous les niveaux, que vous soyez débutant, initié ou confirmé et constitue une introduction complète à l’écosystème de test Java.
Rock SOLID: using the SOLID principles to write code that stands the test of time
Emma Gaubert
Emma Gaubert a animé une conférence sur les principes SOLID pour un code maintenable. En voici un rappel :
- S (Single Responsibility) : les classes doivent avoir une unique responsabilité.
- O (Open/Closed Principle) : les classes doivent être ouvertes à l'extension, mais fermées à la modification.
- L (Liskov Substitution) : les classes dérivées doivent pouvoir se substituer à leurs classes de base.
- I (Interface Segregation) : il est essentiel de bien séparer les rôles de chaque interface.
- D (Dependency Injection Principle) : il faut éviter au maximum le couplage entre les classes.
Elle a démontré l'intérêt d'écrire du code SOLID à l'aide d'un exemple amusant et a exposé les avantages de cette méthode. Je recommande cette conférence pour ceux qui souhaitent réviser les principes SOLID de manière ludique et claire.
Coder dans un vieux langage
Nirina Rabeson
Souvent source de blagues et autres élucubrations, COBOL reste néanmoins un langage encore largement utilisé dans d’anciennes solutions. Nirina, jeune développeur plein de ressources, nous a partagé sa méthode pour ajouter sa pierre à un édifice bien plus vieux que lui : la transpilation.
Avec son équipe, ils ont développé un transpileur de JavaScript vers COBOL en se basant sur les AST, les Abstracts Syntax Tree. En effet, notre code, si l’on regarde bien, est découpé en une multitude de feuilles et de nœuds qui forment un arbre syntaxique. Ainsi, le transpileur va transformer le code JavaScript en AST, puis chaque nœud et feuille JavaScript est remplacé par son équivalent COBOL avant de tout rassembler en remontant la structure de l’arbre.
Cette solution pertinente pose tout de même une question de fond : est-ce que persister dans le COBOL est la réelle solution ? L’ajout continu de code ne risque-t-il pas de faire atteindre à la solution un point de non-retour où un refactoring serait trop coûteux ?
2. Qualité, performance et résilience
45 min pour mettre son application à genoux : le guide complet du test de charge
Mathilde Lorrain et Loïc Ortola
Bien que fréquemment évoqués, les tests de charge sont rarement mis en œuvre. Leur utilisation se cantonne principalement aux projets où de faibles temps de réponse sont critiques ou les interruptions de service onéreuses.
Mathilde et Loïc ont souhaité nous initier aux fondamentaux de ces derniers. Leur présentation s’est décomposée en deux parties : la théorie et la pratique.
La partie théorique a été abordée de manière divertissante, notamment grâce à la diffusion et au commentaire en direct de deux excellentes vidéos au format "Bref", qui ont su allier clarté, concision et humour. C’est un exercice qu’ils avaient pour sûr travaillé !
L'atelier pratique s'est appuyé sur "Takiciné", une plateforme d'informations cinématographiques (toute ressemblance avec un site existant serait purement fortuite). L'application était pleine d'humour : des photos de collègues remplaçaient les acteurs sur les affiches, et le titre du film de démonstration faisait référence à l'outil de test de charge utilisé, Gatling. Les tests de performance ont été développés en direct, illustrant la simplicité d'utilisation de l'outil et comment structurer efficacement ses tests de charge.
Alors, comment réaliser un test de charge ? Il faut d'abord identifier le parcours utilisateur le plus fréquenté, l'objectif étant de simuler au mieux l'usage réel. Pour cela, on peut simuler soi-même le parcours et identifier les end-points sollicités. Ensuite, plusieurs questions se posent : les utilisateurs se connecteront-ils simultanément ou progressivement ? Quel sera leur comportement de navigation ? Interagiront-ils tous avec le même type de contenu (films romantiques) ? Quelle proportion consultera les nouveautés ? Quelle proportion s'orientera vers les comédies ?
Une fois le comportement utilisateur défini, on peut le traduire dans notre langage favori en utilisant la librairie Gatling. De nombreux outils permettent de rendre les tests réalistes. Par exemple, il est possible de récupérer les réponses des requêtes HTTP pour enchaîner les appels dynamiquement. Cela permet d'utiliser des identifiants obtenus lors des appels précédents et d'éviter de solliciter constamment les mêmes ressources. Cette approche est essentielle pour ne pas fausser les résultats des tests, car les mécanismes de mise en cache côté base de données pourraient être sur-sollicités de manière non représentative.
Après avoir transcrit notre comportement, nous pouvons lancer les tests. Un fichier de compte rendu avec les résultats et des détails sera généré.
En sortant de cette conférence, j’avais l’impression de pouvoir écrire moi même des tests de charge.
Pour finir, le thème de leur prochaine conférence a été annoncé : une suite logique axée sur l'amélioration des performances des sections lentes identifiées. Ils prévoient également de donner des conseils pratiques pour optimiser nos applications et leur permettre de supporter une charge plus importante.
Flakiness : quand tester c'est vraiment douter
Maxime Clement
Docker Desktop, eux aussi, ont vécu des tests qui parfois échouent, parfois réussissent. Ce sont des tests instables, aussi appelés Flaky tests. Ces tests interviennent principalement dans le haut de la pyramide de tests, quand on commence à retirer nos mocks et dépendre de tiers externes comme des APIs, car nous maîtrisons de moins en moins l’environnement.
Le problème avec ces tests, c’est que, de manière logique, elle casse la CI/CD. Ce qui demande au développeur d’investiguer et d’y passer du temps avant de se rendre compte que l’échec n’est pas dû à une erreur de code, mais un environnement externe qu’on ne peut pas maîtriser. Ça devient particulièrement gênant lorsque ces cas sont récurrents : c’est de la perte de temps pour le développeur, mais aussi une perte de confiance envers les tests lorsqu'il voit un test en échec.
Tenter de réduire la probabilité qu’un flaky test survienne n’est pas envisageable car, celle-ci reste toujours insatisfaisante : ils sont arrivés au mieux qu’un flaky test survienne 19 fois sur 20 . Ils ont alors décidé de chercher comment vivre avec ces flaky tests et ont développé une API interne qui permet des les ignorer. Lorsqu’un de leur test est reconnu en tant que Flaky, ils le documentent, ainsi que son erreur. Ensuite, l’API intervient (lors du build de la pipeline) : si un test échoue et est référencé en tant que flaky, il sera alors tagué comme “ignoré”. En revanche, si ce même test casse pour une erreur différente de celles connues en base, le test sera bien KO.
Leur solution permet donc de garder la pipeline en succès, tout en gardant l’information sur le test instable et de ne pas utiliser le temps du développeur à perte.
Case : les méthodes de la crim' adaptées au code
Sylvain Coudert
Sylvain Coudert a animé une conférence très ludique axée sur l'analyse de codebase, comparable à une scène de crime. Il a démontré comment identifier, à l'aide de lignes de commande, les éléments qui ralentissent un projet. Pour ce faire, il s'appuie sur l'analyse des logs Git, le nombre de lignes de code et la fréquence des modifications apportées aux fichiers.
Grâce à des outils de visualisation de données, Sylvain met en lumière ces informations via des schémas. Ces représentations graphiques illustrent la taille du code et la concentration des modifications. De plus, il analyse la complexité et le couplage des fichiers afin de définir les actions prioritaires pour optimiser le temps de développement.
3. Sécurité et enjeux tech
Je malmène ton LLM en direct avec 10 failles de sécurités
Gaetan Eleouet
Les LLM sont à la mode, mais soulèvent, eux aussi, des problèmes de sécurité. Au travers d’une démo de live coding, Gaetan s’amuse à malmener son LLM, le transformant d’un simple assistant de bibliothèque en vrai petit garnement désobéissant. Afin de nous éviter cette crise d’adolescence, voici quelques points sur lesquels nous devons porter toute notre attention :
- Sensitive Information Disclosure : le LLM a accès à tout et fait fuiter des informations,
- Right access : le LLM à tous les droits,
- Supply Chain Vulnerabilities : le LLM fournit des liens dangereux,
- Data poisoning : le LLM s’entraîne sur un dataset qui lui ajoute des nouvelles règles,
- Désinformation : le LLM annonce de fausses informations,
- Représentation vectorielle : le LLM peut être trop influencé par certains mots, quitte à oublier le contexte général de la demande,
- Mauvais contrôle des sorties : le LLM peut laisser des failles au niveau de ses sorties (comme des XSS, Cross-site scripting),
- Mauvais cas d’utilisation : le LLM essaiera toujours de répondre à la demande même s’il n’est pas fait pour, quitte à donner de mauvais résultats,
- Consommation excessive : une forte consommation, couplé à des requêtes complexes peut entraîner un DoS (Denial of Service).
La santé a-t-elle peur du cloud ?
Montaine Marteau
La gestion des données médicales, à la fois sensibles et vitales, soulève de véritables défis en matière de sécurité, de confidentialité et d’exploitation. Ces enjeux prennent une dimension particulière lorsqu’il s’agit d’envisager l’hébergement de ces données dans le cloud.
Certaines solutions viennent cependant répondre aux exigences élevées du secteur. La certification HDS (Hébergeur de Données de Santé) impose des standards stricts en matière de sécurité des infrastructures, de traçabilité et de contrôle des accès, apportant ainsi des garanties indispensables pour la protection de données aussi critiques.
Dans le domaine de la recherche, des approches innovantes comme l’apprentissage fédéré permettent de valoriser les données sans avoir à les centraliser. Les algorithmes s’entraînent directement sur des données locales, limitant les risques liés au transfert ou au stockage massif. Le projet MELLODY, appliqué au cancer du sein, en est un exemple concret.
Grâce à ces outils certifiés et ces technologies émergentes, le cloud dans le domaine de la santé évolue vers un modèle plus respectueux des contraintes du secteur, tout en conservant son potentiel d’innovation.
4. Vision & futur du métier
L'avenir des développeurs
Greg Lhotellier
Après plusieurs années de bouleversements majeurs, le métier de développeur est en pleine mutation, notamment sous l’impulsion de l’intelligence artificielle. Lors de ce talk, Greg retrace les événements clés ayant transformé l’écosystème tech depuis la crise COVID, nous menant aujourd’hui à une situation défavorable. En effet, le marché est en baisse, les recrutements sont gelés et les dirigeants voient en l’IA une forme de rédemption.
Malgré ce tableau plutôt morose, le talk invite les développeurs à prendre part à cette révolution. L’IA est une révolution technique, et la technique, ce sont les développeurs. L’IA ne perdurera pas sans la technique. Sans les développeurs, elle restera une “techno-buzz”. Sans les développeurs, elle ne pourra pas évoluer. Sans les développeurs, elle n’existerait tout simplement pas.
Que devons-nous faire ? Comme la sélection naturelle nous l’a toujours appris, nous devons nous adapter et prendre place dans le train de l’IA. Nous allons suivre la transformation, la tester, l’explorer et enfin, communiquer par notre expertise. Il est probable que notre mission change, l’humain est encore aujourd’hui le garde-fou de la qualité. Ainsi le software craftsmanship a-t-il encore de belles années devant lui.
Ce DevLille 2025 nous a boostés : des talks inspirants, des idées à tester dès demain, et des rencontres qui font du bien.On repart avec des pistes concrètes, des réflexions à creuser… et surtout, l’envie de continuer à apprendre et partager.
À bientôt pour de nouvelles aventures tech, ici sur notre blog !
