Un état de l’art sur l’intégration de Dynamics AX 

Le contexte de la mission

L’objectif de cette première partie est d’expliquer le contexte dans lequel j’ai réalisé ma mission de fin d’études pour le diplôme d’ingénieur CNAM. En effet, il est tout d’abord important de comprendre les raisons du choix du sujet sur l’ERP Microsoft Dynamics AX dans le secteur public et les conditions dans lesquelles j’ai réalisé ce travail.
Pour cela, je vais ainsi commencer par présenter l’entreprise Gfi Informatique dans laquelle je travaille depuis maintenant six ans. Après cette présentation générale et un historique du groupe, je ciblerai ensuite un des secteurs importants pour la société : le secteur public.
Dans un second temps, je m’intéresserai sur les raisons qui ont poussées Gfi à vouloir investir dans l’intégration d’ERP dans le secteur public. Je présenterai ainsi le contexte national, l’offre proposée par la société (le vertical Gfi-SSP) et, pour terminer, l’équipe Software SSP (Solutions Secteur Public) chargée des projets de ce produit.
Enfin, dans un dernier point, je m’arrêterai sur le choix de l’ERP Microsoft Dynamics AX par l’entreprise pour bâtir sa solution. Après avoir défini le concept d’ERP, je ferai par conséquent une introduction sur la gamme Dynamics et je finirai par montrer le positionnement de Dynamics AX sur le marché.

L’entreprise Gfi

Ma mission s’est déroulée dans l’entreprise Gfi Informatique. En premier lieu, je vais donc commencer par une présentation générale et un bref historique de la société.

Présentation et historique de la société Gfi 1.1

Né il y a maintenant plus de quarante ans, le groupe Gfi s’est constitué au fil du temps en acquérant notamment de multiples entités.

Présentation générale du groupe

Gfi est une ESN (Entreprise de Services du Numérique) française qui compte près de 10 000 collaborateurs dans le monde. Elle est implantée dans toute la France avec plus de 40 agences. A l’international, elle compte des filiales en Europe (Belgique, Luxembourg, Suisse, Espagne, Portugal) et au Maroc.
Gfi se définit « comme un acteur européen de référence des services informatiques à valeur ajoutée et des logiciels occupant un positionnement stratégique entre les opérateurs de taille mondiale et les acteurs de niche ». Elle a choisi de développer sa stratégie autour de six secteurs dont voici des exemples de clients :
 Banque Assurance : BNP Paribas, Société Générale, Caja de Madrid,… ;
 Secteur Public : ministères, établissements publics, régions, départements,… ;
 Telecom et Média : Orange, Telefonica, Radio-France,… ;
 Transport-Services : SNCF, RATP, Air France,… ;
 Industry-Retail : La Poste, Eurocontrol,… ;
 Utilities-Energy-Chemicals : EDF, GDF-Suez, Total, Areva,…. .
Après cette rapide présentation générale, je vais maintenant donner quelques dates clés qui ont construit le groupe.

Gfi et l’intégration ERP dans le secteur public

Gfi est depuis longtemps considéré comme un grand intégrateur ERP sur le marché français (Tomas, 2007). En effet, l’entreprise a d’abord commencé à intégrer des solutions SAP, Oracle et Sage. En 2012, c’est autour des produits ERP Microsoft et depuis 2014, suite au rachat des activités d’iORGA Group, Gfi devient leader en France de l’intégration des solutions Oracle-JDE. Aujourd’hui, tous les secteurs sont concernés par cette intégration d’ERP et notamment le secteur public.

Le vertical Gfi-SSP 2.1

Aujourd’hui, Gfi réalise 20% de son chiffre d’affaires dans les solutions et services pour le secteur public. Le Pôle Finances de la branche Software compte 150 collaborateurs spécialisés. 650 établissements publics et plus de 1000 collectivités territoriales utilisent les offres de ce pôle.
Fort de cet avantage, la société est ainsi devenue Microsoft Gold Certified Partner. En juillet 2009, Gfi a effectivement fait le choix d’utiliser l’ERP Microsoft Dynamics AX comme socle de renouvellement de certaines gammes de ses produits édités. En intégrant à Dynamics AX son vertical Secteur Public, Gfi offre alors sa longue expérience dans l’édition de solutions de gestion financière pour le secteur public.
Développée au cœur de l’ERP Microsoft Dynamics AX, la solution Gfi-SSP présente toute la convivialité, la performance, la flexibilité et l’évolutivité dont les acteurs financiers du secteur public peuvent avoir besoin.

L’ERP Microsoft Dynamics AX

Dans ce troisième point, il s’agit par conséquent d’aborder le concept d’ERP en apportant une définition. Puis, dans un second temps, présenter la gamme ERP de Microsoft Dynamics et son positionnement sur le marché mondial et national.

Concept d’ERP ou PGI 3.1

