Blog technique | Olivier Page

Claude Code tout au long du cycle de vie logiciel

Thu, 08 Oct 2026 00:00:00 GMT

Claude Code est l'outil de codage agentique d'Anthropic, qui s'exécute dans votre terminal et peut vous accompagner à chaque étape du cycle de vie logiciel. Ce guide relie les sept phases — des exigences à l'exploitation — aux prompts, à la configuration et aux diagrammes concrets qu'un développeur expert utilise réellement.

Le cycle de vie en sept phases

Chaque phase a une tâche pour l'agent. À chaque étape, vous décidez quoi déléguer et quoi relire vous-même. Voici la boucle, puis chaque phase en détail.

flowchart LR
    R[1. Requirements] --> P[2. Planning]
    P --> D[3. Design]
    D --> I[4. Development]
    I --> T[5. Testing]
    T --> C[6. CI / CD]
    C --> O[7. Operations]
    O -. feedback loop .-> R

1. Exigences

Claude transforme des notes brutes en backlog structuré et, surtout, signale ce qui est ambigu avant que cela ne devienne un bug. Donnez-lui la source et un format de sortie strict :

Turn notes/requirements.md into a structured backlog:
- Rewrite each functional requirement as "As a <role>, I want <goal>,
  so that <value>".
- List non-functional requirements (security, performance, availability)
  as separate items.
- Flag anything ambiguous or missing as an open question.
- Output a markdown table: ID | Requirement | Priority | Acceptance criteria.

2. Planification et estimation

Découpez les epics en tâches d'une journée, ordonnées par dépendance. L'agent est doué pour le séquencement car il voit le couplage entre fichiers et services :

Break this epic into tasks no larger than one day, ordered by dependency.
For each task give: title, affected files, effort (S/M/L), and definition
of done. Start with the riskiest task.

Epic: migrate order checkout from REST to async messaging.

Pour les gros changements, commencez en mode plan afin que Claude propose l'approche et la liste des tâches avant de toucher les fichiers. Relisez et ajustez le plan, puis laissez-le exécuter. Le plan devient votre gantt :

gantt
    title Sprint plan for checkout migration
    dateFormat  YYYY-MM-DD
    section Design
    ADR & event schema      :a1, 2026-10-08, 2d
    section Build
    Order service producer  :a2, after a1, 3d
    Consumer + DLQ          :a3, after a2, 3d
    section Test
    Contract tests          :a4, after a3, 2d
    section Ship
    Canary + rollout        :a5, after a4, 2d

3. Architecture et conception

Demandez à Claude de produire un diagramme système, puis contestez-le. Il critiquera volontiers le couplage, les points de défaillance uniques et les compromis de cohérence :

flowchart TD
    subgraph Client["Client"]
        A[Web App]
    end
    subgraph Edge["Edge"]
        B[API Gateway]
    end
    subgraph Core["Core services"]
        C[Order Service]
        D[Payment Service]
    end
    subgraph Data["Data"]
        E[(Order DB)]
        F[(Payment DB)]
    end
    A --> B
    B --> C
    B --> D
    C --> E
    D --> F
    C -. async events .-> D

Consignez le résultat dans un Architecture Decision Record afin que la session suivante — humaine ou agent — parte du même contexte :

# ADR-007: Move checkout to async messaging

## Status
Proposed

## Context
Checkout currently calls the payment service synchronously over REST.
Under peak load this couples availability and pushes latency past SLO.

## Decision
Publish an OrderPlaced event to the broker; the payment service consumes
it and publishes PaymentCaptured. Use an outbox pattern for reliability.

## Consequences
- Lower coupling and better tail latency.
- New failure modes need a dead-letter queue and idempotent consumers.

4. Développement

Un CLAUDE.md de qualité production est le levier le plus puissant pour une sortie cohérente. Il encode les commandes de build, l'architecture, les règles de sécurité et le style afin que chaque session parte de vos standards :

# CLAUDE.md

## Build & test
- `dotnet build` — build the solution (src/Orders.sln)
- `dotnet test` — run the xUnit suite
- `dotnet format` — apply code style from .editorconfig
- `dotnet ef migrations add <Name>` — add an EF Core migration

## Architecture
- `src/Orders.Api` — HTTP API (ASP.NET Core minimal APIs)
- `src/Orders.Application` — use cases, no I/O
- `src/Orders.Infrastructure` — EF Core, Azure Service Bus
- `src/Orders.Domain` — entities and value objects, no dependencies
- `tests/Orders.UnitTests` — one xUnit project per layer

## Security rules (never break these)
- Never log or commit secrets, tokens, or appsettings.Production.json
- Use parameterized queries; never concatenate SQL strings
- Do not add a package without mentioning it in the summary

## Testing
- New code ships with unit tests (xUnit + FluentAssertions)
- Mock external calls (HTTP, DB) — no network in unit tests
- Integration tests use Testcontainers

## Style
- Enable nullable reference types in every project
- Prefer records for DTOs and primary constructors for services
- Comments only explain "why", never "what"

Les routines répétables deviennent des skills. Écrivez la procédure une fois et déclenchez-la par son nom :

---
name: write-tests
description: Add unit tests for a changed class following project conventions.
---

1. Read the diff and find every public method that changed.
2. Write an xUnit test (with FluentAssertions) for the happy path plus one edge case each.
3. Mock dependencies with NSubstitute — no real I/O.
4. Run `dotnet test` and fix anything red before reporting.

Les tâches lourdes et isolées vont aux sous-agents au jeu d'outils restreint, gardant la session principale concentrée et peu coûteuse :

---
name: code-reviewer
description: Expert reviewer for pull requests.
tools: Read, Grep, Bash
model: sonnet
---

Review the diff for correctness, performance, and security.
Return findings ordered by severity (blocker, major, minor).

Les prompts fréquents deviennent des slash commands, et $ARGUMENTS les rend composables dans tout le code :

---
description: Generate unit tests for a given file.
---

Read the file at $ARGUMENTS and its dependencies. Write an xUnit
test at `tests/` covering the public methods, the happy path, and
one failure case. Run `dotnet test` and fix anything red.

5. Tests

Pratiquez le développement piloté par les tests en boucle serrée : vous écrivez le test qui échoue, Claude implémente le correctif minimal, et la suite est le contrat. Itérez jusqu'au vert, puis refactorisez :

flowchart LR
    W[Write failing test] --> R[Claude implements]
    R --> G{Suite green?}
    G -- No --> F[Claude fixes]
    F --> G
    G -- Yes --> RF[Refactor & review]
    RF --> W

Act as the implementer. I have written this failing xUnit test:

<test code>

Implement the minimal change that makes it pass. Do not add features
the test does not require. Run `dotnet test` and confirm green.

Avant de merger, confiez le diff à un sous-agent de revue. Il vérifie la justesse, la sécurité et les conventions sans brûler votre attention.

6. CI/CD et release

Claude Code a sa place dans le pipeline. Un merge n'a lieu qu'après lint, tests, scan de sécurité et revue automatisée — puis déploiement avec smoke test et chemin de rollback :

flowchart LR
    PR[Pull request] --> L[Lint & typecheck]
    L --> T[Unit tests]
    T --> S[Security scan]
    S --> R[Claude Code review]
    R --> M[Merge]
    M --> D[Deploy]
    D --> P[Smoke tests]
    P --> V{Pass?}
    V -- No --> RB[Rollback]
    V -- Yes --> O[Release]

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x
      - run: dotnet restore
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: >
            Review the changes in this pull request. Summarize the
            behaviour change, flag correctness and security issues,
            and post inline comments on the files.

Le mode headless rend l'agent scriptable, pour que les checklists de release et les migrations ponctuelles tournent depuis le terminal ou une étape de workflow :

claude -p "Run the release checklist and report failures" \
  --output-format stream-json \
  --permission-mode acceptEdits

Les hooks appliquent la politique au niveau de l'outil, en bloquant les commandes dangereuses avant qu'elles ne s'exécutent :

#!/usr/bin/env bash
# .claude/hooks/guard.sh — block destructive commands
set -euo pipefail

read -r INPUT

if echo "$INPUT" | grep -qE 'rm -rf|git push --force|DROP TABLE'; then
  echo "Blocked a potentially destructive command." >&2
  exit 2
fi

exit 0

7. Exploitation et maintenance

En astreinte, connectez Claude au code, à la base de données et au système de tickets via MCP, puis demandez-lui de trier un incident comme le ferait un ingénieur senior :

flowchart LR
    CC[Claude Code] <-->|MCP| GH[GitHub MCP]
    CC <-->|MCP| DB[(Database MCP)]
    CC <-->|MCP| TK[Ticketing MCP]

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<token>" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost:5432/app"]
    }
  }
}

Quand les serveurs prêts à l'emploi ne suffisent pas, construisez le vôtre avec le SDK officiel. Un serveur expose des outils typés que Claude peut appeler :

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'

const server = new McpServer({ name: 'ticketing', version: '1.0.0' })

server.tool(
  'search_tickets',
  'Search support tickets by keyword',
  { query: z.string().describe('Search term') },
  async ({ query }) => {
    const rows = await db.tickets.find({ subject: { $like: `%${query}%` } })
    return { content: [{ type: 'text', text: JSON.stringify(rows, null, 2) }] }
  },
)

const transport = new StdioServerTransport()
await server.connect(transport)

Pour conclure

Traitez Claude Code comme un coéquipier sur tout le cycle de vie : clarifiez les exigences, séquencez le plan, relisez la conception, implémentez et testez, gardez le merge et triez en production. Les experts qui en tirent le plus sont ceux qui définissent le contexte, codifient leurs standards et restent dans la boucle à chaque point de décision.

Angular pour les experts : architecture moderne et dernières nouveautés

Wed, 02 Sep 2026 00:00:00 GMT

Angular a beaucoup évolué ces dernières versions. Si vous avez écrit votre dernière application avec NgModule, *ngIf et des constructeurs @Injectable, une grande partie de tout cela est désormais optionnelle. Ce guide présente ce à quoi ressemble aujourd'hui un code Angular moderne, de niveau expert.

flowchart TD
    C[Component] --> S[Signals]
    C --> T[Template]
    T --> CF[Control flow]
    T --> DF[Defer]
    C --> I[inject services]
    I --> H[HttpClient / resource]
    C --> R[Router]
    R --> LZ[Lazy loading]
    R --> FG[Functional guards]

Composants standalone

NgModule est désormais optionnel. Les composants, directives et pipes déclarent leurs propres dépendances via imports, et l'application se câble avec des fonctions provide*.

import { Component, input, output } from '@angular/core'

@Component({
  selector: 'app-user-card',
  standalone: true,
  imports: [],
  template: `
    <div class="card">
      <h3>{{ name() }}</h3>
      <button (click)="select.emit(id())">Select</button>
    </div>
  `,
})
export class UserCardComponent {
  readonly id = input.required<number>()
  readonly name = input.required<string>()
  readonly select = output<number>()
}

Les signals : le cœur de la réactivité

Les signals remplacent la plupart de l'ancien cérémonial de ChangeDetectionStrategy. Ils sont le fondement des inputs, des outputs et de l'état dérivé.

import { Component, computed, effect, signal } from '@angular/core'

@Component({ /* ... */ })
export class CounterComponent {
  readonly count = signal(0)
  readonly double = computed(() => this.count() * 2)

  constructor() {
    effect(() => console.log('count is now', this.count()))
  }

  increment() {
    this.count.update((n) => n + 1)
  }
}

Le binding bidirectionnel moderne utilise model(), et les requêtes utilisent viewChild / contentChild qui renvoient des signals :

readonly value = model(0)
readonly list = viewChild.required(ElementRef)

Pour les données asynchrones, resource() remplace la danse manuelle « état de chargement + fetch » :

import { resource, signal } from '@angular/core'

export class UserListComponent {
  readonly search = signal('')

  readonly users = resource({
    request: () => ({ q: this.search() }),
    loader: ({ request }) => fetchUsers(request.q),
  })
}

resource() expose value(), status(), isLoading() et error(), pour que le template puisse réagir à chaque phase de chargement.

Flux de contrôle natif et chargement différé

Les anciennes directives structurelles *ngIf / *ngFor sont désormais des blocs intégrés qui se lisent comme du simple template.

