Architecture de l’analytique en temps réel : couches, modèles et compromis

Architecture de l’analytique en temps réel : couches, modèles et compromis

Une architecture d’analytique en temps réel achemine continuellement les événements de l’endroit où ils se produisent vers l’endroit où quelqu’un peut agir à partir de ces données, au lieu d’attendre une tâche nocturne. En pratique, cela signifie quatre couches : l’ingestion, le traitement des flux, un magasin de données pour la restitution et une couche de consommation, comme des tableaux de bord, des API ou des alertes. La difficulté réside rarement dans le choix des outils. Il s’agit de déterminer le niveau de fraîcheur réellement nécessaire pour chaque réponse et de ne payer que pour cela.

Ce guide présente les différentes couches, les modèles Lambda et Kappa, les décisions de conception qui posent problème en production, ainsi qu’une méthode pour dimensionner correctement la solution. Il s’adresse aux responsables métier, opérationnels et technologiques qui parraineront ou évalueront ce type de système, et pas uniquement aux ingénieurs qui le construiront.

Points clés à retenir

• Une architecture de flux comporte quatre couches : ingestion, traitement, restitution et consommation. La latence s’accumule à travers chacune d’elles ; mesurez-la donc de bout en bout.
• Partez de la décision, pas de la technologie. Un contrôle antifraude et un tableau de bord des stocks nécessitent des niveaux de fraîcheur très différents, et la courbe des coûts est raide.
• Kappa (un seul pipeline de flux) convient à la plupart des nouveaux projets. Lambda (traitement par lots et traitement des flux) ne justifie son coût supplémentaire que lorsque deux normes de précision doivent coexister.
• Les données arrivant en retard, la contre-pression, les changements de schéma et la gouvernance sont les éléments qui font tomber les systèmes après leur lancement. Concevez-les dès le premier jour.
• Un dimensionnement adapté vaut mieux qu’un dimensionnement maximal. De nombreuses équipes ont besoin de minutes, pas de millisecondes.

Table des matières

• Qu’est-ce qu’une architecture d’analytique en temps réel ?
• Les quatre couches et la circulation des données entre elles
• Flux ou traitement par lots : quelles sont les différences réelles ?
• Lambda ou Kappa : quel modèle choisir ?
• Les décisions de conception qui déterminent la robustesse de la solution
• Un parcours dimensionné correctement, de l’idée à la production
• Comment Ridiculous Engineering vous aide
• FAQ
• Sources

Qu’est-ce qu’une architecture d’analytique en temps réel ?

Les systèmes de traitement par lots collectent les données, attendent l’exécution d’une tâche planifiée, puis publient les résultats plusieurs heures plus tard. Un système en temps réel traite les données comme un flux continu : chaque événement est capturé, traité et rendu interrogeable en quelques secondes ou moins. Les recommandations d’AWS Well-Architected relatives à l’analytique décrivent les composants fondamentaux d’une architecture de flux comme les sources de données, l’ingestion des flux et les producteurs (par exemple la capture des modifications de données ou Kafka Connect), le stockage des flux (par exemple Kafka ou Kinesis), le traitement des flux (par exemple Flink ou Spark) et les destinations en aval, comme indiqué dans son architecture de référence des flux.

Cette liste constitue une checklist utile pour une première séance de réflexion au tableau blanc. Si une proposition de fournisseur omet l’une de ces cases, demandez où cette responsabilité est prise en charge.

« En temps réel » est d’abord un terme métier, avant d’être un terme technique

Personne n’a besoin que tout soit traité en millisecondes. Un contrôle antifraude pour un paiement peut nécessiter une réponse bien inférieure à une seconde. Une vue des stocks en entrepôt peut être parfaitement utile si elle est actualisée toutes les quelques minutes. Un rapport hebdomadaire destiné aux dirigeants peut ne pas nécessiter de flux du tout.

Avant de dessiner la moindre architecture, notez pour chaque cas d’utilisation :

1. La décision ou l’action que les données permettent de prendre.
2. La personne ou le système qui prend cette décision ou réalise cette action (une personne, une application ou une règle automatisée).
3. Le degré d’obsolescence que les données peuvent atteindre avant que la décision ne se dégrade.
4. Le coût d’une réponse erronée ou incomplète.

Ces quatre réponses définissent votre budget de latence. Tout ce qui suit est conçu pour le respecter, et pas pour viser un niveau plus strict.

Les quatre couches et la circulation des données entre elles

1. Ingestion : capturer et mettre en mémoire tampon

Les événements proviennent des bases de données des applications, des clics des utilisateurs, des systèmes de paiement, des capteurs IoT, des journaux et des API tierces. L’ingestion les capture de manière fiable et les place dans un stockage durable. Deux approches courantes :

• Publication d’événements depuis les applications. L’application émet un événement métier (« commande passée ») vers un flux. La sémantique est claire, mais cela nécessite de modifier le code de l’application.
• Capture des modifications de données (CDC). Un connecteur lit le journal des modifications de la base de données et publie chaque insertion ou mise à jour. Cette approche est moins invasive pour les systèmes existants, ce qui explique pourquoi elle est si fréquente dans les projets de modernisation.

Le tampon est tout aussi important que la capture. Une plateforme de streaming fonctionne comme un journal distribué en ajout uniquement, dans lequel les événements sont conservés pendant une période configurable, de quelques heures à plusieurs mois, voire indéfiniment, et restent disponibles pour être lus par n’importe quel consommateur, comme le décrit un guide du secteur sur les applications d’analyse en temps réel . Cette conservation permet de rejouer l’historique après la correction d’un bug ou d’ajouter ultérieurement un nouveau consommateur sans toucher au système source. Pour une présentation technique plus approfondie de cette couche, notre guide pratique du streaming d’événements avec Kafka couvre les sujets, les partitions et les garanties de livraison.

2. Traitement : valider, enrichir, agréger

La couche de traitement transforme les événements bruts en données utiles : elle les valide, les joint à des données de référence, calcule des totaux cumulés, détecte des schémas ou leur attribue un score à l’aide d’un modèle. Les recommandations de Microsoft pour choisir une technologie de traitement de flux soulignent que le choix dépend souvent de la nécessité d’un traitement avec ou sans état, ainsi que de l’utilisation éventuelle de fenêtres temporelles, soit glissantes (avec chevauchement), soit par lots fixes (sans chevauchement), pour les agrégations temporelles.

En termes simples :

• Sans état les opérations (filtrage, analyse syntaxique, transformations simples) sont peu coûteuses et faciles à mettre à l’échelle.
• Avec état les opérations (« nombre de connexions échouées par utilisateur au cours des cinq dernières minutes ») doivent mémoriser certaines informations, ce qui influe sur la mémoire, la récupération et le coût.
• Les fenêtres définissent « les cinq dernières minutes » et sont à l’origine de la plupart des problèmes de justesse inattendus.

3. Mise à disposition : un stockage conçu pour la question posée

Les données traitées sont stockées dans un système adapté à la manière dont elles seront interrogées. Il n’existe pas de réponse unique :

Pour le cas des recherches, le scénario de référence de lakehouse en quasi-temps réel de Microsoft dénormalise les données dans un stockage NoSQL tel qu’Azure Cosmos DB afin de prendre en charge des réponses d’API en quelques millisecondes. Pour le cas du lakehouse, ce même scénario utilise Delta Lake, qui fournit des garanties ACID ainsi qu’un traitement unifié en streaming et par lots sur un lac de données.

Le principe de conception : structurer les données en fonction du lecteur. La pré-agrégation et la dénormalisation au moment de l’écriture sont ce qui accélère les lectures.

4. Consommation : tableaux de bord, API, alertes et modèles

C’est à ce stade que l’entreprise perçoit la valeur, et que les exigences de latence varient le plus. Un écran d’exploitation en direct, une métrique destinée aux clients dans votre produit, une alerte adressée à un responsable d’astreinte et un flux de caractéristiques pour un modèle d’apprentissage automatique lisent tous la couche de mise à disposition différemment. Planifiez d’abord les consommateurs, puis remontez jusqu’à leur origine.

Un tableau de bord auquel personne ne fait confiance ou que personne ne comprend fait perdre toute la valeur du pipeline. Les personnes qui consultent des chiffres en direct doivent également savoir les interpréter ; c’est pourquoi certaines organisations associent le déploiement d’une plateforme à une formation à l’analyse web pour les analystes et les responsables qui utiliseront les tableaux de bord au quotidien. Notre guide sur l’analytique en libre-service va plus loin pour expliquer comment rendre cette dernière étape efficace.

La latence est la somme de chaque étape

Il est tentant d’évaluer les performances du moteur de traitement et de considérer le travail comme terminé. Pourtant, la latence de bout en bout correspond au total de la capture, du transit réseau, de la mise en mémoire tampon, du traitement, de l’écriture dans le système de stockage, du temps d’exécution des requêtes et de l’actualisation du tableau de bord. Instrumentez chaque étape avec des horodatages dès le premier jour. Lorsqu’une partie prenante vous dit « le tableau de bord semble lent », vous devez savoir quelle étape a consommé ces secondes.

Flux continu ou traitement par lots : quelles sont les différences réelles ?

Au-delà de la fraîcheur des données, les deux modèles présentent des compromis d’ingénierie différents. Les recherches sur le sujet soulignent que les moteurs de traitement en continu sont confrontés à des compromis entre latence et débit : accuser réception des messages un par un pour garantir leur livraison ajoute une surcharge et est moins efficace que le traitement par lots, selon l’analyse IEEE de Jimmy Lin sur les architectures Lambda et Kappa.

Cela a des conséquences pratiques pour la planification :

• Le traitement en continu coûte plus cher par enregistrement que le traitement par lots lorsqu’il fonctionne 24 heures sur 24. Si une actualisation horaire suffit à la prise de décision, le traitement par lots est la réponse honnête.
• Le traitement en continu vous oblige à gérer des situations que le traitement par lots masque : les événements reçus dans le désordre, les livraisons en double et les résultats partiels.
• Les opérations changent. Une tâche nocturne qui échoue peut être relancée le matin. Un flux qui s’interrompt à 2 heures du matin constitue un incident.

Une approche hybride est normale. De nombreuses entreprises traitent en continu les 10 % de données qui déterminent des décisions urgentes et laissent le reste en traitement par lots.

Lambda ou Kappa : quel modèle convient ?

Ces deux noms reviennent dans presque chaque revue d’architecture ; il vaut donc la peine d’être précis.

Lambda a été proposée par Nathan Marz vers 2011. Elle exécute côte à côte une couche de traitement par lots et une couche temps réel transitoire, avec une couche de fusion qui combine leurs résultats. La couche par lots fournit à terme des réponses exactes et complètes. La couche de vitesse fournit immédiatement des réponses approximatives.

Kappa a été proposée par Jay Kreps dans un article de blog publié en 2014. Elle utilise un moteur unique de traitement des flux pour toutes les données et évite la complexité du double pipeline de Lambda. Les données historiques sont retraitées en rejouant le journal avec le même code. Ces deux descriptions proviennent de l’article de Lin.

Le compromis réel

La logique dupliquée constitue le véritable coût de Lambda. Lorsque deux bases de code calculent le « chiffre d’affaires », elles finiront par diverger, et quelqu’un passera une semaine à chercher pourquoi.

Notre recommandation pour la plupart des nouveaux systèmes : commencez par adopter une approche Kappa. Conservez un journal d’événements durable, écrivez la logique une seule fois et rejouez les événements lorsque vous devez corriger l’historique. N’ajoutez un chemin de traitement par lots distinct que si vous disposez d’une raison documentée, par exemple si la facturation doit être exacte alors qu’un tableau de bord opérationnel peut tolérer de petites erreurs. Les tables lakehouse modernes qui gèrent le streaming et le traitement par lots sur les mêmes données réduisent encore l’écart, car vous disposez d’une seule couche de stockage avec deux façons de la lire.

Les décisions de conception qui déterminent la robustesse du système

Le diagramme se ressemble d’un projet à l’autre. Les différences importantes sont présentées ci-dessous.

Données tardives et désordonnées

Les événements n’arrivent pas dans l’ordre où ils se sont produits. Les appareils mobiles se déconnectent, les réseaux prennent du retard et les systèmes en amont réessaient. Les processeurs de flux gèrent cela à l’aide de seuils de progression : une estimation évolutive de la progression du temps des événements, utilisée pour déterminer à quel moment une fenêtre est suffisamment complète pour être publiée.

Le compromis est direct. Un seuil de progression strict publie rapidement les résultats, mais ignore ou traite incorrectement les événements retardataires. Un seuil plus souple attend davantage, ce qui améliore l’exhaustivité, mais augmente le délai ainsi que l’état que le système doit conserver. Choisissez sa valeur à partir du retard observé dans vos données réelles, et non d’une valeur par défaut. Décidez ensuite explicitement de ce qui doit arriver aux événements reçus après la fermeture de la fenêtre : les ignorer, les acheminer vers un flux de correction ou mettre à jour le résultat.

