Les schémas sont le contrat entre producteurs et consumers. Sans gouvernance, les events cassent silencieusement. Dans un environnement bancaire, cette situation est intenable: les flux doivent rester stables, auditables et compréhensibles sur plusieurs années. La gouvernance de schéma n’est pas un “nice to have”, c’est une discipline de sécurité et de conformité.

Cet article propose une approche avancée: compatibilité, versioning, gestion public/private, sécurité des données, catalogues d’events et tests contractuels. L’objectif est simple: éviter que le flux d’events devienne un risque opérationnel.

Pourquoi un Schema Registry ?

Un Schema Registry centralise les schémas, impose des règles de compatibilité et automatise la validation. Il évite les dérives où chaque équipe publie ses propres formats, rendant les integrations fragiles.

Dans une banque, un event TransferSettled peut être consommé par le ledger, le reporting, le contrôle interne et parfois des partenaires externes. Un changement non gouverné peut avoir un impact réglementaire.

Le Schema Registry agit comme un contrôle de qualité: un schema invalide ou incompatible est rejeté avant publication. Cela réduit drastiquement les incidents silencieux.

Public vs private: deux niveaux de contrat

Events publics

Un event public est un contrat d’intégration entre domaines. Il doit être stable, versionné et documenté. Les changements sont lents et coordonnés.

Events privés

Un event privé est interne à une équipe ou un service. Il peut évoluer plus rapidement car l’impact est limité à des consumers contrôlés.

En banque, on traite comme publics les events qui touchent plusieurs domaines: AccountOpened, TransferSettled, CardBlocked. Les events de cache ou de métriques internes restent privés.

Fact vs delta

• Fact: décrit un fait complet, stable et durable.
• Delta: décrit une variation d’état, utile pour l’interne.

Dans un contrat public, privilégier les facts. Les deltas créent un couplage au contexte interne du producteur, ce qui rend l’intégration fragile.

Envelope standard: la base du contrat

Un event sans metadata est incomplet. Un envelope standard inclut: - event_id - type - occurred_at - schema_version - correlation_id - causation_id

Ces champs permettent la traçabilité, la compatibilité et l’audit. En banque, le correlation_id permet de reconstituer un flux complet (ex: virement de bout en bout) sans ambiguïté.

Compatibilité: backward, forward, full

La compatibilité définit comment un consumer plus ancien ou plus récent réagit à un schéma mis à jour:

• Backward: les nouveaux producers peuvent être lus par les anciens consumers.
• Forward: les anciens producers peuvent être lus par les nouveaux consumers.
• Full: backward + forward.

En banque, la compatibilité backward est souvent privilégiée car les consumers migrent plus lentement que les producers. Toutefois, pour les flux critiques, une compatibilité full est recommandée.

Stratégies d’évolution de schéma

Changements additifs

Ajouter un champ optionnel est généralement safe (backward compatible). Exemple ajouter channel à un event TransferInitiated.

Changements destructifs

Supprimer ou renommer un champ est un changement majeur. Il faut créer un nouveau type d’event ou une nouvelle version de schéma. Exemple: passer de TransferInitiated.v1 à TransferInitiated.v2.

Versioning par type ou par topic ?

Deux approches: - Versioning dans le schéma: même topic, schema_version évolue. - Versioning par topic: ...v1, ...v2.

En banque, on combine souvent les deux: un schéma versionné dans le topic, et un nouveau topic lorsqu’un changement majeur impose une coexistence longue.

Domain events vs integration events

Une confusion fréquente consiste à publier des events trop proches du modèle interne. Un domain event décrit un fait interne, optimisé pour la logique métier. Un integration event est une version stabilisée, destinée aux autres domaines. En banque, un domain event peut contenir des détails très granulaires, tandis qu’un integration event expose un contrat durable.

Exemple: - Domain event: LedgerEntryCreated avec les détails comptables internes. - Integration event: TransferSettled avec des champs stabilisés et utiles aux consommateurs externes.

Cette séparation évite de “geler” un modèle interne en contrat public.

Stratégies d’upcasting et downcasting

Lorsqu’un schéma évolue, deux techniques permettent de préserver la lecture: - Upcasting: transformer un event ancien vers le format nouveau. - Downcasting: adapter un event nouveau vers un ancien format.

Dans un système bancaire, ces transformations sont utiles lors de migrations progressives. Un consumer legacy peut continuer à fonctionner si un pipeline renvoie un event downcasté. À l’inverse, un nouveau consumer peut rejouer l’historique en appliquant un upcasting automatique.

Ces mécanismes doivent être documentés et testés. Ils ne remplacent pas une stratégie de versioning, mais permettent une coexistence propre pendant une période de transition.

Politiques de compatibilité en pratique

Le Schema Registry applique des politiques de compatibilité par sujet. En banque, on définit souvent: - Backward pour les topics opérationnels où les consumers migrent lentement. - Full pour les topics critiques (ledger, reporting réglementaire).

Il est conseillé d’avoir une politique par domaine, plutôt qu’une règle globale. Les flux de notification peuvent tolérer plus d’évolution que les flux comptables. Cette granularité réduit les blocages inutiles tout en maintenant la sécurité sur les flux critiques.

Versioning et dépréciation contrôlée

Le versioning n’est pas qu’une question technique, c’est un processus organisationnel. Un plan de dépréciation doit inclure: - un délai d’annonce, - un calendrier de migration, - une date de retrait du schéma obsolète.

Dans une banque, ce calendrier doit être aligné avec les périodes d’audit et les fenêtres de changement approuvées. Les events publics évoluent souvent sur plusieurs mois, tandis que les events privés peuvent évoluer sur des cycles courts.

Formats de sérialisation

JSON

Lisible mais verbeux, faible contrôle de compatibilité. Utile pour prototypage.

Avro

Compact, schéma strict, bien intégré au Schema Registry. Très courant.

Protobuf

Compact et performant, nécessite plus de discipline sur le versioning.

Dans un contexte bancaire, Avro ou Protobuf sont recommandés. JSON peut rester pour des flux internes ou du debug.

Gouvernance des données sensibles

Les events bancaires contiennent des PII. La gouvernance doit inclure: - classification (public, interne, restreint), - masking ou tokenisation, - séparation des topics par sensibilité, - politiques de rétention et purge.

Exemple: un event public TransferInitiated peut contenir un account_ref pseudonymisé. Le détail complet reste dans un topic privé avec accès restreint.

Tests contractuels et CI/CD

Un schéma ne doit pas changer sans validation. Les bonnes pratiques incluent: - validation automatique via Schema Registry en CI, - contract tests producer/consumer, - revue d’architecture pour les events publics.

Un pipeline bancaire mature bloque le déploiement si un schéma casse la compatibilité. Cela évite les incidents silencieux et réduit les coûts de support.

Validation runtime et qualité des données

Même avec un Schema Registry, les données peuvent être incorrectes. Un champ peut être présent mais incohérent (montant négatif, devise invalide). Les consumers critiques doivent donc appliquer des validations métier. Une banque met souvent en place un “data quality layer” qui vérifie: - la cohérence des montants (unités mineures, devise), - la présence des identifiants de corrélation, - l’intégrité des relations (compte existant, statut actif).

Les événements invalides doivent être isolés (DLQ) avec un processus de correction. Cette discipline protège les projections et évite que des données corrompues contaminent les reportings.

Processus de revue et gouvernance transverse

Un schéma public devrait passer par un processus de revue. Dans les banques, cela peut prendre la forme d’un “event review board” réunissant architecture, sécurité et métiers. L’objectif est de valider: - la pertinence métier de l’event, - l’impact sur la conformité (PII, rétention), - la compatibilité et la stratégie de migration.

Cette gouvernance transverse réduit le risque de divergence entre équipes et assure que les events publics sont alignés avec les exigences réglementaires.

Catalogue d’events

Un catalogue est un inventaire structuré: - nom de l’event, - domaine propriétaire, - description métier, - schéma et version, - SLA et rétention, - public/private.

Dans une banque, ce catalogue est un outil clé pour le contrôle interne et la conformité. Il permet de savoir qui publie quoi, et pourquoi.

Exemple de fiche catalogue

• Event: TransferSettled
• Owner: Paiements
• Version: v2
• Compatibilité: backward
• Retention: 7 ans (audit)
• Sensibilité: interne

Nommage des champs et stabilité sémantique

La gouvernance ne porte pas seulement sur les types d’events, mais aussi sur les champs. Des règles simples évitent les ambiguïtés: - privilégier des noms explicites (amount_minor plutôt que value), - indiquer les unités (minor units, ISO 4217), - éviter les champs génériques (data, info, payload).

Dans une banque, la sémantique doit être claire pour éviter les erreurs d’interprétation. Exemple: TransferAuthorized signifie que les règles ont été validées, mais pas que l’écriture comptable est passée. Cette précision doit se retrouver dans le schéma et dans la documentation.

Exemple bancaire: évolution d’un event

Un event TransferInitiated v1 contient: - transfer_id - from_account - to_account - amount_minor

Une nouvelle exigence impose d’ajouter le canal (channel). La modification est additive, on publie v1 compatible backward. Le schema_version passe à 2.

Si un changement majeur est requis (ex: remplacer from_account par une structure complexe), on crée TransferInitiated.v2 avec un nouveau topic. Le consumer peut migrer à son rythme, et l’historique v1 reste disponible pour l’audit.

Bonnes pratiques de base

• Documenter chaque event public dans un catalogue.
• Appliquer un naming stable et versionné.
  • prod.corebanking.transfer.evt.initiated.v1
  • prod.corebanking.transfer.evt.initiated.v2
• Automatiser la validation de compatibilité en CI.
• Éviter les champs ambigus (data, payload, info).
• Ajouter des metadata systématiques (event_id, occurred_at).

Gouvernance organisationnelle

La gouvernance n’est pas que technique. Elle nécessite: - un ownership clair par domaine, - un processus de revue pour les events publics, - des SLA documentés, - un suivi des versions en production.

Dans un contexte bancaire, ces pratiques s’intègrent aux processus de conformité existants (audit, risk management).

Pièges à éviter

• Exposer un modèle interne dans un event public.
• Changer un schéma sans version explicite.
• Ignorer la compatibilité dans le Schema Registry.
• Utiliser un event “delta” comme contrat public.
• Dupliquer les mêmes données dans plusieurs formats concurrents.

Un autre piège est la documentation obsolète. Un schéma non synchronisé avec son catalogue devient source de confusion. En banque, cette incohérence peut entraîner des erreurs d’audit, car la description officielle ne correspond plus aux événements réellement publiés. La gouvernance doit donc être vivante.

Conclusion

La gouvernance des schémas est la base d’une architecture event-driven durable. Elle permet d’éviter les cassures silencieuses, de garantir la conformité et assurer la compréhension des flux sur la durée. En banque, la discipline de schéma est un pilier aussi important que la sécurité ou la disponibilité. Un système event-driven sans gouvernance devient vite un risque opérationnel.

La maturité se construit dans la durée: catalogues tenus à jour, revues régulières des schémas, et retours d’expérience après incident. C’est cette boucle d’amélioration continue qui transforme un flux d’events en actif stratégique plutôt qu’en dette technique.