@if (user(); as u) {
  <p>Hello {{ u.name }}</p>
} @else {
  <p>Not signed in</p>
}

@for (item of items(); track item.id) {
  <li>{{ item.label }}</li>
} @empty {
  <li>Nothing here</li>
}

@switch (status()) {
  @case ('ok') { <span>OK</span> }
  @case ('error') { <span>Error</span> }
  @default { <span>Unknown</span> }
}

Ne chargez les morceaux lourds que lorsque c'est nécessaire avec @defer :

@defer (on viewport) {
  <app-heavy-chart />
} @placeholder {
  <p>Chart appears here…</p>
} @loading (minimum 200ms) {
  <p>Loading…</p>
}

Détection de changements sans Zone.js (zoneless)

Vous pouvez désormais vous passer complètement de Zone.js. Fournissez la détection zoneless au bootstrap et laissez les signals indiquer à Angular ce qui a changé.

import { bootstrapApplication } from '@angular/platform-browser'
import { provideZonelessChangeDetection } from '@angular/core'

bootstrapApplication(AppComponent, {
  providers: [provideZonelessChangeDetection()],
})

Le zoneless réduit le surcoût d'exécution et les surprises — mais il attend un état basé sur les signals et du code compatible OnPush.

Injection de dépendances avec inject()

L'injection par constructeur est remplacée par la fonction inject(), qui rend le code concis et s'accorde avec les API fonctionnelles.

import { inject, Injectable } from '@angular/core'

@Injectable({ providedIn: 'root' })
export class UserService {
  readonly api = inject(ApiService)
  readonly users = this.api.getUsers()
}

Routing : guards fonctionnels et lazy loading

Les guards, resolvers et interceptors sont désormais de simples fonctions.

import { inject } from '@angular/core'
import type { CanActivateFn } from '@angular/router'
import type { HttpInterceptorFn } from '@angular/common/http'

// guard
export const authGuard: CanActivateFn = () => inject(AuthService).isLoggedIn()

// interceptor
export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthService).token()
  return next(req.clone({ setHeaders: { Authorization: `Bearer ${token}` } }))
}

Le lazy loading se fait par route et par composant :

export const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/admin.routes').then((m) => m.adminRoutes),
  },
  {
    path: 'profile',
    loadComponent: () =>
      import('./profile/profile.component').then((m) => m.ProfileComponent),
  },
]

HTTP avec les signals

HttpClient fonctionne directement avec les signals : un GET peut être une valeur réactive.

import { HttpClient, provideHttpClient } from '@angular/common/http'

@Injectable({ providedIn: 'root' })
export class UserService {
  private readonly http = inject(HttpClient)

  readonly users = this.http.get<User[]>('/api/users')
}

Pour un chargement par requête qui vit déjà dans un Observable, rxResource() enveloppe directement HttpClient :

import { inject, Injectable, signal } from '@angular/core'
import { HttpClient } from '@angular/common/http'
import { rxResource } from '@angular/core/rxjs-interop'

@Injectable({ providedIn: 'root' })
export class UserService {
  private readonly http = inject(HttpClient)
  readonly query = signal('')

  readonly users = rxResource({
    request: () => this.query(),
    loader: ({ request }) => this.http.get<User[]>(`/api/users?q=${request}`),
  })
}

rxResource() expose les mêmes signals value(), status(), isLoading() et error() que resource().

Gestion d'état avec NgRx

Pour l'état global, NgRx propose un SignalStore basé sur les signals, qui s'intègre au modèle moderne zoneless et piloté par signals.

import { computed } from '@angular/core'
import { patchState, signalStore, withComputed, withMethods, withState } from '@ngrx/signals'

interface CartState {
  items: CartItem[]
}

export const CartStore = signalStore(
  withState<CartState>({ items: [] }),
  withComputed(({ items }) => ({
    count: computed(() => items().length),
    total: computed(() => items().reduce((sum, item) => sum + item.price, 0)),
  })),
  withMethods((store) => ({
    addItem(item: CartItem) {
      patchState(store, { items: [...store.items(), item] })
    },
    removeItem(id: string) {
      patchState(store, { items: store.items().filter((item) => item.id !== id) })
    },
  })),
)

Fournissez le store et injectez-le dans le composant :

@Component({
  selector: 'app-cart',
  standalone: true,
  providers: [CartStore],
  template: `
    <p>{{ cartStore.count() }} items — {{ cartStore.total() | currency }}</p>
    <button (click)="cartStore.addItem({ id: '1', price: 10 })">Add</button>
  `,
})
export class CartComponent {
  readonly cartStore = inject(CartStore)
}

Pour les collections, withEntities fournit une forme normalisée prête à l'emploi :

import { setAllEntities, withEntities } from '@ngrx/signals/entities'

export const UserStore = signalStore(
  withEntities<User>(),
  withMethods((store) => ({
    load(users: User[]) {
      patchState(store, setAllEntities(users))
    },
  })),
)

Pour une orchestration asynchrone complexe, le classique @ngrx/effects excelle toujours ; createEffect transforme des flux d'actions en effets de bord.

@Injectable()
export class UserEffects {
  private readonly actions$ = inject(Actions)
  private readonly users = inject(UserService)

  loadUsers$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadUsers),
      switchMap(() => this.users.getAll().pipe(
        map((users) => loadUsersSuccess({ users })),
      )),
    ),
  )
}

SignalStore est le choix moderne par défaut pour la plupart des états ; utilisez @ngrx/effects quand vous avez besoin de flux asynchrones avancés.

Une architecture moderne

Une application Angular propre et scalable aujourd'hui ressemble à ceci :

Tout en standalone — pas de NgModule, des imports explicites.
Signals pour l'état — signal/computed/effect plus model/input.
inject() partout — des services composables et testables.
Zoneless + OnPush — une détection de changements prévisible.
Guards/interceptors fonctionnels — une couche de routing fine et typée.
Routes lazy + @defer — un chargement initial rapide.
Dossiers par fonctionnalité — grouper par domaine, pas par couche.

src/app/
  auth/
    login.component.ts
    auth.service.ts
    auth.guard.ts
  orders/
    order-list.component.ts
    order.service.ts
  shared/
    ui/
      button.component.ts

Historique des versions

Une chronologie condensée des versions majeures et de leurs changements clés.

Version	Sortie	Changements majeurs / breaking changes
2.0	Sept 2016	Réécriture complète depuis AngularJS : TypeScript, composants, DI
4.0	Mars 2017	Saut de version (pas de 3.x) ; nouveau `HttpClient` ; package d'animations
5.0	Nov 2017	Build optimizer ; `HttpClient` stable
6.0	Mai 2018	Workspaces Angular CLI ; RxJS 6 ; providers tree-shakables
7.0	Oct 2018	Prompts CLI ; drag & drop CDK et virtual scrolling
8.0	Mai 2019	Ivy (aperçu) ; differential loading ; import dynamique pour les routes lazy
9.0	Fév 2020	Ivy activé par défaut ; améliorations TestBed
10.0	Juin 2020	TypeScript 3.9 ; nouveau sélecteur de plage de dates
11.0	Nov 2020	Hot module replacement ; types plus stricts
12.0	Mai 2021	View Engine supprimé ; API moderne de Sass ; mode strict par défaut
13.0	Nov 2021	Support IE11 abandonné ; RxJS 7 ; plus d'`entryComponents`
14.0	Juin 2022	Composants standalone (aperçu) ; formulaires réactifs typés ; `inject()`
15.0	Nov 2022	Standalone stable ; `NgModule` optionnel ; directive composition API
16.0	Mai 2023	Signals (aperçu) ; serveur de dev esbuild ; inputs requis
17.0	Nov 2023	Flux de contrôle intégré ; `@defer` ; standalone par défaut
18.0	Mai 2024	Zoneless (expérimental) ; variables `@let` ; inputs/outputs signals
19.0	Nov 2024	Signals stables ; `resource()`/`rxResource()` ; `linkedSignal`
20.0	Mai 2025	Détection zoneless stable (par défaut pour les nouvelles apps)
21.0	Nov 2025	Améliorations signals et zoneless

Pour conclure

Le passage aux signals, aux composants standalone et à la détection zoneless est le plus grand bouleversement de l'histoire d'Angular. L'adopter — signals pour l'état, inject() pour les dépendances, routing fonctionnel et lazy loading — vous donne des bundles plus petits, moins de bugs de détection de changements et un code bien plus facile à raisonner.

Les design patterns pour les développeurs : un guide accessible

Wed, 02 Sep 2026 00:00:00 GMT

Les design patterns sont des solutions réutilisables à des problèmes courants. Ce ne sont pas des modèles à copier-coller — ce sont des idées que l'on adapte à sa propre situation. Ce guide présente dix des plus utiles, regroupés par rôle.

flowchart TD
    A[Design patterns] --> B[Creational]
    A --> C[Structural]
    A --> D[Behavioral]
    A --> E[Architectural]
    B --> B1[Singleton]
    B --> B2[Builder]
    C --> C1[Adapter]
    C --> C2[Decorator]
    C --> C3[Facade]
    D --> D1[Strategy]
    D --> D2[Observer]
    D --> D3[Chain of Responsibility]
    E --> E1[MVC]
    E --> E2[MVVM]
    E --> E3[CQRS]
    E --> E4[Event Sourcing]

Strategy (Stratégie)

L'idée : choisir un algorithme à l'exécution sans changer le code qui l'appelle.

Pensez à une page de paiement : le client peut payer par carte, PayPal ou virement. Chaque option est une stratégie différente derrière le même bouton.

public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

public class CreditCardPayment : IPaymentStrategy
{
    public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} by card");
}

public class PayPalPayment : IPaymentStrategy
{
    public void Pay(decimal amount) => Console.WriteLine($"Paid {amount} via PayPal");
}

public class Checkout
{
    private readonly IPaymentStrategy _strategy;

    public Checkout(IPaymentStrategy strategy) => _strategy = strategy;

    public void Complete(decimal amount) => _strategy.Pay(amount);
}

Decorator (Décorateur)

L'idée : ajouter un comportement à un objet en l'enveloppant, couche par couche.

Comme ajouter des suppléments à un café : on part d'un espresso et on empile le lait, le sucre ou le caramel sans modifier l'espresso lui-même.

public interface ICoffee
{
    string Description { get; }
    decimal Cost { get; }
}

public class Espresso : ICoffee
{
    public string Description => "Espresso";
    public decimal Cost => 2.00m;
}

public class MilkDecorator : ICoffee
{
    private readonly ICoffee _inner;

    public MilkDecorator(ICoffee inner) => _inner = inner;

    public string Description => _inner.Description + ", milk";
    public decimal Cost => _inner.Cost + 0.50m;
}

Observer (Observateur)

L'idée : un objet notifie plusieurs abonnés lorsqu'il change.

Comme une newsletter : les gens s'abonnent et chacun reçoit une mise à jour à chaque nouvelle édition.

public interface IListener
{
    void Notify(string message);
}

public class NewsFeed
{
    private readonly List<IListener> _listeners = new();

    public void Subscribe(IListener listener) => _listeners.Add(listener);

    public void Publish(string message) =>
        _listeners.ForEach(listener => listener.Notify(message));
}

Chaîne de responsabilité (Chain of Responsibility)

L'idée : faire passer une requête le long d'une chaîne de gestionnaires jusqu'à ce que l'un d'eux la traite.

Comme le support client : un ticket est escaladé niveau par niveau jusqu'à ce que quelqu'un puisse le résoudre. Chaque gestionnaire décide de traiter la requête ou de la transmettre.

public interface IHandler
{
    IHandler SetNext(IHandler handler);
    void Handle(string request);
}

public abstract class BaseHandler : IHandler
{
    private IHandler? _next;

    public IHandler SetNext(IHandler handler)
    {
        _next = handler;
        return handler;
    }

    public virtual void Handle(string request)
    {
        _next?.Handle(request);
    }
}

public class AuthHandler : BaseHandler
{
    public override void Handle(string request)
    {
        if (request.StartsWith("auth"))
        {
            Console.WriteLine("Auth passed");
            base.Handle(request);
        }
        else
        {
            Console.WriteLine("Auth failed — stop");
        }
    }
}

public class LoggingHandler : BaseHandler
{
    public override void Handle(string request)
    {
        Console.WriteLine($"Logging: {request}");
        base.Handle(request);
    }
}

var logging = new LoggingHandler();
var auth = new AuthHandler();
logging.SetNext(auth);

logging.Handle("auth:user-42");

Chaque gestionnaire ne connaît que le suivant, donc la chaîne peut être réordonnée ou étendue sans modifier les gestionnaires existants.

Singleton

L'idée : garantir qu'il n'existe qu'une seule instance d'une classe.

Comme un fichier de configuration unique pour une application — tout le monde lit le même.

public sealed class Configuration
{
    public static Configuration Instance { get; } = new Configuration();

    private Configuration() { }

    public string AppName => "MyApp";
}

Facade (Façade)

L'idée : masquer un système complexe derrière une porte d'entrée simple.

Comme le contact d'une voiture : on tourne une clé et de nombreux éléments travaillent ensemble en dessous.

public class OrderFacade
{
    private readonly PaymentService _payment = new();
    private readonly InventoryService _inventory = new();

    public void PlaceOrder(Order order)
    {
        _payment.Charge(order);
        _inventory.Reserve(order);
    }
}

Builder (Monteur)

L'idée : construire un objet complexe étape par étape plutôt qu'avec un énorme constructeur.

Comme commander un burger personnalisé : on choisit le pain, le fromage, les extras — puis on assemble.

public class Burger
{
    public bool Cheese { get; set; }
    public bool Bacon { get; set; }
}

public class BurgerBuilder
{
    private readonly Burger _burger = new();

    public BurgerBuilder AddCheese() { _burger.Cheese = true; return this; }

    public BurgerBuilder AddBacon() { _burger.Bacon = true; return this; }

    public Burger Build() => _burger;
}

Adapter (Adaptateur)

L'idée : faire fonctionner ensemble deux interfaces incompatibles.

Comme un adaptateur de prise de voyage qui permet à votre chargeur de se brancher sur une prise étrangère.

public interface IShape
{
    double Area();
}

public class LegacyRectangle
{
    public double Width { get; set; }
    public double Height { get; set; }
}

public class RectangleAdapter : IShape
{
    private readonly LegacyRectangle _rect;

    public RectangleAdapter(LegacyRectangle rect) => _rect = rect;

    public double Area() => _rect.Width * _rect.Height;
}

MVC (Model-View-Controller)

L'idée : séparer les données, la présentation et la logique de contrôle.

Le model détient les données, la view les affiche et le controller réagit aux actions de l'utilisateur.

public class User
{
    public string Name { get; set; } = "Olivier";
}

public class UserController
{
    public string GetUserName() => new User().Name;
}

MVVM (Model-View-ViewModel)

L'idée : lier directement la vue à un view model, afin que l'interface se mette à jour automatiquement quand les données changent.

Populaire dans les applications desktop et mobiles : un clic modifie une propriété et l'écran le reflète sans câblage manuel.

public class CounterViewModel : INotifyPropertyChanged
{
    private int _count;

    public int Count
    {
        get => _count;
        set { _count = value; OnPropertyChanged(); }
    }

    public void Increment() => Count++;

    // INotifyPropertyChanged implementation omitted for brevity
}

CQRS (Séparation commande/requête)

L'idée : séparer les écritures (commandes) des lectures (requêtes).

Les lectures et les écritures ont souvent besoin de modèles et de stockages différents. Les séparer garde chaque côté simple et scalable.

public record CreateOrderCommand(int Id, decimal Total);

public record GetOrderQuery(int Id);

public class CreateOrderHandler
{
    public void Handle(CreateOrderCommand command) { /* save the order */ }
}

public class GetOrderHandler
{
    public Order Handle(GetOrderQuery query) => /* load the order */ null!;
}

Event Sourcing (Sourcing d'événements)

L'idée : stocker chaque changement d'état comme un événement immuable, et reconstruire l'état courant en rejouant ces événements.

Au lieu d'enregistrer le solde actuel, vous enregistrez « déposé 100 », « retiré 40 ». Le solde est une projection que vous pouvez recalculer à tout moment.

public interface IEvent { }

public record AccountOpened(Guid AccountId, string Owner) : IEvent;
public record MoneyDeposited(Guid AccountId, decimal Amount) : IEvent;
public record MoneyWithdrawn(Guid AccountId, decimal Amount) : IEvent;

public class Account
{
    public Guid Id { get; private set; }
    public decimal Balance { get; private set; }

    public void Apply(IEvent @event)
    {
        switch (@event)
        {
            case AccountOpened e:
                Id = e.AccountId;
                break;
            case MoneyDeposited e:
                Balance += e.Amount;
                break;
            case MoneyWithdrawn e:
                Balance -= e.Amount;
                break;
        }
    }
}

// load = replay the history
var account = new Account();
foreach (var @event in eventStore.Load(accountId))
{
    account.Apply(@event);
}

Le sourcing d'événements offre une piste d'audit complète, rend l'état reproductible et se marie naturellement avec CQRS — mais il coûte plus de stockage et de complexité.

Pour conclure

Vous n'utiliserez pas chaque pattern tous les jours — mais les reconnaître vous aide à lire le code des autres, à discuter clairement des conceptions et à choisir le bon outil quand un problème vous semble familier.

Java et l'écosystème Spring pour les experts : Boot, Security, JPA, Kafka, profils, gateway

Wed, 02 Sep 2026 00:00:00 GMT

Java ne cesse de devenir plus concis, et l'écosystème Spring ne cesse de supprimer le boilerplate. Ce guide couvre les fonctionnalités du langage et les modules Spring qu'un développeur backend expert utilise au quotidien, puis se termine par une chronologie des versions.

flowchart TD
    B[Spring Boot] --> S[Spring Security]
    B --> J[Spring Data JPA]
    B --> C[Spring Cloud Stream]
    B --> P[Profiles]
    B --> G[Spring Cloud Gateway]
    B --> BA[Spring Batch]
    C --> K[Kafka Binder]
    BA --> DB[(Database)]

Java moderne

Lambdas

Un lambda est une implémentation compacte d'une interface fonctionnelle (une interface à une seule méthode abstraite). Il alimente l'API Stream et les DSL fonctionnels de Spring.

List<String> names = List.of("Ada", "Bob", "Cara");

// lambda
names.forEach(name -> System.out.println(name));

// method reference
names.forEach(System.out::println);

Le JDK fournit les interfaces fonctionnelles courantes, vous en écrivez donc rarement.

Predicate<String> isLong = s -> s.length() > 3;
Function<String, Integer> length = String::length;
Consumer<String> print = System.out::println;
Supplier<String> id = () -> UUID.randomUUID().toString();

Streams

Un stream est un pipeline sur une collection : une source, une chaîne d'opérations intermédiaires paresseuses, et une opération terminale qui l'exécute.

List<Order> orders = List.of(/* ... */);

List<String> emails = orders.stream()
  .filter(o -> o.total() > 100)
  .sorted(Comparator.comparing(Order::total).reversed())
  .map(Order::customerEmail)
  .distinct()
  .limit(10)
  .toList();

Opérations terminales courantes :

double sum = orders.stream().mapToDouble(Order::total).sum();

Map<Status, List<Order>> byStatus =
  orders.stream().collect(Collectors.groupingBy(Order::status));

boolean anyLarge = orders.stream().anyMatch(o -> o.total() > 1000);

filter, map, sorted, distinct et limit sont paresseuses ; toList, collect, reduce et forEach déclenchent le pipeline. Les streams encouragent un traitement de données immuable et déclaratif.

Records

Les records offrent des porteurs de données immuables sans boilerplate.

public record User(String name, int age) { }

Pattern matching

instanceof rétrécit la variable sur place.

if (obj instanceof String s) {
  System.out.println(s.length());
}

Les expressions switch se combinent au pattern matching pour une logique typée et exhaustive.

String result = switch (obj) {
  case Integer i -> "int " + i;
  case String s  -> "str " + s;
  default        -> "other";
};

Classes scellées

Les hiérarchies scellées déclarent chaque sous-type autorisé, pour que le compilateur puisse vérifier l'exhaustivité.

public sealed interface Shape permits Circle, Square { }

public record Circle(double radius) implements Shape { }
public record Square(double side) implements Shape { }

Threads virtuels

Le projet Loom (stable depuis Java 21) fait évoluer le code bloquant avec des threads légers et peu coûteux.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  executor.submit(() -> handleRequest());
}

Spring Boot

Spring Boot câble une application à partir d'une seule annotation et de valeurs par défaut sensées, configurées via application.yml.

@SpringBootApplication
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

Les starters apportent toute une fonctionnalité (web, data, security) avec une seule dépendance, et l'auto-configuration s'adapte à ce qui est sur le classpath.

Beans et composants Spring

Un bean est tout objet géré par le conteneur IoC de Spring. Les composants sont des classes auto-détectées par le scan de composants via des annotations stéréotypes.

@Component
public class EmailService { }

@Service
public class OrderService { }

@Repository
public class OrderRepository { }

@Controller
public class OrderController { }

@Component est le stéréotype générique ; @Service, @Repository et @Controller sont des spécialisations qui ajoutent du sens et des comportements futurs.

Pour les objets tiers ou construits manuellement, déclarez un bean dans une classe @Configuration.

@Configuration
public class AppConfig {
  @Bean
  OrderValidator orderValidator() {
    return new OrderValidator();
  }
}

Injectez les dépendances par le constructeur — le choix moderne et testable.

@Service
public class OrderService {
  private final OrderRepository repository;
  private final EmailService email;

  public OrderService(OrderRepository repository, EmailService email) {
    this.repository = repository;
    this.email = email;
  }
}

@Autowired est l'ancienne méthode pilotée par annotations. Elle peut cibler les champs, les setters ou les constructeurs.

@Service
public class OrderService {

  @Autowired
  private OrderRepository repository;

  private EmailService email;

  @Autowired
  public void setEmailService(EmailService email) {
    this.email = email;
  }
}

L'injection par champ et par setter est flexible mais rend les dépendances mutables et plus difficiles à tester. Préférez l'injection par constructeur — sur un constructeur unique, @Autowired est même optionnel.

Quand plusieurs beans partagent le même type, @Qualifier choisit le bon.

@Service
public class CreditCardPayment implements PaymentService { }

@Service
public class PayPalPayment implements PaymentService { }

@Service
public class CheckoutService {

  private final PaymentService payment;

  public CheckoutService(@Qualifier("payPalPayment") PaymentService payment) {
    this.payment = payment;
  }
}

Le qualifier est le nom du bean — par défaut le nom de classe avec une première lettre minuscule. Vous pouvez fixer un nom explicite avec @Service("paypal") ou @Bean("paypal").

Spring propose plusieurs scopes de beans. singleton (par défaut) crée une instance par conteneur ; prototype crée une nouvelle instance à chaque demande ; les scopes web (request, session, application, websocket) sont liés à un contexte web.

// singleton (default) — one instance per container
@Component
public class SingletonService { }

// prototype — a new instance on every injection
@Component
@Scope("prototype")
public class ShoppingCart { }

// request — one instance per HTTP request
@Component
@Scope(value = WebApplicationContext.SCOPE_REQUEST,
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class RequestContext { }

// session — one instance per HTTP session
@Component
@Scope(value = WebApplicationContext.SCOPE_SESSION,
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSession { }

// application — one instance per ServletContext
@Component
@Scope(value = WebApplicationContext.SCOPE_APPLICATION)
public class AppWideConfig { }

// websocket — one instance per WebSocket session
@Component
@Scope(value = "websocket",
       proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ChatSession { }

Les scopes à courte durée (request, session, websocket) nécessitent proxyMode = ScopedProxyMode.TARGET_CLASS pour pouvoir être injectés dans des singletons à plus longue durée.

Spring fournit des annotations raccourcies pour les scopes web courants :

@Component
@RequestScope
public class RequestContext { }

@Component
@SessionScope
public class UserSession { }

@Component
@ApplicationScope
public class AppWideConfig { }

@RequestScope et @SessionScope sont des raccourcis pour la version @Scope avec proxyMode = ScopedProxyMode.TARGET_CLASS. Il n'y a pas de raccourci pour prototype ou websocket — utilisez @Scope pour ceux-là.

Voici l'ensemble complet :

Scope	Durée de vie	Raccourci
`singleton`	Une instance par conteneur	par défaut
`prototype`	Nouvelle instance à chaque demande	—
`request`	Une instance par requête HTTP	`@RequestScope`
`session`	Une instance par session HTTP	`@SessionScope`
`application`	Une instance par `ServletContext`	`@ApplicationScope`
`websocket`	Une instance par session WebSocket	—

En bref, les annotations raccourcies sont @RequestScope, @SessionScope et @ApplicationScope. Spring Cloud fournit aussi @RefreshScope pour @Scope("refresh"). Il n'y a pas de raccourci pour singleton (par défaut), prototype ou websocket.

@SpringBootApplication active le scan de composants sur son package, donc toute classe annotée y est détectée automatiquement.

Spring Security

La sécurité se configure via un bean SecurityFilterChain. Le DSL lambda est le style moderne et lisible.

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  return http
    .authorizeHttpRequests(auth -> auth
      .requestMatchers("/api/public/**").permitAll()
      .anyRequest().authenticated())
    .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()))
    .build();
}

