Exemple 1 : le système d'information

Lorsque l’on veut construire un système d’information, il faut être le plus simple possible. L’expérience montre en effet que 80 % des fonctionnalités développées à grands frais, dont la maintenance sera elle aussi coûteuse[1], ne sont pas utilisées : il faut donc limiter les fonctionnalités au strict nécessaire en obéissant au principe que les Américains ont avec humour baptisé KISS (« Keep it simple, stupid ! »). Celui qui rédige une expression de besoin, un cahier des charges, doit définir des priorités entre les demandes des utilisateurs, élaguer, simplifier : il s’agit de répondre non à la demande, mais à des besoins dont la demande est l'expression déformée et le plus souvent inflationniste.

Si l’on considère maintenant non une application, mais l’ensemble d'un système d’information, les écarts entre les nomenclatures qu'utilisent les diverses applications introduisent une complication supplémentaire. Une base de donnée utilise telle nomenclature de produits, telle table de l’organisation, tel code géographique ; une autre base de données en utilisera d’autres. La logique voudrait que les tables de codage fussent identiques dans toutes les applications, mais la sociologie de l’entreprise, le particularisme des métiers, l’insouciance des dirigeants, les circonstances de l'exécution font qu’en pratique l’architecture des bases de données n’est jamais cohérente. Elle est soumise à un phénomène d’entropieirrésistible dont l'explication réside dans la nature même des données [Boydens] :

1) L'interprétation des données en informatique scientifique (chimie, biologie, etc.) évolue et comporte des ambiguïtés sémantiques, même si ces données sont vérifiées et contrôlées :

- Dans les années 80, avant la découverte de la chute du taux d'ozone par des chercheurs britanniques, les valeurs faibles de ce taux ont été considérées comme des anomalies dans les bases de données stratosphériques de la NASA : la théorie d'alors ne permettait pas de penser qu'elles puissent être correctes. La NASA a ensuite adapté la structure de la base pour intégrer ces "anomalies" parmi les valeurs admises.

- L'analyse des facteurs à l'origine des maladies cardiaques (tabac, alcool, stress etc.) repose sur le suivi de cohortes d'individus. Durant l'observation les équipes de médecins, la composition de la cohorte (certains volontaires cessent de donner signe de vie) et les théories médicales évoluent. Ces évolutions nécessitent des adaptations ponctuelles de la structure de la base de données médicales.

2) Le problème est encore plus aigu en informatique de gestion. Il est normal et parfaitement admissible qu’un agent fasse passer son travail opérationnel avant les tâches de saisie[2] ; mais il en résulte que les données sont souvent incomplètes et qu’en outre parmi les données saisies seules celles que l’agent juge importantes auront été bien vérifiées[3]. Il arrive aussi que des interprétations locales soient données aux tables de codage qui se dégradent alors en multiples dialectes. Par ailleurs les changements de la réglementation obligent parfois à des traitements rétroactifs qu’il est impossible de réaliser en toute rigueur : il faudrait disposer de données non collectées à l’époque et que l’on ne peut pas reconstituer.

