Précédent Remonter Suivant
Page d'accueil de ce livre

Chapitre 3  Normalisation et démarche qualité


1  Genèse de la démarche

Nous ne saurions clore le rapide panorama des méthodes de contrôle du travail dressé au chapitre précédent sans évoquer la démarche qualité, qui s'est répandue voici une décennie et qui répand aujourd'hui une certaine déception.

La démarche qualité, et l'idée de normalisation à laquelle elle est étroitement associée, sont nées dans le monde industriel au XXe siècle. Certes, le premier empereur chinois, Qin Shihuangdi (259-210 avant notre ère), avait déjà normalisé l'écartement des roues des chars (et prévu la peine de mort pour les contrevenants)1, et en 1732 Louis XV en fait autant pour le diamètre des canons, cependant que la réorganisation des fabrications pour la marine de Louis XIV en 1689 peut être considérée comme un plan qualité précurseur. Le système métrique (1795) fut aussi une avancée majeure. Mais l'Association française de normalisation (AFNOR) ne voit le jour qu'en 1926, et l'International Standardization Organization (ISO) en 1947. Les Américains avaient créé le National Institute of Standards and Technology (NIST) en 1901. La première norme d'assurance qualité sera émise par l'armée américaine en 1959, et cette démarche traversera l'Atlantique dans le sillage du prestige associé au programme spatial Apollo, pour aboutir en 1987 à la publication de la première version des normes ISO 9000 dévolues au domaine « du management et de l'assurance de la qualité ».

Écartons dès l'abord le risque d'une confusion : le contrôle de qualité est une méthodologie à base de calcul de probabilités et de statistiques destinée à vérifier la conformité aux spécifications d'une production le plus souvent industrielle et de masse. Au stade le plus élémentaire il consiste à prélever des échantillons de la production, à les vérifier et à contrôler que le taux de défauts n'excède pas les seuils d'admissibilité. Il n'entretient que de lointains rapports avec la démarche qualité dont il est question ici.

La démarche qualité consiste à instaurer dans une entreprise un ensemble de procédures qui permettront d'établir et de vérifier son aptitude à fournir des produits satisfaisants pour ses clients. L'idée initiale était « on écrit ce que l'on fait, on fait ce que l'on a écrit ». Cette exigence a été atténuée parce qu'elle engendrait une paperasse invraisemblable, mais elle peut cependant donner une première intuition de la démarche, de concert avec l'idée associée de traçabilité : s'il survient un incident, une erreur ou une faute, il faut pouvoir en retrouver l'origine afin de les corriger.

Pour ce faire, le fonctionnement de l'entreprise sera analysé afin d'identifier les processus qu'elle met en oeuvre, leurs inputs et leurs produits, ainsi que les interactions entre eux. Cette analyse en processus permettra de modéliser le fonctionnement de l'entreprise, et ainsi de décrire dans des documents les flux d'information et de matières qui la parcourent, et en fin de compte ce que chaque acteur d'un processus doit recevoir (comme information et comme matière) pour effectuer sa mission, et ce qu'il doit livrer au processus suivant à l'issue de celle-ci.

Nous ne pouvons que le constater une fois encore, nous venons de tomber sur des idées qui nous apparaissent sous le jour favorable du bon sens et de la rationalité : qui pourrait contredire le projet de construire un modèle opérationnel de l'organisation de l'entreprise afin de mieux la comprendre et de pouvoir vérifier que les projets formulés sont bien exécutés comme prévu ? Comment douter que la livraison aux clients de produits satisfaisants et conformes à leurs commandes, de préférence dans les délais fixés, ne soit une condition de la survie de l'entreprise ? Et toute méthode qui permet de s'approcher de ces buts n'est-elle pas à adopter ? Sans aucun doute : pour que le résultat soit à la mesure de l'attente, il faut encore que la méthode soit appliquée avec suffisamment de réalisme et de sobriété pour ne pas introduire plus de désordre qu'elle n'est censée en supprimer.


2  Pour une normalisation modérée