Contrôle de la pression et durabilité

Que se passe-t-il lorsqu’un système de stockage en aval ralentit ? Sans plan, la réponse est une perte de données ou une défaillance en cascade. Un bon pipeline met les données en mémoire tampon dans le journal durable, ralentit les producteurs ou augmente la capacité des consommateurs, et alerte quelqu’un au lieu de supprimer silencieusement des enregistrements. Demandez à votre équipe de le démontrer en ralentissant délibérément un consommateur dans un environnement de test.

Garanties de livraison

« Une seule fois exactement » est l’objectif pour tout ce qui concerne les finances ou les stocks, mais il s’agit d’une propriété de l’ensemble du pipeline, et non d’un seul composant. Lorsqu’elle ne peut pas être garantie de bout en bout, concevez des écritures idempotentes afin que la relecture d’un événement ne le comptabilise pas deux fois.

Évolution des schémas et qualité des données

Les producteurs modifient le format de leurs événements, généralement sans avertissement. Utilisez un registre de schémas, validez les données lors de leur ingestion et envoyez les enregistrements incorrects vers un flux de quarantaine avec une alerte, au lieu de les laisser contaminer les tables en aval. La même discipline que celle appliquée aux mises en production des applications s’applique ici : notre article sur l’intégration et le déploiement continus des pipelines de données montre comment les contrôles de schéma soumis à l’approbation d’une pull request détectent les changements incompatibles avant leur mise en production.

Sécurité et gouvernance

Le streaming ne vous dispense pas de la gouvernance. Au contraire, les enjeux sont plus importants, car les données se déplacent plus rapidement qu’un examen manuel ne peut le faire. Traitez le contrôle des accès, le chiffrement, la conservation, la traçabilité et la responsabilité des schémas comme des éléments de l’architecture, en particulier dans les secteurs réglementés comme la santé, la finance et l’administration, où la gouvernance doit fonctionner au même rythme que les données. Déterminez qui est responsable de chaque type d’événement, qui peut le lire et combien de temps il est conservé avant de faire circuler le premier événement.

Déplacez l’intelligence en périphérie lorsque cela permet de réduire les coûts

Pour les caméras, les capteurs et les machines qui produisent d’importants volumes de données, filtrez les données et exécutez l’inférence localement, puis envoyez uniquement les agrégats ou les exceptions vers l’amont. Cela réduit la bande passante et les dépenses cloud, tout en raccourcissant le temps de réponse des actions locales.

Un parcours adapté de l’idée à la production

La plupart des projets temps réel qui échouent n’ont pas choisi la mauvaise technologie. Ils ont essayé de tout diffuser en continu d’un seul coup. Voici une séquence qui fonctionne :

1. Choisissez une décision. Par exemple, signalez les commandes bloquées dans les deux minutes ou affichez les niveaux de stock en temps réel pour chaque entrepôt. Définissez le budget de latence et le coût d’une réponse incorrecte.
2. Cartographiez les sources. Quels systèmes contiennent les événements ? Pouvez-vous les publier ou avez-vous besoin de CDC ? Lesquels de ces systèmes sont suffisamment anciens pour compliquer cette tâche ?
3. Construisez la tranche verticale la plus fine possible. Une source, une tâche de traitement, un magasin de données de mise à disposition et un consommateur, avec une instrumentation de la durée de bout en bout.
4. Ajoutez les chemins d’échec. Données tardives, relecture, quarantaine, alertes et guide d’exploitation pour le flux bloqué.
5. Mesurez le résultat. La décision s’est-elle améliorée ? Moins de ruptures de stock, des blocages pour fraude plus rapides, des temps de réponse plus courts ? Si le chiffre n’évolue pas, arrêtez-vous avant de passer à l’échelle.
6. Étendez progressivement. Ajoutez les sources et les consommateurs un par un, en réutilisant la plateforme.

L’argumentaire métier qui sous-tend cette approche est présenté dans notre vue d’ensemble de pourquoi les données en temps réel changent le fonctionnement des entreprises. En bref : le bénéfice vient de décisions plus rapides, et non de la technologie de diffusion en continu elle-même.

Construire, acheter ou combiner

