Problématique
La stratégie de l’entreprise évolue sans cesse, ce qui nécessite de mettre en place rapidement de nouvelles fonctionnalités pour répondre aux modifications de l’activité. Ces changements ne peuvent être atteints sans rapprochement des différents points de vue du système d’information par alignement, parce qu’on doit mesurer les conséquences des décisions avant d’agir. L’alignement pose et traite la question fondamentale de la cohérence des informations situées à différents niveaux d’abstraction. Une fois l’alignement effectué, son analyse permet d’identifier les actions d’évolution à réaliser. Les échanges nécessitant toujours d’être de plus en plus rapides et d’être capables de transmettre des volumes d’informations de plus en plus importants, la maîtrise des points de vue du SI répond par conséquent à l’amélioration de l’efficacité et des performances du SI.
Nous détaillons les besoins de développement du SI et les motivations pour réaliser l’alignement.
Répondre à des besoins d’évolution du SI
L’évolution de l’entreprise est permanente que ce soit pour s’améliorer en faisant des choix stratégiques internes (nouveau produit, baisse de coût…), ou pour répondre à des contraintes multiples venant de l’extérieur (concurrence, inflation législative…).
Nous détaillons quelques-uns des facteurs nécessitant un besoin d’évolution du SI de l’entreprise.
Le facteur concurrentiel (figure 1.1) est lié à la mondialisation et au progrès technologique qui ont entraîné la libéralisation de la nouvelle économie, des monopoles et l’ouverture des marchés nationaux vers l’international. Ces changements entraînent une nouvelle concurrence sur les marchés traditionnels. Par exemple, l’ouverture en France entre 2000 et 2007 des fournisseurs d’énergie (gaz et électricité) à la concurrence
a aboli les monopoles d’État de EDF et GDF. EDF a dû s’adapter et faire évoluer l’activité de son SI pour proposer des contrats correspondants à la fois aux tarifs réglementés historiques et à la nouvelle offre de marché.
Aligner les points de vue du SI
Pour avoir une meilleure compréhension du système d’information par les différents acteurs, nous souhaitons réaliser une cartographie des différents points de vue qui le composent. Puis, nous souhaitons rendre cohérents les différents points de vue à l’aide de l’alignement. Cet alignement va permettre à l’architecte d’obtenir de nouveaux indicateurs pour décider de la maintenance et des évolutions à appliquer.
Modéliser
Centraliser les documents et connaissances du système d’information est un problème essentiel de l’alignement du SI qui peut être résolu par l’utilisation d’un référentiel. Le référentiel a pour but d’obtenir et de maintenir une image complète du SI avec les différents points de vue métiers et informatique (figure 1.5). Ainsi, le référentiel permet de connecter les différents supports décrivant l’activité de l’entreprise (PDF, document, présentation, tableur) ainsi que les modèles et patrons de conception (données, objets, comportements) des logiciels. Le principal défi du référentiel est de le maintenir à jour à chaque évolution du SI.
La cartographie vise à modéliser les différents points de vue hétérogènes de l’entreprise. Il est nécessaire de définir les concepts (traitements et données) de chaque point de vue pour définir un langage adapté aux informations à modéliser. Un langage unifié permet de résoudre la communication entre les différents acteurs et parties prenantes de chaque point de vue (figure 1.6) : décideurs, architectes, développeurs, analystes métier, etc.
L’alignement entre les points de vue permet d’établir une traçabilité entre les concepts et de vérifier la cohérence du SI : par exemple les applications répondent aux différentes fonctionnalités organisationnelles. À partir de l’alignement, la navigation ascendante et descendante (figure 1.7) permet de représenter et confronter les différents points de vue du SI. Le SI n’est plus une collection de différents points de vue sans relation, mais devient un ensemble logique, structuré et cohérent.
La gouvernance des SI
L’élaboration de normes de contrôle des entreprises a débuté dès les années 2000 suite aux scandales financiers Enron, Worldcom, Madoff… Le Congrès américain promulgue alors la loi Sarbanes-Oxley [31], illustrée par l’exemple 2.1 définissant des normes de comptabilité et mesures de contrôle. La mondialisation de la finance et des industries entraîne les autres continents à prendre des mesures similaires : la France en 2003 avec la loi de sécurité financière LSF [46] et plus largement l’accord européen BALE II en 2004. Ces lois édictent les principes de transparence [49] suivants : une responsabilité accrue des dirigeants, un renforcement du contrôle interne et une réduction des sources de conflits d’intérêts. Ces nouvelles préoccupations ont impacté les entreprises sur le contrôle de leur SI, pour en assurer une plus grande maîtrise.
ITIL
Information Technologiy Infrastructure Library (ITIL), ou Bibliothèque pour l’infrastructure des technologies de l’information est un référentiel ouvert et public de bonnes pratiques visant à améliorer la fourniture de services informatiques d’une entreprise. L’Office of Gouvernment Commerce (OGC), ou le bureau du commerce du gouvernement est un cabinet du gouvernement britannique à l’origine d’ITIL en 1988. Le but est d’améliorer le service public et l’utilisation de l’argent du contribuable. Depuis la version 3 de 2007, des experts de grandes entreprises interviennent : EY, HP, CGI… c’est à partir de cette version que sont traitées la gouvernance des SI et l’alignement stratégique (cf. section 2.4.3) du SI sur les processus métier. A l’origine une norme européenne, ITIL s’est ensuite implantée début 2000 sur le marché nord-américain. Désormais présente au niveau mondial, elle est devenue incontournable par la promotion du réseau itSMF. Les thématiques de ITIL v3 sont : Stratégie des services, Conception des services, Transition des services, Exploitation des services, et Amélioration continue des services. Le client est au cœur de l’approche ITIL, l’implémentation commence fréquemment par la gestion du référentiel de configuration , la gestion des changements, et la gestion des incidents et problèmes.
CobiT
Control Objectives for information and technology (CobiT), ou Objectifs de contrôle de l’Information et des Technologies Associées, est un cadre de référence pour assurer la maîtrise de la gouvernance du SI dans la durée par la certification d’une personne physique [91]. L’Information Systems Audit and Control Association (ISACA) a développé CobiT à partir de 1994 comme référence pour l’audit des SI, le cadre est représenté en France depuis 1967 par l’association française de l’audit et du conseil informatique (AFAI). La formation est destinée aux directeurs des SI, consultants, formateurs et experts en sécurité. Issue des bonnes pratiques des experts mondiaux, CobiT vise à contrôler la gouvernance plutôt que son exécution. Ainsi CobiT aide à optimiser et évaluer les risques liés aux investissements informatiques ; contrôler la sécurité des services informatiques internes ou sous-traités ; assurer la fourniture de services et leur bon fonctionnement.
Il existe plusieurs versions de CobiT ; elles sont complémentaires. CobiT 4.1 traite les thèmes suivants : Planification et Organisation ; Acquisition et Installation ; Livraison et Support ; Monitoring. Tandis que CobiT 5 aborde les sujets suivants : Évaluer, diriger, et surveiller ; Aligner, planifier et organiser ; Bâtir, acquérir, et implanter ; Livrer, servir et soutenir ; Surveiller, évaluer et mesurer. Une des préoccupations de CobiT (également une des notre) est de contribuer à l’alignement des technologies sur la stratégie d’entreprise. Cet alignement s’occupe spécifiquement des budgets d’investissement et de fonctionnement pour que la valeur ajoutée de l’informatique soit conforme au métier de l’entreprise.
Différents cadres d’architecture d’entreprise
L’historique de la section 2.3.1 nous a permis de constater que différents courants de cadre d’architecture ont émergé et évolué. L’étude des principales démarches dans les sections suivantes va nous permettre une meilleure compréhension des objectifs et des étapes d’exécution d’un cadre d’architecture. Zachmann : le cadre précurseur John Zachman propose dans son framework (Zachman Framework for Enterprise Architecture – ZFEA) une représentation de l’architecture d’entreprise organisée sous forme matricielle (cf. figure 2.8) avec en ligne les différents points de vue et les acteurs responsables, puis en colonne les différents concepts répondant aux questions circonstancielles : Quoi? Comment ? Où ? Qui? Quand ? Pourquoi? [74]. La genèse de cette approche par questions remonte à la méthode Five W’s utilisée dans le journalisme américain, un article de journal doit systématiquement répondre aux questions : Who, What, Where, When, Why ? Le choix d’ajouter How par Zachman est une influence de la méthode BSP créée par son professeur Duane Dewey Walker qui fait la distinction entre how (le processus), who (l’organisation) et what (la donnée) [53]. En effet une organisation peut être modifiée sans impact sur les processus, de plus les données peuvent avoir des sens différents selon leur utilisation. En français la variante QQOQCCP (Qui? Quoi? Où ?
Quand ? Comment ? Combien ? Pourquoi?) est utilisée comme méthode empirique en sciences de l’information et de la communication : benchmarking, roue de Demming,analyse qualité TQM, méthodes agiles…
BPM : le point de vue des processus métier
Les points de vue métier sont déclinés en deux représentations (cf. figure 3.1) : description des activités en processus et classification en domaines fonctionnels. Nous allons définir le point de vue processus métier dans cette section, puis le point de vue fonctionnel dans la section suivante 3.2.
Les processus métiers sont tout d’abord illustrés par des exemples. Puis, nous dressons une description des différents concepts dans un tableau qui permet de présenter le méta-modèle que nous avons appelé BPM. Notre méta-modèle a pour but de faire une synthèse des concepts primordiaux pour modéliser des processus métier. Notre définition constitue une référence unifiée, ou commune. Nous ferons un comparatif pour dresser la compatibilité avec les concepts des normes les plus couramment rencontrées.
Introduction
Le point de vue processus reflète l’organisation des activités d’une entreprise privée ou d’une administration publique sous forme de processus. Le cycle de vie des activités du SI (création, modification, suppression) dépend d’une part des décisions stratégiques et d’autre part de l’évolution du savoir-faire de l’entreprise. L’entreprise répond stratégiquement à une demande des clients de son secteur économique, pour vendre des services ou des produits. L’offre se conforme à des normes ou standards de qualité, et des lois provenant des états ou des unions économiques internationales.
Les activités sont réalisées par des acteurs qui peuvent être des personnes : clients, législateurs, personnel de l’entreprise, sous-traitants, fournisseurs, distributeurs, etc.; ou bien des machines ou systèmes informatiques. Ces acteurs jouent un rôle interne
ou externe à l’entreprise et peuvent se décliner selon la précision que l’on applique aux processus à modéliser.
|
Table des matières
Préambule
1 Introduction
Introduction
1.1 Problématique
1.1.1 Répondre à des besoins d’évolution du SI
1.1.2 Aligner les points de vue du SI
1.2 Méthodologie
1.3 Synthèse de la démarche et des résultats de la thèse
1.4 Plan de la thèse
2 État de l’art
Introduction
2.1 Le système d’information
2.1.1 Propriétés du SI
2.1.2 Cartographie du SI
2.1.3 Problème de la maîtrise des évolutions du SI
2.2 La gouvernance des SI
2.2.1 ITIL
2.2.2 CobiT
2.2.3 ISO 38500
2.2.4 CMMI
2.2.5 PMBOK
2.2.6 ISO 27000
2.2.7 Bilan
2.3 L’architecture d’entreprise et urbanisation
2.3.1 Historique
2.3.2 Urbanisation : la métaphore de la cité
2.3.3 Différents cadres d’architecture d’entreprise
2.3.4 Cadre commun d’urbanisation, l’essentiel
2.3.5 Comparaison des approches
2.4 L’alignement du SI
2.4.1 Alignement spatial
2.4.2 Alignement temporel
2.4.3 Alignement stratégique
2.4.4 Méthodes d’alignement mixte
2.4.5 Bilan
2.5 Le positionnement de la thèse
3 Cartographie du SI : les points de vue et méta-modèles associés
Introduction
3.1 BPM : le point de vue des processus métier
3.1.1 Introduction
3.1.2 Exemples
3.1.3 Définition du méta-modèle
3.1.4 Comparaison
3.1.5 Expérimentations
3.1.6 Bilan
3.2 Fun : le point de vue fonctionnel
3.2.1 Introduction
3.2.2 Exemples
3.2.3 Définition du méta-modèle
3.2.4 Comparaison
3.2.5 Expérimentations
3.2.6 Bilan
3.3 App : le point de vue applicatif
3.3.1 Introduction
3.3.2 Exemples
3.3.3 Définition du méta-modèle
3.3.4 Comparaison
3.3.5 Expérimentations
3.3.6 Bilan
Conclusion
4 Alignement du SI
Introduction
4.1 Une définition de l’alignement par les méta-modèles
4.1.1 Liens des concepts de traitements
4.1.2 Liens des concepts de données
4.1.3 Autre définition de l’alignement
4.1.4 Définition de l’alignement adaptable et extensible
4.1.5 Résumé
4.2 L’alignement par composition des modèles
4.2.1 Fusion de méta-modèle
4.2.2 Extension de méta-modèle
4.2.3 Annotations
4.2.4 Tissage de modèles
4.2.5 Facettes
4.2.6 Comparaison des différentes techniques de composition de modèles
4.3 Une implémentation de l’alignement à l’aide de facettes
4.3.1 Présentation du projet Eclipse EMF Facet
4.3.2 Contribution au projet Eclipse EMF Facet
4.3.3 Implémentation de la définition d’alignement avec Facet
4.3.4 Atelier de tissage
4.3.5 Exploitation de l’alignement à l’aide de requêtes
Conclusion
5 Proposition d’un processus global d’alignement et expérimentations
Introduction
5.1 L’ingénierie des modèles
5.2 La présentation des études de cas d’entreprises
5.3 Le processus proposé et ses outils
5.3.1 Étape d’abstraction pour obtenir un modèle applicatif
5.3.2 Étape de concrétisation des modèles du SI
5.3.3 Étape d’alignement par tissage
5.4 Le bilan des expérimentations
5.5 Le bilan du processus d’IDM
5.6 Le bilan des outils supports du processus
5.7 Des travaux connexes d’architecture d’entreprise exploitant l’IDM
Conclusion
6 Assister l’évolution du SI par le résultat de l’alignement
Introduction
6.1 Les éléments des modèles pour le calcul des indicateurs d’alignement
6.1.1 Typologie des éléments
6.1.2 Identification des éléments non alignables
6.2 Le tableau de bord de l’alignement
6.2.1 Maquette
6.2.2 Variante des indicateurs en fonction du temps
6.3 Une analyse de l’alignement par requêtes OCL
6.3.1 Nombre d’éléments de l’alignement
6.3.2 Taux d’alignement
6.3.3 Liste des éléments non alignés
6.3.4 Incohérence d’alignement entre liens de traitement et donnée
6.3.5 Couplage
6.4 La visualisation des dépendances
6.4.1 DSM : matrice de dépendances
6.4.2 Algorithme de clustering : MCL
6.4.3 Conception d’un éditeur de matrice interactif
6.4.4 Matrice multi-domaines
6.5 Une interprétation des indicateurs pour l’aide à la décision
Conclusion
7 Conclusion
7.1 Bilan
7.2 Contributions
7.2.1 Publications
7.2.2 Prototypes développés
7.3 Perspectives
7.3.1 Perspectives scientifiques
7.3.2 Perspectives industrielles
Bibliographie
Liste des tableaux
Liste des figures
Liste des définitions
Liste des exemples
Liste des expérimentations