Les resource servers JWT sont la norme pour les API sans état ; la sécurité par méthode (@PreAuthorize) protège les appels de service individuels. Activez-la avec @EnableMethodSecurity et annotez les méthodes à protéger.

@RestController
@RequestMapping("/api/orders")
public class OrderController {

  private final OrderService orders;

  public OrderController(OrderService orders) {
    this.orders = orders;
  }

  @PreAuthorize("hasRole('ADMIN')")
  @DeleteMapping("/{id}")
  public void cancel(@PathVariable Long id) {
    orders.cancel(id);
  }
}

@PreAuthorize accepte SpEL : vous pouvez vérifier les rôles (hasRole), les autorités (hasAuthority) ou la requête elle-même (#id == authentication.name). Utilisez @PostAuthorize pour filtrer la valeur retournée après l'exécution.

Filtres vs interceptors

Les deux enveloppent les requêtes, mais à des couches différentes. Un filtre fait partie de l'API Servlet et s'exécute autour de toute la requête, avant le DispatcherServlet de Spring. Un interceptor est Spring MVC et s'exécute dans le dispatcher, avec accès au contrôleur cible.

flowchart LR
    R[Request] --> F[Filter]
    F --> D[DispatcherServlet]
    D --> I[Interceptor]
    I --> C[Controller]

Un filtre sert aux préoccupations qui doivent s'exécuter avant même que Spring ne voie la requête :

@Component
public class RequestLoggingFilter extends OncePerRequestFilter {

  @Override
  protected void doFilterInternal(
      HttpServletRequest request,
      HttpServletResponse response,
      FilterChain chain) throws ServletException, IOException {

    long start = System.currentTimeMillis();
    chain.doFilter(request, response);
    log.info("{} {} took {} ms", request.getMethod(),
        request.getRequestURI(), System.currentTimeMillis() - start);
  }
}

Un interceptor sert aux préoccupations qui ont besoin du contrôleur, comme chronométrer un handler précis :

@Component
public class TimingInterceptor implements HandlerInterceptor {

  @Override
  public boolean preHandle(HttpServletRequest request,
      HttpServletResponse response, Object handler) {
    request.setAttribute("startTime", System.currentTimeMillis());
    return true;
  }

  @Override
  public void afterCompletion(HttpServletRequest request,
      HttpServletResponse response, Object handler, Exception ex) {
    long start = (long) request.getAttribute("startTime");
    log.info("Handler {} took {} ms", handler,
        System.currentTimeMillis() - start);
  }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

  @Override
  public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new TimingInterceptor())
        .addPathPatterns("/api/**");
  }
}

	Filtre	Interceptor
Couche	API Servlet	Spring MVC
S'exécute	Avant le `DispatcherServlet`	Dans le `DispatcherServlet`
Voit le contrôleur	Non	Oui (`HandlerMethod`)
Usages types	Auth, CORS, encodage, journalisation	Chronométrage, attributs de modèle, journalisation par handler

En bref : les filtres pour le niveau conteneur, les interceptors pour le niveau MVC.

@RestController vs @Controller

@Controller est le stéréotype MVC classique : ses méthodes renvoient un nom de vue résolu par un ViewResolver. @RestController est la combinaison de @Controller + @ResponseBody, donc ses méthodes renvoient des données sérialisées en JSON.

@Controller
public class PageController {

  @GetMapping("/")
  public String home() {
    return "index"; // view name, not JSON
  }
}

@RestController
@RequestMapping("/api/users")
public class UserController {

  private final UserService users;

  public UserController(UserService users) {
    this.users = users;
  }

  @GetMapping
  public List<User> list() {
    return users.findAll(); // serialized to JSON
  }
}

@GetMapping, @PostMapping, @PutMapping et @DeleteMapping sont des raccourcis pour @RequestMapping(method = ...). Utilisez @Controller pour les pages rendues côté serveur et @RestController pour les API.

Spring Data JPA

Les entités mappent les classes aux tables, et les interfaces de repository génèrent les requêtes à partir des noms de méthode.

@Entity
@Table(name = "customer")
public class Customer {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  @Column(nullable = false)
  private String name;
}

public interface CustomerRepository extends JpaRepository<Customer, Long> {
  List<Customer> findByNameContainingIgnoreCase(String name);

  Page<Customer> findByNameContainingIgnoreCase(String name, Pageable pageable);
}

La pagination utilise Pageable avec Page ou Slice :

Page<Customer> page = repository.findByNameContainingIgnoreCase(
    "a", PageRequest.of(0, 20, Sort.by("name")));

List<Customer> content = page.getContent();
long total = page.getTotalElements();
int pages = page.getTotalPages();

PageRequest.of(page, size) correspond à offset = page * size et limit = size. Page exécute une requête COUNT supplémentaire pour le total ; utilisez Slice pour l'éviter quand vous n'avez besoin que d'un indicateur « a-t-il une suite ».

Utilisez @Transactional sur les frontières de service pour que plusieurs écritures soient validées ou annulées ensemble.

@Service
public class OrderService {

  private final OrderRepository orders;
  private final PaymentService payments;

  public OrderService(OrderRepository orders, PaymentService payments) {
    this.orders = orders;
    this.payments = payments;
  }

  @Transactional
  public Order placeOrder(Order order) {
    Order saved = orders.save(order);
    payments.charge(order.getTotal());
    return saved;
  }
}

Si une étape lève une RuntimeException, toute la méthode est annulée. Ajustez-la avec rollbackFor (pour les exceptions vérifiées), readOnly = true (pour les requêtes en lecture seule) et propagation (pour rejoindre ou exiger une nouvelle transaction).

Lombok et MapStruct

Lombok

Lombok supprime le boilerplate avec des annotations à la compilation. @Getter/@Setter génèrent les accesseurs, @Builder un builder et @Slf4j un logger.

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Entity
public class Customer {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  private String name;
}

@RequiredArgsConstructor génère un constructeur pour les champs final, ce qui se marie parfaitement avec l'injection par constructeur.

@Service
@RequiredArgsConstructor
public class OrderService {
  private final OrderRepository orders;
  private final PaymentService payments;

  public void place(Order order) {
    orders.save(order);
  }
}

@Data regroupe les accesseurs avec equals/hashCode/toString, mais évitez-le sur les entités JPA, où le equals généré peut mal se comporter sur un état mutable.

MapStruct

MapStruct génère des mappers typés entre DTO et entités à la compilation. Déclarez une interface et il produit l'implémentation.

@Mapper(componentModel = "spring")
public interface CustomerMapper {

  CustomerDto toDto(Customer customer);

  @Mapping(target = "id", ignore = true)
  Customer toEntity(CreateCustomerRequest request);
}

Avec componentModel = "spring", le mapper est un bean Spring injectable.

@Service
@RequiredArgsConstructor
public class CustomerService {
  private final CustomerRepository repository;
  private final CustomerMapper mapper;

  public CustomerDto create(CreateCustomerRequest request) {
    return mapper.toDto(repository.save(mapper.toEntity(request)));
  }
}

Contrairement aux mappers à réflexion, MapStruct est type-safe et échoue à la compilation quand les champs ne correspondent pas.

Spring Cloud Stream avec le binder Kafka

Cloud Stream abstrait l'infrastructure de messagerie derrière un modèle de binding, de sorte que votre code parle fonctions, pas clients Kafka.

@Bean
Function<Order, Order> processOrder() {
  return order -> {
    // validate, enrich, or transform
    return order;
  };
}

spring:
  cloud:
    stream:
      bindings:
        processOrder-in-0:
          destination: orders
        processOrder-out-0:
          destination: orders-processed
      kafka:
        binder:
          brokers: localhost:9092

Changez le binder (Kafka, Rabbit, Kafka Streams) sans toucher à la fonction.

Profils

Les profils chargent une configuration différente par environnement. Les fichiers se nomment application-{profile}.yml, et spring.profiles.active les sélectionne.

spring:
  profiles:
    active: dev

# application-dev.yml
server:
  port: 8080

Chargement de plusieurs profils

Les profils sont additifs et ordonnés — activez-en plusieurs à la fois :

spring:
  profiles:
    active: dev,local

Règles de chargement :

Un profil plus tardif remplace un profil plus précoce.
Chaque application-{profile}.yml remplace le application.yml de base.
Sans profil actif, Spring utilise le profil default (application.yml seulement).
Activez-les en externe avec la variable d'environnement SPRING_PROFILES_ACTIVE ou --spring.profiles.active=dev,local.

Un profil peut aussi en inclure d'autres avec include :

spring:
  profiles:
    include: common,metrics

Vous pouvez aussi conditionner des beans avec @Profile.

@Component
@Profile("!prod")
public class DevDataSeeder { }

Spring Cloud Gateway

La gateway route les requêtes vers les services en aval à l'aide de prédicats et de filtres.

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1

Les prédicats font correspondre la requête ; les filtres la transforment (réécrire le chemin, ajouter des en-têtes, couper le circuit). Avec un client de découverte, lb:// répartit la charge entre les instances.

Spring Batch

Spring Batch gère de grands traitements de données planifiés : lire par blocs, traiter, écrire, avec reprise et nouvelle tentative intégrées. Un job est constitué d'étapes orientées par blocs (chunk).

@Configuration
@EnableBatchProcessing
public class BatchConfig {

  @Bean
  public Job importUsersJob(JobRepository jobRepository, Step step) {
    return new JobBuilder("importUsersJob", jobRepository)
        .start(step)
        .build();
  }