Les services cloud managés réduisent le travail opérationnel, mais renforcent la dépendance au fournisseur et entraînent des coûts récurrents. Les moteurs open source offrent davantage de contrôle, mais nécessitent des personnes pour les exploiter. Le code personnalisé développé autour de l’un ou l’autre est l’endroit où résident votre logique métier et vos différences concurrentielles. La bonne combinaison dépend de la taille de votre équipe, de vos exigences de conformité et du nombre de systèmes à interconnecter. Méfiez-vous de toute approche incapable d’expliquer ce qui se passe à 2 heures du matin en cas de défaillance.

Comment Ridiculous Engineering aide

Nous concevons et développons les composants qui font le lien entre votre problématique métier et un système opérationnel : ingestion d’événements provenant de sources anciennes et modernes, pipelines de traitement, magasins de données pour la restitution, ainsi que tableaux de bord et applications qui les exploitent. Notre analytique des données et intelligence décisionnelle commence par la décision que vous souhaitez améliorer et la latence réellement nécessaire, puis dimensionne l’architecture en conséquence. Lorsque le consommateur est une application ou un workflow, notre équipe de développement logiciel sur mesure développe ce volet avec les mêmes ingénieurs seniors, tandis que nos travaux de développement d’IA et d’automatisation couvrent les modèles et les actions automatisées alimentés par des données en direct. Le prix dépend du périmètre ; l’étape suivante consiste donc à échanger sur votre cas d’usage et à obtenir un devis.

FAQ

Quelle est la différence entre l’analytique en temps réel et l’analytique en continu ?

Dans l’usage courant, les deux termes se recouvrent. Le streaming décrit la technique : traiter les événements en continu à mesure qu’ils arrivent. Le temps réel décrit le résultat : des données suffisamment récentes pour permettre d’agir dans le délai que vous avez défini. Vous pouvez diffuser des données en continu tout en ne fournissant des résultats que toutes les quelques minutes, ce qui suffit souvent aux besoins de l’entreprise.

Dois-je choisir Lambda ou Kappa ?

Pour la plupart des nouveaux systèmes, commencez par Kappa : un seul pipeline de streaming, une logique écrite une seule fois et un historique retraité par rejeu d’un journal durable. Choisissez Lambda uniquement lorsque deux consommateurs nécessitent des garanties de précision différentes, par exemple des chiffres de facturation exacts à côté d’un tableau de bord en direct plus tolérant. Mettez cela en balance avec le coût de maintenance de deux chemins de code.

À quelle vitesse mon système doit-il fonctionner ?

Partez de la décision et remontez jusqu’au système. Une vérification de fraude peut nécessiter des réponses en moins d’une seconde, tandis qu’un tableau de bord des stocks ou des ventes peut très bien être actualisé toutes les quelques minutes. Chaque réduction de la latence augmente les coûts et les efforts opérationnels ; fixez donc l’objectif en fonction de la valeur de la décision, et non de ce que les outils permettent de faire.

Avons-nous besoin de Kafka ?

Pas toujours. La capacité importante est de disposer d’un journal d’événements durable et rejouable, et Kafka est une solution courante pour y parvenir. Si votre volume est modeste et vos sources peu nombreuses, un service de streaming managé, voire des micro-lots fréquents, peut suffire. Notre guide Kafka pour les ingénieurs peut vous aider à vous faire une idée.

Qu’est-ce qui tombe le plus souvent en panne après le lancement ?

Les causes habituelles sont les changements de schéma en amont, les événements reçus en retard ou en double, ainsi que les magasins de données en aval trop lents, qui créent une contre-pression. La validation lors de l’ingestion, les écritures idempotentes, un circuit de mise en quarantaine pour les enregistrements incorrects et des alertes sur le retard permettent de résoudre la plupart de ces problèmes.

Sources

• Architecture de référence, Data Analytics Lens (AWS Well-Architected)
• Choisir une technologie de traitement des flux (Microsoft Learn)
• Traitement des données lakehouse en quasi temps réel (Microsoft Learn)
• The Lambda and the Kappa (Jimmy Lin, IEEE 2017)
• Créer des applications d’analytique en temps réel
• Cours de formation à l’analytique web

Recommandé

• Les données en temps réel : un changement décisif pour les entreprises
• Data Mesh ou Data Fabric : choisir la bonne architecture
• Concevoir une couche sémantique prête pour la production : guide pratique
• Stack de données moderne : feuille de route pratique pour les décideurs