P ROJETS EN COURS EN RELATION AVEC LE DATAMINING

2.1.2.1 PROJET HERACLES

A l'avenir, une meilleure connaissance de l'objet ou du sujet fiscal doit permettre des contrôles et des recouvrements plus ciblés, avec une assistance plus efficace. Cette connaissance couvre la collecte, le traitement et l'analyse des données, dans le but de distinguer les catégories d'objets et de sujets fiscaux, avec leurs besoins spécifiques et les opérations à effectuer ou non.

Elle permet de mettre au point des profils et d’organiser efficacement les opérations de contrôle, d’assistance, d’encaissement et de règlement des litiges, en fonction des risques. Les données opérationnelles seront disponibles en tant que telles dans l’architecture, par le biais d’un data warehouse, au sein d’un environnement analytique. Ce data warehouse servira à réaliser des analyses en fonction de la gestion des risques, de l'image du client/citoyen et de l'encaissement fiscal.

Parallèlement, le data warehouse autorise différentes approche intégrées du citoyen, via les datamarts. Exemple: une image du citoyen basée sur ses données patrimoniales, sur les informations fiscales...

Les résultats de ces analyses et des profils seront comparés avec les données opérationnelles, en particulier les données des déclarations.

Les résultats des comparaisons et des analyses seront mis à la disposition des utilisateurs via le système de traitement intégré des données et dans les applications destinées aux agents du SPF Finances.

À partir de l'environnement opérationnel, on pourra émettre un feedback électronique à destination de l'environnement analytique. Ce feedback servira à affiner les profils de risque et l'analyse des actions en matière d'assistance, de contrôle, d'encaissement, de recouvrement et de contentieux.

En outre, les technologies de BI (environnement data warehouse, datamining) connaissent un développement rapide et gagnent en importance. Le projet TBT (tableaux de bord pour le management) a mis en évidence les possibilités d'un environnement de data warehouse, plus précisément dans le cadre d'une analyse du type 'tableaux de bord'. Le projet datamining a permis un premier test à l'aide de modèles de datamining, en particulier en ce qui concerne la fraude à la TVA.

Grâce au projet Agora, une étude a porté sur l'impact d'un environnement data warehouse dans la lutte contre la fraude. Ces projets soulignent l'importance croissante que prendront les systèmes liés aux technologies du type Business Intelligence. Le SPF Finances constate aussi la nécessité de coordonner et d'optimiser le recours à ces technologies (data warehouse, outils d'analyse, gestion des métadonnées) dans un souci de cohérence, d'efficacité et de clarté.

Le SPF Finances dispose d'un environnement de Business Intelligence. Une première mise en œuvre d'un système data warehouse - datamining est en cours dans le cadre de l'introduction de la gestion des risques pour le contrôle, l'assistance et le service.

Cet environnement possède les fonctionnalités suivantes :

• aide à l'analyse des données et à la prise de décision o recherche et analyse multidimensionnelles o exploitation des données et des résultats d'analyse

ƒ analyse des risques

ƒ réservoir d'information (provenant des sources d'information du SPF Finances et de sources externes)

ƒ traitement standardisé et non standardisé

L'environnement de business intelligence est intégré dans l'architecture technologique définie pour le SPF Finances. Il répond aux normes fixées par le SPF dans le cadre de la révision de son infrastructure technologique. On pourra consulter les standards sur le site internet du SPF Finances.

Le SPF Finances a revu son système informatique, notamment en lançant de vastes projets d'infrastructure qui constituent les pierres d'angle de l'infrastructure informatique. La description générale de l'architecture technologique du SPF Finances est disponible sur le site internet du SPF. Dans le cadre de la mise à jour de l'infrastructure technologique du SPF Finances, de grands projets de consolidation ont vu le jour (ATLAS pour un stockage homogène, RDC - Relational Data Center pour une plate-forme RDBMS unique…).

La figure ci-dessous illustre l'architecture BI livrée suivant les spécifications du premier cahier des charges 'Environnement Business Intelligence, data warehouse et analyse des risques'. Le schéma représente l'environnement de production.

Parallèlement, on a aussi installé un environnement comparable pour le développement et les tests dans le cadre du premier cahier des charges 'Environnement Business Intelligence, data warehouse et analyse des risques'.

Output Input

Architecture Production

Le Back-end reposera sur des outils IBM. La base de données IBM DB2 a été retenue en tant que base de données relationnelle. Cet environnement a ensuite connu une série d'extensions. On a choisi IBM DB2 Cube Views pour supporter l'analyse multidimensionnelle. On a par ailleurs installé les outils ETL d'IBM/Ascential. Les outils comprennent :

IBM Websphere Datastage (ETL)

IBM Websphere ProfileStage (analyse des données sources)

IBM Websphere QualityStage ('matching' avancé des données, data survival) IBM Websphere MetaStage (tenue des données relatives aux données) IBM Business Glossary