  @Bean
  public Step step(JobRepository jobRepository,
      PlatformTransactionManager transactionManager,
      ItemReader<User> reader,
      ItemProcessor<User, User> processor,
      ItemWriter<User> writer) {
    return new StepBuilder("step", jobRepository)
        .<User, User>chunk(100, transactionManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();
  }

  @Bean
  public ItemReader<User> reader() {
    return new FlatFileItemReaderBuilder<User>()
        .name("userReader")
        .resource(new FileSystemResource("users.csv"))
        .delimited()
        .names("name", "email")
        .targetType(User.class)
        .build();
  }

  @Bean
  public ItemProcessor<User, User> processor() {
    return user -> {
      user.setEmail(user.getEmail().toLowerCase());
      return user;
    };
  }
}

Job — tout le processus batch.
Step — une phase ; ici une étape par blocs qui lit, transforme et écrit.
Reader / Processor / Writer — le pipeline de blocs.
chunk(100) — traite 100 éléments par transaction, pour qu'un échec annule un bloc, pas tout le job.

Spring Batch enregistre l'état du job et des étapes dans un stockage de métadonnées, pour que les jobs puissent reprendre là où ils ont échoué.

Historique des versions Java

Une chronologie condensée des versions majeures et de leurs changements clés.

Version	Sortie	Changements majeurs / breaking changes
8	Mars 2014	Lambdas, Streams, `Optional`, `java.time` ; PermGen supprimé (Metaspace)
9	Sept 2017	Système de modules (JPMS/Jigsaw), JShell, `List.of`/`Map.of`
10	Mars 2018	Inférence de type `var` pour les variables locales
11	Sept 2018	LTS ; `HttpClient`, `var` dans les lambdas ; modules Java EE & CORBA supprimés
12	Mars 2019	Expressions switch (aperçu), Shenandoah GC
13	Sept 2019	Blocs de texte (aperçu), ZGC
14	Mars 2020	Expressions switch standard ; records & pattern matching (aperçu)
15	Sept 2020	Blocs de texte standard ; classes scellées (aperçu)
16	Mars 2021	Records standard ; pattern matching pour `instanceof` standard
17	Sept 2021	LTS ; classes scellées standard ; forte encapsulation des internes du JDK
18	Mars 2022	Jeu de caractères UTF-8 par défaut ; serveur web simple
19	Sept 2022	Threads virtuels (aperçu) ; record patterns (aperçu)
20	Mars 2023	Record patterns standard ; threads virtuels (2e aperçu)
21	Sept 2023	LTS ; threads virtuels standard, pattern matching pour switch, collections séquencées
22	Mars 2024	Variables & motifs sans nom ; instructions avant `super()`
23	Sept 2024	Déclarations d'import de module (aperçu) ; motifs primitifs (aperçu)
24	Mars 2025	En-têtes d'objets compacts, API class-file, stream gatherers
25	Sept 2025	LTS ; concurrence structurée & scoped values stables

Pour conclure

Le Java moderne s'appuie sur les records, le pattern matching, les types scellés et les threads virtuels pour réduire le boilerplate et passer à l'échelle. L'écosystème Spring empile l'auto-configuration de Boot, la chaîne de filtres de Security, les repositories de JPA, les bindings de Cloud Stream, les profils et une gateway. Ensemble, ils donnent un backend de production concis, typé et facile à raisonner.

Orchestrer des workflows de longue durée avec les sagas MassTransit

Wed, 02 Sep 2026 00:00:00 GMT

Le problème d'une transaction unique

Un checkout se termine rarement en une seule requête. L'argent doit être encaissé, le stock doit être réservé et l'entrepôt doit être prévenu pour l'expédition. Tout envelopper dans une transaction distribuée — un commit en deux phases entre services — semble propre sur le papier, mais s'effondre vite dans la réalité.

Le hic, c'est qu'aucun service ne peut prédire combien de temps un autre mettra. Un prestataire de paiement peut attendre une vérification anti-fraude, et un contrôle de stock peut être lent sous la charge. Garder des verrous ouverts sur plusieurs systèmes pendant aussi longtemps est irréaliste et peut alourdir toute la plateforme.

Un saga contourne cela en découpant le flux en étapes locales qui se terminent rapidement et peuvent être annulées séparément.

Ce qu'est réellement un saga

Un saga est une chaîne d'actions locales où chaque étape possède une action compensatoire qui l'inverse lorsqu'une étape ultérieure échoue. Au lieu d'une opération atomique, le travail est découpé en petits morceaux récupérables indépendamment.

Prenons une commande comme exemple :

sequenceDiagram
    participant Client
    participant Saga
    participant Payments
    participant Inventory
    Client->>Saga: OrderSubmitted
    Saga->>Payments: ChargePayment
    Payments-->>Saga: PaymentSettled
    Saga->>Inventory: AllocateInventory
    Inventory-->>Saga: InventoryAllocated
    Saga->>Client: FinalizeOrder

Si l'étape de stock signale qu'un article est épuisé après que le paiement est déjà passé, le saga déclenche un remboursement pour rendre l'argent. Chaque pièce est découplée et rien ne reste verrouillé pendant tout le parcours.

Les sagas MassTransit sont des machines à états

MassTransit implémente les sagas à travers une machine à états, une approche héritée d'Automatonymous. Avant d'écrire du code, il est utile de connaître les quatre éléments du modèle :

États — les positions que peut occuper un workflow
Événements — les messages qui font passer le workflow d'un état à un autre
Comportements — le travail effectué lorsqu'un événement arrive dans un état donné
Instance — l'enregistrement persisté contenant les données d'une seule conversation

Chaque machine à états inclut gratuitement un état Initial et un état Final. Une nouvelle instance démarre dans Initial, et atteindre Final signifie que le saga est terminé.

Voici la machine à états que nous allons construire :

stateDiagram-v2
    [*] --> ProcessingPayment: OrderSubmitted
    ProcessingPayment --> ReservingInventory: PaymentSettled
    ProcessingPayment --> Failed: OrderDeclined
    ReservingInventory --> Completed: InventoryAllocated
    ReservingInventory --> Failed: OrderDeclined
    Completed --> [*]
    Failed --> [*]

L'instance du saga

L'instance est l'entité que MassTransit persiste entre les messages. Elle conserve la clé de corrélation, l'état courant et les données métier dont les étapes ont besoin.

public class OrderState : SagaStateMachineInstance
{
    public Guid CorrelationId { get; set; }
    public string CurrentState { get; set; } = string.Empty;

    public decimal Total { get; set; }
    public string? PaymentReference { get; set; }
    public DateTime? PlacedAt { get; set; }
    public string? BuyerEmail { get; set; }
}

CorrelationId est l'identifiant qui relie chaque message entrant à la bonne instance, tandis que CurrentState enregistre où en est le workflow. Les propriétés restantes transportent les données nécessaires au processus.

Les événements

Les événements sont les messages qui déclenchent les transitions. Chacun doit être corrélé à une instance précise via un identifiant partagé.

public record OrderSubmitted(Guid OrderId, decimal Total, string Email);

public record PaymentSettled(Guid OrderId, string PaymentReference);

public record InventoryAllocated(Guid OrderId);

public record OrderDeclined(Guid OrderId, string Reason);

Ces records circulent sur le bus ; le saga y réagit et peut publier de nouvelles commandes en réponse.

Construire la machine à états

La machine à états relie les états, les événements et les comportements, et déclare quelles transitions sont autorisées.

public class OrderStateMachine : MassTransitStateMachine<OrderState>
{
    public OrderStateMachine()
    {
        InstanceState(x => x.CurrentState);

        Event(() => OrderSubmitted, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => PaymentSettled, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => InventoryAllocated, x => x.CorrelateById(c => c.Message.OrderId));
        Event(() => OrderDeclined, x => x.CorrelateById(c => c.Message.OrderId));

        Initially(
            When(OrderSubmitted)
                .Then(c =>
                {
                    c.Saga.Total = c.Message.Total;
                    c.Saga.BuyerEmail = c.Message.Email;
                    c.Saga.PlacedAt = DateTime.UtcNow;
                })
                .PublishAsync(c => c.Init<ChargePayment>(new
                {
                    OrderId = c.Saga.CorrelationId,
                    Amount = c.Saga.Total
                }))
                .TransitionTo(ProcessingPayment)
        );

        During(ProcessingPayment,
            When(PaymentSettled)
                .Then(c => c.Saga.PaymentReference = c.Message.PaymentReference)
                .PublishAsync(c => c.Init<AllocateInventory>(new
                {
                    OrderId = c.Saga.CorrelationId
                }))
                .TransitionTo(ReservingInventory),
            When(OrderDeclined)
                .TransitionTo(Failed)
                .Finalize()
        );

        During(ReservingInventory,
            When(InventoryAllocated)
                .PublishAsync(c => c.Init<FinalizeOrder>(new
                {
                    OrderId = c.Saga.CorrelationId
                }))
                .TransitionTo(Completed)
                .Finalize(),
            When(OrderDeclined)
                .PublishAsync(c => c.Init<ReimbursePayment>(new
                {
                    OrderId = c.Saga.CorrelationId,
                    Amount = c.Saga.Total
                }))
                .TransitionTo(Failed)
                .Finalize()
        );

        SetCompletedWhenFinalized();
    }

    public State ProcessingPayment { get; private set; } = null!;
    public State ReservingInventory { get; private set; } = null!;
    public State Completed { get; private set; } = null!;
    public State Failed { get; private set; } = null!;

    public Event<OrderSubmitted> OrderSubmitted { get; private set; } = null!;
    public Event<PaymentSettled> PaymentSettled { get; private set; } = null!;
    public Event<InventoryAllocated> InventoryAllocated { get; private set; } = null!;
    public Event<OrderDeclined> OrderDeclined { get; private set; } = null!;
}

Remarquez la logique de compensation : lorsque l'étape de stock échoue après le paiement, le saga publie ReimbursePayment pour annuler le débit. Le chemin nominal et le chemin d'échec sont déclarés côte à côte, ce qui rend le workflow facile à lire.

Les consumers

Le saga est le coordinateur, pas l'exécutant. Le vrai travail se trouve dans les consumers qui traitent les commandes et rendent compte via des événements.

public class ChargePaymentConsumer(
    IPaymentGateway gateway,
    ILogger<ChargePaymentConsumer> logger) : IConsumer<ChargePayment>
{
    public async Task Consume(ConsumeContext<ChargePayment> context)
    {
        try
        {
            var result = await gateway.ChargeAsync(
                context.Message.OrderId,
                context.Message.Amount);

            if (result.Succeeded)
            {
                await context.Publish<PaymentSettled>(new
                {
                    OrderId = context.Message.OrderId,
                    PaymentReference = result.Reference
                });
            }
            else
            {
                await context.Publish<OrderDeclined>(new
                {
                    OrderId = context.Message.OrderId,
                    Reason = result.RejectionReason
                });
            }
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Payment failed for order {OrderId}", context.Message.OrderId);

            await context.Publish<OrderDeclined>(new
            {
                OrderId = context.Message.OrderId,
                Reason = "Payment gateway error"
            });
        }
    }
}

Séparer les responsabilités de cette façon permet à chaque service de se concentrer sur son propre rôle, pendant que le saga fait avancer tout le processus dans la bonne direction.

Configuration avec Azure Service Bus

Persister l'état du saga nécessite un dépôt. Nous utiliserons Entity Framework Core sur SQL Server, avec Azure Service Bus comme transport.

D'abord, les paquets requis :

Install-Package MassTransit.EntityFrameworkCore
Install-Package MassTransit.Azure.ServiceBus.Core
Install-Package Microsoft.EntityFrameworkCore.SqlServer

Définissez un DbContext et une carte de classe pour l'instance du saga :

public class OrderSagaDbContext : SagaDbContext
{
    public OrderSagaDbContext(DbContextOptions options) : base(options) { }

    protected override IEnumerable<ISagaClassMap> Configurations
    {
        get { yield return new OrderStateMap(); }
    }
}

public class OrderStateMap : SagaClassMap<OrderState>
{
    protected override void Configure(EntityTypeBuilder<OrderState> entity, ModelBuilder model)
    {
        entity.Property(x => x.CurrentState).HasMaxLength(64);
        entity.Property(x => x.BuyerEmail).HasMaxLength(256);
        entity.Property(x => x.PaymentReference).HasMaxLength(64);
    }
}

Enfin, enregistrez le tout dans l'application :

builder.Services.AddDbContext<OrderSagaDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("SqlServer")));

builder.Services.AddMassTransit(x =>
{
    x.AddSagaStateMachine<OrderStateMachine, OrderState>()
        .EntityFrameworkRepository(r =>
        {
            r.ConcurrencyMode = ConcurrencyMode.Pessimistic;
            r.AddDbContext<DbContext, OrderSagaDbContext>();
        });

    x.UsingAzureServiceBus((context, cfg) =>
    {
        cfg.Host(builder.Configuration.GetConnectionString("ServiceBus"));
        cfg.ConfigureEndpoints(context);
    });
});

Pourquoi choisir les sagas

Résilience — chaque étape peut être réessayée séparément, et les échecs déclenchent une compensation au lieu de laisser le système à moitié fait.
Visibilité — l'état courant indique exactement où en est chaque commande, ce qui simplifie le débogage et la supervision.
Couplage lâche — les services communiquent par messages et peuvent évoluer séparément sans casser le flux global.
Maintenabilité — une modification sur une étape ne se répercute pas sur les autres.

La machine à états force aussi le processus métier à être explicite. Chaque état et transition est énoncé clairement, transformant un flux distribué opaque en quelque chose qu'un nouveau membre de l'équipe peut suivre.

Conclusion

Modéliser un checkout comme un saga MassTransit donne des workflows coordonnés et récupérables sans la douleur des transactions distribuées. Définissez les états et les événements, persistez l'instance et laissez Azure Service Bus transporter les messages. Le résultat est un processus clair, observable et indulgent quand les choses tournent mal.

Python pour la finance : NumPy, pandas et les outils de l'analyse quantitative

Wed, 02 Sep 2026 00:00:00 GMT

