Ouidou

Ouidou et Scaleway : un partenariat stratégique pour accélérer le cloud souverain en Europe

Emmie Pommeret — Wed, 08 Apr 2026 16:55:09 +0000

L’article Ouidou et Scaleway : un partenariat stratégique pour accélérer le cloud souverain en Europe est apparu en premier sur Ouidou.

JTE : un moteur de templates moderne, rapide et sécurisé pour Java

Emmie Pommeret — Mon, 09 Mar 2026 09:34:01 +0000

Écrit par Thusitha T.

Introduction

Les moteurs de templates occupent une place clé dans la création de vues côté serveur, l’envoi d’emails personnalisés ou encore la génération de fichiers HTML à partir de données Java. Bien que des outils tels que Thymeleaf, FreeMarker ou Velocity soient populaires, un nouvel acteur a réussi à se démarquer grâce à sa performance et sa facilité d’utilisation : JTE (Java Template Engine).
Cet article vous propose une introduction à JTE, incluant ses principes opérationnels et ses bénéfices techniques, tout en fournissant un aperçu de son intégration au sein d’un projet Java modern.

Qu’est-ce que JTE ?

JTE (Java Template Engine) est un moteur de templates compilé, créé en 2020, qui vise à offrir une alternative plus rapide, sécurisée et typée aux moteurs de templates traditionnels utilisés dans les applications Java.
Contrairement à des solutions interprétées comme Thymeleaf ou FreeMarker, JTE compile les templates en classes Java au moment du build. Cela lui permet d’obtenir des performances proches de celles du code natif, tout en garantissant la détection d’erreurs à la compilation.

Objectif principal

JTE vise à fournir un moteur de templates modern pour Java, approprié aux contextes de haute performance (API, microservices, applications server-side rendering, etc.), tout en maintenant une simplicité d’apprentissage.

Les atouts majeurs

Haute Performance

L’un des atouts les plus marquants de JTE est dans sa rapidité d’exécution.

En effet, JTE supprime la phase d’interprétation. Les fichiers .jte sont transformés en classes Java lors de la compilation. Ainsi, les modèles sont donc directement exécutés comme du code Java optimisé par la JVM.

Des comparaisons indépendantes ont démontré que JTE peut être plus rapide que Thymeleaf ou FreeMarker dans différents scénarios.

Sécurité renforcée

En appliquant une échappement automatique du HTML et des autres formats (XML, JSON, etc.), JTE réduit drastiquement les risques d’injections XSS (Cross-Site Scripting).
De plus, comme les templates sont compilés, il n’y a aucune exécution dynamique de code, contrairement à d’autres moteurs plus permissifs.

Typage fort et vérification à la compilation

Etant donné que les templates JTE sont vérifiés à la compilation, si un champ ou une méthode n’existe plus dans un objet passé au template, l’erreur est détectée avant le déploiement, et non à l’exécution.

Intégration fluide

JTE ne nécessite pas de configuration complexe.
Un simple ajout de dépendance Maven ou Gradle suffit pour l’utiliser dans un projet Java.
Il s’intègre facilement avec des frameworks comme Spring Boot.

Installation


    gg.jte
    jte-spring-boot-starter-3
    3.2.1


    gg.jte
    jte
    3.2.1

Les fichiers .jte placés dans src/main/resources/templates seront automatiquement détectés et rendus via les contrôleurs Spring (@Controller + ModelAndView).

Structure de base

src/
 ├─ main/
 │   ├─ java/
 │   ├─ resources/
 │   │   └─ templates/
 │   │       └─ hello.jte

Exemple de template `hello.jte`

@import java.time.LocalDateTime

  
    Hello ${name}!
    Nous sommes le ${LocalDateTime.now()}.

Contrôleur

import org.springframework.web.servlet.ModelAndView;
@GetMapping("/hello")
public ModelAndView hello() {
  return new ModelAndView("hello", Map.of("name", "Jean"))
}

Classe Java générée du template

package jte;
import gg.jte.TemplateOutput;
import gg.jte.html.HtmlTemplateOutput;
import gg.jte.runtime.Template;
import java.time.LocalDateTime;
import java.util.Map;
public final class JtehelloGenerated implements Template {
  @Override
  public void render(Map params, TemplateOutput output) {
    String name = (String) params.get("name");
    output.writeContent("\n  \n    Hello ");
    output.writeUserContent(name);
    output.writeContent("!
\n    Nous sommes le ");
    output.writeUserContent(LocalDateTime.now());
    output.writeContent(".\n  \n");
  }
  @Override
  public static void render(Map params, HtmlTemplateOutput output) {
    new JtehelloGenerated().render(params, output);
  }
}

Explications

Le fichier .jte est transformé en une classe Java qui implémente l’interface gg.jte.runtime.Template et tout le contenu statique HTML est injecté via output.writeContent(...).

Les variables quant à elles (${name}, ${LocalDateTime.now()}) deviennent des appels Java typés et sûrs.

La méthode render est appelée par le moteur JTE lors de l’exécution.

Résultat affiché


  
    Hello Jean!
    Nous sommes le 2025-10-23T14:35:10.123.

Exemples d’utilisation de JTE

Affichage conditionnel

@if(isAdmin)
  Bienvenue, administrateur ${userName}.
@else if(isGuest)
  Bienvenue, invité.
@else
  Bienvenue, utilisateur.
@end

Etant donné que le template est compilé en if / else Java, aucune erreur n’est possible à l’exécution.

Boucle `for` (`foreach`)


@for(Product product : products)
  ${product.getName()} — ${product.getPrice()} €
@end

Fragment réutilisable

Supposons que nous avons le fragment fragments/header.jte :

@param String title

  ${title}

En appelant ce dernier dans le template suivant :

@template.views.fragments.header(
  title = "Accueil"
)

  Bienvenue sur notre site !

Nous aurons le résultat suivant :


  Accueil


  Bienvenue sur notre site !

Limites et points de vigilance avec JTE

Même si JTE se distingue par ses performances et sa sécurité, il est important de connaitre ses limites avant de l’adopter dans un projet.

Recompilation après chaque modification

Vu que JTE travaille avec des templates compilés, lorsqu’on modifie un .jte, les modifications seront prises en compte seulement après recompilation.

Communauté encore jeune

Comparé à Thymeleaf ou FreeMarker, JTE dispose d’une communauté plus restreinte.
La documentation officielle est claire mais moins riche en exemples et moins d’intégrations tierces existent pour l’instant (tags Spring Security, intégrations JSP, etc.).

Moins d’écosystème autour des extensions

En misant sur la simplicité et la performance, JTE a un écosystème plus fermé que par exemple Thymeleaf qui propose des dialectes et des extensions personnalisables. Autrement dit, si le projet a besoin de tags ou de macros complexes, JTE sera moins adapté.

Extensions et plugins JTE encore limités

JTE propose plusieurs plugins officiels pour l’intégration dans les outils de build, mais ils restent moins matures que ceux des moteurs plus anciens :

Plugin	Description	Limitation actuelle
jte-maven-plugin	Compile les templates `.jte` lors du `mvn compile`	Peu documenté, nécessite une configuration manuelle des chemins
jte-gradle-plugin	Compilation automatique dans Gradle	Incompatible avec certains environnements Gradle anciens (< 7)
jte-intellij-plugin	Coloration syntaxique et autocomplétion	Support partiel, pas encore complet sur les `@include` et `@param`
jte-spring-boot-starter	Intégration MVC avec Spring Boot	Fonctionne bien mais peu d’exemples complexes dans la doc

Il n’y a exemple aucun plugin sur Eclipse ou VS Code permettant d’avoir la coloration syntaxique et l’autocomplétion.

Pas de Virtual DOM ni de rendu réactif

JTE est un moteur de rendu côté serveur pur :
il ne propose aucun Virtual DOM, ni mécanisme de réconciliation des changements de données comme le font des bibliothèques front-end (React, Vue, Svelte…).

Chaque rendu JTE recrée le HTML complet à partir du serveur, sans mise à jour partielle du DOM côté client.

Cela signifie que toute modification d’état nécessite un nouvel appel serveur et un rechargement complet de la vue.

Conclusion

JTE s’impose aujourd’hui comme une alternative aux moteurs historiques de templates Java.
Son approche compilée, son typage fort et sa sécurité intégrée en font un choix pertinent pour les développeurs cherchant à améliorer les performances et la fiabilité de leurs applications Java.

Autrement dit, il peut être l’idéal pour les applications où le contenu est statique au build (templates de mails, vues serveur, génération de rapports HTML). Par contre, s’il s’agit d’un projet avec des templates très dynamique, très intéractifs ou orientés utilisateur, un framework front moderne reste plus adapté.

Liens utiles

Documentation officielle : jte: Java Template Engine – jte
Repo GitHub : GitHub – casid/jte: Secure and speedy templates for Java and Kotlin.
Intégration avec Spring Boot : jte Spring Boot 3 Starter – jte

L’article JTE : un moteur de templates moderne, rapide et sécurisé pour Java est apparu en premier sur Ouidou.

La Sobriété Numérique, de la quantification des émissions carbone des applications à la mise en œuvre des corrections

Emmie Pommeret — Mon, 16 Feb 2026 08:58:11 +0000

Écrit par Hudson T.

Qu’est que c’est La Sobriété Numérique

Selon l’ADEME, dans une étude réalisée en 2020, 2,5 % de l’empreinte carbone de la France est liée au numérique, avec 10 % de la consommation annuelle d’énergie attribuée aux services numériques. Pour atteindre la transition écologique définie par la France, la mesure des émissions de carbone et la mise en œuvre de mesures d’atténuation des risques sont essentielles pour un avenir durable.

Dans cette perspective, nous appliquons les principes de la sobriété numérique, qui consistent à concevoir des services numériques plus économes, afin de réduire les impacts environnementaux et la consommation d’énergie des technologies, par exemple lors de la navigation sur internet et de l’utilisation d’applications web sur les ordinateurs et les téléphones portables.

La Sobriété Numérique dès la conception de l’application

La conception d’une application web implique plusieurs facteurs importants, en particulier si l’on considère l’empreinte carbone associée à l’utilisation de ces applications. Pour réduire la consommation d’énergie, il est nécessaire d’analyser des aspects tels que :

Cible : évaluer la taille et les habitudes du public qui utilisera la plateforme et sa fréquence d’utilisation, car le nombre d’accès est directement lié aux émissions générées.
Technologies utilisées : choisissez des technologies web modernes mais moins gourmandes en énergie, qui évitent le chargement continu des pages web et la répétition des requêtes et des connexions.
Requêtes HTTP : réduire le nombre de requêtes effectuées lors de l’utilisation de l’application, en minimisant les appels redondants.
Taille des fichiers : optez pour des fichiers plus petits et optimisés, tels que des images compressées, du HTML, CSS et JavaScript minifiés.
Infrastructure d’hébergement : vérifiez la répartition géographique des serveurs afin de réduire la latence et d’améliorer le chargement. Privilégiez les hébergeurs qui utilisent des énergies renouvelables.

De nombreuses pratiques d’éco-conception sont également directement liées à l’expérience utilisateur (UX) et à l’interface (UI). Au cours du processus de conception, il est essentiel de réduire le nombre d’actions nécessaires à l’utilisateur pour atteindre ses objectifs, en optimisant les flux et les interfaces. Une conception simple et fonctionnelle permet non seulement de minimiser l’impact sur l’environnement, mais aussi de créer des applications plus agréables à utiliser.

Comment mesurer l’empreinte carbone des applications web

Globalement, la navigation sur Internet est directement liée à la consommation d’énergie des applications. Il est donc possible de mesurer l’impact carbone des applications en prenant en compte l’énergie consommée lors de leur utilisation.

Pour ce faire, il existe des outils qui permettent de calculer l’empreinte carbone en tenant compte de la matrice énergétique du pays, du pourcentage d’énergies renouvelables utilisées et de l’empreinte carbone moyenne des sites de la région. Une solution existante est le site Ecoindex et l’extension GreenIt – Analyses qui fournissent un rapport sur la quantité de code inutilisé sur la page, le nombre d’images plus grandes que nécessaire et indiquent même les formats d’image qui pourraient être modifiés pour réduire la consommation d’énergie et les émissions de CO₂ lors du téléchargement. Ils vérifient également si l’hébergeur du site utilise de l’énergie renouvelable sur ses serveurs, en utilisant l’outil de The Green Web Foundation.

Figure 1 : Exemple d’évaluation de l’EcoIndex par l’extension GreenIt.

Comment mettre en œuvre L’Eco-conception lors de la rédaction du code

Les stratégies à utiliser pour chaque projet doivent être adaptées à ses caractéristiques spécifiques. Nous vous présentons quelques exemples concrets de bonnes pratiques illustrant comment certaines décisions techniques peuvent influencer directement la performance et la maintenabilité d’une application.

Dans les applications React

Il est important d’éviter les re-rendus inutiles. Cela peut se faire en utilisant React.memo pour prioriser les rendus uniques. Il faut également être attentif à l’utilisation des hooks : par exemple, privilégier useMemo pour les variables qui ne changent pas entre les rendus ou pour les opérations simples, plutôt que de recourir à useState lorsqu’il n’est pas nécessaire. Une autre bonne pratique consiste à mettre en cache les informations afin de réduire les appels HTTP redondants et inutiles.

Dans les applications Java

Il est recommandé d’envisager l’utilisation de Hibernate pour abstraire la base de données. Afin d’optimiser les performances, il est aussi possible de tirer parti du cache de second niveau proposé par Hibernate, qui diminue significativement le nombre d’accès à la base de données.

Dans toutes les applications, il est tout aussi important de s’assurer que les changements souhaités sont effectivement observés dans le code, et de vérifier les points définis au cours du développement. Il est essentiel que notre CD/CI soit adaptée à cet effet. Il existe différents modèles qui contrôlent les applications et leurs résultats en fonction de l’évolution du code, comme le Template Eco-CI fourni par Green Coding.

Une autre solution simple consiste à utiliser le plugin creedengo dans le logiciel SonarQube, le logiciel d’analyse statique de code utilisé dans la plupart des CI existantes. Le plugin permet d’ajouter des règles d’analyse au champ d’application du logiciel, visant à identifier les problèmes d’éco-conception, permettant de les corriger au fur et à mesure de l’écriture du code, dans de nombreux langages tels que Java, JavaScript, PHP, Python et C#. Bien que très récent et en cours de développement, l’outil est déjà disponible pour la version 9.4.+ de SonarQube. Le plugin vous permet d’ajouter de nouvelles règles à marquer avec la balise creedengo comme indiqué ci-dessous.

Ci-dessous, nous présentons un exemple d’identification d’un problème d’éco-conception dans un code Java, signalé par SonarQube avec le plugin installé. Comme on peut le constater, notre code présente un problème de performance marqué avec le tag creedengo, qui indique une inefficacité liée à l’appel de la fonction size à l’intérieur d’une boucle.

Figure 2 : Exemple d’analyse SonarQube avec des erreurs de performance remontées par creedengo.

Ce comportement est problématique car la fonction size est évaluée à chaque itération, entraînant une consommation inutile de cycles CPU et, par conséquent, une augmentation de la consommation énergétique.

SonarQube propose une solution : stocker la valeur retournée par la fonction size dans une variable avant la boucle. Cela permet d’éviter de recalculer la taille de la collection à chaque itération, améliorant ainsi l’efficacité du code tout en réduisant son impact énergétique.

Figure 3 : Exemple de proposition SonarQube avec creedengo pour améliorer l’efficacité.

Conclusion

La sobriété numérique est cruciale pour réduire l’impact environnemental des services numériques. En adoptant des pratiques d’éco-conception, en optimisant le code et en mesurant les émissions de carbone, il est possible de réduire la consommation énergétique tout en améliorant l’expérience utilisateur. Cela soutient la transition écologique et permet aux entreprises de répondre aux attentes croissantes des consommateurs et des régulateurs en matière de durabilité. Cela renforce également leur image de marque et leur engagement envers l’environnement.

Sources

Outils de mesure mentionnés

Quelques ressources pour aller plus loin…

L’article La Sobriété Numérique, de la quantification des émissions carbone des applications à la mise en œuvre des corrections est apparu en premier sur Ouidou.

Introduction pratique au Q-learning avec Gymnasium Taxi-v3

Emmie Pommeret — Tue, 06 Jan 2026 10:12:18 +0000

Écrit par Kévin A.

Introduction

L’apprentissage par renforcement (Reinforcement Learning, ou RL) est une branche de l’intelligence artificielle dans laquelle un agent IA apprend à prendre des décisions par essai-erreur. Contrairement à l’apprentissage supervisé, il n’existe pas de réponses toutes faites : l’agent explore son environnement et améliore ses choix grâce aux récompenses reçues.

Aujourd’hui nous allons découvrir Gymnasium, une bibliothèque open source proposant de nombreux environnements simulés. Dans cet article, nous allons explorer l’environnement Taxi-v3. Dans cet environnement, le but est simple : déplacer le taxi pour récupérer un passager et le déposer à sa destination le plus efficacement possible.

Nous allons découvrir comment entraîner notre agent à accomplir cette tâche en utilisant le Q-Learning, un algorithme à la fois simple et particulièrement efficace.

Comprendre le Q-Learning et la Q-Table

La Q-Table

Le Q-Learning est un algorithme basé sur une Q-Table, une matrice où chaque ligne correspond à un état possible, et chaque colonne à une action. La valeur dans la case Q(s,a) indique la “qualité” de choisir l’action a dans l’état s.

Au départ, la Q-Table est remplie de zéros. L’agent IA apprend progressivement à mettre à jour cette table en interagissant avec l’environnement.

La formule de mise à jour

Chaque fois que le taxi prend une action et reçoit une récompense, la Q-Table est mise à jour selon :

α (alpha): taux d’apprentissage (généralement entre 0 et 1, mais peut être supérieur dans certains cas spéciaux), correspond au paramètre lr dans notre fonction.
γ (gamma): facteur d’actualisation qui valorise les récompenses futures, correspond au paramètre gamma dans notre fonction.
r : récompense immédiate.
s,a : état et action actuels.
s′ : nouvel état après action.

Dans notre implémentation, cette formule est appliquée avec les valeurs par défaut de lr = 0.1 et gamma = 0.99, ce qui signifie que l’agent apprend modérément vite et accorde une grande importance aux récompenses futures.

Stratégie d’exploration

Pour éviter que l’agent ne se contente d’une stratégie sous-optimale, on utilise une approche ε-greedy :

L’approche ε-greedy équilibre exploration et exploitation en Q-learning : l’agent explore aléatoirement avec une probabilité ε, sinon il choisit la meilleure action connue. Un ε élevé favorise l’exploration (utile au début), tandis qu’un ε faible privilégie l’exploitation des connaissances acquises.

Le epsilon decay consiste à réduire progressivement la valeur de ε au cours de l’entraînement. Cette diminution graduelle permet de commencer par une exploration intensive pour découvrir l’environnement, puis de converger vers une stratégie stable en privilégiant l’exploitation des connaissances.

Plusieurs approches existent pour implémenter cette décroissance :

La décroissance exponentielle utilise la formule ε = ε_initial × decay_rate^épisode et offre une réduction rapide au début qui ralentit progressivement.
La décroissance linéaire applique une réduction constante à chaque épisode avec ε = ε_initial – (decay_step × épisode).
Une approche particulièrement populaire est la décroissance avec plancher, qui suit ε = max(ε_min, ε × decay_rate) et maintient un niveau minimal d’exploration permanent, évitant que l’agent devienne trop rigide.
Enfin, la décroissance inverse propose une formule ε = ε_initial / (1 + decay_rate × épisode) pour une décroissance douce et continue.

Chaque approche offre un compromis différent entre vitesse de convergence et maintien de l’exploration, le choix dépendant de la complexité de l’environnement et des objectifs d’apprentissage.

Description du problème

Dans Taxi-v3, le joueur (notre agent IA) contrôle un taxi dans une grille de 5×5 cases. Sa mission est simple : récupérer un passager à un point donné et le déposer à la bonne destination.

L’environnement nous met à disposition tous les éléments nécessaires pour définir le problème d’apprentissage par renforcement de manière claire et structurée.

États : position du taxi, position du passager (4 emplacements possibles ou “dans le taxi”), et destination (4 emplacements possibles). Cela donne 500 états possibles.
Actions : 6 choix sont disponibles – se déplacer au nord, sud, est, ouest, prendre un passager, déposer un passager.
Récompenses :
- +20 si le passager est déposé au bon endroit.
- -10 si le taxi tente une mauvaise action (par exemple déposer sans passager).
- -1 pour chaque pas, afin d’encourager une solution rapide.

Implémentation en Python

Voici une version simplifiée de l’entraînement avec Q-Learning :

import gymnasium as gym
import numpy as np
# Création de l'environnement Taxi
env = gym.make("Taxi-v3")
# Initialisation de la Q-Table
state_space = env.observation_space.n
action_space = env.action_space.n
Q = np.zeros((state_space, action_space))
# Hyperparamètres
alpha = 0.1     # taux d'apprentissage
gamma = 0.6     # facteur d'actualisation
epsilon = 0.1   # exploration
episodes = 10000
# Entraînement
for episode in range(episodes):
    state, _ = env.reset()
    done = False
    while not done:
        if np.random.uniform(0,1) < epsilon:
            action = env.action_space.sample()  # exploration
        else:
            action = np.argmax(Q[state])        # exploitation
        next_state, reward, done, truncated, info = env.step(action)
        # Mise à jour de la Q-Table
        best_next_action = np.argmax(Q[next_state])
        Q[state, action] = Q[state, action] + alpha * (
            reward + gamma * Q[next_state, best_next_action] - Q[state, action]
        )
        state = next_state

Après un entraînement de 10000 épisodes comme dans notre exemple (quelques minutes) le taxi apprend à résoudre efficacement sa mission.

Résultats et analyse

Évaluation de l’agent

Une fois entraîné, l’agent peut être évalué sur plusieurs parties de test. Les métriques typiques sont :

score moyen par épisode,
nombre moyen d’étapes nécessaires pour déposer le passager.

En général, après un bon entraînement, l’agent réussit sa mission en moins de 20 étapes.

Visualisation des performances

On peut tracer la progression du score moyen :

import matplotlib.pyplot as plt
# Liste des récompenses obtenues à chaque épisode d'entraînement
plt.plot(rewards_per_episode) 
# Axe horizontal : numéro de l'épisode (de 0 à nombre total d'épisodes)
plt.xlabel("Épisodes") 
# Axe vertical : récompense cumulée par épisode
plt.ylabel("Score moyen") 
# Titre du graphique montrant l'évolution des performances
plt.title("Progression du taxi avec Q-Learning") 
# Affiche le graphique pour visualiser l'apprentissage de l'agent
plt.show()

Voici par exemple un des graphiques de l’entraînement de notre agent. Ce graphique montre comment notre taxi apprend au fil du temps grâce au Q-Learning.

Plusieurs choses sont affiché sur ce graphique.

l’axe horizontal, chaque point correspond à un épisode d’entraînement, c’est-à-dire une partie que joue notre taxi. Plus on avance vers la droite, plus l’agent a eu d’occasions d’apprendre.

l’axe vertical, on y voit deux choses : En orange, on voit le nombre d’étapes que l’agent met pour terminer une partie. Au départ, ce nombre est très élevé (l’agent échoue souvent et atteint la limite de 200 actions), puis il diminue progressivement à mesure que le taxi apprend à être plus efficace.

En vert, les récompenses obtenues par l’agent, elles vont très loin dans le négatif au départ, puis augmentent et se stabilisent quand le taxi apprend à bien jouer.

La ligne rouge, elle représente l’exploration. Au début, le taxi teste un peu tout au hasard (l’epsilon est élevé). Au fur et à mesure, il explore moins et applique ce qu’il a appris (l’epsilon diminue jusqu’à 0).

Notre graphique illustre l’évolution des récompenses et du nombre de pas, où l’on observe une stabilisation progressive (convergence) des performances lorsque l’agent apprend une stratégie optimale, tandis que l’epsilon décroît vers zéro.

Optimiser les performances de l’algorithme Q-Learning

Une fois l’algorithme fonctionnel, il est intéressant de chercher à accélérer l’apprentissage et les performances finales de notre agent. Cela passe par l’optimisation des hyperparamètres.

Le taux d’apprentissage (lr)

Le taux d’apprentissage détermine l’importance accordée aux nouvelles informations par rapport aux connaissances déjà acquises dans la Q-Table. Dans notre approche, la valeur par défaut est fixée à 0.1 (sur une échelle de 0 à 1). Un taux trop faible entraîne un apprentissage très lent car l’agent intègre difficilement les nouvelles expériences, tandis qu’un taux trop élevé provoque des changements trop brutaux qui effacent les apprentissages précédents.

Le facteur de discount (gamma)

Le facteur de discount détermine quelle importance l’agent accorde aux récompenses futures par rapport à celles qu’il peut obtenir immédiatement. Notre implémentation utilise une valeur par défaut de 0.99 (sur une échelle de 0 à 1). Un gamma faible incite l’agent à rechercher des gains immédiats sans se soucier des conséquences, alors qu’un gamma élevé le pousse à prendre des décisions qui peuvent être moins avantageuses maintenant mais plus bénéfiques à long terme.

La probabilité d’exploration (epsilon)

La probabilité d’exploration équilibre entre l’exploration aléatoire de nouvelles actions et l’exploitation des meilleures actions connues. Notre approche utilise un decay exponentiel avec la formule : epsilon = min_epsilon + (max_epsilon – min_epsilon) * exp(-epsilon_decay * episode).

Nos paramètres sont configurés avec :

un epsilon initial de 0.3 pour une exploration modérée au début,
un max_epsilon de 1.0 permettant une exploration maximale si nécessaire,
un min_epsilon de 0.001 pour une exploitation quasi-totale en fin d’entraînement,
et un epsilon_decay de 0.1 pour une décroissance progressive.

Cette configuration permet une transition fluide de l’exploration vers l’exploitation, avec un suivi de l’évolution d’epsilon via epsilon_vec pour analyser le comportement de l’agent.

epsilon = 1.0
epsilon_min = 0.01
epsilon_decay = 0.995
for episode in range(episodes):
    ...
    epsilon = max(epsilon_min, epsilon * epsilon_decay) #  Décroissance avec plancher

Le nombre d’épisodes

Plus il y a d’épisodes, plus l’agent a de chances de converger.
Comme nous pouvons le voir sur le graphique d’entraînement, nous atteignons un point de convergence autour de 20 000 épisodes

Comparer les résultats

La meilleure façon de trouver les bons réglages est de tester plusieurs combinaisons et de comparer les courbes de performance. Une approche simple est la recherche par grille (grid search) : tester différentes valeurs de α, γ, ε et observer la convergence.

def grid_search():
    learning_rates = [0.001, 0.01, 0.1]
    gammas = [0.9, 0.95, 0.99]
    epsilons = [0.1, 0.2, 0.3]
    epsilon_decays = [0.001, 0.01, 0.1]
    best_params = None
    best_reward = float('-inf')
    for lr, gamma, epsilon, epsilon_decay in itertools.product(learning_rates, gammas, epsilons, epsilon_decays):
        print(f"Training with lr={lr}, gamma={gamma}, epsilon={epsilon}, epsilon_decay={epsilon_decay}")
        _, mean_reward = train(env=gym.make("Taxi-v3"),
                               episodes=1000,
                               lr=lr,
                               gamma=gamma,
                               epsilon=epsilon,
                               epsilon_decay=epsilon_decay)
        if mean_reward > best_reward:
            best_reward = mean_reward
            best_params = (lr, gamma, epsilon, epsilon_decay)
    print(f"Best parameters: lr={best_params[0]}, gamma={best_params[1]}, epsilon={best_params[2]}, epsilon_decay={best_params[3]}")
    print(f"Best mean reward: {best_reward}")
grid_search()

Cette méthode peut être améliorée en élargissant la plage de valeurs testées pour chaque paramètre et en augmentant la granularité de la recherche.

Limites du Q-Learning

Même si le Q-Learning fonctionne très bien pour un petit environnement comme Taxi, il présente des limites importantes. La scalabilité constitue un problème majeur car la Q-Table grandit de manière exponentielle quand l’espace d’états devient énorme, rendant impossible son stockage en mémoire vive (RAM) pour des environnements complexes.

De plus, l’algorithme souffre d’un manque de généralisation puisqu’il ne peut pas apprendre sur des états qu’il n’a jamais rencontrés auparavant. Enfin, l’exploration ε-greedy reste une approche basique, alors que d’autres méthodes comme l’exploration de Boltzmann ou UCB (Upper Confidence Bound) offrent des stratégies plus intelligentes.

Pour dépasser ces limites, on peut utiliser des réseaux de neurones pour approximer la fonction Q. C’est le principe des Deep Q-Networks (DQN), utilisés dans des environnements beaucoup plus complexes comme les jeux vidéos, la robotique ou d’autres domaines nécessitant une représentation continue des états.

Visualisation de l’agent

Gymnasium permet de visualiser le plateau de jeu avec :

import gymnasium as gym
env = gym.make("Taxi-v3", render_mode="human")
print(env.render())

Nous avons accès à plusieurs valeurs possibles pour le paramètre render_mode. (ansi, rgb_array, rgb_array_list, human).

Pour cet article nous utiliserons le render_mode “human” qui offre la meilleure visualisation graphique interactive en temps réel.

Et voilà notre agent à l’œuvre !

Conclusion

J’espère vous avoir fait découvrir un sujet intéressant à travers cet article. L’environnement Taxi-v3 est un excellent point d’entrée dans l’IA. Il offre une complexité suffisante pour comprendre les mécanismes fondamentaux tout en restant accessible.

Cet exemple pratique nous a donné un aperçu complet de l’apprentissage par renforcement. Nous avons vu la construction de la Q-Table et l’optimisation des hyperparamètres. Nous avons observé comment un agent développe une stratégie optimale par l’expérience seule, sans supervision directe.

Le Q-Learning s’applique concrètement dans plusieurs domaines. Par exemple, l’optimisation de systèmes de recommandation où l’agent apprend à proposer le contenu le plus pertinent. Ou encore la gestion automatique des ressources serveur pour optimiser les performances. Il peut aussi développer des chatbots qui s’améliorent grâce aux retours utilisateurs. Ces applications montrent qu’un algorithme simple peut résoudre des problèmes complexes du monde réel.

Pour approfondir vos connaissances, plusieurs pistes s’offrent à vous. Explorez d’autres environnements Gymnasium plus complexes. Expérimentez avec des variantes comme SARSA. Ou orientez-vous vers le Deep Reinforcement Learning avec les DQN pour des problèmes nécessitant une représentation continue des états.

liens utiles

Le projet :
https://gitlab.tech.ouidou.fr/kevin.aubel/q-learning

Articles similaire:

Q-Learning in Reinforcement Learning – GeeksforGeeks

A Beginner’s Guide to Q-Learning: Understanding with a Simple Gridworld Example

Reinforcement Learning 101

Site avec implementation de Q-learning:
Search | Kaggle

simonescaccia/dqn-Taxi-v3 · Hugging Face

winkin119/q-Taxi-v3 · Hugging Face

L’article Introduction pratique au Q-learning avec Gymnasium Taxi-v3 est apparu en premier sur Ouidou.

Introduction à K6

Emmie Pommeret — Tue, 09 Dec 2025 13:14:00 +0000

Écrit par Mouloud H.

Définitions des types de tests

Avant de plonger dans l’utilisation de K6, il est important de comprendre les différents types de tests qu’il permet de réaliser :

Smoke testing : Un test rapide visant à valider que le système ou le script fonctionne correctement sous une charge minimale. Souvent appelé “test de santé”, il s’agit d’une méthode préliminaire pour vérifier que les fonctionnalités essentielles de l’application fonctionnent correctement avant de procéder à des tests plus approfondis. Cela permet de s’assurer qu’il n’y a pas de problèmes critiques, comme des erreurs empêchant l’application de démarrer ou de répondre correctement à des requêtes simples.
Load testing : Ce type de test mesure les performances du système sous une charge normale ou attendue. L’objectif est de vérifier comment le système se comporte dans des conditions standard d’utilisation.
Stress testing : Ici, le test pousse le système au-delà de ses limites normales pour évaluer sa stabilité et sa résilience sous une charge extrême.
Soak testing : Aussi appelé test d’endurance, il évalue les performances et la fiabilité du système sur une période prolongée, permettant d’identifier les éventuelles fuites de mémoire ou autres problèmes de stabilité à long terme.

Qu’est-ce que K6 ?

K6 est un outil de test de charge open source, conçu pour les développeurs et les équipes DevOps. Il permet de simuler des charges réalistes sur des applications web et des API, afin de tester leurs performances et leur évolutivité. Développé en Go et racheté par Grafana Labs en 2021, K6 offre une solution complète pour détecter les régressions de performance et construire des systèmes robustes.

Pourquoi utiliser K6 ?

Simplicité d’utilisation : Facile à installer et à utiliser, avec une prise en main rapide grâce à JavaScript pour la rédaction des scripts.
Haute performance : Consomme moins de ressources que les outils basés sur la JVM comme Gatling ou JMeter.
Polyvalence : Convient pour différents types de tests, comme le smoke testing, le load testing, le stress testing ou encore le soak testing.
Visualisation des données : Compatible avec des outils comme Grafana et Datadog pour des tableaux de bord interactifs et un suivi en temps réel.
Open source et gratuit : Accessible à tous sans frais, avec une documentation complète.

Fonctionnalités principales

K6 se distingue par plusieurs fonctionnalités majeures, qui en font un outil très polyvalent et puissant pour les tests de performance :

Tests de charge : Cette fonctionnalité permet de simuler des milliers d’utilisateurs simultanés pour évaluer la résilience de vos applications. Par exemple, vous pouvez identifier comment votre serveur répond lorsqu’un grand nombre d’utilisateurs accèdent simultanément à une API ou à un site web. C’est essentiel pour anticiper les comportements lors de pics d’activité ou lors d’événements promotionnels importants.
Tests de performance : Avec K6, vous pouvez analyser les goulets d’étranglement dans vos systèmes. Cela inclut la détection de lenteurs dans les bases de données, les appels réseau ou encore les API tierces. Grâce à des métriques détaillées, comme le temps moyen de réponse ou les percentiles, vous obtenez une vue complète des performances de votre application sous diverses charges.
Tests fonctionnels : Validez les comportements attendus de vos API même sous des charges importantes. Par exemple, vous pouvez vous assurer que les réponses aux requêtes respectent bien les spécifications (codes HTTP, contenu attendu, etc.), garantissant ainsi une qualité de service optimale.
Métriques personnalisées : K6 permet de définir vos propres métriques en fonction de vos besoins spécifiques. Par exemple, vous pouvez mesurer le taux d’erreur, le temps de traitement d’une requête ou encore le pourcentage de requêtes réussies. Ces métriques offrent une flexibilité et une précision accrues pour vos analyses.
Rapports détaillés : Les rapports générés par K6 incluent des données complètes sur les performances de vos tests. Vous pouvez visualiser les tendances, les erreurs et les temps de réponse sous différentes formes, facilitant ainsi la prise de décision pour optimiser votre application.
Gestion des scénarios avancés : K6 offre une configuration flexible des scénarios de test, permettant de simuler des comportements proches de ceux des utilisateurs réels. Cela inclut la possibilité de moduler progressivement la charge, d’ajouter des délais entre les actions des utilisateurs ou de tester différentes étapes d’un processus utilisateur complexe.

Prise en main avec K6

Installation

Pour installer K6, utilisez le gestionnaire de paquets approprié à votre système :

Sous macOS

brew install k6

Sous Linux

sudo apt update && sudo apt install -y k6

Sous Windows

Téléchargez l’exécutable et ajoutez-le à votre PATH.

Création d’un script de test

Un script K6 est écrit en JavaScript ES6. Voici un exemple simple pour tester une API :

import http from 'k6/http';
import { check } from 'k6';
export default function () {
    const res = http.get('http://localhost:3000/slow');
    check(res, {
        'status est 200': (r) => r.status === 200,
    });
}

Présentation du serveur Express

Pour les tests réalisés avec K6, nous avons utilisé un petit serveur Express local qui simule deux types de requêtes : une requête rapide et une requête lente. Ce serveur est conçu pour servir de base à nos tests de charge et de performance.

Voici le code de ce serveur :

const express = require('express');
const app = express();
const port = 3000;
app.get('/fast', (req, res) => {
    setTimeout(() => res.send('Fast response!'), 50);
});
app.get('/slow', (req, res) => {
    setTimeout(() => res.send('Slow response!'), 2000);
});
app.listen(port, () => {
    console.log(`Server running at http://localhost:${port}`);
});

Exécution d’un test

Pour exécuter le script ci-dessus, utilisez la commande suivante :

k6 run script.js

Le résultat obtenu est le suivant :

checks.........................: 100.00% 1 out of 1
     data_received..................: 241 B   120 B/s
     data_sent......................: 84 B    42 B/s
     http_req_blocked...............: avg=1.26ms min=1.26ms med=1.26ms max=1.26ms p(90)=1.26ms p(95)=1.26ms
     http_req_connecting............: avg=210µs  min=210µs  med=210µs  max=210µs  p(90)=210µs  p(95)=210µs 
     http_req_duration..............: avg=2s     min=2s     med=2s     max=2s     p(90)=2s     p(95)=2s    
       { expected_response:true }...: avg=2s     min=2s     med=2s     max=2s     p(90)=2s     p(95)=2s    
     http_req_failed................: 0.00%   0 out of 1
     http_req_receiving.............: avg=224µs  min=224µs  med=224µs  max=224µs  p(90)=224µs  p(95)=224µs 
     http_req_sending...............: avg=121µs  min=121µs  med=121µs  max=121µs  p(90)=121µs  p(95)=121µs 
     http_req_tls_handshaking.......: avg=0s     min=0s     med=0s     max=0s     p(90)=0s     p(95)=0s    
     http_req_waiting...............: avg=2s     min=2s     med=2s     max=2s     p(90)=2s     p(95)=2s    
     http_reqs......................: 1       0.497928/s
     iteration_duration.............: avg=2s     min=2s     med=2s     max=2s     p(90)=2s     p(95)=2s    
     iterations.....................: 1       0.497928/s
     vus............................: 1       min=1      max=1
     vus_max........................: 1       min=1      max=1

Définition des résultats générés

checks : Indique le pourcentage et le nombre de vérifications réussies.
data_received : Volume total de données reçues par le script.
data_sent : Volume total de données envoyées par le script.
http_req_blocked : Temps passé à établir une connexion (y compris l’attente si toutes les connexions disponibles sont utilisées).
http_req_connecting : Temps passé à établir la connexion TCP.
http_req_duration : Durée totale de la requête, incluant le temps d’attente pour une réponse et l’échange de données.
http_req_failed : Pourcentage de requêtes HTTP ayant échoué.
http_req_receiving : Temps pris pour recevoir les données après qu’une réponse a commencé.
http_req_sending : Temps pris pour envoyer les données au serveur.
http_req_tls_handshaking : Temps pris pour établir une connexion TLS (si applicable).
http_req_waiting : Temps d’attente avant de recevoir la première réponse du serveur.
http_reqs : Nombre total de requêtes HTTP effectuées.
iteration_duration : Temps total pris pour exécuter une itération complète du script.
iterations : Nombre total d’itérations exécutées pendant le test.
vus : Nombre d’utilisateurs virtuels actifs pendant le test.
vus_max : Nombre maximal d’utilisateurs virtuels pendant le test.

Exemples de tests

Smoke Test

import http from 'k6/http';
import { sleep } from 'k6';
export default function () {
    http.get('http://localhost:3000/fast');
    sleep(1);
}

Résultat attendu

Voici un exemple de résultat obtenu lors de l’exécution d’un Smoke Test :

scenarios: (100.00%) 1 scenario, 1 max VUs, 10m30s max duration (incl. graceful stop):
              * default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)
     data_received..................: 241 B 221 B/s
     data_sent......................: 84 B  77 B/s
     http_req_blocked...............: avg=7.09ms  min=7.09ms  med=7.09ms  max=7.09ms  p(90)=7.09ms  p(95)=7.09ms 
     http_req_connecting............: avg=189µs   min=189µs   med=189µs   max=189µs   p(90)=189µs   p(95)=189µs  
     http_req_duration..............: avg=74.24ms min=74.24ms med=74.24ms max=74.24ms p(90)=74.24ms p(95)=74.24ms
       { expected_response:true }...: avg=74.24ms min=74.24ms med=74.24ms max=74.24ms p(90)=74.24ms p(95)=74.24ms
     http_req_failed................: 0.00% 0 out of 1
     http_req_receiving.............: avg=55µs    min=55µs    med=55µs    max=55µs    p(90)=55µs    p(95)=55µs   
     http_req_sending...............: avg=422µs   min=422µs   med=422µs   max=422µs   p(90)=422µs   p(95)=422µs  
     http_req_tls_handshaking.......: avg=0s      min=0s      med=0s      max=0s      p(90)=0s      p(95)=0s     
     http_req_waiting...............: avg=73.76ms min=73.76ms med=73.76ms max=73.76ms p(90)=73.76ms p(95)=73.76ms
     http_reqs......................: 1     0.918662/s
     iteration_duration.............: avg=1.08s   min=1.08s   med=1.08s   max=1.08s   p(90)=1.08s   p(95)=1.08s  
     iterations.....................: 1     0.918662/s
     vus............................: 1     min=1      max=1
     vus_max........................: 1     min=1      max=1

