Dralagen

ADR - Architecture Decision Record

Wed, 07 Jan 2026 10:26:06 GMT

L’Architecture Decision Record (ADR) est un journal de décisions prises par l’équipe. L’objectif est de tracer les décisions validées ou rejetées, le contexte de la décision et les options écartées.

L’objectif

Contexte :

s’assure que tout le monde comprend le problème de la même façon
Se souvenir des conditions de prise de décision Options, Avantages et Inconvénients :
Tracer toutes les idées pour ne pas en oublier
Eviter les mêmes conversations en boucle
Dans le futur, voir les pistes envisagées et pouvoir proposer d’autres solutions non évoquées. La décision et les critères :
une vision similaire pour tout le monde sur la décision
Permet d’avoir les critères déterminant de la décision
Trace le pourquoi Les conseils :
Trace les conditions qui n’ont pas d’importance aujourd’hui mais qui peuvent avoir un impact.
Envisager les limitations futures sur la solution choisie Les conséquences :
Quels sont les actions à prendre

Exemple de template

# ADR TEMPLATE
 
- 📅 Date : 
- 👷 Décision prise par :
- 🏁 Statut :
 
# Contexte
 
<--Quel est le contexte de votre décision. Exemple : ADR précédent, problème auquel l'équipe veut s'attaquer, ...-->.
 
# Options envisagées 💡
 
1. Option 1 : 
    - **Plus de détails :** 
    - ✅ **Avantages :** 
    - 🚫 **Inconvénients :** 
2. Option 2 : 
    - **Plus de détails :** 
    - ✅ **Avantages :** 
    - 🚫 **Inconvénients :**
 
 
# Conseils 
<--Tous les conseils que l'on vous a donnés -->
 
# Décision 🏆
<--Quelles décisions ont été prises et quels étaient les critères-->
 
# Conséquences 
<--Conséquences de votre décision-->
 
♻️ Mise à jour : <date>.

sources :

Comment émettre une notification du Back vers un Front ?

Wed, 07 Jan 2026 10:26:06 GMT

La programmation asynchrone est de plus en plus souvent présente dans nos développements. Les microservices multiplient le nombre de composants présents dans notre infrastructure et la communication synchrone pour réaliser un traitement n’est plus une solution viable. Trop d’adhérence entre les services ; en microservices, on part du principe qu’il y a forcément un élément qui est down.

La communication back-end utilise de plus en plus des modèles asynchrones (Kafka, AMQP, JMS, etc…). Nos services “s’isolent” pour mieux fonctionner ensemble par des notifications.

Comment nos services peuvent notifier la fin d’un traitement ou l’avancement du traitement vers le front pour qu’il puisse réagir. Comment un serveur peut informer l’utilisateur d’un changement d’état, d’une mise à jour.

Les Méthodes

Client pulling

Méthode simple côté front, une requête tous les 5 secondes pour dire “Dans quel état est mon traitement ?” et le service doit répondre à chaque fois. Pour que le service puisse réponde correctement, il doit connaître l’ensemble du traitement pour interroger la base de données ou le bon service afin de collecter les bonnes informations, alors que le front peut déjà avoir en sa possession. Du traitement pas toujours simple dans un système fortement distribué, où plusieurs tâches peuvent être réalisées en concurrence.

Web Socket

Le protocole Web Socket existe, elle permet de faire une communication entre le front et le back en temps réel dans les deux directions. Ça implique d’implémenter un autre protocole, qui n’est pas toujours supporté par les proxy et pare-feu. L’ouverture de flux bi-directionnel peut être un frein ou un refus lié à la sécurité.

Server-Sent Events

La technique Server-Sent Events (SSE) pour établir une connexion du back vers le front. Le front s’abonne au back, et le back émet des données dans la connexion.

Simple et efficient, basé sur une communication unidirectionnelle, l’architecture se simplifie par rapport au Web Socket.
Basé sur HTTP, le protocole HTTP est très bien supporté sur l’ensemble des navigateurs et s’intègre mieux avec l’infrastructure existante telle que HTTP/2, les proxys et les pare-feu.
Reconnection automatique, SSE est en capacité de se reconnecter automatiquement si la connexion est interrompue.
Événements typés, il est possible de typer les événements pour mieux les identifier dans une application gérant plusieurs événements.

Limitation de SSE:

