Le thème cette année était Happy AI. Après une édition 2025 déjà très axée IA, cette nouvelle édition continue dans la même ligne. A la vue du programme, une chose m’a sauté aux yeux : après 2025 où il y avait beaucoup de cas d’usages avec des frameworks, des rappels et ateliers sur les techniques (chat, RAG, …), cette année il y avait plus de méthodologie et des retours d’expérience. En particulier sur l’usage en tant qu’assistant de codage, avec des concepts et des points d’attention dont je n’avais pas connaissance et que je peux appliquer immédiatement pour certains. Bref, pas mal de concret.

Voici un résumé des conférences / ateliers auxquels j’ai participé et qui m’ont personnellement le plus apporté.

L’IA au service du bien commun : Agir avec raison dans l’incertain — Laurence Devillers

Première keynote de ce Devoxx France, et première conférence très intéressante. Laurence Devillers est professeure en intelligence artificielle et chercheur au CNRS entre autres, et travaille dans l’IA depuis les années 90.

L’IA va amplifier nos capacités, refléter ce que nous sommes ou pas, et elle ne ressent rien. Elle ne comprend pas ce qu’elle produit. Elle permet d’avancer plus vite, mais si nous ne sommes pas capables de comprendre ce que sort la machine, nos postes seront remplacés. L’éducation est clé pour avoir un esprit critique face à l’IA.

Tout au long de sa présentation, elle a démystifié 11 mythes autour de l’IA. Elle a parlé du paradoxe de Frankenstein, qui nous bride dans notre imaginaire sur le développement de l’IA. Ce mythe évoque la création de la vie par nous “humains” et le fait que celle-ci se rebelle contre nous. Ceci a pour effet de nous ralentir dans nos travaux sur l’IA.

Quelques autres mythes dont elle a parlé :

• L’IA générale est pour demain (et non, pas du tout). Pour cela elle se base la théorie de système 1 / système 2 de Daniel Kahneman : système 1, voie rapide de décision (intuition, lié à la survie) ; système 2, la cognition, plus long, réflexion par rapport au sens commun, … Par rapport à nous qui avons 2 systèmes, l’IA générative n’a que le système 1 (par la régularité des patterns dans la masse des données d’entraînement) et pas de système 2, car elle n’a pas de conscience du monde. Donc on se doit d’agir en tant que système 2 pour elle.
• L’IA a un niveau doctorat. Qu’est-ce qu’un doctorant ? La méthode scientifique : je fais des hypothèses, je teste des choses, je regarde, j’évalue, je reviens en arrière, … L’IA ne fait pas ça.
• Avec l’IA plus besoin de faire des études. Au contraire, l’IA doit nous inciter à faire plus d’études en sciences. Pour faire des meilleures machines, plus malines, il faut plus d’études, surtout en sciences.

Elle conclue sa keynote par une citation de Blaise Pascal (également dans le titre de la conf) : il faut continuer à agir avec raison dans l’incertain. Cette phrase correspond bien au thème de sa conférence, je vous conseille son visionnage si vous voulez prendre un peu de hauteur par rapport aux différentes affirmations que l’on entend régulièrement sur l’IA.

Specification Driven Development: Développer à l’ère des LLMs — Philippe Bousquet et Benjamin Barbe

Dans cet atelier de 3h, Philippe Bousquet et Benjamin Barbe nous ont présenté un “outil” : speckit. C’est un ensemble d’agents ainsi qu’une méthodologie pour développer à l’aide d’agents, en partant de spécifications. Cela fait quelques temps que j’en avais entendu parler, ce fut donc l’occasion de tester !

Speckit propose la méthodologie suivante, sachant que toutes les étapes ne sont pas obligatoires :

• Constitution : règles et architecture du projet
• Spécifications : intention fonctionnelle
• Clarification : éliminer les ambiguïtés et les incohérences
• Planification : établissement du plan et définition des tâches
• Implémentation : implémentation des tâches

Il fonctionne avec une multitude d’agents ou LLM, ce qui le rend très facile à implémenter. Personnellement pour l’atelier j’ai utilisé Mistral Vibe.

L’atelier est bien fait :

• un cas pour lequel on part de zéro et on implémente un projet entier via speckit
• un second cas où on part d’un projet existant et on y intègre speckit pour développer de nouvelles fonctionnalités

J’ai été très content d’assister à cet atelier, les présentateurs connaissaient bien le sujet, malgré la jeunesse de l’outil. Le support vous guide bien également. Si cela vous intéresse l’atelier complet est disponible en ligne ici, avec la documentation. Je vous le conseille vivement si vous voulez tester speckit !

Domptez vos Agents : AGENTS.md et Context Engineering pour une IA déterministe — Benoit Fontaine

Pour ce tool-in-action, Benoit Fontaine nous a présenté un mélange entre l’état de l’art des connaissances sur les comportements des modèles suivant le contexte, ainsi que son expérience personnelle.

Premier constat : votre agent n’est pas stupide, il est mal nourri. Les performances des agents sont intrinsèquement liées aux données du contexte. Les performances se dégradent lorsque :

• la connaissance est diluée (contexte trop important).
• l’agent est distrait : le contexte est pollué par du code proche mais qui n’a rien à voir avec le dev en cours, ce qui décontextualise la réponse de l’agent.

Le LLM a une meilleure connaissance du début et de la fin du contexte, sur des informations en milieu de contexte la diminution de performance est d’environ 30%. L’agent aura des meilleures performances quand la taille du contexte est contenue entre 60 et 80% de la taille maximale.

Votre AGENTS.md doit devenir l’unique source de vérité :

• architecture et règles des couches
• conventions
• TDD / BDD (ou autre)
• Règles strictes et les violations interdites

AGENTS.md est régi par une norme définie par la Linux Foundation, adopter un autre format revient à s’enfermer dans du vendor locking.

La commande /compact est très importante car elle permet de nettoyer le contexte de tout ce qui pourrait le parasiter et ainsi ne garder que l’utile.

Comment déterminer que votre contexte est arrivé “pourri” :

• Hallucinations d’API : il va commencer à inventer des appels à des api qui n’existent pas
• Amnésie des conventions
• Boucle d’erreur : il boucle sur la même erreur sans en sortir
• Génération de code incohérent

=> contexte pourri = session morte. Vous pouvez redémarrer une nouvelle session.

L’IA est amplificateur universel, il n’y a pas de magie. Soignez votre contexte :).

Pour préparer sa conférence, Benoit à écrit trois articles sur medium, vous pouvez les trouver ici : https://medium.benoitfontaine.fr/. De même, il a fait un projet Github qui lui a servi de support, il est disponible ici : https://github.com/b-fontaine/devoxx-2026

Serveurs MCP : bonnes pratiques, choix de conception et leurs conséquences — Horacio Gonzalez

Ce fut la dernière université à laquelle j’ai assisté avant de devoir quitter ce Devoxx 2026, et elle fut très intéressante ! Horacio Gonzalez nous a fait un retour d’expérience sur l’usage et le développement de serveur MCP, depuis les premiers serveurs sortis après l’annonce du protocole jusqu’à aujourd’hui.

Pour ceux qui ont des doutes sur l’utilité du MCP encore aujourd’hui (ça va tellement vite avec l’outillage IA), celui-ci va devenir un incontournable car il permet de faire le pont entre des accès techniques (APIs, …) et une demande de l’utilisateur en langage naturel. Via un serveur MCP il est possible de donner accès à un LLM à des fonctions lui permettant de mieux nourrir son contexte, mieux répondre à la demande de l’utilisateur.

Le LLM n’appelle jamais l’outil directement, c’est l’application qui fait appel au LLM qui le fera. Actuellement il y a une phase d’appel à évolutions pour une nouvelle version de la spécification qui devrait publiée en juin 2026.

