2.1 - Ingénierie sémantique

Si l’on fait abstraction de la complexité de la plate-forme et de la diversité des « applications », un SI peut sembler très simple. Alimenté par des « données » que quelqu’un saisit, il les traite pour produire des « résultats » puis conserve données saisies et résultats afin qu’ils puissent être consultés : un utilisateur ne fait jamais que lire, écrire et lancer des traitements.

Une donnée, c'est le couple que forment une définition (ou concept) et une mesure, la mesure étant caractérisée par le type de la donnée ainsi que par la périodicité et le délai de ses mises à jour. Une donnée se transforme en information lorsqu’elle est communiquée à un être humain capable de l’interpréter.

À la base de tout SI se trouvent ainsi des choix qui déterminent un langage : il faut choisir les êtres qui seront observés pour être représentés dans le SI, puis les attributs que l’on observera sur ces êtres, et ainsi faire abstraction de tout le reste du monde réel. Le mot « donnée » est donc trompeur : la définition et la mesure sont toutes deux produites de façon sélective par l’observateur humain et non « données » par la nature.

Les concepts doivent obéir au critère de pertinence, c’est-à-dire d’adéquation à l’intention volontaire qui oriente l’action : la qualité sémantique d’un SI est le premier critère de son « alignement stratégique ».

Pour comprendre de quoi il s’agit, considérons la vie quotidienne. Quelqu’un qui conduit une voiture ne doit retenir, dans la continuité de son champ visuel, que les signaux utiles à la conduite et donc faire abstraction des autres signaux. Cette abstraction ne prédétermine pas la couleur d’un feu de signalisation dont l’observation fournit, dans le cadre subjectif mais pertinent que délimite l’abstraction, une donnée objective que le conducteur transformera en information, puis traduira en décision et enfin en action effective.

Certaines personnes à l’entendement sommaire, croyant que la pertinence va de soi, qualifient dédaigneusement le souci sémantique d’« intellectuel » ou de « philosophique ». C’est oublier que l’adage garbage in, garbage out est implacable : si les concepts ne sont pas pertinents le SI ne peut rien fournir qui vaille. La sémantique détermine son architecture tout comme les fondations déterminent celle d’une maison.

Le socle sémantique du SI conditionne d’ailleurs l’action de l’entreprise. Si celle-ci n’a pas choisi d’observer ses clients, « mettre le client au cœur de l’entreprise » sera un slogan sans portée : c’est ce qui se passe quand un transporteur aérien ne connaît que des passagers, un opérateur télécoms que des lignes, une banque que des comptes etc.

Qualité des données

Toute donnée étant le couple que forment une définition et une mesure, la qualité des données s’évalue selon deux critères : pertinence des concepts, exactitude de la mesure.

Un SI n’a pas pour fonction de « décrire la réalité », car la complexité de celle-ci outrepasse toute description, mais de servir l’action de l’entreprise. Il fera donc abstraction des êtres qui ne sont pas concernés par cette action et, dans l’observation de chacun de ces êtres, il fera encore abstraction des attributs jugés sans importance pour l’action.

La construction d’un référentiel (cf. ci-dessous) doit donc partir de la question « que voulons-nous faire », ce qui implique d’élucider la stratégie et les priorités.

La mesure sera exacte si elle peut alimenter un raisonnement exact et, ainsi, favoriser la justesse de l’action. L’exactitude importe plus que la précision car un excès de précision peut être fallacieux : mesurer au micron près la taille d’un être humain, c’est ignorer que le corps humain est élastique.

Les résultats statistiques, indicateurs de pilotage et estimations prévisionnelles peuvent souvent se satisfaire d’un ordre de grandeur exact quoique imprécis. Par contre l’exactitude et la précision se rejoignent dans certaines données opérationnelles : un taux de TVA, un prix unitaire, le montant d’une facture etc. ne tolèrent aucune approximation.

Dans le fonctionnement quotidien de l’entreprise les données se dégradent : l’évolution des techniques, produits et marchés provoque l’obsolescence des concepts ; les fusions et absorptions, ainsi que les partenariats, apportent des homonymes et synonymes ; sur le terrain la pratique du codage est souvent erronée par négligence, malentendu, ou encore par émergence de « dialectes locaux » qui donnent aux codes un autre sens que celui qui est retenu par l’entreprise.

