Vitrine de la RDC
B.P. 190 KINSHASA – XI
KATALAY MATUNGULU Jonathan
Gradué en Sciences
Mémoire de fin d’Etude présenté et défendu en vue de l’obtention du titre de Licencié en Sciences.
Groupe : Informatique
Option : Gestion
Sous la direction du Professeur Docteur :
KAFUNDA KATALAY Pierre
Année-Académique 2017-2018
EPIGRAPHIE
Oui, le bonheur et la grâce m’accompagneront tous les jours de ma vie et j’habiterai dans la maison de l’éternel jusqu’à la fin de mes jours
PSAUMES 23 :6
DEDICACE
Au créateur de cieux et de la terre, Seigneur Jésus-Christ, Dieu tout Puissant, l’assurance de ma vie, lui qui dit un mot et la chose S’accomplie, il est mon salut.
A mes très chers parents spirituels, Daddy et Mommy NGOY KABUYA, car Nous qui étions sans valeur, grâce à leurs révélations, nous sommes dans Le chemin de la délivrance et aujourd’hui, leur Dieu a roulé de dessus
De moi l’opprobre de ma famille.
A mes chers parents, MATUNGULU KALALA CALO et BUMBABO MAYIBA MARIE CLAIRE qui en tant que premiers éducateurs ne pouvaient avoir une minute de repos sans avoir pensé à notre formation intégrale.
Je dédie ce travail.
REMERCIEMENT
Au terme de notre second cycle universitaire, l’opportunité nous est permise D’adresser nos sentiments de reconnaissance à tous ceux qui, de diverses manières, ont Contribué à notre formation intellectuelle.
Au professeur Pierre KAFUNDA KATALAY, directeur de ce travail, qui malgré ses
multiples occupations nous a offert sa disponibilité et sa direction ; mais aussi et surtout à Tshimuni Hervé, dont les orientations et la rigueur nous ont guidés à alimenter nos réflexions.
Nos remerciements sont adressés également à monsieur Emile MUBAMBA
Directeur au département du commissariat d’avarie, qui nous a facilité l’accès
aux données utiles à la réalisation de ce travail.
A mes frères : Prince Matungulu, Glody Matungulu, Arsène Matungulu, Josué
Matungulu
Nos remerciements s’adressent enfin à tous ceux qui d’une manière ou d’une autre ont été un support moral, spirituel et intellectuel tout au long de notre parcours sur la colline inspirée. Nous citons : Aristote Bassayi, Jessy Mutombo, Crédo Lialia, Aristote Mavungu , Salomon Ntumbabo ,Benjamine Temuna ,Derick Makumba, José Ifasso , Jude Dikana, Arnold Dikana, Paul Kanyiki, Fabrice Vunduawe, Armel NZUZI, Bénie BOKUNGU, Ruth Muadi, Sephora Lesambo, Berka Mengi, Christian Mbenda ,Glody Bobele ,Glody Ilongoy , Rex Ilonga, , Christian Kalonda, Jaures Kashila, Hillary Mbuyi, que tous ceux dont notre plume ingrate a mis dans les oubliettes, par économie de place et qui ont contribué de près ou de loin à ce travail, trouvent nos remerciements.
LISTE DES ABREVIATIONS
OCC : Office congolais de contrôle
S.I : Système d’information
POS : Plan d’Occupation des Sols
MOA : Maîtrise d’Ouvrage MOE : Maîtrise d’Œuvre B.I : Business Intelligence
ETL : Extract Transform Load
OLAP : OnLine Analysis Processus
OLTP : OnLine Transactional Processing
SGBD : Système de Gestion de Base de Données
KDD : Knowledge Discovery in Databases
ECD : Extraction des Connaissances à partir des Données
CRM : Customer Relationship Management
CDH : Classification Descendante Hiérarchique
MERISE : Méthode d’Etude et Réalisation Informatique par le Système d’Entreprise
UML : Unified Modeling Language
MCD : Modèle Conceptuel des Données MLD : Modèle Logique des Données SSMS : SQL Server Management Studio SSAS : SQL Server Analysis Service
SSIS : SQL Server Integration Service SSRS : SQL Server Reporting Service SQL : Structured Query Language
LISTE DES FIGURES
Figure 1. La diversité du SI ………………………………………………………………………………………………….5
Figure 2. La dimension managériale …………………………………………………………………………………..7
Figure 3. La diversification des ressources ………………………………………………………………………....8
Figure 4. Les fonctions de SI ……………………………………………………………………………………………….10
Figure 5. Les 4 visions du système d’information (Urbanisation des systèmes d’information)…………………………………………………………………………………………………………………….14
Figure 6. Parallélisme entre urbanisation d’une ville et celle des systèmes……………………….15
Figure 7. Les différentes architectures de système d’information………………………………………20
Figure 8. Architecture d’un système décisionnel…………………………………………………………………27
Figure 9. Architecture d’un entrepôt de données……………………………………………………………...30
Figure 10. Organigramme de l’OCC…………………………………………………………………………...........47
Figure 11. Diagramme d’Ishikawa de l’OCC……………………………………………………………………….48
Figure 12. Cartographie de la vue métier de l’OCC……………………………………………………………50
Figure 13. Cartographie de la vue fonctionnelle de l’OCC………………………………………………….54
Figure 14. Cartographie de la vue fonctionnelle cible………………………………………………………..55
Figure 15. Cartographie de système d’information …………………………………………………………...57
Figure 16. Flux d’information circulant entre divers processus…………………………………………..58
Figure 17. Détermination de la trajectoire…………………………………………………………………………59
Figures 18. Schéma MCD…………………………………………………………………………………………………...64
Figures 19. Schéma MLD…………………………………………………………………………………………………….65
Figures 20. Le diagramme de cas d’utilisations ………………………………………………………………….66
Figures 21. Le diagramme de classe…………………………………………………………………………………..66
Figures 22. Le diagramme des séquences…………………………………………………………………………..67
Figures 23. Le diagramme d’activités…………………………………………………………………………………67
Figures 24. La base de données de l’application…………………………………………………………………68
Figures 25. La modélisation multidimensionnelle………………………………………………………………69
Figures 26. La vue de source de données………………………………………………………………………….70
Figures 27. Le cube de l’application…………………………………………………………………………………..70
Figures 28. Déploiement du cube………………………………………………………………………………………71
Figures 29. Tableaux synthèse de contrôle de marchandise……………………………………………..72
Figures 30. Tableaux synthèse de marchandise contrôle ainsi que leur quantité………………72
Figures 31. Histogramme de marchandise contrôle ainsi que leur quantité……………………..73
Figures 32. Les interfaces utilisateurs……………………………………………………………………………….73
LISTE DES TABLEAUX
Tableau 1. Comparaison entre les données opérationnelles et décisionnelles…………………36
Tableau 2. Découpage du système d’information…………………………………………………………….53
Tableau 3. Dictionnaire des données……………………………………………………………………………….63
0.1. Aperçu théorique
Introduction
Le système d’information est aujourd’hui au cœur du fonctionnement de toute organisation, et son efficacité en conditionne les performances. Depuis une vingtaine d’années, le système d’information connait une imbrication et un empilement d’application ainsi que de nombreux développement spécifiques qui rendent leur évolution et leur maintenabilité coûteuses. Il apparaît une prise de conscience des Directeurs Générales et des Directeurs informatiques de la nécessité de décomplexifier et de modulariser le système d’information afin d’en simplifier la gestion, de le rendre plus rapide pour qu’il réponde mieux aux besoins métiers, en résumé, un système d’information plus évolutif est moins coûteux. Ainsi, l’urbanisation du système d’information est considérée comme une démarche bénéfique pour une entreprise qui veut piloter son système d’information et pour rendre son système d’information plus
évolutif.
En effet, les technologies de l’information nous génèrent une multitude de données comme jamais auparavant. Le problème n’est donc plus tant d’acquérir une masse de données mais de l’exploiter. Pour cela, il faut collecter les données de qualité, la normaliser, la classer, l’agréger et l’analyser pour l’exploiter afin d’en extraire une connaissance en vue de prendre la bonne décision au bon moment. Il s’agit ici de s’intéresser aux besoins des décideurs, à savoir, transformer les données en connaissance voir en prévision c’est-à-dire en information. Dans ce but, il est nécessaire de mettre en place un système particulier appelé « système décisionnel ». Ce système doit permettre de prendre de manière simple les chiffres recueillis pour mettre en lumière la conjoncture actuelle et indique la voie à suivre.
0.2. Problématique
En effet, La problématique de départ liée au concept d’urbanisation de système d’information est d’étudier comment refaire, moderniser et profiler des avancées technologiques, sans faire table rase du passé, et tout ceci dans une optique de limiter les coûts. Ainsi, concernant notre travail, la problématique qui se pose dans cette partie est la suivante : comment continuer à faire évoluer le système d’information de l’ « office congolais de contrôle »? Nous avons constaté au niveau du processus de pilotage, la grande partie de tâche qui se font manuellement, il y a l’absence d’un système informatique de gestion fiable et capable de gérer les informations et surtout lors de la transmission de documents administratifs et de certains rapports de terrain ce qui constitue un danger permanent pour cette institution, raison pour laquelle dans ce travail, nous tenterons de répondre aux questions suivantes :
▪ Comment continuer à faire évoluer le système d’information de
« l’Office Congolais de Contrôle » ?
▪ Comment aider le décideur à prendre la décision lors de
l’importation des produits ?
▪ Comment rendre son système informatique fiable ?
0.3. Hypothèse
Une hypothèse est une proposition des réponses aux questions que l’on
pose à propos de l’objet de la recherche.
Partant de cette définition et compte tenu de multiple questions posées à la problématique, notre hypothèse consiste à faire le découpage de système d’information de l’Office congolais de contrôle, grâce à l’urbanisation de système d’information. Ensuite notre étude sera basée au « département d’exploitation dans son opération sur le commissariat des avariés » et ici, nous proposons la mise en place d’un système décisionnel qui permettra au pilotage de cette entreprise à prendre de décisions optimales lors de contrôle et vérification des marchandises à l’importation.
0.4. Choix et Intérêt du sujet
Notre sujet s’intitule « Urbanisation d’un système d’information et
prise de décisions à l’aide des outils de Business Intelligent »
La motivation vient des quelques soucis rencontrés lors de mon stage à la direction générale de l’Office Congolais de Contrôle. Dans le souci de faciliter le partage des informations et la gestion des agents avec l’urbanisation de système d’information et le système décisionnel.
0.5. Délimitation du sujet
Pour répondre aux normes scientifiques, nous sommes dans l’obligation de limiter notre travail dans le temps et dans l’espace, c’est-à-dire le domaine d’urbanisation de système d’information que nous avons choisi a plusieurs architectures mais nous nous sommes limités seulement sur l’architecture métier et l’architecture fonctionnelle.
o Dans le temps : notre étude est faite durant la période allant du mois de février
2019 au mois de mai 2019 ; cette période nous a permis de récolter les données
nécessaires à l’élaboration de ce travail scientifique.
o Dans l’espace : ici nous sommes bornés que sur le découpage du système d’information et ensuite la mise en place d’un système décisionnel, ceci fait l’objet de département d’exploitation précisément dans le commissariat des avaries.
0.6. Méthode et techniques utilisées
(1) Méthodes
Une méthode de travail est une marche à suivre pour réussir, ou, en abordant le travail sous un angle, elle est l’approche d’un problème. Dans le cadre de notre travail, nous avons utilisé les méthodes suivantes :
o Méthode Analytique : elle nous facilite l’étude des documents existants ;
o Méthode structuro-fonctionnelle : elle nous facilite la compréhension sur les attributions de différents services ;
(2) Techniques
Une technique est un rassemblement des procédés propres à un art. Dans le cadre de travail nous avons utilisé les techniques suivantes :
o La technique d’interview : nous avons eu à converser par jeux de questions réponses ;
o La technique documentaire : qui nous a aidé à consulter certains
ouvrages, revue, afin d’enrichir notre travail.
0.7. Difficultés rencontrées
Pour élaborer ce travail nous avons rencontrés les difficultés suivantes : lenteur de réponse de l’administration de l’entreprise, la rareté de certains documents dans notre domaine de travail.
0.8. Subdivision du travail
Outre l’introduction et la conclusion, le présent travail est reparti en quatre chapitres, à savoir :
o Le système d’information ;
o Urbanisation de système d’information ;
o Le système décisionnel ;
o L’application.
Chapitre I. Généralités système d’information [2], [5]
I .1 Définitions [2], [5]
Un système d’information est un système d’acteurs sociaux qui mémorise
et transforme des représentations via des technologies dès l’information et des modes opératoires.
Le système d’information de l’entreprise est la partie réelle constituée d’informations organisées, d’évènements ayant un effet sur ces informations et d’acteur qui agissent sur ces informations ou à partir de ces informations selon des processus visant une finalité de gestion et utilisant les technologies de l’information
Le système d’information est un ensemble organisé de ressources
matériels, logiciels, personnel, données, procédures etc…permettant d’acquérir, de traiter, de stocker des informations (sous forme de données, texte, images, son, etc…) dans et entre des organisations pour communiqué ou diffuser.
Le système d’information (SI) utilise de moyen humains matériels et méthodes :
➢ Les moyens humains sont composés de l’ensemble de personnes qui reçoivent, manipulent et émettent l’information (les utilisateurs, les concepteurs y compris) ;
➢ Les moyens matériels sont constitués de l’ensemble des machines, des degrés de technique plus au moins poussée, permettant de recevoir, des manipuler et émettre l’information. Ex : machine à écrire, machine à calculer, photocopieuses, télécopieurs, ordinateurs, papier, moyens de télécommunication, support de stockage etc.… ;
➢ Les méthodes sont l’ensemble d’outils de travail et de règles permettant de résoudre les différents problèmes de gestion.
I.2 Les différentes formes d’informations [2], [5]
➢ Les formes d’information manipulées par le système d’information sont très variées ;
➢ L’information écrite, structurée ou non, ayant pour origine des moyens
d’expression humains ou non ;
➢ L’information picturale, structurée ou non, ayant pour origine des moyens
d’expression humaine ou non ;
➢ L’information orale ou sonore, structurée ou non ayant pour origine des moyens d’expression humains ou non ;
➢ Les autres formes d’information : l’information tactile, l’information
olfactive etc.
I.3 Les dimensions d’un système d’information
I.3.1 la dimension informationnelle
Le SI dans sa dimension informationnelle est composé de sa nature, sa diversité et ses qualités
A. Nature
Les SI contiennent des informations sur des personnes, des évènements, des lieux et des objets importants dans l’organisation ou dans l’environnement. L’information est un renseignement qui apporte une connaissance, elle recouvre les données qui sont présentes sous une forme utile et utilisable par les personnes.
Les données, au contraire, sont des valeurs à l’état brut représentant des évènements qui ont lieu dans ou en dehors des organisations. Elles n’ont pas été organisées de façon à ce que les utilisateurs puissent les comprendre et s’en servir.
B. Diversité
L’information n’a de valeur qu’en raison de l’usage qui en est fait.
Sa diversité
L’information est un
support de processus
de l’entreprise
L’information est un support de cohésion sociale
Rôles de
l’information
L’information est un instrument de communication dans l’entreprise
L’information est un instrument de liaison avec l’environnement
L’information est un support de la connaissance individuelle
Figure 1. La diversité du SI
C. Critères de qualité
➢ La pertinence
➢ La fiabilité
➢ La disponibilité
➢ La confidentialité
➢ La valeur
➢ L’efficacité
➢ Etc.
I.3.2 La dimension organisationnelle
L’entreprise est organisée autour de processus empreints d’informations :
➢ L’information dans le processus :
o Un processus correspond à un ensemble d’activité ou d’opération, fonctionnellement liées par la production d’un résultat indéniable.
o L’évènement est alors un fait significatif donc l’apparition va déclencher une réponse dans l’organisation sous forme de déroulement d’activité, et de taches, d’opérations
➢ L’information entre processus :
o L’organisation est représentée par un ensemble de processus
interdépendants
o Ils peuvent être de nature opérationnelle (activité liée à la mission de l’organisation, par ex : réaliser une vente) ou managériale (activité liée au processus opérationnel de l'organisation par ex : comptabiliser le vente
I.3.3 La dimension managériale [2]
Les besoins en termes d’information diffèrent selon la position
hiérarchique du décideur
Dirigeant cadre supérieur
Cadres moyens contrôleurs
Gestionnaires d’opérations
Figure 2. La dimension managériale [2]
A. Stratégique
L’information d’origine externe principalement :
et le futur
Résumée, en champ large, peu répétitive, orientée vers le passée, le présent
B. Gestion, Tactique, Contrôle
Information d’origine interne surtout :
Agréger, champ limité à un domaine, périodicité orientée vers le présent et le passé proche.
C. Gestion des opérations
Information d’origine interne :
le présent.
Détaillée, champ restreint, répétitive, temps de réponse court, orientée vers
I .3.4 La dimension technologique
À la cour de deux dernières décennies, l’informatique a suivi une voie
strictement technique et opposée aux principes de pascal.
Les notions de système d’information peuvent être considérées comme une réaction contre cette déviation et comme un retour vers les besoins des utilisateurs : fiabilité, convivialité, transparence de l’outil, utilité réel, sens du concret…mais aussi l’intelligence artificielle (du moteur de recherche au jeu de go…)
Le management des SI est confronté à de problèmes de plus en plus complexes du notamment à :
➢ La multiplicité, l’hétérogénéité et l’obsolescence accélérée des matériels et
des logiciels ;
➢ L’explosion des phénomènes réseaux et télécommunications ;
➢ La diversification des niveaux d’intervention (holding, division direction,
groupe de travail, individu) ;
➢ L’explosion des besoins des utilisateurs tant pour les SI collectifs qu’individuels ;
➢ Les contraintes budgétaires renforcées ;
➢ La nécessite d’intégrer la stratégie de SI à la stratégie de l’organisation soit
comme support de cette stratégie soit comme arme de cette stratégie.
Evolution technologique : la diversification des ressources
Figure 3. La diversification des ressources (Source : Wikipédia .com)
I.4. les sous-systèmes d’un Système d’information
L’entreprise peut se décomposer en trois sous-systèmes :
➢ Le système de décision ou (pilotage) ;
➢ Le système d’information ;
➢ Le système opérant ;
I.4.1 Le système de pilotage ou décision (SP) [5]
Il exploite les informations qui circulent au sein de l’entreprise, il organise le bon fonctionnement du système, il décide des actions à conduire sur le système opérant et raisonne en fonction des objectifs et des politiques de l’entreprise.
I.4.2 Le système d’information (SI) [5]
C’est un système qui est chargé d’alimenter l’entreprise en informations (d’origine interne ou environnementale), de mémoriser ces informations en vue d’un besoin futur, de les traiter pour une meilleure compréhension et enfin de les communiquer aux autres sous - systèmes auxquels il est relié.
I.4.3 Le système opérant (SO) [5]
Le système opérant est un sous -système de l’entreprise qui assure le fonctionnement de l’entreprise en réalisant la production physique de biens ou services internes et externes.
Il reçoit les informations émises par le SP, et se charge de réaliser les taches qui lui sont confiées.
Il génère à son tour des informations en direction du système de pilotage donc il englobe
toutes les fonctions liées à l’activité propre de l’entreprise.
I.5. Rôles et fonctions du système d’information [2], [5]
I.5.1 Les rôles d’un système d’information
➢ Le système d’information aide à la prise de décision. Il met à la disposition des décideurs les information nécessaires à la prise de décision qui permet d’étudier les conséquences prévisibles des décisions, et fournit les informations, portant sur le futur ;
➢ Le système d’information permet de contrôler l’évolution de l’organisation, de détecter les dysfonctionnements internes, et les situation anormales . Ainsi, il est la mémoire collective de l’organisation en gardant une trace d’information partant sur le passé ;
Sa finalité est d’apporter un soutien aux processus de travail dans l’organisation (processus métier) selon trois modalités principales : fournir de l’information, assister le travail humain et automatiser le travail.
I.5.2 Les fonctions d’un système d’information
➢ L’acquisition ou le récolte de l’information : c’est le fait d’enregistrer une
information (support papier ou informatique) avant son traitement ;
➢ Le Stockage de l’information : c’est le fait de conserver l’information et sa protection soit du disque dur à l’entrepôt de données avec des dispositifs de sécurité ;
➢ Le Traitement de l’information : c’est la transformation et l’enrichissement d’une information en une nouvelle information ;
➢ La diffusion de l’information : mise à disposition de l’information auprès des
utilisateurs et conformément à leurs besoins.
Figure 4. Les fonctions de SI
I.6. Typologie d’un système d’information
La diversité des structures internes et des moyens dont disposent
l’entreprise est à l’ origine de la diversité des types de systèmes d’information.
❖ Typologie basée sur le degré de formation des moyens ;
❖ Typologie basée sur le critère du nouveau nombre d’utilisateurs : le système d’information doit offrir à plusieurs les moyens d’accéder à une information sure et fiable ;
❖ Typologie basée sur le critère du niveau de décision : qui est un type de système d’information destiné au personnel de direction de l’entreprise, permettant d’interroger des manques de données ,d’analyse, des modèles, etc.
❖ Typologie basée sur le critère de degré d’automatisation ;
❖ Le système d’information manuel : toutes les opérations sur l’information sont assurées par l’être humain sans l’intervention de la machine. C’est un système d’information révolu ;
❖ Le système d’information mécanisé : ici certaines opérations sûres sont
réalisées à l’aide des machines électromécanique spécialisées ;
❖ Le système d’information automatisé : avec ce système d’information, les opérations les plus significatives sur les informations sont assurées par des machines électroniques programmables effectuant des traitements automatiques.
I.7 conclusion
À la cour de deux dernières décennies, l’informatique a suivi une voie
strictement technique et opposée aux principes de pascal.
Les notions de système d’information peuvent être considérées comme une réaction contre cette déviation et comme un retour vers les besoins de l’utilisateur : fiabilité, convivialité et transparence de l’outil… la nécessite d’intégrer la stratégie de système d’information a la stratégie de l’organisation soit comme support de cette stratégie soit comme une arme de cette stratégie
Chapitre II. Urbanisation de système d’information [1], [2], [4], [6], [12], [13]
II.1 Urbanisation de système d’information [12], [13] II.1.1 Introduction
L’urbanisation des systèmes d’information est née vers les années 80 en
France dans le secteur bancaire et la démarche d’urbanisation est née de la volonté d’avoir un système d’information évolutif et peu couteux.
En effet, la plupart des évolutions au sein d’un SI se révèlent être couteuses et impactent souvent les autres composants du système entrainant ainsi des problèmes de cohérence et des freins à l’amélioration du système s’information.
Par ailleurs, l’évolution constante du SI engendre des redondances de
fonctionnalités et des chevauchements des flux de communication.
Au final, on se trouve avec un système d’information non conforme avec les processus métiers de l’organisation. La démarche d’urbanisation permet de
« ranger » son système d’information. Il s’agit d’établir ou ré-établir une relation entre les systèmes d’informatiques et la stratégie de l’entreprise. Le but étant de pouvoir intégrer progressivement les demandes d’évolutions du système d’information par approche rationnelle.
II.1.2 Origine et importance de l’urbanisation de SI [12], [13]
Les concepts de l’urbanisation de l’habitat humain (organisation des villes, du territoire) ont été réutilisés en informatique (notamment par Jacques sasson dans les années 1990 dans le secteur bancaire) pour formaliser ou modéliser l’agencement du système d’information (SI) de l’entreprise.
L’urbanisation de SI permet une bonne circulation de l’information au sein d’une organisation, afin de supporter les modifications éventuelles pouvant survenir dans le temps. Il vise aussi à augmenter l’apport de l’informatique à l’activité de l’entreprise par une meilleure flexibilité des SI et une croissance accrue des attentes des métiers.
II.1.3 Quelques définitions liées à l’urbanisation
✓ Nous appelons urbanisation, démarche qui consiste à rendre le système d’information plus apte à servir la stratégie de l’entreprise et à anticiper les changements dans son environnement ;
✓ L’urbanisme du système d’information est la démarche qui consiste à définir un système d’information cible qui puisse s’adapter et anticiper les différents changements (stratégiques, organisationnels, juridiques, etc.) touchant l’organisme ;
✓ Plan d’urbanisme du système d’information est la réunion de la définition du système d’information cible et des règles d’urbanisme avec la trajectoire à suivre pour atteindre ce système d’information cible ;
✓ L’urbanisation du système d’information est la mise en œuvre d’une démarche d’urbanisme.
II.1.4 Les acteur de l’urbanisation
Les principaux acteurs de l’urbanisation de système d’information sont :
Les maitres d’œuvre, les maitres d’ouvrage et le développeur du système d’information.
a) Maitre d’ouvrage
Il est chargé de la définition des besoins et des financements. Il a comme profil, dirigeant de l’organisme capable d’appréhender globalement la problématique du métier ;
b) Maitre d’œuvre
Le maitre d’œuvre est chargé de la conception du SI. Il est professionnel opérationnel en général de l’ingénieur architecte, capables d’aligner les processus et le SI sur la stratégie métier de l’organisation ;
c) Développeur
Il est chargé de la mise en place et du développement du SI. C’est un professionnel de l’informatique (prestataire, ingénieur, technicien en TIC).
II.1.5 Urbanisation d’une ville et urbanisation de système d’information
[12], [13]
II.1.5.1 Urbanisation des villes
L’urbanisation des villes est l’ensemble des plans et des actions cohérentes qui permettent l’organisation optimale des fonctions spatiales, économiques, sociales et environnementales des territoires.
L’objectif est d’aboutir à une représentation de la ville qui prenne en compte les besoins des citadins et les moyens dont dispose la collectivité pour une gestion optimale et durable de son espace.
II.1.5.2 Urbanisation de système information
L’urbanisation du système d’information d’une entité ou organisation (entreprise ou administration) est une discipline d’ingénierie informatique consistant à faire évoluer son système d’information pour qu’il soutienne et accompagne de manière efficace et efficiente les missions de cette organisation et leurs transformations.
Dans l’urbanisation de SI, plusieurs visions sont également mises en
avant : une vision métier, vision fonctionnelle, vision applicative et vision technique.
Figure 5. Les 4 visions du système d’information (Urbanisation des systèmes
d’information) Source : [12], [13]
L’amélioration peut s’effectuer au niveau de chaque visions indépendamment des autres, d’un côté la vision métier (processus métiers) et la vision fonctionnelle (système d’information) et de l’autre, le couple des visions applicative et technique (système informatique).
Donc, pour comprendre les objectifs d’urbanisation du système d’information, il sera mieux de donner d’abord l’importance de la gouvernance du système d’information. La gouvernance permet d’assurer la performance du processus du SI et cette urbanisation contribue fortement à une meilleure gouvernance du SI lorsqu’elle vise à :
✓ Améliorer l’agilité du SI afin de le faire évoluer au même rythme que la stratégie de l’organisation ;
✓ Définir les règles, principes de construction progressive du SI ;
✓ Assurer des états stables du SI ;
Capitaliser le patrimoine applicatif dans le cadre d’une modernisation
progressive du SI.
II.1.5.3 Etude comparative entre l’urbanisation d’une ville et l’urbanisation de
système d’information [4], [6], [12], [13]
La figure suivante donne un parallélisme possible entre l’urbanisation d’une ville et celle de système d’information (SI)
Urbanisation d’une ville Urbanisation des SI
Organisation, processus et réglementation
Organisation des pouvoirs publics, habitants, forces de l’ordre, organisation des services de police, réglementation en matière de
construction…
Organisation et processus métier Organisation des administrations, agents, usagers, processus métiers, procédures de travail et réglementation associées…
Cas d’usages/ services Organisés en zone/ quartier/ bloc Se loger, se déplacer, travailler,
étudier, se distraire, faire des courses,
se soigner…
Fonctionnalités et données Organisés en zone/ quartier/ bloc Scolarité de l’élève, sécurité intérieure, comptabilité générale, paye…
Bâti et équipement Logement, bâtiments divers, moyen de sécurité, équipement lié à la gestion
des déchets…
Applications, composants logiciels Application métiers (ex CHORUS), logiciels et outils transverses (ex messagerie
Réseaux et équipements
d’infrastructure
Energie, eau, transport, télécommunication
Serveurs, PC, imprimantes réseaux de télécommunication sites hébergement
Figure 6. Parallélisme entre urbanisation d’une ville et celle des systèmes
II.1.6 Démarche d’urbanisation de SI
La démarche d’urbanisation des systèmes d’information consiste à transformer, mutualiser, réutiliser et aligner les actifs (et donc les ressources) d’une organisation (équipement, personnels, projets, processus, données) avec ses caractéristiques opérationnelles propres, sa stratégie d’évolution et son champ de contrainte, le tout dans un cadre formel, compréhensible et partagé.
II.1.6.1 Approche de la démarche de l’urbanisation de SI
Nous distinguons trois approches de la démarche d’urbanisation des systèmes d’information, à savoir : l’approche top-down, l’approche bottom-up et l’approche transversale ciblée.
II.1.6.1.1 L’approche top down ou approche descendante
Cette approche est basée sur un ensemble de règles requérant de définir précisément chaque couche inferieure concernée. Cela consiste à l’étude globale du processus et de l’organisation métier pour descendre vers l’architecture technique d’un système d’information.
II.1.6.1.2 L’approche bottom up ou approche ascendante
Cette approche consiste à l’étude de l’architecture technique d’une plate-
forme pour monter vers l’organisation métier.
II.1.6.1.3 L’approche transversale ciblée
Elle consiste à une étude d’un périmètre limité du système d’information, pour modéliser les dimensions (métiers, fonctionnelles, techniques) souhaitées du système d’information, et essentiellement celle-ci, sans être obligé de modéliser tous les objets du système.
II.1.6.2 La méthodologie
Dans la démarche d’urbanisation, la méthodologie à suivre est la suivante :
✓ La modélisation de la stratégie ;
✓ La cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques) ;
✓ La détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques).
Pour bien urbaniser un système d’information, il faut connaitre les éléments suivants :
• Connaitre le système actuel ;
• Etablir la cartographie du système d’information actuelle ;
• Définir des règles et des contraintes d’évolution ;
• Définir un système d’information cible, aligné sur la stratégie de l’entreprise.
Déterminer la trajectoire à suivre pour atteindre ce système d’information
cible.
II.1.6.3 Principe de base de l’urbanisation
savoir :
L’urbanisation du système d’information répond à deux règles de bases, à
• Une application doit appartenir en « cible » à un seul bloc ;
• Les dépendances doivent respecter les notions de cohérence forte/couplage faible :
▪ Entre les applications ;
▪ Au sein d’une application : entre les différents modules ;
▪ Au sein d’un module : entre les composants.
Les principes de bases de l’urbanisation de système d’information se
présentent comme suit :
• Réorganiser le système d’information en appliquant deux idées
maitresses :
▪ Cohérence forte/couplage faible : définir les blocs pour lesquels les données et les traitements présentent une forte cohérence (cohérence forte) et une frontière bien limitée avec les blocs connexes (couplage faible) ;
▪ Encapsulation : le bloc est propriétaire de ses données et de ses traitements et sont masqués pour les autres blocs. Un bloc ne peut accéder aux données d’un autre bloc qu’en faisant appel aux services que propose celui-ci.
• A ma frontière de chaque bloc, les échanges avec l’extérieur se
font :
▪ Au moyen d’interfaces publiques ;
▪ Par l’intermédiaire d’une infrastructure fédérative (web
services,…ou interfaces).
Les évolutions successives permettant d’atteindre la cible s’effectueront
par assemblage de briques fonctionnelles ou techniques.
II.1.7 Procédure d’élaboration d’un plan urbanisme
II.1.7.1 Plan d’urbanisme
Plan d’urbanisme du système d’information est la réunion de la définition du système d’information cible et des règles d’urbanisme avec la trajectoire à suivre pour atteindre ce système d’information cible.
II.1.7.2 La modélisation de la stratégie
II.1.7.2.1 Les objectifs poursuivis
Les objectifs d’une formalisation explicite de la stratégie s’articulent
autour de trois axes :
• Structurer la complexité du système d’information, cet objectif consiste à organiser le travail même de l’urbaniste, soit répartir le travail de définition des descriptions des contributions des acteurs de l’organisation ;
• Faire évoluer le système d’information par l’identification des conséquences de toute évolution stratégique de l’adaptation nécessaire du système d’information, des systèmes informatiques, leurs composants applicatifs et leurs infrastructures de fonctionnement ;
• Maintenir le système d’information par l’identification des conséquences de toute évolution d’un quelconque composant pour réadapter le système d’information à la stratégie.
II.1.7.2.2 Formalisme de la stratégie
La stratégie organise le traitement des sujets de préoccupations dont il est recommandé de formaliser une liste. Ainsi, les bonnes pratiques formalisent la stratégie en deux diagrammes qui sont :
• Le diagramme de causes et effets d’Ishikawa : il s’agit d’une
formalisation des contributions nécessaires à un objectif souhaité.
• Le diagramme de chaine de valeur de porter : il s’agit d’une
identification de processus nécessaires à un objectif souhaité.
II.1.7.2.3 Règle de construction d’un diagramme d’Ishikawa
• Les objectifs sont syntagmes verbaux ;
• Les objectifs ne comportent ni « ou » ni « et » de choix ou de factorisation « ou » ;
• Le diagramme comporte un et un seul effet principal d’objectif
contributeur.
II.1.8 La cartographie est un référentiel d’entreprise et sa réalisation
II.1.8.1 Notion de la cartographie de SI
La cartographie est un référentiel d’entreprise et sa réalisation se mène comme un projet métier transverse, avec ses propres spécificités ; sa mise en place nécessite un engagement fort du management car beaucoup d’acteurs différents sont
impliqués.
Pour aboutir à un système d’information urbanisé, il faut commencer par
connaitre le système existant et bien cerner ses périmètres fonctionnel et technique.
Ainsi, pour faire du système d’information un atout pour l’entreprise, il faut cartographier et définir un plan stratégique pour en connaitre l’évolution en se donnant les moyens de faire vivre cette cartographie et susciter le besoin de l’utiliser.
La mise en place d’une cartographie de système d’information demande
de respecter les éléments suivants :
a) Les notions de zones, quartiers et blocs pour découper le système
d’information ;
b) Les règles de l’urbanisme informatique ;
c) La cartographique et de représentation fixée.
(a) La notion de zone, quartier et bloc
❖ Une zone : Une zone de SI est définie de manière à correspondre aux préoccupations du temps et/ou des métiers de l’entreprise. Une zone est subdivisée en quartiers.
❖ Un quartier : il est défini par la nature des informations traitées.
Un quartier peut se subdiviser en bloc.
❖ Un bloc : un bloc est un ensemble de données et de traitements homogène dans une activité de l’entreprise, le bloc est le composant de base de l’entreprise, il est composé de traitements portant sur un seul niveau d’agrégation.
(b) Les règles de l’urbanisme informatique
L’urbanisme du système d’information ne définit pas la structure interne des blocs, mais il en définit les règles d’échanges et d’interaction, ces règles d’urbanisme peuvent varier suivant l’approche utilisée et doivent être bien définies au préalable.
Ces règles sont :
• Un bloc appartient à un seul quartier, un quartier à une zone.
Donc un bloc à une seule zone ;
• Un bloc est autonome : chaque bloc doit présenter une cohérence fonctionnelle interne forte et un couplage le plus faible possible avec les autres blocs ;
• Un bloc à deux points d’ancrage (Evénement à traiter +CR
d’exécution ;
• Un bloc est asynchrone ;
• Une donnée ne peut être mise à jour que par un bloc et un seul ;
• Un bloc émet des résultats normalisés ;
• Toute communication entre blocs transite par le système de gestion de flux.
II.1.8.2 Définition de la cartographie de SI
La cartographie est l’ensemble des études et des opérations scientifiques, artistiques et techniques, intervenant à partir des résultats d’observations ou de l’exploitation d’une documentation et de l’établissement de cartes.
La cartographie de système d’information est un outil pour la maitrise et la mise à jour du système d’information, c’est pour cela qu’elle doit être pérennisée de façon à être une image la plus exacte et la plus exhaustive de système d’information à tout moment.
II.1.8.3 Les différents types de cartographie de SI
Plusieurs types des cartographies sont utilisés pour mettre en place un système d’information (cartographie métier, cartographie fonctionnelle, cartographie applicative, cartographie technique, etc.) qui peuvent être réalisées pour détruire les systèmes existants et/ou le système cible. Comme pour la cité, la cartographie d’un système d’information est à la fois basée sur une approche méthodologique et sur une démarche de communication.
Figure 7. Les différentes architectures de système d’information (source :
wikipédia.com)
II.1.8.4.1 La cartographie métier
Elle consiste à une structuration du système d’information par les activités de l’entreprise ou de l’organisme vis-à-vis de ses processus métiers qui contribuent à la stratégie de l’entreprise. Elle décrit donc l’ensemble de processus métier et des activités de l’entreprise que le système d’information doit supporter. Cette cartographie est représentée par trois processus :
• Processus de pilotage : il est stratégique pour l’organisation, il fixe les grandes orientations pour l’entreprise, il définit la finalité et les objectifs de l’organisation, et par conséquent il détermine tous les autres processus ;
• Processus opérationnel : le processus de la chaine de valeur de
l’entreprise destiné à créer de la valeur pour ses clients ;
• Processus de support : est un périphérique au métier de l’entreprise et
soutient son activité.
Il fournit des services, des moyens techniques et financiers, des ressources humaines et matérielles aux processus opérationnels de l’entreprise.
II.1.8.4.2 la cartographie fonctionnelle
Elle offre un cadre de structuration cible des informations et traitements nécessaires au processus métier. Elle répond à la question QUOI ? Sans tenir compte des acteurs et de l’organisation. La finalité d’une telle étude est la structuration du système d’information en blocs fonctionnels communicants.
Chaque bloc (zone, quartier ou ilot) doit présenter une cohérence fonctionnelle interne forte et un couplage le plus faible possible avec les autres blocs.
II.1.8.4.3 La cartographie applicative
Elle décrit l’ensemble des matériels logiciels de base et technologies utilisés. Il s’agit de la structuration et de dimensionnement des moyens d’infrastructure technique à mettre en œuvre pour informatiser l’activité de l’entreprise ou de l’organisme.
II.1.8.5 Les objectif de la cartographie de SI
consistent à :
Les objectifs spécifiques de la cartographie de système d’information
• Maîtriser et piloter le système d’information ;
• Modéliser les cibles ;
• Faciliter les études d’impacts ;
• Améliorer la maîtrise de couts informatiques.
D’où, les cartographies sont au cœur de la démarche à suivre pour un projet d’urbanisation de système d’information.
II.1.8.6 quelques outils de la cartographie de SI
Dans un premier temps, un outil de représentation peut être suffisant afin
d’assurer la communication sur l’architecture.
Des outils tels que Visio permettent d’assurer l’aspect communicationnel et visualisation de l’architecture. Au-delà de ceux-ci, il faut des outils tels qu’Aris, Méga, Proforma ou Case Wise, ces outils possèdent toutes les fonctions de modélisation, représentation et de gestion de référentiel.
Un système d’information urbanisée favorise la pérennisation de ses
cartographies, car :
• Il rend ses évolutions plus faciles à piloter ;
• Il induit une cartographie plus claire ;
• Il induit une cartographie plus exhaustive.
II.3 conclusion
L’urbanisation de système d’information est une discipline de l’ingénierie informatique permettant de faire évoluer le système d’information et le système information informatique au même rythme que la stratégie et l’organisation.
Elle doit permettre de faciliter le positionnement des métiers et les données au cœur du système d’information. Pour bien urbaniser, il y a une démarche que nous devons suivre, cette démarche doit être intégrée avec la planification et la gestion de projet, la conduite de projet et enfin la production et la gestion des infrastructures (notamment en lien avec le processus ITIL de gestion des changements).
Chapitre III. Système décisionnel [3], [7] [8], [12], [13] [15]
III.1 L’entreprise
III.1.1 Définitions
Une entreprise est une organisation dotée d’une mission et d’un objectif
métier, elle doit gérer sa raison d’être et sa pérennité au travers de différents objectif (sécurité, développement, rentabilité) par voie de conséquence, cette organisation humaine est dotée d’un centre de décision.
III.1.2 Problématiques
Ce titre amène naturellement à définir la position de l’entreprise par rapport au sujet Data warehouse, Datamining. Une entreprise se doit en permanence de pouvoir se situer face à la concurrence, mais également par rapport à la demande et a ce qu’elle peut offrir. C’est sur ces points qu’un système d’information décisionnel intervient.
III.2 Notion du décideur [3], [7] [8], [12], [15] III.2.1 Le décideur et son rôle
Le décideur peut être le responsable de l’entreprise ou d’une organisation
quelconque, le responsable d’une fonction ou d’un secteur.
Il est donc celui qui engage la pérennité ou la raison d’être de l’entreprise, il doit s’entourer de différents moyens lui permettant une prise de décision la plus pertinente. Parmi ces moyens, les data warehouse ont une place primordial, en effet, ils contiennent les données de toutes les activités de l’entreprise.
Le principal problème réside dans l’exploitation de ces informations, pour
cela, il est temps de bien penser le Dataminig.
III.2.2 le besoin du décideur
Pour faire face à la concurrence qu’engendre la mondialisation, les
entreprises doivent être
De plus en plus performantes et rapides dans leurs prises de décisions. D’autre part, les volumes de données suivent un accroissement continu pouvant atteindre plusieurs Téraoctets pour une société.
Bien entendu, ces informations ne se trouvent pas sur un système unique. Ceci pose la problématique suivante : Comment prendre des décisions sur
la base d’informations issues de systèmes hétérogènes n’aillant pas de moyens pour
communiquer facilement entre eux.
Le Datawarehouse répond en partie à cette problématique. En effet, cette base de données regroupe l’ensemble des informations de l’entreprise de façon cohérente dans le but de faciliter l’analyse et la prise de décision.
III.2.3 la décision
Nous pouvons dire que, une décision est le résultat d’un processus comportant le choix conscient entre plusieurs solutions envie d’atteindre un objectif. L’efficacité des services d’une entreprise dépend de la qualité de ces décisions, donc améliorer l’habilité à prendre des décisions, c’est optimiser l’usage des ressources dont dispose l’entreprise.
III.2.4 les processus de la prise de décision
La technique du processus décisionnel comporte cinq (5) étapes :
• Définir le problème : le problème à résoudre est souvent présenté dans des termes Vagues et peut être difficile à identifier. Il arrive que ce que nous croyons être le Problème ne soit en réalité qu’un symptôme et si l’on s’attaque qu’au symptôme, on n’arrivera jamais au fond du problème. Avant de pouvoir être plus précis, il faut donc Que la définition initiale parle du problème tel qu’il se présente ;
• Rassembler les faits et les données : il faut rassembler tous les renseignements
Pertinents car le manque de faits probants diminue grandement la qualité
et l’efficacité de décision ;
• Evaluer et interpréter les faits et les données : pour être efficace, il est souvent Nécessaire de traiter une quantité considérable de renseignements en utilisant une Méthode de classification des données recueillies en les groupant en catégories avec les critères communs ;
• Etablir plusieurs solutions : il faut toucher d’envisager toutes les solutions
possibles
visant à atteindre les objectifs sous juger de leur valeur objective. Au cours de cette Étape, l’imagination doit avoir libre cours en provoquant des réactions en chaîne, car d’une idée peut en jaillir une autre ;
• Décider (choisir une décision) : c’est ici qu’il faut évaluer, juger, critiquer. Il faut tenir Compte du pour et du contre pour chaque solution, évaluer leurs avantages et leurs désavantages.
III.3 le système décisionnel [3], [7] [8], [12], [13] [15] III.3.1 introduction
Depuis que l’on stock de l’information, on cherche toujours à l’exploiter, qu’elle serve de base à nos prises de décision. C’est ainsi dans une entreprise, les systèmes d’informations de gestion ont été historiquement structurés en deux sous- systèmes : l’un dit opérationnel qui prend en charge la réalisation des opérations au jour le jour, et l’autre dit décisionnel qui fournit d’information pour définir la stratégie, piloter les opérations et analyser les résultats pour la bonne prise de décision.
En effet, aujourd’hui les technologies de l’information nous génèrent une multitude de données comme jamais auparavant. Le problème n’est donc plus tant d’acquérir une masse de données mais de l’exploiter. Pour cela, il faut collecter les données de qualité, la normaliser, la classer, l’agréger et l’analyser pour l’exploiter afin d’en extraire une connaissance en vue de prendre la bonne décision au bon moment.
Il s’agit ici de s’intéresser aux besoins des décideurs, à savoir, transformer les données en connaissance voir en prévision c’est-à-dire en information. Dans ce cas, il est nécessaire de mettre en place un système particulier appelé « système décisionnel
». Ce système doit permettre de prendre de manière simple les chiffres recueillis pour mettre en lumière la conjoncture actuelle et indique la voie à suivre.
Un système décisionnel ne remplace pas les systèmes opérationnels qui font fonctionner l’entreprise, mais il vient ‘y intégrer en y extrayant des données afin d’en diffuser la connaissance de la manière la plus facilement exploitable par les personnes concernées. Le système opérationnel n’est pas, à priori, modifié par la mise en place du système décisionnel, ce dernier vient le compléter par une exploitation avancée de l’information.
C’est ainsi les organisations ont pour la plupart mis en place leur système opérationnel pour être efficaces et réactives, elles doivent maintenant, pour être proactives déployer un système décisionnel.
La mise en place d’un système décisionnel permet d’apporter les réponses efficaces à tous les niveaux de l’entreprise : cet aspect décisionnel est présent dans les organisations depuis de nombreuses années, il revêt l’apparence de rapports et de tableaux de bord.
Un système décisionnel est donc avant tout un moyen qui a pour but de faciliter la définition et la mise en œuvre de stratégie gagnante. Il va en particulier aider au pilotage des plans d’actions (prévision, planification, suivi), à l’apprentissage (acquisition de savoir-faire, de connaissance, de compétences) et à la réalisation d’innovation incrémentale (adaptation du modèle d’affaires : produits/services, organisation, etc.).
III.3.2 Définitions de quelque concept [3], [7] [8], [12], [13] [15]
Un système décisionnel appelé aussi « Business Intelligent » est un
ensemble des technologies destinées à permettre aux collaborateurs de l’entreprise d’avoir accès et de comprendre les données de pilotage plus rapidement de sorte qu’ils prennent de décision meilleure à temps pour enfin atteindre les objectifs de leur organisation.
Cette nouvelle utilisation de l’information contenue dans les bases opérationnelles des entreprises a donné lieu à l’élaboration de nouveau système dédié à l’analyse et à la prise de décision.
Ce système regroupe un ensemble d’information et d’outil mise à la disposition de décideur pour supporter de manière efficace la prise de décision. Ainsi, un système décisionnel peut être considéré comme un système d’information dédié aux applications décisionnelles. Donc, le système décisionnel (ou encore système informatique d’aide à la décision « SIAD »), c’est un ensemble des moyens informatiques et techniques destinés à améliorer la prise de décision.
L’informatique décisionnel (ou BI pour Business Intelligence) peut être définie comme étant un ensemble des moyens, des outils et des méthodes permettant de collecter, consolider, modéliser et restituer les données de l’entreprise dans le but d’apporter une aide à la prise de décision. Son avantage ou importance est de permettre aux responsables de la stratégie d’une entreprise d’avoir une vue d’ensemble de l’activité traitée.
La maturité des systèmes décisionnels peut être illustrée en cinq étapes :
▪ Les tableaux de bord (Que s’est-il passé ?) ;
▪ L’analyse (Pourquoi ?) ;
▪ La prédiction (Que va-t-il se passer ?) ;
▪ L’aide opérationnelle (Qu’est-il en train de se passer ?) ;
▪ L’entrepôt Actif (Que faire ?).
III.3.3 Problématique
III.3.3.1 Pourquoi le décisionnel ?
A titre de rappel, le décisionnel ne concerne souvent que les entreprises qui gèrent un historique de leurs événements passés (faits, transactions etc.). Les entreprises qui viennent de naître n'ont souvent pas besoin de faire du décisionnel car elles n'ont pas encore besoin de catégoriser ou de fidéliser leurs clients.
Le souci majeur pour elles serait plutôt d'avoir le maximum de clients et c'est après en avoir récupéré un grand nombre qu'elles penseront certainement à les fidéliser et leur proposer d'autres produits susceptibles de les intéresser.
C'est ce que l'on appelle Customer Relationship Management (CRM ou gestion des relations clients).
III.3.3.2 Qui a besoin du décisionnel ?
Les décideurs sont les principaux utilisateurs des systèmes décisionnels. Les décideurs sont généralement des « marqueteurs » ou analystes en général. Ces derniers établissent généralement des plans marketing qui leur permettent de mieux cibler leurs clients, de les fidéliser etc. Et pour cela, ils ont besoin d'indicateurs et des données résumées de leurs activités (ils n'ont souvent besoin de détail que pour des cas spécifiques).
Par exemple, contrairement aux systèmes relationnels où les utilisateurs chercheront à connaître leurs transactions pour faire un bilan, les systèmes décisionnels quant à eux cherchent plutôt à donner un aperçu global pour connaître les tendances des clients (d'où l'opposition des deux modes [quantitatif contre qualitatif]).
III.3.4 Fonction et architecture d’un système décisionnel [7] [8], [12], [13] [15]
III.3.4.1 Les fonctions d’un système décisionnel
Tout système d’information décisionnel, telle que le sont le Data warehouse mettent en œuvre cinq (5) fonctions fondamentales :
✓ La collecte : la collecte des données brutes dans leurs environnements d'origine, ce qui implique des activités plus ou moins élaborées de détection et de filtrage, car un excédent de données, un défaut de fiabilité ou un trop mauvais rapport signal/bruit sont pires que l'absence de données ;
✓ L’intégration : L’intégration des données, c'est-à-dire leur regroupement en un ensemble technique, logique et sémantique homogène approprié aux besoins de l'organisation ;
✓ La diffusion : c’est la distribution d’information élaborée à partir des données dans des contextes appropriés aux besoins des individus ou des groupes de travail utilisateurs ;
✓ La présentation : Elle correspond à des conditions de mise à disposition de
l’information (contrôle d’accès, personnalisation, ergonomie,…) ;
✓ L’administration de donnée : C’est la gestion du dictionnaire de données et le processus d’alimentation de bout en bout, car le système d’information décisionnelle doit-être lui-même piloté.
Dans la pratique, la fonction de la collecte et celle d’intégration sont étroitement liées entre elles et sont généralement associées à l’entrepôt. De même, la diffusion et la présentation sont fortement orientées sujet, tournées vers l’utilisateur et sont métiers, manipulant des contenus à forte valeur ajoutée informationnelle et non des données brutes ; elles sont donc fortement imbriquées logiquement et techniquement.
III.3.4.2 l’architecture d’un système décisionnel
L’architecture ci-dessous est une bonne représentation pour avoir une
vision générale d’un système décisionnel :
Figure 8. Architecture d’un système décisionnel
L’architecture d’un système décisionnel met en jeu quatre éléments essentiels : les sources de données, l’entrepôt de données, les magasins de données et les outils d’analyse et d’interrogation.
❖ Les sources de données : Elles sont nombreuses, variées, distribuées et autonomes.
Elles peuvent être internes (Bases de production) ou externes (Internet, Bases des partenaires) à l’entreprise ;
❖ L’entrepôt de données : C’est le lieu de stockage centralisé des informations utiles pour les décideurs. Il met en commun les données provenant des différentes sources et conserve leurs évolutions ;
❖ Les magasins de données : Ce sont des extraits de l’entrepôt orientés sujet. Les données sont organisées de manière adéquate pour permettre des analyses rapides à des fins de prise de décision ;
❖ Les outils d’analyse : permettent de manipuler les données suivant des axes d’analyses. L’information est visualisée au travers d’interfaces interactives fonctionnelles dédiées à des décideurs souvent non informaticiens.
III.3.5 Les apports des systèmes décisionnels
Les apports des systèmes décisionnels sont multiples et peuvent être classés en deux catégories :
o L’amélioration de l’efficacité de la communication et de la distribution des
informations de pilotage ;
o L’amélioration du pilotage des entreprises résultat des meilleures décisions,
prises plus rapidement.
Si le premier point est aisément compréhensible, c’est-à-dire présente peu de risque de mise en œuvre et pose peu de problème d’évaluation, ce n’est clairement pas en revanche une source de gains significative. Il sera très difficile, le plus souvent, de justifier les coûts d’un projet sur cette seule promesse.
La seconde catégorie à nettement plus de potentiel de gains, mais il faut bien connaître que les risques de ne pas atteindre les objectifs initiaux sont réels, sans parler des énormes difficultés d’évaluation des bénéfices escomptés. Les bénéfices de ce type le plus souvent cités sont les suivants :
✓ Unicité des chiffres, une seule vérité acceptée par tous ;
✓ Meilleure planification ;
✓ Amélioration de la prise de décision ;
✓ Amélioration de l’efficacité des processus ;
✓ Amélioration de la satisfaction des clients et des fournisseurs ;
✓ Amélioration de la satisfaction des employés.
III.3.6 Les caractéristiques des systèmes décisionnels
Les systèmes d'information se sont souvent développés par domaine d'activité : financier, commercial, marketing, etc. L’information accumulée est très diverse et elle est gérée par des systèmes hétérogènes. Le but de ces systèmes est de fournir aux organismes l’infrastructure nécessaire pour réaliser leurs tâches quotidiennes.
Un grand besoin d’intégration de ces systèmes, dit transactionnels, est ressenti afin de permettre à tous les acteurs de disposer des informations relatives à leurs centres d’intérêts.
Ces informations doivent pouvoir être accessibles et faciles à interroger par le décideur en fonction de son secteur d'activité (marketing, économique).
L’approche adoptée pour répondre à ce besoin est de regrouper les informations disparates, après les avoir prétraitées, au sein d'un unique espace de stockage de données intégrées par sujet. L’analyse de ces données par des requêtes interactives devient alors possible et permet de prendre rapidement de meilleures décisions.
Différents outils d’analyse peuvent être greffés sur cet espace tel que les outils d’analyse interactive, les outils de fouille de données permettant l’extraction de nouvelles connaissances et les requêtes fournissant des tableaux de bord aux différents acteurs de la décision.
III.4 Quelques outils de prise de décision
Dans cette section, nous présentons d’une manière globale, quelques concepts de base relatifs aux systèmes décisionnels en passant par l’entrepôt de données (DATAWERAHOUSE), le magasin de données (DATA MART), la modélisation multidimensionnelle et la fouille de données ( DATA MINING) qui est la technique d’exploration de données.
III.4.1 Data warehouse (Entrepôt de données) III.4.1.1 Définitions
Un entrepôt de données (ED) ou data warehouse (DW) est défini comme
étant « une collection de données intégrées, orientées sujet, non volatiles, historisées, résumées, disponibles pour l’interrogation et l’analyse ; et organisées pour le support d’un processus d’aide à la décision». Cette définition met l’accent sur les caractéristiques suivantes :
➢ Intégrées : Les données de l’entrepôt proviennent de différentes sources
éventuellement hétérogènes.
L’intégration consiste à résoudre les problèmes d’hétérogénéité des systèmes de
stockage, des modèles et sémantique de données ;
➢ Orientées sujet : Après leur intégration dans une sorte de source globale, les données sont réorganisées autour de thèmes, contrairement aux données des systèmes transactionnels généralement organisées par processus fonctionnel.
L’intérêt de cette organisation est de disposer de l’ensemble des informations utiles sur un sujet, le plus souvent transversal aux structures fonctionnelles et organisationnelles de l’entreprise, c’est-à-dire chaque décideur d’une entreprise doit disposer d’une vue sur les informations qui lui sont pertinentes, et qui peuvent influer dans ses décisions pour une meilleure exploitation de ces données ;
➢ Non volatiles : Dans un entrepôt, tout se conserve, rien ne se perd : cette caractéristique est primordiale dans les entrepôts de données. En effet, et contrairement aux bases de données classiques, un entrepôt de données est accessible en ajout ou en consultation uniquement.
Les modifications ne sont autorisées que pour des cas particuliers
(correction d’erreurs…etc.) ;
➢ Historisées : La conservation de l’évolution des données dans le temps, constitue une caractéristique majeure des entrepôts de données. Elle consiste à s’appuyer sur les résultats passés pour la prise de décision et faire des prédictions ; autrement dit, la conservation des données afin de mieux appréhender le présent et d’anticiper le futur.
➢ Résumées : Les informations issues des sources de données doivent être agrégées et réorganisées afin de faciliter le processus de prise de décision.
➢ Disponible pour l’interrogation et l’analyse : Les utilisateurs doivent pouvoir consulter les données en fonction de leurs droits d’accès. L’Entrepôt de données doit comporter un module de traitement des requêtes, exprimées dans un langage, doté d’opérateurs puissants, pour l’exploitation de la richesse du modèle.
Bref, un data warehouse permet d’agréger et de consolider les données afin de les exploiter. Mais son intérêt est de conserver la trace des données produites après l’application des règles de gestion et cela est rendu possible grâce aux métadonnées, c’est à dire les «données sur les données».
Ces métadonnées permettent de stocker des informations telles que le nom de la base de production dont la donnée est extraite, la date et l’heure de la dernière extraction, la fréquence de mise à jour de cette information.
III.4.1.2 Architecture de Data warehouse (l’entrepôt de données)
La figure ci-dessous montre l’architecture générale d’un entrepôt de données. Cette architecture présente les processus et les outils qui s’appliquent aux données.
Elle répond aux comment : comment récupérer les données sources, comment leur donner une forme répondant aux besoins et comment les placer à un endroit accessible ? Les outils, les utilisateurs, le code, tout ce qui donne vie à l’entrepôt de données fait partie de l’architecture.
Figure 9. Architecture d’un entrepôt de données
Dans l’architecture précédente, un seul espace de stockage est défini pour les données décisionnelles : l’entrepôt de données. I intégrer un grand volume de données centralisées et, en même temps, de répondre à des requêtes des utilisateurs concernant un thème, un métier ou une analyse spécifique.
L'entrepôt de données centralise les données issues de plusieurs sources (bases de production de l'entreprise, fichiers textes, documents web, etc.). Ces données sont fusionnées dans l'entrepôt qui est généralement une grosse base de données (SQL Server, Oracle etc.).
Une fois l'entrepôt confectionné, les données sont arrangées suivant des secteurs d’activités particulières et ensuite extraites dans des serveurs d'analyse ou serveurs OLAP sous forme de cubes de données afin d'être analysées. Enfin, des générateurs d'états (Requêtes ou Rapports) sont utilisés afin de présenter le résultat aux utilisateurs finaux ou décideurs (ex: analystes marketing).
Nous distinguons là deux problématiques indépendantes :
➢ La gestion efficace des données historisées et centralisées ;
➢ La définition d’un sous ensemble de données autour d’un thème particulier afin
de répondre aux besoins spécifiques de ses utilisateurs.
Au regard de notre architecture précédente, nous avons généralement trois étapes clés :
➢ L’intégration : Elle consiste à extraire et regrouper les données, provenant de sources multiples, et hétérogènes. Un certain nombre de problèmes est à résoudre à ce niveau : les données doivent être filtrées, triées, homogénéisées et nettoyées.
Les sources de données sont souvent diverses et variées et le but est de trouver des outils ETL (Extraction / Transformation / Loading) afin d’extraire les données, de les nettoyer, de les transformer et de les mettre dans l'entrepôt de données.
Donc, un outil ETL (Extraction/ Transformation/Loading) permet à partir de diverses sources de données, d'extraire de l'information, de faire des transformations afin de nettoyer les données et de charger des données utiles dans l'entrepôt de données.
✓ L’Extraction (Extract) : consiste à faire la lecture et l’extraction de données
du système source ;
✓ La transformation (Transform) : c’est la tâche la plus complexe et qui demande beaucoup de réflexion. Elle présente les grandes fonctionnalités suivantes :
Nettoyage des données ;
o Standardisation des données ;
o Conformité des données ; o Gestion des tables de fait ; o Gestion des dimensions ;
o Affectations des clés de substitution.
✓ Le chargement (Load) : Il permet de transférer les données vers leur destination
finale, c’est-à-dire l’entrepôt.
➢ La structuration : Cette étape consiste à réorganiser les données, dans des magasins afin de supporter efficacement les processus d’analyse et d’interrogation, et d’offrir aux différents utilisateurs, des vues appropriées à leurs besoins.
➢ L’interrogation et l’analyse : L’exploitation de l’entrepôt, pour l’aide à la
décision peut se faire de différentes façons, dont :
✓ L’interrogation à travers un langage de requêtes,
✓ La connexion à des composants de report, pour des représentations graphiques et tabulaires,
✓ L’utilisation des techniques OLAP (OnLine Analytical Process),
✓ L’utilisation des techniques de fouille de données (Data Mining).
III.4.1.3 Les techniques de réalisation d’un data warehouse (l’entrepôt de
données)
Il existe pratiquement trois techniques ou approches pour mettre en place un Data warehouse. Il s'agit de :
➢ La technique Bottom-up, prônée par Kimball,
➢ La technique Top-Down, prônée par Inmon,
➢ La technique Middle-out ou Hybride qui dérive des deux premières approches.
A. La technique Top-Down
Cette technique consiste à concevoir l’entrepôt intégralement. D’où la nécessité de connaitre à l’avance toutes les dimensions et tous les faits.
L’objectif ultime de cette technique est de livrer une solution technologiquement saine basée sur des méthodes et technologies éprouvées des bases de données.
Avantage
• Offrir une architecture intégrée : méthode complète ;
• Réutilisation des données ;
• Pas de redondances ;
• Vision claire et conceptuelle des données de l’entreprise et du travail à
réaliser.
Inconvénients
• Méthode lourde ;
• Méthode contraignante ;
• Nécessite du temps.
B. La technique Bottom-up
Cette approche consiste à créer les data marts un par un puis les regrouper
par des niveaux intermédiaires jusqu'à l’obtention d'un véritable entrepôt.
Cette technique a pour objectif de livrer une solution permettant aux usagers d’obtenir facilement et rapidement des réponses à leurs requêtes d’analyse.
Avantages
• Simple à réaliser ;
• Résultats rapides ;
• Efficace à court terme.
Inconvénients
• Pas efficace à long terme ;
• Le volume de travail d'intégration pour obtenir un entrepôt de données ;
• Risque de redondances (car réalisations indépendantes).
C. La technique Middle-out ou technique hybride
Cette approche, comme son nom l’indique, est un mix des deux premières approches. On commence par concevoir un modèle de données de l'entreprise en même temps que les modèles spécifiques, c’est-à-dire concevoir intégralement l'entrepôt de données (toutes les dimensions, tous les faits, toutes les relations), puis créer en même temps des divisions plus petites et plus générales.
Avantages
• Développement d’un modèle de données d’entreprise de manière itérative
;
• Possibilité de recharger les cubes ;
• Possibilité de garder les faits et les dimensions dans leur détail de grain le plus fin ;
• La possibilité de créer des agrégats ;
• Une plus grande flexibilité à retraiter les données, les corriger ;
• Ne pas avoir à charger le détail dans les cubes.
Inconvénients
• Implique, parfois, des compromis de découpage (dupliquer des dimensions identiques pour des besoins pratiques) ;
• Cette approche entraîne une plus grande charge de travail aux équipes
d’administration et d’exploitation.
III.4.1.4 les concepts OLTP et OLAP
De nos jours, les données applicatives métier sont stockées dans une (ou plusieurs) base(s) de données relationnelle(s) ou non relationnelles et connaissant qu’un système est un ensemble d’éléments matériels ou immatériels (hommes, machines, méthodes, règles.) en interaction et transformant par un processus des éléments (les entrées) en d’autres éléments (les sorties), les données permettant la prise de décisions diffèrent des données opérationnelles.
P a g e
| xlvii
Dans cette section nous allons définir les deux systèmes étant à la base de la subdivision de deux concepts ou mondes dans nos entreprises quant aux données produites, c’est-à-dire, le monde transactionnel ou opérationnel et le monde décisionnel, en passant par la définition et les caractéristiques de chaque système.
III.4.1.4.1 OLTP
A. Définition :
« Un système OLTP (On Line Transaction Processing) ou système transactionnel est un système de gestion ou de production servant de relater la vie de l'entreprise dans un environnement informatique, plus restreint, mieux gérable et plus flexible. » Il s’agit ici de la conception et développement d’une base de données relationnelle ainsi que les différentes transactions qui permettent la modification des données.
Le système transactionnel comprend des tâches quotidiennes, répétitives et atomiques qui sont effectuées par les employés de l'entreprise pour lui permettre d'avoir une activité et donc de survivre.
Le traitement d'une commande, l'édition d'une facture, l'emballage d'un produit, le suivi d'un colis ou la consignation d'une réclamation sont des taches nécessaires à la vie d'une entreprise. On parle d'opération quand on parle de ce type d'actions et les systèmes informatiques opérationnels (OLTP) sont faits pour assister ces genres d’opérations au sein d’une entreprise.
Une des principales caractéristiques des systèmes transactionnels, est une activité de modification et d'interrogation fréquentes et répétitives. L’accès au système est réalisé par de très courtes transactions. Enfin, la plupart de ces systèmes ne conservent pas les évolutions des données manipulées.
B. Caractéristiques
Les systèmes transactionnels présentent les caractéristiques ci-après :
➢ Extrêmement rapides : dans un système de gestion de pannes d'une centrale nucléaire, il ne faudrait pas que le système nous annonce une panne critique 30 minutes après qu'elle ne se soit produite ;
➢ Fermés : on ne laisse pas la place à l'improvisation dans les OLTP, les choix sont restreints, les utilisateurs sont guidés dans le processus ;
➢ Petite volumétrie des données : les systèmes de gestion ne gèrent pas des Téra
Octets de données. Ces systèmes s'intéressent à ce qui se passe maintenant ;
➢ Données atomiques : on entre un produit, une ligne de commande, une facture.
Ce sont des éléments avec un grain très fin ;
➢ Grand public : les OLTP sont des aides à l'opération, ils sont donc destinés à toute personne participant à la vie quotidienne de l'entreprise. Donc tous les employés de l'entreprise. Les décideurs sont exclus du groupe car ils participent à un niveau plus élevé que la gestion quotidienne ;
➢ Transactionnels : les OLTP fonctionnent en utilisant le principe de transaction
;
➢ Lecture, écriture et modification des données : dans un OLTP on peut ajouter de l'information, en supprimer si elle n'est pas utile pour la production et la modifier s'il existe des erreurs ;
➢ Projets comportant peu de risques : les projets de systèmes OLTP sont maintenant bien rodés, les fonctionnalités et les besoins évidents, il y'a moins de risque d'échecs ;
➢ Fragmentés : on entend par ici décentralisés. Sauf dans le cas des ERP, on trouvera des systèmes pour la gestion des ressources humaines, des systèmes pour la production, des CRM, des systèmes de facturation, etc. ;
➢ Hétérogènes : Les systèmes OLTP sont souvent des systèmes disparates en termes de technologie utilisée.
III.4.1.4.2 OLAP
OLAP.
Dans la littérature, plusieurs définitions sont proposées pour les systèmes
Dans ces définitions, les caractéristiques de base sont la structure
dimensionnelle des données, les données forment des points dans un espace à plusieurs dimensions, et l’interactivité de l’interrogation afin de s’approcher de la perception du décideur et de l’aider au mieux dans son processus de prise de décision.
a. Définition
« Un système OLAP (On Line Analytical Processing) est un système d’information décisionnel qui organise les données dans un espace dimensionnel. » Nous pouvons aussi résumer la définition de ce dernier en cinq mots : Fast Analysis of Shared Multidimensional Information (FASMI) traduit en français comme suit : « Analyse Rapide d'Information Multidimensionnelle Partagée ».
Ce terme s'oppose à OLTP qui désigne les systèmes transactionnels et a pour objectif ultime de combler les lacunes des systèmes transactionnels. OLAP est un mode de stockage prévu pour l’analyse statistique des données et une base de données OLAP peut se représenter comme un cube à N dimensions avec pour objectif de s’intéresser qu’aux besoins des décideurs, à savoir, transformer les données en connaissances voire en prévisions, c’est-à-dire en information.
OLAP désigne donc les bases de données multidimensionnelles ou cubes destinées à l'analyse.
Ce type d’application (OLAP) utilise en règle générale un entrepôt de données pour stocker des données transverses provenant de plusieurs sources hétérogènes, Il regroupe un ensemble d’outils en interaction qui réalisent la synthèse dynamique, l’analyse interactive et l’agrégation d’un grand volume de données afin d’améliorer le processus de prise de décision.
b. caractéristiques
Les principales caractéristiques de ces systèmes sont :
➢ La vision dimensionnelle des données;
➢ La transparence entre l’outil de visualisation et l’espace de stockage des
données dimensionnelles ;
➢ L’interopérabilité (l’outil rend invisible à l’utilisateur l’hétérogénéité des
données) ;
➢ La manipulation intuitive des données et la flexibilité des restitutions ;
➢ Le décideur dispose d’une interface ergonomique de consultation.
III.4.1.4.3 Comparaison entre le Système OLAP et OLTP
à savoir :
Nous préférons effectuer cette comparaison par rapport à deux aspects clés
o Aspect données décisionnel par rapport à celles opérationnelles ;
o Aspect caractéristiques décisionnelles par rapport à celles opérationnelles.
Les données permettant la prise de décisions diffèrent des données
opérationnelles :
|
Données opérationnelles |
Données décisionnelles |
|
Orientées application, détaillées, précises au moment de l’accès |
Orientées activité (thème, sujet), condensées, représentent des données historiques |
|
Mise à jour interactive possible de la part des utilisateurs |
Pas de mise à jour interactive de la part des utilisateurs |
|
Accédées de façon unitaire par une personne à la fois |
Utilisées par l’ensemble des analystes, gérées par sous ensemble |
|
Haute disponibilité en continu |
Exigence différente, haute disponibilité ponctuelle |
|
Uniques (pas de redondance en théorie) |
Peuvent être redondantes |
|
Petite quantité de données utilisées par un traitement |
Grande quantité de données utilisée par les traitements |
|
Réalisation des opérations au jour le jour |
Cycle de vie différent |
|
Forte probabilité d’accès |
Faible probabilité d’accès |
|
Utilisées de façon répétitive |
Utilisée de façon aléatoire |
Tableau 1 : Comparaison entre les données opérationnelles et décisionnelles
Nous pouvons aussi comparer ces deux systèmes par rapport à leurs caractéristiques respectives.
En rapport avec ce deuxième aspect, la comparaison se fera par rapport à quatre éléments :
• Les utilisateurs ;
• Le contenu des données ;
• La structure de la base de données ;
• L’administration du système.
III.4.2 Data marts (magasins de données) [3], [7] [8], [12], [13] III.4.2.1 Définitions
Un Data Marts (ou magasin de données ou encore mini-entrepôt de données) est un sous ensemble d’un entrepôt de données qui satisfait les exigences d’un département, service d’une organisation ou d’une fonction professionnelle Autrement dit, le magasin de données est un extrait de l'entrepôt.
Les données extraites sont adaptées à une classe de décideurs ou à un usage particulier (recherche de corrélation, logiciel de statistiques,...). L’organisation des données suit un modèle spécifique qui facilite les traitements décisionnels Ainsi, le Data Marts est une petite structure très ciblée et pilotée par les besoins utilisateurs.
Il a la même vocation que le Data Warehouse (fournir une architecture décisionnelle), mais vise une problématique précise avec un nombre d’utilisateurs plus restreint.
En général, c’est une petite base de données (SQL ou multidimensionnelle) avec quelques outils, et alimentée par un nombre assez restreint de sources de données.
III.4.2.2 pourquoi créer un data marts ?
Nous avons plusieurs raison importantes qui nous permettent de créer un magasin de données, citons :
❖ Donner aux utilisateurs un accès aux données dont ils ont besoins pour leurs analyses les fréquents.
❖ Fournir les données sous une forme compatible avec la perception collective des données par groupe d’utilisateurs d’un département ou d’une fonction professionnelle.
❖ Améliorer les délais de réponse, grâce à la réduction du volume des données auxquelles les utilisateurs finals accèdent.
❖ Les mini-entrepôts utilisent normalement un nombre de données moindre, de sorte que des taches telles que le nettoyage, le chargement,
❖ la transformation et l’intégration des données sont nettement faciles.
❖ Les couts de mise en place des mini-entrepôts sont généralement moindres que
ceux engendrés par l’installation d’un entrepôt de données.
III.4.2.3. les outils d’alimentation d’un data warehouse
Par définition, l’ETL (Extract Transform Loading) est un serveur chargé d’extraire, nettoyer et transformer les données émanant de sources diverses pour ensuite les insérer dans un entrepôt de données.
Ainsi, l’ETL sont des outils qui permettent d’extraire les données provenant des différentes sources du système opérationnel (Excel, MySQL, etc.), les transforme, puis les charges dans l’entrepôt de données. Donc, ce processus se déroule en trois phases :
(1) Extraction des données :
Cette extraction consiste à collecter les données utiles dans le système de production. Pour rafraîchir la base décisionnelle, il faut identifier les données ayant évolué afin d’extraire le minimum de données, puis planifier ces extractions afin d’éviter les saturations du système de production.
Ainsi, pour extraire les données sources, il y a plusieurs technologies utilisables, à savoir :
✓ des passerelles, fournies principalement par les éditeurs de bases de données.
Ces passerelles sont généralement insuffisantes car elles sont mal adaptées aux processus de transformation complexes ;
✓ des utilitaires de réplication, utilisables si les systèmes de production et décisionnel sont homogènes et si la transformation à appliquer aux données est légère ;
✓ des outils spécifiques d’extraction. Ces outils sont certainement la solution opérationnelle au problème de l’extraction, mais leur prix relativement élevé est un frein à leur utilisation dans les premières applications.
(2) La transformation des données :
Cette transformation se fait de plusieurs façons selon la nature de données. Ainsi, à ce stade, nous pouvons appliquer des filtres prédéfinis sur les données afin d'attribuer des valeurs cohérentes aux variables mal ou non renseignées ou encore d'harmoniser les formats (date : JJ/MM/AAAA).
On peut également avoir à convertir les données d'un format EBCDIC vers
ASCII. Ainsi, la transformation de données consiste à :
o La constitution des historiques ;
o L’homogénéisation des nomenclatures des différentes sources ;
o L’intégration de données externes ;
o Filtrage, agrégation, mise à la granularité ;
o Nettoyage, suppression d’erreurs.
(3) Le chargement des données :
Le chargement de données permet d’insérer les données dans un entrepôt de données enfin de rendre ces données disponible lors des analyses. Notons que, le chargement est la dernière phase de l’alimentation d’un entrepôt de données. C’est une phase délicate notamment lorsque les volumes de données sont importants.
III.4.2.4 La modélisation multidimensionnelle
La modélisation multidimensionnelle fait appel aux concepts clés ci-après :
❖ Une dimension : c’est tout ce qu’on utilisera pour faire nos analyses. « Donc une table de dimension est une table servant d'axes d'analyse ». Chaque dimension comporte un ou plusieurs attributs ou membres et chaque membre à des caractéristiques propres ;
❖ Un fait : Il représente un sujet d’analyse dans une application décisionnelle ou
autrement, c’est tout ce qu’on voudra analyser.
Supposons, par exemple, que nous souhaitons analyser les performances des agences dans une société de location de véhicules. Dans un schéma dimensionnel, ce besoin est modélisé par le fait Location. « Donc une table de fait est une table contenant tous les faits du SI et dont dépendent toutes les autres tables. Cette table ne contient que des clés étrangères venant des tables de dimensions et des valeurs numériques appelées mesures. »
❖ Une mesure : Est un élément de donnée sur lequel portent les analyses, en fonction des différentes dimensions et ces valeurs sont le résultat de diverses opérations d’agrégation sur les données.
Autrement, Une mesure est un indicateur d’analyse de type numérique et
cumulable, accompagnée d’un ensemble de fonctions d’agrégation qui permettent de l’agréger en fonction des axes d’analyse. En considérant notre exemple précédent, afin de calculer la performance des agences, nous définissons les mesures d’activités montant et durée des locations dans le fait Location.
Les mesures sont réunies dans un même fait si elles peuvent être analysées suivant les mêmes axes d’analyse. Les faits comportent un très grand volume de données pouvant être résumées, lors des interrogations, grâce aux opérations d’agrégation. Or, ces opérations ne peuvent être appliquées que sur des données numériques et additives.
❖ Un paramètre : Un paramètre est un attribut appartenant à une dimension. Il représente un niveau de détail selon lequel sont visualisées les mesures d’activité d’un sujet d’analyse.
❖ Une hiérarchie : Une hiérarchie est une perspective d’analyse définie dans une dimension. Elle regroupe un ensemble de paramètres organisés de la granularité la plus fine vers la granularité la plus générale.
❖ Les attributs ou membres d'une dimension sont organisés suivant des hiérarchies et Chaque attribut appartient à un niveau hiérarchique (Ou niveau de granularité) particulier.
Les hiérarchies sont primordiales dans le modèle dimensionnel puisqu'elles sont employées pour manipuler les mesures lors des opérations d’agrégation.
❖ Un cube : un cube de données est une structure dimensionnelle constitué d'une ou plusieurs tables de faits avec leurs tables de dimensions.
III.4.2.5 Les type des modélisations multidimensionnelles
C’est la description de la base multidimensionnelle indépendamment des
choix d'implantation.
En rapport avec, nous avons trois modèles ou schémas à savoir :
a. Le schéma en étoile
C’est une structure constituée d’une table de faits, contenant des données factuelles au centre et entourée par des tables de dimensions qui contiennent des données de référence (éventuellement dénormalisées).
Dans un tel schéma, les mesures sont regroupées dans un seul fait relié à plusieurs dimensions regroupant les paramètres de l’analyse et les dimensions ne sont pas en relations entre elles.
Avantage :
• Facilité de navigation ;
• Nombre de jointures limité.
Inconvénients :
• Redondance dans les dimensions ;
• Toutes les dimensions ne concernent pas les mesures.
b. Le schéma en constellation
Ce schéma est une extension du schéma en étoile. Il consiste à fusionner plusieurs schémas en étoile qui utilisent des dimensions communes.
Un schéma en constellation comprend donc plusieurs faits reliés à un ensemble de dimensions qui peuvent être partagées. Autrement dit, Dans un schéma en constellation, plusieurs modèles dimensionnels se partagent les mêmes dimensions, c'est-à-dire, les tables de faits ont des tables de dimensions en commun.
A ce niveau transforme les concepts du niveau conceptuel en tenant compte d’un modèle de données particulier. C’est la description de la base multidimensionnelle suivant la technologie utilisée.
Au niveau logique, nous n’avons qu’un seul modèle ou schéma à savoir :
c. Le schéma en flocon
Dans un schéma en flocon, la table de faits, référence les tables de dimensions de premier niveau, au même titre que le schéma en étoile. La différence réside dans le fait que les dimensions sont décrites par une succession de tables appelée hiérarchie (à l’aide de clefs étrangères) représentant la granularité de l'information. Dans ce modèle on a un seul niveau hiérarchique par table de dimension et la table de dimension de niveau hiérarchique le plus bas est reliée à la table de fait (elle a la granularité la plus fine).
Avantage :
• Normalisation des dimensions ;
• Economie d’espace disque (réduction du volume) ;
• Ce schéma évite les redondances d’information.
Inconvénients :
• Modèle plus complexe (nombreuses jointures) ;
• Requêtes moins performantes ;
• Navigation difficile.
III.4.3 data mining (La fouille
de donnée)
« Les données ne naissent pas pertinentes, mais elles le deviennent »
III .4 .3.1 définitions
Le Data mining est une méthode et technique permettant de recherché est de pouvoir extraire les données (connaissance de l’entreprise) ;
Le data mining est un ensemble d’outils d’analyse d’entrepôt de donnée et de cube apportant au décisionnaire des éléments supplémentaires de prise de décisions qui ne sont pas forcément visible aux premiers abord
III.4.3.2 objectifs
Le data mining à trois objectifs :
❖ Expliquer : le data mining pourra tenter d’expliquer un évènement ou un incident indiscernable par la consultation des informations contenues dans l’entrepôt de données de l’entreprise. Le Data mining va aider à trouver des hypothèses d’explications ;
❖ Confirmer : le data mining aidera à confirmer un comportement ou une hypothèse, si le décisionnaire a de doute, il pourra tenter de confirmer cette hypothèse en la vérifiant en appliquant des méthodes statistique ou d’intelligence artificielle ;
❖ Explorer : enfin, il peut explorer les données pour découvrir un lien inconnu jusque-là. Il ne doit pas être vu et utilisé uniquement en tant qu’aide à la prise de décision.
Par contre, l’informatique décisionnelle dans son ensemble, et plus particulièrement le data mining permet de suggérer des hypothèses. La décision finale appartiendra toujours au décideur.
III.4.3.3 Les méthodes du data mining
Il utilise des méthodes d’apprentissage automatiques, Ces méthodes sont
de deux types :
➢ Analyse descriptive
➢ Analyse prédictive
III.4.3.3.1 analyse descriptive
(par classification)
Le principe de ces méthodes est de pouvoir mettre en évidence les informations présentes dans le Data warehouse mais qui sont masquée par masse de donnée. Parmi les techniques et algorithme utilisé dans cette analyse, on a :
o Analyse factorielle (ACP& ACM)
o Méthodes de centres mobiles
o Classifications hiérarchique
o Classifications neuronale (réseaux de kohonen)
o Etc….
III.4.3.3.2 Analyse prédictive (par réseaux de neurones)
Contrairement à son précèdent, cette technique fait appels a de l’intelligence artificielle. L’analyse prédictive, est comme son nom l’indique une technique qui va essayer de prévoir une évolution des évènements en se basant sur l’exploitation de ceux stockés dans le Data warehouse.
En marketing, l’objectif est par exemple de déterminer les profils d’individus présentant une probabilité importante d’achat ou encore de prévoir à partir de quel moment un client deviendrai infidèle.
Parmi les techniques & algorithme utilisé dans l’analyse prédictive, on a :
o L’arbre de décision
o Réseaux de neurone
o La régression linéaire o L’analyse probabiliste o Etc….
III.4.3.4 Les techniques du Data mining
Derrière ces analyses se positionnent des outils basés sur des techniques différentes. Voici de plus importante de ces techniques :
o Découverte de règle
o Arbre de décision o Signal processing o Fractales
o Réseaux neuronaux
o Hybride
o Etc….
III.5 conclusion
Nous avons défini le système décisionnel comme un ensemble de moyens, d’outils et de méthodes permettant de collecter, consolider, modéliser et de restituer les données de l’entreprise dans le but d’apporter une aide à la prise de décision. Ce système comporte généralement deux types de composant : Un entrepôt de données (DATA WAREHOUSE) et un magasin de données (DATA MART), ainsi que des méthodes d’exploration des données.
Un entrepôt de données a pour vocation l’aide à la prise de décision en présentant une vue synthétisée des données de toute l’entreprise. C’est dans cette optique que son architecture est pensée. Il est orienté sujet, intégré, historisé et non volatile. Son objectif ultime est de centraliser l’information décisionnelle en assurant l’intégration des données extraites, la pérennité de ces données dans le temps et la conservation de leurs évolutions.
Le magasin de données en soit, n’est qu’un mini entrepôt contenant des informations extraites de l’entrepôt et se rapportant à un secteur d'activité particulier de l'entreprise ou à un métier qui y est exercé. Il a donc pour objectif de supporter efficacement des processus d’analyse de type OLAP.
Ainsi, les données stockées dans un magasin doivent correspondre à une structure adaptée aux analystes et visant à aider les décideurs non informaticiens lors de la prise de décision. Cette représentation des données est basée sur une modélisation multidimensionnelle.
Chapitre IV. APPLICATION
IV.1 Présentation de l’entreprise
IV.1.1 Historique de L’office congolais de contrôle
Knight et kotechna se voulant des arbitres impartiaux des échanges commerciaux, ces sociétés répondaient au besoin légitime de chaque partenaire d’acheter et de consommer des produits qui, non seulement réunissent des critères minima de qualité, mais qui en plus, sont fournis à des prix juste et équitables.
La SCS qui était par la suite dénommée SZS poursuivra son travail jusqu’au 30 septembre 1973, date à laquelle celle-ci deviendra OZAC à la suite de la zaïrianisation décrétée par le pouvoir public.
OZAC héritera de tout le partenaire de SCS, à la suite de la libération du pays de la dictature et du changement du nom du pays par le feu M’zée Laurent Désiré Kabila, l’ex président de la RDC, OZAC passera pour L’OCC jusqu’à nos jours
IV.1.2 Situation géographique
La direction générale de l’Office Congolais de Contrôle en sigle « OCC »
se trouve au numéro 98 de l’avenue du port à Kinshasa/Gombe, en RDC
IV.1.3 Nature juridique
Le statut juridique de l’OCC est défini par l’ordonnance loi N° 074/013 du 10 janvier 1974 qui stipule que l’OCC est un établissement /organisme public à caractère technique et commerciale dote de la personnalité juridique propre et placée sous la tutelle du ministre du commerce extérieure.
Le décret N° 09/42 du 03 décembre 2009 qualifie l’OCC comme toujours un établissement public en ajoutant qu’il l’est aussi à caractère scientifique et fixe les statuts d’un établissement public.
IV.1.4 Mission
L'OCC a pour mission le contrôle de la qualité, de la quantité, de prix et de conformité des marchandises tant à l'importation qu'à l'exportation et même à la fabrication locale pour :
➢ Protéger la santé de la population en empêchant l'entrée des produits impropres à la consommation par l'analyse physico-chimique et microbiologique des échantillons et produits ;
➢ Prévenir les sinistres et procéder au constat de dommage ou de avarie survenu aux marchandises et produits, et établir les certificats y afférant ;
➢ Le contrôle technique des appareils de production ainsi que celui des travaux
;
➢ La gestion et l'exploitation de silos, magasins généraux et entrepôts de douanes ;
➢ Toute opération se rapportant directement ou indirectement à son activité
légale, sauf des opérations d'achats en vue de la revente.
IV.1.5 vision
L’OCC se veut être un organisme leader reconnu au niveau international pour soutenir les efforts de développement économique, industriel et le progrès social
dans le pays
L’OCC se veut un organisme tierce partie, impartial dont la structure, le personnel, la compétence et l’intégrité lui permettent d’accomplir ce rôle d’arbitre selon des critères définis.
Encore un organisme d’évaluation de la conformité : il est membre correspondant de l’ISO membre de CEI et de l’ARSO aussi de L’OMC depuis le 01er janvier 1997
IV .1.6 structure organique et fonctionnement de l’OCC
IV.1.6.1 structure organique
L’OCC a une structure centralise C’est à dire que les décisions importantes s’arrêtent a la direction générale, dont il est question du pouvoir macro hiérarchique, il s’agit de :
➢ Le conseil d’administration ;
➢ Le comite de gestion ;
➢ Les départements centraux ;
➢ Les directions provinciales ;
➢ Les agences.
1. Le conseil d’administration
Il s’occupe de la bonne gouvernance. Il est compose de dix administrateurs
provenant du ministère de tutelle, des acteurs économiques et du personnel de l’office.
2. Le comite de gestion
C’est l’instance exécutive qui supervise la gestion et qui assiste le conseil d’administration par ses recommandations. Il se confond à la direction générale, aujourd’hui composé de trois membres a savoir le directeur général, le directeur général adjoint et le directeur financier.
3. Les départements centraux
Chaque département est spécialisé dans un champ opérationnel. Les différents métiers de l’OCC permettent au département de proposer un très large choix de prestation de services pour les acteurs économique et institutionnels. A la tête de chaque département, il Ya un titulaire et son adjoint. Et voici, ces différents départements repartie en deux groupes :
A. Département de gestion
➢ Département administratif ;
➢ Département audit interne ;
➢ Département commercial ;
➢ Département informatique ;
➢ Département juridique ;
➢ Département planification & développement ;
➢ Département service généraux
B. Département d’exploitation
➢ Département certification des produits ;
➢ Département commissaire d’avaries ;
➢ Département contrôle des exports ;
➢ Département contrôle des importations ;
➢ Département métrologie et contrôle technique ;
➢ Département normalisation ;
➢ Département de laboratoires
Tous les dix-sept départements dépendent (y compris ceux formant la nature des départements AB) directement de la direction générale et leurs pouvoirs des spécialisations ou compétences.
1. Les directions provinciales
Il y en a neuf sur toute l’étendue du pays, au niveau de chaque direction provinciale trônent un chef de la direction provinciale et son adjoint puis viennent les chefs de divisions (et leur adjoint) au caractéristique de différents département centraux.
2. Les agences
Les agences sont issues de direction provinciale, il y en a vingt et trois sur toute le territoire national
IV.1.6.2 fonctionnement
Dans le cadre de la surveillance des transactions commerciales en RDC, les contrôles de l'OCC sont en la base des statistiques que publie le gouvernement sur le commerce extérieur et la production industrielle locale.
I. Contrôle des exportations
Ce contrôle est requis afin d'assurer :
• La valorisation des produits exportés en fonction de critère de qualité ;
• La défense du juste prix des produits congolais exportés ;
• La promotion du commerce extérieur ;
• La contribution à l'augmentation des recettes de l'OFIDA en décelant tout le cas de sous facturation.
Départ le texte qui le régit, l'OCC contrôle toutes les exportations congolaises en émettant tout d'abord un certificat de qualité qui `est le contrôle analytique principale après le contrôle d'usage, il livre le certificat de vérification à l'exportation qui déclare la marchandise conforme aux manifestes d'exportation.
II. Contrôle des importations
Le contrôle à l'importation est requis pour :
• Défendre l'équilibre de la balance des paiements par la découverte des facturations et des indications à la banque centrale des commissions rapatriables ;
• Sauvegarder les intérêts des opérations économiques grâce aux redressements qualitatifs et quantitatifs de produits et marchandises importés ;
• Sauvegarder la santé du consommateur par les surveillances da la qualité des produits alimentaires et pharmaceutiques. Il existe deux contrôles principaux sur toutes les importations vers la RDC selon qu'il existe deux types d'importation ci-après : importation avec licence et les importations sans licence ou irrégulières.
III. Le contrôle de la production industrielle locale
L'OCC a l'obligation de contrôler la production industrielle, locale pour garantir les standards de qualité. Ces contrôles ne sont pas seulement essentiels pour des raisons de sécurité et de santé de la population, mais aussi une plus grande compétitivité de l'industrie locale. Des conventions et protocoles d'accords ont été signés entre l'OCC et les producteurs à cet effet.
IV. Contrôles techniques
Ces contrôles concernent le secteur de la sécurité, de l'environnement du travail, de la métrologie légale, de l'industrie et des travaux divers (constructions,...) c'est ainsi que l'OCC réalise le contrôle périodique des appareils sous pression (chaudières), d'élevages (Ascenseurs), des câbles de mines, ...ils possèdent à la réception des ouvrages les contrôles métrologies (poids et volume) rassurent les consommateurs de l'exactitude dans la délivrance des articles soumis au contrôle pondéral ou volumique (débit du carburant, ...)
V. Commissariat d'avarie
Celui-ci reste un corollaire et un prolongement obligé de l'activité de contrôle. Ainsi l'OCC renseigne la Banque Centrale sur les commissions rapatriables pour les polices d'assurances souscrites en devises étrangères. L'OCC est le superviseur officiel des réclamations d'assurances pour les dégâts causés sur les marchandises pendant le transport et assure la prévention des risques sur les exportations des produits miniers de la Gécamines.
IV.1.7organigramme de l’occ
Figure 10. Organigramme de l’OCC
IV.2 Démarche d’urbanisation
A savoir, dans le deuxième chapitre nous avons détaillé la démarche d’urbanisation de système d’information, mais dans le cadre de ce travail, nous choisissons la démarche itérative qui sera basé sur l’approche top-down. Notre méthodologie se présente de la manière suivante :
❖ La modélisation de la stratégie ;
❖ Analyse et cartographie du système existant ;
❖ Description du système d’information cible, aligné sur la stratégie d’entreprise ;
❖ Détermination de la trajectoire à suivre pour atteindre ce système d’information
cible.
IV.2.1 Modélisation de la stratégie
L’objectif stratégique et majeur de l’OCC est d’assurer la qualité des
produits sur le marché Congolais.
En voici, la modélisation de la stratégie de l’OCC par le diagramme des causes à effet ou diagramme d’Ishikawa :
Ordonner à un fournisseur ou un service de soumettre son produit au contrôle
Assurer la bonne gouvernance du SI
Contrôler la qualité, quantité, le prix et la conformité des
Contrôler avant accès sur
Le marché
Couvrir les aspects de conformité et de performance
Equipez d’un
marchandises Etablir les notes
de controle
système décisionnel
Analyse de qualité des
Produits
Valider les preuves et documents administratifs
Gérer les documents avant accès sur le marché
Veiller à la qualite aux frontières
figure.11 diagramme d’Ishikawa
de l’OCC
IV.2.2 Analyse et cartographie de système existant
IV.2.2.1 Modélisation et cartographie de l’architecture métiers
Comme nous le savons, dans l’architecture métier, il y a trois types de processus et dans le cadre de ce travail, ces processus sont constitués des organes ci- après :
1. Le processus de pilotage
Ici nous avons comme organe : le comite de gestion, le conseil d’administration et l’administrateur délégué général. Ces organes ont la vocation de fixer les règles suivantes :
❖ La conception, l’orientation, le contrôle et la décision de l’office ;
❖ Définir la politique générale, en déterminer le programme, arrêter le budget et approuver les états financiers de fin d’exercice. Développer l’efficacité et la qualité des prestations et impulser les politiques de développement de l’Office.
2. Le processus opérationnel ou de réalisation
Les processus de la chaine de valeur de l’entreprise destinés à créer de la valeur pour le client. Dans le cas de l’OCC, le processus opérationnel est constitué des organes suivant : Le département Commissariat d’Avaries, le département de Contrôle des Exportations, le département de Contrôle des Importations, le département des Certifications de Produits, le département des Laboratoires, le Département de Contrôles techniques, le département de Métrologie et le département de Normalisation. Ces organes ont pour vocations de rendre disponibles les services suivants :
❖ Réaliser les constats, certificats et expertises ;
❖ Concevoir, coordonner et superviser les activités d’inspection des produits destinés à l’exportation sur l’ensemble du territoire national ;
❖ Assurer la conformité des importations aux textes légaux et réglementaires
ainsi qu’aux normes ;
❖ Effectuer le contrôle de quantité, de qualité et de conformité de toutes les marchandises et de tous les produits fabriqués sur le territoire de la République
❖ Assurer l’évaluation de la conformité, au moyen d’essais physico-chimiques et/ou microbiologiques, lors de l’inspection des marchandises importées ou exportées, et lors de la certification des produits.
3. Le processus de support
Nous avons les périphériques au métier de l’entreprise et soutiennent son
activité. Ils fournissent des services, des moyens techniques et financiers, des ressources
humaines et matérielles aux processus opérationnels de l’entreprise :
après:
Dans le cas de l’OCC, ce processus est constitué des Départements ci-
❖ Le Département Administratif ;
❖ Le Département Audit Interne ;
❖ Le Département Commercial ;
❖ Le Département Financier ;
❖ Le Département Informatique ;
❖ Le Département Logistique ;
❖ Le Département Planification et Développement.
IV.2.2.2 Cartographie de l’architecture métiers de l’OCC
Figure .12 cartographie de la vue métier de l’OCC
P a g e
| lxxii
IV.2.2.3 Cartographie de l’architecture fonctionnelle
IV.2.2.3.1 Découpage du système d’information
Cette activité consiste à découper le système d’information en plusieurs
parties de taille différente de la manière suivante :
❖ Les zones : sont définies de manière à correspondre à une
préoccupation de temps et/ou de métier de l’entreprise.
❖ Les quartiers : sont définies par la nature des informations traitées
❖ Les blocs : est un ensemble des données et des traitements homogènes dans une activité de l’entreprise. Le bloc est le composant de base de l’entreprise
Dans le cadre de l’OCC, nous présentons ci-dessous les zones, quartiers et
blocs après un découpage strict de notre système d’information :
Différentes zones répertoriées
- Inspections et Contrôles ;
- Tests et Analyses ;
- Certification et Normalisation ;
- Assurances marchandises.
• Différents quartiers répertoriés pour la zone « Inspections et Contrôles »
- Le Département Contrôle des Importations ;
- Le Département Contrôle des Exportations ;
- Le département des contrôles techniques.
• Différents quartiers répertoriés pour la zone « Tests et Analyses »
- Le département des Laboratoires
• Différents quartiers répertoriés pour la zone « Certification et
Normalisation »
- Le département des Certifications de Produits ;
- Le département de Normalisation.
• Différents quartiers répertoriés pour la zone « Assurances marchandises »
- Le département de Commissariat d’Avaries
✓ Les blocs pour quartier Contrôle des Importations
- Contrôle Avant Embarquement ;
- Suivi des imports ;
- Contrôle Arrivées (Métrologie).
✓ Les blocs pour quartier Contrôle des Exportations
- Vérification des Exports ;
- Suivi des Exports.
✓ Les blocs pour quartier Contrôles techniques
- Sécurité et Salubrité sur les lieux du travail ;
- Production industrielle locale
- Contrôles automobiles, des unités fluviales et lacustres
✓ Les blocs pour le quartier Laboratoires
- Analyses et tests des produits Agricoles et Denrées
Alimentaires ; Chimique ;
Cosmétiques.
- Analyses et tests des Textiles, Produits de chimie et de Génie
- Analyses et tests des Produits Pharmaceutiques et
✓ Les blocs pour la Certification de Produits
- Certification d’Agrochimies ;
- Certification des produits Pharmaceutiques et Cosmétiques ;
- Normes et référentiels.
✓ Les blocs pour l’Assurances Marchandises
- Contentieux et Recours ;
- Suivi et Statistiques des Avaries
-
|
Zone |
Quartier |
Ilots ou Bloc |
|
Inspections et contrôles |
➢ Département de contrôle des importations ;
➢ Département de contrôle des exportations ;
➢ Département des contrôles techniques. |
• Contrôle avant Embarquement ; • Suivi des imports ; • Contrôle Arrivées (Métrologie). • Vérification des
• Suivi des Exports.
• Sécurité et Salubrité sur les lieux du travail ; • Production industrielle locale ; • Contrôles automobiles, des unités fluviales et lacustres. |
|
Tests et analyses |
➢ Département de laboratoire |
• Analyses et tests des produits Agricoles et Denrées Alimentaires ; • Analyses et tests des Textiles, Produits de chimie et de Génie Chimique ; • Analyses et tests des Produits Pharmaceutiques et Cosmétiques. |
|
Certification & Normalisation |
➢ Département de certifications de produit ;
➢ Département de normalisation |
• Certification d’Agrochimies ; • Certification des produits Pharmaceutiques et Cosmétiques.
• Normes et référentiels. |
|
Assurance marchandise |
➢ Département de commissariat avaries |
• Contentieux et Recours ; • Suivi et Statistiques des Avaries |
Tableau .2 découpage du système d’information
IV.2.2.3.2 cartographie de l’architecture fonctionnelle de l’OCC
Zone d’échange
Contrôle
Pilotage
Conseil
d’administration
Comite de gestion
Direction générale
Inspection & contrôle
Contrôle des importations
Contrôle des exportations
Contrôle technique
Activité support
Administration Audit interne Finance Commercial Informatique
Logistique
Planification &
Développement
Certification &
normalisation
Certification de produit
Normalisation de produit
Tests & analyses
Laboratoire
Assurance marchandise
Commissariat
avarie
Figure 13. Cartographie de la vue fonctionnelle de l’OCC
IV.2.2.4 Diagnostic de l’analyse et scenario de mise en œuvre
IV.2.2.4.1 Critique de l’existant
Nous constatons qu’au niveau du processus de pilotage, les décideurs se focalisent que sur le contrôle de gestion mais la majorité de tâche se fait manuellement même dans la surveillance de produit c’est-à-dire la provenance de produit, la durée de consommation de produit alimentaire, leur qualité etc… il y a l’absence d’un système d’information de gestion (SIG) fiable et cela constitue un danger permanent pour cette entreprise public.
En plus, dans l’architecture actuelle, les décideurs n‘ont pas d’outils fiables pour leur
Prise de décision et pour faire évoluer leur système d’information.
IV.2.2.4.2 Proposition des solutions
Dans le cadre de ce travail, nous proposons deux solutions dont l’une manuelle et l’autre informatique :
➢ Solution manuelle : Après avoir étudié et critiqué le système en place, nous
proposons aux décideurs de l’OCC les solutions suivantes :
✓ Cartographier et urbaniser l’ensemble du système d’information de cette
entreprise ;
✓ D’intégrer le contrôle intelligent de produit au niveau de zone d’échange contrôle dans l’architecture Fonctionnelle ;
✓ Bien repartir les différentes tâches des agents et les envoyer dans des formations pour la mise en niveau.
➢ Solution informatique :
✓ Développé un logiciel de gestion des avaries qui sera intégrer dans la zone
d’échange assurance marchandise ;
✓ Après analyse du système existant, nous proposons aux décideurs de cette entreprise de mettre en place un outil d’aide à la décision basé sur le datamining pour minimiser le risque liés à la provenance et destination des produits, la durée de consommation de produit alimentaire et leur qualité. En plus, les décideurs doivent disposer des outils de cartographie pour faire l’évolution de leur système d’information.
IV.2.2.4.3 Choix de la meilleure solution
Après l’analyse du système existant et des propositions de solution, il préalable de trouver et de proposer aux responsables une meilleure solution qui répondra à leur besoin.
C’est ainsi, notre choix se focalise sur la solution informatique, car celle- ci va garantir aux dirigeants la bonne prise de décision lors la provenance et destination des produits, la durée de consommation de produit alimentaire et leur qualité et la bonne gouvernance de l’ensemble du système d’information grâce à la démarche d’urbanisation.
IV.2.2.5 Description du SI cible
Conformément à notre travail, nous allons maintenant décrire le système d’information cible qui tient compte de nos propositions souhaitées enfin de permettre aux décideurs la bonne gouvernance de l’ensemble de son système d’information. Ainsi, la description du système d’information cible sera réalisé en trois volets et cela s’effectuera de la manière suivante :
£ La cartographie de l’architecture fonctionnelle cible ;
£ Mise en place de la cartographie du système d’information ;
£ Flux de circulation des informations entre les différents processus.
IV.2.2.5.1 Cartographie fonctionnelle cible
Zone d’échange
Contrôle
Pilotage
Conseil
d’administration
Comite de gestion
Inspection & contrôle
Contrôle des importations
Contrôle des exportations
Contrôle technique
Activité support
Administration Audit interne Finance Commercial
Informatique
Direction générale
Contrôle intelligence via
infra-rouge
Logistique
Planification & Développement
Certification &
normalisation
Tests & analyses
Laboratoire
Certification de produit
Normalisation de
produit
Assurance marchandise
Commissariat avarie
Gestion des
avaries
Figure 14. Cartographie de la vue fonctionnelle cible
IV.2.2.5.2 Cartographie du système d’information
Processus de Pilotage
Conseil
d’administration
Comité de Gestion Administrateur délégué général
Processus d’inspection & contrôle
Processus Opérationnel
Contrôles d’importations
Contrôles d’exportations
Contrôles techniques
Processus de test & analyse
Analyse & test de produit agricole et
donnée alimentaire
Analyse & test de textiles, produit de chimie et de génie
chimique alimentaire
Analyse & test des produits cosmétiques et
pharmaceutique
Processus de certifications & normalisation
Certification agrochimique
Certification produits pharmaceutique et
cosmétique
Normes & référentiels
Processus d’Assurances marchandises
Contentieux & recours
Suivi & statistiques des avariés
Support de planification
Processus de support
Support d’administration
Support d’Audit Support de Logistique
Support de Commerciale Support Informatique Support de Finance
IV.2.2.5.3 Flux d’information circulant entre divers processus
Figure 15. Cartographie de système d’information
Processus de pilotage
Conseil d’administration
PV de conseil d’administration
Conseil d’administration
PV de conseil d’administration
Conseil d’administration
• Instruction général & lettre circulaire
• Ordre de service & lettre collective
Processus Opérationnel
Normalisation
Métrologie
Contrôle
d’importation
Certification des produits
Laboratoire
Contrôle
d’exportation
Contrôle des
produits
Commissariat
d’avariés
Contrôle
technique
AVIS de service Rapport
Processus de support
Logistique
Finance
Planification &
développement
Administration
Audit interne
Commercial
Informatique
Figure 16. Flux d’information circulant entre divers processus
IV.2.2.5.4 Détermination de la trajectoire à suivre
Services
Palier 3
Palier 4
f
Palier 2
Palier 1
Temps
Figure 17. Détermination de la trajectoire
IV.2.2.6 Développement de l’application
Pour ce qui concerne ce travail, la méthodologie de développement de notre application se présente de la manière suivante :
✓ Une étude préalable ;
✓ La conception ;
✓ Le déploiement et la segmentation.
IV.2.2.6.1 Etude préalable sur la gestion constatation des avaries et de la rédaction du certificat des avaries
I. La constatation des avaries
Dans la mission légale de l'OCC figure aussi la constatation des avaries survenues aux marchandises et produits en vue d'établir le certificat d'avaries y afférant. L'avarie est selon le Chef de ce service, quelque chose d'anormal, une pourriture ou rouille, du dommage ou casse en même temps un manquant survenu sur la marchandise ou le produit.
Étymologiquement, ce mot provient de l’arabe ÚæÇÑ `awâr, avarie; défaut; imperfection. Mais, aujourd'hui, c'est un terme utilisé par les marins pour désigner un problème d'origine technique : casse d'une pièce, déchirure d'une voile. Ces avaries sont de nature diverse : manquant à la livraison, coulage, casse, souillure, rouille, mouillure, pourriture dégageant une odeur nauséabonde etc. L'OCC alors dans le souci de répondre à cette mission légale précitée, il se fixe comme objectifs à atteindre :
• Veiller à ce que les marchandises importées soient conformes à la commande de l'importateur ;
• Garantir que ces marchandises soient propres à la consommation humaine sinon, procéder à leur destruction.
Ainsi, peut-on se targuer, la RDC est épargnée d'être la poubelle car tout est tamisé par l'OCC avant la mise en consommation. Bel objectif n'est-ce pas et est-il atteint ! De cette façon, le commissaire d'avarie détermine la nature, la hauteur et la cause des avaries afin de permettre aux opérateurs économiques de se faire indemniser par les assureurs ou par les tiers responsables, en statuer sur les responsabilités : soit c'est le fournisseur ou le transporteur, l'assureur peut le cas échéant poursuivre le transporteur si les avaries viennent de lui. Plusieurs documents sont indispensables pour la constatation d'une avarie :
• Police d'assurance,
• Factures du fournisseur,
• La liste de colisage,
• La LT, le rapport du déchargement de l'OCC,
• L'AV BIVAC,
• Le PV du constat contradictoire de la SNCC,
• Copie de la lettre de réserve adressée au dernier transporteur venant du propriétaire présentant ses regrets, son indignation sur les dommages survenus,
• Constat de l'emballage, s'assurer que les scellés ou plombs en place sont d'origine, aussi pendant l'itinéraire s'il n'y avait pas de rupture de charge, transbordement qui serait la cause de l'avarie.
L'exploitation de ces divers documents suffit pour l'établissement du constat des avaries et par la suite du certificat de celles-ci.
II. Le certificat d’avaries
Ce certificat a pour importance de faire bénéficier aux importateurs de l'indemnisation de leurs marchandises, à condition que les importateurs aient souscrit à l'assurance de leur cargaison (Police d'Assurance). Il est le seul document engageant l'OCC à l'étranger, donc, dans le monde des assureurs et des fournisseurs pour réclamer la réparation des dommages survenus sur les marchandises. Il est opposable, conciliant deux contractuels, l'assureur et
l'assuré.
Une marchandise avariée et qui avait été couverte par l'assurance, c'est celle devant être remboursée ou restituée. On assure celle-ci contre les éventuels risques sur le trajet. Le certificat est établi en série que voici :
• SERIE 00 : certificat dont la marchandise est impropre à la consommation humaine, constat fait à l'œil nu ou par l'odorat ; d'emblée suspecte à la consommation du fait de l'odeur ou à la vue ;
• SERIE 100 : cas de la marchandise non conforme soit parce qu'il n'y a pas d'indications précises sur : nom de la marchandise, pays d'origine, date de péremption, l'étiquetage, le numéro du lot, soit le nom, l'adresse du fabricant et code de production manquent ;
• SERIE 200 : ici, sont classés les certificats dont la police d'assurance étrangère en copie, a été transmise à l'OCC ;
• SERIE 300 : dans ce cas, c'est l'original de cette police d'assurance qui a été remis à l'OCC et l'Office réclamera le dédommagement à la place de l'importateur. L'OCC agit comme commissaire pour ce type de certificat ;
• SERIE 400 : ce type de certificat est fait s'il n'y a pas de police d'assurance, mais sur demande de l'importateur seulement ;
• SERIE 500 : ce certificat concerne les produits à l'exportation, donc, qui quittent la RDC mais assurés par la SONAS.
PROCEDURES POUR L'OBTENTION DU CERTIFICAT : La requête est adressée au CA qui l'accepte et transmet des ordres via le SEX au Bureau Commissariat d'Avarie. De cette façon, le Commissaire d'avarie est obligé d'entrer en contact avec le requérant ou le commerçant pour l'obtention des documents relatifs au dossier, documents déjà cités dans le point constatation des avaries. Tous les certificats s'obtiennent contre paiement de ceci :
• Frais honoraires du Commissaire d’avarie : 265$US
• Ouverture dossier : 15$US
• TVA : 16%
Lors de notre passage à ce bureau, nous avions visualisé le Certificat d'Avarie n° A.MDT/2006/400.022 du requérant NTUMBABO TSHUNZA, concernant la marchandise : bougie britellite du fournisseur HEXACON INTL Commodity Traders Pty Ltd. Avarie constatée : manquants à l'embarquement : 3080 supposés contre 1802 déchargés, donc, 1278 comme manquant. Le certificat était de la série 400, car le requérant n'avait de police d'assurance. Le certificat d'avarie est signé en six exemplaires par le Commissaire d'avarie en tant qu'expert de l'OCC et le CA dont copies envoyées à la fois au DCA et à la DIPROKOR. Document détenu au niveau de ce bureau : le registre de production des certificats.
IV.2.2.6.2 La conception de la base de données transactionnelle
IV.2.2.6.2 .1 Modélisation par approche merise
La règle de gestion est l’ensemble de normes fixés par une structure quelconque qui permet aux différents acteurs d’adopter un certain comportement afin d’attendre les objectifs. Nous pouvons dire encore que la règle de gestion est l’ensemble des règles qui régissent l’organisation de l’entreprise en déterminant la façon dont les événements se déroulent dans l’entreprise, Suite à notre interview avec quelques agents de l’O.C.C, nous avons ressorti les règles de gestion qui précisent les contraintes qui doivent être respectées par le modèle :
Règle de gestion 1 : Un ou plusieurs agents travaillent dans une et une seule agence tandis qu’une agence a besoin d’un ou plusieurs agents.
Règle de gestion 2 : chaque marchandise est fournie par un et un seul
fournisseur tandis qu’un fournisseur fourni un ou plusieurs marchandises.
Règle de gestion 3 : chaque marchandise est constituée d’un et seul bon de marchandise tandis qu’un bon de marchandise constitue une et une marchandise.
Règle de gestion 4 : chaque bon de marchandise se situe dans un et
un seul container.
Règle de gestion 5 : chaque bon de marchandise est destiné à un et un seul destinataire.
Règle de gestion 6 : chaque requérant déclare un ou plusieurs bon de
marchandise.
Règle de gestion 7 : chaque agent rédige un ou plusieurs bon de marchandise. Ainsi, après analyse de l’existant, nous avons retenu les entités suivantes pour notre base de données : Agent, agence, marchandise, fournisseur, bon de marchandise, container, destinataire, requérant. Dans ce cas, le dictionnaire sera donc :
|
RUBRIQUES |
DEFINITIONS |
NATURES |
TAILLES |
|
Id_agent
Nom agent
Post nom agent Téléphone agent Adresse agent E-mail agent |
Identifiant de l’agent
Nom de l’agent
Post nom de l’agent
Téléphone de l’agent
Adresse de l’agent
Adresse électronique de l’agent |
Entier
Chaine Caractère Chaine Caractère Chaine Caractère Chaine Caractère Chaine Caractère |
20
20
20
20
20 |
|
Id_agence Libelle agence Adresse agence Téléphone agence |
Identifiant de l’agence
Information de l’agence
Adresse de l’agence
Téléphone de l’agence |
Entier
Chaine Caractère
Chaine Caractère
Chaine Caractère |
20
20
20 |
|
Id_bon_marchandise
Libelle bon
Assurance |
Identifiant de bon_marchandise
L’information sur le bon
Assurance du bon |
Entier
Chaine Caractère
Chaine Caractère |
20
20 |
|
Id_fournisseur
Nom fiss
Post nom fiss Téléphone fiss Adresse fiss E-mail fiss |
Identifiant du fiss
Nom du fiss
Post nom du fiss Téléphone du fiss Adresse du fiss Adresse électronique du fiss |
Entier
Chaine Caractère Chaine Caractère Chaine Caractère Chaine Caractère Chaine Caractère |
20
20
20
20
20 |
|
Id_container Libelle container capacité |
Identifiant du container
L’information sur le container
La capacité de contenir |
Entier
Chaine Caractère
Chaine Caractère |
20
20 |
|
Id_requerant
Nom reque
Post nom reque
Téléphone reque |
Identifiant du requérant
Nom du requérant
Post nom du requérant
Téléphone du requérant |
Entier
Chaine Caractère
Chaine Caractère
Chaine Caractère |
20
20
20 |
|
Adresse reque
E-mail reque |
Adresse du requérant
Adresse électronique du requérant |
Chaine Caractère
Chaine Caractère |
20
20 |
|
Id_destinataire
Nom dest
Post nom dest Téléphone dest Adresse dest E-mail dest |
Identifiant du destinataire
Nom du destinataire
Post nom du destinataire
Téléphone du destinataire
Adresse du destinataire
Adresse électronique du destinataire |
Entier
Chaine Caractère
Chaine Caractère Chaine Caractère Chaine Caractère Chaine Caractère |
20
20
20
20
20 |
|
Id_marchandise Etat-marcha Type marcha Libelle marca
Quantité
Qualité |
Code marchandise
Etat de la marchandise
Type de la marchandise
Intitulé de la marchandise
Quantité de la marchandise
Qualité de la marchandise |
Entier
Chaine Caractère Chaine Caractère Chaine Caractère Numérique |
20
20
20 (9,2) 20 |
Pays de provenance Pays de provenance Chaine Caractère 20
Chaine Caractère
Tableau 3. Dictionnaire des données
IV.2.2.6.2 .1.1 Modélisation conceptuel de données
La modélisation conceptuelle est une étape constituant la description la plus stable du système. Ce modèle a pour but d’écrire de façon formelle les données qui seront utilisées par le système d’information. Dans ce cas, concernant notre travail, ce modèle se présente comme suit :
Figures 18. Schéma MCD
IV.2.2.6.2 .1.2 Modélisation logique de données
Figures 19. Schéma MLD
IV.2.2.6.2 .2 Modélisation par approche uml
IV.2.2.6.2 .2.1 diagramme de cas d’utilisations
Un cas d’utilisation permet de décrire l’interaction entre les acteurs (utilisateurs du cas) et le système. La description de l’interaction est réalisée suivant le point de vue de l’utilisateur. La représentation d’un cas d’utilisation met en jeu trois concepts :
➢ L’acteur : est un utilisateur type qui a toujours le même comportement vis- à-vis
d’un cas d’utilisation.
➢ Le cas d’utilisation : correspond à un certain nombre d’actions que le
système devra exécuter en réponse à un besoin d’un acteur.
➢ L’interaction entre l’acteur et le cas d’utilisation : permet de décrire les échanges entre un acteur et un cas d’utilisation.
Dans cette partie, nous avons pu décrire les besoins des utilisateurs vis- à-vis du système.
Figures 20. Le diagramme de cas d’utilisations
IV.2.2.6.2 .2.2 diagramme de classe
Ce diagramme nous donne l’aperçu structurel du futur système à implémenter :
Figures 21. Le diagramme de classe
IV.2.2.6.2 .2.3 diagramme des séquences
Sur ce point, nous avons illustré les interactions entre des objets au sein du système :
Figures 22. Le diagramme des séquences
IV.2.2.6.2 .2.4 diagramme d’activités
A ce niveau nous allons pouvoir décrire le comportement interne des opérations du système :
Figures 23. Le diagramme d’activités
IV.2.2.6.2.2.5 Présentation de la base de données
SQL SERVER est un système de gestion de base de données relationnelle (SGBDR), ce qui lui confère une très grande capacité à gérer les données tout en conservant leur intégrité et leur cohérence. En effet, SQL SERVER est entièrement intégré à Windows, ce qui autorise de nombreuses simplifications au niveau de l’administration tout en offrant un maximum de possibilités. Ainsi donc, SQL SERVER peut gérer deux types des bases de données différentes :
Figures 24. La base de données de l’application
IV.2.2.6.2.2.6 Construction de l’entrepôt de donnée
La modélisation dimensionnelle (ou modèle multidimensionnel) souvent appelé modélisation OLAP se présente comme une alternative au modèle relationnel. Elle correspond mieux aux besoins du décideur tout en intégrant la modélisation par sujet. Nous pouvons aussi dire que, la modélisation dimensionnelle dérive des concepts OLAP. Ainsi, par définition, la modélisation dimensionnelle (ou multidimensionnelle)
est une méthode ou une technique de conception logique qui vise à présenter les données sous standardisée, intuitive et qui permet des accès hautement performants.
Ainsi donc, un modèle multidimensionnel est composé des tables de faits et des dimensions. Pour notre travail, nous avons une table de fait (Fait Qualité) et six tables des dimensions (Fournisseur, Container, Marchandise, Requérant, Bon marchandise, Temps). En plus, nous avons utilisé le modèle en étoile
Figures 25. La modélisation multidimensionnelle
IV.2.2.6.2.3 Construction de l’entrepôt de donnée
Il est important de savoir que, lorsque l’entrepôt de données est créé et
bien modélisé, créer un cube d’entreprise est assez simple ; cela se fait en trois étapes :
❖ Création de la source de données ;
❖ Création de la vue de source de données ;
❖ Création de cube.
Pour ce qui concerne ce travail et en tenant compte de la modélisation multidimensionnelle, et à l’aide de SQL Server 2012, nous présentons la vue de source de données ainsi que le cube :
Figures 26. La vue de source de données
Figures 27. Le cube de l’application
IV.2.2.6.2.3.1 Déploiement de l’entrepôt de donnée
Figures 28. Déploiement du cube
Après le déploiement de notre mini entrepôt nous avons la liste d’un échantillon de toutes les marchandises contrôlées par OCC durant l’année 2016. Ainsi leurs pays de provenance, leurs fournisseurs et leurs quantités. Ici chaque marchandise à un bon état.
IV.2.2.6.2.3.2 La Restitution de données
Etant donné, il existe plusieurs outils pour faire la restitution des données, dans le cadre de ce travail, nous allons utiliser les outils de restitution de la gamme Microsoft Office Excel 2016.
Ici, notre objectif est de créer un tableau croisé dynamique à partir d’un cube. Le tableau croisé dynamique va être fait à partir des données et des règles de gestion contenues et spécifiées dans le cube. Faire des tableaux croisés dynamiques à partir d’un cube a beaucoup d’avantage :
➢ Les données sont centralisées. Elles sont donc utilisées par plusieurs services réduisant ainsi les risques liées au recoupement de données ;
➢ Les données sont fiables. Lorsqu’un entrepôt de données est correctement fait, les utilisateurs passent beaucoup moins de temps à la récupération et au traitement de données.
Ainsi, depuis la version 2000, Excel a la capacité de créer des tableaux croisés dynamiques à partir d’un cube. Donc, dans ce travail, le modèle de notre tableaux croisés dynamique et les graphiques réalises grâce à un tableau croisé est :
Figures 29. Tableaux synthèse de contrôle de marchandise
Figures 30. Tableaux synthèse de marchandise contrôle ainsi que leur quantité
Figures 31. Histogramme de marchandise contrôle ainsi que leur quantité
IV.2.2.6.3.3 Quelques interfaces utilisateurs et codes sources
Figures 32. Les interfaces utilisateurs
private void BtEnreg_Click(object sender, EventArgs e)
{
EnregistreRenseignementClient();
}
private void EnregistreRClient()
{
bool verifier = false;
try
{
if (DtGridVFacture.Rows.Count <= 0)
{
MessageBox.Show("Un Problème est survenu lors de l'enregistrement. " +
'\n' + "Rassurez vous d'avoir remplit la grille", "Avertissement", MessageBoxButtons.OK, MessageBoxIcon.Warning);
}
else
{
Clients client = new Clients(); client.Id_categorie = CboClinet.Text; client.Nomclient = TxtNoms.Text;
if (new DaoClients().insererClient(client))
{
Factures facture = new Factures();
facture.id_client = new
DaoClients().getIdClientByNom(TxtNoms.Text);
facture.Codeguichet = Properties.Settings.Default.Guichet;
facture.Date_Facturation = DtPDate.Value; facture.Remise = Convert.ToDecimal(Txtremise.Text); facture.IdFacture = txtNfacture.Text;
if (new DaoFactures().insererFacture(facture))
{
foreach (DataGridViewRow item in DtGridVFacture.Rows)
{
verifier = false;
DetailCommande detailcmd = new DetailCommande();
detailcmd.Id_client = new DaoClients().getIdClientByNom(TxtNoms.Text);
IV.2.2.6.3.4 Conclusion
Dans ce chapitre, nous avons réalisé l’application. Notre démarche pour la réalisation de l’application se présente en 3 volets, à savoir: Etude préalable, conception de la base de données transactionnelle, construction de l’entrepôt de données. Donc, il est important de noter que, dans ce travail nous avons utilisé l’approche merise et l’uml pour la modélisation transactionnelle et enfin nous avons aussi réalisé un mini entrepôt de données complet de contrôle de qualité de produit tout en développant l’ETL pour l’alimentation de la base de données transactionnelle (base de données source) vers le mini entrepôt de données et Pour ce qui concerne de l’application utilisateur, nous avons utilisé le langage Visual C# comme langage de programmation et SQL Server comme SGBD.
CONCLUSION ET PERSPECTIVE
Tout au long de ce travail, nous avons constaté que l’urbanisation de système d’information est très importante et elle est devenue un sujet d’actualité pour les entreprises. Ainsi, urbaniser le système d’information, c’est-à-dire diriger la transformation continue du système d’information en vue de simplifier et de garantir sa cohérence, il y a une démarche à suivre pour arriver et cette démarche est appelée
« démarche d’urbanisation ».
Dans cette démarche, le système d’information se coupe en quatre architectures ou vues : métier, fonctionnelle, applicative et technique ; la représentation graphique de ces vues constitue ce qu’on appelle « la cartographie de système d’information » et cela est réalisé grâce à un plan d’urbanisation appelé (Plan d’occupation des sols) en analogie avec l’urbanisme civil.
Dans ce travail, nous avons commencé d’abord par urbaniser le système d’information de l’office congolais de contrôle. Cependant, nous nous sommes limités à l’architecture fonctionnelle. Donc, nous avons découpé le système d’information et ensuite nous avons cartographié la vue métier et la vue fonctionnelle cible, c’est ainsi à la fin, nous avons présenté une trajectoire à suivre pour atteindre le système d’information cible.
En second lieu, nous avons mis en place un système d’aide à la prise de décision pour le contrôle de qualité de produit de l’occ. Ainsi, notre démarche pour la réalisation de l’application se présente en 3 volets, à savoir: Etude préalable, conception de la base de données transactionnelle, construction de l’entrepôt de données. Donc, il est important de noter que, dans ce travail nous avons utilisé l’approche merise et l’uml pour la modélisation transactionnelle et enfin nous avons aussi réalisé un mini entrepôt de données complet de contrôle de qualité de produit tout en développant l’ETL pour l’alimentation de la base de données transactionnelle (base de données source) vers le mini entrepôt de données et Pour ce qui concerne de l’application utilisateur, nous avons utilisé le langage Visual basic.net comme langage de programmation et SQL Server comme SGBD.
Dans ce travail, nous avons traités les éléments nécessaires pour urbaniser
un système d’information et pour mettre en place un système décisionnel.
Pour clore, les systèmes d’aide à la prise de décision actuels sont des systèmes passifs et les entrepôts de données n’échappent pas à cette règle. Les systèmes décisionnels attendent que d’autres applications leur soumettent des requêtes avant de réagir et fournir les réponses. Dans l’avenir, nous souhaiterons construire des systèmes d’aide à la décision actifs (semblables aux systèmes experts) qui sauraient reconnaître les informations intéressantes et les fournir sans interventions ou sollicitation externe. Ces systèmes chercheraient en permanence les nouvelles données
et réagiraient lorsque les changements importants seraient détectés totalement différents
des systèmes d’alerte traditionnel.
REFERENCE ET BIBLIOGRAPHIE
0. OUVRAGES
1. CASEAUX Yves, Urbanisation et BPM, Edition Dunod, 2005 ;
2. CHELLI Henri, Urbaniser l’entreprise et son système d’information, Vuibert
2003 ;
3. GOUARNE Jean-Marie, Le projet Décisionnel, Edition Eyrolles 1997 ;
4. VALLATIN Julien, Urbanisation des villes et urbanisation des S.I, juin 2002
i. NOTES DES COURS
5. KAFUNDA KATALAY Pierre, Gestion infocentre, Cours inédit, Deuxième licence informatique de Gestion, UNIKIN 2017-2018 ;
6. MAPHANA Simon, Audit informatique, Notes de cours deuxième licence, UNIKIN 2017-2018 ;
7. MBUYI MUKENDI Eugène, Fondement théorique des systèmes
d’information, 2ème licence, UNIKIN, 2017-2018 ;
8. MBUYI MUKENDI Eugène, Urbanisation de S.I, note de cours deuxième licence, UNIKIN 2017-2018 ;
ii. MEMOIRES ET THESES
9. ARSON Florence, La cartographie, outil de pilotage de l’évolution des systèmes d’information, Université de Paris 1, Mémoire 2004-2005 ;
10. CHAPPRON Julie, L’urbanisme organisationnel : méthode et aide à la décision
pour piloter l’évolution du système d’information de l’entreprise, Université Jean
Monnet, Thèse 2008 ;
11. MUKENDI Samy, De l’urbanisation vers un système décisionnel pour l’analyse de qualité des produits importés, cas de l’Office Congolais de Contrôle, Mémoire, UNIKIN, fac/Sc,Dpt Math-info 2016-2017 ;
12. SIMONIN Jacques, Conception de l’architecture d’un système dirigé par un modèle d’urbanisme fonctionnel, Université de Kermès 1, Thèse 2009 ;
13. SINDANI Evariste, Urbanisation des systèmes d’information et mise en place
d’un Système décisionnel pour l’octroi de crédit, Mémoire, UNIKIN, fac/Sc ,Dpt
Math-info 2012-2013 ;
iii. WEBOGRAPHIE
14. Wikipedia : Urbanisation de système d’information, Janvier 2018
15. www.cigref.fr, Janvier 2018 ;
16. www.cluburba-si.fr, Février 2018 ;
Table des matières
Introduction ............................................................................................................................................vii
0.1. Aperçu théorique ....................................................................................................................vii
0.2. Problématique.........................................................................................................................vii
0.3. Hypothèse ..............................................................................................................................viii
0.4. Choix et Intérêt du sujet ........................................................................................................ viii
0.5. Délimitation du sujet ............................................................................................................. viii
0.6. Méthode et techniques utilisées...............................................................................................ix
0.7. Difficultés rencontrées.............................................................................................................ix
0.8. Subdivision du travail..............................................................................................................ix Chapitre I. Généralités système d’information [2], [5] ............................................................................x I .1 Définitions [2], [5] .........................................................................................................................x
I.2 Les différentes formes d’informations [2], [5]................................................................................x
I.3 Les dimensions d’un système d’information ................................................................................xii I.3.1 la dimension informationnelle.................................................................................................... xii A. Nature ..................................................................................................................................... xii
B. Diversité ................................................................................................................................. xii
C. Critères de qualité.................................................................................................................. xiii I.3.2 La dimension organisationnelle ................................................................................................ xiii I.3.3 La dimension managériale [2]................................................................................................... xiii A. Stratégique............................................................................................................................. xiv
B. Gestion, Tactique, Contrôle................................................................................................... xiv
C. Gestion des opérations........................................................................................................... xiv I .3.4 La dimension technologique .................................................................................................... xiv I.4. les sous-systèmes d’un Système d’information ........................................................................... xv I.4.1 Le système de pilotage ou décision (SP) [5] .............................................................................. xv I.4.2 Le système d’information (SI) [5]............................................................................................. xvi I.4.3 Le système opérant (SO) [5] ..................................................................................................... xvi I.5. Rôles et fonctions du système d’information [2], [5].................................................................. xvi I.5.1 Les rôles d’un système d’information ....................................................................................... xvi I.5.2 Les fonctions d’un système d’information............................................................................... xvii I.6. Typologie d’un système d’information ...................................................................................... xvii I.7 conclusion .................................................................................................................................. xviii
Chapitre II. Urbanisation de système d’information [1], [2], [4], [6], [12], [13] .................................. xix
II.1 Urbanisation de système d’information [12], [13]...................................................................... xix II.1.1 Introduction.............................................................................................................................. xix II.1.2 Origine et importance de l’urbanisation de SI [12], [13] ......................................................... xix II.1.3 Quelques définitions liées à l’urbanisation .............................................................................. xix II.1.4 Les acteur de l’urbanisation ...................................................................................................... xx a) Maitre d’ouvrage .................................................................................................................... xx
b) Maitre d’œuvre ....................................................................................................................... xx c) Développeur ........................................................................................................................... xx II.1.5 Urbanisation d’une ville et urbanisation de système d’information [12], [13] ......................... xx II.1.5.1 Urbanisation des villes........................................................................................................... xx II.1.5.2 Urbanisation de système information .................................................................................. xxii
II.1.5.3 Etude comparative entre l’urbanisation d’une ville et l’urbanisation de système
d’information [4], [6], [12], [13] ..................................................................................................... xxiii II.1.6 Démarche d’urbanisation de SI.............................................................................................. xxiv II.1.6.1 Approche de la démarche de l’urbanisation de SI .............................................................. xxiv II.1.6.1.1 L’approche top down ou approche descendante .............................................................. xxiv II.1.6.1.2 L’approche bottom up ou approche ascendante............................................................... xxiv II.1.6.1.3 L’approche transversale ciblée ........................................................................................ xxiv II.1.6.2 La méthodologie ................................................................................................................. xxiv II.1.6.3 Principe de base de l’urbanisation ....................................................................................... xxv II.1.7 Procédure d’élaboration d’un plan urbanisme ....................................................................... xxvi II.1.7.1 Plan d’urbanisme ................................................................................................................ xxvi II.1.7.2 La modélisation de la stratégie .......................................................................................... xxvi II.1.7.2.1 Les objectifs poursuivis ................................................................................................... xxvi II.1.7.2.2 Formalisme de la stratégie ............................................................................................... xxvi II.1.7.2.3 Règle de construction d’un diagramme d’Ishikawa........................................................ xxvii II.1.8 La cartographie est un référentiel d’entreprise et sa réalisation............................................ xxvii II.1.8.1 Notion de la cartographie de SI ......................................................................................... xxvii II.1.8.2 Définition de la cartographie de SI ................................................................................... xxviii II.1.8.3 Les différents types de cartographie de SI ........................................................................ xxviii II.1.8.4.1 La cartographie métier ..................................................................................................... xxix II.1.8.4.2 la cartographie fonctionnelle ............................................................................................ xxx II.1.8.4.3 La cartographie applicative............................................................................................... xxx II.1.8.5 Les objectif de la cartographie de SI ................................................................................... xxx
II.1.8.6 quelques outils de la cartographie de SI .............................................................................. xxx II.3 conclusion ................................................................................................................................. xxxi Chapitre III. Système décisionnel [3], [7] [8], [12], [13] [15]............................................................ xxxii III.1 L’entreprise ............................................................................................................................ xxxii III.1.1 Définitions ........................................................................................................................... xxxii III.1.2 Problématiques .................................................................................................................... xxxii III.2 Notion du décideur [3], [7] [8], [12], [15] .............................................................................. xxxii III.2.1 Le décideur et son rôle ....................................................................................................... xxxii III.2.2 le besoin du décideur ........................................................................................................... xxxii III.2.3 la décision........................................................................................................................... xxxiii III.2.4 les processus de la prise de décision................................................................................... xxxiii III.3 le système décisionnel [3], [7] [8], [12], [13] [15] ................................................................ xxxiv III.3.1 introduction ........................................................................................................................ xxxiv III.3.2 Définitions de quelque concept [3], [7] [8], [12], [13] [15] ................................................ xxxv III.3.3 Problématique..................................................................................................................... xxxvi III.3.3.1 Pourquoi le décisionnel ?................................................................................................. xxxvi III.3.3.2 Qui a besoin du décisionnel ? .......................................................................................... xxxvi III.3.4 Fonction et architecture d’un système décisionnel [7] [8], [12], [13] [15].........................xxxvii III.3.4.1 Les fonctions d’un système décisionnel ..........................................................................xxxvii III.3.4.2 l’architecture d’un système décisionnel .........................................................................xxxviii III.3.5 Les apports des systèmes décisionnels .....................................................................................xl III.3.6 Les caractéristiques des systèmes décisionnels ........................................................................xl III.4 Quelques outils de prise de décision ..........................................................................................xli III.4.1 Data warehouse (Entrepôt de données) ...................................................................................xli III.4.1.1 Définitions ............................................................................................................................xli III.4.1.2 Architecture de Data warehouse (l’entrepôt de données)................................................... xliii III.4.1.3 Les techniques de réalisation d’un data warehouse (l’entrepôt de données) ....................... xlv
A. La technique Top-Down........................................................................................................ xlv B. La technique Bottom-up ........................................................................................................ xlv C. La technique Middle-out ou technique hybride.................................................................... xlvi
III.4.1.4 les concepts OLTP et OLAP .............................................................................................. xlvi
III.4.1.4.1 OLTP ............................................................................................................................. xlviii A. Définition : ......................................................................................................................... xlviii B. Caractéristiques .................................................................................................................. xlviii
III.4.1.4.2 OLAP............................................................................................................................... xlix a. Définition.............................................................................................................................. xlix b. caractéristiques ......................................................................................................................... l
III.4.1.4.3 Comparaison entre le Système OLAP et OLTP .................................................................. l
III.4.2 Data marts (magasins de données) [3], [7] [8], [12], [13] .......................................................liii III.4.2.1 Définitions ............................................................................................................................liii III.4.2.2 pourquoi créer un data marts ? .............................................................................................liii III.4.2.3. les outils d’alimentation d’un data warehouse ....................................................................liv (1) Extraction des données : .........................................................................................................liv (2) La transformation des données : ...................................................................................................liv (3) Le chargement des données : .........................................................................................................lv III.4.2.4 La modélisation multidimensionnelle ...................................................................................lv III.4.2.5 Les type des modélisations multidimensionnelles................................................................lvi a. Le schéma en étoile ................................................................................................................lvi
b. Le schéma en constellation.................................................................................................... lvii
c. Le schéma en flocon .............................................................................................................. lvii III.4.3 data mining (La fouille de donnée) ....................................................................................... lviii III .4 .3.1 définitions ......................................................................................................................... lviii III.4.3.2 objectifs .............................................................................................................................. lviii III.4.3.3 Les méthodes du data mining ............................................................................................. lviii III.4.3.3.1 analyse descriptive (par classification)...............................................................................lx III.4.3.3.2 Analyse prédictive (par réseaux de neurones) ....................................................................lx III.4.3.4 Les techniques du Data mining .............................................................................................lx III.5 conclusion.................................................................................................................................. lxii
Chapitre IV. APPLICATION ............................................................................................................... lxiii IV.1 Présentation de l’entreprise ...................................................................................................... lxiii IV.1.1 Historique de L’office congolais de contrôle ........................................................................ lxiii IV.1.2 Situation géographique.......................................................................................................... lxiii IV.1.3 Nature juridique .................................................................................................................... lxiii IV.1.4 Mission .................................................................................................................................. lxiii IV.1.5 vision ..................................................................................................................................... lxiv IV .1.6 structure organique et fonctionnement de l’OCC................................................................. lxiv IV.1.6.1 structure organique ............................................................................................................. lxiv
1. Le conseil d’administration .................................................................................................. lxiv
2. Le comite de gestion.............................................................................................................. lxv
3. Les départements centraux .................................................................................................... lxv A. Département de gestion ......................................................................................................... lxv B. Département d’exploitation ................................................................................................... lxv
1. Les directions provinciales ................................................................................................... lxvi
2. Les agences........................................................................................................................... lxvi IV.1.6.2 fonctionnement................................................................................................................... lxvi I. Contrôle des exportations ..................................................................................................... lxvi
II. Contrôle des importations..................................................................................................... lxvi
III. Le contrôle de la production industrielle locale .............................................................. lxvii IV. Contrôles techniques ....................................................................................................... lxvii V. Commissariat d'avarie ......................................................................................................... lxvii
IV.1.7organigramme de l’occ......................................................................................................... lxviii IV.2 Démarche d’urbanisation ....................................................................................................... lxviii IV.2.1 Modélisation de la stratégie................................................................................................... lxix IV.2.2 Analyse et cartographie de système existant ......................................................................... lxix IV.2.2.1 Modélisation et cartographie de l’architecture métiers ...................................................... lxix
1. Le processus de pilotage........................................................................................................ lxx
2. Le processus opérationnel ou de réalisation .......................................................................... lxx
3. Le processus de support........................................................................................................ lxxi IV.2.2.2 Cartographie de l’architecture métiers de l’OCC ............................................................... lxxi IV.2.2.3 Cartographie de l’architecture fonctionnelle .................................................................... lxxiii IV.2.2.3.1 Découpage du système d’information ........................................................................... lxxiii IV.2.2.3.2 cartographie de l’architecture fonctionnelle de l’OCC ................................................ lxxvii IV.2.2.4 Diagnostic de l’analyse et scenario de mise en œuvre ................................................... lxxviii IV.2.2.4.1 Critique de l’existant ................................................................................................... lxxviii IV.2.2.4.2 Proposition des solutions............................................................................................. lxxviii IV.2.2.4.3 Choix de la meilleure solution ...................................................................................... lxxix IV.2.2.5 Description du SI cible ..................................................................................................... lxxix IV.2.2.5.1 Cartographie fonctionnelle cible .................................................................................... lxxx IV.2.2.5.2 Cartographie du système d’information ........................................................................ lxxxi IV.2.2.5.3 Flux d’information circulant entre divers processus .................................................... lxxxii IV.2.2.5.4 Détermination de la trajectoire à suivre .......................................................................lxxxiii IV.2.2.6 Développement de l’application......................................................................................lxxxiv
IV.2.2.6.1 Etude préalable sur la gestion constatation des avaries et de la rédaction du certificat des avaries............................................................................................................................................lxxxiv
I. La constatation des avaries ................................................................................................lxxxiv II. Le certificat d’avaries ........................................................................................................ lxxxv IV.2.2.6.2 La conception de la base de données transactionnelle .............................................lxxxvi IV.2.2.6.2 .1 Modélisation par approche merise .......................................................................lxxxvi IV.2.2.6.2 .1.1 Modélisation conceptuel de données..................................................................... xci IV.2.2.6.2 .1.2 Modélisation logique de données ......................................................................... xcii IV.2.2.6.2 .2 Modélisation par approche uml ............................................................................... xcii IV.2.2.6.2 .2.1 diagramme de cas d’utilisations ........................................................................... xcii IV.2.2.6.2 .2.2 diagramme de classe............................................................................................ xciii IV.2.2.6.2 .2.3 diagramme des séquences ................................................................................... xciv IV.2.2.6.2 .2.4 diagramme d’activités ......................................................................................... xciv IV.2.2.6.2.2.5 Présentation de la base de données........................................................................ xcv IV.2.2.6.2.2.6 Construction de l’entrepôt de donnée.................................................................... xcv IV.2.2.6.2.3 Construction de l’entrepôt de donnée.................................................................... xcvii IV.2.2.6.2.3.1 Déploiement de l’entrepôt de donnée................................................................... xcix IV.2.2.6.2.3.2 La Restitution de données .................................................................................... xcix IV.2.2.6.3.3 Quelques interfaces utilisateurs et codes sources ........................................................ci IV.2.2.6.3.4 Conclusion................................................................................................................. ciii CONCLUSION ET PERSPECTIVE .................................................................................................... civ REFERENCE ET BIBLIOGRAPHIE.................................................................................................... cv
0. OUVRAGES.............................................................................................................................. cv
i. NOTES DES COURS.................................................................................................................. cv ii. MEMOIRES ET THESES ............................................................................................................ cv iii. WEBOGRAPHIE ....................................................................................................................... cv