De même, la normalisation est un principe propre à emporter l'adhésion. La non-normalisation est une plaie qui coûte très cher à quiconque veut construire un système d'une certaine complexité. Pour citer un exemple minuscule, j'ai dû réécrire des dizaines de pages de programmes Fortran parce que leur auteur avait utilisé deux dispositifs exotiques du langage qui n'étaient plus disponibles sur le nouvel ordinateur où il fallait désormais l'exécuter : c'est alors que j'ai rêvé à Ada, langage bien structuré et strictement normalisé. À une échelle plus vaste, des technologies telles que les réseaux informatiques et leur utilisation pour partager des documents à distance (le WWW), l'enregistrement vidéographique ou l'impression laser, n'ont pu se déployer à grande échelle qu'avec l'apparition de méthodes et de procédés universels admis par tous, que ce soit par l'effet de normes officielles ou par un accord entre industriels.



Si la normalisation a engendré une grande désillusion, c'est bien celle induite par l'expérience des normes de réseau de l'ISO. J'ai eu l'occasion à la fin des années 1980 d'avoir sous ma responsabilité une équipe qui travaillait avec des systèmes ISO (réseau X25, messagerie X400), et un ingénieur qui travaillait avec les systèmes de l'Internet (réseau UUCP et TCP/IP, messagerie SMTP). Au bout d'un an j'ai bien dû constater que le coût du système ISO était supérieur d'un ordre de grandeur à celui du système Internet, et surtout qu'il ne permettait pas vraiment d'utiliser le réseau, ne serait-ce que pour le courrier électronique. Cette conclusion ne nécessite pas une argumentation très serrée, quinze ans plus tard la cause est entendue et tout le monde a pu faire les mêmes constatations.

Quelle était l'origine de ce fiasco des normes de réseau de l'ISO ? Les moyens engagés pour les définir et les implémenter avaient été considérables, les principaux opérateurs de télécommunications et plusieurs des principaux industriels de l'informatique avaient fait travailler des centaines d'ingénieurs sur ce projet, alors que l'Internet apparaissait à l'époque comme une entreprise artisanale et désordonnée, ce qu'il était effectivement. L'analyse d'un phénomène aussi complexe excède largement le cadre du présent ouvrage, disons simplement que la démarche de l'ISO apparaissait singulièrement dépourvue de pragmatisme, par opposition à celle des groupes informels qui définissaient les protocoles de l'Internet. Cette absence de pragmatisme et d'esprit tourné vers la pratique ne semblait pas totalement indépendante du fait que les comités de normalisation sont constitués de gens dont c'est en fin de compte l'activité professionnelle à plein temps, qu'ils y soient délégués par des industriels qui ont des intérêts dans le domaine visé ou qu'ils soient des fonctionnaires de la normalisation. Il résulte de cette situation la constitution d'un milieu social de la normalisation, assez coupé de la pratique, dont l'objectif risque de devenir son autoconservation, en l'occurrence produire de plus en plus de normes, de plus en plus exhaustives, de plus en plus épaisses, et en fin de compte de plus en plus difficiles à appliquer. Il est vraiment dommage d'en arriver là, parce que mes participations épisodiques à des comités de normalisation informatique rattachés de façon plus ou moins directe à l'ISO m'y ont fait rencontrer des ingénieurs de haute valeur et de grande compétence, dont l'activité aura malheureusement été souvent stérile, en tout cas dans le domaine informatique. À l'inverse, les normes de l'Internet, les Requests for Comments (RFC)[54] , sont des documents assez informels rédigés le plus souvent par des praticiens et dont l'adoption résulte en dernière analyse de l'acceptation par les développeurs et les utilisateurs. Aussi étrange que cela puisse paraître, cela donne d'excellents résultats, qu'il serait peut-être imprudent d'étendre à d'autres domaines, mais en tout cas cela donne à réfléchir : nous y reviendrons ci-dessous à la page ??. Le dispositif de production de normes de l'IEEE (Institute of Electrical and Electronics Engineers) semble aussi donner d'assez bons résultats, puisque qu'il encadre notamment avec succès toute l'infrastructure des réseaux locaux (Ethernet, WiFi, etc.).

