# ComLab, un laboratoire de la communication

## Présentation de ComLab, la solution technique de lest.fr

par Elie Perrichon, communication CNRS - LEST, le mardi 16 mars 2021

Initié dans le cadre du projet scientifique du LEST, le projet technique EasyLab avait pour « vocation de favoriser la communication en interne pour mieux valoriser et articuler les différentes activités des membres du laboratoire ; développer le recueil et le maintien d'informations entre acteurs susceptibles de travailler sur les mêmes données ; permettre leur valorisation dans le cadre du projet scientifique du laboratoire (articles, publications, colloques, séminaires, invités, projets de recherches, opérations de communication...) »<fnref n="1" />.

Pour que cet ambitieux projet, adossé au projet scientifique du LEST et intégré à l'ensemble de son projet technique, ne reste pas un vœu pieux, il est dès lors estimé qu'il devra « proposer une solution technique de partage et de centralisation des données qui doit venir s'adapter à l'organisation du laboratoire. »<fnref n="2" /> ; ComLab est cette solution technique ; livrable du projet technique et solution logicielle fonctionnelle et transposable.

Initiateur du projet au LEST, il m'est revenu de le porter et de l'animer. Une fois le travail de recueil du groupe « EasyLab » achevé, j'ai pris en charge l'animation du groupe de travail « Site Web », portant le volet communication externe du projet, et la rédaction du cahier des charges.

C'est à ce point que j'ai réalisé la spécification technique et fonctionnelle de ComLab, toujours en lien avec ces groupes de travail, même en veille, et dont voici les principaux résultats.

## Structure technique

ComLab est conçu comme une solution devant prendre place dans un écosystème logiciel institutionnel, aussi la solution technique retenue correspond aux portails mis en place au CNRS et à Aix-Marseille Université : **Drupal 8** ; et sous la forme d'un **module spécifique** afin de faciliter son déploiement : le **module ComLab**.

Il requiert pour fonctionner un faible nombre de modules contribués, à savoir réalisés par d'autres membres de la communauté Drupal. Le tableau ci-après reprend le détail de la plateforme logicielle, des modules requis par ComLab ainsi que ceux utilisés dans la version actuelle de lest.fr.

Plateforme logicielle

Modules requis par ComLab

Modules lest.fr

Drupal 8.9.13 /

Chaos Tool Suite (ctools), Dynamic

Admin Toolbar, Backup and Migrate,

Bootstrap 3.23

Entity Reference, Entity API, Entity Reference Revisions, Group et

Bootstrap Layouts, Pathauto, Scheduler, VariationCache, Views Bootstrap, Views

<footnote n="1">¹ LEST, *Dossier d'évaluation du contrat pluriannuel 2011 – 2016*, p.44, Aix-en-Provence, septembre 2016.</footnote>

<footnote n="2">² Ibid</footnote>
Nginx 1.19.7

Php 7.3

Mariadb 10.3 Token.

Infinite Scroll et Visitors.

Redis 6.2.

Etant donné la baisse de contribution à la communauté Drupal suite à la montée de la version 7 à la version 8, le nombre des modules contribués supplémentaires retenu est faible et concerne pour l'essentiel des modules extrêmement fréquents dans l'environnement Drupal.

Le fonctionnement du module ComLab reposant sur des formats de données qui lui sont propres pour l'essentiel, il est compatible *a priori* avec un large nombre de modules. Aucun des modules installés, y compris à des fins d'évaluation, n'a rencontré de problèmes de compatibilité.

## Ecosystème logiciel institutionnel

L'enseignement supérieur et la recherche, à l'origine du Web tel que nous le connaissons, reste un acteur extraordinairement dynamique qui propose de nombreux sites et services. ComLab vient s'intégrer à cet environnement en collectant les publications par l'*API HAL* , en référençant les *carnets hypothèses*, plateformes *sciencesconf.org* et de nombreuses ressources du *Cairn* ou d'OpenEdition.

Ouvert sur le monde et l'international, il intègre les réseaux et médias sociaux « grand public » comme scientifiques et référence les institutions selon leur proximité académique avec le LEST. Développer l'intégration de ComLab et élargir son écosystème sont des points forts de progression envisageables, notamment par la création d'endpoint, la collecte de données sur les systèmes des fonds documentaires ou bibliothécaires, la collecte sur *theses.fr*, l'intégration du ou des CAS AMU/CNRS/Eduroam, le versement de données de système de gestion, etc. Les opportunités et les possibilités sont nombreuses.

