Spring Framework fournit le conteneur IoC, l'AOP, le web MVC, les transactions ; Spring Boot ajoute l'auto-configuration, les starters et un serveur embarqué pour démarrer sans configuration manuelle.

Avec Spring « nu », il fallait déclarer soi-même la DataSource, le TransactionManager, le DispatcherServlet… Spring Boot détecte les bibliothèques présentes et configure tout avec des valeurs par défaut raisonnables, que l'on surcharge dans application.yml. L'application se lance comme un simple java -jar (Tomcat embarqué).

@SpringBootApplication          // = @Configuration + @EnableAutoConfiguration + @ComponentScan
public class BanqueApplication {
    public static void main(String[] args) {
        SpringApplication.run(BanqueApplication.class, args);
    }
}

Mécanisme de Spring Boot qui crée automatiquement des beans selon le classpath et les propriétés (ex. une DataSource si un driver JDBC est présent).

Chaque auto-configuration est conditionnelle (@ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty). Si tu déclares ton propre bean, celui de Boot s'efface. Pour voir ce qui a été activé ou non : --debug au démarrage.

@AutoConfiguration
@ConditionalOnClass(DataSource.class)
public class MaDataSourceAutoConfig {
    @Bean
    @ConditionalOnMissingBean          // seulement si l'application n'en définit pas
    DataSource dataSource(DataSourceProperties p) { return p.initializeDataSourceBuilder().build(); }
}

java -jar app.jar --debug    # rapport "CONDITIONS EVALUATION REPORT"

Dépendance Maven/Gradle « tout-en-un » qui apporte un ensemble cohérent de bibliothèques pour un besoin (web, JPA, sécurité…) avec des versions compatibles.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>   <!-- Spring MVC + Jackson + Tomcat -->
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Principe où ce n'est plus ton code qui crée ses dépendances : le conteneur Spring les crée, les relie et gère leur cycle de vie.

Sans IoC, OrderService ferait new JpaOrderRepo() : couplage fort, impossible à remplacer en test. Avec IoC, la classe déclare ce dont elle a besoin et le conteneur le fournit. L'Injection de dépendances est la technique qui réalise l'IoC.

// ❌ sans IoC : la classe choisit et construit sa dépendance
private final OrderRepo repo = new JpaOrderRepo();
// ✅ avec IoC : elle la reçoit
public OrderService(OrderRepo repo) { this.repo = repo; }

Technique où les dépendances d'un objet lui sont fournies de l'extérieur, de préférence par le constructeur.

Trois formes : par constructeur (recommandée), par setter, par champ (@Autowired sur un attribut, à éviter). Le constructeur rend les dépendances obligatoires et final, rend la classe testable sans Spring (new OrderService(mockRepo)) et révèle les classes qui ont trop de dépendances.

@Service
public class OrderService {
    private final OrderRepo repo;
    private final PaymentGateway gateway;
    // un seul constructeur → @Autowired implicite depuis Spring 4.3
    public OrderService(OrderRepo repo, PaymentGateway gateway) {
        this.repo = repo;
        this.gateway = gateway;
    }
}

Objet créé, configuré et géré par le conteneur Spring (ApplicationContext). Par défaut, un seul exemplaire (singleton) par contexte.

Tout ce que Spring injecte est un bean : services, repositories, contrôleurs, mais aussi objets techniques (ObjectMapper, DataSource). Un bean est déclaré par un stéréotype (@Service…) ou une méthode @Bean.

@Component
public class GenerateurReference {
    public String nouvelle() { return "TX-" + UUID.randomUUID(); }
}

Le conteneur IoC de Spring : il scanne les classes, crée les beans, résout les dépendances, applique les proxies (transactions, sécurité) et publie des événements.

@Component
public class Demarrage implements ApplicationRunner {
    private final ApplicationContext ctx;
    public Demarrage(ApplicationContext ctx) { this.ctx = ctx; }
    public void run(ApplicationArguments args) {
        System.out.println(ctx.getBeanDefinitionCount() + " beans chargés");
    }
}

Annotations qui déclarent une classe comme bean lors du scan ; elles indiquent aussi son rôle dans l'architecture.

@Configuration marque une classe de configuration ; chaque méthode @Bean qu'elle contient déclare un bean, utile pour des classes que tu ne peux pas annoter (bibliothèques tierces).

@Configuration
public class ClientsConfig {
    @Bean
    RestClient waveClient(RestClient.Builder builder,
                          @Value("${wave.base-url}") String baseUrl) {
        return builder.baseUrl(baseUrl).build();
    }
}

Durée de vie d'un bean : singleton (un par contexte, défaut), prototype (nouveau à chaque injection), request (un par requête HTTP), session (un par session HTTP).

@Component
@Scope("prototype")
public class PanierCalcul { /* état propre à chaque utilisation */ }

@Component
@RequestScope                       // un exemplaire par requête HTTP
public class ContexteRequete { private String correlationId; }

Annotation qui demande à Spring d'injecter une dépendance ; facultative sur un constructeur unique depuis Spring 4.3.

Si plusieurs beans du même type existent, Spring ne sait pas lequel choisir : on précise avec @Qualifier("nom") ou on marque un bean @Primary.

public NotificationService(@Qualifier("sms") Notificateur notificateur) { … }

Les paramètres (URL, timeouts, secrets) vivent hors du code, dans application.yml ou des variables d'environnement ; on les lit avec @Value ou, mieux, une classe @ConfigurationProperties typée.

banque:
  virement:
    plafond-journalier: 5000000
    timeout: 3s

@ConfigurationProperties(prefix = "banque.virement")
public record VirementProperties(BigDecimal plafondJournalier, Duration timeout) {}

@SpringBootApplication
@ConfigurationPropertiesScan
public class App {}

Un profil active une configuration ou des beans selon l'environnement (dev, test, prod) : fichier application-prod.yml, beans annotés @Profile("prod").

@Bean @Profile("dev")
PaymentGateway fauxGateway() { return new PaymentGatewaySimule(); }

java -jar app.jar --spring.profiles.active=prod   # charge application-prod.yml

Module qui expose des endpoints de supervision : santé (/actuator/health), métriques, info, et format Prometheus.

Indispensable en production et sur Kubernetes : les probes liveness/readiness interrogent /actuator/health/liveness et /actuator/health/readiness.

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    health:
      probes:
        enabled: true

Ensemble de projets pour les systèmes distribués : Gateway (API Gateway), Config Server, OpenFeign, Circuit Breaker, Stream (Kafka/RabbitMQ).

Sur Kubernetes, une partie de ces besoins (découverte de services, configuration) est assurée par la plateforme ; Spring Cloud Gateway et Spring Cloud Stream restent très utilisés.