Le rapport montre que l’API répond correctement avec des temps de réponse très courts, ce qui est attendu dans un Smoke Test.

Stress Test

Le Stress Test pousse le système au-delà de ses limites pour évaluer sa stabilité et identifier les points de défaillance. Il permet de déterminer à quel moment le système commence à échouer lorsqu’il est soumis à une charge importante.

Exemple de script

import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
    stages: [
        { duration: '30s', target: 200 },
        { duration: '1m', target: 15000 },
        { duration: '20s', target: 0 },
    ],
};
export default function () {
    http.get('http://localhost:3000/slow');
    sleep(1);
}

Résultat attendu

Voici un exemple de résultat obtenu lors d’un Stress Test :

scenarios: (100.00%) 1 scenario, 15000 max VUs, 2m0s max duration (incl. graceful stop):
              * default: Up to 15000 looping VUs for 2m0s over 3 stages (gracefulRampDown: 20s, gracefulStop: 20s)
    ...
    WARN[0088] Request Failed                                error="Get \"http://localhost:3000/slow\": dial tcp 127.0.0.1:3000: connect: connection reset by peer"
    WARN[0088] Request Failed                                error="Get \"http://localhost:3000/slow\": read tcp 127.0.0.1:59822->127.0.0.1:3000: read: connection reset by peer"
    ...
     data_received..................: 50 MB  445 kB/s
     data_sent......................: 18 MB  155 kB/s
     http_req_blocked...............: avg=1.03ms   min=0s    med=3µs  max=1.92s    p(90)=23µs  p(95)=221µs
     http_req_connecting............: avg=1.01ms   min=0s    med=0s   max=1.92s    p(90)=0s    p(95)=181µs
     http_req_duration..............: avg=2.02s    min=0s    med=2s   max=3.59s    p(90)=2.07s p(95)=2.17s
       { expected_response:true }...: avg=2.02s    min=1.99s med=2s   max=3.59s    p(90)=2.07s p(95)=2.17s
     http_req_failed................: 0.01%  26 out of 208653
     http_req_receiving.............: avg=58.19µs  min=0s    med=18µs max=156.64ms p(90)=64µs  p(95)=129µs
     http_req_sending...............: avg=165.75µs min=0s    med=6µs  max=295.11ms p(90)=35µs  p(95)=98µs 
     http_req_tls_handshaking.......: avg=0s       min=0s    med=0s   max=0s       p(90)=0s    p(95)=0s   
     http_req_waiting...............: avg=2.02s    min=0s    med=2s   max=3.59s    p(90)=2.07s p(95)=2.17s
     http_reqs......................: 208653 1847.535897/s
     iteration_duration.............: avg=3.03s    min=1s    med=3s   max=4.93s    p(90)=3.08s p(95)=3.18s
     iterations.....................: 208653 1847.535897/s
     vus............................: 37     min=3            max=15000
     vus_max........................: 15000  min=15000        max=15000
running (1m52.9s), 00000/15000 VUs, 208653 complete and 0 interrupted iterations

Ce résultat montre que le système est soumis à une charge très élevée, avec des utilisateurs simultanés atteignant 15 000 au pic. Les temps de réponse restent raisonnables bien que légèrement augmentés sous la charge. Quelques erreurs peuvent apparaître (par exemple, 0.01% d’échecs), mais cela est attendu dans des tests de stress extrêmes. Une analyse plus approfondie peut être nécessaire pour optimiser les performances sous ces conditions.

Personnalisation des métriques

K6 permet de créer des métriques personnalisées pour enrichir les rapports. Voici un exemple mesurant le taux d’erreurs :

import http from 'k6/http';
import { Rate } from 'k6/metrics';
const errorRate = new Rate('error_rate');
export default function () {
    const res = http.get('http://localhost:3000/fast');
    errorRate.add(res.status >= 122);
}

data_received..................: 241 B   4.2 kB/s
     data_sent......................: 84 B    1.5 kB/s
     error_rate.....................: 100.00% 1 out of 1
     http_req_blocked...............: avg=1.39ms  min=1.39ms  med=1.39ms  max=1.39ms  p(90)=1.39ms  p(95)=1.39ms 
running (00m00.1s), 0/1 VUs, 1 complete and 0 interrupted iterations