Bien que SSE est bien supporté par tous les navigateurs modernes. L’API EventSource est normalisée dans le cadre de HTML5 sortie en 2014, mis en draft en 2011, cette API peut encore être considérée comme jeune.
SSE est optimisé pour du texte ; ce n’est pas possible d’envoyer du binaire.
Si on utilise HTTP/1, il y a une limite technique : le nombre de connexions ouvertes par navigateur à 6 pour un même domaine. Ce qui implique qu’on peut bloquer l’ensemble d’une page web, si on a plusieurs onglets d’ouvert. Pour contourner cela, on cherchera à mettre en place un “shared worker”.
Si l’application a beaucoup d’utilisateurs simultanés, le serveur doit être en capacité de maintenir un nombre important de connexions HTTP.

Conclusion

L’utilisation du Server-Sent Events (SSE) permet d’avoir un approche au temps réel plus simple que l’utilisation d’un simple client pulling aura du mal à répondre sans créer une surcharge importante sur l’infrastructure. Ça mise en place peut-être élégante, il faudra bien prendre en compte toutes les contraintes lors de la reconnexion du client ou lorsqu’ notre environnement contient plusieurs serveurs. SSE offre une mise en place plus simple et moins coûteuse que d’utiliser le protocole Web Socket.

Aller plus loin

Pour mieux comprendre, vous pouvez trouver un POC sur la Mise en place de Server-Sent Events.

Sources:

Reset des clé PGP provenant d'une clé physique

Wed, 07 Jan 2026 10:26:06 GMT

Lors de l’insertion d’une clé physique, la signature est sauvegardée localement avec le numéro de série de la carte.

Pour simplifier l’utilisation pour signer les commits Git, j’utilise la même clé PGP sur 2 clés physiques différentes. Si je change de clé physique, il faut réinitialiser le cache des clés.

Une fonction bash permet de forcer le changement :

