Avant-propos.

L'administration des données (appelée AD dans la suite) peut être définie comme « l'ensemble des actions concourant à garantir la cohérence des informations traitées par le système d'information, en termes de sens, de format et de contenu ».

Cette définition, très large, peut être déclinée à plusieurs niveaux au sein de l'organisation de l'armée de terre. On retient ici les trois niveaux identifiés dans la circulaire de référence sur l'organisation de la fonction « administration des données » :

• 1. Niveau armée de terre.

• 2. Niveau direction centrale ou organismes assimilés.

• 3. Niveau projet/système.

Les deux premiers niveaux ont pour objectif d'assurer la cohérence des données échangées, au sein de l'armée de terre d'une part, au sein d'un organisme d'autre part.

Le troisième niveau a pour objectif d'assurer la cohérence des données du projet avec les normes définies par les deux premiers niveaux.

La présente circulaire définit les règles qui s'appliquent à l'administration des données du niveau 3, c'est-à-dire la fonction d'administration des données d'un projet.

1. Règles régissant l'administration des données dans les projets.

1.1. Existence et situation de l'administrateur des données du projet.

La mise en place d'un administrateur des données local (ADL) est obligatoire dans les projets informatiques traités dans l'armée de terre (une ou plusieurs personnes suivant les besoins), quelle que soit leur taille, et indépendamment du fait qu'il soient ou non sous-traités.

Au sein de la maîtrise d'ouvrage :

• un administrateur des données est recommandé ;

• si le projet est sous-traité l'administrateur des données est obligatoire ;

• l'administration de données, au sein de la maîtrise d'ouvrage, ne peut pas être sous-traitée ;

• si aucun administrateur des données ne peut être désigné (absence de compétence ou manque de personnel) c'est l'administrateur des données de la direction ou de l'état-major auquel est rattaché le projet qui assure cette fonction.

Au sein de la maîtrise d'œuvre : la mise en place d'un administrateur des données est obligatoire au sein de la maîtrise d'œuvre.

Il est identifié dans l'organigramme si l'importance du projet le justifie.

L'administrateur des données doit être directement rattaché au chef de projet, et ne doit donc pas être inclus dans une équipe de conception ou de développement.

Dans tous les cas, la personne à qui est confiée la mission d'administration des données est identifiée nominativement [même si elle cumule plusieurs fonctions, administrateur de base de données (DBA) en particulier].

Dans le cas où l'administrateur cumulerait des fonctions, il est important de dissocier les tâches relevant de l'administration des données des autres tâches. Notamment, au cours des réunions de validation, l'administrateur des données est formellement identifié.

Dans le cas de projets sous-traités cette directive doit être intégrée au cahier des clauses techniques particulier (CCTP).

1.1.1. Profil.

Les tâches décrites dans la suite conduisent à conseiller, pour la personne en charge de l'administration de données du projet, deux au moins des quatre caractéristiques suivantes :

• expérience/formation en matière de systèmes d'information ;

• expérience/formation dans la gestion de grands projets ;

• très bonne connaissance fonctionnelle du champ du projet ;