Intégration avec Grafana et Prometheus

Voici une configuration complète pour visualiser vos résultats dans Grafana et Prometheus.

Pré-requis

Docker et Docker Compose installés sur votre machine.

Configuration Docker Compose

Créez un fichier docker-compose.yml :

version: '3.7'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--web.enable-remote-write-receiver"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    networks:
      - monitoring
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    networks:
      - monitoring
networks:
  monitoring:
volumes:
  grafana-data:

Configuration Prometheus

Créez un fichier prometheus.yml :

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'k6'
    static_configs:
      - targets: ['host.docker.internal:6565']

Exécution

Démarrez les conteneurs :

docker-compose up -d

Lancer un test K6 avec Prometheus Remote Write

Ajoutez cette configuration dans votre script K6 :

import http from 'k6/http';
import { sleep, check } from 'k6';
export const options = {
    stages: [
        { duration: '30s', target: 50 },  // Monter jusqu'à 50 utilisateurs virtuels
        { duration: '1m', target: 10000 }, // Monter jusqu'à 10000 utilisateurs virtuels
        { duration: '2m', target: 200 }, // Monter jusqu'à 200 utilisateurs virtuels
        { duration: '30s', target: 0 },  // Descendre progressivement à 0
    ],
    thresholds: {
        http_req_duration: ['p(95)<2000'], // 95% des requêtes doivent répondre en moins de 2s
        http_req_failed: ['rate<0.01'],   // Moins de 1% des requêtes échouées
    },
    ext: {
        experimental: {
            prometheus_rww: {
                address: 'http://host.docker.internal:9090/api/v1/write',
                pushInterval: '5s',
            },
        },
    },
};
export default function () {
    const fastRes = http.get('http://localhost:3000/fast');
    check(fastRes, {
        'status is 200': (r) => r.status === 200,
        'response time < 100ms': (r) => r.timings.duration < 100,
    });
    const slowRes = http.get('http://localhost:3000/slow');
    check(slowRes, {
        'status is 200': (r) => r.status === 200,
        'response time < 300ms': (r) => r.timings.duration < 300,
    });
    sleep(1);
}