Horacio a commencé par nous décrire les 3 primitives serveurs qu’un MCP peut exposer (outil, ressource, prompt). Puis une fois les bases du protocole posées, il nous a exposé sa méthode pour développer son propre MCP :

• Phase 1 : avoir quelque chose de fonctionnel. Bien utiliser toutes les primitives. Les outils doivent être construits comme des APIs. Les ressources permettent de limiter la réflexion des LLMs en fournissant des données statiques (ou semi-statiques). Les prompts ont l’intérêt de pouvoir être versionnés et ainsi être adaptés au modèle et sa version. Structurez bien les retours et les erreurs, mieux cela sera fait plus le LLM sera performant. Et surtout : n’oubliez pas toutes vos bonnes pratiques de code (sécurité surtout !).
• Phase 2 : on commence a déployer. L’authentification n’est pas optionnelle, on doit savoir qui fait quoi : pour de la sécurité, de la traçabilité, et l’amélioration globale du système. Mettre en place des logs, avec de l’observabilité, et un dashboard permettant de mesurer la fiabilité de l’outil (et suivre son éventuelle dégradation suite à changement de modèle). Pour éviter de surcharger le contexte, on peut appliquer le nouveau pattern code mode de Cloudflare. Il est possible de voir comment CleverCloud a implémenté un MCP pour son API en regardant son code ici.
• Phase 3 : passage à l’échelle. Comme pour un gros monolithe, on découpe en domaines / microservices. Faire plusieurs MCP suivant son propre contexte (par domaine, par source/service, par rôle), et mettre une gateway en frontal pour regrouper les fonctions communes (nettoyage des I/O, authentification, …) et avoir des MCPs plus simples. Mettre également un rate limit pour éviter les LLMs qui bouclent par moments.

Personnellement j’ai bien aimé cette université, même si Horacio avait prévu bien plus de contenu qu’il n’y avait de temps disponible. Son expérience et ses anecdotes permettent d’avoir une bonne compréhension de ce qu’on peut faire avec un MCP (et ce qu’on ne doit pas faire !). Si le sujet vous intéresse, je vous conseille vivement son visionnage.

Enfin voici les autres conférences auxquelles j’ai assisté :

• Les échecs à l’ère de l’intelligence artificielle — Laurent Fressinet : l’histoire de la relation entre l’IA et les échecs, avec notamment Kasparov et Deep Blue. Keynote intéressante qui démontre aussi l’évolution des relations entre les humains et la machine.
• Apprendre à notre IA à … apprendre — Stéphane Philippart : une bonne conférence pour comprendre comment mieux nourrir une IA pour la rendre plus pertinente.
• CLI-Driven Developer Experience : L’ingrédient secret d’une équipe alignée — Julian Briault : comment Julien, à travers son expérience aux restos du cœur ou chez Deezer, à mis au point une CLI pour faciliter les opérations, le partage de connaissance, … au sein des équipes (dev, ops, …).
• Le développeur face à l’IA : du prototypage rapide à la fin des intermédiaires ? — Nicolas Grenié : comment utiliser l’IA pour prototyper rapidement et laisser libre cours à ses idées pour déployer rapidement. Une keynote qui donne pleins d’idées.
• L’IA sur le terrain : l’humain au cœur de la valeur — Marjory Cannone : tout le monde veut de l’IA, mais tout le monde ne sait pas comment ou ne sait pas s’il en a besoin. Retour terrain de Marjory qui travaille avec des TPE/PME dans les Vosges.
• Concurrency Crossroads: Choosing between Reactive Programming & Virtual Threads — Willem Jan Glerum : conférence Java, avec des rappels sur ce qu’est la programmation réactive, les threads virtuels, et ce que ça peut apporter ou pas suivant les cas. Elle se termine sur un comparatif de performances réalisé par l’équipe de Quarkus.
• Les gardiens du Prompt : menaces et recettes de sécurité pour une production zen — Philippe Laumay et Loïc Gudet : tous pleins de bons conseils sur la gestion d’une application avec de l’IA, la sécurisation des prompts, les guardrails, … Chaudement recommandée pour ce qui font de l’IA en production.
• Se retourner la tête avec les quiz Java de José et Jean-Michel — José Paumard et Jean-Michel Doudoux : un moment de détente avec un quiz en live et beaucoup de discussions dans le public suivant les questions !
• Mise : un multi-outil pour votre poste Dev & Ops — Rémi Verchère : une bonne présentation de Mise, un outil d’installation d’outils de configuration de contexte projet. Il m’intéressait car avec l’arrêt de volta les mainteneurs recommandaient de passer à Mise. A tester !
• L’IA au défi de la condition humaine — Jean-Gabriel Ganascia : une keynote bien sympa, ou après une bonne partie dédiée à l’IA heureuse, la conclusion paraît bien plus terre à terre. Je vous la conseille !
• La course à l’IA : La France risque-t-elle de devenir un “territoire servant”? — Loup Cellard : à travers 2 déploiements de datacenters à Bordeaux et Marseille Loup nous démontre comment les territoires peuvent être impactés, les choix politiques locaux, et qui sont les acteurs principaux de ces installations.
• Et si on ouvrait le capot de PostgreSQL ? — Benjamin Coenen : une bonne conférence pour comprendre comment fonctionne PostgreSQL en interne, et ce qu’implique une création d’index ou un appel vaccum. A voir !

C’est tout pour cette édition 2026, j’espère que cette lecture vous aura donné envie d’aller visionner quelques conférences, personnellement je suis très satisfait de ce que j’ai pu voir cette année !

Si vous avez aimé cet article ou si vous l’avez trouvé utile, n’hésitez pas à 👏 ou à le partager ! 🙂

Retours du Devoxx FR 2026 was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cette année encore une édition sympathique du Breizhcamp malgré un contexte un peu morose dans la tech rennaise. Slickteam était de nouveau sponsor, et nous avons pu tous venir voir les conférences qui nous intéressaient, voici quelques retours.

Sortir des ORM avec JooQ — Samuel Lefebvre et Sylvain Decout

Samuel et Sylvain de Shodo nous ont présenté un workshop sur JooQ. C’est un framework qui génère une api à partir du modèle de la base de donnée, et permet d’écrire des requêtes en java directement. Avec JooQ, plus besoin d’ORM.

Ils ont commencé par nous faire une présentation technique du framework, et un retour de leur propre expérience. Ensuite nous sommes passé à la pratique avec les exercices du workshop, qui est bien fait et permet de voir l’utilisation de JooQ dans différents cas, avec une montée en puissance progressive. Les exercices consistent en un remplacement d’un appel via un repo JPA par une requête JooQ. Ainsi, ils démontrent aussi par la pratique qu’une migration peut se faire progressivement dans une base de code.

Vous pouvez trouver le code du workshop ici, si cela vous intéresse je vous conseille la vidéo puis les exercices pour avoir une bonne idée des capacités de l’outil. Personnellement, je pense que sur un futur projet nous testerons pour voir sur le long terme comment cela se passe niveau maintenance et appréhension par les équipes. Je suis plus convaincu par JooQ que la dernière conférence que j’ai vu il y a plusieurs années, ne reste plus qu’à l’utiliser pour de vrai.

Rendre ses tests concis et évolutifs grâce à JUnit5 & cie — Juliette de Rancourt

Juliette est développeuse chez Shodo et contributrice sur JUnit5, et nous a presenté différents outils et méthodes de JUnit5 afin de rendre nos tests plus maintenables. JUnit 5 a déjà 8 ans, et malgré tout beaucoup d’entre nous ne le maîtrisent pas vraiment, et JUnit6 est en pleine préparation.

Tout d’abord JUnit n’est pas fait pour fournir des outils d’assertion complexes, mieux vaut privilégier des librairies spécifiques du type AssertJ. De même avec AssertJ, il est possible de créer ses propres assertions afin de rendre les tests plus lisibles (et éviter les longues suites d’assertions en fin de test).

Il est possible de paramétrer des tests avec @ParameterizedTest (avec ‘name’ pour rendre le rapport plus lisible) et avoir différentes sources pour les valeurs a injecter dans le test (@ValueSource, @CsvSource, @MethodSource, @EmptySource, @NullSource, @ArgumentsSource, …). Ainsi un même test permet de valider plusieurs cas directement suivant les paramètres.

Les petites astuces dont elle nous parlé :

• @DisplayName pour avoir un nom plus parlant dans le rapport, et il est possible d’utiliser un display name generator
• DataFaker pour générer des données aléatoires
• Modifier la config pour avoir le nouveau format de rapport XML
• open-test-reporting-cli pour transformer (entre autres) le rapport XML en HTML
• ApprovalTest qui permet notamment avec un fichier approved.json de comparer le résultat d’un test avec juste ‘verifyJson()’

Si vous utilisez Spring, il est préférable d’annoter vos classes de test avec @DataJpaTest ou @WebMvcTest suivant vos tests car cela permet de charger uniquement une partie du contexte Spring et pas tout le contexte de votre application.

Elle a évoqué pleins d’autres subtilités et astuces, sa conférence était très intéressante, je vous la recommande chaudement !

Si vous avez aimé cet article ou si vous l’avez trouvé utile, n’hésitez pas à 👏 ou à le partager ! 🙂

Retours du Breizhcamp 2025 was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Slickteam we get projects from clients of different sectors, and for one client we have made an application that get orders from SAP. After some time, a client of our client asked to have a PunchOut Catalog to manage their quotation requests. OK ! So, what’s a PunchOut Catalog ?

A PunchOut Catalog in SAP offer the possibility to access directly the supplier’s catalog and to get articles in the cart in SAP. For the client, it’s easier to manage authorisations, budgets limits, … in that way because all these rules are defined in the ERP. You have 2 levels of integration for PunchOut catalogs in SAP:

• Level 1: the buyer is connected to the supplier website through an iFrame directly in SAP, and the supplier website is responsible to send the articles for the order in SAP.
• Level 2: all the supplier’s catalog is pushed in SAP, and the buyer can select the articles directly in SAP. It’s all integrated.

In our case, since there was no real catalog, we had to create an interface that will be integrated as a PunchOut Level1. Our application was developed with SpringBoot and Thymeleaf, and we got some issues… We will see that !

There is a process to declare your PunchOut catalog in SAP, but I will not talk about it here, there is good SAP documentation for that. What interests us developers is what’s coming next !

The user session in your catalog will go like this:

• PunchOutSetupRequest: the first request from SAP, and with that you will authenticate the request, the user, and initiate the session.
• PunchOutSetupResponse: the response for the request, in which you will give SAP the link to your application with a session ID or a token (we managed it with a token, to be stateless).
• PunchOutOrderMessage: the message that your application will send to SAP with the articles the buyer wants to order.

All these objects are described in the CXML documentation, you can get that in the official website.

Now that you have all the context, what was tricky for us ?

Our first issue was that the website is presented in an iFrame inside SAP, and SpringBoot 3.4 goes with some default configuration that does not authorise it. The HTTP header X-Frame-Options is set to DENY by default, and since it is deprecated, you can not authorise it anymore in Spring. To make it work you have to add CSP rules, and since SAP has multiple domains, this is the rule we adopted:

Content-Security-Policy: frame-ancestors 'self' https://*.ariba.com

To enable it, we added this configuration in our WebSecurityConfig:

@Bean
SecurityFilterChain resourceServerFilterChain(HttpSecurity httpSecurity) throws Exception {
    ...
    httpSecurity.headers(headers -> headers
            .contentSecurityPolicy(csp -> csp
                    .policyDirectives("frame-ancestors 'self' https://*.ariba.com")
            )
    );
    ...
    return httpSecurity.build();
}

Our website is now correctly displayed on SAP ! Next issue, the management of the user session.

We were unsure of how the application will react inside the iFrame on the client browser, so we decided to have what we needed for the session inside a token. And since the token has a creation date, it can expire.

The token is an encrypted value that goes along the pages where the user wants to go, it is passed on each request for the backend. We added some data from the PunchOutSetupRequest, such as BuyerCookie, that is required for the PunchOutOrderMessage along the articles for the cart.

It is simple to manage and can work on any environment, without worrying about company policies, SAP rules or other stuff. And now, the last thing to do, push our articles to the cart !

To push the items in the client’s cart in SAP, the first step is to build the PunchOutOrderMessage with the items. This is simple, but you must be aware of your client process in SAP to build it correctly. In our case, the classification for an item must be set on a value that is configured in a certain way in SAP, otherwise the client can not transform the cart into an order in SAP. We learned it along our testing with the client, so be careful !

After you have prepared your POOM to be sent to SAP, this must be done by the client browser. In our implementation, we have an endpoint that returns the POOM to the frontend, and then in javascript we post it using an HTML form to SAP.

Now the process is complete ! Your client’s users can use your PunchOut catalog through SAP, and push items to their cart. Well done !

If you liked this article or you found it useful, don’t hesitate to 👏 it or to share it ! 🙂

How to manage a PunchOut Catalog L1 in SAP and get it done ! was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Avoir un fichier .gitlab-ci.yml clair est essentiel pour assurer une CI/CD efficace. Comprendre ce qui déclenche chaque étape de la pipeline, comment ces déclenchements sont configurés et maintenir un flux de travail fluide et prévisible.

Les pipelines, kezako ?

Les pipelines dans GitLab sont des éléments clés de cette plateforme, automatisant des processus de développement, de test et de déploiement.

Les points clés :

• Automatisation : Réduit les erreurs humaines et accélère le processus de développement.
• Intégration Continue : Assure que le code est toujours dans un état déployable.
• Déploiement Continu : Permet des mises à jour fréquentes et fiables des applications.
• Traçabilité : Fournit des logs détaillés et des rapports pour chaque job, facilitant le débogage et l’audit.

Un fichier .gitlab-ci.yml ressemble à ceci :

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - ./build.sh

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - ./test.sh

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the project..."
    - ./deploy.sh

Une pipeline est composée de “stage”, qui eux-mêmes comprennent des jobs.

Zoom sur les conditions de déclenchement des jobs

Avec only

job1:
  script: echo "Ce travail s'exécute uniquement pour les push sur la branche main."
  only:
    - push
    - main

job2:
  script: echo "Ce travail s'exécute uniquement pour les merge requests."
  only:
    - merge_requests

L’utilisation du mot-clé only dans GitLab CI est désormais dépréciée ; il est recommandé d'utiliser rules pour définir les conditions d'exécution des travaux.

Avec rules

job1:
  script: echo "Ce travail s'exécute uniquement pour les push sur la branche main."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"'

job2:
  script: echo "Ce travail s'exécute uniquement pour les merge requests."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Avec le mot-clé only, la prise en main des conditions de déclenchement des jobs dans GitLab CI était plus simple et intuitive, facilitant la définition rapide de règles basiques pour l'exécution des travaux. Cependant, bien que only soit facile à utiliser pour des cas simples, il présente des limitations en termes de flexibilité et de complexité des conditions.

rules offre une approche plus puissante et expressive pour définir des conditions d'exécution, permettant de créer des règles plus complexes et nuancées. Avec rules, il est possible de combiner plusieurs conditions, d'utiliser des expressions logiques avancées, et de mieux contrôler le comportement des pipelines CI/CD. Ainsi, bien que only soit plus simple pour les débutants, rules permet de répondre à des besoins plus sophistiqués en matière d'automatisation des workflows.