Bref, on peut dire que la normalisation bien faite, restée proche des usages et sans bureaucratie excessive, est la meilleure des choses parce qu'elle seule permet le déploiement technique à grande échelle dont l'Internet offre le meilleur exemple, et que la normalisation en circuit fermé, coupée du contact avec les usages, risque de mener à l'échec, comme l'architecture de réseau de l'ISO en a administré la preuve, sans doute en partie parce que les grands opérateurs de télécommunications institutionnels de la fin de l'époque du monopole croyaient que leur pouvoir en ce domaine était absolu. L'insuffisance de normalisation ou une normalisation trop peu indépendante peuvent freiner l'expansion des technologies les plus prometteuses, et c'est le cas de Java, dont l'inventeur a voulu garder le contrôle exclusif au détriment des développeurs indépendants, dont beaucoup se sont découragés et se sont tournés vers des technologies moins perfectionnées mais plus disponibles et plus ouvertes.

Il ne faudrait pas inférer des lignes ci-dessus que leur auteur préconise d'abandonner le processus de normalisation au bon vouloir de groupes spontanés : la normalisation exige une persévérance et une continuité que seule une organisation solide peut procurer. Les organes de normalisation de l'Internet, sur lesquels nous reviendrons à la page ??, se sont constitués de façon moins formelle que ceux de l'ISO, mais ils n'en sont pas moins dotés d'une grande robustesse.

L'architecture réseau de l'ISO fut peut-être un échec ; il n'en reste pas moins qu'il s'agissait d'une magnifique cathédrale technologique, dont certaines chapelles ont d'ailleurs été incorporées à l'Internet, comme la norme d'annuaire électronique X500 qui a donné naissance à la norme LDAP (Lightweight Directory Access Protocol), universellement adoptée aujourd'hui. Le modèle en sept couches de l'architecture ISO a introduit durablement un surcroît de rigueur intellectuelle dans l'approche des réseaux, et des générations d'étudiants et d'ingénieurs en tirent encore profit.




3  Morne qualité

La démarche qualité, à l'instar de la normalisation, peut être une excellente chose tant qu'elle n'est pas poussée par les qualiticiens à des excès qui risquent d'en faire une véritable nuisance. L'existence de qualiticiens professionnels est d'ailleurs sans doute le premier de ces regrettables excès, parce qu'une démarche qualité véritablement assimilée par une entreprise devrait sans doute être mise en oeuvre par les différents spécialistes de chaque métier qui s'y exerce. Comme pour la normalisation, l'apparition d'une corporation de professionnels de la qualité, instituée en France par exemple dans l'AFAQ[3] (Association Française de l'Assurance Qualité), n'est pas vraiment une bonne chose.

Il est malheureusement difficile de parler avec chaleur du jeu de normes ISO 9000. Ouvrir un de ses textes officiels[4, 5] est une expérience démoralisante. Si la version de l'an 2000 des normes est censée simplifier la démarche, elle ne l'a pas rendue franchement laconique.

Il y a une certaine cuistrerie à vouloir donner à n'importe quoi une allure scientifique. Depuis que l'humanité pense, les plus grands philosophes et les plus grands savants ont étudié le concept de causalité et se sont posé à son propos une foule de questions dont certaines sont encore en suspens : les spécialistes de la qualité balaient d'un revers de main ces atermoiements d'une autre époque et vous proposent un « diagramme causes-effet » dont vous n'avez plus qu'à remplir les cases et hop, vous maîtrisez vos processus. Depuis quelques siècles est apparue l'idée de progrès, et là aussi un débat toujours ouvert concerne les meilleurs esprits. Un manager moderne n'a pas de temps à perdre avec ces billevesées : l'échelle des cinq étapes du progrès est là pour scander votre marche vers la qualité ISO 9000. Il faut vraiment s'accrocher à la table pour éviter que le livre ne vole à travers la pièce. Mais beaucoup de faux concepts de cette sorte, empilés dans un style sentencieux et compassé, mélangés avec des fragments empruntés à la loi informatique et libertés, à d'autres normes ISO, à des manuels d'économie et de statistiques « sans formules » pour managers, finissent par constituer une masse significative de papier qui a toute l'apparence de la connaissance sérieuse. On y chercherait en vain une indication pratique qui pourrait aider à entreprendre quoi que ce soit de réel, par contre il y a tout ce qu'il faut pour créer des processus bureaucratiques générateurs de formulaires à remplir et de rapports à rédiger et à approuver. C'en est même le but avoué !