Configurer Grafana

Accédez à Grafana via http://localhost:3001.
Connectez-vous (utilisateur : admin, mot de passe : admin).
Ajoutez Prometheus comme source de données :
- URL : http://prometheus:9090
Importez un tableau de bord K6 disponible sur Grafana Dashboards (ID : 19665). (k6 Prometheus | Grafana Labs )

Exécution du test :

k6 run --out experimental-prometheus-rw script.js

Résultats des tests et visualisation dans Grafana

Après avoir exécuté le test de charge avec K6, nous avons intégré les données dans Prometheus et visualisé les résultats dans Grafana. Cette configuration permet une analyse approfondie des performances de votre API en temps réel. Voici deux exemples de tableaux de bord obtenus lors des tests et disponible sur localhost:3001:

Exemple de tableau de bord 1

Ce tableau affiche les métriques clés suivantes :

Taux de transfert (data sent/received) : Analyse de la quantité de données envoyées et reçues au cours du test.
Durée des requêtes HTTP : Répartition des durées de réponse pour les requêtes réussies, ainsi que les statistiques détaillées par URL.
Taux de requêtes par seconde : Indication de la charge générée par les utilisateurs virtuels (Virtual Users).

Exemple de tableau de bord 2

Dans ce tableau, nous pouvons observer :

Vue d’ensemble des performances : Indication des utilisateurs virtuels actifs (VUs), des requêtes HTTP envoyées, et des taux de succès/échec.
Durée des requêtes HTTP : Visualisation des temps de réponse moyens et des percentiles élevés (p95, p99) pour détecter les points d’anomalie.
Rythme des requêtes : Statistiques sur les requêtes par seconde au pic de la charge.

Ces graphiques mettent en évidence les performances globales de votre système et permettent de diagnostiquer les éventuels goulots d’étranglement.

Meilleures pratiques pour K6

Modularité : Divisez vos scripts pour une meilleure lisibilité et maintenance.
Validation : Utilisez des check pour valider les réponses de vos API.
Rapports avancés : Intégrez avec Grafana pour visualiser les métriques en temps réel.
Automatisation : Intégrez K6 dans vos pipelines CI/CD pour surveiller continuellement les performances.

Conclusion

K6 est un outil indispensable pour évaluer la performance et la résilience des applications modernes. Sa simplicité, ses hautes performances et ses nombreuses options en font un choix idéal pour les développeurs et les équipes DevOps. Essayez-le pour garantir une expérience utilisateur optimale, même sous des charges importantes.

Sources

L’article Introduction à K6 est apparu en premier sur Ouidou.

Créer une API en Python avec FastAPI

Emmie Pommeret — Wed, 03 Dec 2025 16:16:37 +0000

Écrit par Mohamed S.

Introduction

Un Framework est un ensemble de structures, de modules et de packages qui facilite le développement d’applications ou de systèmes.

Les trois principaux Framework Python les plus utilisés sont Django, Flask et FastAPI, chacun représente ses avantages et ses inconvénients.

Ça peut être utile de mettre en place une API par exemple dans le cas où on a une application web/mobile qui a besoin de consommer des datas de façon standardisé sans avoir à gérer les accès à une base de données.

FastAPI est un Framework web de haute performance, open source. Lancé en 2018, il permet de créer des APIs avec Python à partir de la version 3.6.

Comme son nom l’indique, FastAPI est très rapide et facile à coder, il est très intuitif à l’utilisation, avec des fonctionnalités de complétion et de débogage, il est basé sur le standard ouvert OpenAI et JASON Schéma.

Le principal usage du Framework est la création de Endpoints APIs, principalement pour les applications de Data Science et e-commerce.

Toutefois, FastAPI ne se limite pas à créer des APIs, il est possible de l’utiliser pour n’importe quel usage d’un Framework web. Il a été désigné meilleur Framework open source en 2021.

Prérequis

Pour utiliser FastAPI, vous devez avoir :

Une base en programmation et une bonne compréhension des concepts de base de langage Python.
Une connaissance des principes des API REST et des requêtes HTTP.

Installation

Assurez-vous que vous avez bien installé Python.

Dans un seconde temps, un éditeur de texte/IDE est nécessaire, tel que VS Code.

Pour installer FastAPI, vous devez exécuter la commande suivante :

$ pip install fastapi

Vous aurez également besoin d’un serveur web local pour tester vos API. Pour cela Python mis à disposition Uvicorn, qui est un serveur web ASGI (Asynchronous Server Gateway Interface).

Pour installer Uvicorn, vous devez exécuter cette commande :

$ pip install "uvicorn[standard]"

Développement

Dans cet article, nous allons créer une application CRUD avec FastAPI.

Une API REST fonctionne avec des requêtes HTTP, c’est ce protocole qui permet de connecter au serveur, il existe différents types de requêtes HTTP, et chaque requête dépend de l’action que l’on souhaite effectuer.

Les types de requêtes :

POST : servent à créer un nouvel élément dans la base de données
GET : servent à récupérer des données (en mode lecture)
PUT : servent à modifier un élément déjà existant dans la base de données
DELETE : servent à supprimer des éléments dans la base de données

Création de l’application

Nous allons commencer par la création de notre modèle utilisateur, et ce modèle aura 5 attributs :

id : un identifiant unique
first_name : le prénom de l'utilisateur
last_name : le nom de famille de l'utilisateur
genre : le sexe de l'utilisateur
role : la liste des rôles de l'utilisateur

Ce modèle sera créé dans un nouveau fichier nommé models.py :

Dans le fichier main.py nous allons créer notre base de données de la manière suivante :

Jusqu’ici, nous avons créé une base de données avec 4 utilisateurs, chacun avec des attributs requis.

La ligne du fichier main.py :

app = FastAPI()

permet de créer une instance de FastAPI.

Lecture des éléments de la base de données

Pour créer une route qui récupère les utilisateurs, nous allons créer un décorateur dans le fichier main.py :

Le décorateur

@app.get("api/get_users")

permet de spécifier le chemin URL et l’action HTTP de notre API, et cette fonction fait appel à la méthode GET.

La fonction ‘get_users()‘ sera exécutée chaque fois qu’un utilisateur visitera le chemin URL spécifié par le décorateur.

Pour lancer le serveur d’API et tester la fonction, nous allons exécuter la commande suivante dans le terminal :

$ uvicorn main:app --reload

Uvicorn est le serveur local, il prend en paramètres le nom du fichier : le nom de l’instance FastAPI.

Dans cet exemple, le nom du fichier est : main, et le nom de l’instance est app.

L’option ‘–reload‘ indique au serveur de se recharger automatiquement lorsque une modification est apportée.

Quand nous exécutons la commande, si tout se passe bien nous allons avoir quelque chose comme ceci dans le terminal :

Nous allons retenir l’URL du localhost et le port 8000, il nous servira d’afficher les résultats de l’API.

FastAPI en plus de mettre en place rapidement et facilement une API, il génère automatiquement une documentation de l’API, cette documentation est basé sur l’interface utilisateur Swagger, pour y accéder on rajoute juste ‘/docs’ à notre URL.

127.0.0.1:8000/docs

Nous allons exécuter l’endpoint qui représente la récupération des utilisateurs, nous allons avoir ce résultat qui regroupe les utilisateurs.

Création de nouveaux éléments dans la base de données

Nous allons créer un endpoint dans le fichier main.py, qui permettra de créer de nouveaux éléments et de les enregistrer en base de données.

Dans cette fonction nous avons utilisé l’action HTTP POST, qui permet la création en base de données.

L’interface du Swagger après avoir ajouté le nouvel élément ressemblera à l’image suivante :

L’utilisateur toto titi a été bien ajouté en base de données.

Suppression d’un élément de la base de données

Etant donné que nous créons une application CRUD, l’application doit avoir la possibilité de supprimer une ressource existante.

Pour cela, nous allons créer un endpoint toujours dans le fichier main.py, qui permettra la suppression :

Dans le décorateur, nous avons utilisé l’action HTTP DELETE, qui permet la suppression en base de données.

La fonction nécessitera un id à supprimer, si l’id de l’utilisateur est introuvable un message d’erreur sera renvoyé, c’est le cas dans l’image suivante, où nous allons renseigner un id qui n’existe pas dans la base de données :

Et quand nous allons renseigner un bon id qui existe dans la base de données, l’utilisateur qui a cet id ne sera plus dans la base de données, il sera supprimé.

Mettre à jour un élément de la base de données

Dans cette partie, nous allons créer un endpoint qui permettra de mettre à jour un élément qui existe déjà en base de données, en utilisant l’action HTTP PUT.

Toujours dans le fichier main.py, on ajoute la fonction suivante :

Dans les paramètres de la fonction qui met à jour les éléments, l’id est à renseigner obligatoirement, par contre les autres champs sont facultatifs, d’où leurs déclarations : ‘Optional[str] = None‘ qui veut dire que c’est optionnel et que la valeur par défaut est nulle.

Dans le cas ou l’id renseigné est introuvable en base de données, l’API générera une erreur.

Conclusion

Dans cet article, nous avons découvert le cadre FastAPI pour python et constaté à quelle vitesse nous pouvons mettre en place une application alimentée par FastAPI.

Nous avons appris à créer des endpoints (points de terminaison) d’API CRUD, c’est-à-dire créer, lire, mettre à jour et supprimer (Create, Read, Update, Delete) des éléments de base de données.

En conclusion, FastAPI est un framework Python moderne, rapide et efficace pour la création d’API web. Grâce à son utilisation des annotations de type Python, il permet de garantir la validation automatique des données et de générer une documentation interactive, facilitant ainsi le développement et la maintenance des API.

FastAPI représente un excellent choix pour les développeurs cherchant à construire des API robustes, performantes et facile à maintenir.

Références

Site Officiel de FastAPI (en)

L’article Créer une API en Python avec FastAPI est apparu en premier sur Ouidou.

Optimiser vos tests avec Cucumber

Emmie Pommeret — Mon, 17 Nov 2025 10:11:16 +0000

Écrit par Faiez T.

Introduction :

Qu’est-ce que Cucumber ?

Cucumber est un outil puissant utilisé pour automatiser les tests logiciels, qui repose sur la méthodologie du Behavior Driven Development (BDD). Il permet de décrire le comportement attendu d’une application sous forme de scénarios simples et compréhensibles par tous, facilitant ainsi la collaboration entre les différentes équipes.

Qu’est-ce que BDD ?

Le Behavior Driven Development (BDD) est une approche de développement logiciel qui se concentre sur la description du comportement attendu d’une application à travers des scénarios clairs et accessibles. Ces scénarios peuvent être compris par toutes les parties prenantes, qu’il s’agisse de développeurs, de testeurs, d’analystes métiers ou d’utilisateurs finaux, facilitant ainsi la communication et la collaboration tout au long du processus de développement.

Pourquoi utiliser Cucumber ?

1. Langage naturel avec Gherkin

L’un des points forts de Cucumber est qu’il utilise un langage naturel appelé Gherkin pour définir les tests. Gherkin est une syntaxe simple qui permet d’écrire des scénarios en anglais ou dans d’autres langues, en suivant une structure intuitive.

Exemple d’un scénario Gherkin :

Feature: Connexion utilisateur  
 Scenario: Connexion réussie avec des identifiants valides  
   Given un utilisateur avec un identifiant valide "faiez.tmar"  
   When il tente de se connecter avec son mot de passe  
   Then il est redirigé vers la page d'accueil

2. Tests lisibles et compréhensibles

Les scénarios écrits avec Cucumber sont compréhensibles par toutes les parties prenantes du projet, qu’elles soient techniques ou non. Cela permet :

Une collaboration accrue entre les développeurs, les testeurs et les responsables métier.
Une meilleure compréhension des fonctionnalités attendues de l’application.

3. Automatisation des Tests

Une fois les scénarios définis, Cucumber permet de les automatiser, ce qui améliore la qualité du logiciel en garantissant :

Une exécution rapide et fiable des tests.
La détection rapide des régressions lors des phases de développement.

Les concepts clés de Cucumber

1. Feature

Une Feature est un fichier .feature qui décrit une fonctionnalité spécifique de l’application. Ce fichier regroupe plusieurs scénarios liés à cette fonctionnalité.

Exemple :

Feature: Gestion des utilisateurs
Afin de pouvoir accéder à l'application
En tant qu'utilisateur enregistré
Je veux pouvoir me connecter avec mes identifiants

2. Scénario

Un Scenario décrit une situation ou un cas d’utilisation spécifique, en détaillant le comportement attendu de l’application dans ce cas.

Exemple :

Scenario: Connexion avec des identifiants valides
Given un utilisateur avec l'identifiant "faiez.tmar"
When il saisit son mot de passe correct
Then il est redirigé vers la page d'accueil

3. Steps

Les Steps ou étapes définissent les actions à réaliser et les résultats attendus dans le scénario. Elles se décomposent en trois catégories principales :

Given : Décrit le contexte initial.
When : Décrit l’action ou l’événement déclencheur.
Then : Définit le résultat attendu.

Syntaxe des Steps :

Given un utilisateur est sur la page de connexion  
When il saisit ses identifiants corrects  
Then il est redirigé vers la page d'accueil

4. Step Definitions

