Pendant longtemps, la donnée d’entreprise a été traitée par lots : on collecte toute la journée, puis on lance un traitement la nuit pour produire les rapports du lendemain. Ce modèle a un coût caché — la décision arrive toujours avec un temps de retard sur la réalité du terrain.
Les architectures de données en temps réel (souvent bâties autour d’outils comme Kafka ou Spark Streaming) changent cette équation : chaque événement — une vente, un capteur de flotte, une transaction — est traité au fil de l’eau, dès qu’il se produit. Concrètement, cela veut dire qu’un tableau de bord logistique reflète la position d’un véhicule il y a quelques secondes, pas celle d’hier soir.
Pour une organisation, l’intérêt n’est pas seulement technique. C’est un changement de posture : on passe d’une gestion a posteriori (« que s’est-il passé ? ») à une gestion en direct (« que se passe-t-il, et que dois-je faire maintenant ? »). Dans le transport, cela permet de détecter un écart d’itinéraire ou une surconsommation de carburant avant qu’elle ne devienne un problème budgétaire. Dans le commerce, cela permet d’ajuster un stock ou une promotion pendant qu’elle produit encore de l’effet.
Le temps réel n’est cependant pas une fin en soi. Il faut l’aborder avec pragmatisme : toutes les données n’ont pas besoin d’être traitées à la seconde près, et une architecture temps réel mal dimensionnée coûte plus cher qu’elle ne rapporte. La bonne question n’est pas « avons-nous besoin de temps réel ? » mais « quelles décisions, dans notre activité, perdent réellement de la valeur si elles attendent un jour de plus ? »
C’est cette question que nous posons systématiquement avant de concevoir un pipeline de données pour un client : identifier les flux qui méritent un traitement continu, et laisser les autres au traitement par lots, plus simple et moins coûteux à opérer. L’objectif reste le même — transformer la donnée brute en décision utile, au bon moment.