Entropie du système d'information

15 juillet 2001

Isabelle Boydens a critiqué un passage de la page "Modestie ou timidité ?". Voici un abrégé de ses remarques : 

Vous appelez "principes élémentaires" : (1) définir les domaines d'action, processus de production, "populations" d'entités, "classes d'objets" ; (2) organiser les processus pour éviter les doubles saisies, doubles identifications, doubles connexions ; (3) éliminer synonymes et homonymes ; (4) construire les référentiels (identifiants, définitions), gérer les données de référence. " 

Or la construction du référentiel, la maîtrise de la sémantique ne sont pas des "principes élémentaires". Il faut dire la vérité aux dirigeants : l'harmonisation du référentiel est un objectif inaccessible vers lequel il faut tendre.

Comme tout ce que dit Isabelle Boydens (dont je recommande l'ouvrage "Informatique, normes et temps"), ces remarques sont fines et pertinentes. Les contraintes sémantiques sont simples à exprimer, difficiles à respecter. C'est comme au jeu de Go : des règles faciles à apprendre, une maîtrise qui s'approfondit sans fin.

Dans le cas particulier des systèmes d'information, la complexité est double ; l'une, transitoire peut-être, tient au moment de l'histoire de l'informatique où nous nous trouvons ; l'autre, permanente, est causée par l'entropie qui dégrade sans cesse les systèmes d'information.

Complexité historique

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 Merise (mis au point entre 1972 et 1975) ; celle de l'informatisation des processus qui organise l'entreprise autour du "travail assisté par ordinateur" et débute dans les années 90 (on trouve sur le site de Bernard Morand une utile présentation de l'histoire des méthodes). 

Chacune de ces phases peut se représenter par un petit dessin : des applications juxtaposées, "en tuyau d'orgue", pour la première ; des bases de données et des référentiels pour la seconde, qui a ambitionné de corriger le désordre sémantique par l'administration des données et la gestion des données de référence. Un petit diagramme d'activité, inspiré d'UML ("Unified Modeling Language"), représente convenablement la troisième qui réalise l'informatisation des processus.

C'est cette dernière phase que j'évoque lorsque je parle de "principes élémentaires" pour désigner les domaines d'action, processus de production, "populations", "classes", etc. Mais nos entreprises n'ont pas attendu 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 SI (ainsi on 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 orienté objet ne concernent aujourd'hui qu'une petite partie des SI et se juxtaposent aux réalisations antérieures. Ainsi nos SI comportent une accumulation historique 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. 

Évoquer, comme je l'ai fait, les principes qui doivent orienter la construction d'un SI neuf, c'est tourner le dos à la situation des SI actuels et se projeter dans le futur - ou bien c'est considérer le cas hypothétique d'une entreprise nouvelle qui partirait de zéro pour construire son SI. Cela n'enlève rien à la qualité de ces principes, mais cela restreint leur portée pratique. 

Entropie du SI

Même si nous étions parvenus au terme de l'évolution actuelle, même si les SI étaient spécifiés en UML et réalisés en mode objet, le désordre y naîtrait comme l'entropie naît dans la matière. 

Supposons que vous ayez créé dans votre entreprise un référentiel de l'organisation immatriculant les services, les établissements et les zones géographiques. Il s'agit d'une base de données de référence. Tout ira bien si les divers domaines de l'entreprise répliquent ce référentiel sans délai dans leurs processus ou le consultent à chaque utilisation.

Cependant les personnes qui équipent les processus seront tentées de construire le référentiel propre à chaque processus. Cela se passe ainsi : lors de l'écriture du code, on y introduit une copie de la table de référence, et comme on travaille sous la contrainte des délais on remet à plus tard l'écriture du module qui assurerait sa mise à jour. Puis on oublie la nécessité de ce module. Lors de la recette, tout se passera bien puisque la table, étant récente, est à jour. Mais à la longue, le référentiel évoluera, on oubliera de mettre la table du processus à jour (il faudrait le faire à la main), l'écart se creusera entre les deux tables et le désordre s'installera. Supposons ainsi que le SI comporte de facto plusieurs tables pour le découpage géographique. Vous avez découpé la France en quelques "régions" et donné un nom à chacune d'entre elles. Le marché évoluant, l'entreprise décide de modifier les régions en faisant passer une ville ou un département de l'une à l'autre. Le référentiel est modifié ; mais les tables des divers processus ne seront pas mises à jour ou pas en même temps. Les régions diffèreront 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, la pagaïe est générale. Seule une gendarmerie vigilante, ici une direction de l'architecture ayant l'information et l'autorité nécessaires, pourra maintenir la discipline. Cela rappelle la circulation automobile : le code de la route est connu, mais chacun pouvant être tenté de faire une faute la peur du gendarme est utile.

Eh bien, direz-vous, il n'y a qu'à mettre des gendarmes pour maintenir l'ordre. Mais parfois les forces de l'ordre sont débordées. Supposez que vous ayez articulé votre SI avec celui d'un partenaire : il sera difficile de lui faire prendre en compte les modifications de votre référentiel et vos gendarmes n'ont pas le droit de suite chez lui. En outre son propre SI sera en désordre : s'il utilise pour classer ses produits une table différente par région, vous serez obligé de les connaître toutes et de suivre leurs errements. Si vous ne parvenez pas à faire prendre au sérieux par les dirigeants "ces histoires informatiques" pour qu'ils en fassent un des sujets de leurs négociations, le désordre s'insinuera par les échanges avec vos 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 SI occasionnera des conflits féroces entre équipes de managers (c'est à qui prendra le pouvoir, à qui gardera sa place). Pendant la guérilla,  vous devrez vivre avec un système hétéroclite, des référentiels dont les nomenclatures ne correspondent pas, etc.

Dans l'économie évolutive, innovante qui est en train de naître, les partenariats seront fréquents, ainsi que les fusions, absorptions etc. : autant d'occasions pour que l'entropie s'accroisse quelle que soit la qualité des gendarmes. L'état naturel du SI, ce n'est plus l'ordre, mais un désordre contre lequel la lutte n'est jamais gagnée. Ce n'est pas une raison pour perdre de vue les "principes simples" sur lesquels on peut bâtir un SI, mais il sera en pratique très difficile de les respecter exactement.

Comment font les forces de l'ordre lorsqu'elles sont débordées ? Elles louvoient à la recherche d'un compromis permettant 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 SI quand les sources de désordre ont un fort débit. S'il parvenait un instant à imposer la logique, la discipline, la méthode etc., l'ordre serait de courte durée. Il ne pourra donc pas se contenter de préceptes logiques ; il devra avoir aussi une sensibilité tactique pour limiter la casse et faire en sorte que, quoique désordonné, le SI reste assez cohérent pour rendre un service acceptable.