Devoxx France est la plus grande conférence indépendante autour du développement et de la programmation, en Europe. Cette année encore, Sedona a participé aux 3 jours de conférences qui se sont tenus du 16 au 18 avril. Cette année l’IA était à l’honneur, l’IA est de plus en plus présente que ce soit sur les besoins de nos clients ou bien en assistance de nos développements, il est donc normal que ce sujet ait été le plus discuté cette année.
Nous avons choisi quelques talks que nous souhaitons vous partager pour ce jour 3, on vous raconte ?
Vendredi 18 Avril 2025
Plongez dans l’Ère Quantique : décryptez et anticipez la révolution à venir – Fanny Bouton
Fanny Bouton a ouvert sa keynote « Quantique » à Devoxx France 2025, en partageant son parcours qui débute dès son enfance avec le COBOL enseigné par son père, puis sa passion pour la science-fiction des années 80 qui l’a conduite au quantique. Elle rappelle que les ordinateurs quantiques disponibles aujourd’hui comptent entre 2 et 156 qubits, IBM ayant récemment déployé son système “Aachen” à 156 qubits sur le processeur Heron R2 dans son data center européen. Malgré ces progrès, la suprématie quantique n’est pas encore atteinte : persiste le défi de l’erreur et la nécessité d’algorithmes robustes, exigeant une maîtrise fine des mathématiques et de la physique quantique.
Pour illustrer ce chemin de maturation, Fanny a comparé l’évolution du quantique à celle de la Formule 1 : comme un pilote et son écurie, il faut entraîner et former dès maintenant les talents pour tirer parti des futures machines. Elle insiste sur l’urgence de l’éducation continue et sur l’écosystème européen, où la France et le Pays Basque en particulier préparent l’arrivée du premier IBM Quantum System Two (156 qubits) à Saint Sébastien d’ici fin 2025, une installation stratégique qui renforcera la souveraineté et l’innovation régionale. En conclusion, elle a invité chacun à s’engager dès aujourd’hui dans le quantique — en suivant des podcasts ou en participant à France Quantum — pour ne pas manquer cette révolution technologique.
Les LLM rêvent-ils de cavaliers électriques ? – Thibaut Giraud (Monsieur Phi)
Nous avons trouvé percutante la remise en cause de la métaphore du « perroquet stochastique » : l’intervenant a souligné que, pour prédire un coup d’échecs, un LLM doit internaliser la configuration de l’échiquier et raisonner sur l’enchaînement des coups, et non pas se contenter d’assembler des mots au hasard. Voir que GPT-3.5 Turbo Instruct joue autour de 1 750–1 800 Elo, avec plus de 99 % de coups légaux et des parties cohérentes sur 147 coups, nous a convaincu qu’on est face à une forme de compréhension implicite, portée par la richesse des données PGN et la capacité du modèle à exploiter les patterns statistico-structurels.
Au-delà des chiffres, c’est la démonstration de l’importance de la représentation interne qui nous a marqué : comme de bons joueurs d’échecs visualisent l’échiquier à partir d’une séquence de coups, le LLM construit un « modèle mental » du plateau grâce à ses embeddings et à ses dépendances contextuelles. Cette capacité à gérer l’état du jeu, couplée au format PGN standard, prouve que ces modèles peuvent effectivement comprendre des contextes complexes, ouvrant la voie à des applications stratégiques où la prédiction séquentielle seule ne suffit plus.
Déployer un service utilisant du Machine Learning : et la QA là-dedans ?
Lors de cette session, François Mockers, QA Lead chez PayLead, a d’abord rappelé que les modèles de Machine Learning – par leur non-déterminisme et leur dépendance aux données – posent des défis particuliers pour la validation en production. Il a ensuite détaillé les différentes phases d’un déploiement ML, du premier jeu de données d’entraînement jusqu’à l’inférence en prod, en soulignant les points de contrôle clés : intégration de tests unitaires sur les transformations de données, vérification de la qualité des prédictions via des scénarios utilisateurs automatisés, et monitoring de la dérive des modèles pour détecter rapidement toute régression.
Enfin, François a insisté sur l’importance de la collaboration entre les développeurs, les QAs et les data scientists pour bâtir un pipeline de déploiement robuste : définir clairement les responsabilités, partager des critères d’acceptation métier et établir des « garde-fous » dans le CI/CD pour chaque mise à jour de modèle. Il a illustré ses propos avec des retours d’expérience concrets où une simple évolution de données d’entrée avait brisé des scénarios utilisateurs, montrant qu’un processus QA bien intégré n’est pas un luxe, mais une nécessité pour garantir la fiabilité et l’efficacité des services ML en production.
45 min pour mettre son application à genoux : le guide complet du test de charge
La session sur Takiciné était passionnante, notamment la mise en avant du rôle crucial des tests de charge avant tout lancement. Simuler des dizaines, voire des centaines d’utilisateurs virtuels avec Gatling montre à quel point des scénarios diversifiés—chargement de la page d’accueil, navigation entre les films, authentification via la Test Gateway—peuvent révéler des goulets d’étranglement invisibles en développement. L’idée de structurer les scénarios en groupes et d’intégrer des feeders pour introduire de l’aléatoire m’a particulièrement marqué : cela rend les tests plus réalistes et met en lumière des chemins d’usage qu’on n’aurait pas forcément imaginés.
Ce que nous avons retenu en fin de présentation, c’est que l’intégration des tests de charge dans le CI/CD n’est pas un luxe, mais une nécessité pour garantir la fiabilité continue. Automatiser la création et la destruction de données de test, exécuter des smoke tests rapides avant chaque déploiement, et utiliser des environnements de staging dédiés, voilà autant de bonnes pratiques qui permettent de déployer en toute confiance. Loïc et Mathilde ont montré que, même si la mise en place demande un peu d’effort initial, la sérénité apportée en production n’a pas de prix.
Optimisation des requêtes PostgreSQL : Parlons Performance ! – Lætitia Avrot (EDB)
Nous avons particulièrement apprécié la clarté avec laquelle Latitia Avro a décortiqué chaque étape du traitement d’une requête dans PostgreSQL — du parseur jusqu’à l’exécuteur — pour nous montrer comment l’optimiseur choisit son plan d’action. Comprendre qu’un simple EXPLAIN ANALYZE peut révéler des ajustements concrets à apporter (comme l’ajout d’un index multicolonne ou la réécriture d’une clause WHERE) nous a rappelé que la performance n’est pas un mystère inaccessible, mais le fruit d’une série de choix éclairés.
Ce qui nous a également marqué, c’est son insistance sur l’équilibre à trouver entre trop peu et trop d’index : un index bien ciblé peut accélérer une requête de façon spectaculaire, tandis qu’un excès d’index pèse sur les écritures. Enfin, ses conseils sur la mise à jour régulière des statistiques et l’usage d’outils natifs comme EXPLAIN nous semblent désormais incontournables pour tout DBA ou développeur souhaitant tirer le meilleur de PostgreSQL en production.
The DDD Horror Picture Show – Thomas PIERRAIN & Pauline Jamin (Agicap)
Nous avons assisté à ce talk qui décortique avec humour et lucidité les travers du Domain-Driven Design. Pendant près d’une heure, ils ont partagé des anecdotes concrètes sur l’obsession des agrégats, montrant comment une trop forte dépendance peut provoquer des coquilles de synchronisation, notamment autour des fuseaux horaires. Ils ont ensuite mis en garde contre l’usage excessif des événements, rappelant que multiplier les notifications peut transformer votre architecture en un labyrinthe ingérable. Le concept de « vampire de contexte » a particulièrement résonné, illustrant à quel point aspirer toutes les données d’un contexte tiers peut conduire à un couplage fragile et à des migrations monumentales. Les speakers ont ponctué leurs réflexions d’un humour acerbe, comparant parfois nos pratiques DDD à une séance d’horreur où l’on découvre nos propres erreurs passées. L’impact a été immédiat : le public a ri, hoché la tête et pris conscience de ces biais cognitifs qui nous poussent à complexifier sans forcément raisonner en termes de valeur métier.
Au-delà du constat, Pauline et Thomas ont proposé des leviers simples pour éviter ces cauchemars, comme la méthode du canard en plastique pour prendre du recul et clarifier sa pensée. Ils ont encouragé la veille technologique et l’échange d’astuces entre pairs, soulignant que s’inspirer des retours d’expérience est une arme efficace pour casser le cargo cult. L’idée de comparer systématiquement plusieurs solutions via l’approche « bon, la brute et le truand » a été saluée pour son pragmatisme et sa facilité de mise en place. Enfin, ils ont rappelé l’importance du rasoir d’Ockham : toujours considérer d’abord la solution la plus simple avant de plonger dans des architectures complexes. En conclusion, ce talk nous a rappelé qu’un DDD bien utilisé reste un outil puissant, à condition de garder la simplicité et la valeur métier au cœur de nos décisions. Grâce à cet échange, nous avons pu repartir avec des pistes concrètes pour éviter les pièges et garder mes futurs designs à la fois élégants et robustes.
Platform Engineering : DevOps est maintenant majeur – Alexis Morelle & Henri Gomez (WeScale)
Le DevOps a grandi. Il a traversé son enfance, son adolescence turbulente, et entre maintenant dans une nouvelle phase : celle du Platform Engineering. Lors de ce talk éclairant à Devoxx France, Alexis Morelle et Henri Gomez, tous deux de chez WeScale, ont partagé leur vision de cette transition, avec un retour précieux sur l’évolution culturelle et technique du mouvement.
L’enfance du DevOps : deux mondes qui s’ignoraient
Henri a commencé par rappeler les origines du DevOps : une dualité entre deux cultures.
D’un côté, le développeur, orienté produit, vitesse et innovation. De l’autre, l’ops, garant de la stabilité, de la sécurité et du maintien en conditions opérationnelles. Deux rôles fondamentaux mais historiquement antagonistes, avec peu de dialogue.
À l’époque, on connaissait tous la théorie de la patate chaude : ce fameux .war livré un vendredi à 18h, juste avant que le dev ne parte en week-end… et l’ops qui se débrouille pour une MEP risquée. Résultat prévisible : ça casse.
DevOps : une culture avant d’être un outillage
Le DevOps a changé ça. Il a ouvert un espace de dialogue. Le dev apprend à connaître les contraintes de l’ops, et inversement. Chacun découvre “la planète de l’autre”. Fini les Cerfa de 40 pages pour mettre en prod, place à l’agilité, à la collaboration et à l’automatisation.
Outils modernes & open source : la montée en compétences
Alexis a ensuite pris la parole pour insister sur l’importance de l’open source dans cette transformation. L’outillage s’est modernisé : gestion de config sur Git, tickets sur JIRA, déploiement automatisé… Les Ops ont dû se former à des outils autrefois réservés aux devs. Mais cette transition a aussi laissé certains experts sur le carreau, dépassés par l’évolution rapide.
Cloud, GitOps, sécurité… et IA
Avec l’arrivée du cloud, les règles ont changé. Tout s’est accéléré : Infrastructure as Code, conteneurs, GitOps, sécurité embarquée. Des gains de productivité énormes… mais aussi des dérives.
Alexis met en garde contre le DevOps “piloté par ChatGPT” : copier coller un script Terraform généré par l’IA sans comprendre ce qu’il fait, ce n’est pas de l’ingénierie. C’est risqué, et surtout contraire à l’esprit DevOps.
Platform Engineering : penser produit, penser adoption
Le cœur du talk : le Platform Engineering. On entre dans l’ère du self-service : des outils comme Gitfrog, la signature d’artifacts, la gestion de repository… Mais avec une règle d’or : on ne construit pas une plateforme pour soi. On la construit pour les utilisateurs.
Cela implique une vision produit, une roadmap, des indicateurs d’adoption. Si un service n’est pas utilisé, il ne faut pas hésiter à le décommissionner plutôt que de gaspiller de l’énergie et du temps à le maintenir.
Pas de plateforme magique : transition progressive
Le Platform Engineering ne se fait pas en un jour. Cela demande de la formation, des migrations par étapes mais aussi une adaptation à la maturité de l’organisation.
Et surtout, il ne faut pas tomber dans le piège de penser que le Platform Engineering remplace le DevOps. C’est une erreur stratégique. Comme on a trop vite enterré les sysadmins/netadmins à une époque, ne jetons pas les DevOps d’aujourd’hui.
En conclusion
Ce talk était un vrai voyage dans le temps et dans les pratiques. Alexis et Henri nous ont rappelé que DevOps, ce n’est pas qu’un buzzword ou une pile d’outils. C’est une culture. Et que le Platform Engineering, s’il veut réussir, devra la prolonger, pas la remplacer.
Article rédigé par Edouard Lamotte, Mathieu Broutin, Amine Amarir, Kaiqiang Xu et Omar Belahcen