## Modèles de données

A la spécification, je considère trois grands types de données :

* Les **acteurs** : Personnes physiques et morales ;

* Les **modalités** : Axes de recherche, activités scientifiques, projets de recherche et thèses ;

* Les **produits** : Publications.

Les **acteurs** comportent les entités « **Person** » et « **Institution** », dont voici le détail technique :

### Person

### CV

* Visual

* Person > Person

* First name

* Text - revision

* Last name

* File

* Name (F + ‘ ‘ + L)

* Nationality

* Gender (N, F, M, O)

* Focus > Focus
## Contact Person

* Category

* Discipline

* Tags

* Person > Person

* Type

* Data

* Weight

Le modèle de données « Person » est séparé du « CV », qui n'est créé que pour les membres permanents et contractuels du laboratoire. L'entité « Person » peut être ainsi mobilisée pour n'importe quel acteur sans nécessairement autoriser un accès ou nécessiter un CV. Le CV est constitué d'un champ texte long, prenant en charge les révisions, ainsi que d'un dépôt de fichier PDF.

Attendu l'évolution et le nombre des outils de communications actuels, les données de contact des personnes, comme pour l'ensemble des données contact, sont libres dans leur quantité et leur qualité ; celles-ci sont définies dans une table dédiée afin d'être traitées – contrôlées, transformées et mises en forme – dans le code. Un poids leur est associé afin que l'internaute puisse les ordonner à sa convenance. Nous verrons plus loin comment le type de données associé au contexte de l'entité permet des traitements assez fins.

## Institution

* Visual

* Acronym

* Name

* Type (int)

* Localization

* Tags

## Institution Institution

* Institution

* Type

* Institution

## Contact Institution

* ...

L'entité « Institution » a pour particularité de proposer un « Type » qui, comme pour les contacts, est défini dans une table spécifique que nous verrons plus loin. Elle comprend surtout une table de relation à elle-même « Institution Institution » qui permet de définir les relations entre les institutions ; une liste récapitulative des référentiels définis est disponible en annexe.

« Institution » est complétée par une table « Place » qui permet de définir différents sites physiques auxquels peuvent être associées une « Address » ainsi que des « Room » comportant différents types de salles (Conference, Meeting, Office) ainsi qu'une jauge.

Les modalités considérées sont : « Focus », les axes de recherche ; « Event », les activités scientifiques ; « Session », les séances de ces activités ; « Project », les projets de recherche et « Thesis », les thèses.

### Focus

### Event

### Session

### Project

### Thesis

* Acronym

* Name

* Description

* Visual

* Acronym

* Name

* Description

* Focus > Focus

* Visual

* Name

* Datetime Begin

* Datetime End

* Visual

* Acronym

* Name

* Date Begin

* Date End

* Description

* Visual

* Title

* Phd student > Person

* Direction > Person
* Type

* Localization

* Tags

## Event Contact

* ...

## Event Project

* Event

* Project

* Description

* Places

* Room

* Localization

* Tags

## Event Session

* Event

* Session

* Focus >

Focus

* Funds

* Localization

* Tags

## Project Contact

* ...

* Co-direction
> Person

* Phd School

* Date Begin

* Date End

* Summary

* Focus >
Focus

* Funds

* Localization

* Tags

Les entités « Session » consistent en un temps d'une ou plusieurs activités scientifiques auxquelles elles sont liées par la table « **Event Session** », afin d'associer plusieurs séances à une activité et plusieurs activités – co-animation – à une séance. Naturellement, les séances sont définies par un temps et un lieu, ce dernier consistant à l'affection d'une « Place » et éventuellement d'une « Room » associée à une « Institution ». Les « Session » sont également transposables en temps de travail spécifique (Assemblée générale, conseil du laboratoire, réunion,...) afin de prendre en charge les temps de vie du laboratoire sur le volet Intranet.

Les « Event » sont dotés d'un « Type » afin de différencier les séminaires des colloques ou, comme nous venons de le voir, des réunions. Elles peuvent être associées au « Project » par une table dédiée « **Event Project** ».

« Project », initialement défini pour gérer les contrats de recherche, a été étendu et permet désormais de présenter un large nombre de travaux réalisés par *n* « Person » en relation avec *n* « Institution » sur une période donnée.