Les Step Definitions sont des méthodes implémentées en Java (ou dans un autre langage compatible) qui définissent le comportement à exécuter pour chaque étape du scénario.

Exemple en Java :

@Given("un utilisateur est sur la page de connexion")
public void userOnLoginPage() {
// Code pour naviguer vers la page de connexion
}
@When("il saisit ses identifiants corrects")
public void provideCorrectCredentials() {
// Code pour saisir les identifiants
}
@Then("il est redirigé vers la page d'accueil")
public void redirectedToHomePage() {
// Code pour vérifier la redirection
}

Exemple d’Implémentation de Cucumber avec Spring Boot

1. Configuration du Projet

Pour intégrer Cucumber dans un projet Spring Boot, vous devez ajouter les dépendances nécessaires dans le fichier pom.xml :


    
    
        io.cucumber
        cucumber-java
        7.0.0
    
    
        io.cucumber
        cucumber-spring
        7.0.0
    
    
    
        org.springframework.boot
        spring-boot-starter-test
        test

Créez une classe CucumberTest.java :

import io.cucumber.junit.Cucumber;
import io.cucumber.junit.CucumberOptions;
import org.junit.runner.RunWith;
@RunWith(Cucumber.class)
@CucumberOptions(features = "classpath:features", plugin = {"pretty"})
public class CucumberTest {
}

2. Exemple de scénario Gherkin :

Dans un fichier article.feature, nous allons définir des scénarios en Gherkin pour tester la gestion des articles. Chaque scénario correspond à une action CRUD sur un article.

Feature: Gestion des articles
  Afin de gérer les informations de mes articles
  En tant qu'administrateur
  Je veux pouvoir créer, lire, mettre à jour et supprimer des articles.
Scenario: Création d'un nouvel article
  Given un article avec le titre "Cucumber et Spring Boot"
  When l'article est créé
  Then l'article doit être enregistré dans la base de données
Scenario: Lecture d'un article
  Given un article avec le titre "Cucumber et Spring Boot"
  When je consulte l'article
  Then le titre de l'article doit être "Cucumber et Spring Boot"
Scenario: Mise à jour d'un article
  Given un article avec le titre "Cucumber et Spring Boot"
  When je mets à jour l'article avec le titre "Cucumber avancé"
  Then le titre de l'article doit être "Cucumber avancé"
Scenario: Suppression d'un article
  Given un article avec le titre "Cucumber et Spring Boot"
  When je supprime l'article
  Then l'article ne doit plus exister dans la base de données

3. Implémentation des steps en Java

Dans la classe ArticleStepDefinitions.java, nous allons implémenter les étapes des scénarios.

import io.cucumber.java.en.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.ResponseEntity;
import org.springframework.test.web.client.TestRestTemplate;
import static org.junit.Assert.*;
@SpringBootTest
public class ArticleStepDefinitions {
    @Autowired
    private ArticleRepository articleRepository;
    private Article article;
    @Given("un article avec le titre {string}")
    public void givenAnArticleWithTitle(String titre) {
        article = new Article();
        article.setTitre(titre);
    }
    @When("l'article est créé")
    public void whenArticleIsCreated() {
        articleRepository.save(article); 
    }
    @Then("l'article doit être enregistré dans la base de données")
    public void thenArticleShouldBeSavedInDatabase() {
        Article savedArticle = articleRepository.findByTitre(article.getTitre());
        assertNotNull(savedArticle); 
        assertEquals(article.getTitre(), savedArticle.getTitre()); 
    }
    @When("je consulte l'article")
    public void whenGetArticle() {
        article = articleRepository.findByTitre(article.getTitre());
    }
    @Then("le titre de l'article doit être {string}")
    public void thenTitleOfArticleShouldBe(String titre) {
        assertEquals(titre, article.getTitre()); 
    }
    @When("je mets à jour l'article avec le titre {string}")
    public void whenIUpdateTheArticleWithTitle(String nouveauTitre) {
        article.setTitre(nouveauTitre);
        articleRepository.save(article); 
    }
    @Then("le titre de l'article doit être {string}")
    public void thenTitleOfArticleShouldBeUpdated(String titre) {
        article = articleRepository.findByTitre(titre);
        assertNotNull(article); 
        assertEquals(titre, article.getTitre()); 
    }
    @When("je supprime l'article")
    public void whenIDeleteTheArticle() {
        articleRepository.delete(article); 
    }
    @Then("l'article ne doit plus exister dans la base de données")
    public void thenArticleShouldNotExistInDatabase() {
        Article deletedArticle = articleRepository.findByTitre(article.getTitre());
        assertNull(deletedArticle); 
    }
}

4. Exécution des Tests

Vous pouvez maintenant exécuter vos tests avec Maven en utilisant la commande suivante :

mvn test

Les tests Cucumber vont s’exécuter, et vous pourrez vérifier les résultats pour vous assurer que les opérations CRUD sur les articles fonctionnent correctement.

Conclusion

En conclusion, Cucumber, en tant que framework basé sur la méthodologie BDD, facilite l’automatisation des tests et améliore la collaboration entre les équipes grâce à son utilisation de scénarios écrits dans un langage naturel. Son approche permet une compréhension claire des comportements attendus de l’application, tant pour les techniciens que pour les non-techniciens.

Grâce à l’intégration avec des outils comme Spring Boot, Cucumber permet d’implémenter et d’exécuter efficacement des tests automatisés, garantissant ainsi une meilleure qualité logicielle et une détection rapide des régressions.

L’article Optimiser vos tests avec Cucumber est apparu en premier sur Ouidou.

Comment préparer votre Jira Cloud dès maintenant ?

Emmie Pommeret — Fri, 14 Nov 2025 15:32:01 +0000

L’article Comment préparer votre Jira Cloud dès maintenant ? est apparu en premier sur Ouidou.

Replay webinaire IA

Emmie Pommeret — Wed, 05 Nov 2025 17:11:41 +0000

L’article Replay webinaire IA est apparu en premier sur Ouidou.

Atlassian arrête le Data Center : pourquoi votre migration doit commencer maintenant

Emmie Pommeret — Wed, 05 Nov 2025 14:23:14 +0000

L’article Atlassian arrête le Data Center : pourquoi votre migration doit commencer maintenant est apparu en premier sur Ouidou.

Ouidou

Ouidou et Scaleway : un partenariat stratégique pour accélérer le cloud souverain en Europe

JTE : un moteur de templates moderne, rapide et sécurisé pour Java

Introduction

Qu’est-ce que JTE ?

Objectif principal

Les atouts majeurs

Haute Performance

Sécurité renforcée

Typage fort et vérification à la compilation

Intégration fluide

Installation

Structure de base

Exemple de template hello.jte

Hello ${name}!

Contrôleur

Classe Java générée du template

Hello "); output.writeUserContent(name); output.writeContent("!

Explications

Résultat affiché

Hello Jean!

Exemples d’utilisation de JTE

Affichage conditionnel

Boucle for (foreach)

Fragment réutilisable

Limites et points de vigilance avec JTE

Recompilation après chaque modification

Communauté encore jeune

Moins d’écosystème autour des extensions

Extensions et plugins JTE encore limités

Pas de Virtual DOM ni de rendu réactif

Conclusion

Liens utiles

La Sobriété Numérique, de la quantification des émissions carbone des applications à la mise en œuvre des corrections

Qu’est que c’est La Sobriété Numérique

La Sobriété Numérique dès la conception de l’application

Comment mesurer l’empreinte carbone des applications web

Comment mettre en œuvre L’Eco-conception lors de la rédaction du code

Conclusion

Sources

Outils de mesure mentionnés

Quelques ressources pour aller plus loin…

Introduction pratique au Q-learning avec Gymnasium Taxi-v3

Introduction

Comprendre le Q-Learning et la Q-Table

La Q-Table

La formule de mise à jour

Stratégie d’exploration

Description du problème

Implémentation en Python

Résultats et analyse

Évaluation de l’agent

Visualisation des performances

Plusieurs choses sont affiché sur ce graphique.

Optimiser les performances de l’algorithme Q-Learning

Le taux d’apprentissage (lr)

Le facteur de discount (gamma)

La probabilité d’exploration (epsilon)

Le nombre d’épisodes

Comparer les résultats

Limites du Q-Learning

Visualisation de l’agent

Conclusion

liens utiles

Articles similaire:

Site avec implementation de Q-learning:Search | Kaggle

Introduction à K6

Définitions des types de tests

Qu’est-ce que K6 ?

Pourquoi utiliser K6 ?

Fonctionnalités principales

Prise en main avec K6

Installation

Sous macOS

Sous Linux

Sous Windows

Création d’un script de test

Présentation du serveur Express

Exécution d’un test

Définition des résultats générés

Exemple de template `hello.jte`

Boucle `for` (`foreach`)

Site avec implementation de Q-learning:
Search | Kaggle