Les scientifiques ont compris depuis longtemps le risque de l'apparition de pseudo-sciences, engendré par le système d'évaluation par les pairs. Le plus difficile est d'amorcer le processus. Il faut une masse critique de quelques personnes pourvues de positions officielles dans les structures de la science reconnue, que l'on pourra chercher parmi les scientifiques de disciplines existantes, d'un certain âge, si possible un peu mégalomanes et frustrés d'avoir obtenu une reconnaissance certaine mais insuffisante à leurs yeux. Le mieux, si possible, est d'en trouver dans au moins deux ou trois pays différents. On peut alors commencer à organiser de petits congrès, à s'échanger des étudiants, à se citer mutuellement et à chercher des appuis tactiques (pardon, des collaborations interdisciplinaires) auprès de disciplines suffisamment éloignées pour éviter les confrontations gênantes. Il faut aussi lancer des publications, et, avec les imprimantes laser, les brevets de Rank Xerox tombés dans le domaine public et le WWW, c'est devenu beaucoup plus facile qu'il y a quelques années. Le succès n'est pas garanti, mais il y a des exemples grandioses : sciences de gestion, sciences de l'éducation, intelligence artificielle... Incidemment, le processus de création d'une vraie science nouvelle n'est sans doute pas très différent, et c'est bien ce qui donne à une entreprise de ce type, menée avec méthode et persévérance, quelque chance d'aboutir.

La démarche qualité ne cherche pas vraiment à se placer dans le champ scientifique, mais sous sa forme « pure et dure » l'idée n'est pas à écarter qu'elle soit un succès de cette espèce. Encore une fois, elle est née de bonnes idées, et dans un contexte qui la justifiait totalement. Le lancement d'un vol habité vers la Lune est un projet d'une complexité telle et pour lequel un échec est si grave que la mise en place d'une structure de supervision lourde est bien sûr indispensable. À une échelle moindre, j'ai eu l'occasion de voir le manuel d'utilisation d'un avion de ligne : il s'agissait d'un petit camion aménagé en bibliothèque, que l'on amenait sur le tarmac pour le feuilleter et arriver à fermer la soute à bagages. Aujourd'hui ce serait peut-être un jeu de CD-ROMs. Le volume de cette documentation est sûrement justifié. En même temps, il s'agit d'une littérature assez systématique et répétitive, parce que la complexité d'un avion consiste beaucoup en répétitions de multiples éléments semblables.

La démarche ISO 9000 est peut-être raisonnable dans un environnement industriel, parce que justement on y effectue beaucoup d'opérations répétitives, ce qui veut dire que le ratio nombre d'opérations / nombre de procédures aura une valeur élevée. De surcroît l'erreur peut y être mortelle (nous verrons des cas de systèmes d'information où une erreur peut être mortelle). La construction d'un système d'information est exactement le contraire d'une succession d'opérations répétitives. Par définition, l'information est ce qui est imprévu. L'annonce d'un événement certain contient une quantité d'information égale à zéro, au sens de Shannon. Lorsqu'un ingénieur conçoit un appareil mécanique, il s'efforce d'avoir le plus grand nombre possible de pièces identiques, afin d'en simplifier la production. Lorsqu'un développeur conçoit un logiciel, s'il identifie des traitements identiques, il les supprime pour n'en avoir plus qu'un exemplaire, et lorsque le logiciel a été ainsi réduit par élagage des branches répétitives, il n'est plus que de la complexité à l'état pur. Appliquer ISO 9000 à une activité de développement informatique est d'une part coûteux, d'autre part assez stérile, car on ne saisit que des aspects très extérieurs de cette activité et de ses résultats, ce qui n'aide guère à identifier les défauts et à les corriger. On trouvera dans le livre passionnant d'Isabelle Boydens[17] une critique solide de l'application à un processus de conception logicielle de la norme ISO 9000 conçue pour la production industrielle.

