ROYAUME DU MAROC PROJET E-RH DANS L ADMINISTRATION PUBLIQUE MAROCAINE - PREMIÈRE PHASE

Transcription

1 MMSP ROYAUME DU MAROC PROJET E-RH DANS L ADMINISTRATION PUBLIQUE MAROCAINE - PREMIÈRE PHASE Lignes directrices pour la définition des référentiels communs et du noyau commun

2 Version 1.0 Page i TABLE DES MATIÈRES 1. CONTEXTE BUT DU DOCUMENT PERIMETRE DU PROJET PERIMETRE FONCTIONNEL POPULATIONS CONCERNEES REFERENTIELS COMMUNS REFERENTIELS FONCTION PUBLIQUE Référentiel des concepts Dictionnaire des données et nomenclatures associées Évènements des gestions et règles associées Répertoire et fiches descriptives des fonctions de base DEFINITION DES REFERENTIELS COMMUNS ADMINISTRATIFS DEFINITION DES REFERENTIELS COMMUNS QUALITATIFS PROTOCOLES D'INTERCHANGE DEFINITION DES PROTOCOLES D'INTERCHANGE ADMINISTRATIFS DEFINITION DES PROTOCOLES D'INTERCHANGE QUALITATIFS NOYAU COMMUN SPECIFICATIONS FONCTIONNELLES Gestion administrative Gestion qualitative Gestion des référentiels Fonctions transverses Interfaces (Protocoles d interchange) SPECIFICATIONS TECHNIQUES Caractéristiques concernant le système SIRH a) Caractéristiques générales b) Construction de processus et workflow c) Fonction d échanges automatisés de données d) Éditions e) Traçabilité f) Ergonomie g) Documentation Outils de paramétrage et de personnalisation Contraintes du système informatique a) Généralités b) Interopérabilité c) Contraintes d'environnement Table des matières

3 Version 1.0 Page ii d) Gestion des environnements et de configuration e) Contraintes liées à l utilisation d outils f) Contraintes liées à l utilisation d une base de données g) Sécurité h) Langue RÔLES ET RESPONSABILITES ANNEXE : EXIGENCES POUR L ARCHITECTURE SOA PREAMBULE QU EST-CE QUE LE SOA SOA ET L HR DE L ADMINISTRATION PUBLIQUE DU MAROC SCHEMA GENERAL BASE SCHEMA GENERAL AVANCE SERVICES IT POUR L ARCHITECTURE SOA Table des matières

4 Version 1.0 Page iii FIGURES Figure 1 Les référentiels communs...4 Figure 2 Les référentiels communs (un exemple)...5 Figure 3 Les dossiers de la gestion administrative...7 Figure 4 Les dossiers de la gestion qualitative...8 Figure 5 Circuit des flux des informations administratives et qualitatives Figura 6 - Eléments de la SOA Figura 7 - Schéma général - Base Figura 8 - Schéma général - Avancé ACRONYMES CCED CED CGED CMR DAAG DB GIPE MEF MEN MMSP ORD PB PPR RECAP RH SDI SIRH TE TGR TIC TM Contrôle central des engagements de dépenses de l État Contrôle des engagements de dépenses de l État Contrôle général des engagements de dépenses de l État Caisse marocaine des retraites Direction des Affaires Administratives et Générales Direction du budget Gestion intégrée du personnel de l État Ministère de l économie et des finances Ministère de l éducation nationale Ministère de la modernisation du secteur publique Ordonnateurs Poste budgétaire Paierie principale des rémunérations Référentiel des Emplois et des Compétences communs aux Administrations Publiques Ressources Humaines Schéma directeur informatique Système d Information des Ressources Humaines Tableau des effectifs Trésorerie générale du Royaume Technologies de l information et de la communication Trésorerie Ministérielle Table des matières

5 Version 1.0 Page 1 1. CONTEXTE Dans le cadre de la stratégie de réforme du secteur public, le Ministère de la Modernisation des Secteurs Publics a lancé le «Projet de Gestion e-rh dans l Administration Publique Marocaine (SYGERH-BC)». La première phase de ce projet est relative à l étude de la situation existante et à la conception du nouveau système intégré et harmonisé. Le premier document rédigé (État des lieux et stratégie e-rh à court, moyen et long terme, cod. RMA-B07-XXX-0001) contient la description générale de ce nouveau système indiquant, comme étape primordiale du projet, la définition des référentiels communs et du noyau commun. Les référentiels communs doivent représenter un langage commun entre les différents partenaires du système de Gestion e-rh dans l Administration Publique Marocaine. Après la mise en oeuvre de la première version de ces référentiels, ils devront être tenus à jour, au fil des évolutions réglementaires. Ces référentiels communs sont la base de la conception d un noyau commun pour les SIRH, c'est-à-dire un ensemble de spécifications fonctionnelles et techniques, décrites dans un cahier de charges. La définition des référentiels communs et du noyau commun permettra de: Faire une économie de temps et de moyens dans la conception des nouveaux systèmes tout en tenant compte des spécificités des Départements; Harmoniser les nomenclatures utilisées par les administrations publiques de manière à permettre la remontée d informations exploitées par le futur infocentre destiné au pilotage de la politique Fonction Publique; Avoir des SIRH harmonisés, cohérents et interopérables fonctionnellement et techniquement. En cohérence avec les lignes directrices du projet, notamment l intérêt à consolider les acquis, cette étude cherchera à capitaliser ce qui existe déjà dans l administration publique marocaine, en particulier la norme GIPE. En conséquence, pour les données administratives, il serait nécessaire de procéder à une intégration progressive de la norme GIPE existante, dans un système global concerté et adaptable, alors que, pour ce qui est des données qualitatives, il serait souhaitable de tenir compte de l expérience du MFP et du Ministère de l Intérieur dans ce domaine. Dans le premier document susdit, on trouve les références de tous les partenaires du système de gestion RH de l État ainsi que les flux d informations nécessaires pour le bon fonctionnement de ce système. Contexte