Python est le langage de référence de la finance moderne, car son écosystème couvre tout, du nettoyage de données à la simulation de Monte-Carlo. Ce guide parcourt les bibliothèques clés avec des exemples concrets.

flowchart TD
    P[Python] --> N[NumPy]
    P --> PD[pandas]
    P --> M[matplotlib]
    Y[yfinance] --> PD
    PD --> R[Returns & indicators]
    N --> R
    R --> V[Visualization]
    R --> PF[Portfolio metrics]

NumPy : le calcul financier vectorisé

NumPy fournit des tableaux rapides et vectorisés — le socle de tout calcul financier.

import numpy as np

prices = np.array([100, 102, 101, 105, 107])

# simple returns
returns = np.diff(prices) / prices[:-1]
print(returns)  # [ 0.02   -0.0098  0.0396  0.0190]

# log returns
log_returns = np.log(prices[1:] / prices[:-1])

# annualized volatility
volatility = returns.std() * np.sqrt(252)

Tout est élément par élément, ce qui évite les boucles Python et garde le calcul rapide.

pandas : DataFrames et séries temporelles

pandas enveloppe les données dans un DataFrame avec de puissantes opérations temporelles.

import pandas as pd

df = pd.DataFrame({
    'date': pd.date_range('2026-01-01', periods=5, freq='D'),
    'close': [100, 102, 101, 105, 107],
})

df['returns'] = df['close'].pct_change()
df['cum_return'] = (1 + df['returns']).cumprod() - 1

Rééchantillonnez, faites des fenêtres glissantes et des décalages avec des méthodes intégrées :

df['sma_3'] = df['close'].rolling(3).mean()
df['prev_close'] = df['close'].shift(1)

Récupérer des données de marché avec yfinance

yfinance télécharge les historiques de prix directement depuis Yahoo Finance.

import yfinance as yf

ticker = yf.Ticker('AAPL')
history = ticker.history(period='1y', interval='1d')

prices = history['Close']
returns = prices.pct_change().dropna()

Vous pouvez aussi charger plusieurs tickers à la fois avec yf.download.

Rendements et métriques de portefeuille

À partir des rendements, calculez les métriques de risque essentielles.

def sharpe_ratio(returns, risk_free_rate=0.0):
    excess = returns - risk_free_rate / 252
    return excess.mean() / returns.std() * np.sqrt(252)

sharpe = sharpe_ratio(returns)
vol = returns.std() * np.sqrt(252)
ann_return = (1 + returns.mean()) ** 252 - 1

print(f"Return: {ann_return:.2%}, Vol: {vol:.2%}, Sharpe: {sharpe:.2f}")

Corrélation entre deux actifs :

a = yf.Ticker('AAPL').history(period='1y')['Close'].pct_change()
b = yf.Ticker('MSFT').history(period='1y')['Close'].pct_change()

corr = a.corr(b)

Indicateurs techniques

Les moyennes mobiles sont quelques appels pandas.

df['sma_20'] = df['close'].rolling(20).mean()
df['ema_20'] = df['close'].ewm(span=20, adjust=False).mean()
df['signal'] = np.where(df['sma_20'] > df['ema_20'], 1, 0)

rolling donne une fenêtre simple ; ewm une exponentielle. Le croisement d'une moyenne courte au-dessus d'une longue est un signal classique.

Visualisation avec matplotlib

Tracez les prix et les indicateurs pour vérifier les données.

import matplotlib.pyplot as plt

plt.figure(figsize=(10, 5))
plt.plot(df['date'], df['close'], label='Close')
plt.plot(df['date'], df['sma_20'], label='SMA 20')
plt.plot(df['date'], df['ema_20'], label='EMA 20')
plt.legend()
plt.show()

Simulation de Monte-Carlo

Simulez de nombreux chemins de prix futurs en échantillonnant des chocs aléatoires.

def monte_carlo(initial_price, mu, sigma, days=252, simulations=1000):
    dt = 1 / 252
    paths = np.zeros((days, simulations))
    paths[0] = initial_price
    for t in range(1, days):
        shocks = np.random.normal(mu * dt, sigma * np.sqrt(dt), simulations)
        paths[t] = paths[t - 1] * (1 + shocks)
    return paths

paths = monte_carlo(100, mu=0.07, sigma=0.20)

final_prices = paths[-1]
value_at_risk = np.percentile(final_prices, 5)

Cela sous-tend des mesures de risque comme la value-at-risk et le pricing d'options.

Pour conclure

NumPy fait le calcul, pandas façonne les données, yfinance les alimente et matplotlib les montre. Maîtrisez ces quatre-là et vous pourrez calculer des rendements, des indicateurs et des simulations de Monte-Carlo — l'épine dorsale de la finance quantitative en Python.

Bases de données relationnelles pour les experts : ACID, clés, triggers et index

Wed, 02 Sep 2026 00:00:00 GMT

Les bases de données relationnelles font tourner la plupart des applications pour une bonne raison : elles offrent de solides garanties et un modèle clair. Ce guide parcourt les concepts sur lesquels tout DBA expert s'appuie, avec des exemples SQL et des diagrammes.

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered as"

ACID

ACID décrit les quatre garanties qu'offre une transaction.

flowchart LR
    T[Transaction] --> A[Atomicity]
    T --> C[Consistency]
    T --> I[Isolation]
    T --> D[Durability]

Atomicité — toutes les instructions réussissent ou aucune.
Cohérence — la base passe d'un état valide à un autre état valide.
Isolation — les transactions concurrentes n'interfèrent pas.
Durabilité — les données validées survivent à un crash.

stateDiagram-v2
    [*] --> Active
    Active --> Committed: COMMIT
    Active --> Aborted: ROLLBACK
    Committed --> [*]
    Aborted --> [*]

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

Clés primaires

Une clé primaire identifie chaque ligne de façon unique. Elle est toujours NOT NULL et unique. Préférez une clé de substitution (identité, UUID) à une clé naturelle qui peut changer.

CREATE TABLE customer (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE
);

Les clés composites identifient une ligne par plusieurs colonnes ensemble — le cas classique d'une table de jointure.

CREATE TABLE order_line (
  order_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  PRIMARY KEY (order_id, product_id)
);

Clés étrangères

Une clé étrangère garantit l'intégrité référentielle : chaque valeur doit exister dans la table référencée. ON DELETE / ON UPDATE indiquent au moteur quoi faire quand le parent change.

CREATE TABLE "order" (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL
    REFERENCES customer(id) ON DELETE CASCADE
);

CASCADE supprime l'enfant quand le parent disparaît ; SET NULL efface la colonne ; RESTRICT bloque le changement.

Commandes SQL : DDL, DQL, DML, DCL, TCL

SQL se divise en cinq familles de commandes.

DDL — Langage de définition des données

Définit et modifie le schéma.

CREATE TABLE product (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  price NUMERIC(10, 2) NOT NULL
);

ALTER TABLE product ADD COLUMN active BOOLEAN DEFAULT true;

DROP TABLE product;

DQL — Langage de requête des données

Lit les données. C'est simplement SELECT.

SELECT id, name, price
FROM product
WHERE active
ORDER BY price DESC;

DML — Langage de manipulation des données

Modifie les données : INSERT, UPDATE, DELETE.

INSERT INTO product (name, price) VALUES ('Keyboard', 89.90);

UPDATE product SET price = 79.90 WHERE name = 'Keyboard';

DELETE FROM product WHERE id = 1;

UPDATE et DELETE doivent porter une clause WHERE — sans elle, ils touchent chaque ligne.

DCL — Langage de contrôle des données

Gère les permissions avec GRANT et REVOKE.

GRANT SELECT, INSERT, UPDATE ON product TO app_user;
REVOKE DELETE ON product FROM app_user;

TCL — Langage de contrôle des transactions

Contrôle les transactions avec COMMIT, ROLLBACK et SAVEPOINT.

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SAVEPOINT before_credit;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

ROLLBACK TO before_credit;
COMMIT;

Jointures

Les jointures combinent des lignes de deux tables ou plus via une condition de jointure.

-- INNER JOIN: only matching rows
SELECT c.name, o.id AS order_id, o.total
FROM customer c
JOIN "order" o ON o.customer_id = c.id;

-- LEFT JOIN: all customers, even without orders (NULL on the right)
SELECT c.name, o.id AS order_id
FROM customer c
LEFT JOIN "order" o ON o.customer_id = c.id;

-- RIGHT JOIN: all orders, even without a customer (NULL on the left)
SELECT c.name, o.id AS order_id
FROM customer c
RIGHT JOIN "order" o ON o.customer_id = c.id;

-- FULL OUTER JOIN: both sides, NULL where missing
SELECT c.name, o.id AS order_id
FROM customer c
FULL OUTER JOIN "order" o ON o.customer_id = c.id;

-- CROSS JOIN: every combination of rows
SELECT c.name, p.name
FROM customer c
CROSS JOIN product p;

-- self join: employees and their managers
SELECT e.name AS employee, m.name AS manager
FROM employee e
LEFT JOIN employee m ON m.id = e.manager_id;

Les jointures se combinent naturellement avec l'agrégation :

-- order totals from line items
SELECT o.id, SUM(ol.quantity * p.price) AS total
FROM "order" o
JOIN order_line ol ON ol.order_id = o.id
JOIN product p ON p.id = ol.product_id
GROUP BY o.id;

Utilisez des alias de table (c, o) pour la lisibilité, et gardez la condition de jointure dans ON plutôt que WHERE pour que l'intention reste claire.

Index

Un index accélère les recherches au prix de performances d'écriture et de stockage. La plupart des bases utilisent un B-tree, qui garde les données triées pour des recherches rapides par égalité et par plage.

flowchart TD
    R[Root] --> N1[Node 10 - 20]
    R --> N2[Node 20 - 30]
    N1 --> L1[Leaf 10]
    N1 --> L2[Leaf 15]
    N2 --> L3[Leaf 20]
    N2 --> L4[Leaf 25]

Index unique — impose l'unicité comme une contrainte unique.
Index composite — couvre plusieurs colonnes, de gauche à droite.
Index couvrant — stocke des colonnes supplémentaires pour ne jamais toucher la table.
Index partiel — n'indexe que les lignes qui satisfont une condition.

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

CREATE INDEX idx_order_customer ON "order"(customer_id);

CREATE INDEX idx_order_line_product
  ON order_line(product_id) INCLUDE (quantity);

Une règle simple : indexez les colonnes que vous filtrez (WHERE), joignez (JOIN) et triez (ORDER BY).

Déclencheurs (triggers)

Un trigger s'exécute automatiquement avant ou après INSERT, UPDATE ou DELETE. Ils sont parfaits pour les journaux d'audit et les colonnes dérivées. En PostgreSQL, la logique vit dans une fonction de trigger.

CREATE FUNCTION audit_order() RETURNS trigger AS $$
BEGIN
  INSERT INTO audit_log (table_name, row_id, action, changed_at)
  VALUES ('order', COALESCE(NEW.id, OLD.id), TG_OP, now());
  RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_audit
AFTER INSERT OR UPDATE OR DELETE ON "order"
FOR EACH ROW EXECUTE FUNCTION audit_order();

Fonctions

Les fonctions sont des morceaux de logique réutilisables et composables qui renvoient une valeur.

Une fonction scalaire :

CREATE FUNCTION order_total(order_id BIGINT) RETURNS NUMERIC AS $$
  SELECT COALESCE(SUM(price * quantity), 0)
  FROM order_line
  JOIN product ON product.id = order_line.product_id
  WHERE order_line.order_id = order_total.order_id;
$$ LANGUAGE sql;

Une fonction table (renvoie un ensemble de lignes) :

CREATE FUNCTION customer_orders(customer_id BIGINT)
RETURNS TABLE(order_id BIGINT, total NUMERIC, placed_at TIMESTAMPTZ) AS $$
  SELECT id, total, placed_at
  FROM "order"
  WHERE customer_id = customer_orders.customer_id;
$$ LANGUAGE sql;

Procédures stockées

Les procédures ressemblent aux fonctions mais peuvent gérer leurs propres transactions et n'ont pas à renvoyer de valeur. Utilisez-les pour des opérations transactionnelles en plusieurs étapes.

CREATE PROCEDURE transfer(from_acc BIGINT, to_acc BIGINT, amount NUMERIC)
LANGUAGE plpgsql
AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_acc;
  UPDATE accounts SET balance = balance + amount WHERE id = to_acc;
  COMMIT;
END;
$$;

Niveaux d'isolation

L'isolation contrôle ce que les transactions concurrentes voient les unes des autres.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

Read uncommitted — peut lire des données non validées (lectures sales).
Read committed — chaque instruction voit un instantané stable.
Repeatable read — toute la transaction voit un seul instantané.
Serializable — les transactions se comportent comme si elles s'exécutaient une à une.

Bonnes pratiques

Utilisez des procédures stockées pour le CRUD — centralisez la logique de données en un seul endroit et accordez l'accès à la procédure plutôt qu'à la table.
Utilisez des requêtes paramétrées — ne concaténez jamais l'entrée utilisateur dans le SQL ; liez les valeurs en paramètres pour prévenir l'injection SQL.
Gérez les permissions — laissez les utilisateurs exécuter les procédures CRUD sans accès direct aux tables.

-- parameterized query: the value is bound as data, not SQL
SELECT id, name FROM customer WHERE email = $1;

-- grant execution through a procedure, not the table
GRANT EXECUTE ON PROCEDURE create_customer TO app_user;
REVOKE ALL ON customer FROM app_user;

Les instructions paramétrées séparent le SQL des valeurs, de sorte que l'entrée est traitée comme des données. Combinées aux permissions au niveau des procédures, la surface reste petite et auditable.

Pour conclure

ACID vous donne la correction ; les clés donnent l'intégrité ; les index donnent la vitesse ; les triggers, fonctions et procédures donnent une logique réutilisable et imposée. Maîtriser tout cela — et en connaître les compromis — c'est ce qui distingue un DBA d'un développeur qui écrit du SQL par hasard.

Tailwind CSS pour les experts : bonnes pratiques et outils pour une belle UI

Wed, 02 Sep 2026 00:00:00 GMT

Tailwind CSS v4 est passé à une configuration en CSS et à un moteur plus rapide. Ce guide couvre les motifs et les outils qui gardent une base Tailwind propre, scalable et agréable à regarder.

Tailwind CSS v4

La version 4 se configure entièrement en CSS. Pas de tailwind.config.js : vous l'importez et déclarez vos jetons de design.

@import "tailwindcss";

@theme {
  --color-primary: #6366f1;
  --font-sans: 'Inter', ui-sans-serif, system-ui, sans-serif;
  --radius-lg: 0.75rem;
}

Les utilitaires et variantes personnalisés se déclarent dans le même fichier.

@utility container {
  margin-inline: auto;
  padding-inline: 1rem;
}

@custom-variant dark (&:where(.dark, .dark *));

Jetons de design

Définissez les jetons une fois et référencez-les partout, pour que les couleurs et les espacements restent cohérents. Les valeurs arbitraires comme bg-[#6366f1] sont pour les cas uniques, pas pour un design system.

@theme {
  --color-primary-500: #6366f1;
  --color-primary-600: #4f46e5;
  --spacing-18: 4.5rem;
}

Alors bg-primary-500, p-18 et text-primary-600 fonctionnent.

Bonnes pratiques utility-first

Composez de petits utilitaires plutôt que d'écrire du CSS sur mesure, mais extrayez un motif dès qu'il se répète.

<button class="inline-flex items-center gap-2 rounded-lg bg-primary-600 px-4 py-2 text-sm font-medium text-white hover:bg-primary-500">
  Save
</button>

Règles pour rester maintenable :

Réutilisez les jetons, pas les valeurs brutes.
Triez les classes automatiquement (voir le plugin Prettier ci-dessous).
Préférez gap/space-* aux marges manuelles.
Gardez les variantes responsive et d'état proches des classes de base.

Composants réutilisables

Quand un motif se répète, extrayez-le. Tailwind offre trois niveaux.

Classes composants avec @apply :

.btn {
  @apply inline-flex items-center gap-2 rounded-lg px-4 py-2 text-sm font-medium;
}
.btn-primary {
  @apply bg-primary-600 text-white hover:bg-primary-500;
}

Variantes de classes avec class-variance-authority (idéal pour React/Solid) :

import { cva, type VariantProps } from 'class-variance-authority'

const button = cva('inline-flex items-center rounded-lg font-medium', {
  variants: {
    variant: {
      primary: 'bg-primary-600 text-white hover:bg-primary-500',
      ghost: 'border border-gray-300 text-gray-700',
    },
    size: {
      sm: 'px-3 py-1.5 text-sm',
      md: 'px-4 py-2 text-base',
    },
  },
  defaultVariants: { variant: 'primary', size: 'md' },
})

Fusion de classes avec clsx + tailwind-merge :

import { clsx, type ClassValue } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

// later conflicting class wins
cn('px-4', 'px-2') // 'px-2'

L'écosystème de composants

Vous n'avez pas à construire chaque primitive de zéro.

shadcn/ui — des composants à copier-coller, basés sur Radix, que vous possédez et modifiez.
Radix UI / Headless UI — des primitives accessibles et sans style.
daisyUI — des classes de composants prêtes à l'emploi et thématisables.

Associez-les à Tailwind pour un contrôle total sans le fardeau de l'accessibilité.

Outillage

@tailwindcss/vite — le plugin Vite (ajoutez-le une fois, oubliez-le).
prettier-plugin-tailwindcss — trie les classes utilitaires pour un ordre cohérent.
clsx + tailwind-merge — composez et dédupliquez les classes.
class-variance-authority — des variantes de composants typées.

npm install -D tailwindcss @tailwindcss/vite prettier-plugin-tailwindcss
npm install clsx tailwind-merge class-variance-authority

Rendre l'UI magnifique

Une belle UI est surtout de la cohérence, pas de la décoration.

Typographie — une seule échelle de polices, une hauteur de ligne confortable, une mesure contrainte.
Espacement — restez sur l'échelle de 4px ; alignez sur une grille.
Couleur — une petite palette avec un accent unique ; vérifiez le contraste.
Mouvement — des transitions courtes et subtiles (transition, duration-150).
Mode sombre — concevez les deux, piloté par la variante dark.

Exemples prêts pour la production

Une configuration complète, prête à copier : des jetons de design, un utilitaire cn et des composants typés.

Jetons de thème (theme.css) :

@import "tailwindcss";

@theme {
  --color-brand-50: #eef2ff;
  --color-brand-500: #6366f1;
  --color-brand-600: #4f46e5;
  --color-brand-700: #4338ca;

  --color-surface: #ffffff;
  --color-ink: #0f172a;
  --color-muted: #64748b;

  --font-sans: 'Inter', ui-sans-serif, system-ui, sans-serif;
  --shadow-card: 0 1px 2px rgb(15 23 42 / 0.06), 0 4px 12px rgb(15 23 42 / 0.08);
}

@custom-variant dark (&:where(.dark, .dark *));

Bouton (button.tsx) avec variantes typées :

import { cva, type VariantProps } from 'class-variance-authority'
import { cn } from './cn'

const buttonVariants = cva(
  'inline-flex items-center justify-center gap-2 rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-brand-500 disabled:pointer-events-none disabled:opacity-50',
  {
    variants: {
      variant: {
        primary: 'bg-brand-600 text-white hover:bg-brand-500',
        secondary: 'border border-slate-200 bg-surface text-ink hover:bg-slate-50',
        ghost: 'text-ink hover:bg-slate-100',
        destructive: 'bg-red-600 text-white hover:bg-red-500',
      },
      size: {
        sm: 'h-8 px-3 text-xs',
        md: 'h-10 px-4',
        lg: 'h-12 px-6 text-base',
      },
    },
    defaultVariants: { variant: 'primary', size: 'md' },
  },
)

export interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

export function Button({ className, variant, size, ...props }: ButtonProps) {
  return (
    <button
      className={cn(buttonVariants({ variant, size }), className)}
      {...props}
    />
  )
}

Carte et champ (card.tsx, input.tsx) :

export function Card({ className, ...props }: React.HTMLAttributes<HTMLDivElement>) {
  return (
    <div
      className={cn(
        'rounded-md border border-slate-200 bg-surface p-6 shadow-card',
        className,
      )}
      {...props}
    />
  )
}

export function Input({ className, ...props }: React.InputHTMLAttributes<HTMLInputElement>) {
  return (
    <input
      className={cn(
        'h-10 w-full rounded-md border border-slate-200 bg-surface px-3 text-sm text-ink placeholder:text-muted focus:outline-none focus:ring-2 focus:ring-brand-500',
        className,
      )}
      {...props}
    />
  )
}

Ces jetons et composants forment la base d'un vrai design system : des couleurs cohérentes, des variantes typées et une source unique de vérité.

Pour conclure

La configuration CSS-first de Tailwind v4, les jetons de design et l'extraction de composants (avec cva et cn) vous donnent un système qui passe à l'échelle. Ajoutez shadcn/Radix pour les primitives et le plugin Prettier pour l'ordre, et vous obtenez une UI belle et maintenable.

TypeScript et JavaScript pour les experts : fonctionnalités modernes et architecture

Wed, 02 Sep 2026 00:00:00 GMT

JavaScript gagne sans cesse de petites fonctionnalités précises, et TypeScript transforme sans cesse les erreurs d'exécution en erreurs de compilation. Ce guide couvre ce qui compte pour du code front-end de production aujourd'hui, avec des exemples.

flowchart TD
    JS[JavaScript] --> A[Modern built-ins]
    A --> A1[toSorted / at / groupBy]
    A --> A2[Promise.withResolvers]
    TS[TypeScript] --> B[The type system]
    B --> B1[Discriminated unions]
    B --> B2[Utility types]
    TS --> C[Architecture]
    C --> C1[Result types]
    C --> C2[Exhaustive checks]

JavaScript : les essentiels modernes

Chaînage optionnel et coalescence des nuls

Lire des données imbriquées sans exploser, et ne retomber que sur null/undefined.

const city = user?.address?.city
const label = name ?? 'Anonymous'
const retries = config?.retries ?? 3

Affectation logique

Ne modifier une variable que lorsqu'elle est fausse, nulle ou vraie.

user.nickname ||= user.firstName
settings.theme ??= 'dark'

Méthodes de tableau non mutantes

toSorted, toReversed, toSpliced et with renvoient de nouveaux tableaux au lieu de muter, ce qui se marie parfaitement avec l'état immuable.

const sorted = items.toSorted((a, b) => a.score - b.score)
const reversed = items.toReversed()
const first = items.at(0)
const last = items.at(-1)

Groupement et clonage

Object.groupBy répartit une collection en une ligne, et structuredClone fait une copie profonde sans bidouillage JSON.

const byStatus = Object.groupBy(orders, (o) => o.status)

const copy = structuredClone(original)

Aides pour les promesses

Promise.withResolvers vous donne les fonctions resolve/reject sans envelopper une promesse dans un constructeur.

const { promise, resolve, reject } = Promise.withResolvers<string>()

async function nextMessage(): Promise<string> {
  return promise
}

Array.fromAsync transforme un itérable asynchrone en tableau.

const lines = await Array.fromAsync(stream)

Promesses et Observables

Promesses

Une promesse représente une valeur qui sera disponible plus tard. async/await aplatit les callbacks.

function fetchUser(id: number): Promise<User> {
  return fetch(`/api/users/${id}`).then((res) => res.json())
}

async function loadUser(id: number): Promise<User | null> {
  try {
    return await fetchUser(id)
  } catch (error) {
    console.error('failed to load user', error)
    return null
  }
}

Exécutez des travaux indépendants en parallèle et récupérez les résultats :

const [a, b, c] = await Promise.all([
  fetchUser(1),
  fetchUser(2),
  fetchUser(3),
])

Observables

Les Observables (RxJS) modélisent un flux de valeurs dans le temps. Construisez des pipelines d'opérateurs et désabonnez-vous toujours.

import { from, fromEvent } from 'rxjs'
import { debounceTime, filter, map, switchMap } from 'rxjs/operators'

const search$ = fromEvent<InputEvent>(input, 'input').pipe(
  debounceTime(300),
  map((event) => (event.target as HTMLInputElement).value),
  filter((term) => term.length >= 3),
  switchMap((term) =>
    from(fetch(`/api/search?q=${term}`).then((res) => res.json())),
  ),
)

const subscription = search$.subscribe({
  next: (results) => console.log(results),
  error: (err) => console.error(err),
})

subscription.unsubscribe()

Une promesse produit une valeur ; un observable en produit plusieurs dans le temps. Utilisez les promesses pour des résultats uniques, les observables pour des événements et des flux.

TypeScript : le système de types qui compte

`unknown` bat `any`

any désactive le vérificateur de types ; unknown vous oblige à rétrécir d'abord.

function parse(value: unknown): string {
  if (typeof value === 'string') return value
  throw new Error('not a string')
}

`satisfies` et `as const`

satisfies vérifie un objet contre un type sans l'élargir, et as const fige les valeurs sur leurs types littéraux.

const palette = {
  primary: '#c770f0',
  danger: '#ef4444',
} satisfies Record<string, string>

const routes = ['/', '/about', '/blog'] as const
type Route = (typeof routes)[number]

Unions discriminées

Modélisez chaque état avec un champ kind partagé, et le compilateur rétrécit pour vous — le socle des reducers et machines à états typés.

type State =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'success'; data: User[] }
  | { kind: 'error'; message: string }

function render(state: State): string {
  switch (state.kind) {
    case 'idle': return 'Waiting…'
    case 'loading': return 'Loading…'
    case 'success': return state.data.map((u) => u.name).join(', ')
    case 'error': return state.message
  }
}

Prédicats de type

Rétrécissez unknown vers une forme concrète en toute sécurité.

function isUser(value: unknown): value is User {
  return typeof value === 'object' && value !== null && 'id' in value
}

Types template littéraux

Construisez des types de chaînes à partir d'unions — idéal pour les routes et chemins d'API typés.

type Route = `/api/${'users' | 'orders'}/${string}`

Paramètres de type `const`

Gardez les littéraux de tuples précis sans saupoudrer as const partout.

function preserve<const T>(items: T[]): T[] {
  return items
}

const pair = preserve([1, 'two']) // [number, string]

Types utilitaires

Composez de nouveaux types à partir d'existants au lieu de les écrire à la main.

type UserInput = Omit<User, 'id' | 'createdAt'>
type PartialUser = Partial<User>
type ReadonlyUser = Readonly<User>

Fonctionnalités TypeScript récentes

Décorateurs standard

Les décorateurs font désormais partie du langage, sans drapeau expérimental.

function logged(target: unknown, context: ClassMethodDecoratorContext) {
  // wrap the method
}

class Service {
  @logged
  fetchData() {
    /* ... */
  }
}

Gestion explicite des ressources

using exécute le nettoyage de manière déterministe via Symbol.dispose.

function readFile(path: string) {
  using handle = openFile(path)
  return handle.read()
}

`NoInfer`

Empêchez le compilateur d'inférer un argument de type à une position précise.

declare function createPair<T>(first: T, second: NoInfer<T>): T

const result = createPair('a', 'b') // T is inferred from the first arg only

Modèles d'architecture

Types Result au lieu d'exceptions

Représentez le succès et l'échec dans le type, pour que les appelants ne puissent pas oublier de gérer les erreurs.

type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E }

function divide(a: number, b: number): Result<number> {
  if (b === 0) return { ok: false, error: new Error('division by zero') }
  return { ok: true, value: a / b }
}

Vérifications exhaustives

Un utilitaire never garantit que chaque cas est traité quand l'union grandit.

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`)
}

// switch (state.kind) { ... default: assertNever(state) }

Types marqués (branded types)

Évitez de confondre des identifiants qui partagent le même type sous-jacent.

type UserId = string & { readonly __brand: 'UserId' }
type OrderId = string & { readonly __brand: 'OrderId' }

function toUserId(id: string): UserId {
  return id as UserId
}

Immutabilité par défaut

Préférez readonly, as const et les méthodes non mutantes pour que les changements d'état soient explicites.

interface Config {
  readonly apiUrl: string
  readonly retries: number
}

ESM et tree-shaking

Utilisez les modules ES et les imports nommés pour que les bundlers puissent supprimer le code inutilisé, et préférez les imports de type pour que les types ne s'infiltrent jamais dans les bundles d'exécution.

import type { User } from './models'
import { fetchUsers } from './api'

Pour conclure

L'expert front-end moderne s'appuie sur les nouvelles API JavaScript pour le traitement des données, et sur les unions discriminées, les types utilitaires et les types Result de TypeScript pour repousser les erreurs à la compilation. Adoptez ces motifs et votre code devient plus petit, plus sûr et bien plus facile à raisonner.

Les principes SOLID en pratique

Sat, 15 Aug 2026 00:00:00 GMT

Les principes SOLID sont un ensemble de cinq règles de conception qui aident à produire des logiciels maintenables et évolutifs.

Principe	Objectif
SRP	Une seule raison de changer
OCP	Ouvert à l'extension, fermé à la modification
LSP	Les sous-types doivent être substituables
ISP	Des interfaces petites et ciblées
DIP	Dépendre des abstractions, pas des implémentations

Responsabilité unique

Une classe ne doit avoir qu'une seule raison de changer.

class Invoice {
    void calculateTotal() { /* ... */ }
    void print() { /* violates SRP */ }
}

Extraire print() dans une classe dédiée InvoicePrinter permet à chaque préoccupation d'évoluer indépendamment.

Principe ouvert/fermé (OCP)

Un module doit être ouvert à l'extension mais fermé à la modification — le nouveau comportement s'ajoute en écrivant du code, pas en réécrivant l'existant.

public interface IDiscount
{
    decimal Apply(Order order);
}

public class SeasonalDiscount : IDiscount
{
    public decimal Apply(Order order) => order.Total * 0.10m;
}

public class LoyaltyDiscount : IDiscount
{
    public decimal Apply(Order order) => order.Total * 0.15m;
}

Ajouter un nouveau type de remise revient à ajouter une classe ; les existantes restent intactes.

Substitution de Liskov (LSP)

Les objets d'un sous-type doivent pouvoir être utilisés partout où le type parent est attendu, sans comportement surprenant.

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
}

public class Square : Rectangle
{
    public override int Width { set { base.Width = value; base.Height = value; } }
    public override int Height { set { base.Width = value; base.Height = value; } }
}

Un Square n'est pas un substitut fidèle de Rectangle — redimensionner un côté modifie silencieusement l'autre. Modélisez-les séparément ou derrière une abstraction commune.

Ségrégation des interfaces (ISP)

Un client ne doit pas être forcé de dépendre de méthodes qu'il n'utilise jamais. Préférez plusieurs interfaces étroites à une seule interface large.

// one fat interface
public interface IWorker
{
    void Work();
    void Eat();
}

// focused interfaces
public interface IWorkable
{
    void Work();
}

public interface IEatable
{
    void Eat();
}

Désormais, chaque classe n'implémente que ce dont elle a réellement besoin.

Inversion des dépendances

Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Tous deux doivent dépendre d'abstractions.

public interface IClock
{
    DateTime UtcNow { get; }
}

public class SystemClock : IClock
{
    public DateTime UtcNow => DateTime.UtcNow;
}

La logique métier reste ainsi testable et découplée de l'horloge.

D'autres articles plus détaillés suivront — celui-ci ne fait que poser les bases.

Les diagrammes Mermaid dans vos articles

Sun, 12 Jul 2026 00:00:00 GMT

Tout bloc de code délimité et étiqueté mermaid est rendu sous forme de diagramme SVG. Voici un tour d'horizon de ce qui est disponible.

Organigramme

flowchart LR
    A[Start] --> B{Logged in?}
    B -- Yes --> C[Dashboard]
    B -- No --> D[Login page]
    D --> E[Submit credentials]
    E --> B

Séquence

sequenceDiagram
    autonumber
    participant U as User
    participant A as API
    participant D as Database
    U->>A: POST /orders
    A->>D: INSERT order
    D-->>A: ok
    A-->>U: 201 Created

Diagramme de classes

classDiagram
    class Order {
        +id: string
        +total: number
        +submit()
    }
    class LineItem {
        +sku: string
        +qty: number
    }
    Order "1" --> "*" LineItem

Diagramme d'états

stateDiagram-v2
    [*] --> Draft
    Draft --> Published: publish()
    Published --> Archived: archive()
    Archived --> [*]

Entité-relation

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE_ITEM : contains
    PRODUCT ||--o{ LINE_ITEM : "ordered as"

Diagramme de Gantt

gantt
    title Release plan
    dateFormat YYYY-MM-DD
    section Backend
    API design       :a1, 2026-07-01, 7d
    Implementation   :a2, after a1, 14d
    section Frontend
    UI design        :b1, 2026-07-01, 7d
    Implementation   :b2, after b1, 14d

Diagramme circulaire

pie title Tech stack usage
    "Java" : 40
    "C#" : 35
    "Python" : 15
    "Other" : 10

Graphe Git

gitGraph
    commit id: "init"
    branch feature
    checkout feature
    commit id: "feat: parser"
    checkout main
    commit id: "fix: typo"
    merge feature

Carte mentale

mindmap
  root((Blog))
    Content
      Markdown
      Frontmatter
    Rendering
      Code highlighting
      Mermaid

Chronologie

timeline
    title Project milestones
    2026 Q2 : Kickoff
    2026 Q3 : Beta release
    2026 Q4 : General availability

Enveloppez n'importe lequel de ces exemples dans un bloc mermaid et il sera rendu sur la page.

Concevoir un pipeline CI/CD avec GitHub Actions

Fri, 05 Jun 2026 00:00:00 GMT

Automatiser votre pipeline de livraison supprime les étapes manuelles et rend chaque merge reproductible. Voici le pipeline que j'utilise pour mes projets personnels.

Vue d'ensemble

flowchart TD
    P[Push to main] --> L[Lint]
    L --> T[Unit tests]
    T --> S[SonarQube scan]
    S --> B[Build image]
    B --> V[Vulnerability scan]
    V --> D{Pass?}
    D -- Yes --> E[Deploy]
    D -- No --> R[Notify & block]

Le fichier de workflow

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run test -- --coverage
      - run: npm run build

Processus de release

Les releases sont créées à partir de tags et suivent un déploiement progressif.

gantt
    title Release rollout
    dateFormat  YYYY-MM-DD
    section Deploy
    Tag release        :2026-06-01, 1d
    Staging            :2d
    Canary (5%)        :2d
    Full rollout       :2d

Séquence de rollback

Si une release casse, le rollback est entièrement automatisé.

sequenceDiagram
    participant M as Monitoring
    participant O as Orchestrator
    participant K as Kubernetes
    M->>O: error rate > 1%
    O->>K: kubectl rollout undo
    K-->>O: rollout reverted
    O-->>M: healthy again

Gardez le pipeline rapide, déterministe et observable — tout le reste suit.

Bienvenue sur mon blog technique

Tue, 02 Jun 2026 00:00:00 GMT

Pourquoi un blog ?

J'ai créé cet espace pour partager les notes et leçons que je recueille au fil de mes projets personnels et de mes missions en production. Attendez-vous à des articles de fond sur SolidJS, .NET, Java, Angular et leurs outils.

La puissance du Markdown

Les articles sont rédigés en Markdown, ce qui me permet de me concentrer sur le contenu. Le moteur de rendu prend en charge l'essentiel :

Titres, listes et citations
Tableaux
Liens et images
Blocs de code avec coloration syntaxique
Diagrammes Mermaid

Coloration syntaxique

Les blocs de code sont colorés automatiquement selon le langage indiqué :

export interface Feature<T> {
  run(input: T): Promise<T>
}

export const identity = <T,>(value: T): T => value

public sealed class Greeter
{
    public string Hello(string name) => $"Hello, {name}!";
}

Diagrammes Mermaid

Les diagrammes sont rendus à partir d'un bloc mermaid :

flowchart TD
    A[Write Markdown] --> B{Contains mermaid?}
    B -- Yes --> C[Render SVG diagram]
    B -- No --> D[Render plain HTML]
    C --> E[Show article]
    D --> E

Les diagrammes de séquence fonctionnent aussi :

sequenceDiagram
    participant Client
    participant API
    participant Cache
    Client->>API: GET /posts
    API->>Cache: lookup
    alt hit
        Cache-->>API: data
    else miss
        API-->>API: build response
        API->>Cache: store
    end
    API-->>Client: 200 OK

Pour finir

Voilà l'essentiel. Restez à l'écoute pour des articles techniques plus détaillés.