À ce sujet de la complexité du logiciel, il est des vérités que l'on n'ose pas penser et encore moins proférer parce que le public, même et surtout le public cultivé, ne les jugerait pas vraissemblables. Le 8 juillet 2004, Richard Stallman, le porte-parole de la Free Software Foundation, a prononcé dans l'enceinte des Rencontres Mondiales du Logiciel Libre à Bordeaux une conférence intitulée « Les dangers des brevets logiciels ». Après avoir rappelé le lien entre la notion de brevet et celle d'idée originale, il a comparé sous ce rapport les logiciels avec quelques entités traditionnellement brevetables. Par exemple dans l'industrie pharmaceutique l'originalité d'une idée aboutit à la formule chimique d'une molécule, qu'il est indubitablement possible de protéger par un brevet. Un avion de ligne comporte des centaines de milliers de pièces qui, pour certaines d'entre elles, sont couvertes par des brevets, soit peut-être des centaines, voire des milliers de brevets. Mais qu'est-ce qu'un logiciel, sinon une suite d'idées ? Un logiciel de taille moyenne, disons de quelques centaines de milliers de lignes, comporte de l'ordre de cent mille idées2, il est de ce point de vue beaucoup plus complexe qu'une molécule biologique ou qu'un avion, hormis le fait qu'un avion moderne comporte aussi des millions de lignes de logiciel. Les logiciels de grande taille, notamment les systèmes d'exploitation, sont les objets techniques les plus complexes du monde d'aujourd'hui.

Pour en revenir aux tentatives d'appliquer la démarche qualité à l'informatique, il peut être tentant de découvrir, dans d'autres volets du fonctionnement du système d'information, des activités plus industrielles. L'exploitation est une cible de choix. Mais dans une exploitation informatique moderne, ce qui est répétitif est automatisé, et ce qui ne l'est pas, et qui est vraiment décisif, est l'activité de conception et de paramétrage des automates, activité très similaire à du développement logiciel ; et même, le plus souvent, c'en est : le paramétrage des listes de contrôle d'accès d'un routeur ou l'écriture d'un script pour arrêter les machines lorsque l'onduleur détecte une coupure de courant, c'est de la programmation, et pas de la variété la plus facile. Appliquer à cette activité des procédures administratives lourdes, telles que prévues par ISO 9000, ne va guère aider à l'améliorer. Cela fera passer au premier plan les interactions avec les interlocuteurs extérieurs, plus faciles à identifier et à comptabiliser, aux dépens des tâches de fond, qui font en réalité la qualité du service.

Si les procédures ISO 9000 ne peuvent pas appréhender la teneur intime du travail informatique, mais seulement son enveloppe extérieure, elles risquent de n'être plus qu'un banal outil de vérification du fait que les personnes affectées à ces tâches sont bien présentes sur leur lieu de travail le bon nombre d'heures, et que pendant ce temps elles se consacrent bien à la mission confiée par leur employeur. Il faut alors se poser deux questions : ISO 9000 est-il l'outil le mieux adapté à cette fonction ? Mettre en place ce type de contrôle est-il un facteur décisif d'amélioration des résultats du travail informatique ? La suite de cet ouvrage s'efforcera de fournir des éléments de réponse à la seconde question. La première ne nous semble pas mériter un long examen.


4  Pour une démarche qualité adaptée aux situations réelles