6 Version 1.0 Page 2 2. BUT DU DOCUMENT Ce document a pour objectif de fournir des lignes directrices pour la définition des: Spécifications fonctionnelles pour la gestion administrative et qualitative des fonctionnaires civils de l État (référentiels communs): données, fonctions de base, interfaces et règles d échange entre les partenaires, Spécifications techniques: infrastructure, interopérabilité, confidentialité, sécurité, intégrité des données; ces termes de référence doivent tenir compte des exigences de déconcentration de la gestion du personnel. Aussi, le noyau commun ne décrit pas de processus de gestion, propres à chaque ministère; par exemple il décrit les données et la fonction de mise à jour de l'avancement de grade dans le système d information, pas le processus de l avancement avec les différentes phases pour aboutir à l avancement même. Chaque département ministériel, pourra ensuite bâtir son propre SIRH à partir de ce noyau commun selon les spécifications contenues dans son cahier des charges complémentaire (description des processus de gestion RH, modules spécifiques, nomenclatures propres, reprise des données, interfaces spécifiques, ). Ainsi, dans le cas de refonte de SIRH, l'utilisation de ce noyau commun permettra à un département ministériel à la fois de réaliser des gains de temps et d'argent sur toute la phase de description détaillée, sur le choix du produit et l'intégration de son système, et de construire un système d'information respectant les critères de cohérence et d'interopérabilité. D autre part, dans le cas de SIRH en cours de développement ou déjà en production, leurs mises à niveau avec le noyau commun garantira le respect des critères de cohérence et d'interopérabilité interministérielle et permettra aussi de réduire les coûts de maintenance. But du document

7 Version 1.0 Page 3 3. PERIMETRE DU PROJET 3.1 PERIMETRE FONCTIONNEL En se référant aux processus de Gestion des Ressources Humaines dans la Fonction Publique (cf. paragraphe 2 du document «État des lieux et stratégie e-rh à court, moyen et long terme», cod. RMA-B07-XXX-0001) les domaines fonctionnels du projet sont : la «Gestion administrative» : les fonctions de gestion et de contrôle de toutes les données administratives (recrutement et mobilité, promotions, situation familiale, postes budgétaires, ); la «Gestion qualitative» : les fonctions de gestion et de contrôle de toutes les données qualitatives (poste de travail, compétences, activités, organisation, formation,...) ; les «Protocoles d interchange» (interfaces communes pour l alimentation du contrôle et de la paye (TGR) et pour les flux de retour, pour l alimentation de la CMR, ) 3.2 POPULATIONS CONCERNEES Potentiellement tous les personnels civils de l État, au nombre de plus de fonctionnaires (source : MMSP 2006) - régis par le statut général de la Fonction Publique et les statuts des particuliers - font l objet de cette étude. Périmètre du projet

8 Version 1.0 Page 4 4. REFERENTIELS COMMUNS Les référentiels communs constituent la base des spécifications fonctionnelles du noyau. 4.1 REFERENTIELS FONCTION PUBLIQUE Les référentiels communs s appuient sur l ensemble des textes législatifs et réglementaires relatifs aux personnels de l Etat. Ces référentiels comprennent les concepts «fonction publique», la liste des données et nomenclatures associées (tables de valeur), l'ensemble des événements et règles de gestion ayant un impact sur la situation personnelle, administrative ou financière du fonctionnaire, ainsi que les caractéristiques des fonctions de base (voir schéma). Textes réglementaires Concepts Dictionnaire des données et nomenclatures Evènements de gestion Règles de gestion Fonctions de base Figure 1 Les référentiels communs Le résultat de cette activité sera la rédaction des documents suivants : le référentiel des concepts ; le dictionnaire des données et les nomenclatures associées ; le référentiel des évènements de gestion ; Référentiels communs

9 Version 1.0 Page 5 le référentiel des règles de gestion des données le répertoire et les fiches descriptives des fonctions et services attendus du noyau SIRH commun. La figure suivante décrit un exemple des référentiels communs pour l avancement de grade sur titre. Textes réglementaires: lois, statuts, dahir, arrêtés, Concepts: grade, motif de l avancement, Evènements de gestion: avancement de grade sur titre Dictionnaire des données et nomenclatures: grade (code, libellé,..) Règles de gestion: Conditions de Déclanchement: demande du fonctionnaire, existence et validité de l arrêté Contrôles/Impact: avancement suivant les modalités de classement des statuts particuliers Fonctions de base: fiche de l avancement de grade Figure 2 Les référentiels communs (un exemple) Tous les éléments du schéma doivent être mis à jour au fil des évolutions réglementaires Référentiel des concepts Le référentiel des concepts de la gestion des Ressources Humaines de la Fonction Publique est constitué d'un ensemble de fiches décrivant chacune des principaux concepts selon les rubriques suivantes : Définition : par exemple qu est-ce que c est qu un grade, ses attributs associés, les modes d accès au grade et ainsi de suite ; Références : par exemple les textes réglementaires et les statuts particuliers concernant les modes d accès au grade ; Commentaire ; Référentiels communs

10 Version 1.0 Page 6 Fiches liées : par exemple les fiche d autres concepts liés au grade tels que statut, échelon. Chaque ministère peut ajouter, à ces référentiels, ses propres concepts Dictionnaire des données et nomenclatures associées C'est un document décrivant : Les données administratives (recrutement et mobilité, promotions, situation familiale, postes budgétaires, ); Les données qualitatives (poste de travail, compétences, activités, organisation, formation, ) ; Les données nécessaires à la constitution des référentiels statutaires (nomenclatures, règles de gestion, visas, modèles d'arrêtés) et des référentiels emplois et compétences (emploi-types, compétences, activités, ) ; Les données nécessaires au "traçage" des évènements de gestion ; Les tables de valeurs possibles. Les figures suivantes illustrent des exemples pour les données à saisir dans des différents dossiers. Référentiels communs

11 Version 1.0 Page 7 Situation familiale Carrière (diplômes, expériences professionnelles, ) Affectations Identification (état civil, statut, ) Grade/Echelon Congés et absences Promotions Recrutement et mobilité Dossier personnel Dossier administratif Evaluation et Notation Fonctionnaire Poste budgétaire Prise en charge Info. Bancaires Compl. traitement Indemnités/retenues Bulletins de salaire Dossier financier Masse salariale Les dossiers de la gestion administrative Évènement de gestion Modèle d acte Figure 3 Les dossiers de la gestion administrative Référentiels communs

12 Version 1.0 Page 8 Unité Unité Unité Unité structurelle Objectif global Fonction Objectif spécifique Activité Compétence Famille d emplois Compétences formation Poste de travail Dossier poste de travail Fiche de poste de travail Emploi type Parcours professionnels Dossier formation Fonctionnaire Référentiels Dossier fonctionnaire Dossier organisation Les dossiers de la gestion qualitative Figure 4 Les dossiers de la gestion qualitative Principes de base de gestion des données : Toutes les rubriques et sous-rubriques doivent être gérées avec une date d'effet et historisées, y compris celles concernant les nomenclatures; L'état («à contrôler», «contrôlée», «validée») dans lequel passe successivement toute rubrique ou sous-rubrique créée dans la base de données doit être matérialisé dans cette dernière. Les descriptions fournies dans le dictionnaire sont de nature "logique" et non "physique" : les données "de service" nécessaires à la gestion, en particulier celles de la gestion historique et de la gestion des états des rubriques ne sont pas détaillées puisqu'elles dépendent fortement des modes de représentation et de traitement choisis. Les Ministères doivent pouvoir enrichir ce dictionnaire avec les nomenclatures, et éventuellement leurs données particulières. Référentiels communs

13 Version 1.0 Page Évènements des gestions et règles associées Le référentiel des évènements de gestion indique, pour chaque évènement : Le concept associé à l'évènement (cf. référentiel des concepts), par exemple, corps et grade ; La ou les rubrique(s) principale(s) impactée(s) (cf. dictionnaire des données et nomenclatures associées), par exemple, la carrière ; La ou les fonction(s) qui traite(nt) la ou les rubrique(s) (cf. répertoire et descriptif des fonctions), par exemple, fonctions de gestion des données administratives ; Le ou les évènement(s) qu'il est nécessaire d'enchaîner à celui-ci pour que l'acte de gestion soit complet, par exemple, le classement. Le référentiel des règles de gestion, organisé par grande famille d'évènements, doit indiquer pour chaque évènement : Les conditions de son déclenchement, par exemple, existence et validité du titre ; Les règles de contrôle de saisie des données associées, par exemple, le fonctionnaire doit être en activité ; Les règles d'impact à propager sur les autres données de la base, par exemple, nouveau classement selon les règles des statuts particuliers, nouvelle affectation. Les références aux textes réglementaires qui traitent l'évènement sont également indiqués dans le référentiel des règles le concernant. Dans le cadre de leur projet d'intégration, les Ministères vont ajouter à ces référentiels les évènements et les règles qui leur sont particuliers Répertoire et fiches descriptives des fonctions de base Le périmètre fonctionnel du noyau commun est structuré en différents domaines fonctionnels. Pour chaque fonction de chaque domaine, une fiche descriptive indique : Un rappel éventuel de la définition des concepts associés à cette fonction; L'objet de la fonction ; Les acteurs ou intervenants et leur rôle dans la mise en œuvre de la fonction ; Les événements déclencheurs de la fonction (cf. référentiel des évènements); Les rubriques de données concernées (cf. dictionnaire des données) ; Les opérations élémentaires qui doivent pouvoir être exécutées ; Référentiels communs

14 Version 1.0 Page 10 Les règles de gestion à prendre en compte sachant que, par défaut, ces règles sont celles correspondante à l'évènement précis qui a un impact sur les rubriques gérées par la fonction (cf. référentiel des règles) ; Les résultats attendus. Les fonctions doivent prendre en charge la gestion de toutes les données décrites dans le dictionnaire des données, en appliquant les règles du «référentiel des règles de gestion» qui les concernent. Un ensemble d élément à insérer dans une fiche de fonction pour l avancement de grade pourrait être : Objet de la fonction : par exemple, gestion des données concernant la situation administrative d'un agent : grade ; Acteurs/intervenants : par exemple, gestionnaire administratif RH (mise à jour), fonctionnaire (validation) Évènement déclencheur : par exemple, avancement de grade ; Rubrique : par exemple, dossier administratif du fonctionnaire ; Opérations élémentaires : par exemple, récupération des données, saisie des données, contrôles Règles de gestion : par exemple, le fonctionnaire doit être en activité ; Résultat : par exemple, dossier mis à jour, situation administrative à l écran et papier. 4.2 DEFINITION DES REFERENTIELS COMMUNS ADMINISTRATIFS Pour l élaboration des référentiels communs administratifs, il serait opportun de se baser sur la norme GIPE utilisée par tous les acteurs de la gestion RH dans l Administration. Le système GIPE est un ensemble de normes et de règles de gestion qui régissent les échanges d information entre les entités principalement concernées par le traitement des dossiers des fonctionnaires de l État : la DB, les ordonnateurs, les Trésoreries Ministérielles, la TGR et la CMR. Le système GIPE qui a été, dès le départ, conçu en fonction de l utilisation généralisée de l informatique, vise à: Unifier les concepts relatifs aux données et aux procédures concernant la gestion du personnel de l État; Normaliser les règles de gestion en adoptant pour chaque type de statut les mêmes règles quel que soit le département ou l entité concernée par l application de ces règles; Simplifier les procédures et les circuits administratifs en vue de réduire les délais de traitement des dossiers des fonctionnaires; Référentiels communs

15 Version 1.0 Page 11 Harmoniser et rapprocher les données échangées entre partenaires dans le but d aboutir à une «fiche identique» du fonctionnaire au niveau de tous les intervenants dans le processus de gestion du personnel. Les différents travaux réalisés par la Commission Interministérielle chargée de la Gestion Intégrée du personnel ont abouti à la définition des spécifications minimales à respecter, par l ensemble des acteurs qui interviennent dans le processus de gestion et de rémunération, notamment au niveau de: Modèle conceptuel des données (MCD) qui fait partie du système intégré de gestion du personnel; Mise en place d un système unifié de codification et d identification; Normalisation des concepts utilisés ; Procédures de contrôle et de rapprochement des données détenues par les différents acteurs intervenants dans le processus de rémunération; Suivi des postes budgétaires; Responsabilité de la saisie des données; Protocoles de communication entre les différents acteurs. Les travaux de la commission GIPE ont été formalisés dans 2 documents : un manuel de codification GIPE qui a concerné les informations suivantes répartis en deux catégories : Codifications définies en termes de contenant et de contenu : Grades, positions Codifications définies uniquement en termes de contenant (contenu à définir et à maintenir pour chaque ordonnateur): Affectations, Diplômes Un manuel de communication définissant la liste des enregistrements de communication entre les différents intervenants. À quelques exceptions près, l ensemble des intervenants dans le processus de gestion du personnel de l état ayant adhéré au système GIPE ont adopté le dictionnaire de données commun et le système de codification GIPE. Parallèlement, la majorité des Ordonnateurs utilisent un système informatisé, le GIPE Ordonnateur, qui a été développé par le CED pour appuyer la mise en œuvre des normes et des règles GIPE (pour sa description voir le document État des lieux et stratégie e-rh à court, moyen et long terme, cod. RMA-B07- XXX-0001). Actuellement une structure au niveau du CGED assure : La mise à jour de la norme GIPE, à travers la production de fiches de mise à jour au fil des évolutions réglementaires ayant un impact sur cette norme ; La diffusion des fiches de mise à jour à tous les intervenants. Référentiels communs

16 Version 1.0 Page 12 Face à la décision de prendre la norme GIPE comme point de départ pour la définition des référentiels communs administratifs, il faut préciser que : D une part, il faut noter que le champ d application de la norme GIPE se limite au personnel payé par la PPR et aux actes de gestion nécessitant le visa du CCED (TM dans la nouvelle structure du CCED); d autre part, il faut également noter que l évolution de certains volets de la norme GIPE n est plus assurée par une entité unique et de manière concertée. C est le cas notamment: Des actes familiaux qui, depuis qu ils ne nécessitent plus le visa du CCED, n entrent plus dans le champ d activité de l entité du CGED chargée de la maintenance de la norme GIPE ; Des types de mouvements loi-cadre et des mentions (utilisés dans la production et la transmission, entre les partenaires, des morasses budgétaire) qui sont mis à jour: o Chacun à son niveau et de même, par la Direction du Budget et par l entité du CGED chargée de la maintenance de la norme GIPE, à l occasion de l évolution du cadre réglementaire les concernant ; o Par la Direction du Budget pour répondre à des contraintes internes. Il en suit que, pour constituer les Référentiels Communs Administratifs, il est nécessaire de procéder à une intégration progressive de la norme GIPE existante dans un système global concerté et adaptable. Comme on a déjà proposé dans le document «État des lieux et stratégie e-rh à court, moyen et long terme» (cod. RMA-B07-XXX-0001), il serait opportun de constituer un groupe de travail interministériel chargé de la réception et de l évaluation des exigences et des propositions des différents Ordonnateurs et des autres entités intervenant dans la gestion RH de l État. Il serait préférable de démarrer en procédant en chemin inverse par rapport au schéma de la figure 1 «Les référentiels communs», avec une approche bottom-up. On pourrait commencer par l analyse des fonctions de base de GIPE Ordonnateur et du manuel de codification GIPE, en consultant entre autres les documents : Système de Gestion Intégrée du Personnel de l État (Documents GIPE (MFP - janvier 1996)» ; Système de Gestion des Ressources Humaines (MFP/DAAG)»), Pour ensuite : Déterminer l évènement de gestion qui fait déclencher la fonction, Extraire les règles de gestion développées, Repérer les données impliquées, Référentiels communs

17 Version 1.0 Page 13 Définir les concepts, Dresser la liste des textes réglementaires. Une fois les documents prévus sont rédigés, on pourrait d un côté, améliorer les fonctions ainsi décrites, de l'autre côté, ajouter les autres fonctions nécessaires pour que le noyau commun soit complet et répond aux exigences des ordonnateurs. Pour la conception des fonctions à ajouter, il faudrait suivre l approche décrite au paragraphe 4 «Référentiels Communs» (approche top-down). 4.3 DEFINITION DES REFERENTIELS COMMUNS QUALITATIFS Pour les référentiels communs qualitatifs il n existe aucune norme déjà utilisée et partagée, il serait intéressant d'élaborer les référentiels en suivant la méthodologie suivante, en tenant compte : Du RECAP et du guide méthodologique, réalisés par le MMSP ; Des lignes directrices pour le plan de Formation Continue, réalisés par le MMSP ; De l expérience et des fonctionnalités déjà mises en place dans des SIRH du MFP et du Ministère de l Intérieur. Référentiels communs