Les events de déclenchement

C’est le moyen par lequel sont déclenchés les pipelines Gitlab. C’est essentiellement avec la variable CI_PIPELINE_SOURCE que l’on peut déterminer la source de déclenchement (push, web, schedule merge_request_event …). Les valeurs sont affichées sur cette page de la documentation Gitlab.

Pour ma part, je me suis inspiré de ce tableau (présent aussi sur la doc Gitlab), pour construire les différents scénarios de déclenchement.

Scenario de test

Pour cet article, j’ai pris pour exemple un projet de base Node.js, avec un seul fichier source de test. L’idée est de montrer une pipeline Gitlab avec un projet type Node.js.

Les étapes de la pipeline

Stages

Jobs

Je reviendrai sur les triggers en peu plus loin de l’article.

Mon organisation de branche et pipeline

Branche main

Dans mon projet exemple, j’ai opté pour une structure avec une seule branche principale, à savoir la branche main. Cela ne correspond donc pas à un cas où l’on aura à gérer plusieurs versions en parallèle en production. Dans mon approche, je considère que la branche main est conçue pour être toujours prête pour la mise en production. Cette approche favorise un flux de travail direct et efficace, où chaque modification apportée à la branche main est immédiatement prête à être déployée, assurant ainsi intégrations et livraisons continues fluides et sans complications inutiles.

Il est important de noter qu’adopter une seule branche principale, telle que main, augmente considérablement le niveau de responsabilité pour ceux qui gèrent les merges vers cette branche. En effet, chaque modification fusionnée dans main est potentiellement prête à être déployée en production. Cela exige une vigilance accrue et une rigueur dans les processus de revue de code et de test, afin de garantir que chaque modification est stable, fonctionnelle et prête pour un environnement de production. Les contributeurs doivent s'assurer que leur code est bien testé et revu avant d'être fusionné, minimisant ainsi les risques d'introduire des erreurs ou des instabilités dans l'application.

Dans la configuration de l’exemple, la pipeline CI/CD est conçue pour déployer automatiquement l’application vers un environnement de staging dès qu’un push est effectué sur la branche main

Tags

Dans ce projet exemple, l’application d’un tag ne se limite pas à la simple identification d’une version. Elle sert également de déclencheur pour la pipeline CI/CD. Lorsqu’un tag est poussé dans le dépôt, cela initie automatiquement le processus de déploiement vers l’environnement en production. Cette méthode garantit que seules les versions explicitement marquées et validées sont mises en production, renforçant ainsi la stabilité et la fiabilité du processus de livraison.

Branche sans MR

Les branches qui n’ont pas de merge request associée ne déclenchent aucune pipeline CI/CD pour ce projet. Ces branches sont principalement utilisées pour permettre aux développeurs de travailler de leur côté sur une fonctionnalité spécifique, sans interférer avec le code principal, et cela évite aussi de sur-utiliser les pipelines lorsqu’on n'en a pas besoin.

Branche avec MR

Au contraire des branches sans MR, les branches avec MR réagissent comme la branche main, à la différence, il n’y a pas exactement les mêmes jobs qui se déclenchent. Par exemple, le packaging et le déploiement vers l’environnement de staging ne se déclenchent pas automatiquement, mais manuellement par un utilisateur depuis l’interface web de Gitlab.

Déclaration des rules

.rules_tags_template: &rules_tags
  if: "$CI_COMMIT_TAG != null"

.rules_web_template: &rules_web
  if: '$CI_PIPELINE_SOURCE == "web" && $CI_COMMIT_BRANCH != "main" && $CI_COMMIT_TAG == null'

.rules_main_template: &rules_main
  if: '($CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "web") && $CI_COMMIT_BRANCH == "main"'

.rules_merge_request_template: &rules_merge_request
  if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

.rules_default_template: &rules_default
  when: never

J’ai créé des références pour les rules afin de les définir une seule fois dans le fichier .gitlab-ci.yml. Après cela, je les ai appelées dans les jobs pour avoir une meilleure lisibilité des jobs et avoir un aperçu rapide de quand est-ce que les jobs seront déclenchés.

Voici une description de chaque rule que j’ai défini pour le projet exemple :

• rules_tags Déclencheur lorsqu’un tag est créé
• rules_web Déclencheur depuis l’interface web de Gitlab
• rules_main Déclencheur lorsqu’un push est fait sur la branche main
• rules_merge_request Déclencheur lorsqu’il y a un événement sur une merge request
• rules_default Règle par défaut que je mets à chaque job. Par défaut, dans cet exemple, tous les jobs ne seront jamais déclenchés.

Description des triggers du projet exemple

Test des scénarios

Sur la branche sans MR

Par défaut, il n’y a pas de pipeline de créée dans ce cas-ci. Le seul cas où l’on peut créer une pipeline, c’est en passant par l’interface web de Gitlab.

Sur la branche avec MR

Suite à un push (ou via le web), une pipeline est créée avec le tag merge_request pour signifier que c’est relié à une MR.

Sur Main

Suite à un push (ou via le web), une pipeline est créée et se déroule “spécifiquement” pour une mise en ligne dans l’environnement de staging.

Avec la création d’un tag

Enfin, sur la création d’un tag, une pipeline est créée, liée à ce dernier et déroule le processus spécifique à la mise en production.

Conclusion

Je suis convaincu que maîtriser pleinement toute la structure liée à l’intégration continue / déploiement continue permet de gérer plus efficacement les flux de travail, en assurant que chaque modification est testée et validée avant d’être déployée.

Cependant, il est évident qu’il existe de nombreuses autres approches et configurations possibles pour gérer l’intégration et la livraison continue. L’exemple fourni ici n’est qu’une des nombreuses façons d’aborder ce sujet, et il est important de reconnaître que chaque projet peut avoir des besoins et des contraintes uniques qui nécessitent des solutions adaptées.

L’essentiel est de trouver un équilibre qui convienne à l’équipe et au projet, tout en garantissant la qualité et la stabilité du code.

Lien du dépôt Gitlab : https://gitlab.com/ronronan/gitlab-ci-cd-article

Si vous avez apprécié cet article, n’hésitez pas à 👏 ou à le partager.

[CI-CD] Comment je m'organise avec mes pipelines GitLab ? was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tout d’abord, pour pouvoir publier sur Maven Central, il vous faudra un compte sur https://central.sonatype.com/. Après, dans l’interface sonatype, vous devez générer un token d’accès depuis la page “My Account” :

Une fois les paramètres du token récupérés, mettez-les de côté pour une configuration future.

Maintenant, vous allez avoir besoin d’une clé GPG. Si vous êtes sur Linux, vous pouvez utiliser la commande gpg pour en générer une :

$ gpg --gen-key

Vous pouvez vérifier que votre nouvelle clé a bien été créé ainsi :

$ gpg --list-keys
[keyboxd]
---------
pub   ed25519 2025-03-24 [SC] [expire : 2028-03-23]
      00A000B00DF0000X00D000E000F00C00B0000
uid          [  ultime ] Ronan Barbot <ronan.barbot@slickteam.fr>
sub   cv25519 2025-03-24 [E] [expire : 2028-03-23]

La chaîne 00A000B00DF0000X00D000E000F00C00B0000 correspond à l’ID de votre clé. Nous allons en avoir besoin pour publier cette clé sur un serveur de clé GPG, afin que la CI puisse la récupérer et l’utiliser pour signer l’artefact :

$ gpg --keyserver keyserver.ubuntu.com --send-keys 00A000B00DF0000X00D000E000F00C00B0000

Ainsi votre clé se trouve sur le serveur keyserver.ubuntu.com (ou celui de votre choix) et notre future action Github pourra la récupérer pour signer le package.

Ensuite, il faut configurer le fichier de build afin d’avoir les informations nécessaires pour le package. Notre build se fait avec Gradle et le DSL Kotlin, nous avons déclaré les plugins suivants :

plugins {
    `java-library`
    `maven-publish`
}

Puis, nous avons configuré le build :

java {
    withJavadocJar()
    withSourcesJar()
}

tasks.jar{
    enabled = true
    archiveClassifier.set("")
}

publishing {
    publications {
        create<MavenPublication>("maven") {
            from(components["java"])
            withBuildIdentifier()
            pom {
                name.set("hubspot-java")
                description.set("Java Wrapper for HubSpot API")
                url.set("https://github.com/Slickteam/hubspot-java")
                licenses {
                    license {
                        name.set("GNU GENERAL PUBLIC LICENSE, Version 3, 29 June 2007")
                        url.set("https://www.gnu.org/licenses/gpl-3.0.txt")
                    }
                }
                developers {
                    developer {
                        id.set("DepositFix")
                        name.set("DepositFix")
                    }
                    developer {
                        id.set("Slickteam")
                        name.set("Slickteam")
                    }
                }
                scm {
                    connection.set("scm:git:https://github.com/Slickteam/hubspot-java.git")
                    developerConnection.set("scm:git:git@github.com:Slickteam/hubspot-java.git")
                    url.set("https://github.com/Slickteam/hubspot-java")
                }
            }
        }
    }
    repositories {
        maven {
            url = layout.buildDirectory.dir("staging-deploy").get().asFile.toURI()
        }
    }
}

Les étapes de build ainsi que les informations nécessaires pour la publication de la librairie sont configurées. Nous pouvons construire un package qui sera conforme aux prérequis pour la publication sur Maven Central.

Nous avons configuré JReleaser afin qu’il publie notre artefact sur Maven Central de cette façon :

plugins {
    signing
    id("org.jreleaser") version "1.17.0"
}

jreleaser {
    gitRootSearch = true

    project {
        description = "Java Wrapper for HubSpot API"
        license = "GNU GENERAL PUBLIC LICENSE, Version 3, 29 June 2007"
    }

    signing {
        setActive("ALWAYS")
        armored = true
    }
    deploy {
        setActive("ALWAYS")
        maven {
            setActive("ALWAYS")
            mavenCentral {
                create("sonatype") {
                    setActive("ALWAYS")
                    url.set("https://central.sonatype.com/api/v1/publisher")
                    stagingRepositories.add("build/staging-deploy")
                }
            }
        }
    }

    release {
        github {
            skipRelease = true
            skipTag = true
            overwrite = false
            token = "none"
        }
    }
}

Le dépôt de staging standard est configuré pour le téléversement sur Maven Central, le service fera de lui-même la promotion du package en public.

Dernier point à réaliser, l’action Github. Pour cela, nous avons fait une action Github qui est déclenchée sur la création de tag et qui lance la cible JReleaser avec Gradle (.github/workflows/release.yml) :

name: Publish package to the Maven Central Repository
on:
  push:
    tags:
      - v*
  pull_request:
    branches: [ main ]
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Java
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'adopt'
      - name: Run chmod to make gradlew executable
        run: chmod +x ./gradlew
      - name: Publish package to local staging directory
        run: ./gradlew :publish
      - name: Publish package to maven central
        env:
          JRELEASER_MAVENCENTRAL_USERNAME: ${{ secrets.JRELEASER_MAVENCENTRAL_USERNAME }}
          JRELEASER_MAVENCENTRAL_PASSWORD: ${{ secrets.JRELEASER_MAVENCENTRAL_PASSWORD }}
          JRELEASER_GPG_PASSPHRASE: ${{ secrets.JRELEASER_GPG_PASSPHRASE }}
          JRELEASER_GPG_SECRET_KEY: ${{ secrets.JRELEASER_GPG_SECRET_KEY }}
          JRELEASER_GPG_PUBLIC_KEY: ${{ secrets.JRELEASER_GPG_PUBLIC_KEY }}
          JRELEASER_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: ./gradlew :jreleaserDeploy -DaltDeploymentRepository=local::file:./build/staging-deploy

Comme vous pouvez le voir, il y a 5 variables d’environnement à configurer dans GitHub :

• JRELEASER_MAVENCENTRAL_USERNAME : le nom d’utilisateur de votre token sonatype
• JRELEASER_MAVENCENTRAL_PASSWORD : le mot de passe de votre token sonatype
• JRELEASER_GPG_PASSPHRASE : passphrase de votre clé GPG
• JRELEASER_GPG_SECRET_KEY : votre clé secrète GPG en base 64 ($gpg --export-secret-keys <key id> | base64)
• JRELEASER_GPG_PUBLIC_KEY : votre clé secrète GPG en base 64 ($gpg --export <key id> | base64)

Une fois terminé, l’application et la CI sont prêtes, ne reste plus qu’à faire un tag !

Lorsque vous faites votre nouveau tag, vous devriez voir l’action s’exécuter dans Github :

Puis après quelques minutes, le déploiement doit apparaître dans votre compte sur Maven Central :

Si vous voulez vérifier, dans la recherche de package dans le dépôt central, que votre package doit être disponible :

J’espère que ce tuto vous sera utile. Pour mon premier déploiement, je me suis basé sur l’article de Thomas Schühly sur dev.to. J’ai adapté certaines parties, car OSSRH est désormais déprécié depuis la migration du nouveau Maven Central.

Si vous avez aimé cet article ou si vous l’avez trouvé utile, n’hésitez pas à 👏 ou à le partager ! 🙂

Publier sur Maven Central via l’API de publication avec JReleaser et Github Action was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cette année encore il y avait de belles conférences pour ce Devoxx France 2025, certains choix ont été durs pour déterminer quelles conférences privilégier. Je vous propose un retour à chaud sur celles qui m’ont le plus marquées.

Null Safety en Java avec JSpecify et NullAway — Sébastien Deleuze

Sébastien a commencé par présenter JSpecify, et plus précisément le chemin qui avait abouti à cette librairie. JSpecify est une librairie issue de la réflexion de plusieurs gros acteurs du monde Java (Broadcom- ex Pivotal, Google, …). Le but premier a été de réaliser une spécification pour définir la sémantique ainsi que les concepts derrière chaque nouvelle annotation. Il a fallu 5 ans pour aboutir au résultat, c’est-à-dire 4 nouvelles annotations, et une librairie sous license Apache2.

Premier point : pourquoi Optional n’est-il pas suffisant ?

• C’est une classe qui nécessite une encapsulation, du coup il y a un overhead en mémoire par rapport au type simple.
• Cela casse les signatures des méthodes. Pour mettre à jour une base de code ou une librairie, le coût et les impacts peuvent être conséquents.
• Il ne faut l’utiliser que pour des valeurs de retours, donc on ne peut couvrir tout notre code.
• Son utilisation génère du bruit, le code est un peu plus long à déchiffrer pour un développeur.

Les nouvelles annotations :

• @Nullable : un élément peut être nullable
• @NonNull : un élément ne peut être null
• @NullUnMarked : définit pour une classe, un package ou un module que la nullité des éléments de l’ensemble est non-spécifiée, c’est-à-dire inconnue
• @NullMarked : définit pour une classe, un package ou un module que la nullité des éléments de l’ensemble n’est pas autorisée

Les avantages de JSpecify :

• L’annotation @NullMarked peut être ajoutée dans le fichier package-info à la racine d’un package, et ainsi définir la non nullité par défaut de tout le code compris dans le package. Il faudra spécifier cas par cas avec @Nullable ce qui peut être null.
• Si le code est bien spécifié, des warnings sont remontés dans l’IDE pour pouvoir traiter les cas directement durant la phase de développement initiale.
• Il permet la vérification sur les génériques, la tableaux, les éléments d’un tableau.

Kotlin reconnaît les annotations JSpecify depuis la version 1.5.20, les warnings remonteront donc dans l’IDE si vous utilisez des librairies avec JSpecify dans votre projet Kotlin.

Tout ça c’est bien, mais en fait la détection d’un élément nullable mal géré ne casse pas le build. C’est là qu’intervient NullAway. C’est un plugin pour l’outil errorprone qui permet d’effectuer un certain nombre de contrôles au build et ainsi évite que ces possibles problèmes ne se passent au runtime.

Pour l’utiliser vous devez ajouter dans votre build errorprone puis son plugin NullAway. Ainsi la vérification des annotations JSpecify sera correctement faite lors du build et celui-ci cassera en cas de mauvaise gestion des valeurs nullables dans le code.

Sébastien fait partie de l’équipe de développement de Spring, Spring Framework 7, Springboot 4 et toute la galaxie des projets Spring devrait être null-safe d’ici la fin de l’année. Il n’y a plus qu’a faire de même sur nos projets !

La territorialisation des infrastructures comme levier de pouvoir — Ophélie Coelho

En ces temps de contexte géopolitique mouvant, la seconde keynote du jeudi était intéressante. Ophélie est chercheuse indépendante spécialisée dans la géopolitique du numérique.

Elle a commencé par nous parler des cables télégraphiques sous-marins, qui, au début du 20ème siècle, étaient la propriété exclusive de l’empire britannique. Lors du conflit entre l’empire russe et l’empire japonais l’accès au réseau est devenu un moyen de pression géopolitique pour agir contre les russes.

Ensuite elle a parlé de l’Afrique à travers différentes cartes, montrant que nos environnements virtuels sont extrêmement ancrés dans un environnement physique, et donc des territoires, et donc liés aux décisions politiques des dirigeants de ces mêmes territoires. Mais, actuellement, au-delà de la géopolitique, le pouvoir des big tech pose également question. Par exemple, Google possède plusieurs dizaines de câbles sous-marin, dont une dizaine à 100%. Cela leur donne potentiellement un pouvoir de décision et de pression énorme.

Elle a terminé sa keynote par une cartographie qu’elle en train de réaliser pour mesurer le pouvoir de chaque big tech dans différents secteurs. Cela est important car les autres big (oil, pharma, …) sont cantonné à leur secteur. Les big tech sont les seuls a être réellement multi secteurs avec un poids de plus en plus important sur des secteurs qui peuvent être critiques. D’où les questions récentes liées à l’antitrust et au démantèlement de ces groupes tentaculaires et au pouvoir souvent trop important.

L’IOT pour 5 ans et + : atelier d’initiation sur carte micro:bit — Jonathan Baranzini et Thomas Cami

Petit atelier fun en début de seconde journée sur la carte micro-bit faite par une fondation de la BBC. Jonathan a commencé par nous présenter la carte :

• Carte assez petite
• Plusieurs capacités embarquées (boussole, accéléromètre, leds, port RF, micro, haut-parleur, …)
• Simple pour développer (Bloc, javascript, python nativement)
• Peu chère (19€)
• Développement possible directement en ligne, ici, avec en plus un simulateur intégré qui permet de vérifier le fonctionnement avant de pousser le programme sur la carte.

L’atelier permet d’aborder différentes capacités de la carte, de voir le développement par bloc ou Javascript / Typescript. Il est didactique et certains exercices nécessitent d’être en binôme, ce qui est très sympa. Je vous met le lien vers le déroulé de l’atelier si vous souhaitez vous y essayer avec votre propre carte : par ici.

Dans leur société ils utilisent la carte pour faire des katas (exercices de programmation pour appréhender un concept ou une méthode), je trouve que c’est une très bonne idée. De plus, comme la carte a peu de capacité de calcul ou de mémoire, cela contraint un peu plus notre réflexion sur les ressources prises par nos logiciels, chose relativement oubliée de nos jours où les contraintes matérielles n’impactent que très peu d’équipes dans notre industrie.

PostgreSQL : Le couteau suisse dont vous avez besoin (sans le savoir) — Lætitia Avrot

Après avoir pu enfin profiter des keynotes en amphi bleu, je suis allé prendre une piqûre de rappel et découvrir quelques fonctionnalités de PostgreSQL.

Lætitia a commencé par un petit tip que je ne connaissais pas : pour une date ou un timestamp, plutôt que de le déclarer NULLABLE, on peut le mettre NON NULL et attribuer la valeur infinity pour une valeur encore non définie (une date de fin par exemple). Ainsi la valeur NULL sera synonyme d’erreur manifeste et non une valeur probablement vide.

Ensuite elle nous a présenté des fonctionnalités avec RANGE :

• On peut définir une plage avec soit des limites exclues (par ex: ‘(1:5)’::int4range => plage de 2 à 4) ou incluses (par ex: ‘[1:5]’::int4range => plage de 1 à 5).
• Il existe différents types d’opérateurs pour les plages (je vous renvoie à la vidéo de son talk pour le détail), mais si on souhaite les indexer, tous les opérateurs ne sont pas supportés par tous les types d’index, il faut faire attention lors de sa déclaration.
• On peut donc, avec ses opérateurs, déclarer par exemple une contrainte de non recoupement (dans son exemple, un vélo ne peut être loué sur 2 plages horaires qui se recouvrent).

Après nous avons plongé dans les colonnes générées, avec de bons rappels pour nous, devs, présents dans la salle et quelques subtilités permises par PostgreSQL :

• Lorsqu’on déclare une séquence puis qu’on fait un nextval() dans un insert, on peut juste remplacer le type de notre id par SERIAL et le tour est joué, plus de séquence ni de nextval().
• Il est possible d’empêcher l’insertion d’une valeur dans une colonne et de laisser la BDD gérer toute seule la valeur de cette colonne. Cela se fait grâce à generated always as.
• On peut calculer la valeur d’une colonne à partir d’une autre colonne, et si la valeur de la colonne de référence change la colonne calculée sera mise à jour.
• Il n’est pas possible de calculer une colonne à partir d’une autre colonne calculée.

Enfin elle a abordé le full text search, une fonctionnalité présente dans PostgreSQL depuis un certains nombre d’année maintenant.

• Une petite précision au départ pour rappeler que définir un champ en VARCHAR avec une contrainte de taille n’est jamais que le fait d’avoir un champ TEXT avec une contrainte pas forcément cohérente avec le métier (qui peut bouger), autant tout déclarer en TEXT simplement.
• Pour pouvoir effectuer une recherche full text il faut avoir déclarer sa colonne en tsvector, qui enregistre des vecteurs associés à une langue.

Une conf très intéressante, vous pouvez retrouver les slides ici.

Sinon, pour les autres conférences / ateliers auxquels j’ai participé :

