@SURTITRE:NORMALISATION
@TITRE:Bien définir les données
@CHAPO:Pour interconnecter leurs systèmes d'information, les entreprises auront de plus en plus besoin de s'entendre sur la définition de leurs données. Les normalisateurs mettent au point les règles à suivre pour bien s'entendre.
@TEXTE:L'avenir de l'informatique dépend de la cohérence des données plus encore de la solidité des architectures techniques. L'EDI (échange de données informatisé), par exemple, ne pourra donner toute sa mesure que si tous les partenaires sont d'accord sur la sémantique des messages, et pas seulement sur la syntaxe Edifact.
Ce type de préoccupation peut sembler encore bien futuriste à bien des responsables informatiques. Ils ont déjà bien du mal à résoudre les problèmes internes à leur entreprise et à mettre d'accord les utilisateurs des différentes directions. Et à couler leur consensus dans le bronze des méthodes et des ateliers de génie logiciel. Mais, à plus ou moins long terme, il faudra bien s'entendre sur le sens des mots. Non seulement au niveau sectoriel (l'automobile, la santé) et national, mais globalement et mondialement.Comme pour les systèmes d'exploitation, les langages de programmation et les protocoles de télécommunications, la cohérence se construit à la fois par les standards de fait et par la normalisation proprement dite.
@INTER:Normalisation par le marché ou par le consensus?
@TEXTE:Les progiciels, en particulier, structurent fortement les données par leur conception même et par leur documentation. Mais les grands acteurs industriels jouent aussi leur rôle, par les modèles qu'ils imposent tant à leurs réseaux de distribution qu'à leurs fournisseurs. Enfin, toutes les autorités législatives ou règlementaires définissent des données plus ou moins directement: plan comptable, déclarations sociales ou douanières, etc.
Au niveau le plus élevé, les organismes de normalisation souhaitent faciliter la cohérence de ces processus. L'ISO (International standard organisation) et la CEI (Commission électrotechnique internationale) préparent ensemble une norme internationale (ISO/IEC DIS 11179) sur les données. Elle comportera six parties (voir encadré).
@INTER:Quelques règles simples pour bien définir les données
@TEXTE:Parmi les travaux les plus immédiatement utiles, signalons la quatrième partie: règles à suivre pour formuler des définitions de données. Même sans entrer formellement dans le jeu de la standardisatin, ces règles peuvent inspirer tous les rédacteurs de spécifications et documentations informatiques. D'autant qu'elles sont accompagnées d'exemples Six des règles sont obligatoires.
1. Une définition de données doit être unique. Autrement dit, deux données différentes doivent avoir des définitions différentes. Exemple: Date de réception des marchandises et Date d'expédition des marchandises ne doivent pas avoir la même définition "Date à laquelle les marchandises sont livrées".
2. Une définition s'exprime au singulier (sauf si la donnée a un sens pluriel par nature). Exemple: Numéro d'article doit se définir comme "numéro de référence identifiant un article", et non "identifiant les articles".
3. Une défintion doit dire ce qu'est le concept, et pas seulement ce qu'il n'est pas. Exemple: définir Coût de fret comme "coûts imputés à un chargeur pour transporter des marchandises, par quelque moyen que ce soit, d'un lieu à un autre, conformément à un contrat de transport". Et non "coûts autres que l'emballage, la documentation, le chargemnet, le déchargement et l'assurance".
4. Une définition doit former une phrase descriptive. Elle ne doit pas se contenter d'indiquer un synonyme ou de paraphraser le nom de la donnée. Exemple: Nom de l'agent se définira "nom de la personne autorisée à agir au nom d'une autre personne" et non simplement comme "représentant".
5. Une définition n'emploiera abréviations que si elles sont bien connues. On développe un acronyme à sa première utilisation. Exemple: LMI (Le monde informatique).
6. Pas de définitions à tiroirs. La définition d'une donnée ne doit pas contenir celle d'une autre donnée. Si nécessaire, on mettra une note à la fin de la définition.
Cette partie de la norme comporte en outre sept recommandations, non strictement obligatoires. Une définition doit donner le sens essentiel du concept, être précise et sans ambiguïté, tenir par elle-même, ne pas entrer dans des considérations sur l'usage du terme, éviter les raisonnements circulaires. Enfin, toutes les définitions doivent s'appuyer sur une même terminologie et suivre une structure logique cohérente.
@INTER:Les attributs de base de toute donnée
@TEXTE:Plus proche de la technique informatique, la partie 3 définit les attributs de base pour spécifier les données. Elle se limite à un jeu d'attributs de base, indépendamment de leur utilisation dans des applications particulières: nom, définition, obligation, condition, occurrence maximum, type de donnée, taille maximum, jeu de caractères,langue, commentaire. Elle définit chacun de ces éléments, indique s'il est obligatoire. Elle en précise aussi le mode d'utilisation. En annexe, la norme propose un certain nombre d'attributs additionnels, de type identification, définition, relationnel, de représentation ou administratif.
Pour l'observateur extérieur, et sans doute pour bien des développeurs, ces cadres semblent bien abstraits et loin du concret. Ils ne prennent pas non plus en compte les évolutions actuelle de la technique: orientation objet, interfaces graphiques, données volumineuses de type binaire (blobs, binary large objects, comme le son ou l'image vidéo). Mais ils ont le mérite de permettre, à relativement peu de frais, une conception du système d'information qui en facilitera les liaisons avec ceux des autres entreprises. Leur portée pratique devrait dépendre essentiellement des grands éditeurs. Soit en y conformant leurs progiciels. Soit en les intégrant à leurs ateliers de génie logiciel. @SIGNATURE:PIERRE BERGER
@ENCADRE TITRE:Les six thèmes de la norme ISO 11179
@ENCADRE TEXTE:
- Partie 1. Cadre général pour la production et la normalisation des données (types)
- Partie 2. Classification des concepts pour l'identification des domaines.
- Partie 3. Attributs de base des données (types).
- Partie 4. Règles et directives pour la formulation des définitions des données.
- Partie 5. Principes de nommage des données (types).
- Partie 6. Enregistrement des données (types).