Les « Thesis » mettent pour leur part en évidence l'ensemble des liens directs avec les « Person », par les champs *Students*, *Direction* et *Co-direction* et les « Institution », par les champs *Phd School* ou *Funds*.

Les produits de la recherche sont les publications. Si nous nous sommes logiquement appuyés sur HAL pour gérer ces données, nous avons toutefois défini une entité « **Publication** », en collaboration la documentation, afin de garantir son adaptation au standard de la documentation.

## Publication

* Visual

* Title

* Subtitle

* Date

* Description

* Publisher

* DOI

* ID HAL

* ID Zotero

* Type

* Focus

* Disciplines

* Localization
* Tags

Cette entité a pour vocation de gérer les publications qui représentent une importance particulière dans une logique de communication, mettant en avant les visuels et les membres de l'unité à destination de la rubrique « Vient de paraître ».

Hors de ce système dédié à la communication de notre unité, l'ensemble des publications est collecté via l'API HAL selon les logiques suivantes :

* Toutes les publications : collecte parmi la collection LEST de HAL des documents – Article, Communication, Poster, Ouvrage, Chapitre d'ouvrage, Direction d'ouvrage, Autre, Rapport, HDR et Thèse – des plus récents au plus anciens. Des filtres et solutions de tris seront proposés.

* Personne :

* Si un identifiant HAL a été indiqué, l'ensemble des publications associées est collecté sur HAL.

* Sans id HAL, le système reconstitue un identifiant possible sinon probable – nom et prénom en minuscule, reliés par un tiret court – et effectue une tentative de collecte ;

* Si elle échoue, il effectue enfin une recherche par auteur à ce nom et prénom parmi la collection LEST de HAL et elle seulement ;

* Projet : Collecte sur la base de l'identifiant HAL de la collection propre au projet ;

Pour ces deux dernières solutions, des paramètres de tri et de filtre seront proposés dans les outils d'administration des pages « Person » et « Project ».

Nous voyons ici comment le système soutien et valorise les participations à l'écosystème logiciel institutionnel, ici HAL, en améliorant la qualité des données pour les membres et les projets qui y contribuent.

## Relations entre les données

ComLab propose deux grands types de relations, directes, conventionnelles d'entité à entité, et articulées par un terme signifiant, selon le triplet « sujet - verbe - complément » caractéristique du Web Sémantique.

Ces **relations articulées** permettent d'associer les entités selon un terme signifiant sur la nature de cette relation. Hors de rares champs dédiés, comme nous l'avons vu avec les données de « Thesis » qui qualifie la relation des « Person » à la thèse, le système s'appuie sur deux tables aux vocations similaires : « Work » et « TypeInfo »

« Work » comporte le référentiel des différentes relations de travail qu'une « Person » peut entretenir avec les « Institution », mais aussi les « Event », « Session », « Project » et « Publication ». Ces relations sont établies au sein de la table « Attribution » pour une période donnée, comme représentées dans le schéma relationnel ci-après dans les relations avec les Institutions.
<figure><img src="image_1.png" /></figure>

« TypeInfo » comprend non seulement les mêmes référentiels pour les relations entre « Project » et « Institution », « Event » et « Institution », « Institution » et « Institution », mais aussi l'ensemble des typologies utilisées pour qualifier nos données (Genre, Type de contact, Type d'activités, etc,...). Pour rappel, les référentiels constitués sont disponibles en annexe.

Ces relations nous permettent d'associer de manière signifiante l'ensemble de nos modèles de données et de restituer ces liens dans différents contextes de consultations : projets portés par un membre ou une institution, institutions contributrices d'une activité, thèses dirigées, etc. Ce qui permet, d'une part, un maintien simplifié des données et, d'autre part, de valoriser, encore une fois, les contributions des acteurs ; sur ce point nous constatons avec satisfaction une nette amélioration de la visibilité du travail constant des équipes IT.

Notons aussi qu'un champ *Lang* est présent dans les tables « Work » et « TypeInfo », car cette logique d'articulation nous autorise à proposer un contenu signifiant dans différentes langues sur la base de la traduction de moins de 200 termes.

La prise en charge de la féminisation des professions faisant partie des développements prioritaires, ce registre sera probablement multiplié par deux sinon trois, la table « Work » intégrant à côté du champ *Title*, comprenant la forme neutre, les champs de l'attribution au masculin et au féminin, l'accord étant assuré par le choix de *Genre* établi par les « Person » dans leur profil.