La naissance de la démarche qualité au sein d'un projet aussi important qu'Apollo lui a donné une impulsion initiale très forte, assortie d'un grand prestige. La naissance de cercles intéressés par cette démarche a constitué un apport intéressant à la batterie d'outils dont disposent les ingénieurs, toujours attachés à améliorer leurs méthodes et leurs processus, puisque c'est en fait l'essence de leur métier. La déviation de la démarche qualité vers la lourdeur bureaucratique est le fruit vénéneux de son succès même : elle est devenue une institution, avec ses professionnels à plein temps qui ont eu intérêt à la développer et à la déployer le plus largement possible. Sous couvert d'ISO 9000, des positions de pouvoir bien payées ont pu être confiées à des personnes dépourvues de toute compétence bien identifiée, ce qui revient à dire qu'il leur a suffi de savoir lire et d'utiliser habilement cette aptitude pour acquérir une position dominante par rapport à des ingénieurs qui ont cru, à leur grand tort, que leur compétence durement acquise avait une valeur décisive pour leur employeur. Quelques idées en provenance d'ISO 9000 ont séduit les instances administratives, toujours attirées par des procédures qui leur permettraient de contrôler le travail, si possible par des moyens externes qui évitent d'avoir à en comprendre la teneur intime.

Donner un tel pouvoir à des personnes dépourvues de compétences précises a un autre avantage : la direction est assurée de leur fidélité parce que leur position ne tient qu'à elle, alors que des agents compétents risquent d'être plus indépendants.
Encore une fois, entendons-nous bien : savoir lire, vraiment lire, comprendre et assimiler ce qu'on lit, c'est une compétence rare, il n'est pas aberrant de confier à ceux qui la possèdent des responsabilités spéciales. Quiconque doit diriger une entreprise ou un département d'entreprise est confronté au paradoxe d'avoir à encadrer des spécialistes dont il ne maîtrise pas le métier, ou du moins pas tous les aspects de leur métier. Cette situation paradoxale est inhérente à la division du travail, il faut s'en accommoder, et pour cela créer un système de traductions, de correspondances, en bref de signes, qui permette au dirigeant incompétent dans tel ou tel secteur de désigner et de diriger, pour ainsi dire de l'extérieur, les activités d'un collaborateur compétent dans ce secteur. Cette situation est délicate et exige beaucoup de doigté si l'on ne veut pas qu'elle devienne conflictuelle. La démarche qualité peut avoir à cet égard un rôle positif.

Décrire l'extérieur d'un processus sans analyser son fonctionnement intime ni la sémantique des objets qu'il affecte, c'est une démarche d'abstraction éventuellement utile, même si elle comporte un aspect d'encapsulation de la compétence dans de l'incompétence qui peut paraître désagréable et qui comporte sûrement des limites.

En fin de compte nous arrivons à la conclusion que la démarche ISO 9000 est un mécanisme du pouvoir de la direction de l'entreprise sur son personnel, un peu comme le système des chronométreurs dans l'usine taylorienne. Ce n'est ni une surprise renversante ni un scandale en soi : simplement, la distribution du pouvoir qu'elle organise n'est pas la mieux adaptée à l'activité d'édification du système d'information ; ISO 9000 n'apparaît pas comme un bon système d'incitation des informaticiens au travail et, contrairement à ce qui se passe à l'usine, la contrainte n'est pas un moyen applicable ici.
Nous devons citer un autre facteur de pénétration de la démarche ISO 9000 dans les entreprises : la pression des grands cabinets d'audit internationaux. On comprend que ces cabinets soient attirés par des procédures normalisées d'évaluation d'une activité à partir d'éléments externes, et si l'explosion en vol scandaleuse d'Arthur Andersen n'avait jeté un certain discrédit sur leur activité, on pourrait dire que c'est légitime. Une version légère d'ISO 9000, limitée aux grands processus dont le fonctionnement peut intéresser les actionnaires, sans entrer dans le détail de l'organisation interne de l'entreprise, serait peut-être une évolution souhaitable.

De grands groupes industriels et certaines administrations ont exigé de leurs fournisseurs la certification ISO 9000 : à partir de là l'épidémie n'était plus enrayable, et elle s'est répandue dans toutes sortes d'organisations qui n'en avaient pas besoin, pour toutes sortes de processus qui ne s'y prêtaient pas.

Que l'on m'entende bien : toutes les organisations ont quelque chose à gagner dans l'adoption d'une démarche qualité adaptée à leur situation réelle, mais rares sont celles qui pourraient avoir intérêt à adopter une démarche qualité aussi coûteuse que celle décrite par ISO 9000, tant celle-ci est contaminée par le discours technocratique et par l'imitation de travail décrite par Alexandre Zinoviev[128].