• avoir participé à la phase de schéma directeur (s'il y a lieu).

L'administrateur des données du projet doit donc être, de manière optimale, expérimenté, capable de prendre du recul et des décisions motivées. Il doit pouvoir faire preuve de beaucoup d'autonomie et d'une capacité à appréhender plusieurs problèmes en même temps. Cette fonction requiert enfin une certaine « autorité » compte tenu de sa responsabilité.

L'administration de données de direction (ADD) possède une prérogative de blocage, de veto, si la cohérence du système d'information auquel appartient le projet est en jeu, et mise en évidence, par exemple, par l'administrateur de données local (ADL).

1.2. Tâches confiées à l'administrateur des données du projet.

Les activités s'inscrivant dans la fonction d'administration des données doivent conduire à centraliser, tenir à jour et valider :

• le modèle conceptuel des données (MCD) ;

• le modèle logique des données (MLD) ;

• le dictionnaire des données.

De manière plus détaillée, cela se traduit par les actions listées ci-dessous, qui sont séparées en deux catégories : les actions à effectuer au début du projet afin de permettre le bon fonctionnement de l'AD, et les actions récurrentes, c'est-à-dire les actions menées tout au long du projet. Les tâches initiales devraient normalement être traitées avant le démarrage du projet, et leur résultat intégré au plan pour l'assurance de la qualité (PAQ), ou tout autre document analogue décrivant les règles en vigueur au sein d'un projet.

1.2.1. Tâches initiales.

Au démarrage du projet l'administrateur des données du projet est chargé :

• de récupérer les normes existantes afférentes au domaine traité par le projet ;

• d'élaborer le lexique utilisé pour les définitions, et les abréviations recommandées sur la base du lexique armée de terre ;

• de définir les règles de codification des noms de données au sein du projet et au sein de l'atelier de génie logiciel utilisé ;

• de fournir au projet les tables de codification normalisées du domaine ;

• de définir la typologie des données élémentaires (montants, volumes, etc.) ;

• de définir le mode de fonctionnement de l'AD au sein du projet (voir 2).

1.2.2. Tâches récurrentes.

Pendant la phase de déroulement du projet l'administrateur de données du projet est responsable des tâches suivantes :

• contrôle de la modélisation ;

  • contrôle des objets et relations du MCD (avec leur définition), du rattachement des propriétés aux objets et relations ;

  • gestion du MLD (tables et colonnes en environnement relationnel) ;

• contrôle des propriétés élémentaires (sens, format, contenu), vérification de la cohérence des données (synonymes, polysémies, etc.) ;

• vérification de l'existence de données analogues à celles modélisées, au sein de l'armée de terre ;

• qualification des règles applicables aux données (valeurs possibles ou règle de codification) ;

• identification de l'origine des données et de leur propriétaire ;

• gestion des « alias » (gestion des manifestations différentes voulues d'une même donnée élémentaire ; très utile pour les données logiques et techniques) ;

• gestion des données « techniques » (une zone d'affichage ou de saisie sur écran par exemple) ;

• définition des modalités d'interface avec les applications externes au système ;

• coordination avec l'AD de niveau supérieur, en particulier ;

  • pour les besoins d'évolution des normes ;

  • pour la fourniture dictionnaire vers niveau « direction » ;

  • pour la liaison avec le « fonctionnel » du domaine ;

  • pour la fourniture des flux de données vers les autres systèmes ;

  • participation aux instances de normalisation interprojets.

La responsabilité, de la cohérence et de la modélisation des données, du niveau conceptuel, relève dans sa totalité de l'administrateur des données du projet. Mais, en aucun cas, la pertinence fonctionnelle du MCD par rapport aux objectifs du projet, n'est de sa compétence.

Il n'y a qu'un seul MCD pour un projet, même si les sous-projets sont susceptibles de n'en voir que des parties.

Le MCD est la référence. A ce titre il doit être tenu à jour jusqu'à l'achèvement du projet et suivi au cours de l'élaboration des différentes versions. La version finale du MCD sert de base de départ pour la maintenance.

1.3. Interactions avec la fonction de l'administrateur de base de données.

L'administrateur de données n'est pas impliqué dans l'optimisation du modèle logique des données, c'est-à-dire le passage du MCD vers le MLD brut puis le MLD optimisé. Ces tâches incombent en effet au DBA, en plus de la mise en œuvre effective et de l'optimisation physique de la base de données.

L'administrateur de données local demeure, quelles que soient les actions d'optimisation entreprises au niveau du MLD (modification de la structure des tables, adjonction, retrait de tables), responsable de ce dernier.

Sa responsabilité d'administrateur de données au niveau du MLD s'exprime donc de la façon suivante :

• garantir la cohérence du MLD avec le MCD (en principe, le mieux est qu'il n'y ait qu'un seul dictionnaire pour les deux modèles, mais tous les outils ne le permettent pas) ;

• vérifier que les modifications de structures introduites dans le cadre de l'optimisation sont pertinentes en terme de sens, et cohérentes.

2. Modes de fonctionnement de l'administration des données.

Les trois principaux modes de relation qui peuvent s'instaurer entre l'administrateur des données du projet et les équipes de concepteurs/développeurs sont :

• le fonctionnement avec contrôle a priori, modèle conseillé ;

• le fonctionnement contrôle a posteriori, modèle déconseillé ;

• le fonctionnement mixte, modèle parfois plus réaliste pour de gros projets.

Dans ces trois scénarios, l'implication de l'administrateur des données du projet dans le processus de conception des données paraît indispensable (limitation des blocages dans le premier scénario, limitation des remises à hauteur dans le deuxième).

2.1. Fonctionnement en contrôle a priori.

Dans ce scénario, l'administrateur des données est intégré au processus de conception, et c'est lui seul qui est autorisé à faire évoluer le modèle dans l'atelier de génie logiciel (AGL) (au moins : objets et relations, au plus : attributs).

Ce mode permet de « verrouiller » la conception, mais il a le défaut de placer l'administration des données sur le chemin critique de conception, et de rigidifier quelque peu le processus. Dans ce scénario, l'administrateur des données a la responsabilité du contenu de l'AGL de conception sur la partie « données ».

Un tel scénario nécessite une administration des données centrale plus étoffée que le suivant (temps de réaction).

2.2. Fonctionnement en contrôle a posteriori.

Dans ce scénario, l'administrateur des données intervient en « arrière-plan » pour vérifier la cohérence d'ensemble (modèles et attributs) sans bloquer la conception. Les projets modélisent « à volonté », et sont responsables de l'utilisation de l'AGL de conception (avec un seul modèle malgré tout pour l'ensemble des projets). L'administrateur des données fait ses remarques suite à son analyse, remarques qui doivent être réintroduites dans le modèle par les différents projets.

Ce mode permet de découpler la conception et le contrôle sémantique, mais il induit un risque de perte de contrôle du modèle par l'administrateur de données, et des surcoûts de conception liés aux remises à niveau qui font suite aux contrôles de l'AD.

2.3. Fonctionnement en contrôle mixte.

Ce scénario est un compromis des deux scénario précédents.

L'administrateur des données travaille en mode a priori pour la conception des objets et des relations.

La création des propriétés est ensuite laissée à l'initiative des équipes de conception/réalisation.

Ce mode de fonctionnement est adapté aux gros projets, qui ont un nombre important de données, et que la procédure a priori risque de ralentir en début de conception.

Ce mode comporte cependant un risque, car il y a nécessairement un contrôle a posteriori des données par l'administrateur des données, et donc possibilité de modifications et de reprises. Mais ce risque est moindre car il ne remet pas en cause le modèle.

3. Texte abrogé.

La circulaire n^o 1766/DEF/EMAT/BMSI/S/2 du 9 décembre 1993 relative au fonctionnement de l'administration des données au sein des projets informatiques de l'armée de terre est abrogée.