Les relations directes sont utilisées pour les appartenances aux axes de recherche de l'unité – entité « Focus » – organisant ainsi le contenu autour du projet scientifique de l'Unité, ainsi que pour offrir une navigation transversale thématique, via les mots-clefs « Tags », la localisation géographique, « Localization », ou encore disciplinaire, « Discipline ».

Ces relations nous permettent de favoriser une navigation libre parmi les contenus tout en multipliant et diversifiant les points d'ancrage avec la culture de nos utilisateurs.

## Gestion éditoriale

Les données ainsi organisées sont simples à distribuer dans l'arborescence d'un site et propose une quantité et une qualité de contenu extrêmement satisfaisante, ci-après la manière dont ils sont incorporés au site lest.fr :
<figure><img src="image_2.png" /></figure>

Une couche éditoriale permet de publier des articles associés à une de nos données (article sur la parution d'une publication, l'arrivée d'un membre, la clôture d'un projet,...) Elle offre toute la latitude nécessaire au développement d'une communication institutionnelle, et permet de choisir à quel moment et à quel propos tel modèle de données sera mis en avant.

<figure><img src="image_3.png" /></figure>

Cette couche constitue une manière supplémentaire d'accéder aux données, dont la gestion et l'organisation sont destinés aux services communication.

Cette couche comprend aussi l'édition des URLs du site Web ; les données et leur type peuvent être croisés pour composer des contenus et des URLs **optimisés pour les moteurs de recherche** ; le référentiel sémantique constitué étant signifiant – constructeur de sens et susceptible d'être recherché – et largement rependu sur l'ensemble du site.

La solution technique ainsi proposée autorise à consacrer **moins de temps au maintien des données**, dont la qualité globale sera logiquement meilleure, ainsi qu'à leur duplication dans différents espaces du site (ex. : date de fin de thèse : Thèse, Doctorants, direction, etc..) pour **permettre au communicant de se mobiliser sur le cœur de son métier**, le déploiement d'actions de communication et le développement de contenu ; les **missions proposées sont ainsi plus attractives** que celles consistant à démultiplier la même information avec force copier/coller en association à des relectures fastidieuses.
# Intranet

L'intranet, accès à des fonctionnalités et services réservés aux membres défini selon les droits et opportunités, a été spécifié et réalisé dans un second temps.

L'accès à l'**intranet** n'est permis qu'aux **membres de l'unité**. Toutefois, les fonctionnalités de mise à jour des données de profil et contact sont accessibles à toute personne identifiée dans le système et associée à une adresse électronique.

Lors de la création d'un compte, le système vérifie si l'adresse électronique existe dans la table des contacts des personnes et dans l'affirmative crée un utilisateur associé, s'il n'existe déjà. Dans tous les autres cas, l'accès est refusé si ce n'est à l'administrateur. Bien entendu, une validation du compte par envoi à l'adresse électronique est requise pour valider l'utilisateur créé ou modifier le mot de passe.

Une fois le compte créé, les droits sont attribués à chaque authentification toujours selon les appartenances, statuts, fonctions, missions et responsabilités établis pour la « Person » titulaire de l'adresse électronique dans le système. Ainsi une modification d'un de ses éléments, implique une modification instantanée de droits de l'utilisateur associé.

Les droits sont accordés selon 2 domaines :

* Les **entités** : visibles publiquement, dont les droits sont établis par relations à l'entité ;

* Les **documents partagés** : à la visibilité publique ou spécifique et dont les droits sont établis par la ou les fonctions ;

Pour les entités, la logique est commune à l'ensemble de l'affectation de ces droits, ce sont les relations « **Attribution** » associées à la « **Person** » qui établissent les droits d'accès aux entités. L'affectation des droits ici présentée a été établie pour une unité d'une centaine de membres, pour une équipe IT de 10 personnes ; il est envisageable, sinon tout à fait nécessaire, d'affiner ces droits dans des unités plus importantes.

Les droits d'accès aux entités vues en début de ce texte sont établis selon les relations des personnes authentifiées à ces données, ce qui permet une grande souplesse dans la manière dont les droits sont attribués. Ils sont définis de la manière suivante pour le site du LEST :

* Accès en modification des données dites de profil – Etat civil, axe d'appartenance et contact – par l'adresse électronique : elle établit la relation entre l'utilisateur authentifié et ses données ;

* Accès en modification au CV si la personne est membre de l'unité au moment de la consultation ou si le CV existe déjà, ceci afin d'éviter les dépublications brutales aux dates de fin de contrat ;

