Élucider la sémantique de l’entreprise

(Exposé devant le collège des architectes du système d’information, BNP, 28 juin 2018)

La sémantique fournit à l’entreprise à la fois son socle conceptuel et son langage : elle définit les mots avec lesquels les agents désignent les êtres avec lesquelles l’entreprise est en relation, et qui sont l’objet de leurs conversations : l’ingénierie du système d’information s’appuie sur une ingénierie sémantique.

Il arrive que celle-ci soit de mauvaise qualité, que les données soient incohérentes, lacunaires, voire fallacieuses : or le meilleur des algorithmes ne peut rien fournir qui soit meilleur que les données qui l’alimentent car « garbage in, garbage out ».

Les choix fondamentaux

Dans l’immensité du monde qui l’entoure, et aussi dans la complexité de son monde interne, l’entreprise choisit quelques « populations » qu’elle va observer.

Nous empruntons ici le langage de la démographie. Un mathématicien dirait que l’entreprise choisit des « ensembles » composés d’« éléments », il vaut mieux dire « populations » composées d’« individus » car cela oriente l’intuition vers quelque chose de vivant : des « éléments » sont statiques tandis que des « individus » vivent et évoluent.

Quelles sont les « populations » que l’entreprise observe ? Ses clients, ses agents, ses équipements, ses établissements, les entités de son organisation, les logiciels, les méthodes, ses produits, ses concurrents, les factures, les rubriques de la comptabilité, etc. Ces populations sont donc de nature très diverse.

L’entreprise va aussi choisir les attributs qu’elle observe sur chacun des individus qui composent une population. Un individu possède a priori une infinité d’attributs (que l’on pense à un être humain : son poids, sa taille, le nombre de ses cheveux, la couleur de ses yeux, etc.) : l’entreprise ne va en retenir que quelques-uns, nous verrons comment elle les choisit.

Le langage de l’informatique est rempli de faux amis qui suggèrent à l’intuition autre chose que ce qu’ils désignent. Cela ne gêne pas les informaticiens, qui savent exactement ce que ces mots veulent dire, mais cela entrave leur communication avec les autres personnes, qu’il s’agisse des utilisateurs « de base » ou des dirigeants.

Ainsi lorsque l’on utilise un langage de programmation à objets on dit « classe » au lieu de « population » et on nomme « objet » la représentation d’un être réel tandis que dans le langage courant « classe » désigne une rubrique d’une classification, « objet » désigne un être réel.

Nous verrons que le mot « donnée » est lui aussi un faux ami. Il en est de même d’« ordinateur » car cette machine ne crée pas de l’ordre : c’est l’utilisateur qui doit s’en charger.

Nommer, identifier, observer

Chaque « population » doit être nommée, chaque individu doit être identifié, chaque donnée résulte d’une observation : c’est tout simple mais dans la pratique les choses sont compliquées.

La population des « clients » va être parfois nommée « client », parfois aussi « usager », « assuré », « consommateur », « utilisateur », « bénéficiaire », « passager », etc. On mentionne ainsi dans le nom de cette population la relation que l’entreprise a ou veut avoir avec elle. Cela ne facilite pas la communication dans une entreprise qui pratique plusieurs métiers.

Les entreprises sont fréquemment tentées de se focaliser sur leurs équipements et leurs procédures, et cela entraîne des erreurs dans la définition des êtres observés. Les opérateurs télécoms identifient le client par le numéro de la ligne téléphonique, c’est-à-dire qu’en fait ils ne l’identifient pas. Les banques l’ont identifié par le numéro du compte, le RIB. Les transporteurs aérien identifient le passager, que l’on connaît pendant la durée d’un vol, et non le client.

A chaque individu l’entreprise doit associer un identifiant : pour une personne physique « nom et prénom » serait un identifiant de mauvaise qualité car les homonymes sont nombreux. La pratique montre que l’identifiant doit être composé d’une suite de chiffres et de lettres tirés au hasard tout en évitant les doublons : il ne faut pas introduire d’attribut dans l’identifiant, ni composer l’identifiant à partir des attributs comme le prétend la théorie des bases de données relationnelles, car il faudrait modifier l’identifiant si l’attribut change (et rien ne garantit que ne surviendra pas dans le futur un individu qui posséderait le même multiplet d’attributs qu’un autre).

L’INSEE mettait avant 1975 le code « activité principale » dans l’identifiant des établissements, et il fallait changer l’identifiant lorsque l’établissement changeait d’activité principale. Cette erreur a été corrigée lors de la mise au point du répertoire SIREN.

Enfin les données sont observées : elles ne sont pas « données » par la nature, mais d’abord choisies (puisqu’on choisit les populations et les attributs des individus) puis construites par une action volontaire de l’entreprise. C’est pourquoi le mot « donnée » est un faux ami.

Pertinence et pratique de l’abstraction

Qu’est-ce qui guide le choix des populations à observer, des attributs que l’on observe sur les individus ? C’est la relation que l’entreprise a ou veut avoir avec ces individus, c’est l’action qu’elle entend avoir sur eux.

Les intentions de l’entreprise, qui orientent son action, déterminent ainsi en même temps le choix des populations et des attributs qu’elle va observer. La construction d’un référentiel (définition des populations et des attributs) doit donc partir des questions « que voulons-nous faire ? », puis « comment voulons-nous le faire ? ».

L’équipe qui avait entrepris de construire le « référentiel du champ de bataille » à l’État-major des armées a travaillé longtemps sans pouvoir aboutir, jusqu’au jour où un colonel de plus l’a rejointe et a posé la question simple et cruciale : « que s’agit-il de faire ? » : alors tout s’est éclairé et la construction du référentiel a pu progresser (en l’occurrence il s’agissait d’éclairer ceux qui, sur le champ de bataille, avaient des décisions à prendre et en tout premier le stratège).

Comme le disent Abelson et Sussman¹, l’informatique répond à la question « how to », « comment faire », alors que les mathématiques répondent avec leurs axiomes et démonstrations à la question « what is », « qu’est-ce que c’est ». L’informatique est orientée vers l’action alors que les mathématiques, comme nombre d’autres domaines de la pensée, sont contemplatives.

Lorsqu’on choisit les populations et les attributs que l’entreprise va observer, on choisit du même coup ceux qu’elle n’observera pas : l’informatique s’appuie sur une abstraction, représentation sélective et simplifiée du monde, et cette abstraction répond à une finalité pratique, aux exigences de l’action.

L’informaticien est donc un praticien de l’abstraction. Cette expression semble un oxymore, une impossibilité : dans le langage courant, l’abstraction est loin de la pratique et en outre la production des abstractions est réservée aux Grands Savants. La pratique de l’abstraction rencontre donc naturellement une incompréhension générale et les pouvoirs que découpe la sociologie lui refusent souvent la légitimité. C’est la source principale des difficultés que rencontre l’informaticien dans ses relations avec les autres spécialités que rassemble l’entreprise.

Diversité

L’entreprise pratique plusieurs métiers, qui ont chacun leur action propre : dans le cas de la BNP on peut énumérer la gestion d’actifs, gestion des comptes, assurances, trading, etc. Chacun se découpe encore en métiers de moindre ampleur.

Il en résulte que l’entreprise n’a pas une action à partir de laquelle elle pourrait choisir les populations et les attributs, mais plusieurs actions diverses. Sur un même individu le métier 1 va observer certains attributs, le métier 2 en observera d’autres, certains attributs seront observés par les deux, etc.

Si comme cela se passe souvent les métiers sont organisés en silos presque étanches, chacun va définir à sa façon les populations et les attributs, chacun va identifier à sa façon les individus. Il en résulte des obstacles à leur interopérabilité.

Nous avons vu ci-dessus que la population des clients pouvait être nommée de façon différente par les métiers (« assurés », « bénéficiaires », etc.). Il en est de même pour chaque population : dans certaines entreprises la nomenclature des produits et des pièces détachées diffère d’une usine à l’autre, ce qui ne facilite ni la production, ni la relation avec les clients.

Il arrive aussi qu’un même individu ait plusieurs identifiants : un étudiant sera identifié de façon différente par chacune des facultés où il acquiert des unités de valeur et en outre par la bibliothèque universitaire.

Enfin ceux des attributs qui sont observés par plusieurs métiers recevront souvent des noms différents. Les synonymes (deux mots différents pour désigner la même chose) gênent la communication (« chez nous c’est pas comme ça qu’on dit »), mais avec de l’habitude on peut finir par savoir les traduire. Les homonymes par contre (un même mot pour désigner des choses différentes) sont destructeurs car on croit parler de la même chose alors que ce n’est pas le cas : le malentendu peut durer pendant des réunions entières et plus encore.

Pour mettre au point le référentiel d’une entreprise il faut commencer par construire un dictionnaire qui recueille tous les usages, puis faire la chasse aux synonymes et, surtout, aux homonymes. Il sera cependant toujours très difficile de convaincre les métiers d’adopter un vocabulaire commun car chacun chérit ses habitudes auxquelles il associe le particularisme de sa spécialité, de son service, voire de son étage ou de son couloir, ainsi que l’idée qu’il se fait de sa légitimité.

Origine des données

Chaque donnée résulte de l’observation de la valeur d’un attribut sur un individu à une certaine date ou période, et à chaque population, à chaque attribut, le référentiel associe un concept.

Chaque donnée est donc un être hybride résultant de la rencontre d’un concept et d’un individu, puis de l’action volontaire de l’entreprise qui observe cette rencontre. On est loin de l’idée si répandue qui fait croire que les données sont « données par la nature » et qu’il n’y a pas à s’interroger sur leur origine.

Le mot « concept » répugne, comme « abstraction », aux personnes qui ont gardé un mauvais souvenir du cours de philo. Pourtant chacun parle par concepts dès qu’il entreprend de raisonner. Un concept, c’est une idée à laquelle s’ajoute une définition : « rond régulier » est une idée qui permet de reconnaître un cercle quand on le voit, mais seule sa définition (« lieu des points d’un plan équidistants d’un point donné ») permet de raisonner sur le cercle et de s’engager dans des démonstrations.

L’action s’appuie toujours sur une grille conceptuelle : lorsque nous conduisons notre voiture, notre cerveau sélectionne ce qui est nécessaire à la conduite dans les images qui s’affichent sur notre rétine : signalisation, contours de la route, autres véhicules, etc., et il ignore les détails (physionomie des passants, ornements de l’architecture) qui pourraient nous distraire. Lorsque nous faisons la cuisine, rangeons nos affaires, lisons un livre, nous utilisons d’autres grilles conceptuelles. L’ensemble des grilles conceptuelles dont nous disposons délimite un « petit monde », découpé dans le « grand monde » du réel.

Dans une entreprise le système d’information définit la grille conceptuelle de l’action productive, il délimite ainsi un « petit monde » dans lequel il arrive que toute la carrière d’un individu puisse se dérouler. Mais le « grand monde » existe cependant, et se manifeste par des phénomènes qui semblent incompréhensibles, des incidents imprévus, des innovations qui transforment le rapport à la nature, etc. Chacun vit dans un « petit monde », mais il faut être conscient de l’existence du « grand monde » et attentif aux surprises qu’il peut provoquer.

Critères de qualité

Le résultat d’une observation est une donnée quantitative (longueur d’une distance, volume ou poids d’un bien, densité d’un gaz ou d’un liquide, âge ou revenu annuel d’une personne, date d’un événement, etc.), une donnée qualitative (département de résidence, sexe ou métier d’une personne, entité d’une organisation, etc.) ou une donnée qualitative ordinale (tranche de revenu, tranche d’âge, etc.).

Le critère de qualité d’une donnée quantitative est l’exactitude, c’est-à-dire la capacité à alimenter un raisonnement exact et une décision judicieuse. L’exactitude n’est pas la même chose que la précision car un ordre de grandeur peut souvent suffire. La précision peut d’ailleurs être fallacieuse : mesurer la taille d’un être humain au micron près, c’est ignorer que le corps humain est élastique, qu’il change de longueur dans le cours de la journée, et cela risque de faire croire qu’il a la même consistance qu’une barre d’acier à température constante.

Le critère de qualité d’une donnée qualitative est là encore l’exactitude, car une erreur de classement peut avoir des conséquences pratiques, mais il faut aussi considérer la nomenclature qui définit les rubriques selon lesquelles on classera les individus.

L’étude des nomenclatures montre qu’elles varient selon la situation : les activités économiques ont été classées au XVIII^e siècle selon la matière première employée, au début du XIX^e siècle selon la nature du produit, à la fin du XIX^e siècle selon la technique employée, à partir du milieu du XX^e siècle selon l’association dans une même entreprise : ces quatre classifications ont répondu respectivement à une économie essentiellement rurale, aux besoins de la tarification douanière avec le libre échange, à l’éclosion de la grande entreprise lors d’une phase d’investissement intense, enfin au désir de confronter les données physiques et financières dans la planification du système productif².

Il faut donc que la nomenclature soit pertinente en regard des besoins de l’action dans une situation particulière. Il arrive qu’une nomenclature soit utilisée dans des situations auxquelles elle ne correspond pas et alors les données qualitatives risquent de ne pas être pertinentes : c’est ce qui se passe lorsque l’on impose une même nomenclature à des situations diverses, ou que l’on conserve une nomenclature tandis que la situation a changé.

Conclusion

Certains informaticiens sont tentés de considérer les données comme un « charbon », une matière première indifférenciée que l’on traite en masse sans se soucier de son contenu. Cette attitude est implicite lorsque l’on dit que les données sont « un nouveau pétrole » : l’expression « data lake » risque de transporter les mêmes connotations.

En fait l’exigence de qualité varie selon la nature des données. Les identifiants nécessitent le plus grand soin : un identifiant erroné, c’est un dossier perdu, une affaire ratée, un client ignoré, etc. L’exigence d’exactitude est ici liée à celle de la précision : aucune erreur n’est tolérable. Il en est de même pour les « données de référence ». Le taux de TVA ne tolère aucune approximation, les nomenclatures doivent être à jour, etc.

Les architectes doivent faire en sorte que les évolutions des données de référence soient répliquées sans délai dans les applications : si un programmeur transcrit « en dur » la version actuelle d’une nomenclature sans se soucier de sa tenue à jour, l’application passera les tests mais les problèmes surviendront par la suite.

La qualité des données observées dépend, nous l’avons dit, de la pertinence du concept et de l’exactitude de l’observation. Les données calculées sont obtenues en appliquant un algorithme aux données observées : leur qualité dépend donc et de la qualité des observations, et de celle de l’algorithme. Il arrive que celui-ci doive surmonter des différences conceptuelles : il n’est pas facile de produire des indicateurs à partir des bases de données opérationnelles pour construire des séries chronologiques : calculer des totaux mensuels à partir de données hebdomadaires, par exemple, suppose une estimation, et il en est de même chaque fois que les nomenclatures ne s’emboîtent pas exactement.

Pour désigner un concept on utilise un nom et parfois aussi un adjectif. L’action que les données alimentent (les « use cases ») sera désignée, elle, par un verbe : l’ingénierie des processus associe la sémantique des données, que nous venons de considérer, et celle de l’action ; mais c’est une tout autre histoire.

____
¹ Harold Abelson et Gerald Jay Sussman, Structure and Interpretation of Computer Programs, MIT Press 1996.
² Bernard Guibert, Jean Laganier et Michel Volle, « Essai sur les nomenclatures industrielles », Économie et statistique, février 1971.