Entropie du système d'information
22 novembre 2003
On peut distinguer trois phases
dans l'histoire de l'informatique : celle des applications qui ont
automatisé les fonctions administratives dans les années 50 et 60 (paie,
comptabilité, gestion des stocks etc.) ; celle des systèmes d'information, qui
démarre dans les années 70 avec la méthode Merise (mise au point entre 1972
et 1975) ; celle enfin de l'informatisation des processus qui organise
l'entreprise autour du « travail assisté par ordinateur » et débute
dans les années 90.
Chacune de ces phases peut se
représenter par un petit dessin : pour la première, des applications juxtaposées,
« en tuyau d'orgue » ; pour la deuxième, qui a ambitionné de
corriger le désordre sémantique par la gestion des données de référence,
il faut ajouter au graphique les bases de données et les référentiels. Un petit diagramme d'activité
inspiré d'UML, donc de la modélisation des « objets », représente
convenablement la troisième où se réalise l'informatisation des processus.
Dans la troisième phase, la conception d’un système d’information
doit obéir à quelques principes élémentaires :
bien définir les domaines d'action, les processus de production de valeur ajoutée,
les « populations » d'entités concernées par ces processus, les
« classes d'objets » à utiliser pour décrire ces populations ;
organiser les processus de façon à éviter les doubles saisies, les doubles
identifications, les connexions répétées à des applications diverses ; éliminer
les synonymes et les homonymes ; construire les référentiels (identifiants, définitions
des données) et gérer les données de référence de sorte que la sémantique
du système d'information soit maîtrisée...
Mais nos entreprises n'ont pas
attendu le système d’information ni UML pour s'informatiser ; les
applications conçues « en tuyaux d'orgue » dans les années 60 et
70 sont encore là et les refaire coûterait cher. Pour corriger leurs défauts
les plus criants on leur a associé des référentiels, mais ceux-ci ne
recouvrent en général qu'une partie du système d’information (ainsi
l’entreprise aura créé un annuaire des personnes, un annuaire de
l'organisation, mais non la nomenclature des produits etc.). D'ailleurs la
construction d’un référentiel pose de difficiles problèmes de méthode.
Enfin, les réalisations en
mode objet ne concernent aujourd'hui qu'une petite partie des systèmes
d’information et doivent se juxtaposer aux réalisations antérieures. Ainsi
l’on peut représenter nos systèmes d’information
par le petit dessin ci-dessous : ils se présentent comme l'accumulation
géologique de couches diverses obéissant chacune à des priorités et principes
différents ; les responsables tentent de se débrouiller pour tirer de cet
ensemble disparate la meilleure performance pour le moindre coût.
Lorsque l’on parle de système
d’information, il faut indiquer si l’on parle du système
d’information tel qu’il existe de facto dans une entreprise, souvent
conforme au petit dessin ci-dessus, ou du système d’information idéal
correspondant au cas hypothétique d’une entreprise nouvelle partant de zéro.
*
*
Même si nous étions
parvenus au terme de l'évolution actuelle, même si les systèmes
d’information étaient spécifiés en UML et réalisés en mode objet, le désordre
y naîtrait aussi naturellement que l'entropie naît dans la matière.
Supposons qu’une entreprise
ait créé un référentiel de l'organisation et immatriculé les services, établissements
et zones géographiques. Elle a ainsi construit une base de données de référence qui évolue avec les changements de l’organisation. Tout se passera bien
si les divers domaines de l'entreprise répliquent ce référentiel sans délai
dans leurs processus ou s’ils le consultent lors de chaque utilisation.
Cependant les personnes qui équipent les processus seront toujours tentées de
construire un référentiel propre à chaque processus : alors le désordre
s’installe.
Commentaire de Isabelle Boydens,
Informatique,
normes et temps,
Bruylant, Bruxelles 1999
Isabelle
Boydens explore les conditions pratiques de production et d'interprétation
des bases de données selon une approche à la fois technique et historique.
Elle part pour cela d’un cas précis, la base de données de la sécurité
sociale belge.
Une
telle base de données n'est pas un objet « simple », qu'on la
considère en termes de qualité, de représentativité, de pertinence ou de
lisibilité. Isabelle Boydens décrit ainsi sa démarche :
« Nous
avons préalablement sélectionné un ensemble cohérent et représentatif de
normes légales dont la base de données assure l'automatisation. Nous avons
ensuite analysé et confronté les sources juridiques, les directives et
rapports administratifs, les articles de presse, la documentation informatique
et enfin le code de programmation correspondant. Nous avons procédé à de
nombreuses entrevues avec les gestionnaires et utilisateurs de la base de données.
Enfin nous avons longuement observé le processus de gestion et d'interprétation
de la base de données opéré dans la pratique et nous y avons nous même
participé. Une observation de terrain permet de révéler ce qui n'est ni dit
ni écrit, à savoir les mécanismes informels d'interprétation des données. »
Isabelle
Boydens a examiné ainsi des aspects essentiels de la pratique des bases de données,
aspects très complexes mais que l’on prend rarement la peine d’étudier parce
que l’on suppose, bien à tort, qu’une base de données est quelque chose
de « simple ».
Les choses se passent très
souvent ainsi : lors de l'écriture du code, le programmeur introduit dans le
programme une copie de la table de référence mais, comme il travaille sous une
contrainte de délai, il remet à plus tard l'écriture du module qui assurerait
sa mise à jour. Puis il oublie la nécessité de ce module. Lors de la recette,
tout se passera bien puisque la table, étant récente, est à jour. Cependant par
la suite la table de référence évoluera. On oubliera parfois de mettre la copie à
jour (il faudrait le faire à la main), l'écart se creusera entre les deux
tables, le désordre s'installera.
Supposons ainsi que le système
d’information comporte de facto plusieurs tables représentant le découpage
géographique. Le monde a été découpé en quelques « régions »
et l’entreprise a donné un nom à chacune d'entre elles. Le marché évoluant,
l'entreprise modifie ces régions en faisant passer des pays de l'une à
l'autre. Le référentiel est modifié ; mais les tables des divers processus ne
seront pas mises à jour simultanément. La définition
des régions diffère alors d'un processus à l'autre. Les interfaces
signaleront des erreurs, les vérifications et redressements accapareront
processeurs et back-offices. L'interprétation des données occasionnera, lors
des conversations entre dirigeants, d'interminables perplexités.
Si le désordre concerne
plusieurs référentiels (des produits, des clients, des pièces détachées
etc.), la pagaïe devient générale. Seule une gendarmerie vigilante, ici
une direction de l'architecture ayant l'information et l'autorité nécessaires,
peut maintenir la discipline. Cela rappelle la circulation automobile : le code
de la route est connu, mais comme chacun peut être tenté de commettre une
faute la peur du gendarme est utile.
« Il n'y a qu'à » mettre des
gendarmes pour maintenir l'ordre ? Non, car cela ne résout pas tout : parfois
les forces de l'ordre sont débordées. Supposez que le système d’information de
votre entreprise soit articulé avec celui d'un partenaire (cela suppose
l'« interopérabilité des systèmes d’information ») : il faudra s'organiser pour
faire prendre en compte par ce partenaire les changements de votre référentiel.
, . D’ailleurs le système d’information du partenaire sera peut-être en
désordre, mais vos gendarmes n'ont pas le « droit de suite » chez lui : s'il
utilise pour classer ses produits une table différente par région, vous serez
contraint de les connaître toutes et de suivre leurs errements. Si l’on ne
parvient pas à faire prendre au sérieux « ces histoires informatiques » par les
dirigeants pour qu'ils en fassent un des thèmes à négocier lors de l'accord de
partenariat, le désordre s'insinuera dans le système d'information par les
échanges avec les partenaires.
Une autre source de désordre réside
dans les changements de périmètre de l'entreprise. Supposez que votre entreprise
en achète une autre. L'alignement des systèmes d’information occasionnera
des conflits féroces entre équipes de managers (c’est à qui prendra le
pouvoir, à qui gardera sa place). Pendant toute la durée de cette guérilla il
faut vivre avec un système hétéroclite, des référentiels dont les
nomenclatures ne se correspondent pas, etc.
Dans l'économie innovante et
évolutive d’aujourd’hui les partenariats sont fréquents ainsi que les fusions,
absorptions etc. : autant d'occasions pour que l'entropie s'accroisse quelle que
soit la qualité du travail des gendarmes. L'état naturel du système
d’information, ce n'est donc pas l'ordre mais un désordre contre lequel la
guerre ne sera jamais gagnée. Ce n'est pas une raison pour perdre de vue les
principes selon lesquels on doit bâtir le système d’information, mais il
est en pratique difficile de les respecter exactement.
Comment font les forces de
l'ordre lorsqu'elles sont débordées ? Elles louvoient à la recherche du
compromis qui permettra le moindre mal : elles pactisent avec une bande pour
mettre une autre bande à la raison, elles tolèrent ceci pour pouvoir réprimer
cela, elles négocient des appuis auprès de la municipalité, des familles, des
associations. Le gendarme se fait diplomate. Il en est de même du responsable
d'un système d’information quand les sources de désordre ont un fort débit.
S'il parvient un instant à imposer la logique, la discipline, la méthode etc.,
l'ordre sera de courte durée. Il ne pourra pas se contenter de préceptes
logiques : il devra avoir aussi une sensibilité tactique et "politique" pour limiter la casse
et faire en sorte que, quoique désordonné, le système d’information reste
assez cohérent pour rendre un service acceptable.
|
