Imaginons une entreprise qui remplace les échanges nocturnes de son ERP par des événements diffusés en temps réel. Sur la maquette, les commandes circulent plus vite et chaque application paraît enfin autonome. Puis survient un incident banal : un même événement est traité deux fois, le stock devient incohérent, la facturation attend un message perdu et personne ne sait quel système détient la vérité. Cette situation est illustrative, mais la décision qu’elle impose est très réelle : le DSI doit-il étendre l’architecture événementielle, la corriger ou revenir, pour certains flux, à un traitement plus simple ?
Découpler ne signifie pas simplifier
Une architecture événementielle réduit le couplage direct entre producteurs et consommateurs. L’ERP peut signaler qu’une commande est validée sans connaître tous les services qui utiliseront l’information. Cette indépendance facilite l’évolution locale, mais elle déplace la complexité. Elle n’est plus visible dans une interface synchrone ; elle se répartit entre le broker, les schémas, les abonnements, les files d’erreurs, les mécanismes de reprise et les équipes d’exploitation.
Le dirigeant IT doit donc refuser une équation trompeuse : davantage d’événements ne signifie pas automatiquement davantage d’agilité. Chaque nouveau flux crée un contrat implicite. Qui peut le publier ? Que signifie-t-il exactement ? Peut-il arriver en retard, plusieurs fois ou dans le désordre ? Combien de temps doit-il être conservé ? Sans réponses opposables, l’entreprise ne supprime pas ses dépendances : elle les rend plus difficiles à voir.
Partir de la décision métier, pas du middleware
Le premier travail consiste à distinguer l’événement métier du signal technique. « Commande confirmée » décrit un fait durable et compréhensible. « Ligne modifiée » peut n’être qu’un détail d’implémentation. Si les consommateurs reconstruisent le processus à partir de signaux ambigus, toute évolution de l’ERP risque de les casser.
Pour chaque cas d’usage, le comité d’architecture doit documenter le propriétaire du fait, la source de vérité, les consommateurs autorisés, la latence réellement nécessaire et le comportement attendu en mode dégradé. Le RSSI y ajoute la sensibilité des données, les droits de publication et de lecture, la traçabilité ainsi que le risque de propagation d’une information erronée. Ce cadrage permet au DSI de choisir une architecture en fonction d’un besoin vérifiable, non d’une préférence d’ingénieur ou d’une promesse fournisseur.
Concevoir l’échec avant le chemin nominal
Le scénario heureux démontre peu de chose. La robustesse se mesure lorsqu’un consommateur est indisponible, qu’un message est rejoué ou qu’un schéma évolue. L’idempotence doit empêcher qu’une répétition légitime déclenche deux expéditions ou deux écritures comptables. Les clés de corrélation doivent permettre de suivre une transaction sans exposer inutilement des données sensibles. Les files de quarantaine exigent un propriétaire, un délai de traitement et une procédure de réinjection contrôlée.
La reprise ne peut pas reposer sur une consigne vague. Il faut tester la restauration du broker, la reconstruction d’un état, le rejeu d’une période et la gestion des effets déjà produits dans les systèmes aval. Le responsable de continuité doit savoir quelles activités peuvent fonctionner avec des données retardées et lesquelles nécessitent un arrêt maîtrisé. Une architecture rapide mais impossible à remettre en cohérence après incident constitue une fragilité, pas une modernisation.
Gouverner les schémas et les responsabilités
La compatibilité des schémas est une décision de gouvernance. Ajouter un champ peut sembler anodin ; renommer une valeur, modifier son sens ou supprimer un attribut peut affecter des consommateurs inconnus. Un registre de schémas ne suffit donc pas. Il faut des règles de version, des tests de compatibilité, un inventaire des usages, une période de transition et une procédure de retrait.
Cette discipline rejoint le principe de clean core dans les ERP : limiter les modifications du cœur et utiliser des extensions supportées protège les mises à niveau. Mais déplacer les spécifiques vers des consommateurs événementiels ne les fait pas disparaître. Sans catalogue, responsables nommés et cycle de vie, on transforme une dette concentrée dans l’ERP en dette distribuée autour de lui. Le comité portefeuille doit voir cette charge avant d’autoriser de nouveaux flux.
Mesurer ce que l’exploitation peut réellement tenir
Le tableau de bord utile ne se limite pas au volume de messages. Il suit le retard des consommateurs, l’âge du plus ancien événement non traité, les doublons détectés, les messages en quarantaine, les échecs de désérialisation, les temps de reprise et la part des flux sans propriétaire identifié. Il distingue aussi l’indisponibilité du transport d’une erreur métier persistante.
Ces indicateurs doivent conduire à des décisions. Une file d’erreurs qui grossit appelle un gel des nouveaux consommateurs, pas un seuil d’alerte plus confortable. Un temps de rejeu incompatible avec la continuité impose de revoir la rétention, le partitionnement ou le processus de secours. Si les équipes ne peuvent expliquer rapidement l’origine et l’impact d’un événement, l’observabilité reste décorative.
Reconnaître les cas où le batch gagne
Trois erreurs reviennent souvent : imposer l’événementiel à tous les échanges, confondre temps réel et valeur métier, puis sous-estimer les compétences d’exploitation. Un rapprochement quotidien contrôlé, traçable et relançable peut être supérieur à une chaîne instantanée dont les états intermédiaires sont incompréhensibles. De même, une API synchrone convient lorsqu’une réponse immédiate conditionne la suite et qu’un contrat transactionnel clair est nécessaire.
L’arbitrage final doit comparer la criticité, la latence utile, le besoin de découplage, la capacité de reprise, la maturité des équipes, le coût d’observabilité et la réversibilité. Le DSI peut réserver l’événementiel aux faits métier stables, conserver des batchs pour les consolidations et utiliser des API pour les commandes exigeant une réponse. Cette combinaison n’est pas un compromis honteux : c’est une architecture gouvernée.
Dans l’esprit de « Révolution Numérique ! », la technologie ne vaut que reliée aux décisions, aux risques et aux capacités réelles de l’organisation. La bonne question n’est donc pas : « Sommes-nous assez événementiels ? » Elle est plus exigeante : « Pouvons-nous expliquer, exploiter, sécuriser et reconstruire chaque flux critique lorsque le système cesse de fonctionner comme prévu ? »
Pour approfondir
Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon
Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon
#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique
