Jean-Marie Gouarné (Business Intelligence)

Il y a déjà abondance de littérature sur ce sujet (abondance que j'ai personnellement aggravée). Je m'en tiens donc ici à une simple tentative de définition critique du périmètre de ce domaine un peu incertain mais dont le succès ne se dément pas depuis une bonne quinzaine d'années.

intelligence économique, business intelligence et information décisionnelle

La business intelligence (ou pour les habitués la BI) est devenue, dans les milieux qui gravitent autour de l'informatique, un quasi-synonyme de l'information décisionnelle.

Ceci mérite une première mise au point terminologique, car par ailleurs business intelligence n'est pas (ou n'est plus) synonyme d'intelligence économique. L'intelligence économique (IE) est une notion beaucoup plus vaste qui couvre l'ensemble des activités de collecte d'informations sur l'environnement économique (concurrence et marchés, technologie, politique, société, etc). Selon une définition de l'IHEDN (Institut des Hautes Études de Défense Nationale), c'est "une démarche organisée, au service du management stratégique de l'entreprise, visant à améliorer sa compétitivité par la collecte, le traitement d'informations et la diffusion de connaissances utiles à la maîtrise de son environnement [1]". En France, il convient de marcher sur des oeufs quand on y fait allusion, car d'aucuns lui trouvent un relent d'espionnage. Le mot "intelligence", dans ce contexte, ne signifie pas comme en Français classique "aptitude à comprendre, à établir des relations, à relier des informations entre elles"; il évoque trop lourdement le mot "renseignement". Or, curieusement, alors que le management est d'habitude très friand de vocabulaire d'origine militaire (stratégie, campagne, cible, logistique...) et que les citations de Sun Tzu ou de Clausewitz sont toujours du meilleur effet dans la littérature pour dirigeants, le mot "renseignement" demeure politiquement incorrect dans le monde francophone des affaires. "Il n'existe pas de culture du renseignement en France. Au mieux, il s'agit d'un mal nécessaire, au pire, d'un amalgame barbouzard", regrettent même certains [2].

Aussi a-t-on introduit des notions alternatives, telles que l'analyse stratégique ou encore la veille stratégique, qui, en soi, n'apportent qu'un supplément d'imprécision, mais qui n'ont pas de connotation sulfureuse. L'analyse stratégique, pour ne citer qu'elle, n'exploite que des informations publiques (bien que souvent inconnues du grand public); on parle alors aussi, dans ce cas, d'IE à source ouverte ou open source intelligence (OSINT). L'IE au sens large peut, quant à elle, exploiter des sources non publiques, sans pour autant avoir recours à des procédés illicites.

Quoi qu'il en soit, nous sommes en présence d'une activité d'ingénierie de l'information s'exerçant dans un contexte concurrentiel, a Le cycle du renseignement

vec une vocation offensive ou défensive. Si vous voulez en savoir plus, je vous recommande l'excellente synthèse du CIGREF [3].

Il faut par ailleurs reconnaître que, depuis peu, les milieux politiques semblent prendre conscience de l'importance et de la légitimité d'une activité d'intelligence économique organisée, ne serait-ce que pour la sauvegarde des intérêts nationaux et européens dans le contexte de mondialisation que nous connaissons. La publication du rapport Carayon [4] témoigne de cette évolution.

Quels que soient l'emballage verbal et le contexte d'utilisation, il n'en reste pas moins vrai que le contenu de l'IE, tout comme celui de la BI, se définit très bien par ce que l'École de Guerre Économique appelle le "cycle du renseignement" et que résume le schéma ci-contre (cité dans le rapport du CIGREF). Nous sommes toujours dans une démarche itérative en quatre étapes : expression de besoins informationnels, collecte des données, traitement de ces données en vue de les transformer en informations pertinentes et exploitables, puis diffusion aux destinataires selon le contexte et les contraintes d'utilisation de chacun.

La business intelligence (au sens restreint qui est le nôtre), est beaucoup plus proche des opérations même si elle se veut elle aussi "stratégique". Elle traite des flux d'information provenant essentiellement de quatre sources :

Les pratiquants les plus nombreux de la BI sont sans aucun doute des gens qui n'en ont jamais entendu parler. De même que nos commerçants de quartier qui prennent soin de leur clientèle ne savent pas qu'ils font du CRM (Customer Relationship Management), ils font aussi de la business intelligence comme Monsieur Jourdain faisait de la prose. Croyez moi, ils ne s'en portent pas plus mal. Mais dans le monde des entreprises grandes ou petites dont l'infrastructure repose en grande partie sur des moyens informatiques, la mise en oeuvre de la BI est explicite et passe de plus en plus par un système d'information décisionnel (SID).

Un SID, bien entendu, n'est pas un système qui prend les décisions. En Anglais, on dit Decision Support System (DSS), ce qui en éclaire plus précisément le sens : il s'agit d'un système de "soutien" à la décision. La décision elle-même est humaine ; la vocation du SID n'est pas d'automatiser la décision, elle est d'automatiser (autant que faire se peut) la recherche et la mise en forme des données nécessaires à la prise de décision. La décision elle-même est un processus socio-technique, dans lequel les acteurs humains sont en inter-action de plus en plus étroite avec des automates.

La notion de SID s'est développée dans la dernière décennie du 20ème siècle, alors que celle de SI (système d'information tout court) existait déjà. Il est parfaitement légitime de se demander pourquoi, ayant déjà "inventé" le système d'information, il nous a fallu en inventer un autre, qualifié de décisionnel. Car enfin, quoi demander de plus que des "informations" pour pouvoir décider ? La réponse est à la fois simple et embarrassante : le système d'information "classique" est un système... qui n'informe pas.

Quand le concept de système d'information s'est imposé, et a valu à la plupart des ci-devant "directeurs informatiques" (DI) d'être requalifiés de "directeurs des systèmes d'information" (DSI)... ou mis au placard, il y avait sans doute deux objectifs théoriques à la clé : d'abord remettre la technique à sa place au service du contenu informationnel, ensuite promouvoir une vision systémique cohérente de l'ensemble des applications informatiques, qu'on ne voulait plus voir comme une collection d'automates isolés. Ce volontarisme, de toute évidence, n'a pas suffi, car aujourd'hui encore, dans les DSI, s'il est vrai qu'on s'occupe de plus en plus du système d'information, on est bien obligé de faire surtout de l'informatique. Et on reste au service de maîtrises d'ouvrage (MOA) qui sont elles-mêmes cloisonnées par métiers et sont rarement disposées à penser leur entreprise comme un "système". Certes, depuis une petite douzaine d'années, on a vu passer le business process reengineering (BPR) et ses divers avatars, avec quelques petits succès (et parfois aussi de gros dégâts). Ce courant réformateur tend à réorganiser l'entreprise par processus, donc à diluer les cloisonnements organiques traditionnels et à imposer une meilleure intégration du système d'information. Mais les idées sont plus faciles à remuer que les groupes humains. Le système d'information est encore, dans une large mesure, une vision d'état-major. Dans une grande organisation, les applications sont aujourd'hui largement interconnectées, voire techniquement intégrées dans les cas favorables, mais elles ne forment pas un ensemble informationnel homogène. Si elles constituaient un tout sémantiquement cohérent, les problématiques de gouvernance et d'urbanisme des systèmes d'information, si en vogue de nos jours, n'auraient pas de raison d'être.

business intelligence et système d'information

Ce que nous appelons aujourd'hui système d'information est un ensemble organisé mais hétérogène de composants automatiques et/ou semi-automatiques de traitement de données dont chacun est prioritairement destiné à soutenir une activité opérationnelle particulière. Incidemment, chacun de ces composants peut produire des informations de contrôle très détaillées sur l'activité à laquelle il est lié. Mais ces informations restent "au ras des pâquerettes"; elles ne sont pas directement exploitables à des fins d'analyse et de prévision. De cette limitation congénitale est venue l'idée d'un autre système d'information, spécialement et exclusivement conçu pour l'aide à la décision, et découplé des opérations. Pour essayer de préciser le rôle du SID dans une organisation, je préfère partir du schéma classique issu du courant de pensée systémique des années 1970, courant qui a notamment créé le fondement théorique de la notion de système d'information.

