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 :
-
Le monde est composé d'éléments discrets, univoques, clairement
identifiables et perceptibles.
- Les combinaisons et la connaissance de ces éléments sont
gouvernées par des lois.
- Il est possible d'établir une relation biunivoque entre le réel
observable et sa représentation informatique en vertu de l'isomorphisme
qui les relierait l'un à l'autre.
... 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