Les besoins d'analyse et de reporting en temps réel restent marginaux. Ils ne représentent, selon les acteurs du marché, que 1 à 2 % du marché décisionnel. Néanmoins, ce type de service se révèle indispensable à certains métiers. Ainsi, dans les télécoms, où la concurrence est rude, les opérateurs doivent suivre en continu la consommation de leurs clients. En cas d'incident, ils seront en mesure de proposer des dédommagements appropriés. C'est également un moyen pour eux, par des propositions avantageuses, de conserver des clients mécontents.

Dans le secteur bancaire, les besoins s'avèrent encore plus criants. L'analyse en temps réel optimise tout particulièrement la détection d'une utilisation frauduleuse des cartes bancaires. Grâce à quoi un même numéro ne peut être utilisé à Paris et à Bangkok à une heure d'intervalle.

Souvent liée à l'optimisation de la gestion de la relation client, l'analyse en temps réel est aussi une demande des centres d'appel. L'organisme de crédit Sofinco, par exemple, vient d'embarquer un moteur d'analyse dans l'application fournie à ses opérateurs. Ceux-ci traitent les paramètres fournis par le client au téléphone, intègrent éventuellement un historique et proposent aussitôt le taux le plus approprié.

« Les exemples d'applications décisionnelles en temps réel se multiplient, et la demande devient de plus en plus importante,  souligne Jacques Milman, architecte business intelligence chez IBM Business Consulting Services. D'une manière générale, le problème de fond est assez similaire : il s'agit d'attribuer un score au client et, selon son importance, de lui soumettre des propositions. On se situe clairement dans le domaine de la relation client analytique. Mais avec la nécessité de réagir très vite, au moment même où le client est actif. »

L'approche temps réel montre peu d'impact sur la couche de restitution (reporting, tableaux de bord, etc.), qui se contente de continuer à croiser les données qui lui sont fournies. Tout se joue donc au niveau des processus d'interrogation des données. Les annonces de ces derniers mois, relatives à l'association d'outils d'interrogation de données (EII) au décisionnel, laissent entendre que, à terme, les outils d'analyse interrogeront directement les bases de production. Et qu'elles court-circuiteront par ce biais des étapes de consolidation dans un entrepôt de données (ou datawarehouse).

Pour l'heure, toutefois, cette perspective semble encore très lointaine. De mémoire de décisionnel, l'analyse s'est toujours pratiquée en mode asynchrone. Et cela pour deux raisons principales, liées aux exigences de cohérence des données et de performances.

De fait, l'exploitation de plusieurs sources hétérogènes implique que soit respectée la cohérence des données, un principe souvent absent des systèmes informatiques. Par exemple, une application comptable et un progiciel de gestion intégré ne partageront pas forcément la même définition du chiffre d'affaires net. L'une intégrera les amortissements et les produits retournés, mais l'autre pas. Et donc, analyser ces données sans homogénéiser au préalable leur définition risque d'aboutir à des résultats erronés.

En outre, les bases de production se retrouvent sollicitées en permanence - notamment par les producteurs d'informations. Les champs sont alors verrouillés. Ce qui bloque les requêtes émises par les outils d'analyse.

Les requêtes multisources consomment beaucoup de ressources. Même dans le cas de l'EII. Les temps de réponse s'en ressentent. « Toute requête distribuée implique de rapatrier les données dans un cache ou une base pour les consolider si l'on veut préserver les performances, estime Jacques Milman. L'EII n'est pas prêt pour cela. » En outre, il ne dispose pas de fonctions pour transformer les données. « L'idée d'interroger différentes sources de données à la volée en se passant des datawarehouses est séduisante. Mais, pour l'instant, elle est irréalisable, ajoute Hervé Renault, directeur avant-ventes chez Business Objects. Au contraire, l'étape de consolidation sera renforcée parce que le décisionnel en temps réel n'échappe pas au prérequis de la cohérence des données. »

Raison pour laquelle l'EAI, autre outil dont les mécanismes d'acheminement de données en temps réel aurait pu convenir, n'est pas adapté non plus : il ne sait pas transformer les données.

Dès lors, bien qu'il n'ait pas été prévu pour le fonctionnement en temps réel, l'ETL reste la seule technologie en lice capable d'apporter de la cohérence aux informations et de consolider les données dans un datawarehouse qui garantira les performances. Cet outil d'analyse n'interroge qu'une seule source de données - laquelle, de surcroît, est modélisée pour offrir les meilleurs temps de réponse.

Toutefois, l'ETL est handicapé par son fonctionnement souvent en mode batch, voire asynchrone. Ceci dit, l'évolution des architectures l'autorise à « écouter » et à détecter les modifications intervenues dans les bases de production afin d'alimenter le datawarehouse au fil de l'eau. « Ces architectures nécessitent d'importantes ressources matérielles et ne sont pas les plus performantes, estime Jacques Milman. En général, on préfère s'en tenir au traditionnel mode batch de l'ETL. Quitte à raccourcir les délais de rafraîchissement des données pour les ramener à une heure ou à une minute, tout en lissant la charge des traitements par des mini-batchs. »

Les mises à jour globales d'un datawarehouse demandent un temps considérable. Elles sont donc espacées et pratiquées la nuit pour ne pas bloquer l'accès aux données pendant les heures de travail. Avec le décisionnel en temps réel, les rafraîchissements deviennent plus fréquents. Mais seulement sur la petite partie des données nécessaire à l'analyse. La fréquence est prédéterminée ou déclenchée par des mécanismes proches de ceux que l'on trouve dans le cadre de la réplication entre bases de données.

Dès qu'une modification intervient dans la base de production, celle-ci alerte l'ETL, qui demande alors une mise à jour du datawarehouse. L'optimisation de ces architectures exclut généralement l'option datamart (mini-entrepôt destiné à un usage métier). En ajoutant une étape supplémentaire de traitement, on ne ferait que « ralentir » le temps réel.

Dans tous les cas de figure, ce dialogue permanent entre les bases de production, l'ETL et les outils de restitution implique une intégration très poussée et une augmentation de la puissance des processeurs qui interviennent tout au long de la chaîne décisionnelle. La base de production peut être ralentie par les traitements liés à l'analyse de ses logs pour détecter les modifications et par le système de « push » d'informations vers l'ETL.

De son côté, l'ETL s'avère un goulet d'étranglement si les messages de la base de production sont trop fréquents ou si la quantité de données à traiter est trop importante. D'autant que certaines architectures prévoient un dialogue entre l'outil de restitution et l'ETL qui, s'il opère une modification dans le datawarehouse, génère automatiquement un recalcul des analyses.

« La réussite de toute architecture décisionnelle temps réel dépend du bon équilibre entre la quantité de données mises à jour, la fréquence des rafraîchissements et les ressources matérielles disponibles sur l'ensemble de la chaîne », conclut Thé Vinh Vo, directeur du pôle service Predixio, filiale de Net2S dédiée au décisionnel.