function switchyubi() {
  rm ~/.gnupg/private-keys-v1.d/*
  gpgconf --kill gpg-agent
  gpg --card-status
}

Git - Ajout d'un gitignore global

Wed, 07 Jan 2026 10:26:06 GMT

Par défaut Git lit les fichiers .gitignore présents dans le dépôt, mais aussi un fichier présent dans les méta $GIT_DIR/info/exclude. Git propose la propriété core.excludesFile dans sa configuration pour ajouter un fichier global spécifique. La propriété prend l’emplacement d’un fichier qui sera appliqué dans tous les projets.

Pourquoi définir un fichier gitignore en global ? L’utilité est de pouvoir exclure des fichiers générés par son système d’exploitation sans charger le fichier .gitignore de chaque projet.

L’exemple que j’ai rencontré, on est peu de développeurs sous macOS, et j’en avais marre d’exclure sur chaque projet les fichiers spécifique à macOS. J’ai donc ajouté un fichier .gitignore à partir d’un exemple extrait du repo github/gitignore dans mon “home”. Puis j’ai ajouté dans la configuration ce fichier comme excludesFiles avec la commande suivante :

git config --global core.excludesFile ~/.gitignore

Installation Claude Code

Wed, 07 Jan 2026 10:26:06 GMT

Mon environnement d’installation, un Ubuntu 24.04 et NodeJS 22 installés avec ASDF.

Dans la documentation, l’installation demande d’exécuter cette commande :

npm install -g @anthropic-ai/claude-code

L’installation est réalisée dans le répertoire d’installation de Node dans le dossier ASDF.

Pour éviter d’ajouter un PATH pour chaque version de Node, il est possible d’utiliser un répertoire spécifique pour les installations globales :

mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=~/.npm-global/bin:$PATH 
npm install -g @anthropic-ai/claude-code

L’export du PATH sera ajouté dans la configuration pour le conserver dans les nouveaux shells.

source :

MCP - Atlassian

Wed, 07 Jan 2026 10:26:06 GMT

Le protocole MCP est utilisé pour permettre à une IA (intelligence artificielle) de se connecter à un outil. Jira et Confluence sont souvent utilisés dans les environnements professionnels.

Permettre d’avoir un lien MCP entre l’IA et Confluence/Jira permet plusieurs cas d’utilisation. Côté Confluence, cela permet de lire les conventions de développement de l’entreprise ou de lire un guide de migration qu’on souhaite appliquer.

Le serveur MCP est aussi capable de compléter la documentation du projet pour une fonctionnalité, ou de faire avancer le ticket Jira avec un commentaire.

Plusieurs exemples de configuration sont disponibles sur le repo.

Pour un serveur self-hosted, j’ai dû supprimer la vérification SSL parce que le Docker n’a pas les certificats de l’entreprise. Exemple de configuration pour un serveur :

{  
    "servers": {   
        "mcp-atlassian": {  
            "command": "docker",  
            "args": [  
                "run",  
                "--rm",  
                "-i",  
                "-e", "CONFLUENCE_URL",  
                "-e", "CONFLUENCE_USERNAME",  
                "-e", "CONFLUENCE_PERSONAL_TOKEN",  
                "-e", "CONFLUENCE_SSL_VERIFY",  
                "-e", "JIRA_URL",  
                "-e", "JIRA_USERNAME",  
                "-e", "JIRA_PERSONAL_TOKEN",  
                "-e", "JIRA_SSL_VERIFY",  
                "ghcr.io/sooperset/mcp-atlassian:latest"  
            ],  
            "env": {  
                "CONFLUENCE_URL": "https://confluence.entreprise.com/",  
                "CONFLUENCE_USERNAME": "myUsername",  
                "CONFLUENCE_PERSONAL_TOKEN": "myPATconfluence",  
                "CONFLUENCE_SSL_VERIFY": "false",  
                "JIRA_URL": "https://jira.entreprise.com",  
                "JIRA_USERNAME": "myUsername",  
                "JIRA_PERSONAL_TOKEN": "myPATjira",  
                "JIRA_SSL_VERIFY": "false"
            }  
        }  
    }  
}

Sources:

https://github.com/sooperset/mcp-atlassian

opencode - agent IA dans le terminal

Wed, 07 Jan 2026 10:26:06 GMT

Opencode est un outil de codage agentique conçu dans le terminal. Il se concentre sur l’utilisation d’outils, serveur MCP. La possibilité de lancer plusieurs agents en parallèle. Son gros avantage est-être multi-model avec plusieurs providers.

L’outil est open source et est très proche en fonctionnalité à Claude Code ou Gemini Cli.

Les concepts

Règles

Ajoute des informations à l’agent, le projet utilise le fichier AGENTS.md compatible avec d’autres outils comme GitHub Copilot, Cursor, Kilo Code, Gemini CLI, etc…

Agents

Permet d’ajouter des profiles d’assistant, comme un expert développeur en code/Debug qui respect les bonnes pratiques, ou un profile reviewer qui sera capable de relire le code modifié et vérifier qu’il correspond à ce qui été attendu. On peut aussi imaginer un assistant documentation qui pourra avoir accès en écriture sur le wiki pour compléter ou ajouter de la documentation pour un composant interne par exemple.

Commandes

Un sort de shortcut ou template pour des prompts pré-rédigés, comme l’ajout d’un test sur une méthode ou classe ou la création d’une nouvelle API.

On peut aussi imaginer des commandes plus complexes qui peuvent lire une specification, analyser le projet pour créer un plan, le faire valider et réaliser l’implémentation, exécuter les tests et finir par mettre à jour la documentation.

MCP

Permet d’ajouter des outils externes afin d’agrandir les possibilités de notre agent IA. Que se soit pour récupérer de la documentation ou des tâches avec le MCP - Atlassian ou pouvoir interragir avec un navigateur avec MCP Playwright.

Plugins

Il est possible d’intégrer des plugins, que se soit dans le projet ou global pour ajouter des points d’extension pour sécuriser la lecture de fichier comme des .env.

Les avantages

Multi fournisseurs

J’aime beaucoup cet outil parce qu’on ne dépend pas d’une solution fermée. Ce qui, dans un contexte où un changement de client peut engendrer un changement de provider, permet de garder un outil qu’on maîtrise.

En provider disponible, j’ai réussi à me connecter avec un compte GitHub Copilot, ou encore du local avec Ollama (attention aux performances). Mais il est possible d’utiliser une clé d’API Anthropic ou un abonnement, mais aussi d’utiliser OpenRouter pour faire du benchmark. Ça semble un bon outil pour ne pas se fermer avec un fournisseur où une solution, comme Claude Code ou Gemini CLI.

Multi tâches

J’ai réussi avec les différents Agents à avoir un chef d’orchestre pour lancer des tâches dédiées. Ce découpage en plusieurs tâches m’a permis de diminuer le contexte du chef d’orchestre et a permis de terminer la tâche avec une bonne qualité. Les sous-tâches n’étant pas polluées par le contexte de l’évolution précédente.

Bon, ça demande de reconstruire plusieurs fois un contexte mais souvent plus petit, plus précis.

Limitations observées

Après avoir testé l’outil en septembre 2025, soit la version 0.10.3, j’ai eu quelques éléments gênants lors de l’utilisation.

Lors de l’exécution d’une commande bash, l’outil a une taille limite de retour d’une commande. Si la limite est atteinte, il stoppe la commande et considère que le résultat est correct. Sauf que lors d’exécuter des tests avec Maven un peu trop verbeux, finalement le résultat final n’est pas correct. J’ai réussi à contourner le problème en ajoutant ou en diminuant les logs ou en utilisant un fichier de sortie pour limiter la sortie commande..

Pour aller plus loin :

Le site officiel d’opencode
un article sur Sfeir.dev

Configuration des secrets dans Kubernetes avec sealed secrets

Wed, 07 Jan 2026 10:26:06 GMT

Utilisation de l’outil sealed-secrets de Bitnami. L’objectif est de pouvoir commit un secret sans le compromettre.

Exemple de secret :

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
  namespace: mynamespace
data:
  foo: YmFy  # <- base64 encoded "bar"

Après conversion :

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: mysecret
  namespace: mynamespace
spec:
  encryptedData:
    foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

pré-requis

Avoir d’installer kubeseal et d’avoir un accès au cluster cible qui a sealed secrets d’installé.

Usage

Transforme un secret en secret sealed :

kubeseal -f my-secret.yaml -w my-secret-sealed.yaml -o yaml

Mise en place de Server-Sent Events

Wed, 07 Jan 2026 10:26:06 GMT

Après s’être posé la question de comment notifier le front de la fin d’un traitement back, j’ai décidé de réaliser un proof of concept (POC) pour mieux comprendre le fonctionnement et les difficulté à mettre en oeuvre une communication Server-Sent Events (SSE).

Scénario

Pour que le POC soit “crédible”, il nous faut deux prérequis :

Simuler un traitement asynchrone dans le backend
Le front doit réagir à la fin du traitement

Pour avoir un scénario réaliste, je pars d’un front basique qui souhaite diffuser un message. Il se trouve que, par hasard, la publication prend du temps, et que pour absorber le flux, Nous avons choisi de mettre en place une file de publication pour réaliser cette tâche en asynchrone. À chaque publication d’un message, nous souhaitons notifier les utilisateurs.

sequenceDiagram
    participant Frontend
    participant API 
    participant Service as PublicationService

    Frontend->>API: S'abonne aux notifications
    Frontend->>API: Publie un message
    API-)Service: Lance le traitement
    API-->>Frontend: Accusé de réception
    Note over Frontend: Clear du formulaire
    Note over Service: Traitement long
    Service-)API: Traitement terminé
    API-)Frontend: Notification SSE de traitement réussi
    Note over Frontend: Réception et affichage du message

Étapes de réalisation

Backend

Initialisation

En tant que développeur backend, je suis naturellement parti vers le composant back. L’initialisation à partir de Spring Initalizr, et c’est parti pour la génération, Spring boot 3.4, Java 21 (dernière LTS), Maven (déjà configuré). Nous ajoutons quelques modules pour se simplifier la vie :

Spring Web, pour exposer les services
Spring Modulith, pour tester l’architecture Hexagonal et le ApplicationEvent
Spring Data JDBC, pour gérer les notifications transactionnelles générées par Spring Modulith
H2 Database, pour avoir une base embarqué rapide à initialiser
Spring Boot DevTools, permet d’avoir du LiveReload
Lombok, injection de logger, finalement utilisation des records limite son usage
Spring Configuration Processor, pour améliorer la compatibilité de la configuration YAML

disclaimer

Je fais l’impasse sur la sécurité pour simplifier la configuration, car l’objectif n’est pas de déployer l’application. Certaines dépendances sont discutables, la gestion “transactionnelle” des notifications interne avec une reprise en cas de redémarre n’a pas vraiment de sens avec une base de données in-memory.

Définition de l’API

J’ai besoin de deux endpoints : un premier pour envoyer un message, rien de compliqué avec Spring MVC, une classe Controller, l’annotation @RestController et une méthode recevant du POST avec l’annotation @PostMapping

@RestController
public class MessageController {
	@PostMapping("/message")
	@ResponseStatus(HttpStatus.CREATED)
	public CreatedMessageEvent sendMessage(@RequestBody MessageDto message) {
		return new CreatedMessageEvent(UUID.randomUUID(), message.message(), message.channel(), LocalDateTime.now());
	}
}

Le deuxième endpoint pour la souscription aux événements de message. SSE se base sur le protocole HTTP, Spring nous fournit une classe SseEmitter qui spécialise ResponseBodyEmitter pour faire du SSE.

@GetMapping("/message/event")  
public SseEmitter subscribeMessageEvent() throws IOException {
    SseEmitter sseEmitter = new SseEmitter();
	// code pour émettre une notification
    return sseEmitter;  
}

Lancer le traitement du message

Lors de la réception d’un message, le contrôleur va créer un événement pour lancer le traitement. Puis répond au client que son message qu’il a reçu son message et qu’il va être traité.

Pour émettre un événement dans Spring, il suffit de publier dans ApplicationEventPublisher:

private final ApplicationEventPublisher events;
 
@PostMapping  
@ResponseStatus(HttpStatus.CREATED)  
@Transactional  
public CreatedMessageEvent sendMessage(@RequestBody MessageDto message) {  
    CreatedMessageEvent event = new CreatedMessageEvent(UUID.randomUUID(), message.message(), message.channel(), LocalDateTime.now());  
    events.publishEvent(event);  
  
    return event;  
}

Nous remarquerons la présence de @Transctional pour gérer la publication du message dans le cadre d’une notification “transactional” proposée par Spring Modulith.

Pour la réception de l’événement de “création de message”, j’ai choisi d’utiliser le listener fourni par Spring Modulith @ApplicationModuleListener. Cette annotation est un raccourci de plusieurs annotations :

@Async, qui permet d’ajouter de l’asynchrone dans notre traitement
@Transactional(propagation = Propagation.REQUIRES_NEW), ouvre une nouvelle transaction pour ne pas perturber la transaction d’origine
@TransactionalEventListener, qui surcharge @EventListener qui crée le endpoint de l’événement Et voilà notre méthode pour recevoir un événement de type CreatedMessageEvent:

@ApplicationModuleListener  
void publishMessage(CreatedMessageEvent messageEvent) {
	// Traitement de l'event
}

Nous avons besoin d’une base de données pour stocker les événements générés par l’application. J’ai choisi une base H2 pour simplifier la configuration et le lancement de l’application. Et maintenant, nous pouvons spécifier dans le fichier application.yml notre configuration :

spring:  
  datasource:  
    url: jdbc:h2:mem:messasync  
    driverClassName: org.h2.Driver
  modulith.events.jdbc.schema-initialization.enabled: true

Notifier le front

Le front s’abonne au notification via le endpoint défini, et lorsque nous avons traité notre message, nous publions un événement à tous les fronts qui le souhaite. Nous pouvons voir l’utilisation d’un pattern Observer sera adapté. Pour le créer, nous ajoutons une liste d’observateurs dans notre service de publication. Nous utilisons une liste concurrente pour ne pas avoir de conflit :

private final List<SseEmitter> observers = new CopyOnWriteArrayList<>();

Une méthode pour souscrire au événement, cette méthode sera appelée après la création du SseEmitter:

public void subscribe(SseEmitter sseEmitter) {  
    observers.add(sseEmitter);  
    sseEmitter.onCompletion(() -> {  
        observers.remove(sseEmitter);  
        log.debug("Removed completed sseEmitter {}", sseEmitter);  
    });  
    sseEmitter.onTimeout(() -> {  
        observers.remove(sseEmitter);  
        log.debug("Removed timeout sseEmitter {}", sseEmitter);  
    });  
    sseEmitter.onError((e) -> {  
        observers.remove(sseEmitter);  
        log.debug("remove error sseEmitter {}", sseEmitter, e);  
    });  
}

Lors de la souscription, nous ajoutons les méthodes de nettoyage lorsque la requête http est fermée.

Et dans la méthode de publication de message, nous allons notifier tous nos observers du nouveau message :

@ApplicationModuleListener
void publishMessage(CreatedMessageEvent messageEvent) {
  
    MessageEvent message = messageProcessingService.processMessage(convertEvent(messageEvent));
    
    observers.forEach(sseEmitter -> {
        try {
            sseEmitter.send(SseEmitter.event()
                .id(String.valueOf(message.id()))
                .name("createdMessage")
                .data(message, MediaType.APPLICATION_JSON));
        } catch (Exception e) {
            sseEmitter.completeWithError(e);  
        }
    });
}

Frontend

Côté Frontend, je vais rester succinct : pour lire les événements envoyés par le backend, nous pouvons utiliser l’interface EventSource malgré ses limites sur le nombre de connexions simultanées en HTTP/1.1, cette interface est déjà très puissante.

Pour fonctionner avec une application Angular, nous encapsulons cette EventSource dans un Observable.

export class MessageService {
	listenMessage(): Observable<MessageResponse> {  
	  return new Observable<MessageResponse>(observer => {  
	      const eventSource = new EventSource('http://localhost:8080/message/event');  
	      eventSource.addEventListener("createdMessage", (event) => {
	        let createdMessage = JSON.parse(event.data) as MessageResponse;  
	  
	        observer.next(createdMessage);  
	      });  
	  
	      eventSource.onerror = (event) => {  
	        console.log("Received error", event);  
	      }  
	      return () => {  
	        eventSource.close();  
	      }  
	    }  
	  )  
	}
}

Lorsque le composant doit écouter des événements, il appelle le service listenMessage, qui retourne un Observable. Si nous ne souhaitons plus écouter les événements ou si le composant est détruit, nous marquons l’Observable comme complété, ce qui déclenche la fermeture de l’EventSource et clôt ainsi la connexion entre le frontend et le backend.

Dans notre cas, nous ne faisons rien en cas d’erreur pour ne pas arrêter l’Observable. Il serait intéressant d’émettre un message d’erreur pour informer l’utilisateur du problème.

En cas d’interruption, comme une coupure réseau, un redémarrage de l’application ou un timeout, EventSource se charge de rouvrir la connexion.

Problèmes rencontrés

Erreur 503

Pas défaut, SseEmitter configure son timeout à 30 secondes, et quand je n’envoie pas de message, je reçois aucune données. Et l’interprétation HTTP quand aucune données n’a été envoyée est une réponse 503:

{
  "timestamp": "2025-04-18T13:22:02.325+00:00",
  "status": 503,
  "error": "Service Unavailable",
  "message": "No message available",
  "path": "/message/event"
}

Et cette réponse 503 interrompt la re-connexion de l’EventSource et finalement, quand nous décidons d’envoyer un message, nous ne recevrons pas la réponse.

La première astuce est d’envoyer un premier événement pour signifier que le backend est en vie. Pour ça, j’emmet un message de type heartbeat pour mieux identifier les messages de “ping” des messages qui contient de la vraie donnée. J’ai donc ajouté cette ligne dans la méthode subscribeMessageEvent de mon controller

sseEmitter.send(SseEmitter.event().name("heartbeat"));

Nous aurions pu imaginer aussi envoyer les précédents messages pour servir de “rattrapage”. Mais l’architecture actuelle mémorise aucun message.

Vérification des observers

Pour éviter de ré-ouvrir la connexion tous les 30 secondes, SseEmitter accepte de personnaliser le timeout lors de la phase d’initialisation. Dans la méthode subscribeMessageEvent de mon controller, j’ai ajouté un timeout de 10 minutes. Seulement en 10 minutes, nous pouvons cumuler beaucoup de connexion qui ne sont plus en vie. Et tant que nous n’envions pas de message, il n’y a pas de ménage réalisé.

Donc il faudrait faire du ménage de temps en temps pour enlever les connexions fantômes, et limiter le nombre d’erreur lors de la publication d’un message. Pour faire ça, j’ai ajouté une tâche planifier toutes les 30 secondes qui envoie un “ping” à chaque observer.

@Scheduled(fixedDelay = 30, timeUnit = TimeUnit.SECONDS)  
public void heartbeat() {  
    observers.forEach(sseEmitter -> {  
        try {  
            sseEmitter.send(SseEmitter.event().name("heartbeat"));  
        } catch (IOException e) {  
            sseEmitter.completeWithError(e);  
        } catch (IllegalStateException e) {  
            log.debug("emitter already closed");  
            observers.remove(sseEmitter);  
        }  
    });  
}

Cette option est discutable, ça ajoute du bruit sur le réseau et du traitement à intervalle régulier qui n’est pas nécessaire. Cette ajout permettrait de supprimer le 1er ping à l’ouverture de la connexion.

Évolution

Ajouter un filtre dans la souscription pour recevoir que les messages que d’un canal spécifique parmi un liste définie.

Sources :

dépôt GitHub

Script d'ajout des certificats racines dans le keystore de java

Wed, 07 Jan 2026 10:26:06 GMT

Pour réaliser des appels à des partenaires ou valider une authentification, une application Java réalise des appels HTTP. Ces appels doivent être sécurisés en utilisant le HTTPS et l’application vérifie que le certificat est valide. Pour valider le certificat, nous avons besoin d’ajouter les certificats racines dans le keystore.

La première étape est d’extraire les certificats racine et intermédiaires à partir d’une URL. On télécharge la chaîne de certificats à partir de openssl puis on l’extrait pour le mettre dans un fichier spécifique.

echo | openssl s_client -showcerts -connect ${HOSTNAME}:${PORT} | \
   awk '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/{print $0; if (/END CERTIFICATE/) print ""}' > "$CHAIN_FILE";
csplit -f cert- -n 2 "$CHAIN_FILE" '/END CERTIFICATE/+1' {2}

Récupération du nom du certificat pour l’injecter dans le keystore. Pour ce faire, on récupère le CN présent dans le certificat.

openssl x509 -in "$cert_file" -noout -subject -nameopt RFC2253 2>/dev/null | \
         sed -n 's/.*CN=\([^,]*\).*/\1/p'

Une fois les informations récupérées, on injecte dans le keystore de Java avec Keytool:

keytool -importcert -trustcacerts -cacerts -storepass "$keystore_password" -alias "$alias_name" -file "$cert_file" -noprompt

Compatible Java 9+

On utilise l’option -cacerts pour définir l’emplacement du cacerts de Java, qui a été introduite en version 9.

Le script complet est présent sur GitHub.

Tomcat - Ajout de configuration dans les properties

Wed, 07 Jan 2026 10:26:06 GMT

Pour ajouter un répertoire de configuration dans le classpath de tomcat. On peut ajouter cette argument dans le options JVM :

-Xbootclasspath/a:/my/conf/directory

Bookmarklet coloration Ansi

Wed, 07 Jan 2026 10:26:06 GMT

Il arrive d’avoir dans notre navigateur des sorties console brut, ceux-ci peuvent utiliser des codes couleurs ANSI \u001b[XXm, où XX correspond a une effet sur le texte. Le style est plutôt bien gérer dans un terminal mais pas gérer dans un navigateur.

Avec un peut code Javascript, on peut remplacer les codes par des balises HTML.

Pour l’utiliser, il suffit de l’ajouter en marque-pages, et de cliquer dessus pour faire apparaître les couleurs.

javascript:(function () {
  var map = {
    0: '</span>',
    30: "<span style='color: #000'>",
    31: "<span style='color: #A00'>",
    32: "<span style='color: #0A0'>",
    33: "<span style='color: #A50'>",
    34: "<span style='color: #00A'>",
    35: "<span style='color: #A0A'>",
    36: "<span style='color: #0AA'>",
    37: "<span style='color: #AAA'>",
    39: '</span>'
  };
  document.body.innerHTML = document.body.innerHTML.replace(/\u001b\[([0-9;]*)m/g, function (m, k) {
    return map[k] || '';
  });
  document.body.style.backgroundColor = "#000";
  document.body.style.color = "#AAA";
}());

Client HTTP REST

Wed, 07 Jan 2026 10:26:06 GMT

Pour remplacer Postman, certaines extensions VS Code ont développé une alternative vers un format texte proche de la spécification HTTP (RFC 2616) pour décrire les requêtes.

JetBrains a lui aussi le support des fichiers .http pour ajouter un client REST dans son IDE.

Points fort

le fichier est lisible.
c’est du texte, donc il peut être versionné sous git par exemple.
plusieurs extensions utilisent les fichiers .env pour injecter des variables, comme une authentification ou de définir un ensemble d’URL de service.
peut-être utilisé pour de la documentation.
peut servir pour générer des scénarios de tests.
gère du gRPC, GraphQL, SSE, Web Socket, MQTT et AMQP.

Points négatif

un fichier texte proche des spécifications HTTP est moins user-friendly pour des non-techs.
le support des scripts est dépendant de l’extension, par exemple httpyac support la syntaxe de JetBrains mais pas l’inverse.

La mise en place

Pour des requêtes simples, JetBrains suffit. Si on veut aller plus loin dans la création de scénarios, l’ajout d’authentification, j’aime bien le plugin httpyac qui peut même être utilisé dans une CI.

Sources :

mkcert - SSL pour du local

Wed, 07 Jan 2026 10:26:06 GMT

L’outil mkcert permet de générer des certificats SSL pour un environnement local en seulement quelques lignes de commande.

Je passe l’installation de l’outil en lui même dépendant du système comme Linux ou macOS.

La première étape, installer le certificat racine dans les truststores système et navigateur pour valider le certificat en local :

mkcert -install

Puis on peut générer un certificat pour du local :

mkcert "local.mygroup.fr" localhost 127.0.0.1 ::1

Il est possible d’utiliser l’option -pkcs12 pour créer un keystore utilisable par Java. Si on l’a oublié, il est possible de construire ce keystore avec la commande :

openssl pkcs12 -inkey localhost-key.pem -in localhost.pem -export -out localhost.pfx

Il est possible d’ajouter un connecteur Tomcat pour exécuter Tomcat en HTTPS sans erreur de certificat :

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/local.mygroup.fr+3.p12"
                         type="RSA" />
        </SSLHostConfig>
    </Connector>

Sources :

Docker privilege escalation

Tue, 29 Apr 2025 21:42:23 GMT

Les dangers du groupe docker

Si un utilisateur a le groupe docker alors il a tous les droits sur la machine. il peut utiliser un container du genre alpine ou ubuntu pour remonter le système en mode root

docker run --rm -it -u root --privileged -v /:/mnt -v /var:/mnt/var -v /home/:/mnt/home ubuntu:22.04 chroot /mnt /bin/bash

Source:

https://blog.creekorful.org/2020/08/docker-privilege-escalation/

Génération d'une nouvelle clé GPG

Tue, 29 Apr 2025 21:42:23 GMT

Si vous utilisez la version 2.1.17 ou une version ultérieure

gpg --full-generate-key

Possible de customiser l’algo :

gpg --default-new-key-algo rsa4096 --gen-key

Lié:

Vérification des clés GPG existantes

Source:

https://docs.github.com/fr/authentication/managing-commit-signature-verification/generating-a-new-gpg-key

Récupération de la clé publique

Tue, 29 Apr 2025 21:42:23 GMT

gpg --armor --export ID

Source:

https://docs.github.com/fr/authentication/managing-commit-signature-verification/checking-for-existing-gpg-keys

Vérification des clés GPG existantes

Tue, 29 Apr 2025 21:42:23 GMT

Liste les clés existantes

gpg --list-secret-keys --keyid-format=long

Possible de faire de la récupération de clé publique : Récupération de la clé publique ou de régénérer une nouvelle clé Génération d’une nouvelle clé GPG

Source:

Git - delete branch

Tue, 29 Apr 2025 21:42:23 GMT

Suppression des branches en local :

git branch -d maBranche

Suppression des branches en remote :

git push origin --delete maBranche

Accepte d’avoir plusieurs branches en une seule commande

Source:

Git - rebase branche to change base branch

Tue, 29 Apr 2025 21:42:23 GMT

Git permet de réécrire l’historique avec un rebase de déplacer une branche vers une autre. Ce cas d’usage peut être utile pour déplacer une feature d’une branche de support vers une autre version à cause d’un changement de périmètre.

Ce changement peut se réaliser en une simple ligne de command :

git rebase --onto $targetBranch $fromBranch $featureBranch

$targetBranch : la branche de destination sur lequel les commits seront rejoués
$fromBranch : la branche de base des commits à rejouer, les commits de cette branche seront exclus
$featureBranch : la branche contenant les commits qui vont être rejoués

Source:

https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing