Kafka dans les Systèmes d'Assurance : Architecture pour Haute Concurrence

Lorsqu'un assureur doit traiter un volume élevé de transactions quotidiennes — enrôlements, prélèvements domiciliés, validations contre des listes de risque, tokenisation de cartes —, le modèle requête-réponse synchrone devient fragile dès lors qu'une opération critique dépend de plusieurs intégrations aux latences différentes ; en cas de pic, ce couplage amplifie les temps d'attente en l'absence de limites et de dégradation contrôlée.

Le vrai problème : le couplage temporel

Dans un système synchrone traditionnel, le temps que prend le service de tokenisation des cartes s'ajoute au temps de réponse total de la transaction. Si la validation contre les listes internes de risque, les listes de personnes bloquées et les sources de sanctions —chacune avec sa fréquence de mise à jour, sa version consultée et sa preuve— est sous charge, toute la chaîne attend. Le résultat est prévisible : délais d'attente dépassés (timeouts), reprises manuelles et erreurs de rapprochement.

Apache Kafka résout cela avec un modèle fondamentalement différent : au lieu que les services s'appellent entre eux, ils publient des événements dans des topics et chaque consommateur les traite de manière indépendante, à son propre rythme. Kafka peut offrir un traitement exactly-once au sein de flux Kafka correctement configurés ; lorsque interviennent des API, des processeurs de paiement ou des bases de données externes, il reste nécessaire de disposer d'identifiants idempotents, d'une gestion des doublons et d'un rapprochement (par exemple, avec le patron outbox).

Comment l'enrôlement se résout avec des événements

Le schéma habituel dans les plateformes d'assurance est le suivant : le début de l'enrôlement est publié comme événement, et les validations —identité, listes restrictives, tokenisation du moyen de paiement— sont traitées par des consommateurs indépendants qui publient leur résultat. La coordination suit le patron saga, par chorégraphie (chaque service réagit aux événements des autres) ou par orchestration (un composant réunit les résultats et décide si l'enrôlement peut se poursuivre). La valeur ne tient pas à la messagerie, mais à ce que les validations ne se bloquent pas les unes les autres.

L'enrôlement est modélisé comme une machine à états —en attente, en validation, approuvé, rejeté, expiré, en révision— et l'on définit ce qui se passe en cas de résultats dupliqués ou tardifs, d'indisponibilité d'un tiers et d'expirations.

La différence opérationnelle est de nature, non de degré. Un pic de demande cesse de se transformer immédiatement en timeouts : la file absorbe le volume et chaque consommateur traite à son rythme. Le prix à payer est la latence de traitement. Le découplage réduit la propagation des pannes, mais n'élimine pas le risque : il faut des limites de consommation, des reprises bornées, des files d'exceptions et une surveillance du retard.

La traçabilité comme exigence de premier ordre

L'une des exigences les plus strictes du secteur de l'assurance est l'audit. Chaque transaction — de la demande initiale à la confirmation du paiement — doit être traçable, avec horodatages, états intermédiaires et identité du système ayant traité chaque étape. Les événements constituent une source précieuse de preuves, mais ne remplacent pas un journal d'audit : il faut définir des événements auditables, la corrélation, l'horodatage, l'intégrité, la conservation et un référentiel interrogeable distinct de la rétention de Kafka.

Les topics ne doivent pas diffuser de données sensibles : on publie des références ou des identifiants pseudonymisés et le minimum de données nécessaire ; chiffrement en transit et au repos, accès par topic et rétention définie. Les données de carte restent en dehors de la plateforme d'événements, selon le modèle de responsabilité de PCI DSS ; ce qui circule, c'est le jeton.

Considérations pour la mise en production

Kafka n'est pas gratuit en complexité opérationnelle. Il faut définir correctement le nombre de partitions (il détermine le parallélisme maximal), le facteur de réplication (il influe sur la durabilité), la rétention des messages (elle influe sur le coût de stockage) et les politiques d'idempotence des consommateurs (elles influent sur la cohérence). Dans les environnements Kubernetes, un opérateur dédié simplifie considérablement le cycle de vie du cluster.

La règle pratique qui se vérifie à l'usage est la suivante : Kafka est le bon choix lorsque plusieurs consommateurs indépendants ont besoin du même événement, lorsque la relecture (replay) des événements est nécessaire pour le débogage ou la migration, et lorsque la disponibilité du producteur ne peut pas dépendre de celle du consommateur. Pour une communication requête-réponse entre deux services qui ont besoin d'une réponse immédiate, un REST synchrone reste plus simple et mieux adapté.