• L’Intelligence Artificielle n’existe pas — Keynote de Luc Julia : présentation de remise en perspective de ce qu’est l’intelligence et de ce que ne sont pas les IA par Luc Julia, ingénieur spécialisé dans l’IA et co-créateur de Siri (assistant d’Apple)
• HTMX 2.0 et Webcomponents — Horacio Gonzales et Pierre Zemb : présentation avec des exemples de comment utiliser htmx 2, les web components et comment les réunir. Les slides et le code sont ici.
• Workshop Typescript — Johan Rouve, Marjorie Aubert et Bastien Tran : workshop assez didactique avec un bon support en ligne pour découvrir certains concepts de Typescript, comme les types génériques ou la hiérarchie des types. Le support est par ici et la code par là.
• Langage, IA et propagande : la guerre des récits a déjà commencé — Keynote d’Elodie Mielczareck : quel sens pour les mots et discours à l’heure des LLMs et des faits “alternatifs”?
• Université Quarkus et GenIA — Clément Escoffier et Emmanuel Bernard : présentation de 3 heures sur Quarkus et l’usage des IA génératives à travers les extensions Quarkus. Explications des différentes techniques (chat, RAG, fonctions, MCP) et leur mise en place. Le code est ici et vous pouvez récupérer les slides là.
• BOF Ensemble faisons progresser et grandir les développeurs débutants ! — Alexandre Touret : un débat intéressant sur les différentes manières de faire progresser les débutants, gérer l’intégration dans l’équipe, la relation avec les managers, et plus globalement faire progresser tout le monde.
• Plongez dans l’Ère Quantique : décryptez et anticipez la révolution à venir — Keynote de Fanny Bouton : présentation de ce qu’est l’informatique quantique, où nous en sommes actuellement, vers où nous dirigeons-nous et quelles opportunités vont s’ouvrir dans ce nouveau secteur.
• Les LLM rêvent-ils de cavaliers électriques ? — Keynote de Thibaut Giraud : les LLM sont-ils des perroquets stochastiques ou peuvent-ils jouer aux échecs avec “réflexion” ? Par le créateur de la chaîne “Monsieur Phi”.

Cette année encore une belle édition de Devoxx France, avec pleins de présentations et ateliers très intéressants, et l’occasion de discuter et de revoir des gens. Vivement l’année prochaine !

PS : quand les vidéos sortiront j’ajouterai les liens pour les différentes confs.

PS2 : Les liens sont là !

Si vous avez aimé cet article ou si vous l’avez trouvé utile, n’hésitez pas à 👏 ou à le partager ! 🙂

Devoxx France 2025 — retours à chaud après une édition une nouvelle fois très intéressante ! was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some time ago we had a performance issue on a client application (in production). At first, we saw that the CPU usage was 100%, then we restarted the app so the service can run, and I investigated further.

After some time analysing it, I found that all databases connections were taken, and no new connection was possible. Since the issue was encountered regularly, I put Spring and Hibernate in debug mode to see in more details what was going on.

After a while I saw this:

2025-01-24T17:00:02.941Z: Hibernate: select i1_0.id,i1_0.value from items i1_0 where i1_0.id=?
2025-01-24T17:00:02.950Z: Hibernate: select i1_0.id,i1_0.value from items i1_0 where i1_0.id=?
2025-01-24T17:00:02.962Z: Hibernate: select i1_0.id,i1_0.value from items i1_0 where i1_0.id=?
2025-01-24T17:00:03.235Z: Hibernate: select i1_0.id,i1_0.value from items i1_0 where i1_0.id=?
2025-01-24T17:00:03.533Z: Hibernate: select i1_0.id,i1_0.value from items i1_0 where i1_0.id=?

As you can see, there comes the same request again and again, each taking between 10ms and more than 100ms. I searched through the codebase and I found something like this:

itemList.forEach(itemRepository::save);

So, I changed my code to do it in batch, because I was a little in a hurry and I was thinking that I should search later why there was a select when I wanted to save an entity. My code became this:

itemRepository.saveAll(itemList);

And… nothing changed… I found this extremely strange: we wanted to save data in batch as fast as possible, but we were getting select request to check if each data we wanted to save was existing in the database. But WHY ?

After a few tries and research on the web, I found that this was the normal way of acting for Hibernate. Before saving a data it checks if it exists before. Each and every data, one by one, even in batch. We wanted to save hundreds of data fast, but this was taking a terrible long time because of this behaviour from the ORM…

Finally I decided to skip Hibernate for this part and to do a method that will save in batch in SQL directly:

public void insertBatch(List<Item> entities) {
    if (entities == null || entities.isEmpty()) {
        return;
    }
    StringBuilder query = new StringBuilder("insert into items values");
    entities.forEach(entity -> query.append(String.format(" ('%s','%s'),",
                                                          entity.getId().toString(),
                                                          entity.getValue().toString())));

    entityManager.createNativeQuery(query.substring(0, query.length() - 1))
                 .executeUpdate();
}

Now the code is taking less time to save the data that it was taking to check if ONE data existed.

2025-01-24T18:00:11.585Z DEBUG [] 1672 --- [myapp]  ItemRepositoryImpl     :  -- insertBatch - entities.size() = 490
2025-01-24T18:00:11.595Z DEBUG [] 1672 --- [myapp]  ItemRepositoryImpl     :  -- insertBatch - done
2025-01-24T18:00:11.595Z DEBUG [] 1672 --- [myapp]  ItemRepositoryImpl     :  -- insertBatch - entities.size() = 490
2025-01-24T18:00:11.604Z DEBUG [] 1672 --- [myapp]  ItemRepositoryImpl     :  -- insertBatch - done

This problem gave me a headache, and this happened on a Friday (obviously). I hope this article will help you if you get the same problem or that it will save you from getting through this.

If you liked this article or you found it useful, don’t hesitate to 👏 it or to share it ! 🙂

Why Hibernate is bad for batch saving ? (And how to solve it) was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coder pour les humains : ce que Devoxx m’a appris au-delà du code

Comment choisir parmi une multitude de conférences passionnantes à Devoxx ? Mission presque impossible ! Face aux amphithéâtres parfois complets, j’ai dû improviser et assister à des présentations qui n’étaient pas sur ma liste initiale — plus orientées vers l’humain et le produit que purement techniques. Ce qui m’a rappelé une vérité simple : notre code doit avant tout servir des personnes réelles.

Développer moins, mais mieux ?

Combien d’entre nous continuent à maintenir des fonctionnalités dans leurs applications que personne n’utilise vraiment ? Combien de features restent dans nos produits simplement parce que personne ne s’est posé la question de leur utilité réelle ?

En assistant à “Dans les coulisses des géants de la Tech !”, j’ai découvert comment des entreprises remettent en question chaque fonctionnalité, expérimentent constamment et, surtout, suppriment ce qui n’apporte pas de valeur.

Supprimer des fonctionnalités peut être plus vertueux qu’en ajouter. Si ce que je développe ne sert pas, ou si l’utilisateur n’y accède jamais, alors pourquoi le garder ? Et surtout, pourquoi continuer à le maintenir ?

Et si on testait ce qui compte vraiment ?

Dans la même veine, j’ai repensé ma vision des tests. La démonstration de Playwright était bluffante (des tests end-to-end qui s’écrivent presque tout seuls, comme par magie !). Mais après la conférence sur Gravity, une petite voix intérieure m’a soufflé : “Les parcours que tu testes avec tant de minutie, sont-ils vraiment ceux que tes utilisateurs empruntent chaque jour ? Est-ce que ce sont ceux qui génèrent de la valeur ?”

Je n’ai pas encore toutes les réponses, et à vrai dire, je ne sais pas non plus quels outils me semblent les plus pertinents mais j’ai bien envie de continuer à explorer le sujet. Atteindre 80% de couverture de code, c’est bien. Mais couvrir 100% des fonctionnalités qui créent réellement de la valeur, c’est mieux !

Bonus : on travaille pour des humains mais aussi avec des humains

J’ai trop aimé la conférence “Fighters, Bards, Druids and Wizards in IT” pour ne pas la mentionner. Oui, nos collègues ne pensent pas tous comme nous. Et c’est très bien.
Cette diversité de profils, de modes de communication, de façons de raisonner, peut devenir une vraie force si on prend le temps de l’écouter. Ça m’a rappelé que travailler dans une équipe, c’est aussi savoir se mettre à la place des autres, adapter sa façon de parler, de proposer, de convaincre.

Et finalement, c’est peut-être le fil rouge de tout ça : coder pour des humains, c’est aussi coder avec des humains.