3) Il y a conflit entre l’exigence formelle du code informatique et le flou inhérent à des concepts dont l'interprétation est sujette a l'expérience humaine, même quand il s'agit de concepts générateurs de droits et de devoirs (cotisations, prestations sociales, impôts etc.). Par exemple la distinction entre un ouvrier et un employé repose sur le caractère prépondérant de leurs activités manuelles ou intellectuelles, caractère bien difficile à évaluer ; des difficultés analogues se rencontrent avec les concepts de journée de travail, de catégorie d'activité etc. Les ambiguïtés ne sont pas forgées par l'homme mais résultent du fait que, par nature, les sensibilités, expériences etc. qui permettent d'appréhender ces concepts sont diverses. Il faut trancher car les contraintes formelles de l'informatique exigent - heureusement - des données dépourvues d'ambiguïté. Mais la façon dont on tranche évolue. La structure formelle de la base informatique doit être ponctuellement adaptée à une évolution des interprétations liée à celle du réel observable (des métiers disparaissent, d'autres apparaissent, des catégories transitoires se font jour etc.). L'analyse de cette question est une voie pour améliorer la gestion des SI (documentation, gestion des versions) : on administre mieux un SI quand on sait qu'il est susceptible d'inclure des concepts ambigus.

Théorie, système d’information et observation

On ne peut construire un SI que si l'on dispose d'une théorie, préalable nécessaire à la définition des concepts selon lesquels on découpera le réel observé puis on effectuera les observations. La théorie est toujours sélective : il existe des aspects de la réalité dont elle ne rend pas compte. Les choix faits lors de la modélisation sont conditionnés par les besoins des producteurs de la théorie (idéalement, de l'entreprise pour le marketing, ou de la société si on considère les théories scientifiques). Les questions relatives à la qualité de la théorie se posent en termes d’adéquation aux besoins (pertinence) et d’économie conceptuelle

Les questions relatives à la qualité du SI se posent en termes sobriété et de cohérence.

La qualité de l'observation effectuée dans le cadre d'un SI se mesure en termes de fidélité de l'application des règles et conventions de codage ; parfois les défauts éventuels de la théorie ou du SI suscitent des difficultés de codage logiquement insurmontables ; la pratique comporte alors un à-peu-près.

Les mesures réalisées dans le cadre du SI apportent des surprises quand elles reflètent des phénomènes que la théorie ne prévoit pas. Alors soit on les suppose non significatives, soit on élabore la nouvelle théorie qui en rendra compte, mais c'est long et pénible. Il est donc naturel, même si c’est parfois regrettable, que les surprises apportées par la mesure soient ignorées quelque temps.

Par ailleurs les besoins changent, donc la théorie évolue. Cette évolution englobe et conditionne celle du SI dont l'évolution est donc plus rapide que celle de la théorie.

Les données de dates différentes ou fournies par des pays différents proviennent de SI relevant de théories différentes. Il est généralement impossible de construire un transcodage parfait. La comparaison ne peut alors se faire qu’au prix d’une approximation.

Au total l’utilisation rigoureuse des données de gestion est plus difficile que celle des données scientifiques. Les codages se diversifient dans le temps et l'espace (c’est pourquoi tout raisonnement économique doit passer par une phase pénible de retraitement des données). Les tableaux statistiques issus de sources différentes sont incohérents car leurs éléments mesurent des réalités différentes. Les données comptables sont de nature diverse selon que la comptabilité observe l’engagement, la facture, le mouvement de trésorerie, le fait générateur, ou encore selon la méthode utilisée pour estimer les données manquantes et corriger les anomalies. Les tableaux de bord des dirigeants occasionnent en réunion de direction de pénibles interrogations : « D’après mes données ça monte, et vous dites que ça baisse ? à la réflexion, cela provient du fait que j’ai consolidé telle filiale, alors que vous vous référez à un autre périmètre, etc. »

L’entropie du système d’information le complique ; elle l’éloigne de la simplicité, de la logique, de la clarté initiales de sa conception, même si les dirigeants croient qu’il leur est resté conforme. La clarté initiale elle-même ne va pas de soi. Tout système d’information est fondé sur une abstraction : il représente les êtres qu’il considère (clients, fournisseurs, produits, personnes de l'entreprise, entités de l’organisation etc.) par des classes[4] dotées d’un nombre fini d’attributs et de règles de gestion ; les valeurs prises par les attributs sont codées selon des nomenclatures choisies en fonction des besoins. La spécification de ces attributs et de ces règles élimine, par son silence, les attributs qui ne seront pas notés, les règles qui ne seront pas appliquées. Or cette simplicité est intolérable pour les personnes qui aiment la pensée compliquée. Elles vont chercher les cas particuliers qui ne se coulent pas dans le modèle et exiger que l’on complique celui-ci pour pouvoir traiter ces exceptions[5]. Leur grand argument est que l’informatique doit se plier à la demande des utilisateurs et non l’inverse (idée juste en général mais utilisée ici de façon perverse).

Ces personnes vont aussi exiger que l’on complique les codages : elles trouveront trop simple de coder un aspect de la réalité selon une nomenclature, c’est-à-dire selon une suite de partitions emboîtées [Marcotorchino]. Elles vont préférer que les rubriques d'un même niveau se chevauchent, que les niveaux se relient par des liens obliques au lieu de s’emboîter.

Elles sont par ailleurs très sensibles à la solidarité entre les diverses parties du monde. Leur intuition, c’est que tout est relié à tout. Si elles avaient à modéliser les phénomènes de gravitation à l’œuvre dans le système solaire, elles ne négligeraient pas l’attraction des autres étoiles. Ainsi elles s’opposent à la modularité du système d’information, au fait que l’on sépare celui-ci en parties entre lesquelles les échanges de messages sont rares. Elles militent pour que le système d'information traite en bloc les divers aspects du métier, ce qui accroît la taille des projets et complique leur réalisation.

[1] Si l’on change de système d’exploitation, il faut réécrire le programme et on le réécrit en entier, y compris les lignes de code qui ne sont jamais utilisées.

[2] Le conseiller de l’ANPE qui vient de trouver un emploi pour un chômeur serait mal venu de retenir celui-ci par la manche pour pouvoir « finir de remplir le dossier » : le dossier reste donc incomplet, et pour une raison parfaitement normale.

[3] Il est naturel que le contrôleur qui vérifie une déclaration fiscale examine soigneusement les données qui déterminent le montant de l’impôt, et qu’il soit moins attentif aux autres.

[4] Nous utilisons ici la terminologie de la modélisation des « objets » : même si cette terminologie est peu satisfaisante, elle est consacrée par l’usage.

[5] « Dans le cadre de mon travail sur des projets d'« e-government », je travaille avec des juristes qui passent leur temps à évoquer les exceptions, les cas qu'on ne peut formaliser, etc. Un jour, en pleine réunion, un de mes directeurs - un des rares qui se distingue par son courage - a mis un terme à la conversation en disant qu'on ne bâtissait pas un système d'information à partir d'exceptions, que si 80% des cas étaient pris en compte, le système était une réussite et que le reste se traiterait manuellement. » (extrait d’un message reçu le 20 juillet 2001).

Exemple 1 : système d’information