Page d'accueil de ce livre
Chapitre 7 L'horizon du système d'information
1 Cohérence et pertinence des données
À son apparition, l'informatique de gestion donna naissance à des
applications séparées : comptabilité, paie du personnel, gestion des
stocks. Il apparut bientôt que la séparation de ces
applications engendrait des redondances et des incohérences dans les
données. D'où l'idée d'unifier les différentes visions de l'entreprise
exprimées par les fichiers multiples de ces applications en un système
cohérent : le Système d'Information de
l'Entreprise[25] (SI).
Cette idée est bien sûr pleine de bon sens : dès lors qu'une donnée,
disons la catégorie d'un employé, est enregistrée de façon indépendante
dans le fichier de paie d'un côté, dans l'organigramme de l'entreprise
de l'autre, il est à peu près inévitable que ces données soient incohérentes.
C'est pour éviter cela qu'ont été inventés les Systèmes de Gestion de Bases
de Données (SGBD).
L'idée de Système d'Information est bien
sûr une bonne idée, mais ici aussi nous allons voir que sa
systématisation outrancière conduit à l'inverse du résultat recherché,
à la perte d'information.
Comme nous avons déjà eu l'occasion de le voir, notamment à la section
5, l'information n'est pas une denrée qui existe dans la
nature, elle est le produit d'une élaboration complexe par une démarche
que nous pouvons décomposer en deux temps : une phase de construction
d'une base de données, suivie d'une phase d'interprétation de ces
données. Les données contenues dans la base dépendront étroitement des
intentions qui auront été au principe de leur élaboration.
Nous examinerons tout d'abord quelques exemples qui nous aideront à
appréhender la difficulté de la conception d'un Système d'Information.
Nous vérifierons notamment un résultat fondamental de la Field
theory of information évoquée
à la page ??, selon lequel une base de données
construite pour observer et décrire un phénomène ne peut pas être
impunément utilisée pour en décrire un autre, même si l'intitulé des
données donne à penser qu'elles conviennent aux deux usages. Ce
résultat, qui sera illustré par des exemples simples que chacun pourra
vérifier, jette un doute sur la validité de projets tels que les
datawarehouses ou les SI décisionnels construits en puisant
directement les données dans les bases destinées à l'exploitation
quotidienne de l'entreprise. On pourra trouver une confirmation
a contrario de ce doute en consultant sur le site de Michel
Volle[119] une histoire de
datawarehouse qui a réussi ; on verra notamment que le prix de
cette réussite a été un effort considérable pour élaborer de nouvelles
données à partir des sources.
Inventaire et budget
Dans plusieurs organismes successifs, j'ai eu la responsabilité des
systèmes et des réseaux informatiques, et j'ai été confronté à la nécessité
d'avoir une idée la plus précise possible du parc de micro-ordinateurs,
imprimantes et autres réseaux locaux installés par les utilisateurs,
afin d'évaluer correctement la dimension des infrastructures à installer.
Le problème semblait minuscule et simple, et les gestionnaires du lieu
m'ont conseillé d'explorer pour ce faire le fichier des immobilisations
où étaient enregistrés tous les matériels acquis par l'organisme et
suffisamment onéreux pour avoir le statut d'investissement.
La méthode ainsi suggérée soulève dès l'abord une objection de fond :
un inventaire des immobilisations omet, par définition, tous les
matériels loués ou achetés en crédit-bail, que la comptabilité connaît
sous la rubrique « Travaux, fournitures et services extérieurs »,
très éloignée des investissements, de telle sorte que le rapprochement
et la mise en cohérence de ces deux sources d'informations est
pratiquement impossible. Sans aller plus loin, on voit déjà que le
responsable informatique, à la recherche de données relatives aux
objets physiques de son domaine, trouvera difficilement ce qu'il cherche
dans les informations de gestion.
L'enregistrement des immobilisations est une obligation légale, mais
les données ainsi collectées sont rarement exploitées. Des données
inexploitées ne stimulent pas la mise au point de bonnes procédures de
collecte : partout où j'ai eu l'occasion de les examiner, les données
relatives aux immobilisations étaient de très mauvaise qualité. Les
montants étaient à peu près exacts, mais les intitulés censés décrire
les objets acquis étaient totalement inexploitables, rédigés par des
personnes qui n'avaient pas la moindre idée de ce dont il s'agissait
ni de comment se rapprocher d'une nomenclature systématique. De toutes
les façons, les utilisateurs s'étaient ingéniés à acheter des
matériels parfois importants en mettant à contribution les sources de
financement les plus variées, dont certaines n'entraînaient aucune
inscription dans les livres de l'organisme. Les matériels acquis avec
l'argent de contrats de recherche divers et variés n'étaient même pas
la propriété de l'entreprise, mais il me fallait néanmoins les
raccorder au réseau, et donc les connaître. Bref, l'exploitation des
bases de données opérationnelles ne donnait aucun espoir d'obtenir une
idée même approximative du parc installé, alors que le nom des données
en laissait espérer une description exacte.
Dans un des organismes en question, j'ai procédé par enquête, avec un
questionnaire distribué à l'ensemble des responsables de services
pour leur demander la liste des matériels installés dans leur secteur.
Je venais d'y prendre mes fonctions, ce qui me faisait bénéficier de
l'effet de surprise, et comme la construction d'un nouveau réseau
était à l'ordre du jour, le bruit s'est répandu que ceux qui ne
répondraient pas au questionnaire ne seraient pas raccordés. Ces deux
circonstances ont conféré à l'enquête un taux de réponse excellent,
qui a permis d'élaborer une estimation du parc installé dont
l'expérience ultérieure a montré qu'elle n'était pas trop mauvaise. On
peut noter que les informations recueillies, parfaitement adaptées à
l'objectif poursuivi, ne pouvaient être d'aucune utilité aux
comptables chargés de gérer les immobilisations. Par la suite, des
enquêtes analogues ont été lancées pour mettre à jour les données de
la première, mais le stratagème avait été éventé, et les taux de
réponse ont été si faibles que les résultats étaient à peu près
inexploitables. Je vérifiais ainsi une règle de base du métier de
collecteur de données : l'information est une denrée qui s'échange,
les gens que l'on interroge ne vous répondent utilement que s'ils y
voient un intérêt, et un ordre de répondre émis par la hiérarchie ne
fait que diminuer la qualité des réponses.
Je retiendrai de ces expériences convergentes qu'essayer d'utiliser pour
les besoins de la gestion technique une base de données constituée pour
les besoins de la conformité aux règles comptables était voué à un échec
total malgré l'identité nominale des données utiles aux deux usages.
Une autre petite expérience que chacun a pu faire : je devais gérer le
budget de mon service et donc veiller à ne pas émettre de commandes
qui en excèdent le solde. En principe le service comptable de
l'entreprise est là pour résoudre ce genre de problème, mais entre
l'instant où une commande est émise, celui où la somme correspondante
est débitée, et plus encore celui où cette information parvient à
l'acheteur, court un délai qui peut être long, phénomène dit de la
différence entre comptabilité de trésorerie et comptabilité au fait
générateur. En principe la commande est enregistrée au stade de
l'émission pour les besoins de la gestion de trésorerie, mais cette
information n'est pas forcément accessible au service acheteur
(inutile de dire que dans les administrations publiques on n'a même
pas conscience de l'existence de la question). Les systèmes de
commande en ligne résolvent en partie ce problème, mais jusqu'à une
date récente chacun devait tenir sa petite comptabilité parallèle pour
éviter les dépassements fâcheux.
Enquête statistique, SI géographique
L'INSEE organise des Enquêtes Annuelles d'Entreprises (EAE) qui
sont une des bases de l'étude de l'activité économique en France. La
nature de l'enquête est adaptée aux différents secteurs de l'industrie
et des services. J'ai eu la chance il y a quelques années de
participer à la refonte de l'EAE Bâtiment - Travaux Publics, une
expérience extrêmement instructive1.
Incidemment, le maître d'oeuvre de cette EAE particulière était à
l'époque la Division Statistique du Ministère de l'Équipement.
Il fallait élaborer un questionnaire qui satisfasse à trois conditions :
-
il devait procurer les informations attendues par les organisateurs
de l'enquête ;
- la réponse aux questions devait ne pas poser de problèmes insolubles
aux entreprises interrogées ;
- l'organisation générale de l'enquête devait se faire en collaboration
avec les deux syndicats professionnels, la Fédération Nationale du
Bâtiment et celle des Travaux Publics.
Le Bâtiment et les Travaux Publics sont des activités assez différentes.
Il y avait à cette époque 230 000 entreprises de bâtiment, dont 210 000
entreprises d'une seule personne, cependant que les 15 000 entreprises
de travaux publics étaient en moyenne beaucoup plus importantes.
Demander à une très petite entreprise de remplir un questionnaire
statistique est délicat : il ne faut poser qu'un minimum de questions,
pour lesquelles l'élaboration de la réponse ne demande pas des heures
de travail, c'est-à-dire que les chiffres à fournir doivent figurer
tels quels dans les livres comptables de l'entreprise interrogée. Nous
voulions connaître les effectifs, la masse salariale, le chiffre
d'affaires, choses assez simples, mais aussi les investissements, ce
qui est une notion déjà beaucoup plus complexe, notamment du fait des
amortissements et des éventuels dégrèvements fiscaux ou subventions
qui l'accompagnent. Il fallait aussi des renseignements qualitatifs
sur les gros matériels. Cela m'a donné l'occasion d'une lecture
attentive du plan comptable de la branche, et d'une augmentation
significative de ma compétence (livresque) en matière de bulldozers
et de sonnettes à vapeur.
Mais la principale surprise me fut procurée par les négociations avec
les syndicats professionnels. Nous avons eu l'honneur d'être reçus par
le Président de la Fédération Nationale du Bâtiment : en fait ce
monsieur assez important ne demandait pas mieux que de donner sa
bénédiction à notre enquête, il suffisait de lui demander --- et de
faire passer l'administration du questionnaire par ses services, ce
qui avait l'avantage pour nous qu'il parviendrait aux entreprises
interrogées sous le sceau de leur syndicat, et pour le syndicat de lui
donner la primeur des résultats bruts. Finalement tout s'est déroulé à
la satisfaction générale, mais il est clair que l'omission d'une seule
de ces étapes diplomatiques aurait suffi à liquider radicalement la
qualité de l'enquête pour plusieurs années.
De cette expérience de construction d'un système d'information --- en
effet qu'est-ce qu'une enquête statistique, sinon un SI ? --- nous
avons retenu que pour obtenir l'accès aux données de base, et pour en
extraire de quoi fabriquer l'information que nous voulions, il nous a
fallu d'une part nous livrer à une étude très spécifique de l'univers
particulier que nous nous proposions d'explorer, d'autre part mener
des négociations somme toute agréables bien qu'assez serrées avec les
membres de cet univers.
Lorsque les instituts de statistique publics traversent des saisons
d'étiage budgétaire, ils n'ont plus les moyens d'organiser toutes les
enquêtes qu'ils souhaiteraient, et ils se rabattent sur l'exploitation
des données administratives. Parfois cela donne des résultats exploitables,
mais si cette pratique est peu prisée c'est bien parce que la plupart du
temps les données extraites des bases administratives ne satisfont pas
aux impératifs de la statistique.
Prenons un dernier exemple dans le domaine des systèmes d'informations
géographiques. La question fut posée un jour d'une possible synergie
entre le service du cadastre, qui fait des cartes à grande échelle à
des fins surtout fiscales et notariales, et l'Institut Géographique
National, qui fait des cartes topographiques à grande échelle pour les
militaires et les randonneurs ; la réponse fut évidente, mais
imprévisible pour le profane : le cadastre est confronté à une
exigence de conservation des surfaces, cependant que pour l'IGN c'est
la conservation des distances qui est importante, de ce fait le
cadastre et l'IGN utilisent des méthodes cartographiques fondées sur
des projections différentes et parfaitement incompatibles. Les données
de l'un ne seraient d'aucun secours pour l'autre.
Développement de logiciel statistique
Revenons sur le cas du logiciel statistique dont nous avons évoqué le
développement à la page ??. Pourquoi les experts
de l'INSEE, assistés par d'excellents ingénieurs d'une société de
services réputée, n'ont-ils pas réussi à construire un logiciel aussi
abouti que SAS (Statistical Analysis
System), par exemple ?
SAS, de SAS Institute[94], est
aujourd'hui et depuis près de trente ans le logiciel préféré des
statisticiens, qui ne trouvent guère à lui reprocher que son coût
élevé. Vu d'un oeil d'informaticien il y aurait bien des choses à
lui reprocher, notamment la lourdeur de sa syntaxe et de sa gestion de
données, son caractère fermé, etc. --- rien n'y fait, les
statisticiens l'adorent. On observe ici un phénomène assez courant
dans les usages de l'informatique : imposer à l'utilisateur un
apprentissage long et pénible peut conduire le logiciel à l'échec,
mais si cet écueil a été évité et si pour quelque autre concours de
facteurs positifs le système a réussi à convaincre une masse critique
d'utilisateurs enthousiastes, la difficulté même de l'apprentissage
renforce l'adhésion de ceux qui l'ont subi, qui semblent ne pas
vouloir abandonner les fruits d'une compétence si chèrement acquise.
Il entre aussi sans doute dans cet adhésion une part de fierté à être
admis dans une société d'initiés. SAS a de toute évidence réussi à
déclencher ce phénomène, dont un autre exemple est le langage de
programmation C, à la syntaxe particulièrement torturée.
SAS a été à ses débuts l'oeuvre de quelques enseignants et
chercheurs de l'université d'État de Caroline du Nord, au nombre
desquels l'actuel PDG de SAS Institute James Goodnight, qui avaient
conçu ce logiciel pour leurs propres besoins. La société fut créée en
1976 et établit presque aussitôt un partenariat avec IBM. Il convient
de souligner que le marché des logiciels statistiques n'était pas
vierge, mais l'intégration de SAS aux systèmes IBM et son interface
interactive ont contribué à un succès rapide. Le système se présente
comme un interpréteur de commandes : l'utilisateur tape une expression
du langage d'interrogation, le système donne la réponse. Ce n'est pas
forcément idéal pour des travaux complexes avec de gros volumes de
données, mais l'effet de séduction initiale est garanti --- et en 1976
c'était inhabituel.
Parmi les éléments qui ont assuré le succès continu de SAS depuis
1976, nous citerons la qualité statistique du système : chaque fois
que j'ai eu l'occasion de le vérifier moi-même ou de recueillir l'avis
de spécialistes de domaines particuliers des statistiques, j'ai
constaté que SAS offrait la gamme complète des meilleurs algorithmes
programmés de façon impeccable. Cette qualité reconnue donne au
logiciel un statut envié auprès des revues scientifiques, dont les
referees acceptent sans vérification les résultats des calculs
dès lors que ceux-ci ont été effectués avec SAS. Autre qualité du logiciel,
l'utilisateur peut étendre ses possibilités en lui ajoutant des
fonctions qu'il programme lui-même, ce qui est de première importance
pour des chercheurs, qui par définition ne sauraient se satisfaire des
analyses standard. SAS Institute sait maintenir avec ses clients un
contact étroit et attentif, notamment au travers de clubs
d'utilisateurs très dynamiques, ce qui lui a permis de s'adapter
parfaitement aux évolutions du marché --- ainsi on chercherait en vain
sur la page d'accueil de leur site WWW le mot « statistique », et c'est
plutôt l'analyse financière qui y est en vedette. Enfin SAS Institute
n'est pas une société par actions, ce qui lui permet d'échapper aux
exigences d'actionnaires et de maintenir un budget de recherche et
de développement particulièrement élevé, plus de 25% d'un chiffre
d'affaires qui s'élevait en 2003 à 1,34 milliard de dollars.
Revenons à la question posée au début de cette section : pourquoi les
développements de l'INSEE ont-ils abouti à un succès moindre que celui de
SAS ? Si l'on compare les moyens mis en oeuvre, il ne fait aucun
doute que les effectifs d'experts en statistiques et d'ingénieurs en
informatique de l'INSEE étaient supérieurs à ceux de l'université d'État
de Caroline du Nord, et l'équipe du projet logiciel de l'INSEE
comptait dix personnes alors que SAS Institute avait sept employés en 1976.
Il est sans doute injuste de formuler la question en ces termes :
après tout, dans le domaine du logiciel comme dans bien d'autres,
toutes les tentatives ne peuvent pas aboutir au même succès, et
l'équipe de l'université d'état de Caroline du Nord comportait sans
doute des personnages particulièrement compétents, dotés d'une vision
aiguë de l'avenir à moyen terme des usages de l'informatique et des
moyens techniques de les satisfaire. L'aide d'IBM pourrait bien avoir
été décisive. Observons cependant que SAS a été développé initialement par
des experts pour leur propre usage, tandis que le logiciel de l'INSEE
a fait l'objet d'un cahier des charges rédigé par une équipe non
dépourvue de compétences, mais orientée vers l'obtention de gains de
productivité par des méthodes tayloriennes.
D'autre part, le cahier des charges était très conditionné par les
pratiques en cours à l'INSEE pour le dépouillement d'enquêtes
statistiques, qui étaient soumises à des contraintes particulières.
L'enquête par excellence, qui constituait et constitue toujours la
mission centrale de l'INSEE, c'était le recensement de la population,
qui comportait (cela va changer) un enregistrement par habitant du
pays et un enregistrement par logement, soit 90 millions
d'enregistrements. À l'époque dont nous parlons il était inimaginable
de placer cet énorme volume de données sur disque, et le traitement
était effectué à partir de fichiers sur bandes magnétiques. Les
stipulations techniques du cahier des charges étaient donc très
orientées vers des traitements par lots de fichiers séquentiels,
méthode de travail qui était imposée par les circonstances mais qui ne
répondait pas à tous les besoins. Le logiciel était assez bien adapté
à l'obtention de tableaux de base à partir de données brutes, mais
les chercheurs de l'INSEE qui devaient ensuite réaliser des analyses
plus fines ne disposaient ni de méthodes modernes et appropriées de
gestion des données, ni de méthodes statistiques perfectionnées, ni de
moyens d'étendre le logiciel par l'ajout de fonctions à leur
convenance. Ils eurent donc tendance à utiliser plutôt SAS.
Passage à l'Euro
Mon employeur me confia un beau jour de juillet 2001 le pilotage du
passage à l'Euro de ses applications financières et comptables.
J'étais depuis deux mois dans la maison, la transition devait être
achevée pour le 1er janvier 2002, sans report possible puisque
c'était la date limite fixée par la loi, et le chef du projet Euro
venait de donner sa démission. Je dois dire que cette situation était
un peu inquiétante.
Le projet Euro avait été mené selon toutes les règles de l'art, et
donc un serveur de fichiers consacré au projet abritait des dizaines
de documents, représentant au total quelques milliers de page. Je
plongeai fébrilement dans cette masse de documentation : la récolte
que je pus en tirer fut conforme aux règles de l'art des projets,
c'est-à-dire que ces documents formels et verbeux étaient conformes
aux normes mais d'une vacuité inquiétante en termes d'information
réelle, ils ne contenaient à peu près aucune indication ni sur la
situation de départ, ni sur ce qu'il convenait de faire. J'y trouvai
quand même quelques généralités relatives aux règles comptables de
passage à l'Euro, qui tenaient en une dizaine de lignes soigneusement
recopiées sur des dizaines de documents, et une liste à peu près complète
des applications concernées.
J'étais épaulé par un prestataire extérieur, chargé d'assistance à la
maîtrise d'ouvrage, et par un planificateur, dont les avis
convergèrent : il fallait recenser toutes les applications
potentiellement concernées par le passage du franc à l'Euro, dresser
un tableau où elles figureraient en ligne et en colonne, chaque case
correspondrait ainsi à une interférence possible entre deux
applications ; on pourrait faire abstraction des cases de la
diagonale, et ne considérer qu'un des triangles déterminés par cette
diagonale en admettant que les interactions entre l'application A et
l'application B étaient les mêmes que celles entre B et A. Nous
recensâmes vingt applications, ce qui donnait un tableau de 400 cases,
ramené par les simplifications évoquées ci-dessus à 180 cases utiles.
Examiner ces 180 cas et résoudre les problèmes soulevés avant le
1er janvier 2002, même en y passant les nuits et les week-ends,
semblait une mission impossible. Évidemment, cela aurait pu aussi
représenter un contrat attrayant pour un prestataire de services...
Cet objectif n'était hors d'atteinte que parce que la méthode proposée
par le chargé d'assistance à la maîtrise d'ouvrage et par le
planificateur était adaptée à un ordinateur, mais pas du tout à des
humains. De toute façon la démarche proposée était non seulement
irréalisable, mais en outre peu judicieuse ; il fallait faire autrement.
Quelques entretiens avec le directeur du système d'information, fin
connaisseur des circuits de données et des habitudes informelles de la
maison, m'apprirent quelles étaient les applications vitales, ainsi
que les dates réelles auxquelles des résultats seraient exigibles.
Ainsi telle application était en fait trimestrielle, ce qui laissait
jusqu'au 15 mars pour régler son cas ; telle autre ne concernait qu'un
fichier de quelques dizaines d'entrées, en cas de malheur on pourrait
toujours s'en sortir avec un tableur. Par contre il fallait bien
entendu traiter sans faute la paie, le budget, les commandes, puis ne
pas trop tarder pour le règlement des fournisseurs.
Cette démarche empirique mais informée à la meilleure source réduisait
le nombre d'applications concernées à cinq, mais surtout les interférences
réelles à quatre ou cinq, de surcroît très simplifiées dès qu'elles
avaient été expliquées par le directeur du système d'information, qui
connaissait leur nature, ce qui évitait d'avoir à explorer toutes sortes
de cas qui ne se produiraient jamais.
Une fois les problèmes identifiés, je pris contact avec les auteurs ou
les responsables de maintenance des programmes concernés, qui par
chance étaient encore présents dans la maison, et qui se montrèrent
compétents, coopératifs et efficaces. Je dois dire notamment qu'ils
connaissaient bien mieux les aspects règlementaires du passage à
l'Euro que les gens dont c'était théoriquement la fonction, et qui
furent dans cette affaire d'une tranquillité impressionnante. Le
passage du Franc à l'Euro posait notamment une question
incontournable, la nécessité de choisir entre trois méthodes possibles
de conversion à l'Euro des bases de données et des applications :
-
-
Première méthode : conversion uniquement au niveau le plus fin.
On remonte dans la base de données en respectant les règles de
celle-ci. En d'autres termes, on convertit les lignes détail des
écritures et on refait les calculs pour obtenir la nouvelle valeur
des lignes total.
- Avantages : Respecte la logique de la base de données.
- Inconvénients : Les écarts de conversion même s'ils sont faibles
peuvent engendrer des incompréhensions pour les utilisateurs (non
respect de la cohérence des montants en francs et en euros).
-
Deuxième méthode : conversion directe de tous les montants de la
base de données (lignes détail comme total).
- Avantages : respecte la cohérence entre les montants en francs et
en euros.
- Inconvénients : ne respecte pas la logique de la base de données.
La nouvelle valeur d'une ligne total ne sera pas toujours égale à
la somme des valeurs des lignes détail.
-
Troisième méthode : conversion directe de tous les montants de
la base de données. Création d'une ligne de détail supplémentaire
pour l'écart de conversion.
- Avantages : respecte la cohérence entre les montants en francs et
en euros et la logique de la base de données.
- Inconvénients : suivant les caractéristiques de l'application peut
être très lourde à mettre en place voire impossible.
Nous attendîmes en vain que les responsables officiels nous indiquent
quelle solution choisir. Finalement nous (les informaticiens) eûmes à
décider nous-mêmes, ce qui ne semble pas une procédure normale.
Bref tout se passa sans encombre, parce que la méthode canonique fut
évitée, et grâce au savoir concret de gens qui connaissaient bien le
terrain et les programmes. Le modèle aujourd'hui standard du chef de
projet parfaitement incompétent mais qui suit des procédures en béton,
illustré par le chef du projet Euro qui avait prudemment démissionné
au moment fatidique, aurait mené droit à la catastrophe. Cette expérience
plaide aussi pour l'acquisition et la conservation de compétences internes.
Annuaire électronique
J'ai eu un jour à lancer et à réaliser un projet d'annuaire
électronique dans un grand organisme de recherche scientifique. Il
apparut assez vite que ce type de projet était notablement plus
complexe qu'il n'y paraît lorsque l'on n'a pas essayé.
Constituer un annuaire papier, donc statique, d'une population donnée
consiste à effectuer à un instant donné un recensement exhaustif des
individus de cette population et de leurs caractéristiques qui doivent
figurer dans l'annuaire, telles qu'adresse, numéro de téléphone, etc.
Pour constituer un annuaire électronique qui présente des avantages
significatifs par rapport à un annuaire papier, il faut créer une base
de données qui contienne les données déjà évoquées ci-dessus, et
surtout mettre en place des processus d'alimentation et de mise à jour
de cette base avec pour objectifs les qualités suivantes : pertinence,
actualité, fiabilité, exhaustivité, disponibilité. Concevoir ces
processus d'alimentation de l'annuaire demande d'avoir identifié les
sources adéquates de données.
La réponse naïve à cette question, qui me fut donnée par quelques
aspirants-prestataires, va de soi : « Eh bien, vous prenez votre
fichier de personnel, une extraction, et voilà ! » C'était simplement
oublier qu'un organisme de recherche réunit bien d'autres individus
que ses propres personnels, lesquels ne représentent qu'une petite
moitié des quelques milliers de personnes actives dans l'institution.
Pour écarter d'autres idées simplistes, qu'il suffise de dire que
lesdits personnels sont dispersés sur quelques dizaines de sites dotés
chacun de ses propres règles de gestion administrative et technique.
Il fallait chercher autre chose.
Une enquête auprès de collègues expérimentés m'apprit qu'il existait
environ 130 fichiers de personnel dans la maison, exhaustifs
ou partiels. De quoi faire dresser les cheveux sur la tête d'un
concepteur de système d'information ! Il est plus que probable que
l'existence de bases de données de bonne qualité facilement accessibles
serait de nature à faire disparaître beaucoup de ces fichiers d'intérêt
local, constitués pour résoudre un problème ponctuel et pas forcément
toujours de très bonne qualité. Mais il ne ferait pas passer le nombre
de fichiers de personnel de 130 à 1 !
Une visite aux détenteurs de quelques-uns des 130 fichiers a révélé
un certain nombre de fichiers redondants, morts ou indigents, mais
aussi des fichiers bien vivants qui avaient de bonnes raisons de
continuer à mener une existence distincte. Parmi les bonnes raisons,
la plupart ont trait à des exigences temporelles quant à la
disponibilité des données. Ainsi, lorsqu'un nouveau salarié prend
ses fonctions le premier jour du mois, le degré d'urgence de son
inscription dans les fichiers du personnel est déterminé par
l'objectif de lui verser sa rémunération, c'est-à-dire que cette
inscription doit avoir lieu au plus tard entre le 15 et le 20 du mois.
Mais pour qu'il puisse effectivement commencer à travailler il faut
lui ouvrir un compte de messagerie électronique bien avant cette date,
et, pour ce faire, l'enregistrer dans les bases de données
correspondantes. Il serait également souhaitable qu'il soit dans
l'annuaire téléphonique. Bref, les auteurs et les utilisateurs de ces
fichiers ont des impératifs différents, sans même aborder la délicate
question de la confidentialité des données et du secret
professionnel. Les supprimer au profit d'une base de données unique
n'irait sûrement pas sans poser de difficiles problèmes.
Il existe dans cet organisme une base d'informations sur les
recherches, qui contient des entrées pour chaque formation de
recherche (unité, laboratoire, équipe, etc.) et pour chaque chercheur,
ingénieur ou technicien. Chaque entrée comporte des informations
factuelles (adresse, nom de l'entité, liste du personnel, liste de
publications...) ou descriptives (résumé des recherches en cours).
Lorsque les formations de recherche rédigent leur demande budgétaire
annuelle, celle-ci n'est validée que si la base de données est mise à
jour ; de plus, le budget attribué croît avec les effectifs
enregistrés dans la base, ce qui incite à ne pas oublier de
personnels. Ce dispositif bureaucratique garantit une bonne mise à
jour une fois par an, ce qui n'est déjà pas si mal. Il est question de
modifier cette règle, justement parce qu'elle est bureaucratique (ô
combien : les unités de recherche doivent remplir chaque année 22
formulaires pour mettre à jour cette base !), ce qui sera une bonne
idée mais ne fera pas les affaires de notre projet d'annuaire. Il est
clair que, lorsque la mise à jour de la base ne sera plus un événement
déclencheur de financement, les formations de recherche seront moins
enclines à veiller à son exactitude (on les comprend).
Cela dit, la base d'informations sur les recherches nous semblait
la meilleure source de données pour notre annuaire, malgré plusieurs
faiblesses :
-
elle n'était mise à jour qu'une fois par an ;
- son développement avait été confié à un prestataire extérieur
dont l'activité avait été peu contrôlée, de ce fait le Modèle
Conceptuel de Données de la base avait dérivé vers un état peu
connaissable ;
- le schéma de la base s'était dégradé, sa structure opacifiée ;
- les identifiants de certaines tables étaient de mauvaise qualité ;
- la base avait été maintenue dans un état relativement bon par la
personne qui l'avait conçue et créée, mais cette personne était
partie à la retraite, et dans ce genre de situation la succession
est toujours, disons, difficile.
Que le lecteur ne se laisse pas abuser par l'apparence anecdotique de
cette liste de défauts : toute base de données est bien réellement
exposée à ces risques précisément.
Nos dernières illusions s'envolèrent lorsque nous décidâmes de quitter
le havre de la Direction Générale pour visiter des sites opérationnels
en province ou en région parisienne. Les personnes chargées
d'alimenter les bases en données recueillies sur le terrain nous
expliquèrent avec ménagement mais franchise les procédures suivies.
Les fichiers dont le contenu avait une incidence financière ou en
termes de personnel étaient mis à jour sérieusement, mais uniquement
pour les données qui avaient une telle incidence. D'autres fichiers à
usage purement bureaucratique (ou perçu comme tel), et dont les
procédures de mise à jour étaient de surcroît particulièrement
pénibles, étaient beaucoup moins bien traités --- en général on se
contentait de renvoyer la version de l'année précédente et personne ne
s'apercevait de rien.
Bref, nous avions rêvé d'un système d'information où il nous aurait
suffi de voleter de base de données en base de données pour y butiner
les données utiles à notre projet : il se révélait que nous avions à
construire les données dont nous avions besoin, et que la
réutilisation de données existantes n'était pas un avantage mais bien
plutôt une contrainte, imposée par le souci de cohérence mais assortie
d'un coût élevé induit par leur mauvaise qualité et, paradoxalement,
par leur incohérence, qu'un avantage.
Je ne crois pas que la situation décrite ci-dessus corresponde à un
cas particulièrement défavorable : je pense au contraire que tous les
univers de données réels sont peu ou prou conformes à cette
description. Les données sont bonnes si elles ont une bonne raison de
l'être, et elles sont bonnes à l'usage pour lequel elles ont été
construites. Si on veut en faire autre chose, il faut
les ré-élaborer entièrement. On pourra se reporter utilement à
l'« Histoire d'un tableau de bord » narrée par Michel
Volle[115] ; à partir de données de gestion il s'agit
de créer un tableau de bord pour la direction d'une grande entreprise ;
ce ne sera rien de pharaonique, juste une sélection de séries
temporelles soumises à des traitements statistiques classiques de
correction des variations saisonnières et d'extrapolation de tendance ;
l'objectif a été atteint, mais les données n'étaient pas juste là,
prêtes à servir, comme le lecteur pourra s'en rendre compte en lisant
l'article. Dans le même ordre d'idées on pourra aussi consulter un
article consacré à la réalisation, dans le même contexte, d'un
datawarehouse[119], c'est-à-dire d'un système
informatique d'aide à la décision dans le domaine commercial à partir
des données opérationnelles : le système d'extraction et d'adaptation
des données est une véritable usine informatique qui a coûté 25
millions d'Euros.
Informatique de gestion manuelle
Au tout début des années 1990, j'ai été amené à contribuer au
renouvellement de l'informatique de gestion d'un grand établissement
d'enseignement supérieur. Il s'agissait d'organiser le renouvellement
complet du système, matériel et logiciel. À cette occasion je me suis
penché sur le fonctionnement informatique du système de paie, qui
s'est révélé assez curieux : il existait un logiciel de paie, ainsi
qu'un fichier des personnels devant recevoir une rémunération.
Chaque mois ce programme était lancé, et il produisait les quelques
centaines de bulletins de salaire qui correspondaient aux personnes
qui avaient travaillé ce mois-là. Mais ces bulletins étaient pour la
plupart lourdement erronés. En fait ils ne servaient que de masques de
saisie pour une dame du service de paie qui possédait la mémoire et
les arcanes de la paie de chaque agent. Elle corrigeait tous les
bulletins à la main, et lançait l'impression des vrais bulletins de
salaire. Personne n'avait jamais réussi à paramétrer correctement le
logiciel, et le traitement était en fait manuel. Cette dame prenait
ses vacances en août, mois pour lequel on rejouait la paie de juillet,
quitte à régulariser en septembre les différences qui auraient dû
apparaître entre juillet et août.
Ce secret était bien caché, et sa découverte m'a valu l'inimitié de la
dame. L'avantage d'une paie manuelle, c'est qu'elle est facile à
personnaliser : mon salaire du mois suivant fut de 45 francs et
quelques centimes. Mais je suis convaincu que cette pratique (la paie
manuelle, pas le salaire de 45 francs) est plus répandue qu'on ne le
pense. Lorsque, pour tel système de gestion financière et comptable,
des prestataires font intervenir des dizaines de consultants pendant
des mois pour des « réfections de bases de données », de quoi
s'agit-il en réalité, sinon de passer des écritures comptables à la
main ? Cela ne révèle-t-il pas un dysfonctionnement grave du système ?
2 Terminologie, thésaurus, « ontologie »
L'enthousiasme engendré par une percée intellectuelle telle que le
modèle objet (par exemple) peut susciter une tendance à en surestimer
la portée, à en prendre les auteurs pour des démiurges2. La propension à verser
dans cette erreur résulte souvent d'une mauvaise perception de la
complexité des rapports entre les mots inventés par les humains et les
choses dans la réalité : des naïfs peuvent croire que ces rapports
seraient en fait une relation isomorphe, c'est-à-dire qu'à chaque mot
correspondrait une chose dans le monde réel, et que la structure des
relations entre les mots refléterait simplement celle des relations
entre les choses réelles. Nous allons très brièvement et très
sommairement expliquer ici pourquoi le point de vue qui considère le
monde des significations comme un simple reflet du monde réel nous
semble faux, puis envisager quelques occurrences de cette erreur dans
le monde des Systèmes d'Information. Nous renvoyons le lecteur qui
voudrait prendre connaissance d'une véritable analyse philosophique de
la question à la lecture, par exemple, d'un livre de Karl
Popper[86] qui lui consacre des
développements détaillés et approfondis. Roger
Penrose[84] donne aussi des
arguments contre la thèse de l'isomorphisme entre les mots et les
choses. Nous avons d'ailleurs déjà rencontré à la section
5 un point de vue de ce genre (la « théorie TDQM
»), et sa réfutation par
Isabelle Boydens[17].
Pour parler du monde qui nous entoure, nous employons un langage fait
de signes, et nous avons appris à interpréter ces signes de telle
sorte que nous pouvons grâce à eux échanger avec nos congénères
quelques informations qui éventuellement pourront nous renseigner (ou
nous induire en erreur) sur certains aspects de certains objets du
monde réel. Des propos de notre interlocuteur, inférer ce qu'il a
voulu nous dire, ce qu'il « avait derrière la tête » et qu'il voulait
nous communiquer, est déjà un exercice où le risque d'erreur (de
malentendu) est important ; pour comprendre ces propos, nous devons
posséder toutes sortes de compétences relatives au contexte dans
lequel a lieu l'échange de signes et à la nature particulière de cet
interlocuteur et de nos relations avec lui. Alors a fortiori
entre les signes du langage qu'il aura employés et un objet, ou un
état, ou un événement du monde réel, la distance laissée à
l'interprétation est considérable, et c'est là tout le problème de la
représentation, qui n'a pas une réputation de facilité. Croire
dans ces conditions qu'un langage humain (tel que le français ou le
bambara, au hasard) puisse rendre compte « exactement et naturellement »
ne serait-ce que d'une partie infime de l'univers, ce n'est pas
seulement nourrir une illusion, c'est se méprendre sur la nature même
du langage, du monde et de leurs rapports. N'oublions pas que « le
langage travestit la pensée. Et notamment de telle sorte que d'après
la forme extérieure du vêtement l'on ne peut conclure à la forme de la
pensée travestie; pour la raison que la forme extérieure du vêtement
vise à tout autre chose qu'à permettre de reconnaître la forme du
corps[126] ».
Victor Klemperer, philologue allemand qui a
miraculeusement échappé au génocide, a consacré à la langue nazie un
livre[58] où il écrit (page 35 de l'édition française
Pocket) : « On cite toujours cette phrase de Talleyrand, selon
laquelle la langue serait là pour dissimuler les pensées du
diplomate... Mais c'est exactement le contraire qui est vrai. Ce que
quelqu'un veut délibérément dissimuler, aux autres ou à soi-même, et
aussi ce qu'il porte en lui inconsciemment, la langue le met au jour ».
Ce passage, loin de contredire la citation précédente de Wittgenstein,
la complète et en achève le sens, qui réfute le réductionnisme
linguistique : comment, si le langage travestit le propos du locuteur
et si sa langue révèle ce qu'il dissimule, peut-on espérer établir
une correspondance isomorphe entre discours et réalité ?
Outre les difficultés liées à la labilité des langues humaines et à leur
interprétation, il en est une autre qui s'oppose absolument au projet
de décrire de façon exacte et complète une partie de la réalité, et
William Kent[57] a attiré notre
attention sur elle : « Il nous est impossible de tracer un cercle
imaginaire autour d'un certain corpus d'information et de déclarer
qu'il contient tout ce que nous savons au sujet d'une certaine chose,
et que tout ce qui est contenu dans le cercle a trait uniquement à
cette chose, et donc que cette information ``représente'' la chose. »
Les inepties autour de l'aptitude supposée du modèle objet à mettre en
correspondance les objets du monde, ceux de la pensée et ceux du
langage ne sont que cuistrerie vénielle et hybris modérée à côté des
exactions de la branche de la psychologie cognitive qui élabore de
soi-disant ontologies.
De longue date les spécialistes de la documentation élaborent des
thésaurus, qui sont des vocabulaires contrôlés, normalisés et
commentés. Leur utilité est grande pour indexer articles et documents :
si chaque auteur donne pour son article les mots-clés qui lui
passent par la tête avec des acceptions de son cru, les recherches
documentaires risquent de devenir difficiles et peu fructueuses.
Disposer d'un thésaurus qui explique quel mot utiliser dans quelle
circonstance, et qui en donne les équivalents dans différentes
langues, est éminemment précieux, même si le rêve d'un thésaurus
complet et parfait est inaccessible, ne serait-ce qu'à cause des
évolutions incessantes tant des sciences que des langues.
La démographie dispose ainsi du thésaurus POPIN, la biologie de
MeSH. Tout ce que nous avons dit nous incite à la prudence à
leur égard : de tels thésaurus ne sont utilisables que dans le cadre
limité pour lequel ils ont été conçus, c'est-à-dire indexer des
articles scientifiques. Et un thésaurus multilingue ne saurait
prétendre abolir toutes les différences subtiles qui existent entre
les langues et remplacer les dictionnaires linguistiques qui, pour
chaque entrée, peuvent donner de nombreuses traductions. Il se trouve
par exemple qu'en français le mot grue peut désigner un oiseau
ou un appareil de levage. Le mot anglais crane possède les deux
mêmes acceptions, ainsi d'ailleurs que son équivalent allemand
Kran. Mais en français le mot chemise peut désigner
soit un vêtement, soit une pièce de moteur à pistons : or ni
l'anglais ni l'allemand ne possèdent ce couple d'acceptions pour un
même mot. Bref, selon que notre thésaurus sera ornithologique,
mécanique, vestimentaire ou de travaux publics, il n'aura pas la même
structure. Et encore ne s'agit-il ici que d'exemples simplissimes
pris dans des langues très voisines.
Les travaux issus de cette entreprise terminologique laborieuse et
méconnue mais utile à la science ont été détournés de leur objectif
par des cognitivistes qui se sont dit un peu vite que, puisque l'on
avait des mots, cela ferait bien l'affaire pour représenter des
concepts, et que dès lors que l'on disposait de concepts, pourquoi ne
pas les relier par des flèches qui matérialiseraient, par exemple, les
formules de la logique du premier ordre, avec ses prédicats qui
permettent le calcul logique. Les flèches seraient bien sûr
instanciées dans des bases de données informatiques par des pointeurs
ou des références, et l'on pourrait ainsi donner une structure
formelle de la science et distinguer les énoncés vrais des faux ---
rien de moins. Et tant qu'à faire, on appellerait cela une ontologie,
ou plutôt des ontologies, une par domaine scientifique, par
exemple.
Il y a là une confusion tout à fait dommageable entre les objets de la
linguistique, ceux de la logique et ceux de la métaphysique. Les
logiciens sérieux ont compris depuis longtemps que leur discipline
devait se doter de ses propres formalismes justement parce que les
langages humains étaient bien trop mobiles et fluides pour des
opérations formelles. Comment formuler des propositions sûres avec les
mots et les constructions grammaticales du langage humain, dès lors
(pour ne prendre qu'une objection entre cent) que telle langue va
exprimer telle signification par un procédé lexical, alors que telle
autre le fera par un procédé syntaxique ? Ainsi, le français dira
« j'ai oublié ma valise à la maison » là où le bambara dira « ma valise
est restée à la maison », et d'ailleurs le verbe bambara qui signifie
« oublier » n'admet que des compléments d'objet indirects, il n'existe
aucun moyen direct d'oublier quelque-chose. Les ambiguïtés du
langage humain ne sont d'ailleurs pas un simple problème de syntaxe,
ce sont les limites mêmes au traitement de l'information par l'esprit
humain. Dès la fin du XIXe siècle Gottlob
Frege[38] avait compris les
difficultés liées à l'usage du langage humain et avait entrepris
d'élaborer un système formel pour les démonstrations logiques. Il
suivait d'ailleurs en cela un chemin déjà ouvert par George
Boole (1815 -- 1864).
Certains cognitivistes contemporains semblent ne jamais avoir entendu
parler de ces travaux, ou alors ne pas en avoir compris la portée. Il
en résulte des confusions dramatiques, exprimées par exemple
ainsi[47] : « les terminologies ne peuvent plus se
contenter de recenser les termes et les organiser [sic] brièvement
sous forme d'une hiérarchie. Elles doivent également proposer toute
une gamme de relations qui reflètent au mieux les connaissances du
domaine et répondent de manière adaptée aux besoins des applications. »
On peut lire aussi, plus loin dans le même article qui fait une
recension de travaux marquants de ce domaine, à propos d'un système
formel à usage médical construit autour de la terminologie SNOMED :
« Les règles du système formel utilisent et explicitent les relations,
transversales ou non, qui peuvent exister entre les composants du
nouveau terme [construit par le système, nda] mais aussi entre le
nouveau terme et ses composants. Une règle de formation d'un
diagnostic par combinaison d'un terme signifiant une région du corps
(axe Topologie de la SNOMED) et d'un terme signifiant une pathologie
(axe Morphologie) est par exemple instanciée dans la combinaison de
termes élémentaires glande apocrine et inflammation
(pathologie). La nouvelle notion inflammation de la glande
apocrine, désignée également par le terme hidrosadénite,
est-une inflammation qui est localisé-dans la
glande apocrine. Cette règle très productive est également à
l'origine d'autres diagnostics... Le potentiel combinatoire des 5 880
termes de l'axe Morphologie de la SNOMED avec les 12 936 termes de
l'axe Topographie, permettrait de créer 76 millions de concepts... »
On croit rêver --- et on espère ne jamais tomber entre les mains de
médecins convertis à des systèmes formels de cet acabit. On remarque
aussi que les opérateurs du système, écrits dans une police de
caractères particulière, comme localisé-dans, en reçoivent
une aura informatique spéciale qui semble autoriser les fautes
d'orthographe.
François Rastier[91] a donné
une critique salubre de cette insondable cuistrerie, en passant en
revue un certain nombre de confusions et d'énormités repérées dans la
littérature des « ontologies ». Empruntons-lui ce rappel aux
définitions :
« L'ontologie se définit [...] comme la ``science de l'Être'' : elle reste
constitutivement métaphysique, car la métaphysique est la ``science de
l'Être en tant qu'Être''.
En revanche, le rôle des sciences reste précisément de rompre avec la
métaphysique en définissant et en structurant de façon critique et
réflexive des domaines d'objectivité. »
En nommant « ontologies » des nomenclatures terminologiques ou des
thésaurus, et en affirmant que les termes qui y figurent, arrangés
selon des principes qui feraient recaler à ses examens tout étudiant en
linguistique, sont ainsi érigés au rang de concepts, ces cognitivistes
balayent d'un revers de la main vingt-cinq siècles de pensée
philosophique et deux siècles de linguistique pour ne nous donner
en échange qu'un positivisme caricatural.
L'encre des paragraphes précédents à peine sèche, il convient de
préciser ceci : il existe quelques logiciels parfaitement raisonnables,
et même recommandables, dont le seul défaut est de se prétendre
ontologiques. Il s'agit tout bonnement de carnets de notes
électroniques et hypertextuels, qui permettent de gérer et d'indexer
des données peu structurées, ce qui est utile, et l'informatique est
bien adaptée à un tel usage. Et bien sûr le slogan « ontologie » est
plus éclatant que « bloc-note électronique », il faut bien le
reconnaître. Se classent aussi dans cette catégorie des logiciels
capables de comparer des sites Web consacrés à des thèmes voisins et
d'établir entre eux des interliens vers des notions communes, c'est
utile et intéressant, mais appeler cela le « Web
sémantique » est pour le moins abusif : ici comme là, le péché véniel
d'enflure verbale finit par confiner à l'imposture intellectuelle,
ce qui est plus gênant.
Isabelle Boydens a écrit un livre (dérivé de
sa thèse)[17] où, entre autres analyses pénétrantes dont
nos chapitres précédents se sont déjà fait l'écho, elle traque dans
les bases de données et les systèmes d'information des erreurs du même ordre que celles que nous
évoquions quelques lignes plus haut. Elle y démonte des théories qui
laissent croire qu'entre les symboles d'un langage et les objets d'un
univers réel qu'il peuvent désigner il pourrait y avoir une
correspondance isomorphe, c'est-à-dire telle qu'à chaque symbole
corresponde sans ambiguïté un objet et un seul de cet univers, et que
l'univers puisse être totalement décrit par le langage. Ainsi munie
d'une armure à l'épreuve des syllogismes creux et des impostures
techno-scientifiques, elle entreprend une analyse du système
d'information de la sécurité sociale belge sur laquelle tout candidat
à la construction d'un SI administratif ou de gestion devrait se
pencher.
Nous croyons en avoir assez dit pour que le lecteur, surtout s'il a
pris soin de consulter les ouvrages que nous avons cités, soit
convaincu de l'impossibilité d'un isomorphisme entre quelque univers
réel que ce soit et un système d'information quel qu'il soit. Un SI
n'est par nature qu'une représentation, une abstraction qui ne retient
à propos de la réalité qu'elle représente que les informations qui
importent à l'objectif poursuivi, exprimées avec la précision
nécessaire, mais pas plus. Cette conclusion ne vise pas à abolir tout
espoir de construire un système d'information pertinent et utile, mais elle veut souligner les
difficultés de l'entreprise et fixer les bornes des ambitions qu'elle
pourra se donner.
- 1
- Merci à Jean-Michel
Agnus, qui dirigeait les opérations !
- 2
- La
tentation de se croire égal aux dieux, d'excéder ses limites, porte
le nom savant d'hybris ; nous avions eu l'occasion à la section
2 d'en signaler une occurrence, qui consistait à
imaginer que justement le modèle objet pouvait représenter
naturellement le monde réel. Nous avions dit que cette hypothèse
n'avait tout simplement aucun sens, parce que rien ne peut «
représenter naturellement le monde réel ».
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre