Ce texte appartient à la série L'ingénierie du système d'information.
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. La donnée se transforme en information lorsqu'elle est communiquée à un être humain capable de l'interpréter[4].
À 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 donc faire abstraction de tout le reste du monde réel. Le mot « donnée » est trompeur : la définition et la mesure sont toutes deux produites 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 transforme en information, puis traduit 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 » restera 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 un 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.
Pertinence des concepts
Le 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 » et cela suppose d'élucider la stratégie et les priorités.
Exactitude de la mesure
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.
Lutte contre l'entropie
Dans le fonctionnement quotidien de l'entreprise les données se dégradent : l'évolution des techniques, produits et marchés provoque une 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 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[5] 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[6] 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[7] (classe d'âge d'une personne, tranche d'imposition), 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[8]. 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 son utilisation automatique par des traitements informatiques.
Chacun des éléments du référentiel est soumis à des règles. Pour les expliquer, nous évoquerons des défauts que l'on rencontre 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 des priorités de facto qui diffèrent de celles que l'entreprise prétend ou souhaite 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 : il fallait le modifier lorsqu'elle 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.
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[9].
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, rigoureuse, qui permette de définir 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[10]. 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 :
a) 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),
b) par les procédures introduites dans les systèmes de saisie ou les interfaces pour vérifier la qualité du codage,
c) par la disponibilité des tables de passage.
Lorsque deux entreprises entendent faire communiquer leurs SI elles doivent établir des tables de passage entre 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 : 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.
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.
À suivre :
Ingénierie des processus
Le contrôle
La stratégie
Les méthodes
Le SI et le système informatique
[4] Nous donnons ici au mot « information » son acception étymologique, « donner une forme intérieure ». Elle s'écarte du langage courant (« les informations de vingt heures ») autant que de celui de la « théorie de l'information » de Shannon.
[5] Entité de l'entreprise (direction, service, mission etc.), par différence avec la « personne physique » qui est un individu.
[6] On utilise souvent des synonymes de « nomenclature » : « classification », « typologie », « taxinomie », « table de codage » etc.
[7] Il est possible de transformer une donnée quantitative en donnée qualitative ordinale en attribuant un code à des intervalles de valeur.
[8] La « classe » d'une nomenclature n'est pas la même chose que la « classe » d'un langage de programmation à objets : la première désigne une catégorie d’une classification, la seconde désigne une population.
[9] 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.
Bravo et merci pour cette synthèse aussi claire que serrée !
RépondreSupprimerCela fait de nombreuses années que je décompose le SI en peuplement (ensemble des populations), population (ensemble des objets d'une classe) et objet (element instance de classe). Cela rend le SI plus vivant et permet d'eviter de créer des classes semantiquement pauvres comme "container" et autre "boite".
RépondreSupprimerune sous-population est alors une selection dans une population...
ThierryC
@ThierryC
RépondreSupprimerIl est en effet fécond de substituer mentalement les termes "population" à "classe" et "individu" à "objet", à condition de bien gérer les connotations qui s'attachent à ces termes.
Il faut cependant compléter cette vue ensembliste du monde par une vue organique : une direction d'une entreprise n'est pas incluse dans l'entreprise comme un sous-ensemble dans un ensemble, car elle y remplit une fonction spécifique ; de même, et pour prendre un exemple plus évident encore, les poumons d'une personne ne sont pas un sous-ensemble de cette personne, mais un organe.
la population représente l'extension de la classe (au sens mathématique) et la classe (du modèle objet) en représente l'intension, cad le modèle adopté pour les objets de la population. Ce complément au modèle "objet" est assez fécond en terme de conception.
RépondreSupprimerPour modéliser une entreprise, il faut plutot rajouter au dessus du modèle objet les outils de la systémique et considérer l'entreprise comme un système et ses composants comme des sous-systèmes. La direction est à la tête du sous-système de pilotage de l'entreprise et ce qu'on appelle l'administration représente la composante productive de ce sous-système, sachant que la finalité de l'entreprise est plutôt représentée par son sous-système de production. Système de pilotage et système de production donnant lieu à des informatisations très différentes. Si l'informatique de gestion remplit les besoins d'informatisation du pilotage et ce quel que soit l'entreprise, l'informatique de production relève de techniques spécifiques au domaine.
Un système (et un sous-système) est une association complexe de populations d'objets en interaction d'où émerge la finalité observée du système. La phase de conception qui modélise le système le résoud en sous-systèmes ... jusqu'a décrire un système élémentaire en populations d'objets de classe donnée et en relations statiques et dynamiques entre ces objets...
ThierryC
@ThierryC
RépondreSupprimerD'accord dans l'ensemble.
Je préfère cependant réserver le mot "pilotage" à la gestion quotidienne, et dire "orientation" pour qualifier la mission stratégique de la direction.