Tout d’abord, les domaines d’application ont déjà été abordés de manière informelle dans le chapitre 1 de la partie A de ce rapport, intitulé «Cas d’utilisations ». Nous ne pourrons donc pas éviter un certain nombre de redondance. Il nous faut cependant tenter de définir la manière dont un domaine doit être abordé pour être caractérisé. Nous avons retenu un certain nombre de critères (nom, définition, domaines d’application secondaire, fonctionnalités transverses, méthodes et modèles associés, normes associées, logiciels typiques évalués ou aperçus, Informations cibles, clients typiques, projets phares, organisations phares - institutions) qui sont ceux qui ont été retenus lors de notre étude préliminaire (cf. section « CONTEXTE, OBJECTIFS ET APPROCHE » p 4). Ce sont ces
éléments que nous allons maintenant aborder.
Les informations recueillies pour chaque critère sont partielles, ne peuvent prétendre à l’exhaustivité et sont données à titre d’exemples afin d’approcher la couverture de chaque domaine et leur donner une consistance. D’autres exemples pourraient donc certainement compléter notre approche. Les frontières de chaque domaine ne sont pas non plus nécessairement figées et donnent lieu à des interprétations divergentes en fonction du contexte dans lequel se place l’utilisateur.
Notamment les fonctionnalités transverses sont des fonctionnalités que l’on retrouve dans plusieurs domaines de la gestion de contenu mais aussi dans d’autres domaines informatiques. Nous les avons retenues comme s’appliquant principalement à un domaine selon qu’elles aient été initialement conçues dans le domaine, qu’elles y soient utilisées massivement voir selon qu’elles soient obligatoires pour pouvoir caractériser le domaine. Toutefois, ces fonctionnalités transverses apparaissent bien comme autonomes dans la section 1.1.3 relative aux sous-domaines. Cela est vrai aussi pour notre approche d’autres critères comme les méthodes et modèles associés.
Notre approche des domaines est d’abord fonctionnelle, notamment d’un point de vue informatique, mais elle est aussi sociologique et économique (institutions, projet phare, client typique, logiciels typiques). Afin de rendre l’information plus synthétique, nous présentons les informations du domaine sous forme de tableau.
Nous pourrions nommer les sous-domaines « modules ». Nous aurions alors une approche de l’architecture fonctionnelle des systèmes de gestion de contenu de type « domaine / module / fonctions » (DMF). Notre approche n’est cependant pas aussi rigoureuse. Les sous-domaines pourraient aussi être assimilés à des domaines et les fonctionnalités à des modules ; car en fait, derrière les fonctionnalités que nous présentons, certaines sont suffisamment générales pour comprendre concrètement tout un ensemble de fonctions. Notre approche est donc une approche fonctionnelle à quatre niveaux, avec un recoupement possible des niveaux (les domaines et sousdomaines) et une description formelle du dernier niveau (les fonctions) peu détaillée ou développée. Il s’agit donc d’une approche pragmatique dont l’objectif est d’être suffisamment synthétique pour pouvoir être appréhendée. Elle présente aussi l’avantage de rendre comparable des logiciels éditeurs de gestion de contenu qui affichent des fonctionnalités dans leur présentation en cachant toutefois les détails précis de mise en oeuvre.
Les fonctionnalités permettant de caractériser et classifier les systèmes de gestion de contenu présentées ci-dessous sont au nombre de 80 fonctionnalités environ.
La section 1.1, outre cette introduction, présente donc les domaines d’applications de la gestion de contenu, les diverses fonctionnalités de la gestion de contenu et enfin offre en guise de conclusion une proposition de grille de classification des logiciels de gestion de contenu par domaine d’application.