* Accès en modifications au « Focus » pour les « Person » ayant l'attribution « Responsable d'axe » et affiliées à l'axe correspondant ;

* Accès en modification aux « Event » et « Project » pour les « Person » dans l'équipe de coordination ou les celles possédant la fonction « Communication » parmi l'équipe administrative ou technique ;

* Accès en création et modification aux « Session » pour les « Person » identifiées dans l'équipe de coordination de ou des « Event » parents ;

* Accès en modification aux « Publication » pour toutes « Person » en relation avec l'entité ;
* Accès en modification aux « Thesis » pour les « Person » mentionnées en tant que « Phd Student » ;

* L'ensemble des données sont accessibles en création, modification et suppression par la ou les « Person » ayant la fonction « Communication » au sein de l'unité ;

Une fois encore s'applique la logique qui vise à inciter et à valoriser les **contributions**, en accordant des droits selon les relations visibles et, à l'inverse, nécessitant ces relations pour se voir attribuer les droits.

L'attribution des droits pour la gestion des documents partagés repose sur le module *Group* par lequel sont définis les groupes de travail et les différents rôles au sein de ceux-ci. ComLab, pour sa part, établit les correspondances des « Attributions » avec les groupes de travail et rôles disponibles, sur une association terme à terme (ex. : Fonction « Ressources Humaines » avec rôle « Ressources Humaines », Responsabilité « Conseil du Laboratoire », etc...).

Ces accès en création, modification et suppression concernent les parties « Services et Ressources » et « Vie du Labo ».

## Services et Ressources

La rubrique « Services et Ressources » répond aux besoins de **diffusion des documents et ressources** produits par les services ou ceux des tutelles de l'unité.

ComLab permet à chaque membre ayant une attribution « Fonction » au sein de l'unité, de créer, modifier ou supprimer un format d'article spécifique pour sa ou ses fonctions et elles seulement.

Deux portées sont possibles : **tout public ou membre seulement**. La première permet de déposer directement en ligne des documents accessibles à tous (ex. : Logo de l'unité basse définition, organigramme,...), la seconde des documents accessibles aux membres authentifiés seulement (ex. : Logo haute définition, Livret d'accueil,...). Ces articles prennent en charge les révisions et le dépôt d'un ou plusieurs fichiers aux formats prédéfinis (pdf, doc, docx, txt, jpg, gif, png,svg). Ils sont visibles, accessibles et ordonnés par fonction sous la rubrique « Services & Ressources ».

A noter que le choix réalisé pour l'Intranet du LEST consiste à publier les articles au nom du service et non en nom propre, les membres authentifiés au sein du même service ont les mêmes droits sur l'ensemble des documents publiés par celui-ci. Les services sont libres de diffuser directement leurs articles sans étape intermédiaire de validation. Une toute autre approche aurait été possible, celle-ci vise à responsabiliser les contributeurs, faciliter la transmission et fluidifier la diffusion avec un contrôle exercé a posteriori.

## Vie du Labo

Il s'agit de la rubrique de mise en disposition des comptes-rendus des différentes instances de l'unité et accessibles à ses membres seulement.

Cette partie repose sur la définition des différentes instances au sein du module *Group* et de leur recoupement avec les attributions par ComLab. Pour le LEST les instances suivantes ont été définies :

* Assemblée Générale
* Conseil du Laboratoire

* Conseil des Axes

* Comité Stratégique

Le modèle d'entité « **Session** » a été étendu dans un **format à la portée limitée aux seuls membres** de l'unité et associé systématiquement à un type de « Event » « Activité interne ». Celui-ci a pour particularité de n'être visible qu'aux membres de l'unité. Le type « Réunion interne » n'est visible pour sa part que pour les « Person » associées à la « Session » créée.

Chaque instance ayant une importance pour l'ensemble des membres du labo dans ses activités,
elles sont affichées dans l'agenda de l'unité en page d'accueil aux membres authentifiés. Une fois la
séance passée, les utilisateurs ayant les droits appropriés peuvent déposer le compte rendu dans la
séance correspondante.

## Agenda et salles partagées

Etendre l'entité « Session » à différentes portées permet, en association avec les informations de
lieu – Places – et de de salle – Room – de **gérer l'agenda et la disponibilité des salles**.

