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