18 Version 1.0 Page PROTOCOLES D'INTERCHANGE Le système cible de la gestion RH, avec tous les intervenants et les flux de données prévus, est représenté dans la figure suivante : Circuit des flux des informations administratives et qualitatives des Ressources Humaines de l État DIRECTION DU BUDGET (DB) ORDONNATEUR (ORD) TRÉSORERIE GÉNÉRALE DU ROUYAME (TGR) CASSE MAROCAINE DES RETRAITES (CMR) MINISTÈRE DE LA MODERNISATION DES SECTEURS PUBLICS (MMSP) o Preparation et suivi de la loi cadre Projet de loi cadre, Projet de Erratum REC, formation, évaluation, notation, Loi cadre, Errata o Preparation du projet de loi cadre o Individualisation de la loi cadre o Gestion du personnel o Gestion des postes budgetaires Dossiers de pension Situation des émissions o Gestion de l Infocentre du personnel de l État (IPE) Actes traités (visas et rejets) Dernière situation Situation des pensions Tous les actes (visés ou non soumis au visa) o Liquidation de la pension Resultat de l individualisation, Actes necessitant le visa, Actes ne necessitant pas de visa o Suivi administratif du personnel (TM) o Suivi des postes budgetaires (TM) o Liquidation et payement agents en service Tous les actes (visés ou non soumis au visa) Loi cadre, Errata Situation des émissions Situation des postes budgetaires Situation des postes budgetaires Figure 5 Circuit des flux des informations administratives et qualitatives Pour la gestion des flux de données, détaillés dans la figure précédente, on devrait prévoir la définition des entre les différents partenaires pour préciser: Les parties concernées, leurs droits et leurs obligations ; Le contenu, le niveau de détail, la fréquence et les modes opératoires (format des fichiers, typologies des contrôles automatique sur les données, ) ; Les mécanismes de sécurité mis en œuvre (authentification, non répudiation, intégrité et confidentialité des données télétransmises) ; La responsabilité des erreurs. Protocoles d interchange

19 Version 1.0 Page DEFINITION DES PROTOCOLES D'INTERCHANGE ADMINISTRATIFS Comme pour les référentiels communs administratifs, on pourrait définir des administratifs à partir de ce qui existe, c est-à-dire, des enregistrements de communication entre les différents intervenants, visant la validation des données par le CED, dans le cadre de la norme GIPE. Ces enregistrements concernent notamment : La dernière situation administrative du fonctionnaire ; Les actes de gestion ; L individualisation des Postes Budgétaires. Le manuel pour chaque flux décrit en particulier : Les données à envoyer ; Leurs valeurs possibles ; La composition du flux, Les conditions d adhésion au système, Les éventuels flux de retour. Dans ce cas aussi, on pourrait avancer d un côté en améliorant, si nécessaire, les enregistrements existants, de l autre côté en ajoutant d autres flux, au fur et à mesure que les différents partenaires le considère utile. 5.2 DEFINITION DES PROTOCOLES D'INTERCHANGE QUALITATIFS La fonction des qualitatifs permet principalement la transmission des données qualitatives du fonctionnaire entre l Administration de provenance et celle de destination (en cas de mutation, par exemple). Donc, pour la définition de ces, le groupe de travail interministériel devra vérifier les exigences des Ministères et les formaliser en se basant sur les référentiels communs qualitatifs. Protocoles d interchange

20 Version 1.0 Page Noyau commun Ce paragraphe est consacré à l illustration synthétique des spécifications fonctionnelles et des spécifications techniques, qui doivent être décrites dans un cahier des charges pour la conception d un noyau commun pour les SIRH, afin que les logiciels des différents Ministères soient labellisés, c'est-à-dire officiellement reconnus comme respectant les prescriptions de ce cahier de charges. 6.1 SPECIFICATIONS FONCTIONNELLES Ce paragraphe présente les domaines fonctionnels du Noyau commun Gestion administrative Ces fonctions permettent : De prendre en compte tous les évènements de gestion, et de gérer automatiquement leurs impacts sur tous les éléments de chaque dossier du fonctionnaire, lors d'une saisie directe ou d'une mise à jour automatique de la base de données à l'issue d'un processus de gestion ; De visualiser, d'éditer et d'imprimer tout ou partie des éléments du dossier. Toutes les rubriques, sous rubriques et données élémentaires définies dans le dictionnaire sont concernées. Les rubriques doivent être distribuées entre différentes fonctions selon des grandes familles fonctionnelles : données personnelles, données administratives, données financières et autres données. Toutes les règles de gestion indiquées dans le «référentiel des règles pour un évènement de gestion» (conditions de déclenchement de l'évènement, contrôles de saisie des données et propagation d'impact aux autres données du dossier ou, plus généralement, de la base) doivent pouvoir être appliquées automatiquement à toutes les données impliquées Gestion qualitative Ces fonctions doivent permettre la Gestion Prévisionnelle des Emplois et des Compétences (GPEC) et la gestion de la Formation. Il s agit de concevoir des fonctionnalités pour : La gestion des emplois et des compétences ; La gestion de parcours de formation aussi bien standard qu individuel ; La détermination et la proposition de plans/programmes de développement des compétences ; La gestion des vérifications de l apprentissage et de l alimentation du système des compétences acquises; Noyau commun

21 Version 1.0 Page 17 La gestion et la consultation, avec des profils différents selon le niveau hiérarchique, des curricula professionnels (historique), du positionnement par rapport au parcours de développement d un rôle et à la famille professionnelle de référence. Le système devrait se présenter comme un véritable tableau de bord pour la: Consultation et la gestion des curricula professionnels ; Définition des compétences attendues pour chaque rôle et la vérification de celles possédées par ceux qui occupent le rôle; Certification des compétences ; Gestion intégrée du volet qualitatif (mobilité, attribution des profils professionnels, parcours de formation, sélections, évaluation, ) Gestion des référentiels Ces fonctions vont permettre de gérer les données contenues dans les référentiels : Référentiels généraux (nomenclatures des situations familiales, des communes, des nationalités, des pays, ) ; Référentiels statutaires (statuts, corps/grades, positions/situations administratives, congés, grilles d'avancement, règles de gestion, visas, modèles d'actes) ; Référentiels des emplois et des compétences de l Administration Publique (emploi-type, poste, compétence, activité, ). Un système intégré doit permettre de gérer des référentiels d'éléments formalisés sous forme de fiches (emplois-types, fiches de poste, ) Fonctions transverses Certaines fonctions doivent assurer des services transversaux : Gestion des profils et des accès aux données et aux fonctions ; Gestion de "marqueurs" permettant de repérer l'état de certaines données et gestion d'alertes ; Suivi des décisions pour assurer une traçabilité totale des actes réglementaires ; Exécution des règles de gestion codées dans les référentiels (moteur de règles) ; Gestion collective (par exemple : dans le cadre d'un acte de gestion collective) et de campagnes de gestion. Noyau commun

