L’échange de documents entre CMS est un autre des éléments de productivité que peut proposer un CMS pour rendre réel le concept d’entreprise étendue, cher aux promoteurs des portails d’entreprises (cf. chapitre 1.5 « Portail informatif »).
Le format d’échange des données entre les systèmes est par définition dépendant du format de stockage de ces données. Il est cependant toujours possible de transposer un document d’un format vers un autre, s’il n’y a pas de perte d’information entre les deux formats, c’est à dire si le format d’échange n’est pas moins riche que le format d’origine. Cela a toutefois un coût au développement et pendant l’exploitation du CMS. Or si nous ne rappelons ce qui a déjà été dit en introduction de la section 2.1, XML est un langage complètement approprié à l’échange de données informatisées. On peut donc faire la remarque qu’une architecture native de CMS intégrant XML favorisera la simplicité du système. Nous avons fait référence à la proposition de norme de l’APROGED, l’EIDE, qui est un exemple de format d’échange de documents [17] utilisant XML.
L’échange de données informatisées (EDI) est une fonction fondamentale d’un CMS puisqu’il concerne la capacité du système à importer des ressources et à les exporter dans un second temps. Cette capacité d’importation des systèmes est centrale lors de la première mise en oeuvre d’un CMS et qu’il faut importer dans le système « l’héritage » documentaire de l’organisation, c’est à dire tous les documents créés avant l’implantation du CMS et que l’on veut y intégrer.
Il y a une limite à l’échange de documents entre systèmes de gestion de contenu même lorsque les formats d’échange sont harmonisés. Il s’agit du contenu à proprement parler des méta données. Il faut que celui ci soit sémantiquement compatible. Par exemple, le schéma de classification du sujet des documents doit être le même ou transposable. Ou encore certaines méta données présentes dans le système cible et absentes dans le système source devront alors être éditées spécifiquement suite à l’import des documents. Le protocole d’EDI permet donc l’échange de document mais ne suffit pas à garantir l’harmonisation des modèles de chaque méta donnée. Il faut donc aussi veiller à cet aspect là.
La collecte de composants documentaires passe par leur création à partir du système de gestion de contenu (c’est l’objet des sections 3.1.1 et 3.1.2) mais aussi par leur acquisition à partir de systèmes « partenaires » ou encore systèmes tiers. C’est ce type d’acquisition, l’importation, qui fait l’objet de ce chapitre.
Il y a plusieurs formes dans l’acquisition : la duplication (avec appropriation) ou la réplication.
Lorsqu’il y a duplication, le système qui importe le document se l’approprie. C’est à dire qu’il intègre le document et ses méta données à son référentiel. Il aura donc la charge de maintenir le document. Par contre dans le second cas, le CMS importe les méta données du document « importé », mais pas le document lui-même, qui reste accessible uniquement à partir du système d’origine. Dans certains cas, pour des raisons de performances du système notamment, le document peut être répliqué, mais il est dépendant du système d’origine qui répercute les modifications sur son double. C’est pourquoi on parle de réplication, ou encore de synchronisation. Remarquons encore que la charge de vérifier la cohérence de la copie avec son original peut être sous la responsabilité du système intégrant la copie. Dans tous les cas, les systèmes doivent savoir communiquer entre eux suite à la fédération du document.
Quand un CMS réplique et agrége plusieurs documents de plusieurs sources 36, on parle de syndication 37. Dans le chapitre ci-dessous intitulé RDF Site Summary (RSS) un exemple de langage permettant de syndiquer des documents publiés sur des sites Web est présenté.
36 système source : système d’origine où sont créés et maintenus les documents.
37 Syndication : terme d’origine anglo-saxonne. Certains parlent parfois de fédération ou d’agrégation.