spring:
  cloud:
    gateway:
      server:
        webmvc:
          routes:
            - id: comptes
              uri: http://comptes-service:8080
              predicates:
                - Path=/api/comptes/**

Depuis Spring Boot 3, les API Java EE ont changé de package : javax.persistence → jakarta.persistence, javax.servlet → jakarta.servlet, etc. Boot 4 passe à Jakarta EE 11.

Oracle a cédé Java EE à la fondation Eclipse, qui l'a renommé Jakarta EE sans pouvoir garder le nom javax. Migrer de Boot 2 à Boot 3 impose donc de réécrire les imports (outil OpenRewrite) et de mettre à jour les bibliothèques. De Boot 3 à Boot 4, pas de nouveau renommage.

// Spring Boot 2.x
import javax.persistence.Entity;
import javax.validation.constraints.NotBlank;
// Spring Boot 3.x / 4.x
import jakarta.persistence.Entity;
import jakarta.validation.constraints.NotBlank;

Traitement effectué au build (et non au démarrage) : Spring pré-calcule la configuration des beans pour démarrer plus vite et permettre la compilation native.

Normalement Spring analyse les annotations par réflexion au démarrage. En mode AOT, le plugin Maven/Gradle génère du code Java qui enregistre directement les beans. Spring Boot 4 étend l'AOT à Spring Data (repositories pré-générés).

./mvnw spring-boot:process-aot package

Compile l'application Java en exécutable natif : démarrage en dizaines de millisecondes et mémoire réduite, au prix d'un build long et de restrictions sur la réflexion.

Intéressant pour les fonctions serverless et les microservices qui démarrent souvent. Moins pertinent pour une grosse application longue durée, où la JVM et son JIT restent plus performants une fois chauds.

./mvnw -Pnative native:compile        # produit target/mon-app (binaire natif)
./mvnw spring-boot:build-image -Pnative   # image Docker native via buildpacks

Génération sortie en novembre 2025 : Java 17 minimum (Java 25 recommandé), Jakarta EE 11, Jackson 3, versioning d'API natif, clients HTTP déclaratifs, null-safety JSpecify, résilience intégrée.

Points à retenir pour un entretien :

• Baseline Java 17 (comme Boot 3), support de premier niveau de Java 25.
• Jackson 3 par défaut (Jackson 2 encore disponible en mode déprécié).
• Versioning d'API et HTTP Service Clients intégrés.
• JSpecify pour la null-safety, @Retryable / @ConcurrencyLimit dans le cœur.
• JUnit 6, @MockitoBean remplace @MockBean, RestTestClient remplace TestRestTemplate.
• Les virtual threads restent opt-in (spring.threads.virtual.enabled=true).

Standard d'annotations de nullité adopté par Spring 7 : dans un package @NullMarked, tout est non-null par défaut et @Nullable signale explicitement ce qui peut l'être.

Les IDE et des outils comme NullAway détectent alors à la compilation un risque de NullPointerException. Spring annote toute son API ainsi.

// package-info.java
@NullMarked
package sn.banque.virement;
import org.jspecify.annotations.NullMarked;

// dans le package
public @Nullable Client chercher(String telephone) { … }   // peut renvoyer null : l'appelant est averti

Bibliothèque JSON par défaut de Spring Boot 4 : packages tools.jackson, configuration immuable (JsonMapper.builder()), dates ISO-8601 par défaut, exceptions non vérifiées.

Jackson convertit les objets Java en JSON et inversement (sérialisation/désérialisation) pour les contrôleurs REST. Les annotations (@JsonProperty, @JsonIgnore) restent dans com.fasterxml.jackson.annotation.

JsonMapper mapper = JsonMapper.builder()
        .disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
        .build();                                      // immuable une fois construit
String json = mapper.writeValueAsString(new VirementDto("SN01", "SN02", BigDecimal.TEN));

Spring Framework 7 gère nativement plusieurs versions d'un endpoint : la version est lue dans un header, un paramètre, le chemin ou le media type, puis routée via l'attribut version.

spring.mvc.apiversion.use.header=X-API-Version
spring.mvc.apiversion.supported=1.0,2.0
spring.mvc.apiversion.default=1.0

@GetMapping(path = "/comptes/{id}", version = "1.0")
CompteV1 compteV1(@PathVariable Long id) { … }

@GetMapping(path = "/comptes/{id}", version = "2.0")
CompteV2 compteV2(@PathVariable Long id) { … }   // X-API-Version: 2.0

Client HTTP déclaratif : on écrit une interface annotée et Spring génère l'implémentation (comme OpenFeign, mais intégré au framework). Boot 4 les enregistre avec @ImportHttpServices.

@HttpExchange("/v1/paiements")
public interface OperateurClient {
    @GetExchange("/{id}")
    PaiementDto statut(@PathVariable String id);

    @PostExchange
    PaiementDto initier(@RequestBody DemandePaiement demande);
}

@Configuration
@ImportHttpServices(group = "operateur", types = OperateurClient.class)
class HttpClientsConfig {}   // l'URL de base se configure par groupe

Client HTTP synchrone moderne (Spring 6.1 / Boot 3.2) à API fluide ; c'est le remplaçant officiel de RestTemplate.

Il partage l'infrastructure de RestTemplate (convertisseurs, intercepteurs) mais avec une API lisible et chaînée. Il s'injecte via RestClient.Builder, pré-configuré par Boot (observabilité, Jackson).

@Service
public class TauxService {
    private final RestClient client;
    public TauxService(RestClient.Builder builder) {
        this.client = builder.baseUrl("https://api.bceao.exemple").build();
    }
    public TauxDto taux(String devise) {
        return client.get().uri("/taux/{d}", devise)
                .retrieve()
                .onStatus(HttpStatusCode::is4xxClientError,
                          (req, res) -> { throw new NotFoundException("Devise inconnue " + devise); })
                .body(TauxDto.class);
    }
}

Ancien client HTTP synchrone de Spring ; déprécié pour suppression depuis Spring Framework 7.1 (Boot 4.1), suppression prévue en 8.0. Utiliser RestClient.

// avant
User u = restTemplate.getForObject("/users/{id}", User.class, 42);
// après
User u = restClient.get().uri("/users/{id}", 42).retrieve().body(User.class);

Client HTTP non bloquant et réactif (Spring WebFlux), qui renvoie des Mono/Flux. À réserver aux applications réactives ou aux appels massivement concurrents.

Mono<TauxDto> taux = webClient.get().uri("/taux/{d}", "EUR")
        .retrieve().bodyToMono(TauxDto.class)
        .timeout(Duration.ofSeconds(2));

Depuis Boot 3.2, la propriété spring.threads.virtual.enabled=true fait traiter chaque requête Tomcat, chaque tâche @Async et chaque listener par un virtual thread. Toujours opt-in en Boot 4.

spring.threads.virtual.enabled=true

Spring Framework 7 intègre dans le cœur la relance automatique (@Retryable avec backoff exponentiel et jitter) et la limitation de concurrence (@ConcurrencyLimit).

@Configuration
@EnableResilientMethods
class ResilienceConfig {}

@Service
class NotificationService {
    @Retryable(includes = OperateurIndisponibleException.class,
               maxRetries = 3, delay = 200, multiplier = 2, jitter = 50, maxDelay = 2000)
    public void envoyerSms(String tel, String msg) { … }

    @ConcurrencyLimit(10)            // au plus 10 appels simultanés
    public void appelerOperateur() { … }
}

Style d'architecture où l'on manipule des ressources identifiées par des URL avec les verbes HTTP, de façon sans état (stateless), en échangeant des représentations (souvent JSON).

Bonnes pratiques : noms au pluriel (/clients), pas de verbe dans l'URL (POST /clients et non /creerClient), codes HTTP significatifs, pagination, versioning.

GET lit sans effet de bord (sûr) ; PUT et DELETE sont idempotents (les répéter donne le même état) ; POST et PATCH ne le sont pas par nature.

C'est essentiel pour les relances : un client peut rejouer un GET ou un PUT sans risque, mais rejouer un POST de paiement peut débiter deux fois. D'où l'Idempotency-Key pour les POST sensibles.

@Controller + @ResponseBody : chaque méthode renvoie directement des données sérialisées en JSON, et non une vue HTML.

@RestController
@RequestMapping("/api/v1/clients")
public class ClientController {
    private final ClientService service;
    public ClientController(ClientService service) { this.service = service; }

    @GetMapping("/{id}")
    public ClientDto get(@PathVariable Long id) { return service.get(id); }  // → JSON
}

Annotations qui associent une URL et un verbe HTTP à une méthode Java ; @RequestMapping sur la classe fixe le préfixe commun.

@RestController
@RequestMapping("/api/v1/comptes")              // préfixe
class CompteController {
    @GetMapping                 List<CompteDto> lister() { … }          // GET /api/v1/comptes
    @PostMapping                CompteDto creer(@RequestBody …) { … }   // POST
    @PatchMapping("/{id}/gel")  void geler(@PathVariable Long id) { … } // PATCH
    @DeleteMapping("/{id}")     void supprimer(@PathVariable Long id) { … }
}

@PathVariable lit une partie du chemin (/clients/{id}) pour identifier une ressource ; @RequestParam lit un paramètre de requête (?ville=Dakar) pour filtrer, trier ou paginer.

@GetMapping("/clients/{id}")                       // GET /clients/42
ClientDto get(@PathVariable Long id) { … }

@GetMapping("/clients")                            // GET /clients?ville=Dakar&actif=true
List<ClientDto> chercher(@RequestParam String ville,
                         @RequestParam(defaultValue = "true") boolean actif) { … }

Indique que le corps JSON de la requête doit être désérialisé (par Jackson) dans l'objet Java du paramètre.

@PostMapping
@ResponseStatus(HttpStatus.CREATED)
ClientDto creer(@Valid @RequestBody CreateClientRequest req) { return service.creer(req); }

POST /api/v1/clients
Content-Type: application/json

{"nom": "Awa Ndiaye", "email": "awa@exemple.sn"}

Objet qui représente la réponse HTTP complète : code de statut, en-têtes et corps. Utile quand le code ou les headers varient.

@PostMapping
ResponseEntity<ClientDto> creer(@Valid @RequestBody CreateClientRequest req) {
    ClientDto cree = service.creer(req);
    URI location = URI.create("/api/v1/clients/" + cree.id());
    return ResponseEntity.created(location).body(cree);       // 201 + header Location
}
@GetMapping("/{id}")
ResponseEntity<ClientDto> get(@PathVariable Long id) {
    return service.chercher(id).map(ResponseEntity::ok)
                  .orElse(ResponseEntity.notFound().build()); // 404
}

Fixe le code HTTP renvoyé par une méthode de contrôleur (ex. 201 Created) ou associé à une exception.

@PostMapping
@ResponseStatus(HttpStatus.CREATED)      // 201 au lieu de 200
OrderDto create(@Valid @RequestBody CreateOrderRequest req) { … }

@ResponseStatus(HttpStatus.CONFLICT)     // 409 quand cette exception remonte
class EmailDejaUtiliseException extends RuntimeException { … }

Spring Data lit automatiquement ?page=0&size=20&sort=nom,asc dans un objet Pageable et renvoie une Page (contenu + nombre total d'éléments).

@GetMapping
Page<ClientDto> lister(@PageableDefault(size = 20, sort = "nom") Pageable pageable) {
    return repo.findAll(pageable).map(mapper::toDto);
}

Objet simple qui transporte les données entre couches ou sur le réseau ; c'est le contrat de l'API, distinct de l'entité JPA.

Le DTO expose uniquement ce que le client doit voir (pas de mot de passe haché, pas de relations lazy), reste stable même si le schéma de base change, et porte les annotations de validation. Un record est idéal.

public record ClientDto(Long id, String nom, String email, String ville) {}
public record CreateClientRequest(@NotBlank String nom, @Email String email) {}

Composant qui convertit entité ↔ DTO ; MapStruct génère ce code à la compilation à partir d'une interface, sans réflexion.

@Mapper(componentModel = "spring")
public interface ClientMapper {
    ClientDto toDto(Client entity);
    @Mapping(target = "id", ignore = true)
    Client toEntity(CreateClientRequest req);
}

Standard Jakarta Validation : on annote les champs du DTO avec des contraintes, et @Valid déclenche leur vérification avant l'exécution du contrôleur.

Si une contrainte échoue, Spring lève MethodArgumentNotValidException (→ 400). Contraintes courantes : @NotNull, @NotBlank, @Size, @Email, @Pattern, @Positive, @DecimalMin, @Past.

public record VirementRequest(
    @NotBlank @Pattern(regexp = "SN\\d{2}[A-Z0-9]{20,}") String ibanDest,
    @NotNull @Positive @Digits(integer = 12, fraction = 0) BigDecimal montant,
    @Size(max = 140) String motif) {}

@PostMapping("/virements")
VirementDto virer(@Valid @RequestBody VirementRequest req) { … }

Exception levée par Spring quand un objet annoté @Valid ne respecte pas ses contraintes ; son BindingResult contient la liste des champs en erreur.

@ExceptionHandler(MethodArgumentNotValidException.class)
@ResponseStatus(HttpStatus.BAD_REQUEST)
Map<String, String> erreurs(MethodArgumentNotValidException ex) {
    return ex.getBindingResult().getFieldErrors().stream()
        .collect(Collectors.toMap(FieldError::getField, FieldError::getDefaultMessage, (a, b) -> a));
}   // {"montant": "doit être supérieur à 0"}

@RestControllerAdvice centralise la gestion des erreurs de tous les contrôleurs ; chaque méthode @ExceptionHandler traduit un type d'exception en réponse HTTP cohérente.

Sans cela, chaque contrôleur ferait ses try/catch et les formats d'erreur divergeraient. On mappe : validation → 400, NotFound → 404, conflit métier → 409, exception inattendue → 500 (sans détail technique, mais loggée).

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(NotFoundException.class)
    ResponseEntity<ProblemDetail> notFound(NotFoundException ex) {
        return ResponseEntity.status(404).body(ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage()));
    }
    @ExceptionHandler(Exception.class)
    ResponseEntity<ProblemDetail> inattendu(Exception ex) {
        log.error("Erreur non gérée", ex);                     // détail dans les logs, pas au client
        return ResponseEntity.status(500).body(ProblemDetail.forStatus(HttpStatus.INTERNAL_SERVER_ERROR));
    }
}

Format standard de réponse d'erreur JSON (type, title, status, detail, instance) supporté nativement par Spring 6+.

ProblemDetail pd = ProblemDetail.forStatusAndDetail(HttpStatus.CONFLICT, "Solde insuffisant");
pd.setTitle("Virement refusé");
pd.setProperty("code", "SOLDE_INSUFFISANT");

{ "type": "about:blank", "title": "Virement refusé", "status": 409,
  "detail": "Solde insuffisant", "instance": "/api/v1/virements", "code": "SOLDE_INSUFFISANT" }

JPA est la spécification Java de mapping objet-relationnel (ORM) ; Hibernate en est l'implémentation la plus utilisée ; Spring Data JPA génère les repositories au-dessus.

L'ORM traduit les objets Java en lignes SQL et inversement. On écrit repo.save(client) et Hibernate génère l'INSERT. Il faut quand même comprendre le SQL produit (activer les logs) pour éviter les problèmes de performance.

spring:
  jpa:
    show-sql: true                  # en dev seulement
    properties.hibernate.format_sql: true
    open-in-view: false

Classe Java mappée sur une table : @Entity la déclare, @Id marque la clé primaire, @Column/@Table ajustent le mapping.

@Entity
@Table(name = "compte")
public class Compte {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false, unique = true, length = 34)
    private String iban;
    @Column(nullable = false, precision = 15, scale = 2)
    private BigDecimal solde;
    @Version
    private Long version;            // verrouillage optimiste
    protected Compte() {}            // requis par JPA
}

Interface qui hérite de JpaRepository<Entité, TypeId> ; Spring génère l'implémentation avec save, findById, findAll, delete, pagination…

public interface CompteRepository extends JpaRepository<Compte, Long> {
    Optional<Compte> findByIban(String iban);                 // requête dérivée du nom
    List<Compte> findByClientIdAndStatut(Long clientId, Statut statut);
    boolean existsByIban(String iban);
}

Spring Data construit la requête à partir du nom de la méthode : findByStatutAndVille, countByActifTrue, findTop10ByOrderByDateDesc.

List<Commande> findByStatutAndDateCreationAfter(Statut s, LocalDate d);
// → SELECT c FROM Commande c WHERE c.statut = ?1 AND c.dateCreation > ?2
long countByStatut(Statut s);
List<Commande> findTop10ByClientIdOrderByDateCreationDesc(Long clientId);

@Query écrit explicitement la requête en JPQL (sur les entités) ou en SQL natif ; @Param lie un paramètre nommé.

JPQL manipule des entités et leurs attributs (o.status), pas des tables et colonnes.

@Query("SELECT o FROM Order o WHERE o.status = :s AND o.total > :min")
List<Order> findGrosses(@Param("s") Status s, @Param("min") BigDecimal min);

@Query(value = "SELECT * FROM commande WHERE created_at > now() - interval '1 day'", nativeQuery = true)
List<Order> dernieres24h();

@Modifying
@Query("UPDATE Compte c SET c.statut = 'GELE' WHERE c.id = :id")
int geler(@Param("id") Long id);

Annotations qui mappent les liens entre entités ; le côté @ManyToOne porte la clé étrangère, le côté @OneToMany (mappedBy) est l'inverse.

@Entity class Order {
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderLine> lines = new ArrayList<>();
}
@Entity class OrderLine {
    @ManyToOne(fetch = FetchType.LAZY)       // FK order_id dans la table order_line
    @JoinColumn(name = "order_id")
    private Order order;
}

LAZY charge une relation seulement au premier accès (proxy) ; EAGER la charge immédiatement avec l'entité. Par défaut : @OneToMany LAZY, @ManyToOne EAGER.

La bonne pratique est tout en LAZY, puis charger explicitement ce dont un cas d'usage a besoin (JOIN FETCH, @EntityGraph). EAGER partout provoque des requêtes inutiles et souvent des N+1 cachés.

@ManyToOne(fetch = FetchType.LAZY)
private Client client;     // client.getNom() déclenche le SELECT au moment de l'accès

Anti-pattern où l'on exécute 1 requête pour charger N parents, puis 1 requête supplémentaire par parent pour charger ses enfants : N+1 requêtes au lieu d'une ou deux.

Typique avec des relations LAZY parcourues dans une boucle ou lors de la sérialisation JSON. Invisible en dev avec 10 lignes, catastrophique en production avec 10 000.

List<Order> orders = repo.findAll();              // 1 requête
for (Order o : orders) {
    o.getLines().size();                          // + 1 requête PAR commande → N requêtes
}

Clause JPQL qui charge l'entité et sa relation dans la même requête SQL (jointure), ce qui supprime le N+1 pour ce cas d'usage.

@Query("SELECT DISTINCT o FROM Order o JOIN FETCH o.lines WHERE o.status = :s")
List<Order> findWithLines(@Param("s") Status s);

Annotation qui indique quelles relations charger en même temps que l'entité pour une méthode de repository, sans écrire de JPQL.

@EntityGraph(attributePaths = {"lines", "customer"})
Optional<Order> findById(Long id);

@EntityGraph(attributePaths = "customer")
List<Order> findByStatus(Status status);

Annotation Hibernate qui charge les relations LAZY par lots (ex. 50 parents à la fois avec un IN (...)) : N+1 devient 1 + N/50 requêtes.

@OneToMany(mappedBy = "order")
@BatchSize(size = 50)
private List<OrderLine> lines;

spring.jpa.properties.hibernate.default_batch_fetch_size: 50   # global

Erreur levée quand on accède à une relation LAZY alors que la session Hibernate (transaction) est fermée, typiquement dans le contrôleur ou lors de la sérialisation JSON.

@Transactional(readOnly = true)
public OrderDto get(Long id) {
    Order o = repo.findById(id).orElseThrow();
    return mapper.toDto(o);          // ✅ mapping DANS la transaction : les lignes se chargent
}
// ❌ renvoyer l'entité au contrôleur puis o.getLines() hors transaction → LazyInitializationException

Option activée par défaut dans Spring Boot qui garde la session Hibernate ouverte jusqu'à la fin de la requête HTTP ; elle masque les LazyInitializationException mais génère des requêtes cachées.

spring.jpa.open-in-view: false   # recommandé : charger explicitement dans le service

Le contexte de persistance (EntityManager) suit les entités chargées dans une transaction ; au commit, Hibernate détecte leurs modifications (dirty checking) et génère les UPDATE automatiquement.

@Transactional
public void renommer(Long id, String nom) {
    Client c = repo.findById(id).orElseThrow();
    c.setNom(nom);        // pas de save() nécessaire : UPDATE généré au commit
}

Ne charger que les colonnes utiles en renvoyant une interface ou un record au lieu de l'entité complète ; plus rapide et pas de piège lazy.

public record ClientResume(Long id, String nom) {}

@Query("SELECT new sn.banque.ClientResume(c.id, c.nom) FROM Client c WHERE c.ville = :v")
List<ClientResume> resumes(@Param("v") String ville);

Scripts versionnés qui font évoluer le schéma de base de façon reproductible sur tous les environnements ; exécutés au démarrage de l'application.

-- src/main/resources/db/migration/V3__ajout_statut_compte.sql
ALTER TABLE compte ADD COLUMN statut VARCHAR(20) NOT NULL DEFAULT 'ACTIF';
CREATE INDEX idx_compte_statut ON compte(statut);

Annotation qui exécute une méthode dans une transaction : commit si elle se termine normalement, rollback si une RuntimeException est levée.

Elle se place sur les méthodes publiques des services (pas sur les contrôleurs). Spring l'applique via un Proxy Spring qui ouvre la transaction avant l'appel et la termine après.

@Service
public class VirementService {
    @Transactional
    public void virer(Long source, Long dest, BigDecimal montant) {
        Compte a = repo.findById(source).orElseThrow();
        Compte b = repo.findById(dest).orElseThrow();
        a.debiter(montant);
        b.crediter(montant);       // si exception ici → le débit est annulé (rollback)
    }
}

Objet intermédiaire généré par Spring qui enveloppe ton bean : il exécute du code avant/après chaque appel externe (transaction, sécurité, cache, @Async).

L'appelant reçoit le proxy, pas l'instance réelle. Spring utilise CGLIB (sous-classe générée) par défaut dans Boot. Conséquences : les méthodes private ou final ne sont pas interceptées, et un appel interne this.methode() contourne le proxy.

Contrôleur ──► [Proxy VirementService] ──► begin tx ──► VirementService.virer() ──► commit/rollback

Technique qui ajoute un comportement transversal (logs, transactions, sécurité, métriques) autour de méthodes sans modifier leur code.

@Transactional, @Cacheable, @PreAuthorize, @Async sont implémentés par AOP. On peut écrire ses propres aspects.

@Aspect @Component
public class DureeAspect {
    @Around("@annotation(sn.banque.Chronometre)")
    public Object mesurer(ProceedingJoinPoint pjp) throws Throwable {
        long t0 = System.nanoTime();
        try { return pjp.proceed(); }
        finally { log.info("{} : {} ms", pjp.getSignature(), (System.nanoTime() - t0) / 1_000_000); }
    }
}

Quand une méthode d'un bean appelle une autre méthode du même bean (this.methode()), l'appel ne passe pas par le proxy : @Transactional, @Cacheable, @Async de la méthode appelée sont ignorés.

@Service
public class PaiementService {
    public void traiter() {
        journaliser();                         // ❌ appel interne : pas de REQUIRES_NEW
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void journaliser() { … }
}

Injecter un bean dans lui-même pour appeler ses méthodes via le proxy ; contournement du problème d'auto-invocation.

@Service
public class PaiementService {
    private final PaiementService self;
    public PaiementService(@Lazy PaiementService self) { this.self = self; }   // @Lazy évite la dépendance circulaire
    public void traiter() { self.journaliser(); }                              // ✅ passe par le proxy
    @Transactional(propagation = Propagation.REQUIRES_NEW) public void journaliser() { … }
}

Rejoint la transaction en cours s'il y en a une, sinon en crée une nouvelle. Une erreur n'importe où annule tout l'ensemble.

@Transactional                       // = propagation REQUIRED
public void commander() {
    stockService.reserver();         // @Transactional aussi → même transaction
    paiementService.debiter();       // si échec → la réservation est annulée aussi
}

Suspend la transaction en cours et en ouvre une nouvelle, indépendante : son commit ou rollback n'affecte pas l'appelant.

Cas classique : écrire un journal d'audit qui doit être conservé même si l'opération principale échoue.

@Service class AuditService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void tracer(String evenement) { auditRepo.save(new Audit(evenement)); }  // commit immédiat
}

SUPPORTS utilise une transaction si elle existe ; NOT_SUPPORTED suspend toute transaction ; MANDATORY exige qu'une transaction existe ; NEVER interdit qu'elle existe ; NESTED crée un savepoint.

Par défaut, Spring annule la transaction sur RuntimeException et Error, mais commit sur exception checked. rollbackFor étend ce comportement.

@Transactional(rollbackFor = Exception.class)     // rollback aussi sur les checked
public void importer(Path fichier) throws IOException { … }

Marque une transaction en lecture seule : Hibernate désactive le dirty checking (moins de mémoire, plus rapide) et certains drivers routent vers un réplica.

@Service
@Transactional(readOnly = true)               // défaut pour toute la classe
public class RapportService {
    public List<LigneRapport> mensuel(YearMonth m) { … }
    @Transactional                            // écriture : surcharge locale
    public void archiver(YearMonth m) { … }
}

Met en cache le résultat d'une méthode selon ses paramètres ; les appels suivants avec la même clé ne réexécutent pas la méthode. @CacheEvict invalide.

@EnableCaching @Configuration class CacheConfig {}

@Cacheable(cacheNames = "taux", key = "#devise")
public TauxDto taux(String devise) { return client.taux(devise); }   // 1er appel seulement

@CacheEvict(cacheNames = "taux", allEntries = true)
@Scheduled(cron = "0 0 6 * * *")
public void rafraichir() {}

Framework d'authentification et d'autorisation basé sur une chaîne de filtres Servlet exécutés avant les contrôleurs ; on la configure avec un bean SecurityFilterChain.

@Configuration
@EnableMethodSecurity
public class SecurityConfig {
    @Bean
    SecurityFilterChain api(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())                       // API stateless JWT
            .cors(Customizer.withDefaults())
            .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/health/**").permitAll()
                .requestMatchers(HttpMethod.POST, "/api/v1/virements").hasRole("CLIENT")
                .anyRequest().authenticated())
            .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()))
            .build();
    }
}

Cross-Origin Resource Sharing : règle du navigateur qui bloque les appels vers un autre domaine sauf si le serveur l'autorise via des en-têtes Access-Control-Allow-*. Ce n'est pas une sécurité d'authentification.

Une SPA Angular sur https://app.banque.sn qui appelle https://api.banque.sn est « cross-origin ». Le navigateur envoie d'abord une requête OPTIONS (preflight) ; Spring doit répondre avec les origines, méthodes et en-têtes autorisés.

@Bean
CorsConfigurationSource corsConfigurationSource() {
    var cfg = new CorsConfiguration();
    cfg.setAllowedOrigins(List.of("https://app.banque.sn", "http://localhost:4200"));
    cfg.setAllowedMethods(List.of("GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"));
    cfg.setAllowedHeaders(List.of("Authorization", "Content-Type"));
    var source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/api/**", cfg);
    return source;
}

Cross-Site Request Forgery : un site malveillant fait envoyer par le navigateur de la victime une requête authentifiée (les cookies partent automatiquement). Se protège par un jeton CSRF ou des cookies SameSite.

Concerne les applications qui s'authentifient par cookie de session. Une API qui exige Authorization: Bearer <JWT> n'est pas exposée : un site tiers ne peut pas ajouter cet en-tête. D'où csrf.disable() en API stateless.

// Application à session cookie : garder CSRF, exposer le jeton au front Angular
http.csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()));
// Angular lit le cookie XSRF-TOKEN et renvoie le header X-XSRF-TOKEN automatiquement

BCrypt est une fonction de hachage de mot de passe lente et salée, avec un facteur de coût réglable ; PasswordEncoder est l'interface Spring qui l'encapsule.

Le sel (aléatoire, intégré au hash) empêche les tables précalculées ; la lenteur volontaire (coût 10-12) rend le brute force très coûteux. On ne « déchiffre » jamais un mot de passe : on compare avec matches().

@Bean PasswordEncoder passwordEncoder() {
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();  // {bcrypt} par défaut
}
String hash = encoder.encode("MotDePasse!2026");   // {bcrypt}$2a$10$Qm… (sel inclus)
encoder.matches("MotDePasse!2026", hash);          // true

Le serveur ne conserve aucune session : chaque requête porte sa preuve d'authentification (JWT). Facilite la montée en charge horizontale (n'importe quel pod peut répondre).

http.sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

Configuration Spring Security où l'API valide les JWT émis par un serveur d'autorisation (Keycloak) : signature via JWKS, expiration, émetteur.

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.banque.sn/realms/banque   # Spring récupère les clés publiques (JWKS)

http.oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()));

Vérifie une règle d'autorisation (rôle, propriété de la ressource) avant l'exécution d'une méthode, avec une expression SpEL.

@PreAuthorize("hasRole('CONSEILLER')")
public List<ClientDto> portefeuille() { … }

@PreAuthorize("#compteId == authentication.principal.claims['compte_id'] or hasRole('ADMIN')")
public SoldeDto solde(Long compteId) { … }      // un client ne voit que SON compte

Conteneur (par requête) de l'utilisateur authentifié et de ses autorités ; rempli par les filtres de sécurité, lisible partout dans le traitement.

@GetMapping("/moi")
ProfilDto moi(@AuthenticationPrincipal Jwt jwt) {
    return new ProfilDto(jwt.getSubject(), jwt.getClaimAsString("email"));
}
// ou : SecurityContextHolder.getContext().getAuthentication().getName()

Composant autonome qui déclare lui-même ses dépendances dans imports, sans NgModule. Introduit en v14, standalone par défaut depuis v19.

Avant, chaque composant devait être déclaré dans un NgModule, source de confusion (« dans quel module est-il déclaré ? »). Un composant standalone importe directement les composants, directives et pipes qu'il utilise ; l'application démarre avec bootstrapApplication.

@Component({
  selector: 'app-compte-carte',
  imports: [CurrencyPipe, RouterLink],          // ses dépendances, ici et pas dans un module
  template: `<a [routerLink]="['/comptes', compte().id]">{{ compte().solde | currency:'XOF' }}</a>`,
})
export class CompteCarteComponent {
  compte = input.required<Compte>();
}

Point d'entrée d'une application standalone : on démarre le composant racine et on enregistre les services globaux avec des fonctions provideXxx().

// main.ts
bootstrapApplication(AppComponent, appConfig);

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withComponentInputBinding()),
    provideHttpClient(withInterceptors([authInterceptor, erreurInterceptor])),
  ],
};

Syntaxe de template intégrée (v17, stable v18) qui remplace *ngIf, *ngFor et ngSwitch : plus lisible, typée, plus rapide et sans import.

@if (client(); as c) {
  <h2>{{ c.nom }}</h2>
} @else if (chargement()) {
  <p>Chargement…</p>
} @else {
  <p>Aucun client</p>
}

@switch (compte().statut) {
  @case ('ACTIF') { <span class="ok">Actif</span> }
  @case ('GELE')  { <span class="ko">Gelé</span> }
  @default        { <span>Inconnu</span> }
}

Expression obligatoire dans @for qui identifie chaque élément (souvent son id) : Angular ne recrée que les lignes réellement ajoutées, supprimées ou déplacées.

Sans identifiant, quand la liste est rechargée depuis l'API (nouveaux objets), Angular détruit et recrée tout le DOM de la liste. Avec track t.id, il réutilise les nœuds existants. trackBy est l'équivalent pour l'ancien *ngFor.

@for (t of transactions(); track t.id; let i = $index) {
  <li>{{ i + 1 }}. {{ t.libelle }} — {{ t.montant | number }}</li>
} @empty {
  <li>Aucune transaction</li>
}

Bloc optionnel de @for affiché quand la liste est vide ; remplace un @if séparé.

@for (b of beneficiaires(); track b.id) { <app-beneficiaire [b]="b" /> }
@empty { <p>Ajoutez votre premier bénéficiaire.</p> }

Bloc de template (v17, stable v18) dont le code est chargé à part (lazy) et affiché seulement quand un déclencheur survient : visibilité, interaction, inactivité, timer, condition.

Le composant lourd (graphique, éditeur) sort du bundle initial : la page s'affiche plus vite. @placeholder s'affiche avant le déclenchement, @loading pendant le chargement, @error en cas d'échec.

@defer (on viewport; prefetch on idle) {
  <app-graphique-depenses [donnees]="depenses()" />
} @placeholder (minimum 300ms) {
  <div class="squelette"></div>
} @loading (after 100ms) {
  <p>Chargement du graphique…</p>
} @error {
  <p>Graphique indisponible</p>
}

Un signal est un conteneur de valeur réactive : on le lit en l'appelant count(), on l'écrit avec set() ou update(), et Angular sait précisément quels templates en dépendent.

Contrairement à Zone.js qui revérifie tout l'arbre après chaque événement, Angular met à jour uniquement les vues qui lisent le signal modifié. Introduits en v16, stables depuis v17 (et l'essentiel de l'API réactive stable en v20).

export class PanierComponent {
  quantite = signal(1);
  articles = signal<Article[]>([]);

  ajouter(a: Article) {
    this.articles.update(liste => [...liste, a]);   // nouvelle référence (immutabilité)
  }
  reset() { this.quantite.set(1); }
}

<p>Quantité : {{ quantite() }}</p>

Signal dérivé, en lecture seule, recalculé automatiquement (et paresseusement, avec mémorisation) quand les signaux qu'il lit changent.

articles = signal<Article[]>([]);
total = computed(() => this.articles().reduce((s, a) => s + a.prix * a.qte, 0));
fraisLivraison = computed(() => this.total() > 50_000 ? 0 : 2_000);

Fonction exécutée à chaque fois qu'un signal qu'elle lit change ; sert aux effets de bord (log, localStorage, synchronisation avec une API non Angular).

constructor() {
  effect(() => {
    localStorage.setItem('filtre', JSON.stringify(this.filtre()));   // relu à chaque changement
  });
}

Signal modifiable dont la valeur est réinitialisée automatiquement quand une source change (v19, stable v20). Ex. : la sélection revient au premier élément quand la liste change.

comptes = input.required<Compte[]>();
compteSelectionne = linkedSignal(() => this.comptes()[0]);   // reset si la liste change
choisir(c: Compte) { this.compteSelectionne.set(c); }       // reste modifiable à la main

Versions « signal » de @Input, @Output et du two-way binding (stables depuis v19) : input() renvoie un signal en lecture seule, output() émet un événement, model() est un input modifiable par l'enfant.

export class FiltreComponent {
  options = input<string[]>([]);              // [options]="..."
  min = input.required<number>();             // obligatoire, vérifié à la compilation
  recherche = model('');                      // [(recherche)]="terme" côté parent
  valide = output<string>();                  // (valide)="onValide($event)"

  envoyer() { this.valide.emit(this.recherche()); }
}

<app-filtre [min]="0" [(recherche)]="terme" (valide)="charger($event)" />

API pour charger des données asynchrones sous forme de signaux (value, isLoading, error) qui se rechargent quand leurs paramètres changent. Déclarées prêtes pour la production en v22.

clientId = input.required<number>();
client = httpResource<Client>(() => `/api/v1/clients/${this.clientId()}`);  // rechargé si l'id change

@if (client.isLoading()) { <p>Chargement…</p> }
@else if (client.error()) { <p>Erreur</p> }
@else { <h2>{{ client.value()?.nom }}</h2> }

Bibliothèque qui « patche » les API asynchrones du navigateur (événements, setTimeout, XHR) pour prévenir Angular qu'il doit lancer la détection de changements.

Simple mais coûteux : à chaque clic ou timer, Angular revérifie potentiellement tout l'arbre de composants. Elle complique aussi les stack traces et pèse sur le bundle. Depuis v21, elle n'est plus incluse par défaut dans les nouveaux projets.

Mode sans Zone.js (stable depuis v20.2, défaut des nouveaux projets en v21) : la détection de changements est déclenchée par les signals, les événements du template, l'async pipe et markForCheck.

// projet existant (≤ v20) : activation explicite
bootstrapApplication(AppComponent, {
  providers: [provideZonelessChangeDetection()],
});

Nouvelle API de formulaires basée sur les signals : le modèle est un signal, form() construit l'arbre de champs et un schéma déclare les validations. Expérimentale en v21, stable en v22.

import { form, required, email, minLength, FormField } from '@angular/forms/signals';

@Component({
  imports: [FormField],
  template: `
    <input [formField]="inscription.nom" />
    <input [formField]="inscription.email" />
    @if (inscription.email().invalid()) { <small>Email invalide</small> }
  `,
})
export class InscriptionComponent {
  modele = signal({ nom: '', email: '' });
  inscription = form(this.modele, (p) => {
    required(p.nom); minLength(p.nom, 2);
    required(p.email); email(p.email);
  });
}

Depuis Angular 22, les nouvelles applications utilisent OnPush par défaut ; l'ancienne stratégie « Default » est renommée Eager.

Cela entérine la direction prise avec les signals : un composant ne se met à jour que si ses inputs changent, qu'un événement survient dans son template ou qu'un signal lu change.

Nouveau décorateur (v22) plus court pour un service singleton global, alternative à @Injectable({ providedIn: 'root' }).

@Service()
export class TauxService {
  private http = inject(HttpClient);
}
// équivalent historique :
@Injectable({ providedIn: 'root' }) export class TauxService2 {}

Fonction qui récupère une dépendance depuis l'injecteur courant, utilisable dans un champ, un constructeur, un guard ou un intercepteur fonctionnel.

export class ClientService {
  private http = inject(HttpClient);
  private config = inject(APP_CONFIG);
}
export const adminGuard: CanActivateFn = () => inject(AuthService).estAdmin();

Depuis Angular 21, les nouveaux projets utilisent Vitest à la place de Karma/Jasmine : exécution plus rapide, mode watch, API compatible Jest.

import { describe, it, expect } from 'vitest';
describe('total', () => {
  it('additionne les lignes', () => {
    expect(total([{ prix: 1000, qte: 2 }])).toBe(2000);
  });
});

Brique d'interface : une classe TypeScript (état + logique) associée à un template HTML et des styles, identifiée par un sélecteur.

@Component({
  selector: 'app-solde',                         // <app-solde />
  template: `<p>Solde : {{ solde() | number }} XOF</p>`,
  styles: `p { font-weight: 600 }`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class SoldeComponent {
  solde = input(0);
}

Ancien mécanisme de regroupement (declarations, imports, providers) ; remplacé par les composants standalone, mais encore présent dans beaucoup d'applications existantes.

@NgModule({
  declarations: [ListeComptesComponent],
  imports: [CommonModule, RouterModule.forChild(routes)],
})
export class ComptesModule {}

Affiche dans le template la valeur d'une expression du composant, convertie en texte et échappée (protection XSS).

<h1>Bonjour {{ utilisateur().prenom }}</h1>
<p>Frais : {{ montant() * 0.01 | number:'1.0-0' }} XOF</p>

[propriete]="expression" lie une propriété DOM ou un input de composant à une valeur du composant (sens composant → template).

<button [disabled]="enCours()">Valider</button>
<img [src]="avatarUrl()" [alt]="nom()" />
<app-graph [donnees]="serie()" />
<div [class.alerte]="solde() < 0" [style.width.%]="progression()"></div>

(evenement)="methode($event)" exécute du code du composant quand un événement DOM ou un output survient (sens template → composant).

<button (click)="valider()">Valider</button>
<input (keyup.enter)="chercher(saisie.value)" #saisie />
<app-carte (selectionne)="ouvrir($event)" />

[(x)]="valeur" combine property binding et event binding : la valeur circule dans les deux sens. ngModel l'applique aux champs de formulaire (template-driven).

<input [(ngModel)]="recherche" />          <!-- nécessite FormsModule -->
<app-filtre [(recherche)]="terme" />       <!-- avec un model() côté enfant -->

Classe qui ajoute un comportement à un élément existant : directive d'attribut (change l'apparence/le comportement) ou structurelle (ajoute/retire du DOM, ex. l'ancien *ngIf).

@Directive({ selector: '[appMontantNegatif]', host: { '[class.negatif]': 'valeur() < 0' } })
export class MontantNegatifDirective {
  valeur = input.required<number>({ alias: 'appMontantNegatif' });
}

<span [appMontantNegatif]="solde()">{{ solde() }}</span>

Fonction de transformation utilisée dans le template avec | (date, currency, number, uppercase…) ; on peut créer les siens. « Pure » par défaut : recalculée seulement si l'entrée change.

@Pipe({ name: 'iban' })
export class IbanPipe implements PipeTransform {
  transform(v: string): string { return v.replace(/(.{4})/g, '$1 ').trim(); }   // groupes de 4
}

{{ compte.iban | iban }} · {{ compte.ouverture | date:'dd/MM/yyyy' }} · {{ solde | currency:'XOF':'symbol':'1.0-0' }}

Décorateur (API classique) qui expose une propriété d'un composant enfant pour recevoir une valeur du parent ; required: true (v16) la rend obligatoire.

export class CardComponent {
  @Input({ required: true }) user!: User;
  @Input() compact = false;
}

@Output expose un événement que l'enfant émet vers le parent via un EventEmitter ; le parent l'écoute avec (nomEvenement).

export class CardComponent {
  @Output() selected = new EventEmitter<User>();
  select(u: User) { this.selected.emit(u); }
}

<app-card [user]="u" (selected)="onUserSelected($event)" />

Permet au parent d'insérer son propre HTML à l'intérieur d'un composant enfant (comme un « slot »), éventuellement à plusieurs emplacements via select.

@Component({
  selector: 'app-panneau',
  template: `
    <header><ng-content select="[titre]" /></header>
    <section><ng-content /></section>`,
})
export class PanneauComponent {}

<app-panneau>
  <h3 titre>Mes comptes</h3>
  <app-liste-comptes />
</app-panneau>

Donne au composant une référence vers un élément ou un composant enfant de son template ; disponible à partir de ngAfterViewInit (ou via le signal viewChild()).

export class RechercheComponent {
  champ = viewChild.required<ElementRef<HTMLInputElement>>('saisie');
  focus() { this.champ().nativeElement.focus(); }
}

<input #saisie />

Méthodes qu'Angular appelle à des moments précis de la vie d'un composant : création, changement d'inputs, rendu, destruction.

Ordre : constructor → ngOnChanges → ngOnInit → ngDoCheck → ngAfterContentInit → ngAfterContentChecked → ngAfterViewInit → ngAfterViewChecked → … → ngOnDestroy. Avec les signals, on en utilise de moins en moins (computed/effect/DestroyRef remplacent beaucoup de cas).

Appelé à la création de la classe : sert uniquement à l'injection de dépendances ; les inputs ne sont pas encore disponibles.

constructor(private service: ClientService) {}   // ✅ DI
// ❌ ne pas appeler l'API ici : les @Input ne sont pas encore renseignés

Appelé avant ngOnInit puis à chaque fois qu'un @Input change de référence ; reçoit un objet SimpleChanges (valeur précédente / actuelle).

ngOnChanges(changes: SimpleChanges) {
  if (changes['compteId'] && !changes['compteId'].firstChange) {
    this.chargerTransactions(changes['compteId'].currentValue);
  }
}

Appelé une fois, après le premier ngOnChanges : les inputs sont disponibles. C'est l'endroit pour charger les données initiales et s'abonner aux services.

export class ListeComptesComponent implements OnInit {
  private service = inject(CompteService);
  comptes = signal<Compte[]>([]);
  ngOnInit() {
    this.service.lister().subscribe(c => this.comptes.set(c));
  }
}

Appelé à chaque cycle de détection de changements ; permet une détection personnalisée. Très fréquent, donc à éviter ou garder ultra léger.

Appelé une fois après que le contenu projeté (ng-content) a été initialisé ; @ContentChild est alors disponible.

Appelé une fois après le rendu de la vue du composant et de ses enfants : les @ViewChild sont disponibles, on peut manipuler le DOM (initialiser un graphique, un focus).

@ViewChild('canvas') canvas!: ElementRef<HTMLCanvasElement>;
ngAfterViewInit() { this.chart = new Chart(this.canvas.nativeElement, this.config); }

Appelé juste avant la destruction du composant : on y libère les ressources (désabonnements, timers, listeners globaux) pour éviter les fuites mémoire.

private sub?: Subscription;
private timer?: number;
ngOnInit() {
  this.sub = this.flux.subscribe(…);
  this.timer = window.setInterval(() => this.rafraichir(), 30_000);
}
ngOnDestroy() {
  this.sub?.unsubscribe();
  clearInterval(this.timer);
}

Opérateur RxJS (v16, @angular/core/rxjs-interop) qui se désabonne automatiquement à la destruction du composant ; plus besoin de ngOnDestroy pour les abonnements.

export class NotificationsComponent {
  constructor() {
    inject(NotificationService).flux$
      .pipe(takeUntilDestroyed())                // dans un contexte d'injection
      .subscribe(n => this.afficher(n));
  }
}

Un abonnement, un interval ou un listener jamais libéré continue de vivre après la destruction du composant : mémoire qui grimpe et traitements fantômes.

Les observables HTTP se terminent seuls (une valeur puis complete), mais pas les flux infinis : interval, fromEvent, WebSocket, Subjects de service, valueChanges des formulaires. Remèdes : async pipe, takeUntilDestroyed, toSignal, ou ngOnDestroy.

Formulaires définis dans le TypeScript : un FormGroup regroupe des FormControl avec valeur, validateurs et état (valid, dirty, touched) ; le template s'y relie par formControlName.

Avantages : typés (depuis v14), testables sans DOM, adaptés aux formulaires complexes et dynamiques (FormArray pour une liste de bénéficiaires…).

form = new FormGroup({
  nom: new FormControl('', { nonNullable: true, validators: [Validators.required] }),
  montant: new FormControl<number | null>(null, [Validators.required, Validators.min(100)]),
});

<form [formGroup]="form" (ngSubmit)="valider()">
  <input formControlName="nom" />
  <input formControlName="montant" type="number" />
  <button [disabled]="form.invalid">Envoyer</button>
</form>

Service qui raccourcit la création des formulaires réactifs ; NonNullableFormBuilder évite que reset() remette les valeurs à null.

private fb = inject(NonNullableFormBuilder);
form = this.fb.group({
  name:  ['', [Validators.required, Validators.minLength(2)]],
  email: ['', [Validators.required, Validators.email]],
  age:   [18, [Validators.min(18)]],
});

Fonctions de validation fournies par Angular : required, min, max, minLength, maxLength, email, pattern. Chaque erreur apparaît dans control.errors.

@if (form.controls.email.hasError('email') && form.controls.email.touched) {
  <small>Adresse email invalide</small>
}

Fonction qui reçoit un contrôle et renvoie null (valide) ou un objet d'erreur ; peut aussi porter sur un groupe (ex. confirmation de mot de passe).

export const telephoneSenegal: ValidatorFn = (c) =>
  /^(\+221)?7[05678]\d{7}$/.test(c.value ?? '') ? null : { telephone: true };

export const memesMotsDePasse: ValidatorFn = (g) =>
  g.get('mdp')?.value === g.get('confirmation')?.value ? null : { differents: true };

Formulaires définis dans le HTML avec ngModel et des attributs de validation (required, minlength) ; simples pour un petit formulaire, moins testables et moins typés.

<form #f="ngForm" (ngSubmit)="envoyer(f.value)">
  <input name="email" [(ngModel)]="email" required email />
  <button [disabled]="f.invalid">OK</button>
</form>

form.value exclut les champs désactivés ; form.getRawValue() renvoie toutes les valeurs, y compris désactivées, avec un type complet.

this.form.controls.iban.disable();
this.form.value;          // { nom: 'Awa' }            (iban absent)
this.form.getRawValue();  // { nom: 'Awa', iban: 'SN…' }

Classe qui porte la logique réutilisable (appels HTTP, état partagé) ; @Injectable({ providedIn: 'root' }) en fait un singleton disponible dans toute l'application.

@Injectable({ providedIn: 'root' })
export class ClientService {
  private http = inject(HttpClient);
  lister() { return this.http.get<ClientDto[]>('/api/v1/clients'); }
}

Angular résout les dépendances en remontant une hiérarchie d'injecteurs (élément → composant parent → route → racine) ; un provider déclaré sur un composant donne une instance propre à ce composant et ses enfants.

@Component({
  selector: 'app-assistant-virement',
  providers: [EtatVirementService],     // nouvelle instance par assistant ouvert
})
export class AssistantVirementComponent {}

Service Angular pour les appels HTTP ; renvoie des Observables typés, parse le JSON et passe par les intercepteurs.

create(data: CreateClientRequest): Observable<ClientDto> {
  return this.http.post<ClientDto>('/api/v1/clients', data);
}
search(ville: string) {
  return this.http.get<Page<ClientDto>>('/api/v1/clients', { params: { ville, page: 0, size: 20 } });
}

Fonction qui intercepte chaque requête/réponse HttpClient pour un traitement transversal : ajout du token, gestion globale des erreurs, loader, journalisation.

Les requêtes sont immuables : on les clone() pour les modifier.

export const erreurInterceptor: HttpInterceptorFn = (req, next) => {
  const router = inject(Router);
  return next(req).pipe(
    catchError((err: HttpErrorResponse) => {
      if (err.status === 401) router.navigate(['/login']);
      return throwError(() => err);
    })
  );
};
// enregistrement : provideHttpClient(withInterceptors([authInterceptor, erreurInterceptor]))

Le routeur associe des URL à des composants, affichés dans <router-outlet> ; routerLink navigue sans recharger la page.

export const routes: Routes = [
  { path: '', redirectTo: 'comptes', pathMatch: 'full' },
  { path: 'comptes', component: ListeComptesComponent },
  { path: 'comptes/:id', component: DetailCompteComponent },   // id lu via input() avec withComponentInputBinding
  { path: '**', component: PageIntrouvableComponent },
];

Chargement à la demande du code d'une route (loadComponent / loadChildren) : le bundle initial est plus petit, la première page s'affiche plus vite.

{ path: 'admin', loadChildren: () => import('./admin/admin.routes').then(m => m.ADMIN_ROUTES) },
{ path: 'rapports', loadComponent: () => import('./rapports/rapports.component').then(m => m.RapportsComponent) },

Fonction exécutée avant d'activer une route pour l'autoriser ou rediriger (connexion, rôle, modifications non sauvegardées).

export const authGuard: CanActivateFn = () => {
  const auth = inject(AuthService);
  return auth.estConnecte() ? true : inject(Router).createUrlTree(['/login']);
};
{ path: 'virements', canActivate: [authGuard], loadComponent: … }

Fichiers de configuration remplacés au build selon la cible (dev/prod) : URL de l'API, options. Ils finissent dans le bundle public.

// src/environments/environment.prod.ts
export const environment = { production: true, apiUrl: 'https://api.banque.sn' };

Flux de valeurs asynchrones (0, 1 ou plusieurs) qui ne démarre qu'à l'abonnement et peut se terminer (complete) ou échouer (error).

const tic$ = new Observable<number>(observer => {
  let i = 0;
  const id = setInterval(() => observer.next(i++), 1000);
  return () => clearInterval(id);         // nettoyage à l'unsubscribe
});
const sub = tic$.subscribe({ next: v => console.log(v), error: e => console.error(e) });
sub.unsubscribe();

subscribe() démarre l'Observable et fournit les callbacks next/error/complete ; il renvoie une Subscription dont unsubscribe() arrête le flux.

Une Promise produit une seule valeur, démarre immédiatement et ne s'annule pas ; un Observable peut produire plusieurs valeurs, est paresseux, annulable et composable avec des opérateurs.

const p = fetch('/api/taux');                  // la requête part TOUT DE SUITE
const o$ = this.http.get('/api/taux');         // rien ne part…
const sub = o$.subscribe();                    // …jusqu'ici
sub.unsubscribe();                             // annule la requête HTTP en cours
const valeur = await firstValueFrom(o$);       // conversion vers Promise si besoin

Froid : chaque abonné déclenche sa propre exécution (ex. requête HTTP rejouée à chaque subscribe). Chaud : la source émet indépendamment des abonnés, qui partagent les mêmes valeurs (événements, Subject).

Un Subject est à la fois Observable et émetteur (next) : il diffuse à tous ses abonnés. BehaviorSubject garde la dernière valeur et la donne immédiatement à tout nouvel abonné.

@Injectable({ providedIn: 'root' })
export class SessionService {
  private utilisateur = new BehaviorSubject<Utilisateur | null>(null);
  utilisateur$ = this.utilisateur.asObservable();        // lecture seule à l'extérieur
  connecter(u: Utilisateur) { this.utilisateur.next(u); }
}

pipe() chaîne des opérateurs (fonctions pures) qui transforment un Observable en un autre : map, filter, switchMap, catchError…

this.clients$ = this.http.get<ClientDto[]>('/api/v1/clients').pipe(
  map(liste => liste.filter(c => c.actif)),
  tap(liste => console.log(liste.length, 'clients actifs')),
  catchError(() => of([]))
);

map transforme chaque valeur ; filter laisse passer celles qui respectent une condition ; tap exécute un effet de bord (log) sans changer la valeur.

montants$.pipe(
  filter(m => m > 0),
  map(m => Math.round(m * 1.01)),
  tap(m => console.debug('montant avec frais', m))
);

Pour chaque valeur, lance un nouvel Observable et annule le précédent s'il n'est pas terminé : « la dernière demande gagne ». Idéal pour l'autocomplétion et les changements de paramètres de route.

resultats$ = this.recherche.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(terme => this.api.chercher(terme))     // annule la requête précédente
);

Lance un Observable interne pour chaque valeur et les exécute tous en parallèle, sans annuler ; l'ordre des résultats n'est pas garanti.

from(fichiers).pipe(
  mergeMap(f => this.upload(f), 3)    // 3 envois simultanés au maximum
).subscribe();

Traite les Observables internes l'un après l'autre, dans l'ordre : le suivant ne démarre que lorsque le précédent est terminé.

from(operations).pipe(
  concatMap(op => this.http.post('/api/v1/operations', op))   // ordre garanti
).subscribe();

Ignore les nouvelles valeurs tant que l'Observable interne en cours n'est pas terminé. Parfait contre le double clic sur « Payer ».

this.clicPayer$.pipe(
  exhaustMap(() => this.paiement.payer(this.panier()))   // les clics pendant l'appel sont ignorés
).subscribe();

Combine plusieurs Observables et émet un tableau des dernières valeurs dès que l'un d'eux émet (après que tous ont émis au moins une fois).

vue$ = combineLatest([this.filtre$, this.tri$, this.page$]).pipe(
  switchMap(([filtre, tri, page]) => this.api.lister({ filtre, tri, page }))
);

Lance plusieurs Observables en parallèle et émet une seule fois, quand tous sont terminés, avec leurs dernières valeurs (l'équivalent de Promise.all).

forkJoin({
  client: this.api.client(id),
  comptes: this.api.comptes(id),
  cartes: this.api.cartes(id),
}).subscribe(({ client, comptes, cartes }) => this.initialiser(client, comptes, cartes));

debounceTime attend un silence (ex. 300 ms) avant d'émettre la dernière valeur ; distinctUntilChanged ignore une valeur identique à la précédente. Ensemble, ils évitent des appels inutiles pendant la frappe.

catchError intercepte une erreur pour renvoyer une valeur de repli ou relancer une erreur enrichie ; retry réessaie l'Observable source un certain nombre de fois.

this.http.get<Taux>('/api/taux').pipe(
  retry({ count: 2, delay: 500 }),
  catchError((err: HttpErrorResponse) => {
    this.toast.erreur('Taux indisponible');
    return of(TAUX_PAR_DEFAUT);
  })
);

Partage une seule exécution entre tous les abonnés et rejoue les N dernières valeurs aux nouveaux venus ; sert de cache simple dans un service.

@Injectable({ providedIn: 'root' })
export class ReferentielService {
  devises$ = inject(HttpClient).get<string[]>('/api/v1/devises').pipe(
    shareReplay({ bufferSize: 1, refCount: false })     // 1 seul appel HTTP pour toute l'app
  );
}

Pipe de template qui s'abonne à un Observable (ou une Promise), affiche sa dernière valeur et se désabonne automatiquement à la destruction.

@if (clients$ | async; as clients) {
  @for (c of clients; track c.id) { <li>{{ c.nom }}</li> }
}

Ponts entre RxJS et les signals (@angular/core/rxjs-interop) : toSignal s'abonne et expose la dernière valeur comme signal (désabonnement automatique) ; toObservable fait l'inverse.

clients = toSignal(this.service.lister(), { initialValue: [] });
terme = signal('');
resultats = toSignal(
  toObservable(this.terme).pipe(debounceTime(300), switchMap(t => this.api.chercher(t))),
  { initialValue: [] }
);

Mécanisme qui compare l'état des composants à ce qui est affiché et met à jour le DOM. Historiquement déclenché par Zone.js sur tout l'arbre ; aujourd'hui de plus en plus ciblé grâce aux signals.

Stratégie où un composant n'est revérifié que si une de ses références d'input change, qu'un événement survient dans son template, qu'un signal lu change ou que l'async pipe émet. Défaut des nouveaux projets en v22.

@Component({ changeDetection: ChangeDetectionStrategy.OnPush, … })
export class ListeComponent {
  items = input<Item[]>([]);
}
// parent : this.items = [...this.items, nouvel];   ✅ nouvelle référence
//          this.items.push(nouvel);                 ❌ même référence : l'enfant OnPush ne bouge pas

Le Server-Side Rendering génère le HTML côté serveur (affichage rapide, SEO) ; l'hydratation réutilise ensuite ce DOM côté navigateur au lieu de le reconstruire. L'hydratation incrémentale (avec @defer) n'active que les parties nécessaires.

ng new banque-public --ssr

provideClientHydration(withIncrementalHydration())

Seuils définis dans angular.json : le build avertit ou échoue si le JavaScript initial dépasse une taille donnée. Garde-fou contre l'alourdissement progressif.

"budgets": [{ "type": "initial", "maximumWarning": "500kB", "maximumError": "1MB" }]

Sur-ensemble typé de JavaScript : les types sont vérifiés à la compilation puis effacés ; le navigateur exécute du JavaScript.

Les types n'existent pas à l'exécution : une réponse HTTP typée ClientDto n'est pas vérifiée. Si le backend renvoie autre chose, TypeScript ne le verra pas (valider avec Zod si nécessaire).

function frais(montant: number, taux = 0.01): number { return Math.round(montant * taux); }
frais('1000');   // ❌ erreur de compilation

Les deux décrivent la forme d'un objet. interface peut être étendue et fusionnée (declaration merging) ; type permet en plus unions, intersections, tuples et types calculés.

interface Client { id: number; nom: string; }
interface ClientVip extends Client { conseiller: string; }

type Statut = 'ACTIF' | 'GELE' | 'CLOTURE';              // union : impossible avec interface
type CompteDetaille = Compte & { transactions: Transaction[] };   // intersection

Types paramétrés (<T>) qui rendent une fonction ou une classe réutilisable pour plusieurs types tout en gardant le typage.

interface Page<T> { content: T[]; totalElements: number; number: number; }

function premier<T>(liste: T[]): T | undefined { return liste[0]; }
const c = premier<Client>(clients);       // c : Client | undefined

keyof T donne l'union des clés d'un type ; K extends keyof T contraint un paramètre générique à être une clé valide.

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] { return obj[key]; }
getProperty(client, 'nom');      // string
getProperty(client, 'adresse');  // ❌ erreur : 'adresse' n'est pas une clé de Client

Types utilitaires intégrés qui dérivent un nouveau type d'un existant : tout optionnel, tout requis, lecture seule, sous-ensemble, exclusion, dictionnaire.

interface Client { id: number; nom: string; email: string; telephone?: string; }

type MajClient   = Partial<Omit<Client, 'id'>>;      // PATCH : tout optionnel sauf id exclu
type ClientCree  = Required<Client>;                 // telephone devient obligatoire
type ClientLu    = Readonly<Client>;                 // aucune propriété modifiable
type Resume      = Pick<Client, 'id' | 'nom'>;       // { id; nom }
type SoldesParDevise = Record<'XOF' | 'EUR', number>; // { XOF: number; EUR: number }

Un type union A | B accepte l'une ou l'autre forme ; combiné à des littéraux ('ACTIF' | 'GELE'), il remplace avantageusement les chaînes libres.

type Devise = 'XOF' | 'EUR' | 'USD';
function convertir(m: number, d: Devise) { … }
convertir(100, 'GBP');   // ❌ refusé à la compilation

Union d'objets qui partagent une propriété littérale commune (le discriminant) ; TypeScript en déduit automatiquement le type exact dans chaque branche.

type Result<T> =
  | { success: true; data: T }
  | { success: false; error: string };

function afficher(r: Result<Client>) {
  if (r.success) console.log(r.data.nom);   // ici TS sait que data existe
  else console.error(r.error);              // et ici que error existe
}

Le narrowing affine un type dans une branche (typeof, instanceof, in, ===) ; un type guard est une fonction x is T qui enseigne un test personnalisé au compilateur.

function estErreurApi(e: unknown): e is { code: string; message: string } {
  return typeof e === 'object' && e !== null && 'code' in e;
}
if (estErreurApi(err)) console.log(err.code);    // err est typé

any désactive toute vérification (à bannir) ; unknown accepte n'importe quelle valeur mais oblige à vérifier son type avant de l'utiliser.

const a: any = JSON.parse(texte);   a.foo.bar();          // compile, plante à l'exécution
const u: unknown = JSON.parse(texte);
u.foo;                                                    // ❌ erreur : il faut d'abord affiner
if (typeof u === 'object' && u && 'foo' in u) { … }

a?.b renvoie undefined au lieu de planter si a est null/undefined ; x ?? defaut remplace seulement null/undefined (contrairement à || qui remplace aussi 0 et '').

const ville = client?.adresse?.ville ?? 'Non renseignée';
const remise = saisie ?? 0;        // 0 saisi reste 0 (avec || il deviendrait la valeur par défaut)

valeur! dit au compilateur « je garantis que ce n'est pas null » ; champ!: Type dit qu'un champ sera initialisé plus tard (ex. un @Input). À utiliser avec parcimonie : aucun contrôle à l'exécution.

@Input({ required: true }) user!: User;          // initialisé par Angular
const el = document.getElementById('total')!;   // risqué si l'élément n'existe pas

Ensemble d'options du compilateur (strictNullChecks, noImplicitAny…) qui interdit les approximations ; activé par défaut dans les projets Angular récents.

{ "compilerOptions": { "strict": true, "noUncheckedIndexedAccess": true } }

Fonctions préfixées par @ qui ajoutent des métadonnées à une classe ou un membre ; Angular s'en sert pour déclarer composants, directives, services et inputs.

@Component({ selector: 'app-x', template: '' })   // métadonnées lues par le compilateur Angular
export class XComponent {}

Application déployée comme un seul artefact (un JAR, une base) qui contient toutes les fonctionnalités. Simple à développer, tester et déployer au départ.

Le monolithe n'est pas un défaut : transactions ACID locales, appels en mémoire (nanosecondes), un seul pipeline. Il devient problématique quand il est mal structuré (« big ball of mud ») ou quand des équipes nombreuses se bloquent mutuellement sur le même code et le même déploiement.

Un seul déployable, mais découpé en modules métier aux frontières strictes (API publiques, pas d'accès direct aux tables des autres). Souvent le meilleur point de départ.

On obtient l'essentiel de la clarté des microservices sans leur complexité opérationnelle, et l'on peut extraire un module en service plus tard. Spring Modulith vérifie ces frontières par des tests.

// Test qui échoue si un module accède aux classes internes d'un autre
class ArchitectureTest {
    @Test void verifierModules() { ApplicationModules.of(BanqueApplication.class).verify(); }
}

Service autonome, centré sur une capacité métier, avec sa propre base de données, déployable et scalable indépendamment, qui communique par le réseau (HTTP, messages).

Bénéfices : déploiements indépendants, équipes autonomes, scalabilité ciblée, choix technologiques locaux. Coûts : réseau non fiable, cohérence à terme, observabilité distribuée, tests plus complexes, infrastructure (Kubernetes, CI/CD par service).

Frontière à l'intérieur de laquelle un modèle métier et son vocabulaire ont un sens précis ; c'est la bonne unité pour découper des microservices.

Le mot « Client » n'a pas le même sens pour le service KYC (identité, pièces justificatives) que pour le service Crédit (scoring, capacité de remboursement). Chaque contexte a son propre modèle ; ils communiquent par des contrats explicites.

Chaque microservice possède sa base et est le seul à y accéder ; les autres passent par son API ou ses événements.

Une base partagée recrée un couplage fort (un changement de schéma casse plusieurs services). Le prix : plus de jointure SQL entre services, il faut composer les données via API ou répliquer par événements.

« Les organisations produisent des systèmes dont la structure reproduit leurs structures de communication. » Le découpage technique suit le découpage des équipes.

Conséquence pratique (« Inverse Conway Maneuver ») : on organise les équipes selon les domaines métier que l'on veut voir apparaître dans l'architecture.

Migrer un système legacy pièce par pièce : une façade (gateway) route certaines URL vers le nouveau service, le reste vers l'ancien, jusqu'à extinction de l'ancien.

routes:
  - id: virements-nouveau
    uri: http://virements-service:8080
    predicates: [ Path=/api/virements/** ]     # déjà migré
  - id: legacy
    uri: http://core-banking-legacy:8080
    predicates: [ Path=/** ]                    # tout le reste

Synchrone : l'appelant attend la réponse (REST, gRPC) ; asynchrone : il publie un message ou un événement et continue (Kafka, RabbitMQ).

Point d'entrée unique devant les microservices : routage, authentification, rate limiting, CORS, agrégation, terminaison TLS.

Le front Angular parle à une seule URL ; la gateway redirige vers le bon service. Outils : Spring Cloud Gateway, Kong, NGINX, AWS API Gateway.

Mécanisme qui permet à un service de trouver l'adresse réseau des instances d'un autre service, qui changent en permanence (scaling, redémarrages).

Sur Kubernetes, c'est natif : un Service k8s a un nom DNS stable (http://comptes-service:8080). Hors Kubernetes : Eureka, Consul.

Externaliser la configuration de tous les services dans un dépôt central (Git, Vault, ConfigMaps) pour la modifier sans reconstruire les images.

spring:
  config:
    import: "configserver:http://config:8888"   # Spring Cloud Config

Couche d'infrastructure (un proxy « sidecar » à côté de chaque service) qui gère le trafic réseau : mTLS, retries, timeouts, routage canary, métriques — sans toucher au code.

Utile à grande échelle (dizaines de services) ; ajoute de la complexité et de la latence pour une petite équipe.

Huit hypothèses fausses que l'on fait souvent : le réseau est fiable, la latence est nulle, la bande passante infinie, le réseau sûr, la topologie fixe, un seul administrateur, transport gratuit, réseau homogène.

Chaque appel réseau peut échouer, être lent ou réussir sans que l'appelant le sache : d'où timeouts, retries, idempotence et circuit breakers.

Opération qui modifie des données dans plusieurs services ou bases et devrait être « tout ou rien ». Sans base commune, il n'y a plus de transaction ACID unique.

Exemple : commande → réservation de stock (service Stock) → paiement (service Paiement) → expédition. Solutions : SAGA (cohérence à terme) plutôt que 2PC.

Protocole où un coordinateur demande à tous les participants de se préparer (phase 1) puis de valider (phase 2). Garantit l'atomicité mais bloque les ressources et dépend du coordinateur.

Peu adapté aux microservices : verrous longs, faible disponibilité, peu supporté par les brokers et bases NoSQL. On lui préfère les SAGA.

Les données des différents services finissent par être cohérentes, mais pas instantanément : pendant un court laps de temps, deux vues peuvent diverger.

L'interface doit l'assumer : « Virement en cours de traitement » plutôt qu'un solde faux. On le paie en simplicité, on le gagne en disponibilité et en découplage (théorème CAP).

Suite de transactions locales, une par service ; si une étape échoue, on exécute des transactions de compensation pour annuler les étapes précédentes.

Commande créée → Stock réservé → Paiement débité → ✅ Commande confirmée
                               ↘ Paiement refusé → compensation : libérer le stock → Commande annulée

Style de SAGA sans chef : chaque service réagit aux événements des autres et publie les siens. Couplage faible, mais flux global difficile à visualiser et à déboguer.

@KafkaListener(topics = "stock.reserve")
public void onStockReserve(StockReserve evt) {
    var resultat = paiementService.debiter(evt.commandeId(), evt.montant());
    kafka.send(resultat.ok() ? "paiement.accepte" : "paiement.refuse", evt.commandeId(), resultat);
}

Style de SAGA où un orchestrateur central envoie les commandes à chaque service, attend les réponses et déclenche les compensations. Flux explicite et traçable, au prix d'un composant central.

Outils : un service dédié avec une machine à états, Camunda/Zeebe (BPMN), Temporal.

public void executer(Commande c) {
    stock.reserver(c);
    try { paiement.debiter(c); }
    catch (PaiementRefuseException e) { stock.liberer(c); commande.annuler(c); return; }
    commande.confirmer(c);
}

Opération métier qui annule l'effet d'une étape déjà validée (rembourser, libérer un stock) ; ce n'est pas un rollback technique, l'étape a bien eu lieu.

Écrire l'événement à publier dans une table « outbox » dans la même transaction que la donnée métier ; un relais le publie ensuite sur Kafka. Évite de modifier la base sans publier (ou l'inverse).

Le problème : repo.save() puis kafka.send() n'est pas atomique. Si Kafka est indisponible après le commit, l'événement est perdu. Avec l'outbox, les deux écritures sont dans la même transaction SQL ; un processus (ou Debezium par CDC) lit la table et publie.

@Transactional
public void creerVirement(Virement v) {
    virementRepo.save(v);
    outboxRepo.save(new OutboxEvent("virement.cree", v.id(), json(v)));   // même transaction
}
// Relais : @Scheduled qui lit les lignes non publiées, envoie à Kafka, marque "publié"

Séparer le modèle d'écriture (commandes, règles métier) du modèle de lecture (requêtes, vues optimisées), éventuellement avec des bases différentes synchronisées par événements.

Utile quand les besoins de lecture (tableaux de bord, recherches multicritères) divergent fortement de l'écriture. Prix : deux modèles, synchronisation, cohérence à terme.

// Écriture : agrégat avec règles métier
commandHandler.handle(new EffectuerVirement(source, dest, montant));
// Lecture : vue dénormalisée, alimentée par les événements, interrogée directement
List<ReleveLigne> releve = releveQueryRepo.findByCompteOrderByDateDesc(compte);

Stocker la suite des événements (CompteOuvert, Crédité, Débité…) au lieu de l'état courant ; l'état est reconstruit en rejouant les événements.

Avantages : historique complet et audit naturel, possibilité de reconstruire n'importe quel état passé, nouvelles projections à partir de l'historique. Inconvénients : complexité, évolution des schémas d'événements, besoin de snapshots.

BigDecimal solde = evenements.stream().map(e -> switch (e) {
    case Credite c -> c.montant();
    case Debite d  -> d.montant().negate();
    default        -> BigDecimal.ZERO;
}).reduce(BigDecimal.ZERO, BigDecimal::add);

Fait métier passé et immuable, nommé au passé (VirementEffectué), publié pour que d'autres parties du système réagissent.

public record VirementEffectue(UUID id, String source, String dest, BigDecimal montant, Instant date) {}

Un service lent ou en panne bloque les threads de ses appelants, qui deviennent lents à leur tour, jusqu'à faire tomber tout le système.

Remèdes : timeouts courts, circuit breaker, bulkhead, dégradation gracieuse.

Durée maximale d'attente d'un appel réseau ; sans timeout, un service lent peut bloquer indéfiniment les threads de l'appelant.

var factory = new SimpleClientHttpRequestFactory();
factory.setConnectTimeout(Duration.ofSeconds(2));
factory.setReadTimeout(Duration.ofSeconds(3));
RestClient client = RestClient.builder().requestFactory(factory).build();

Réessayer automatiquement un appel en échec transitoire, en espaçant les tentatives de plus en plus (100 ms, 200 ms, 400 ms…) pour ne pas surcharger le service qui récupère.

Ne réessayer que les erreurs transitoires (timeout, 503) et les opérations idempotentes. Limiter le nombre de tentatives (3).

resilience4j.retry.instances.operateur:
  max-attempts: 3
  wait-duration: 200ms
  enable-exponential-backoff: true
  exponential-backoff-multiplier: 2
  retry-exceptions: [ java.io.IOException, java.util.concurrent.TimeoutException ]

Petite part aléatoire ajoutée aux délais (retries, TTL de cache) pour que des milliers de clients ne réessaient pas tous au même instant (effet « troupeau »).

délai = base × 2^tentative + aléatoire(0..100 ms)

Disjoncteur logiciel : après trop d'échecs, il « s'ouvre » et rejette immédiatement les appels vers le service défaillant pendant un temps, puis teste prudemment son rétablissement.

États : Closed (normal, échecs comptés) → Open (seuil dépassé, appels rejetés directement, fallback) → Half-Open (après un délai, quelques appels de test ; succès → Closed, échec → Open).

@CircuitBreaker(name = "operateur", fallbackMethod = "statutInconnu")
public StatutPaiement statut(String ref) { return operateurClient.statut(ref); }

private StatutPaiement statutInconnu(String ref, Throwable t) {
    return StatutPaiement.A_VERIFIER;     // dégradation gracieuse
}

resilience4j.circuitbreaker.instances.operateur:
  sliding-window-size: 20
  failure-rate-threshold: 50          # % d'échecs pour ouvrir
  wait-duration-in-open-state: 30s
  permitted-number-of-calls-in-half-open-state: 3

Les trois états d'un circuit breaker : fermé (le courant passe, appels normaux), ouvert (appels coupés), semi-ouvert (quelques appels de test).

Bibliothèque Java légère de résilience : CircuitBreaker, Retry, RateLimiter, Bulkhead, TimeLimiter, intégrée à Spring Boot par annotations et propriétés.

<dependency>
  <groupId>io.github.resilience4j</groupId>
  <artifactId>resilience4j-spring-boot3</artifactId>
</dependency>

Réponse de repli quand une dépendance échoue (valeur en cache, valeur par défaut, fonctionnalité masquée) pour que le service reste utilisable.

Exemple : si le service de recommandations tombe, la page d'accueil s'affiche sans le bloc recommandations plutôt qu'avec une erreur 500.

Isoler les ressources (pools de threads, connexions) par dépendance pour qu'un service lent n'épuise pas toutes les ressources de l'appelant, comme les cloisons étanches d'un navire.

@Bulkhead(name = "rapports", type = Bulkhead.Type.SEMAPHORE)   // max N appels simultanés
public Rapport generer() { … }

Limiter le nombre de requêtes acceptées par unité de temps (par client, par IP, par API key) pour protéger un service et assurer l'équité.

Algorithmes : token bucket, fenêtre glissante. Réponse au dépassement : 429 Too Many Requests avec Retry-After.

resilience4j.ratelimiter.instances.otp:
  limit-for-period: 5          # 5 envois d'OTP…
  limit-refresh-period: 1m     # …par minute

Une opération est idempotente si l'exécuter plusieurs fois produit le même effet qu'une seule fois. Indispensable dès qu'il y a des retries ou une livraison « au moins une fois ».

SET solde = 1000 est idempotent ; solde = solde - 100 ne l'est pas. Pour rendre un traitement idempotent : clé d'idempotence, contrainte d'unicité en base, table des messages déjà traités.

@Transactional
public void traiter(PaiementRecu evt) {
    if (dejaTraiteRepo.existsById(evt.id())) return;         // doublon ignoré
    compteService.crediter(evt.compte(), evt.montant());
    dejaTraiteRepo.save(new MessageTraite(evt.id()));        // + contrainte UNIQUE
}

En-tête HTTP contenant un identifiant unique généré par le client pour une opération ; le serveur mémorise la réponse associée et la renvoie telle quelle si la requête est rejouée.

POST /api/v1/paiements
Idempotency-Key: 7c1f6c3e-2b8d-4f6a-9a51-0f2d6e1b9c44

{"compte": "SN01…", "montant": 25000}

@PostMapping("/paiements")
ResponseEntity<PaiementDto> payer(@RequestHeader("Idempotency-Key") UUID cle, @Valid @RequestBody PaiementRequest r) {
    return idempotence.executerUneFois(cle, () -> service.payer(r));  // stocke clé + réponse (Redis/DB)
}

Le domaine métier est au centre et ne dépend d'aucune technologie ; il définit des ports (interfaces) que des adaptateurs (HTTP, JPA, Kafka) implémentent. Toutes les dépendances pointent vers l'intérieur.

On peut tester le métier sans base ni serveur, et changer de technologie (PostgreSQL → MongoDB, REST → Kafka) en ne remplaçant qu'un adaptateur.

[REST Controller] ─► (port entrant: EffectuerVirement) ─► [DOMAINE] ─► (port sortant: ComptePort) ◄─ [JpaCompteAdapter]

Interface définie par le domaine : port entrant = ce que l'application offre (cas d'usage) ; port sortant = ce dont le domaine a besoin (persistance, notifications).

public interface EffectuerVirement { VirementId executer(DemandeVirement d); }   // port entrant
public interface ComptePort { Compte charger(Iban iban); void sauver(Compte c); } // port sortant

Implémentation technique d'un port : contrôleur REST (adaptateur entrant), repository JPA ou client Kafka (adaptateur sortant).

@Component
class JpaCompteAdapter implements ComptePort {
    private final CompteJpaRepository jpa;
    private final CompteMapper mapper;
    public Compte charger(Iban iban) { return mapper.toDomain(jpa.findByIban(iban.valeur()).orElseThrow()); }
    public void sauver(Compte c) { jpa.save(mapper.toEntity(c)); }
}

Cœur métier : entités, value objects, règles et services du domaine, en Java pur (sans annotation Spring ni JPA idéalement).

Orchestre un cas d'usage : charge les objets via les ports, appelle le domaine, gère la transaction, publie les événements. Aucune règle métier propre.

@Service @Transactional
class EffectuerVirementService implements EffectuerVirement {
    public VirementId executer(DemandeVirement d) {
        Compte source = comptes.charger(d.source());
        Compte dest = comptes.charger(d.destination());
        Virement v = source.virerVers(dest, d.montant());   // règle métier dans le domaine
        comptes.sauver(source); comptes.sauver(dest);
        return v.id();
    }
}

Tout ce qui est technique : contrôleurs REST, repositories JPA, consommateurs Kafka, clients HTTP, configuration. Elle dépend du domaine, jamais l'inverse.

Objet métier défini par son identité, qui persiste dans le temps même si ses attributs changent (un Compte reste le même compte quand son solde change).

Objet défini uniquement par ses valeurs, immuable et sans identité (Montant, Iban, Adresse) ; deux value objects égaux sont interchangeables. Il porte ses propres validations.

public record Montant(BigDecimal valeur, String devise) {
    public Montant {
        if (valeur.signum() < 0) throw new IllegalArgumentException("Montant négatif");
        valeur = valeur.setScale(2, RoundingMode.HALF_EVEN);
    }
    public Montant plus(Montant o) { verifierDevise(o); return new Montant(valeur.add(o.valeur), devise); }
}

Règle métier qui ne relève naturellement d'aucune entité (ex. calcul de frais entre deux comptes de banques différentes) ; sans état, en Java pur.

Les dépendances vont toujours dans un seul sens : Controller → Service → Repository. Une couche basse ne connaît jamais une couche haute.

Cinq principes de conception orientée objet (Robert C. Martin) : Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion.

Une classe ne doit avoir qu'une seule raison de changer, c'est-à-dire répondre à un seul acteur ou besoin métier.

// ❌ calcule, persiste, envoie l'email et génère le PDF
class FactureService { … }
// ✅ responsabilités séparées
class CalculFacture { … }   class FactureRepository { … }
class EnvoiFacture { … }    class GenerateurPdf { … }

Ouvert à l'extension, fermé à la modification : on ajoute un comportement en ajoutant du code (nouvelle implémentation), pas en modifiant du code existant et testé.

interface RegleFrais { boolean concerne(Operation o); BigDecimal frais(Operation o); }
@Component class FraisVirementInterne implements RegleFrais { … }
@Component class FraisMobileMoney implements RegleFrais { … }   // nouveau cas = nouvelle classe

BigDecimal frais(Operation o) {               // ce code ne change plus
    return regles.stream().filter(r -> r.concerne(o)).findFirst().map(r -> r.frais(o)).orElse(BigDecimal.ZERO);
}

Une sous-classe doit pouvoir remplacer sa classe mère sans casser le comportement attendu par l'appelant (mêmes contrats, pas d'exception surprise).

class Compte { void debiter(BigDecimal m) { … } }
class CompteBloque extends Compte {
    @Override void debiter(BigDecimal m) { throw new UnsupportedOperationException(); } // ❌ viole LSP
}
// ✅ modéliser "bloqué" comme un état (statut) plutôt que comme une sous-classe

Plusieurs petites interfaces spécifiques valent mieux qu'une grosse interface générale : un client ne doit pas dépendre de méthodes qu'il n'utilise pas.

// ❌ interface CompteOperations { debiter(); crediter(); exporterPdf(); calculerInterets(); envoyerReleve(); }
interface Debitable { void debiter(Montant m); }
interface Exportable { byte[] exporterPdf(); }

Les modules de haut niveau (métier) ne dépendent pas des modules de bas niveau (techniques) : les deux dépendent d'abstractions. Spring réalise l'injection, le principe dit dans quel sens vont les dépendances.

class VirementService {
    private final Notificateur notificateur;          // abstraction
    VirementService(Notificateur n) { this.notificateur = n; }
    // ❌ private final SmsOrangeClient sms = new SmsOrangeClient();
}

Classe « qui fait tout » (des milliers de lignes, des dizaines de dépendances) : symptôme d'une violation du SRP, difficile à tester et à faire évoluer.

Couplage : degré de dépendance entre modules (à minimiser). Cohésion : degré auquel les éléments d'un module servent un même but (à maximiser). Objectif : faible couplage, forte cohésion.

Ensemble d'opérations exécuté comme une unité : soit tout est validé (COMMIT), soit tout est annulé (ROLLBACK).

BEGIN;
UPDATE compte SET solde = solde - 50000 WHERE id = 1;
UPDATE compte SET solde = solde + 50000 WHERE id = 2;
INSERT INTO mouvement(compte_id, montant, type) VALUES (1, 50000, 'DEBIT'), (2, 50000, 'CREDIT');
COMMIT;      -- ou ROLLBACK; en cas d'erreur : aucun des trois changements n'est conservé

Les quatre garanties d'une transaction relationnelle : Atomicité (tout ou rien), Cohérence (contraintes respectées), Isolation (pas d'interférence entre transactions concurrentes), Durabilité (validé = conservé, même après un crash).

• Atomicité : un virement ne peut pas débiter sans créditer.
• Cohérence : la transaction amène la base d'un état valide à un autre (clés étrangères, CHECK solde >= 0, unicité).
• Isolation : deux virements simultanés ne voient pas les états intermédiaires l'un de l'autre, selon le niveau d'isolation.
• Durabilité : une fois le COMMIT confirmé, la donnée est écrite dans le journal (WAL) et survit à une panne.

Réglage du compromis entre cohérence et performance pour les transactions concurrentes : READ UNCOMMITTED, READ COMMITTED (défaut PostgreSQL), REPEATABLE READ, SERIALIZABLE.

*PostgreSQL est plus strict que la norme : pas de lecture sale même en READ UNCOMMITTED, pas de fantôme en REPEATABLE READ.

@Transactional(isolation = Isolation.SERIALIZABLE)   // à réserver aux cas critiques : risque d'échecs à relancer
public void cloturerJournee() { … }

Lecture sale : lire une donnée non validée. Lecture non répétable : relire une ligne et trouver une autre valeur. Fantôme : relancer une requête et trouver de nouvelles lignes. Mise à jour perdue : deux écritures concurrentes, la seconde écrase la première.

T1 lit solde = 100          T2 lit solde = 100
T1 écrit 100 - 30 = 70      T2 écrit 100 - 50 = 50   → solde final 50 : le débit de 30 est perdu

On ne verrouille pas : chaque ligne a un numéro de version ; à l'UPDATE, on vérifie qu'il n'a pas changé. Si oui, l'écriture échoue (conflit) et on relance ou on informe l'utilisateur.

Idéal quand les conflits sont rares (édition d'un dossier client). Pas de verrou tenu, donc bonne scalabilité.

@Entity class Dossier { @Version private Long version; … }
// Hibernate génère : UPDATE dossier SET …, version = 6 WHERE id = 42 AND version = 5
// 0 ligne modifiée → ObjectOptimisticLockingFailureException (→ HTTP 409 Conflict)

On verrouille la ligne dès la lecture : les autres transactions qui veulent la modifier attendent la fin de la transaction. Adapté aux conflits fréquents (solde d'un compte très sollicité).

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT c FROM Compte c WHERE c.id = :id")
Optional<Compte> findForUpdate(@Param("id") Long id);   // SELECT … FOR UPDATE

Règles garanties par la base elle-même : clé primaire (identifiant unique), clé étrangère (référence valide), UNIQUE, NOT NULL, CHECK.

CREATE TABLE compte (
  id         BIGSERIAL PRIMARY KEY,
  client_id  BIGINT NOT NULL REFERENCES client(id),
  iban       VARCHAR(34) NOT NULL UNIQUE,
  solde      NUMERIC(15,2) NOT NULL CHECK (solde >= 0),
  devise     CHAR(3) NOT NULL DEFAULT 'XOF'
);

Organiser les tables pour éliminer la redondance (chaque information stockée une seule fois). La dénormalisation duplique volontairement des données pour accélérer la lecture.

1NF : valeurs atomiques ; 2NF : pas de dépendance partielle à la clé ; 3NF : pas de dépendance entre colonnes non-clés. Exemple : on ne recopie pas l'adresse du client dans chaque commande, on référence client_id.

SELECT choisit les colonnes à renvoyer (la projection) ; ne demander que les colonnes utiles réduit les I/O, le réseau et permet les index couvrants.

-- ❌ ramène 40 colonnes dont des textes volumineux
SELECT * FROM transaction WHERE compte_id = 42;
-- ✅
SELECT id, date_operation, montant, libelle FROM transaction WHERE compte_id = 42;

Une jointure combine les lignes de deux tables selon une condition (souvent clé étrangère = clé primaire) ; son type décide du sort des lignes sans correspondance.

Renvoie uniquement les lignes qui ont une correspondance dans les deux tables.

SELECT c.nom, co.iban
FROM client c
INNER JOIN compte co ON co.client_id = c.id;   -- les clients sans compte disparaissent

Renvoie toutes les lignes de la table de gauche, avec les colonnes de droite remplies si une correspondance existe, NULL sinon.

SELECT c.id, c.nom, COUNT(co.id) AS nombre_commandes
FROM client c
LEFT JOIN commande co ON co.client_id = c.id
GROUP BY c.id, c.nom;                -- les clients sans commande apparaissent avec 0

-- Trouver les clients SANS commande
SELECT c.* FROM client c LEFT JOIN commande co ON co.client_id = c.id WHERE co.id IS NULL;

Symétrique du LEFT JOIN : toutes les lignes de la table de droite, NULL à gauche si pas de correspondance. On l'écrit rarement (on inverse les tables et on fait un LEFT JOIN).

Toutes les lignes des deux tables, appariées quand c'est possible, complétées par des NULL sinon. Utile pour la réconciliation (comparer deux sources).

-- Rapprochement : opérations banque vs relevé opérateur mobile money
SELECT b.reference, b.montant AS montant_banque, o.montant AS montant_operateur
FROM operations_banque b
FULL OUTER JOIN releve_operateur o ON o.reference = b.reference
WHERE b.reference IS NULL OR o.reference IS NULL OR b.montant <> o.montant;   -- écarts

GROUP BY regroupe les lignes qui partagent une valeur ; les fonctions d'agrégation (COUNT, SUM, AVG, MIN, MAX) calculent un résultat par groupe.

SELECT agence, COUNT(*) AS nb_comptes, SUM(solde) AS encours, AVG(solde) AS solde_moyen
FROM compte
GROUP BY agence
ORDER BY encours DESC;

WHERE filtre les lignes avant le regroupement ; HAVING filtre les groupes après le calcul des agrégats.

Ordre logique d'exécution : FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. C'est pourquoi WHERE ne peut pas utiliser COUNT(*).

SELECT client_id, COUNT(*) AS nb_virements
FROM virement
WHERE date_operation >= CURRENT_DATE - 30   -- lignes : 30 derniers jours
GROUP BY client_id
HAVING COUNT(*) > 50;                        -- groupes : clients très actifs (alerte AML)

ORDER BY trie le résultat ; LIMIT restreint le nombre de lignes renvoyées et OFFSET en saute un certain nombre.

SELECT * FROM transaction WHERE compte_id = 42 ORDER BY date_operation DESC LIMIT 20 OFFSET 40;  -- page 3

Une sous-requête est une requête imbriquée ; une CTE (WITH nom AS (...)) lui donne un nom pour rendre une requête complexe lisible, et peut être récursive.

WITH mouvements_mois AS (
  SELECT compte_id, SUM(montant) AS total
  FROM mouvement
  WHERE date_operation >= date_trunc('month', CURRENT_DATE)
  GROUP BY compte_id
)
SELECT c.iban, m.total
FROM compte c JOIN mouvements_mois m ON m.compte_id = c.id
WHERE m.total > 10000000;

Calculs sur un ensemble de lignes liées à la ligne courante (classement, cumul, comparaison avec la précédente) sans réduire le nombre de lignes, via OVER (PARTITION BY … ORDER BY …).

SELECT compte_id, date_operation, montant,
       SUM(montant) OVER (PARTITION BY compte_id ORDER BY date_operation) AS solde_cumule,
       ROW_NUMBER() OVER (PARTITION BY compte_id ORDER BY montant DESC)   AS rang
FROM mouvement;

Requête dont la structure SQL est envoyée séparément des valeurs (paramètres ?) : la base ne peut jamais interpréter une valeur comme du code SQL. Protection de base contre l'injection SQL.

// ❌ concaténation : "'; DROP TABLE users; --" devient du SQL
String sql = "SELECT * FROM users WHERE name = '" + name + "'";
// ✅ paramètre lié
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
// ✅ JPA : @Query("… WHERE u.name = :name") avec @Param, ou les requêtes dérivées

Structure de données annexe qui permet de retrouver des lignes sans parcourir toute la table, comme l'index d'un livre. Accélère les lectures, ralentit un peu les écritures et occupe de l'espace.

CREATE INDEX idx_transaction_compte_date ON transaction (compte_id, date_operation DESC);
CREATE INDEX CONCURRENTLY idx_client_email ON client (email);   -- PostgreSQL : sans bloquer les écritures

Index par défaut : arbre équilibré trié qui gère égalité, plages (<, >, BETWEEN), tri et préfixes (LIKE 'abc%'). Couvre la grande majorité des besoins.

Index basé sur une fonction de hachage, utilisable uniquement pour l'égalité (=). Rarement préférable au B-Tree en PostgreSQL.

Index inversé : pour chaque élément (clé JSON, mot, élément de tableau), la liste des lignes qui le contiennent. Idéal pour JSONB, recherche plein texte et tableaux.

CREATE INDEX idx_client_meta ON client USING GIN (metadonnees);
SELECT * FROM client WHERE metadonnees @> '{"segment": "PME"}';   -- utilise l'index GIN

Index généraliste pour les données géométriques et les plages : géolocalisation (PostGIS), intervalles de dates, recherche de proximité.

CREATE INDEX idx_agence_position ON agence USING GIST (position);
SELECT nom FROM agence ORDER BY position <-> ST_MakePoint(-17.4677, 14.7167) LIMIT 3;  -- 3 agences les plus proches de Dakar

Index minuscule qui stocke le min/max par bloc de pages ; très efficace sur de très grosses tables dont la colonne suit l'ordre physique d'insertion (horodatages de logs, transactions).

CREATE INDEX idx_audit_date ON journal_audit USING BRIN (cree_le);

Index qui ne couvre qu'un sous-ensemble de lignes (clause WHERE) : plus petit et plus rapide quand on interroge toujours ce sous-ensemble.

CREATE INDEX idx_virement_en_attente ON virement (date_creation) WHERE statut = 'EN_ATTENTE';

Index sur plusieurs colonnes ; il sert aux requêtes qui filtrent sur ses premières colonnes (règle du préfixe gauche). L'ordre des colonnes compte.

CREATE INDEX idx_tx ON transaction (compte_id, date_operation);
-- ✅ WHERE compte_id = 42
-- ✅ WHERE compte_id = 42 AND date_operation > '2026-01-01'
-- ❌ WHERE date_operation > '2026-01-01'   (pas de compte_id : index peu utile)

Index qui contient toutes les colonnes demandées par la requête : la base répond sans lire la table (Index Only Scan).

CREATE INDEX idx_tx_couvrant ON transaction (compte_id, date_operation) INCLUDE (montant);
SELECT date_operation, montant FROM transaction WHERE compte_id = 42;   -- Index Only Scan

Affiche le plan d'exécution choisi par la base et, avec ANALYZE, exécute réellement la requête pour donner temps et nombre de lignes réels à chaque étape.

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM transaction WHERE compte_id = 42 AND date_operation > now() - interval '30 days';
-- Index Scan using idx_tx on transaction (cost=0.43..85.20 rows=120) (actual time=0.05..0.31 rows=118)
-- Execution Time: 0.42 ms

Stratégies de lecture : Seq Scan lit toute la table ; Index Scan suit l'index ligne par ligne ; Bitmap Heap Scan collecte via l'index les pages à lire puis les lit en bloc (bon compromis pour beaucoup de lignes ou plusieurs conditions).

Un Seq Scan n'est pas toujours mauvais : sur une petite table ou si la requête ramène une grande partie des lignes, c'est le plus rapide. Il devient suspect sur une grande table filtrée sur peu de lignes.

Cardinalité : nombre de valeurs distinctes d'une colonne. Sélectivité : proportion de lignes retenues par un filtre. Un index est utile sur un filtre très sélectif (peu de lignes).

Un index sur sexe (2 valeurs) sert rarement ; un index sur email (unique) est très sélectif.

ANALYZE collecte des statistiques (distribution des valeurs) que l'optimiseur utilise pour estimer les coûts ; pg_stats permet de les consulter.

ANALYZE transaction;
SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'transaction';

PostgreSQL ne modifie pas une ligne en place : il crée une nouvelle version (MVCC), ce qui permet aux lecteurs de ne pas bloquer les écrivains. VACUUM récupère l'espace des anciennes versions.

L'autovacuum s'en charge normalement. Sur une table très mise à jour, un autovacuum en retard entraîne du « bloat » (table gonflée, requêtes plus lentes).

VACUUM (ANALYZE, VERBOSE) transaction;
SELECT relname, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;

OFFSET relit et jette toutes les lignes précédentes (lent sur les pages lointaines, instable si des lignes arrivent). La pagination keyset repart de la dernière valeur vue : coût constant.

-- OFFSET : page 5000 = 100 000 lignes lues puis ignorées
SELECT * FROM transaction ORDER BY id DESC LIMIT 20 OFFSET 100000;
-- Keyset : on transmet le dernier id reçu
SELECT * FROM transaction WHERE id < :dernier_id ORDER BY id DESC LIMIT 20;

Ensemble de connexions base ouvertes à l'avance et réutilisées (ouvrir une connexion coûte des dizaines de ms). HikariCP est le pool par défaut de Spring Boot (10 connexions par défaut).

spring.datasource.hikari:
  maximum-pool-size: 20
  connection-timeout: 3000      # ms d'attente max pour obtenir une connexion
  leak-detection-threshold: 20000

Base relationnelle open source robuste et très complète : ACID, MVCC, JSONB, index avancés, CTE, fonctions fenêtres, extensions (PostGIS, pg_trgm).

Type PostgreSQL qui stocke du JSON sous forme binaire indexable (GIN) ; permet de mêler données relationnelles et attributs flexibles.

ALTER TABLE client ADD COLUMN metadonnees JSONB DEFAULT '{}';
UPDATE client SET metadonnees = metadonnees || '{"canal": "USSD"}' WHERE id = 42;
SELECT metadonnees->>'canal' FROM client WHERE metadonnees @> '{"segment": "PME"}';

Découper une très grosse table en sous-tables (par date, par région) : les requêtes ne lisent que les partitions concernées et l'archivage devient un simple DETACH.

CREATE TABLE transaction (id BIGINT, date_operation DATE, montant NUMERIC(15,2))
PARTITION BY RANGE (date_operation);
CREATE TABLE transaction_2026_10 PARTITION OF transaction
  FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');

Copie continue de la base principale vers une ou plusieurs répliques ; on y envoie les lectures lourdes (rapports) pour soulager le primaire, et elles servent de secours en cas de panne.

Base NoSQL orientée documents : les données sont stockées en documents BSON (proches du JSON) dans des collections, sans schéma imposé par la base.

Adaptée aux données hétérogènes ou évolutives (catalogues, contenus, logs métier, profils). Pour des écritures financières fortement relationnelles, PostgreSQL reste préféré.

db.clients.insertOne({
  nom: "Awa Ndiaye",
  telephones: ["+221770000000"],
  adresse: { ville: "Dakar", quartier: "Plateau" }
});

Un document est un enregistrement JSON/BSON (avec un _id unique) ; une collection regroupe des documents, comme une table regroupe des lignes, mais sans structure imposée.

Modélisation MongoDB : imbriquer les données lues ensemble dans le même document (embedding), ou stocker une référence vers un autre document (referencing) quand elles sont volumineuses, partagées ou à croissance illimitée.

// Embedding : adresse lue toujours avec le client
{ _id: 1, nom: "Awa", adresse: { ville: "Dakar" } }
// Referencing : des milliers de transactions → collection séparée
{ _id: 9001, clientId: 1, montant: 25000 }

Suite d'étapes ($match, $group, $sort, $project, $lookup…) que traversent les documents, chaque étape transformant le résultat de la précédente ; l'équivalent MongoDB du GROUP BY/JOIN.

db.orders.aggregate([
  { $match: { status: "ACTIVE", createdAt: { $gte: ISODate("2026-01-01") } } },
  { $group: { _id: "$customerId", total: { $sum: "$amount" }, count: { $sum: 1 } } },
  { $sort: { total: -1 } },
  { $limit: 10 }
]);

$match filtre (comme WHERE), $group regroupe et agrège, $sort trie, $limit coupe, $project choisit les champs, $lookup joint une autre collection.

Comme en SQL, sans index une requête parcourt toute la collection (COLLSCAN) ; on crée des index simples, composés, uniques, TTL ou texte.

db.transactions.createIndex({ clientId: 1, date: -1 });
db.sessions.createIndex({ creeLe: 1 }, { expireAfterSeconds: 3600 });   // TTL : suppression auto
db.transactions.find({ clientId: 1 }).sort({ date: -1 }).explain("executionStats");

En cas de partition réseau, un système distribué doit choisir entre Cohérence (tout le monde voit la même donnée) et Disponibilité (tout le monde reçoit une réponse) ; la tolérance au partitionnement n'est pas négociable.

Un système de paiement favorise la cohérence (refuser plutôt que débiter deux fois) ; un fil d'actualité favorise la disponibilité.

Base clé-valeur en mémoire, ultra-rapide (sub-milliseconde), avec structures de données riches ; utilisée comme cache, store de sessions, compteur, verrou distribué, file légère.

SET taux:EUR "655.957" EX 3600     # valeur avec expiration 1 h
GET taux:EUR
INCR compteur:otp:+221770000000

Durée de vie d'une clé : passé ce délai, elle est supprimée automatiquement. Indispensable pour qu'un cache ne serve pas éternellement des données périmées.

EXPIRE session:abc 1800
TTL session:abc        # secondes restantes

String : valeur simple ou compteur. Hash : objet à champs (user:123 → nom, email). List : liste ordonnée (file FIFO/LIFO). Set : ensemble sans doublons.

HSET client:42 nom "Awa" ville "Dakar"
HGET client:42 ville
LPUSH file:notifications "msg1"     # puis BRPOP pour consommer
SADD agences:ouvertes "Plateau" "Medina"
SISMEMBER agences:ouvertes "Plateau"

Ensemble dont chaque élément a un score, maintenu trié : classements, files de priorité, fenêtres glissantes pour le rate limiting.

ZADD classement:agences 1250000000 "Plateau" 980000000 "Medina"
ZREVRANGE classement:agences 0 9 WITHSCORES          # top 10
# Rate limiting fenêtre glissante : un élément par requête, score = timestamp
ZADD rl:client:42 1760440000123 "req-uuid"
ZREMRANGEBYSCORE rl:client:42 0 1760439940123        # purge > 60 s
ZCARD rl:client:42                                   # requêtes dans la dernière minute

Journal d'événements en append-only dans Redis, avec groupes de consommateurs et accusés de réception : une alternative légère à Kafka pour des volumes modérés.

XADD evenements * type "VIREMENT" montant "25000"
XREADGROUP GROUP notif c1 COUNT 10 STREAMS evenements >
XACK evenements notif 1760440000123-0

L'application lit d'abord le cache ; en cas d'absence (miss), elle lit la base, puis écrit le résultat dans le cache. C'est le pattern le plus courant (ce que fait @Cacheable).

public Taux taux(String devise) {
    Taux t = redis.opsForValue().get("taux:" + devise);
    if (t != null) return t;                                    // hit
    t = repo.findByDevise(devise);                              // miss → base
    redis.opsForValue().set("taux:" + devise, t, Duration.ofMinutes(30));
    return t;
}

Le cache lui-même charge la donnée depuis la base en cas de miss (via un « loader »), l'application ne parle qu'au cache.

LoadingCache<String, Taux> cache = Caffeine.newBuilder()
        .expireAfterWrite(Duration.ofMinutes(30))
        .build(devise -> repo.findByDevise(devise));   // loader appelé en cas de miss

Chaque écriture met à jour le cache et la base de façon synchrone : le cache est toujours à jour, au prix d'une écriture un peu plus lente.

L'écriture va d'abord dans le cache, et la base est mise à jour plus tard, en asynchrone et par lots : très rapide, mais risque de perte si le cache tombe avant la synchronisation.

Quand une clé très demandée expire, des centaines de requêtes ratent le cache en même temps et frappent toutes la base, qui peut s'effondrer.

Remèdes : un seul recalcul grâce à un verrou (SETNX), TTL avec jitter pour étaler les expirations, rafraîchissement anticipé avant expiration, ou servir la valeur périmée pendant le recalcul.

SET cle valeur NX PX 5000 n'écrit la clé que si elle n'existe pas : le premier qui réussit obtient le verrou, avec une expiration de sécurité. Sert à coordonner plusieurs instances.

SET lock:recalcul:taux "pod-7" NX PX 5000    # OK → j'ai le verrou ; (nil) → quelqu'un d'autre l'a

RLock lock = redisson.getLock("lock:cloture:" + date);    // Redisson gère renouvellement et libération
if (lock.tryLock(0, 30, TimeUnit.SECONDS)) {
    try { cloturerJournee(date); } finally { lock.unlock(); }
}

Supprimer ou mettre à jour une entrée de cache quand la donnée source change ; « il n'y a que deux choses difficiles en informatique : l'invalidation de cache et nommer les choses ».

Stratégies : TTL court, suppression explicite après écriture (@CacheEvict), événement de changement diffusé à toutes les instances.

Règle qui choisit quelles clés supprimer quand la mémoire est pleine : LRU (moins récemment utilisée), LFU (moins fréquemment utilisée), TTL le plus proche…

CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

Moteur de recherche et d'analyse distribué basé sur Lucene ; son index inversé associe chaque mot aux documents qui le contiennent, ce qui rend la recherche plein texte très rapide.

Usage : recherche de clients par nom approximatif, recherche dans les logs (pile ELK), tableaux de bord analytiques. Ce n'est pas une base transactionnelle de référence : on y réplique les données depuis la base principale.

GET /clients/_search
{ "query": { "match": { "nom": { "query": "ndiay", "fuzziness": "AUTO" } } } }

L'analyseur découpe le texte en termes (tokenisation), met en minuscules, retire accents et mots vides, applique la racinisation ; la même analyse est faite sur la requête pour pouvoir comparer.

PUT /clients
{ "mappings": { "properties": {
    "nom":  { "type": "text", "analyzer": "french" },
    "iban": { "type": "keyword" } } } }