5  La qualité totale des données : une utopie positiviste

La démarche qualité a été appliquée non seulement aux développements de logiciels, mais aussi aux bases de données et à leur contenu. Isabelle Boydens[17] a exploré aussi ces tentatives, et les lignes qui suivent doivent beaucoup à ses analyses. Nous examinerons d'abord l'approche Total Data Quality Management (TDQM) du Massachusetts Institute of Technology (MIT), puis la Field theory of information, qui constitue une critique radicale de la théorie TDQM, bien qu'elle l'ait précédée dans le temps.

Total Data Quality Management (TDQM)

Le programme TDQM lancé par le MIT en 1991 se propose d'élaborer une théorie et des méthodes pour améliorer la qualité des bases de données. L'article le plus significatif pour qui veut cerner l'ambition de ce programme a été publié en 1996 dans les CACM[122] par R.Y. Wang et Y. Wand sous le titre « Anchoring Data Quality Dimensions in Ontological Foundations ». Nous voyons ici apparaître un usage du mot ontologie et de ses dérivés, que nous retrouverons à la page ?? et qui nous semble, là comme ici, abusif.

Cet article professe un positivisme3 proprement incroyable :

« Le monde est fait de choses qui sont dotées de propriétés... Les propriétés sont représentées par des attributs qui sont des caractéristiques affectées aux choses par des humains... Les valeurs des attributs à un instant donné constituent l'état de la chose.

La connaissance d'une chose est appréhendée en termes de ses états. Toutes les combinaisons de valeurs des attributs ne sont pas possibles. Il y a des lois qui limitent les états autorisés à l'espace des états valides... Pour qu'un système d'information soit une bonne représentation d'un système du monde réel, ses états valides doivent refléter les états valides du système du monde réel...

Il y a imperfection de données lorsque la vision du système du monde réel qui peut être inférée d'un système d'information destiné à le représenter n'est pas conforme à la vision qui peut en être obtenue par l'observation directe. »

Ce texte est intéressant parce qu'il résume assez bien et formule explicitement les présupposés généralement implicites des théoriciens des systèmes d'information ; il comporte une métaphysique implicite, dont Isabelle Boydens donne un énoncé explicite (p. 62) :

« Une telle approche repose implicitement sur trois postulats : ... L'approche de Wand et Wang est tautologique... Poser un isomorphisme entre une base de données et l'objet observable correspondant permet ensuite d'analyser la qualité d'une base de données en termes d'un différentiel entre l'objet et sa représentation. »

Isabelle Boydens poursuit sa critique ainsi : il existe effectivement des cas où il est possible de confronter le contenu d'une base de données au système réel qu'elle représente ; ainsi on peut vérifier l'exactitude du catalogue d'une bibliothèque par une exploration exhaustive de ses rayons, mais c'est une opération coûteuse qu'il est hors de question de réitérer à chaque consultation. Et dans la majorité des cas une telle vérification est parfaitement impossible : Isabelle Boydens cite l'exemple de la comptabilité nationale4 qui produit des grandeurs construites et estimées selon des méthodes approchées qui varient d'un pays à l'autre en fonction des sources disponibles et qui sont affectées conventionnellement à des intervalles de temps donnés, ou encore de la base des données collectées lors d'un tremblement de terre, qu'il est bien sûr impossible de reproduire. I. Boydens conclut que « la question de la correction de l'information empirique conduit inévitablement à une impasse », et nous nous rallierons à cette conclusion, non sans qu'elle soit encore renforcée par la section suivante. Incidemment, nous examinerons à la page ?? des points de vue voisins de celui de la théorie TDQM, et auxquels la réfutation d'Isabelle Boydens s'appliquera également.

Field theory of information

Après le premier choc pétrolier (1973-1974) l'opinion et les autorités américaines ont été prises de doute à l'égard du système statistique public, qui affirmait la présence d'importants stocks de produits pétroliers alors que l'automobiliste faisait l'expérience de la pénurie. Sous la présidence de Jimmy Carter, le Department of Energy entreprit une évaluation des bases de données qui dura cinq ans et examina 400 systèmes d'information et 2 200 bases de données. De cet immense travail d'audit, qui eut recours à des méthodes statistiques créées pour les besoins d'analyse de ce volume énorme de données, émergea une démarche scientifique : la Field theory of information[71].

La conclusion principale de cet audit, qui fonde la théorie, est la mise au jour du processus par lequel une donnée devient de l'information (oserons-nous dire l'algorithme donnée/information ?). Une donnée apparemment valide, décrite par un vocabulaire stable sur lequel tout le monde semble d'accord, ne deviendra une information qu'après avoir subi une interprétation par un être humain qui ainsi lui conférera un sens. Et cette interprétation dépendra fortement de celui qui la donne, de ce qu'il cherche dans ces données, de la date à laquelle il les consulte. Bien sûr, ceci est vrai aussi et encore plus pour celui qui constitue la base de données. Les données ne sont pas un élément tangible de la réalité, mais un artefact construit avec une intention déterminée ; cette intention conditionne les interprétations qui pourront être faites de ces données. L'information est encore moins un élément tangible de la réalité, elle n'existe que dans l'esprit de ceux qui interprètent les données ou les textes, elle n'a aucune réalité objective.

Munis de cette conclusion, nous ne serons dès lors pas le moins du monde surpris de l'existence, pour citer Isabelle Boydens (p. 95), « d'un fossé ``large mais invisible'' entre les besoins en information et l'information elle-même. L'opacité du fossé est due à l'absence de contrôle et de vue simultanée sur le phénomène représenté, le processus de production de l'information et le processus d'exploitation de celle-ci. » Ainsi, « les bases de données relatives aux ventes d'énergie étaient confondues et couplées avec d'autres bases de données relatives à la consommation en énergie, ou encore, des données collectées dans le contexte des inventaires étaient exploitées dans d'autres systèmes en vue de mesurer la distribution. »

Ces erreurs d'analyse commises sur la base d'une confusion entre données et informations d'une part, d'une croyance naturaliste dans le caractère réel des données d'autre part, avaient mené droit à une disjonction majeure entre les prévisions des statisticiens et la réalité. Nous retrouverons de telles démarches erronées au chapitre 5 lorsque nous examinerons les méthodes de spécification et de conception du logiciel. Ces erreurs sont au principe de l'utopie du système d'information que nous analyserons au chapitre 7.

Signalons que le livre de Michel Volle Analyse de données[113] rejoint sur de nombreux points les analyses de la Field theory of information.




1
Qin Shihuangdi avait également ordonné la destruction de tous les livres existant dans l'empire afin qu'ils soient réécrits avec un contenu plus conforme à ses souhaits. Ce Fils du Ciel était décidément un précurseur de génie !
2
On verra à la section 3 du chapitre 5 un exemple où il a été possible littéralement de compter les idées d'un logiciel, et d'avoir ainsi une estimation de sa densité intellectuelle : le noyau de sécurité du logiciel du métro METEOR a été développé par la méthode B, qui consiste à élaborer la preuve de la correction du programme en même temps que son code, ce qui fournit une démonstration formelle de justesse. L'écriture des 100 000 lignes de code engendra 30 000 obligations de preuve, dont la plupart furent satisfaites automatiquement par le système ; il resta 2 500 démonstrations rétives à l'automatisation, à effectuer par les ingénieurs. Il est possible de dire que ce logiciel comporte 30 000 idées, dont 2 500 idées difficiles, pour 100 000 lignes de texte.
3
Comme je l'ai déjà signalé, je n'ignore pas qu'il existe par ailleurs un positivisme philosophique respectable.
4
Il ne faut pas confondre comptabilité nationale et comptabilité publique : la seconde expression désigne le système comptable de la puissance publique, au sens de la comptabilité des entreprises, cependant que la comptabilité nationale est une branche de la science économique qui vise à donner de l'économie d'un pays une image globale au moyen d'agrégats comme le produit intérieur brut (PIB), notion bien connue, ou la formation brute de capital fixe (FBCF) qui récapitule les investissements des acteurs économiques.
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre
Précédent Remonter Suivant