Système d'Information

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