Demain, j’écrirai peut-être encore des tests qui ne sont pas les plus pertinents. Je développerai sûrement des fonctionnalités qui finiront dans les oubliettes numériques. Mais je repars avec de nouvelles question à me poser et à poser. Et ça change déjà tout !

Les conférences qui m’ont inspirée cet article

Les vidéos seront bientôt disponibles — je les partagerai dès leur mise en ligne :

• Dans les coulisses des géants de la Tech ! — Rachel Dubois
• Playwright : tester vos applications devient un jeu d’enfant — Benjamin Cavy
• Fighters, Bards, Druids and Wizards in IT — how to talk to them? — Paweł Zajączkowski
• Au secours ! Mon manager me demande des KPIs ! — Geoffrey Graveaud

Coder pour les humains : ce que Devoxx m’a appris au-delà du code was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nous avions créé notre projet dans Github, avec plusieurs champs personnalisés : Sprint, Estimation, Réalisation. Ces 3 champs nous servent à grouper les tickets par Sprint, et de pouvoir mettre, pour chaque ticket, une estimation ainsi que le temps passé à la réalisation. Ne trouvant pas d’outil satisfaisant sur la plateforme, je me suis lancé dans la création d’un petit outil web statique qui me permettrait de récupérer ces informations.

J’ai commencé par demander à LeChat de me créer un outil HTML + javascript pour récupérer ces données à partir de l’API Github de les mettre en forme dans un tableau. Il a utilisé cette requête pour obtenir les données :

const response = await fetch(`https://api.github.com/repos/${repoOwner}/${repoName}/issues`, {
    headers: {
        Authorization: `token ${token}`
    }
});

Avec ceci j’ai bien eu une partie de ce que je voulais, mais il me manquait toutes les données liées aux champs personnalisés du projet. Aucune de ces données n’apparaissait dans les données de la réponse, et dans la documentation je ne trouvais pas où les récupérer.

Après moultes pérégrinations sur les internets, j’ai fini par trouver cet article de Natalie Somersall : https://some-natalie.dev/blog/graphql-intro/. Dans cet article elle détaille comment accéder à l’API GraphQL de Github pour récupérer des données liées au projet. En effet, quand Github a sorti sa fonctionnalité ProjectV2, les informations liées à ces projets étaient uniquement récupérables via l’API GraphQL (et c’est toujours le cas).

Je me suis basé sur son article pour faire ma première requête, et comme elle met une alerte par rapport à la robustesse de la requête, j’ai demandé à GitHub Copilot comment il utiliserait l’API GraphQL pour récupérer ces informations. Entre ce que j’avais et sa réponse, voici la requête que j’utilise désormais :

query {
    repository(owner: "${repoOwner}", name: "${repoName}") {
      projectsV2(first: 10) {
        nodes {
          title
          items(first: 100, after: "${cursor}") {
            nodes {
              content {
                ... on Issue {
                  number
                  title
                  url
                  assignees(first: 10) {
                    nodes {
                      login
                    }
                  }
                }
              }
              sprint: fieldValueByName(name: "${sprintField}") {
                ... on ProjectV2ItemFieldIterationValue {
                  title
                }
              }
              estimate: fieldValueByName(name: "${estimateField}") {
                ... on ProjectV2ItemFieldNumberValue {
                  number
                }
              }
              consumed: fieldValueByName(name: "${consumedField}") {
                ... on ProjectV2ItemFieldNumberValue {
                  number
                }
              }
            }
            pageInfo {
              hasNextPage
              endCursor
            }
          }
        }
      }
    }
}

Ainsi je récupère bien la valeur des 3 champs personnalisés dans le résultat de la requête, avec une gestion de la pagination. Pour tester rapidement des requêtes vers une API GraphQL, vous pouvez utiliser graphiql qui, avec son IDE, permet de requêter facilement et avec de la complétion. J’ai utilisé l’appImage graphql-playground-electron pour tester différents paramètres.

Voici le résultat dans mon application : il y a une modale qui permet de paramétrer ses accès à GitHub (token, propriétaire du repo, projet)

Puis on peut sélectionner un sprint ou une personne, et voir ses stats suivant les estimations et le temps passé par ticket :

Le code de cet outil est consultable ici. J’espère que vous aurez trouvé ce article intéressant, si jamais vous voulez le modifier pour vos propres besoins projet, n’hésitez pas :).

A la découverte des API Github (REST et GraphQL) was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vous vous demandez probablement quel est le lien entre le choix d’une technologie et l’utilisation finale de WordPress. Eh bien, je vais vous raconter mon expérience récente à ce sujet.

Ma problématique

Pour un nouveau projet, j’ai à réaliser un site vitrine pour mettre en avant le produit. Étant technophile et voulant voir ce qu’il se fait, j’ai testé pas mal d’outils existants : VitePress, Hugo, Jekyll, Docusaurus…

J’ai finalement opté pour Docusaurus pour plusieurs raisons : nous avons besoin d’une documentation, d’une section blog et d’une page d’accueil. Docusaurus répond à tous ces besoins, tout en générant un site statique, optimisé pour le référencement sur les moteurs de recherche. De plus, chez Slickteam, nous utilisons déjà cet outil pour la documentation technique de nos projets, ce qui nous donne l’expérience nécessaire pour le manipuler et le maintenir. Après quelques configurations et ajustements, une première version est en ligne et répond à nos attentes pour le moment.

Le constat : le besoin et ses usagers

Notre besoin principal est de mettre en avant notre travail, notre métier, notre identité, ainsi que les événements auxquels nous participons. En résumé, nous avons besoin d’un outil de communication où nous pouvons présenter et mettre à jour des informations de manière régulière et structurée. Cependant, le choix de Docusaurus pose un problème majeur : la personne responsable de la mise en place des éléments de communication est non-technique et a besoin de pouvoir mettre à jour les informations facilement et de manière autonome. Avec Docusaurus, il est nécessaire d’accéder à Git, de mettre à jour les fichiers concernés, de savoir où ils se trouvent puis de déployer les mises à jour. Ce processus est loin d’être simple pour quelqu’un qui n’a pas de compétences techniques.

Le choix final

Après mûre réflexion, j’ai opté pour WordPress, un choix pragmatique qui répond parfaitement à nos besoins. Tout d’abord, grâce à notre offre d’hébergement, nous pouvons déployer rapidement et simplement une instance WordPress sans surcoût, même pour une personne non-technique. Ensuite, une fois l’outil configuré, une personne avec des compétences techniques de base peut vérifier les paramètres essentiels tels que les DNS, le HTTPS, les extensions et le SMTP. Pour la personnalisation du site, WordPress est un outil no-code, et donc, une personne non-technique peut construire et gérer le contenu du site de manière autonome. Enfin, WordPress répond également à ma préoccupation concernant le référencement sur les moteurs de recherche, ce qui a définitivement confirmé mon choix.

Conclusion

J’ai toujours eu cette envie de découvrir de nouveaux outils et de nouvelles technologies, et cela n’a pas changé. Je pense que j’aurai toujours cette inclination technophile à vouloir explorer de nouvelles choses. Cependant, il est crucial de garder à l’esprit le besoin et le contexte associé pour choisir l’outil ou la technologie la plus pertinente. Vouloir à tout prix tester quelque chose de nouveau ou de “hype” n’est pas toujours la meilleure option. En tout cas, c’est la conclusion personnelle que j’en tire.

Merci d’avoir lu cet article. J’espère que mon point de vue sur le sujet vous a peut-être amené à vous poser des questions (ou peut-être que c’était déjà une évidence pour vous).

Si vous avez apprécié cet article, n’hésitez pas à 👏 ou à le partager.

J’arrête les JO de la tech : retour sur cette sombre histoire de WordPress ! was originally published in Slickteam on Medium, where people are continuing the conversation by highlighting and responding to this story.