22 Version 1.0 Page 18 D'autres sont des outils ou des fonctions génériques prédéfinies qui permettront à l'utilisateur de décrire simplement une opération pour l'automatiser et l'intégrer rapidement dans un processus, sans programmation: Requêteur ; Édition de listes ; Saisie de masse ; Saisie de demande ; Saisie de candidature ; Saisie d'avis ou autre donnée. Enfin, d'autres sont des fonctions qui permettront à un ministère d'assembler les fonctions de base entre elles pour automatiser ses processus de gestion comme il le souhaite (outil de construction de processus et de workflow) Interfaces (Protocoles d interchange) Ces fonctions sont destinées à automatiser les échanges avec les partenaires de la gestion de RH (TM, CMR, autres ministères, MMSP) ou avec d'autres parties du système d'information (concours, formation, etc.). Le cahier des charges précis de certaines interfaces sera fourni, d'autres devront pouvoir être constituées à partir d'une fonction d'import/export générique. 6.2 SPECIFICATIONS TECHNIQUES Dans le cahier des charges à respecter pour la refonte/mise en conformité des SIRH, les spécifications fonctionnelles doivent être accompagnées d une liste de caractéristiques et exigences techniques Caractéristiques concernant le système SIRH a) Caractéristiques générales De manière générale, on pourrait proposer que l application SIRH soit capable de : Proposer une séparation des couches de présentation, des traitements métiers et des données ; Rendre le plus indépendant possible les composants logiques et physiques. Chaque couche de l application devra pouvoir être déployée sur une machine dédiée mais, si nécessaire, plusieurs composants devront être capables de partager la même infrastructure ; Permettre de dimensionner les équipements sans impact sur la configuration globale. Noyau commun

23 Version 1.0 Page 19 L architecture logicielle devrait garantir la disponibilité et la performance demandées pour le service et offrir une résistance maximale à la panne. Le matériel devrait être dimensionné afin d offrir de très bonnes performances même en cas de montée en charge «brutale» ou de période de pointe importante. La solution devrait également permettre une évolutivité rapide si le besoin est identifié, sans remettre en cause les choix fondamentaux de l architecture et des composants informatiques. b) Construction de processus et workflow Le SIRH devrait offrir des fonctions de gestion des flux des travaux de deux types : procédural : gestion des acteurs et des actions mises en œuvre par ces derniers, circulation des documents associés. Les événements et les processus devront être configurables par des utilisateurs habilités (suivant leur profil) ; événementiel : à partir d'événements et de situations paramétrés dans le système celui-ci devra être en mesure de déclencher des alertes et des actions à l'attention d'acteurs du système. c) Fonction d échanges automatisés de données Le SIRH disposera de : Moyens d'interconnexion standard et ouverts lui permettant de communiquer avec d'autres systèmes d'information (cf. paragraphe 5. «Protocoles d interchange») ; Outils d alimentation. d) Éditions Le SIRH devra permettre à l utilisateur final de : Générer des rapports et les modifier; Visualiser les éditions avant leur impression; Faire une demande d'édition immédiate ou différée et de mettre en œuvre des modules d impression locale et/ou déportée, y compris pour l impression de masse; Visualiser, à partir d outils bureautiques (formats HTML et/ou PDF), les rapports ou documents à éditer;. Noyau commun

24 Version 1.0 Page 20 e) Traçabilité Afin de tracer les différentes actions des utilisateurs et des administrateurs, le SIRH devra prévoir l enregistrement d informations telles que : Entrée en session d'un utilisateur : date, heure, identifiant de l'utilisateur et du terminal; réussite ou échec de la tentative; Actions qui tentent d'exercer des droits d'accès à un objet soumis à l'administration des droits : date; heure; identité de l'utilisateur; nom de l'objet; type de la tentative d'accès; réussite ou échec de la tentative; Création/suppression d'un objet soumis à l'administration des droits : date, heure, identifiant de l'utilisateur, nom de l'objet, type de l'action; Actions d'utilisateurs autorisés affectant la sécurité de la cible : date, heure, identité de l'utilisateur, type de l'action, nom de l'objet sur lequel porte l'action. f) Ergonomie Le SIRH est destiné à des utilisateurs non experts en matière d outils bureautiques et devra donc être d une utilisation particulièrement simple pour les utilisateurs comme pour les administrateurs. L application devra être facilement paramétrable par un administrateur ne disposant pas de qualifications techniques particulières. Cette simplicité d utilisation est une condition de succès à prendre en considération. Les utilisateurs ne doivent être contraints qu à des manipulations simples, manipuler la souris, cliquer sur des liens, remplir des formulaires. La conception des écrans et de la cinématique doit permettre aux intervenants de se repérer facilement dans les différentes étapes du processus, compte tenu de la multiplicité des informations traitées. La cohérence du graphisme et de l interactivité est un caractère commun à l ensemble de l application. L' Interface Homme Machine devra être intuitive. g) Documentation Toute la documentation sur support papier et électronique devrait être en français (et en arabe, si possible). Cette documentation devrait être accessible en ligne. Noyau commun