Comme nous l'avons vu dans les modèles de données, les « Institution » peuvent être associées à une ou plusieurs « Places » auxquelles peuvent être affectées des « Room », ces dernières définissant bien entendu les différentes salles disponibles sur le lieu en question. Attendu que les séances des activités sont définies au sein de ces « Session », la diffusion de l'information comprend également la réservation de la salle correspondante.

En étendant l'entité « Session » aux temps collectif des instances de l'unité puis à tous temps de
réunion ou d'activité occupant un lieu, il est possible d'établir le temps d'occupation d'un espace
donné. Dans sa logique intégrative, **ComLab prend à charge la gestion partagée d'un lieu,**
**diffusant l'information selon le type d'activité auprès des personnes concernées.**

## Fonctions « Communications »

Par son aspect « **laboratoire** », ComLab a vocation à offrir continuellement de nouvelles
fonctionnalités, définitives ou à des fins d'évaluation. Aussi, aux outils déjà évoqués, différentes
fonctionnalités conventionnelles ou singulières sont ou seront développées en bénéficiant de cette
logique intégrative.

La **Newsletter** de l'unité peut ainsi être éditée par la compilation sur une période, correspondant à la fréquence de parution, des articles ou données publiés sur la période passée et des évènements prévus sur la période à venir. Un article dédié à chacun des numéros peut éventuellement y être associé.

**Organigramme** et **trombinoscope** peuvent être générés selon la même logique : les rôles clefs (fonctions, missions et responsabilités) étant définis dans le système, ils peuvent être utilisés pour générer un organigramme des différentes instances de l'unité comme des équipes. La page « Partenariats » est générée sur ce modèle.

L'édition et la publication dans différents formats est aussi une fonctionnalité réaliste, afin de
générer automatiquement des affiches des activités ou projet au format PDF, prêt à l'impression, ou
de relayer sur les écrans d'information de l'unité les séances en cours ou à venir.
Des billets adaptés aux réseaux sociaux, Facebook, Twitter ou LinkedIn sont susceptibles d'être réalisés sur la base des données intégrées croisées avec des modèles, ou pattern, d'articles.

Un système de veille, par alertes ou RSS, sur les actualités ou publications des « Person », ou étendues à l'ensemble des modèles, pourrait être aussi intégré afin de de nous rapprocher d'un bureau unique de la communication.

## Initialisation & extraction

Etant seul à spécifier et développer l'outil tout en exerçant mes activités de communicant de l'unité, un système **d'import massif des données par fichier CSV** a été nécessaire à son initialisation. Il permet d'importer « Institution », « Person », « Project », « Event », « Session » et « Thesis », un contrôle du format des fichiers et de la qualité des données doit être rajouté afin de le rendre tout à fait opérationnel.

A l'inverse, les documents et tableaux Excel de l'évaluation HCERES ayant également guidés cette spécification, ComLab devra permettre **l'extraction des données au format requis par l'instance d'évaluation**. Les données intégrées tout au long de la réalisation du contrat peuvent être extraites selon leur date, l'axe, comme l'ensemble des thèses dirigées. Permettre la restitution des données d'évaluation tout en autorisant une communication agile est probablement un des principaux atouts de la solution technique.

## Stratégies de déploiements

Tout au long de sa spécification comme du développement, j'ai toujours eu en tête l'idée de déployer plus largement cette solution. Aussi, sans présager des faisabilités techniques en termes d'infrastructure, ComLab pourrait être déployée selon trois stratégies différentes :

* Une approche par site, le système est déployé unité par unité, le versant Intranet étant adapté à la gouvernance et aux services de celle-ci ;

* Une seconde approche, serait d'ajouter à la démarche précédente un référencement et une reconnaissance des applications sœurs afin d'effectuer des renvois mutuels entre les systèmes selon l'appartenance des membres ou les différentes opportunités de synergie ;

* Une troisième approche consisterait à constituer un modèle des données Acteur/Modalités/Publications centralisé, partagé et maintenu par l'ensemble des sites commun à un institut en particulier. La couche éditoriale et l'intranet seraient adaptés et gérés par chacune des unités.

## Remerciements

Je tiens à remercier toutes les personnes qui ont accompagné le projet sur un temps ou tout au long de sa complexe et captivante réalisation, et plus particulièrement Thierry Berthet, Nathalie Besset, Laurent Giglio, Xavier Joutard, Jocelyne Martinière-Tesson, Philippe Méhaut, Delphine Mercier et Amandine Pascal.