Conçu par un éditeur unique, l’ERP est une solution logicielle temps réelle adaptable composée de plusieurs modules interconnectés couvrant la plupart des fonctions-clés de l’entreprise. L’ERP est fondé sur l’utilisation d’une base de données relationnelle (un référentiel) alimentée et gérée par des modules applicatifs paramétrables. Selon Jean-Louis Lequeux (2008), pour désigner une solution comme étant un ERP, elle doit répondre à au moins trois critères précis :
 Comprendre une gestion de plusieurs domaines de l’entreprise par des modules intégrés ;
 Avoir un référentiel unique de données ;
 S’adapter rapidement aux règles de fonctionnement de l’entreprise (professionnelles, légales,…).
D’origine américaine, la notion d’ERP est apparu au début des années quatre-vingtdix. Elle est de fait une généralisation de MPR (Manufacturing Resource Planning) prenant en charge toute la gestion de l’entreprise (ressources humaines, gestion comptable et financière, administration, production, logistique, ventes et achats,…). Le nom de ERP s’est imposé ensuite par rapport à d’autre, comme en France avec PGI (Progiciel de Gestion Intégré) moins « vendeur » selon Deixonne (2006).
Restés confinés jusqu’au début des années deux-mille aux grandes entreprises des secteurs industriels, commerciaux et administratifs, les éditeurs d’ERP s’intéressent maintenant aux PME (Petites et Moyennes Entreprises) / PMI (Petites et Moyennes Industries) ainsi qu’aux organismes de tout secteur. Pour l’entreprise Microsoft, c’est devenu d’ailleurs le cœur de cible de sa gamme ERP Dynamics (Lequeux, 2008). En parallèle, les sociétés de service en informatique et en intégration de systèmes ont par conséquent développé des compétences dans l’intégration des progiciels du marché.
Après avoir abordé le concept d’ERP, je vais évoquer l’exemple de l’ERP Microsoft Dynamics AX choisie pour la solution Gfi-SSP.

Un état de l’art sur l’intégration de Dynamics AX

L’objectif de cette seconde partie est de réaliser un état de l’art sur l’intégration technique de Dynamics AX. Il est effectivement primordial de réaliser cette étape pour pouvoir répondre à la problématique posée en introduction.
Par conséquent, je vais donc m’intéresser au métier d’intégrateur technique ERP. Je verrai ainsi les différents rôles et compétences de ce métier, les qualités requises, ses nombreuses missions et enfin, la nécessité de travailler en mode projet pour réussir les différentes tâches qui lui incombent.
Deuxièmement, je présenterai l’architecture du produit Dynamics AX. Après une présentation de l’architecture logique de la solution, je terminerai par celle des principaux composants.
Enfin, dans un dernier point, je mettrai en évidence les grandes problématiques que soulève l’intégration de la solution Gfi-SSP chez nos clients.

Les études de cas Gfi-SSP

Dans cette dernière partie, il s’agit maintenant de confronter certaines problématiques vues dans la deuxième partie dans le contexte client. Les projets suivants ont été réalisés lors de ma mission avec toujours comme ligne directrice la volonté d’augmenter la qualité du processus d’intégration de l’ERP Dynamics AX.
Par conséquent, je vais d’abord présenter ma première mission qui a consisté à optimiser l’industrialisation des mises à jour des environnements clients. Après la brève présentation du contexte de ce projet, je détaillerai les tâches que j’ai réalisées et les résultats obtenus. Je terminerai enfin par présenter la mise en place du livrable chez le client.
Ensuite, je parlerai du projet du déploiement de la haute disponibilité (HA) dans Dynamics. J’évoquerai tout d’abord les méthodes choisies pour traiter cette problématique.
Ensuite, j’expliquerai comment j’ai réalisé une typologie HA pour Dynamics AX. Enfin, je mettrai en avant mon expérience d’une mise en œuvre de la haute disponibilité chez un client.
Pour terminer, j’aborderai la dernière mission que j’ai réalisée sur le sujet de la supervision de Dynamics AX. Après une présentation du projet, j’étudierai en détails les moyens et les solutions pour superviser cet ERP. Puis, dans un second temps, j’exposerai les résultats obtenus de la supervision d’une plateforme Dynamics AX en production.

L’industrialisation des mises à jour des environnements

Ce premier projet concerne les mises à jour des livrables Gfi-SSP et la copie des environnements Dynamics AX. Après la présentation du contexte, je déroulerai les tâches de ce projet jusqu’au déploiement dans les environnements clients.

Le contexte projet 8.1

Ce projet est né suite au nombre croissant des environnements Dynamics AX déployés chez nos clients. En effet, il existe en moyenne trois à quatre environnements par client qui sont à maintenir à jour tout au long des projets menés. Partant de ce constat, j’ai alors décidé de lister les problèmes existants dans :
 Le cycle de livraison : une mise à jour complète des livraisons Gfi-SSP a une durée assez longue (environ six heures) à cause essentiellement des étapes de compilation et de synchronisation dans Dynamics AX après l’importation des fichiers modèles.
 L’automatisation des outils : la procédure de mise à jour n’est que partiellement automatisée. Les scripts existants ne permettent pas d’enchainer les opérations automatiquement. Par conséquent, la mise à jour demande la mobilisation d’une personne pour les exécuter.
 La méthodologie : les livraisons Gfi-SSP s’exécutent à l’heure actuelle directement dans les environnements utilisés par les équipes projets. Cela pose deux difficultés :
 Tout d’abord, ce processus ne peut commencer qu’en soirée après 18h00 et donc se terminer assez tard ;
 Ensuite, cela signifie que si la mise à jour se déroule mal (erreurs de compilation ou de synchronisation), il faut alors revenir en arrière en restaurant la base de données afin de ne pas bloquer les environnements.

