Précédent Remonter Suivant
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 : 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 :


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 : 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
Précédent Remonter Suivant