Assurer la qualité des données, puis lutter contre l’entropie qui la dégrade, c’est la tâche de l’administration des données.

Administration des données

On appelle « administrateur des données » la personne morale [entité de l’entreprise (direction, service, mission etc.), par différence avec la « personne physique » qui est un individu] chargée de veiller à la qualité sémantique du SI : pertinence des définitions, absence de synonymes et d’homonymes, accessibilité et clarté de la documentation, exactitude des codages etc.

Les définitions sont contenues dans un référentiel qui indique aussi le type de chaque donnée et l'identité de la personne morale (« propriétaire de la donnée ») habilitée à tenir sa mesure à jour et, si nécessaire, à faire évoluer sa définition. L’administrateur des données est garant de la qualité du référentiel et de celle de son utilisation.

La construction d'une nomenclature (Guibert, Laganier et Volle [14] ; on utilise souvent des synonymes de « nomenclature » : « classification », « typologie », « taxinomie », « table de codage » etc.) et l'identification du propriétaire d'une donnée provoquent souvent une redéfinition de la frontière entre des entités de l'entreprise. Ce rôle est « politiquement » si délicat qu’il a été parfois nécessaire de rattacher l’administrateur des données au directeur général.

Référentiel

Par « référentiel » on entend l'ensemble des règles, documents et bases de données concernant les identifiants, nomenclatures et définitions utilisés par le SI, ainsi que les règles concernant le partage de ces références par les diverses composantes du SI.

On peut se représenter l’entreprise comme un ensemble de « domaines » ou « métiers » (leurs contours sont souvent ceux des directions que découpe l’organigramme), dédiés chacun à une production spécifique. Les tâches réalisées dans ces domaines constituent des « processus » articulant des « activités » réalisées par des êtres humains qu’assistent des automates et qu’outillent des machines.

Tout processus concerne divers ensembles de clients, produits, commandes, factures, personnes de l’entreprise, entités de l’organisation etc. On peut, par analogie avec la démographie, considérer chacun de ces ensembles comme une « population » et ses éléments comme des « individus ».

La première indication que contient le référentiel est donc la liste des populations et leur définition. Puis il faut identifier les individus qui composent chaque population.

L'identifiant, clé associée à chaque individu, permet de retrouver les données le concernant aux diverses étapes de son cycle de vie.

À chaque individu sont aussi associées des données (ou « attributs ») observées et tenues à jour. Chaque donnée a un type : elle peut être quantitative (revenu, poids d’une personne etc.), qualitative (métier, commune de résidence etc.), qualitative ordinale (classe d'âge d'une personne, tranche d'imposition ; il est possible de transformer une donnée quantitative en donnée qualitative ordinale en attribuant un code à des intervalles de valeur), textuelle (commentaire) ; ce peut être une image (photographie, carte géographique), une date, une adresse postale ou électronique, un nom propre etc.

La mesure d'une donnée quantitative est un nombre (de type entier, rationnel ou réel) dont les valeurs sont éventuellement bornées. La mesure d'une donnée qualitative est un codage caractérisant l'affectation (classement) d'un individu à une classe d'une nomenclature (la « classe » d'une nomenclature n'est pas la même que la « classe » d'un langage à objets : la première désigne une catégorie dans une classification, la seconde désigne une population). La mesure d’une image est un graphisme.

Le référentiel prend deux formes : une forme documentaire (papier ou, de préférence, électronique) pour les utilisateurs humains ; une forme physique (base de données) pour l’utilisation automatique par des traitements informatiques.

Chacun des éléments du référentiel est soumis à des règles. Pour expliquer ces règles nous évoquerons des défauts que l’on rencontre trop souvent sur le terrain.

Règles pour les identifiants

Certaines entreprises identifient non le client, mais un équipement qui caractérise le service rendu à celui-ci : ainsi un opérateur télécoms identifie la ligne téléphonique (à laquelle le nom et l'adresse du client sont attachés comme des attributs), une banque identifie le compte avec le RIB.

L’examen des identifiants révèle ainsi des priorités de facto qui diffèrent souvent de celles que l’entreprise prétend ou souhaiterait avoir : ces entreprises-là s'intéressent sans doute plus à leur organisation interne qu'au client et à ses besoins.

Il arrive aussi que l'on introduise des attributs dans l'identifiant. Si celui d’un client comprend un élément géographique (numéro du département etc.), il faudra le modifier quand le client déménage. Avant la mise en place du fichier SIRENE, l’INSEE codait l’activité principale d’un établissement dans son identifiant, qu’il fallait donc modifier lorsque l’activité principale changeait.

Il arrive enfin que l'on réutilise pour un nouvel individu l'identifiant d'un autre arrivé en fin de son cycle de vie : ainsi l’ANPE a réutilisé naguère, pour identifier ses agences, les identifiants d'agences supprimées. Cela oblige, lors de l'examen de l’historique concernant un individu, à vérifier qu’il s’agisse continûment du même.

Cette liste d'errements montre la nécessité des règles suivantes :

• définir correctement les populations : il ne faut pas confondre le client avec le produit qui lui est fourni ni avec un contrat passé avec lui ;
• construire des identifiants pérennes, affectés à l'individu pendant tout son cycle de vie ;
• ne pas confondre le rôle de l'identifiant et celui des attributs : l'identifiant ne doit comporter aucun autre code que lui-même ;
• s'interdire de réutiliser un identifiant après la fin du cycle de vie de l'individu.

La meilleure façon de construire un identifiant sera donc de tirer au hasard une suite de caractères puis de vérifier qu’elle n'a pas déjà été utilisée. Elle doit contenir assez de caractères pour qu'il soit possible d'identifier tous les individus de la population concernée pendant le cycle de vie du SI, c'est-à-dire pendant quelques dizaines d'années. Il est utile enfin de lui associer une clé de contrôle qui permettra de vérifier son exactitude.

Nota Bene : De plus en plus souvent, l’identifiant sera un URI (Uniform Resource Identifier) ou un UUID (Universally Unique Identifier) conformément au modèle REST (Representational State Transfer) du Web sur l’Internet (Richardson et Ruby [31]).

Lors des traitements informatique, les identifiants doivent être manipulés et vérifiés avec soin : un identifiant erroné, c’est un dossier perdu avec toutes les conséquences qui en résultent [les universités identifient les étudiants chacune à sa façon : cela crée des difficultés pour les activités interuniversitaires (diplômes cohabilités, échanges entre bibliothèques etc.). Il est donc souhaitable, lorsque plusieurs institutions sont concernées par une même population, que leurs procédures d’identification soient coordonnées].

Règles pour les attributs

Certains attributs sont inutiles : personne ne mesure le nombre des cheveux d’un client, seuls des policiers noteront la couleur de ses yeux. D’autres sont nécessaires : nom, adresse etc. Si l’on classait les attributs sur un axe selon leur utilité il faudrait y placer un curseur pour délimiter ceux que l’on observera, mais il n’existe pas de règle formelle qui permette de définir rigoureusement la position de ce curseur.

Il faut en outre, pour les attributs qualitatifs, choisir le « grain de la photo » qui indique le degré de détail du codage : là non plus, il n’existe pas de règle formelle.

Comme on est toujours tenté d’aller trop loin dans le détail il faut s’imposer une contrainte. Pour construire le référentiel d'une entreprise de service faisant quelques milliards d’euros de chiffre d'affaires, par exemple, il sera raisonnable de se limiter à un délai de l'ordre de six mois et à un budget de l'ordre du million d’euros (entre autres conséquences cela oblige à choisir rapidement l'outil qui servira à mettre en forme et à stocker le référentiel plutôt que de passer des mois à chercher le meilleur outil). Si à l’usage une partie du référentiel se révèle trop peu détaillée on pourra toujours l’enrichir par un travail marginal supplémentaire.

Règles pour les nomenclatures

Une nomenclature est une partition d’une population ou, quand elle a plusieurs niveaux, une suite de partitions emboîtées (ainsi le code géographique contient les niveaux îlot, commune, canton, département, région). À chaque classe d’une partition est associé un code.

Le codage est utilisé dans le SI à deux fins distinctes : d’une part il détermine le traitement de l'individu dans la procédure opérationnelle (qualifier une demande d'emploi par un métier, classer un contribuable dans une tranche d'imposition, évaluer l’éligibilité d’une demande de crédit etc.) ; d’autre part il sert à produire des statistiques sur la population étudiée, chaque individu étant compté dans la classe à laquelle le codage l'affecte.

Si l’on n’y veille pas, la nomenclature aura des défauts qui provoqueront des erreurs : si une partie de la population n'est pas couverte, il y a omission ; si une même partie de la population peut être classée de deux façons différentes, il y a double emploi (cela se produit quand les libellés sont ambigus) ; si le découpage ne correspond pas à l'action que le SI est chargé d'outiller, la nomenclature n'est pas pertinente etc.

La qualité d'une nomenclature se juge donc :

• au plan formel, selon l'exactitude du découpage de la population : il faut qu'elle forme une suite de partitions emboîtées, chacune sans omission ni double emploi ;
• au plan sémantique, selon la pertinence du découpage : les classes doivent regrouper les individus en fonction de la similitude des actions que l'entreprise entend conduire envers eux ;
• au plan pratique, selon la clarté de la documentation qui l'accompagne : même pertinente, une nomenclature non commentée sera mal interprétée par ceux qui l'utilisent ;
• au plan technique enfin :
  • par la clarté du code utilisé pour identifier les classes (on désignera souvent un niveau par le nombre de chiffres que comporte un code numérique),
  • par les procédures introduites dans les systèmes de saisie ou les interfaces pour vérifier la qualité du codage,
  • par la disponibilité des tables de passage.

Lorsque deux entreprises entendent faire communiquer leurs SI elles doivent établir des tables de passage entre leurs nomenclatures. Tout est simple s’il existe une bijection entre classes, la table de passage se ramenant alors à une traduction entre terminologies. Mais souvent la correspondance se fait entre parties de classes : dans ce cas, la table de passage ne sera qu’approximative et il peut en résulter de telles difficultés dans le traitement des dossiers individuels que l'on sera contrait de réformer les nomenclatures. La vérification de l'adéquation des nomenclatures est donc un préalable obligé de tout partenariat ou de toute coopération commerciale lorsqu’ils impliquent, comme c’est le plus souvent le cas, de faire coopérer les SI.

Les nomenclatures évoluent car elles doivent refléter des priorités changeantes. Cela pose plusieurs problèmes (Boydens [4]). Le suivi historique d’une population suppose entre versions successives de la nomenclature un transcodage approximatif. On préfère d’ailleurs parfois, pour éviter les à-coups qui rendraient le SI instable, prolonger la durée de vie d'une nomenclature au delà de ce qui serait convenable en termes de pertinence.

Nota Bene : il existe des standards qu’il est impératif de respecter si l’on veut pouvoir assurer l’interopérabilité entre l’entreprise et le reste du monde : code géographique, liste des langues, microformats pour le codage des cartes de visite ou des événements dans les agendas etc.

Règles pour le partage des références

Les nomenclatures sont la source des tables de codage utilisées par les diverses composantes du SI (« applications »). Il faut que ces tables soient mises à jour sans délai quand les nomenclatures évoluent : sinon on risque des erreurs dans l'interprétation des données transmises d'une composante à l'autre, on risque aussi de produire des statistiques fallacieuses.

La synchronisation des tables de codage avec les nomenclatures ne peut être obtenue que si les tables sont toutes asservies à une table mère, dite « table de référence ». Soit celle-ci sera consultée au coup par coup, soit elle sera répliquée sans délai perceptible dans les composantes qui l'utilisent.

Une erreur fréquente est de « faire comme si » cette tenue à jour allait de soi. Il arrive ainsi que l’on recette, après un développement, des composantes contenant une copie de la table de référence mais non les procédures de mise à jour. Cette copie étant récente l’erreur n’apparaît pas lors de la recette mais pendant l'exploitation l'écart se creusera et la qualité des données se détériorera.