La nouvelle structure adoptée 8.5

Une première version (V1.0) d’un package pour la mise à jour des environnements a ainsi été réalisée à partir d’étapes successives de réflexion et de développement. En effet, j’ai d’abord pensé qu’il était plus judicieux de raisonner non plus en termes d’environnement installé chez le client mais plutôt par processus utilisés pour la mise à jour des environnements. Ce premier niveau de raisonnement permet alors de supprimer la redondance de fichiers et de montrer clairement notre maîtrise des opérations. Ensuite, il m’est apparu évident qu’il fallait séparer les scripts fonctions des scripts utilisé pour l’exécution des traitements d’une livraison. Ce second niveau permet la réutilisation des processus développé.
Un troisième niveau concerne la création de fichiers principaux qui centralise uniquement l’enchaînement des opérations. Enfin, un quatrième niveau concerne la modélisation orienté objet de ces processus. Cette dernière ouvre la perspective de réduire la complexité de l’écriture des scripts et de renforcer la vision processus. Les fichiers font désormais appels à des classes d’objets permettant de modéliser un environnement Dynamics AX.

Conception d’un fichier de configuration client

Concrètement, j’ai d’abord recherché et placé pour chaque client toutes les informations contextuelles des environnements Dynamics AX dans un fichier XML (Figure 19). Ce fichier nommé config.xml (Main\Ressources) est pour le moment généré manuellement. Il se base sur les informations récupérées à partir des bases de données en exécutant un script qui existait déjà : Export_Params.ps1.

Le nouveau découpage en processus des scripts principaux 8.6

Le nouveau découpage en processus des scripts se compose à l’heure actuelle de la copie d’environnement (Main\Process\copyenv) et de la gestion de la base modèle (Main\Process\modelmanagement). Ce sont les deux opérations que je vais abordées tout de suite.

Conception du script de copie d’environnement

La copie d’environnement est l’étape qui consiste à récupérer les données d’un environnement source vers un environnement cible. Cette opération s’exécute en lançant le fichier CopyDb_EnvSource_EnvDest.ps1 (Main\Process\copyenv\sources). A l’origine, c’est un fichier qui existait dans lequel on trouvait les variables en dur ainsi que des fonctions. En m’appuyant sur cet existant, j’ai totalement modifié sa structure en raisonnant en termes de suites d’opérations sur les composants (Figure 23).

Table des matières

Remerciements
Liste d’abréviations
Table des matières
Synthèse
Abstract
Introduction
1ère Partie : Le contexte de la mission
1. L’entreprise Gfi
Présentation et historique de la société Gfi
1.1.La branche Secteur Public
1.2.Gfi et l’intégration ERP dans le secteur public
2. Le vertical Gfi-SSP
2.1.L’équipe Software SSP
2.2.Les clients Gfi-SSP
3. L’ERP Microsoft Dynamics AX
Concept d’ERP ou PGI
3.1.Microsoft Dynamics AX
3.2. 2ème Partie : Un état de l’art sur l’intégration de Dynamics AX 
4. Un métier transverse
Les rôles et compétences du métier d’intégrateur ERP
4.1. Les charges de l’intégrateur
4.2. La méthodologie Sure Step
5. L’architecture de Dynamics AX
L’architecture logique de la solution
5.1. Les composants de la solution
5.2.La virtualisation
6. Les problématiques posées par l’intégration de Dynamics AX
6.1. Les besoins réseaux
6.2. Le mode de déploiement
6.3. Le stockage
6.4. La sécurité
6.5. La sauvegarde
6.6. La gestion des impressions
6.7. La haute disponibilité
6.8. La supervision
7. L’analyse des cas Gfi-SSP
3 ème Partie : Les études de cas Gfi-SSP
8. L’industrialisation des mises à jour des environnements
Le contexte projet
8.1. La mise en place des outils de travail
8.2. La revue de l’organisation d’une livraison
8.3. L’étude de l’organisation des scripts
8.4. La nouvelle structure adoptée
8.5. Le nouveau découpage en processus des scripts principaux
8.6. La mise en œuvre chez les clients
9. La gestion de la haute disponibilité dans Dynamics AX
Le contexte projet
9.1. La haute disponibilité par composants
9.2. Une typologie de haute disponibilité
9.3. Le déploiement chez un client en production
10. La mise en place de la supervision de Dynamics AX
Le contexte projet de la supervision
10.1. L’étude de la supervision de Dynamics A
10.2. Superviser Dynamics AX dans Centreon
10.3. La supervision de Dynamics AX en production
10.4. Conclusion
Annexes 
Bibliographie 
Table des figures 
Liste des tableaux 
Résumé 

Télécharger le rapport complet