L'organisation est vue comme un système composé de trois sous-systèmes, à savoir:

1) Le Système Opérant, qui n'est autre que l'appareil de production, qui importe, transporte, transforme et exporte des flux matériels, énergétiques et financiers;

2) Le Système d'Information, qui constitue à la fois le reflet et le support informationnel du Système Opérant; il capte des données dans le Système Opérant (flèche jaune) auquel il renvoie des commandes ;

3) Le Système de Pilotage qui détermine le comportement de l'organisation en utilisant le Système d'Information comme une interface à double sens, pour être informé sur le Système Opérant et agir sur ce dernier.

Aucune place n'est prévue a priori pour le SID dans cet édifice. Je situe ce dernier dans la zone hachurée en vert (que vous pourrez qualifier, selon votre état d'esprit, de rustine ou de verrue), par dessus la flèche jaune des informations qui remontent vers le Système de Pilotage.

Car le besoin est bien là. Le Système d'Information possède (du moins l'espère-t-on) toutes les données du problème décisionnel, mais pas sous la forme homogène, cohérente, simplifiée qui convient. Un gros travail de transformation et de mise à disposition est à fournir. Le rôle du SID est d'automatiser les traitements correspondants, dans des espaces de travail séparés du reste du SI afin d'éviter toute perturbation mutuelle.

fonctions et architecture du SID

En pratique, les fonctions de collecte et d'intégration sont étroitement liées entre elles, et sont généralement associées à un composant informatique central appelé entrepôt de données (data warehouse). De même, diffusion et présentation sont des fonctions fortement "orientées sujet", tournées vers l'utilisateur et son métier, manipulant des contenus à forte valeur ajoutée informationnelle et non des données brutes; elles sont donc fortement imbriquées logiquement et techniquement. Par conséquent, la mise en oeuvre informatique d'un SID, selon la conception actuellement dominante, implique trois éléments techniques:

Le vocabulaire utilisé pour présenter cette architecture varie assez largement d'une organisation à une autre. Comme il faut bien faire des choix, j'utilise ici celui que j'ai moi-même introduit à la fin du siècle dernier et qui a été retenu par quelques grands comptes français (et parfois repris et développé par d'autres auteurs). Le schéma ci-dessus en montre une transposition en Anglais, tirée d'un support de présentation de GENICORP.

limites et évolution des projets de business intelligence

Je n'entre pas plus avant dans les détails du contenu et des applications d'un système de business intelligence. On a déjà écrit beaucoup (peut-être trop) sur ce sujet. Pour aller plus loin, je vous recommande notamment les références [6] et [7] ci-dessous (et [5] si mon point de vue continue à vous intéresser).

Il me semble plus utile, dans cette introduction personnelle, de mettre le doigt sur ce qui représente pour moi les principales limites actuelles des projets de BI, qui sont autant de pistes d'évolution pour le présent et l'avenir.

La première limite tient au caractère abstrait (bien que nécessaire) de la notion de SID, vue de la fenêtre du décideur. Dans la vie réelle, nous ne sommes pas tantôt dans l'opérationnel, tantôt dans le décisionnel. La décision et l'action sont complètement imbriquées. Plus précisément, il existe une boucle de rétroaction permanente entre opérations, informations et décisions.

Tout processus opérationnel produit des données. Certaines de ces données, exploitées par des automates régulateurs sans intervention humaine, provoquent des rétroactions non décisionnelles sur le processus. D'autres sont converties en informations qui sortent du système d'information "opérationnel" pour entrer dans le SID. Le SID, combiné avec le décideur humain, constitue un dispositif qui, de manière immédiate ou différée, est destiné à rétroagir lui aussi sur les processus (c'est-à-dire sur le système opérant). Le cycle de rétroaction est plus ou moins long, plus ou moins complexe et son séquencement plus ou moins régulier, mais il existe. Plus le niveau de décision est élevé et focalisé sur le long terme, plus la rétroaction est médiate et complexe. C'est ce que j'essaie de montrer dans le schéma ci-dessus, tiré du support de présentation précité. Or les SID conçus jusqu'à présent tiennent compte très imparfaitement de cette intégration cyclique entre décision et action. Cette limitation tient en partie à des facteurs techniques: par conception, les logiciels de BI disponibles sur le marché sont souvent difficiles à intégrer aux systèmes d'information. Mais elle provient aussi de facteurs sociaux et organisationnels, notamment de la très grande difficulté qu'il y a à modéliser l'activité décisionnelle et à la traduire en spécifications informatiques, et aussi peut-être d'une interprétation à mauvais escient du dogme de l'autonomie du SID par rapport aux opérations. Avec le temps, cette première carence de la BI va peut-être se résorber, sous l'influence, entre autres, des démarches d'urbanisation des systèmes d'information, des projets d'EAI (Enterprise Application Integration) et (pour l'aspect cosmétique des choses) du développement des "portails" (qui sont eux aussi des socles techniques d'intégration).

La seconde limite vient de ce que la plupart des SID conçus jusqu'à présent dans les grandes organisations sont essentiellement introspectifs. En effet, même si leurs enjeux sont très souvent liés à des impératifs commerciaux, donc focalisés sur le client et le marché, les données qui les alimentent sont, à une majorité écrasante, d'origine interne. La portée stratégique de tels outils reste donc très limitée. On peut dire que les outils de BI des entreprises ou des grandes administrations sont à l'opposé des systèmes d'information de commandement utilisés par les militaires en opération: les premiers permettent surtout à l'organisation de contempler sa propre histoire et de voir le monde extérieur à travers les lunettes de son propre système de production, tandis que les seconds s'efforcent de présenter au décideur, à tout instant, une vision combinée en temps réel du terrain, de ses moyens d'actions et de ceux de l'adversaire. Notons au passage que la portée stratégique est aussi limitée dans un cas que dans l'autre: dans le cas de la BI, la limite vient du manque d'informations extérieures, tandis que dans le monde des systèmes de commandement elle vient de l'absence de profondeur historique et donc de potentiel d'analyse et de modélisation prédictive. Toutefois, pour un système de commandement, cette limite n'en est pas vraiment une, justement parce que les objectifs sont opérationnels, voire tactiques, mais peu ou pas stratégiques (pour la stratégie, qui se joue largement en-dehors du théâtre d'opérations, voire en-dehors de tout état de guerre déclarée, la problématique de l'information décisionnelle se rapproche de celle de l'intelligence économique). Cette difficulté est techniquement difficile à surmonter, non seulement parce que l'information externe sur l'environnement économique semble plus compliquée à capter que la position d'un char ou d'un porte-avions sur une carte, mais aussi parce que l'information externe disponible est souvent sous une forme considérée comme indigeste.

La troisième limite découle d'un problème de "format" de données. Les informaticiens (qui, inconsciemment, restent marqués par l'époque de la mécanographie) ont pris l'habitude de faire une distinction entre données "structurées" et données "non structurées". Pour simplifier, disons que des données sont considérées comme "structurées" si on peut les représenter sous forme de fiches ou de tableaux dont la structure est prédéfinie et régulière. Par exemple un catalogue de produits indiquant, pour chaque article, un nom, un code, un prix, une quantité en stock. Dans un ensemble de données "structuré", chaque donnée élémentaire possède un "type" prédéfini, le type étant une notion mi-technique, mi-sémantique: il peut s'agir d'une date, d'un montant, d'un nombre entier ou d'un texte. À l'opposé, une donnée est dite "non structurée" s'il n'est pas possible de prédéfinir sa structure et de la ranger dans une table. Une telle donnée peut être, par exemple, un article de presse, une animation graphique, une séquence musicale, ou la page que vous êtes en train de lire. Ces données "non structurées" sont parfois appelées "documents", mais en réalité un document peut correspondre à toute espèce de structure de données. Cette distinction "technicienne" est abusive, car, par définition, toute donnée pouvant être traitée par une machine numérique est nécessairement structurée [8]. En réalité, les données dites "non structurées" sont tout simplement des données dont la structure est plus complexe (on pourrait aussi bien les qualifier de données "hyper-structurées"). En poussant jusqu'à l'absurde la logique qui mène à qualifier de "non structurées" les données complexes, on pourrait arguer de ce que les ordinateurs calculent en binaire, pour soutenir que les nombres décimaux ne sont pas "numériques"... Les vrais problèmes sont, d'une part, l'inaptitude des systèmes de gestion de bases de données classiques à gérer les structures complexes et, d'autre part, le fait que les dispositifs dédiés à la bureautique, à la gestion documentaire et au travail collaboratif ont toujours été gérés en marge du système d'information. Or, dans n'importe quelle organisation fortement et anciennement informatisée, les données dites "structurées" ne représentent qu'une petite partie du stock global de données. Et l'évolution récente de la technologie (notamment la généralisation du XML [9] comme standard de mémorisation et d'échange de données et des fonctions documentaires dans les principaux systèmes de gestion de bases de données du marché) est en passe de faire disparaître les obstacles (et les excuses) techniques qui s'opposaient à la prise en charge des données complexes par les SID. Il n'en reste pas moins un long chemin à parcourir, compte tenu des habitudes acquises et des difficultés de spécification d'un SID ouvert sur l'horizon à 360 degrés.

La quatrième et dernière limite que je citerai ici est le passéisme. Car l'une des caractéristiques majeures des systèmes de BI est de fonctionner sur un stock de données essentiellement historique et déphasé par rapport à l'instant présent. Le contenu informationnel des grands SID actuels comporte deux composantes:

les données statiques, ou référentielles, qui décrivent les éléments du système opérant les moins variables (structure de l'entreprise, produits...);
les données dynamiques, ou événementielles, qui reflètent l'activité (transactions).

Les données dynamiques sont elles-mêmes très incomplètes, car le système d'information capte essentiellement, voire exclusivement, des flux comptables, et les événements non financiers lui échappent généralement, ce qui limite d'emblée le potentiel tactique et stratégique de l'information.

Le passéisme n'est pas un handicap au regard des objectifs traditionnellement assignés au SID, car il n'est pas utile de disposer de données instantanées pour analyser et prévoir à moyen terme. En revanche, il serait susceptible de pénaliser l'utilisateur si, comme on peut s'y attendre, le besoin d'outils d'aide à la décision immédiate (plus proches des systèmes de commandement auxquels j'ai fait allusion plus haut) commence à se répandre. En effet, la cohabitation d'un SID "historique" et d'un SID "de l'intant présent" serait difficle à avaler. La vogue de la réingénierie des processus opérationnels sera sans doute un accélérateur de l'évolution dans ce domaine. Elle a déjà par exemple suscité le concept de business activity monitoring (BAM), une application typiquement décisionnelle, qu'on n'aurait pas intérêt à laisser se développer en-dehors du SID. Dans certains métiers d'ailleurs, on utilise depuis plus d'une décennie des outils décisionnels qui combinent l'historique avec la donnée en temps réel (c'est le cas par exemple sur les marchés de capitaux, où les opérateurs combinent en permanence des informations de cotation immédiate avec des séries historiques à grande profondeur). Là aussi, la technologie est au rendez-vous, notamment grâce à l'EAI qui, sans avoir jusqu'à présent tenu ses promesses en matière d'unification du système d'information, a du moins apporté des composants logiciels qui permettent ou permettront au SID de faire face à l'événement immédiat tout en tirant parti de son fonds historique.

Le Corporate Performance Management (CPM) tend depuis peu à s'imposer dans le vocabulaire des éditeurs de logiciels et des cabinets de conseil. Le CPM se définit comme l'ensemble des méthodes et des outils destinés à contrôler les performances globales d'une organisation et à assurer l'alignement des processus opérationnels sur la stratégie. Il combine notamment l'arsenal de la business intelligence "historique" avec celui de la planification budgétaire. La boucle de rétroaction qui lie information, décision et action en est l'un des principes essentiels, ainsi que la garantie de cohérence entre les niveaux de décision stratégique, tactique et opérationnel. À condition toutefois qu'on ne réintroduise pas certains vieux cloisonnements entre information et action, par exemple au travers de la distinction entre CPM analytique et CPM opérationnel que proposent certains acteurs. Dans l'idéal, le CPM mettrait à la disposition du décideur une sorte de cockpit intégré fournissant à la fois les indicateurs pertinents en temps réel, les outils de planification et les leviers de commande. Comme à chaque fois qu'un concept nouveau est lancé sur le marché, le CPM est concurrencé par diverses expressions plus ou moins équivalentes, telles que l'Entreprise Performance Management (EPM) ou encore le Business Performance Management (BPM) [10]. mais c'est lui qui semble tenir le flambeau. S'agit-il d'une nouvelle mode verbale ou d'une nouvelle approche de l'information décisionnelle ? Les deux, sans doute. La vision est ambitieuse, mais finalement assez classique. Les mêmes idées étaient dans l'air, exprimées d'autres manières, lors du décollage de l'ERP et du data warehouse et elles se retrouvent aussi un peu dans le BAM. Mais la question de la mise en oeuvre pratique du CPM reste entière. Le CPM est présenté par ses promoteurs comme "non intrusif", c'est-à-dire capable d'utiliser les systèmes d'information existants sans les bouleverser. Cependant il ne peut tenir ses promesses que si le "cockpit" reçoit des données homogènes, fiables et synchrones. S'il ne fait que s'installer sur un archipel d'applications informatiques cloisonnées, le CPM se développera dans les mêmes limites et produira les mêmes résultats que les systèmes décisionnels "classiques". Ou bien il restera cantonné dans des périmètres "départementaux" (et ne méritera donc pas le qualificatif "corporate"), ou bien il représentera le volet décisionnel de changements beaucoup plus importants, affectant l'organisation autant que l'informatique. Le CPM n'est donc pas dissociable d'une réingénierie des systèmes d'information et des processus opérationnels... ce qui fait de lui un projet nécessairement "intrusif".

On peut enfin citer une dernière contrainte, d'ordre technique mais dont l'impact stratégique n'est pas négligeable: l'effort de modélisation logique et physique préalable des données qu'imposent généralement les requêtes décisionnelles complexes. Cet effort pèse sur les équipes informatiques non seulement dans les phases de déploiement initial, mais surtout de manière récurrente pendant toute la durée d'utilisation du SID, compromet sa flexibilité et joue négativement sur son bilan économique à moyen terme. Toutefois, de nouvelles technologies tendent depuis peu à éviter cet écueil: il s'agit des systèmes de gestion de bases de données orientés contenu.

En bref, la business intelligence, malgré ses quelques années d'existence, n'est pas au bout de son évolution. On peut même dire qu'elle est encore loin de la maturité.

[1] F. Bournois, P-J. Romani, L'intelligence économique et stratégique dans les entreprises françaises, IHEDN, Economica, 2000. Une autre définition a été proposée par Alain Juillet, responsable de l'intelligence économique auprès du Premier Ministre : "l'intelligence économique est la maîtrise et la protection de l'information stratégique qui donne la possibilité au chef d'entreprise d'optimiser sa décision" (voir entretien accordé à 01 Informatique en juin 2004). Je la trouve un peu trop centralisatrice et défensive.

[2] "L'intelligence économique en France : les incertitudes du marché", Archimag, 2004

[3] "Intelligence économique et stratégique, les systèmes d'information au coeur de la démarche", CIGREF, 2003

[4] "Intelligence économique, compétitivité et cohésion sociale", Rapport au Premier Ministre de Bernard Carayon, député du Tarn, 2003

[7] P. Muckenhirn, "Le système d'information décisionnel, construction et exploitation", Lavoisier, 2003

[8] À la limite, je doute même que la notion de donnée non structurée ait un sens. Pour moi, le "non structuré" relève plutôt de l'univers des idées non formulées, des perceptions et des sentiments. Et encore, je ne suis pas sûr que les psychologues et les cogniticiens seraient unanimes sur ce point.

[9] eXtensible Markup Language. Plutôt que d'un langage, il s'agit d'une grammaire évolutive permettant de décrire toute espèce d'information, notamment les informations dont la structure n'est pas figée et connue à l'avance. Il est intéressant de constater qu'une unité cohérente d'information représentée en XML est toujours appelée un document, quelle que soit sa structure.

[10] A ne pas confondre avec les autres "BPM" que sont le Business Process Management ou le Business Process Modeling.