25 Version 1.0 Page Outils de paramétrage et de personnalisation Dans le document «e_rh État des lieux et stratégie» il a été proposé de bâtir en commun, ou d acquérir, pour un groupe de départements, un produit mutualisé conforme aux spécifications du noyau commun. Pour cette raison, on devrait prévoir un produit particulièrement flexible par rapport au paramétrage et à la personnalisation du progiciel. Le produit en question, basé sur les Référentiels communs et offert à des Ministères avec des caractéristiques différentes, devra pouvoir être aligné aisément aussi bien aux variations des Référentiels qu aux exigences particulières des Ordonnateurs. Le paramétrage et la personnalisation du progiciel devraient, donc, pouvoir s'opérer sur tout ou partie des objets qui définissent les différents modules, quelque soit la nature de ces objets (fenêtres ou écrans, champs et leurs intitulés, processus, règles de gestion, documents ou états, traitements divers sur les données, autorisations, aides en ligne, ) Contraintes du système informatique a) Généralités D une manière générale : L architecture N-tier sera l architecture de base de la solution. La base de données, le serveur métier et le serveur de présentation doivent être séparés, notamment pour pouvoir être installés dans des zones différentes ; Le système doit permettre aux fonctionnaires l accès à ses propres informations (fonctionnalités self-service) ; L infrastructure générale du SIRH possède différents niveaux d intégration de ses composants (niveau de données, niveau des fonctions de base, niveau de processus, niveau d applications). b) Interopérabilité L architecture du SIRH devrait permettre la communication d applications hétérogènes, indépendamment de la technologie et des contraintes. En particulier, au cas où dans le contexte de la réforme du secteur public, on opterait pour une architecture SOA (Service Oriented Architecture) plus ou moins complexe, le SIRH devrait déployer les services nécessaires pour adhérer au système. Le document «Exigences pour l Architecture SOA», joint en Annexe, donne une définition d une SOA et une description des éléments qui la composent. c) Contraintes d'environnement Le produit final devra respecter les contraintes suivantes : Noyau commun

26 Version 1.0 Page 22 Portabilité : il devrait pouvoir fonctionner sur différents systèmes d exploitation (Unix, Linux, Windows) ; Distribution des données : il devrait permettre la distribution sur plusieurs bases de données ; Imports/exports: il devrait permettre les échanges bidirectionnels. d) Gestion des environnements et de configuration Le produit final devra disposer d outils intégrés permettant de faciliter les opérations de gestion des environnements et de configuration : Gérer les différentes versions d un même composant (ou d un groupe de composants) ; Choisir les versions homogènes nécessaires au bon fonctionnement d un environnement ; Superviser et administrer les différents modules livrés. e) Contraintes liées à l utilisation d outils La solution devra être compatible avec les outils utilisés par les Ministères. f) Contraintes liées à l utilisation d une base de données La solution devra être compatible avec les principales bases de données présentes sur le marché (Oracle, SQL Server, ). g) Sécurité La sécurité du système d'information est un aspect important du projet. La couverture des objectifs de sécurité, décrits ci-dessous, devrait être garantie dans le produit final. Habilitations Le système d habilitation des utilisateurs devrait prévoir plusieurs profils selon les différents droits d accès aux services et aux données. Le cloisonnement des traitements impose aux utilisateurs des accès différenciés au système d'information en fonction de leur droit. Confidentialité des données La confidentialité des données justifie un certain degré de sécurité : le chiffrement devra être possible pour tous les protocoles utilisés pour la transmission de données sensibles. Intégrité des données Noyau commun

27 Version 1.0 Page 23 La base de données du futur système d'information sera l'unique source d'information des gestionnaires RH et se doit d'être totalement fiable. Il serait souhaitable que les sessions soient journalisées et que les détails des informations à tracer et des modalités de mise en œuvre de cette journalisation, soient bien précisés. (Des fonctionnalités de traçabilité des opérations seront implémentées ainsi que des mécanismes "d'accounting" - notion de journaux de connexions). Le produit doit disposer d un outil pour vérifier l intégrité des données de la base le cas échéant et d un outil de roll-back en cas de coupure de session. Non répudiation des données Afin de garantir l'intégrité et la non répudiation des documents originaux, le système devrait être compatible avec les dispositifs de la signature électronique. Authentification L'accès à l'application réclame une authentification forte. La solution devrait intégrer le système d authentification unique (Single Sign On). La solution devrait intégrer le traçage de toutes les opérations effectuées (nature de l'opération, utilisateur, valeur de la donnée, date et heure). Les utilisateurs peuvent appartenir à des structures délocalisées temporairement ou pour de plus longues périodes (ex. étranger) et résidant dans des lieux distincts de leur organisme d'administration. Dans ce cas de figure, la solution devra offrir la possibilité d un travail en mode déconnecté. h) Langue Le produit final devrait prendre en charge des données en arabe et présenter des interfaces bilingues. Noyau commun

28 Version 1.0 Page RÔLES ET RESPONSABILITES Comme proposé dans le document «État des lieux et stratégie e-rh à court, moyen et long terme» (cod. RMA-B07-XXX-0001) Il faudrait créer un groupe de travail interministériel, avec des compétences aussi bien administratives que techniques. Il sera chargé de la réalisation des Référentiels Communs et des Protocoles d Interchange et de leurs mises à jour. Il devrait notamment suivre le chantier de préparation des référentiels communs et du noyau commun, en garantissant l accueil et l évaluation des exigences des différents Ministères. Rôles et responsabilités

29 Version 1.0 Page ANNEXE : EXIGENCES POUR L ARCHITECTURE SOA 8.1 PREAMBULE La naturelle évolution des systèmes informatifs, dans le domaine du développement des Administrations Publiques centrales et locales, étant le résultat de la croissance des exigences et de la demande de plus en plus évoluée et intégrée des services informatiques, est depuis toujours un grand problème pour ceux qui se trouvent dans la nécessité de garantir un service IT efficient. Très souvent, les diversités d approche dans le développement des différentes composantes du système, dues à l implémentation en temps différents et par des diverses entités, créent de considérables difficultés d intégration et souvent une véritable impossibilité de communication entre les diverses parties du système informatique, sans compter en outre les problèmes de sécurité dérivant de son développement hétérogène et avec des coûts de gestion élevés causés par le manque d une logique copartagée et de l inévitable duplication de données et d'informations nécessaires au fonctionnement des diverses parties. À travers l utilisation d une architecture logicielle orientée aux services SOA il est possible au contraire de remédier à ces problèmes et permettre ainsi au système de pouvoir améliorer de façon agile en complétant simplement les différentes composantes. Le système SOA garantit dans le temps: une simplification et uniformité des procédures; une gestion des validations plus sûre et flexible pour l accès aux procédures; une intégrité des données accrue; une plus ample transparence sur l état d avancement des flux échangés (par ex. des actes administratifs); la possibilité de créer des processus complexes comme un enchaînement de fonctions élémentaires. 8.2 QU EST-CE QUE LE SOA SOA - L Architecture orientée services (Service Oriented Architecture) - est une architecture logicielle définissant un modèle de systèmes de technologie de l informatique fondé sur le concept de service, qui représente donc l élément structural sur lequel se développent les applications. Le modèle SOA permet de désaccoupler (decoupling) la partie abstraite de définition du service de la partie pouvant être mise en œuvre, c est-à-dire le composant concret. Ce découplage rend le système le moins dépendant de la Annexe : Exigences pour l architecture SOA

30 Version 1.0 Page 26 particulière technologie utilisée pour l implémentation et plus agile dans le suivi des évolutions constantes des systèmes informatiques. SOA est constitué de principes, lignes directrices, meilleures pratiques architecturelles indépendantes de toute technologie et définit une série de propriétés que les services doivent satisfaire pour être réellement réutilisables et facilement intégrés dans un environnement hétérogène. Un service doit définir une interface publiable dans le réseau, pouvant être recherchée et invoquée indépendamment du langage et de la plate-forme. En respectant ces concepts, il est même possible de penser à la définition d une application comme une agrégation de services. Les éléments principaux de l architecture SOA sont les suivants: couches de l'orchestration des Processus de Production (Business Process Orchestration Layer), couches Services (Services Layers), composants des Couches (Components Layers). Figura 6 - Eléments de la SOA À la base du schéma dans la Fig. 1 nous trouvons les systèmes legacy, la couche des applications existantes (layer "existing applications"), qui est interfacé à travers des composants concrets réalisés dans la plate-forme choisie. La couche "composants" ("components") est interfacée avec une couche sémantique afin de créer un service abstrait pouvant être orchestré. La couche des "processus d entreprise" ( business processes ) permet l orchestration des services de la couche "services" ( services ). Annexe : Exigences pour l architecture SOA

31 Version 1.0 Page SOA ET L HR DE L ADMINISTRATION PUBLIQUE DU MAROC Dans le cadre de la proposition de définition d une architecture SOA dans le contexte de l actuelle structure de Ressources Humaines (HR) de l administration publique du Maroc, deux phases ont été identifiées: une phase base qu'il faudrait réaliser dans un court délai et qui pourrait mener à des résultats appréciables et visibles; une deuxième phase avancée où réaliser même les composantes les plus sophistiquées liées surtout aux aspects de sécurité et surveillance, mais non immédiatement indispensables. Schéma général base Dans le schéma de la première phase (base) est illustrée l architecture SOA telle à permettre: un efficace échange de données entre les applications; une gestion fiable des flux de données entre les applications; une plus grande agilité du système pour faciliter les extensions du système et les nouvelles nécessités d intégration de l application. Les différentes directions ORD, TGR, CMR et MMSP sont reliées, à travers une couche concrète de composants et une couche abstraite SOA de communication, au Bus de Services d Entreprise (Enterprise Service Bus ESB). L ESB se charge de gérer de façon fiable les queues de messages et les nécessaires transformations de données pour rendre compatibles les protocoles des différentes applications. Les services ainsi définis peuvent être à leur tour composés en ultérieurs flux au moyen du moteur d Orchestration BPEL (Langage de Description des Procédures d Entreprise ou "Business Process Execution Language") Schéma général avancé Dans le schéma de la deuxième phase - avancé, outre à considérer ce que déjà dit pour la phase base, est illustré l architecture SOA telle à permettre: une gestion centralisée et efficace des utilisateurs du système; une plus grande sécurité pour l accès à l application, à travers la Smart Card ou lecteur d empreintes digitales; une plus grande sécurité de l intégrité des données transmises le long du réseau, obtenue à travers l utilisation de protocoles de transmission cryptés tels que: WS_Security et SSL; un plus haut contrôle et suivi de l utilisation des services du système à travers l adoption d outils de Planification et Suivi des Activités (Business Activity Monitoring BAM). Annexe : Exigences pour l architecture SOA

32 Version 1.0 Page SCHEMA GENERAL BASE Figura 7 - Schéma général - Base Annexe : Exigences pour l architecture SOA

33 Version 1.0 Page SCHEMA GENERAL AVANCE ORD TGR Accès avec Smart card Fichier central des Usagers du système Workstation Couche SOA GIPE WS-Security Couche SOA GIPE WS-Security - Prise en charge assurée à travers le Message Queue - Fonctions de transformation d un type de format à un autre - Gestion des processus de Production comme agrégation de services à travers le système d Orchestration BPEL Enterprise Service Bus Gestion fiable des messages Message Queue Moteur de Transformation Moteur d Orchestration BAM Business Activity Monitoring GIPE GIPE WS-Security WS-Security CMR MMSP Couche SOA Couche SOA Accès avec Smart Card Workstation Figura 8 - Schéma général - Avancé 8.6 SERVICES IT POUR L ARCHITECTURE SOA Les technologies à la base de l architecture SOA sont les suivantes: orchestration des Processus de Production (Business Process Orchestration) BPEL (Langage de Description des Procédures d Entreprise ou "Business Process Execution Language") est le langage XML à la base de l orchestration des services d'orchestration des Processus de Production. À travers le BPEL chaque service peut être assemblé de façon standard selon les règles définies par le Processus de Production ; bus de Services d Entreprise (Enterprise Service Bus ESB). Il s agit de la technologie qui permet de compléter chaque service, d effectuer les transformations des données d un service à l autre et fournit les Annexe : Exigences pour l architecture SOA