En vue de la mise en place de flux de données en temps réel, on a retenu le composant RTI (Real Time Integration), qui fait aussi partie d'IBM Websphere.

L'outil ETL permet d'accéder aux sources internes et externes du SPF Finances, mises à disposition de différentes façons par le SPF. Les jobs ETL traitent les données dans la Staging area (une combinaison de fichiers et de base de données DB2) puis les chargent dans le data warehouse RISK et les datamarts pour les 9 piliers du SPF Finances. Les datamarts sont appelés 'DEPENDENT DATAMARTS' parce qu'ils ne sont alimentés que par une seule source de données, le data warehouse RISK.

L'architecture actuelle permet aussi de créer des datamarts dont toutes les données ne proviennent pas du data warehouse RISK (mais aussi de sources de données extérieures).

Par ailleurs, les jobs ETL peuvent aussi alimenter/tenir la SANDBOX. La SANDBOX (ou 'SQL LAB') est l'environnement de

ATATLLAASS ((SSUUNN SSoollaarriiss)) Internal

BULL IBM

SIEMENS External

W

WIINNTTEELL ((WWiinnddoowwss 22000033 SSeerrvveerr))

Staging Area

Data Mart

Sand box

Sharepoint Services

Traitement intégrés

Reporting Services

Analysis Services

(ROLAP) Risk

Management

Tool

Scheduling tool (VTOM) / Monitoring tool (HP Openview) / Backup tool (Legato) / Identity Management & Auditing (SUN) / Versioning (StarTeam) End-User

Metadata

Tool

R: Risk

TOOL

Repos End-user

____________

Technical

Metadata

tool

Microsoft

Office

Web

Components MS OFFICE BI Development Studio Report builder Clementine

Output Generation

Tool

•

tage

•

Stage

•

R T

TOOL

Repos TOOL

Repos PES

Repos

+ C+Cuubbeevviieewwss Clementine

Server

Les outils de Reporting et OLAP proviennent de chez Microsoft. Microsoft Analysis Services se greffera sur le data warehouse DB2 et les bases de données DM. Ces services formeront aussi une couche sémantique pour les composants du client Microsoft (MS Office, Reporting Services, etc).

En guise d’outils de datamining, on a retenu SPSS pour ce projet.

Tous ces composants de base sont intégrés à l'aide des outils de gestion suivants :

• l'outil de scheduling VTOM

• l'outil de configuration/versioning StarTeam

• l'outil de monitoring HP OpenView

• l'application de back-up Legato

• Identity Management - gestion des identités

Le projet permet déjà de prendre en compte les spécificités de chaque entité et de chacun des piliers du groupe (pour les entités et piliers concernés par les deux premiers releases). Le projet remplit donc la quatrième priorité du plan quinquennal, à savoir la réponse aux besoins internes du département.

La solution datamining proposée doit s’intégrer dans le cadre de l’architecture du Datawarehouse Analyse de Risques.

2.1.2.2 PROJETS DE DATAMINING

Les différents services présentés ont des projets de datamining en cours, selon leurs missions.

Ceux-ci ne seront pas détaillés, du fait de la sensibilité des matières étudiées.

On peut cependant donner une estimation du nombre des modèles utilisés actuellement:

2.1.2.2.1 CELLULE DATAMINING TVA

11 modèles sont utilisés actuellement, nombre qui sera porté à 12 dans les mois à venir.

La complexité de ces modèles peut être très grande, par exemple voici quelques données quantitatives en ce qui concerne une itération DM TVA (chaque année il y a une itération) :

• env. 600 nœuds dans les streams

• env. 80 tables

• la plus grande table comporte presque 40 millions de records

• env. 100 streams (inclusivement les streams mentionnés pour PHP et Reporting)

• quelques streams (Clementine) utilisent des scripts

• 15 fichiers sources

• environ 90 variables indépendantes Il y a aussi

• une série de streams (actuellement Clementine) pour le PHP «Feedback»;

• une série de streams pour le Economic Reporting (i.c. MS Reporting Services).

2.1.2.2.2 DIRECTION II/7

Aucun modèle de datamining pur utilisé, rôle de gestion/manipulation/préparation des données 2.1.2.2.3 OCS

7 modèles actuellement en utilisation régulière.

2.1.2.2.4 SERVICE GESTION DES RISQUES AU SEIN DE LA DOCUMENTATION PATRIMONIALE 5 modèles de complexité variable

2.1.2.2.5 DCU/DSU

SPSS sources Clementine

Nombre d'agents # syntaxes #commandes #variables #records #streams #nodes

6 53 3.990 5.402 819.701.881 40 824

2.1.2.2.6 DOUANES ET ACCISES

Aucun modèle de datamining pur utilisé, rôle de gestion/manipulation/préparation des données 2.1.2.2.7 ARECDIRECTION III/4

SPSS sources

Nombre d'agents # syntaxes #commandes #variables #records #streams #nodes

10 1.238 16.780 4.854 1.005.000.000 53 682