Retour d'expériences sur une centralisation de messagerie et de la mise en place d'outils collaboratifs à l'Inserm
Patrick Lerouge, Laurent Moizo, Guillaume Stevens, Julio Martins
Inserm - DSI – Pôle infrastructures
Hôpital Paul Brousse, 16 avenue Paul Vaillant-Couturier 94807 Villejuif
Louis Réchaussat
Inserm - DSI
101, rue de Tolbiac, 75654 Paris Cedex 13
Résumé
L'Inserm a entrepris, à partir de juin 2006, la centralisation des messageries établies dans ses 14 délégations régionales.
Après avoir fait une revue de l'état de l'art durant l'été 2006, un appel d'offres a été publié fin 2006.
La solution retenue a été OBM1 de la SS2L AliaSource. Seule solution soumise entièrement sous GPL, elle présentait l'avantage de reposer sur des briques logicielles maîtrisées : LAMP, Cyrus Imap, Postfix.
OBM a permis à l'Inserm pour un coût maîtrisé de :
Centraliser la messagerie de 12000 utilisateurs ;
Maintenir une administration fonctionnelle auprès de nos responsables informatiques en région et au sein des laboratoires de recherche ;
Alimenter un annuaire d'entreprise sur lequel s'appuie, entre autres, la messagerie ;
Offrir des outils de travail collaboratif à nos utilisateurs.
La présentation explique le choix, la participation de l'équipe de l'Inserm à son développement, le retour d'expérience sur sa mise en production (début 2008) et les évolutions prévues.
Mots clefs
Retour d'expérience, messagerie électronique, groupware, travail collaboratif, logiciels libres, LDAP, Sympa, Postfix, Cyrus Imap, OBM, plan de reprise d'activité, conduite de changement.
L'Institut National de la Santé et de la Recherche Médicale (Inserm), pour gérer ses 318 unités de recherche, est structuré administrativement en 13 délégations régionales auxquelles s'ajoute le Siège. Au sein de ces délégations, le Département du Système d'Information met à disposition 39 agents : responsables régionaux (RRI), responsables de site (RIS) et techniciens (TI) regroupés dans des délégations régionales du système d'information (DRSI).
Les unités de recherche de l'Inserm sont toutes mixtes (universités, CNRS, Institut Pasteur, ...). Environ 13000 personnes travaillent dans ces structures et parmi elles 6500 sont des statutaires de l'Inserm.
Les services de messagerie électronique de l'Inserm instaurés dans les années 90 étaient implantés dans chaque région et étaient gérés par les équipes informatiques régionales. Ils utilisaient à l'origine des plateformes SunOs®.
En 2001, ces plateformes ont été rénovées et ce fut l'occasion d'introduire le logiciel libre dans le système de production informatique de l'Inserm. Chaque région avait été dotée de 5 serveurs de base Intel, animés par Linux Redhat v7.2. Les briques constitutives choisies étaient Postfix, UW-IMAP et BIND pour le DNS. Pour prendre en compte la mobilité des utilisateurs, un webmail a très tôt été ajouté par les DRSI et suivant les cas Squirrelmail ou IMP-Horde ont été choisis. L'arrivée des virus dans la messagerie électronique a motivé l'intégration d'un filtrage des flux SMTP ; une solution logicielle propriétaire a été adoptée : Trendmicro InterscanVirusWall®, remplacée par Sophos PureMessage® avec l'arrivée des spams.
Certaines DRSI, par ailleurs, avaient fait le choix de déléguer tout ou partie de la gestion de leur messagerie à l'université partenaire, sous nommage Inserm ou non.
Fin 2006, près de 8000 comptes de messagerie étaient recensés ; les adresses de messagerie utilisées tenaient compte de l'implantation régionale, ainsi elles étaient associées à un domaine délégué de « inserm.fr » comme « lille.inserm.fr », « bordeaux.inserm.fr », etc. La partie nominative de l'adresse de courriel, héritait la plupart du temps du login Unix des systèmes Sun limité à 8 caractères.
En résumé, près de 8000 comptes de messagerie utilisant près de 35 domaines Internet étaient gérés via 15 systèmes de messagerie par une trentaine d'agents qui avaient à administrer 85 serveurs.
En 2006, s'est posée la question du renouvellement du parc de ces serveurs qui étaient en fin de vie. Le DSI devait statuer entre un remplacement des systèmes régionaux ou centraliser la messagerie.
Les arguments motivant une centralisation de la messagerie étaient évidents :
du point de vue financier, le remplacement des 15 systèmes en région et de la logistique à mettre en place, aurait d'évidence eu un coût plus élevé que celui d'un système centralisé. S'il s'agissait d'un simple remplacement, il n'y aurait eu aucune valeur ajoutée aux services délivrés aux utilisateurs ;
décharger les équipes régionales des soucis liés à l'administration des systèmes, ces équipes pouvant difficilement assurer une continuité de service par manque d'effectifs. La charge de travail de ces personnels ainsi allégée pouvait être réaffectée à des tâches plus en proximité des structures de recherche ou de leur évolution « métier » ;
les serveurs de messagerie n'étaient pas implantés dans des infrastructures de qualité homogène en région. Ces infrastructures que sont les salles serveurs et leurs sécurités d’accès, les réseaux desservant les sites, les alimentations électriques, les conditionneurs de froid et les dispositifs de sauvegarde étaient qualitativement très hétérogènes. De plus, dans certains cas il n’existait pas de contrat de maintenance sur l’un ou plusieurs des maillons de ces infrastructures ;
les infrastructures informatiques centrales de l'Inserm présentaient toutes les qualités requises pour l'accueil de ce service : la possibilité d'intégrer la messagerie dans un plan de reprise d'activité (PRA) y était possible ; le double rattachement réseau à l'Internet était également un argument ; la supervision des services est assurée par du personnel qualifié sur des plages horaires étendues (6h30-20h) ; l’administration « système » est sous la responsabilité d’une infogérance, ce qui permet d’affirmer que la continuité de service peut être garantie contractuellement ;
la qualité (fiabilité et amélioration des débits) des réseaux (RENATER et réseaux métropolitains) ayant considérablement évolué permettait d'envisager cette centralisation ;
la mobilité, le nomadisme et le besoin de travailler en groupe des utilisateurs nécessitaient d'apporter des services supplémentaires. La convergence vers les nouvelles technologies devait être prise en compte.
D'autres raisons de nature stratégique motivaient cette décision de centraliser la messagerie : consolider des référentiels de structures et des personnes ; constituer un annuaire Ldap national et des annuaires dérivés, maîtriser les identités en vue de déployer des solutions SSO, permettre à la direction générale, aux services centraux et aux délégations régionales d'améliorer la diffusion de l'information aux agents.
Il était important de prendre en compte la proximité des DRSI avec les structures de recherche ; aussi l'administration fonctionnelle devait rester en région, au plus près des utilisateurs.
La prise en compte des besoins des utilisateurs était primordiale :
disponibilité du système, fluidité des échanges qui deviennent de plus en plus importants ;
prise en compte du parc informatique hétérogène : Mac, Windows et Unix ; des clients de messageries différents Thunderbird, Outlook, Entourage et AppleMail ;
ajouter des fonctionnalités de base accessibles aux utilisateurs : répondeur, renvoi de courrier, possibilité de changer de mot de passe, partage de boite de messagerie, listes de diffusion ;
sécurité (antivirus et antispam), signature électronique et cryptage des échanges.
Pour le respect de la notion de service, la transparence pour l'utilisateur de cette migration des comptes était une contrainte évidente, de même que la faculté d'opérer un « retour arrière » en cas de difficulté. L'émergence de nouvelles technologies et des besoins de travailler en groupe convergeaient vers des nouveaux services à proposer aux communautés scientifiques et administratives de l’Inserm :
contacts et agendas personnels et partagés ;
gestion de ressources, salles, matériels... ;
synchronisation avec des assistants numériques personnels (PDA) et téléphones mobiles ;
accès aux données par téléphonie mobile ;
messagerie instantanée ;
gestionnaire de tâches ;
Ceux-ci, regroupés sous la notion de « Groupware » ou de travail collaboratif, répondaient à un besoin croissant à l’Inserm.
Un premier travail exploratoire sur le sujet ainsi qu'un calendrier a été présenté en réunion de direction du DSI en septembre 2006, ce travail a été validé et la décision a été prise de centraliser le système de messagerie et d'y ajouter des fonctionnalités de travail collaboratif.
A cette occasion, il a été décidé d'unifier le nommage des adresses de messagerie électronique en « @inserm.fr », tout en assurant la correspondance avec les adresses préexistantes faisant apparaître la localisation géographique (@ville.inserm.fr).
La méthode était, après exploration de l’état de l’art, de rencontrer des sociétés susceptibles de répondre à nos besoins, d’entendre et analyser leurs propositions techniques, puis de contrôler par voie indépendante des déploiements sur le terrain.
Sur la base de ces recherches, un cahier des charges serait rédigé et un appel d'offre publié.
Les recherches menées ont fait apparaître trois types de solutions : propriétaires et commerciales, commerciales ouvertes à l’ « open source » et entièrement « open source ».
Les solutions propriétaires sont essentiellement portées par Microsoft (Exchange®), IBM (Lotus®) et Novell (GroupWise®). Hormis le vaste déploiement dont bénéficient ces solutions, les caractéristiques communes sont l’utilisation de protocoles propriétaires et donc fermés et le coût non négligeable de l’investissement (achat de licences par utilisateur) et du support. Ces coûts pouvaient, cependant, être modulés par les offres « éducation-recherche ».
Bon nombre de solutions entièrement open-source ont été explorées : More.GroupWare, Citadel, PHPGroupWare, E-GroupWare, Kolab, OpenGroupWare. Ces solutions, de maturité variable, n'avaient pas de déploiement significatif en France ni de SS2L2 pour en assurer l'intégration.
Deux solutions commerciales ouvertes à l'open-source avaient retenu notre attention : OpenXchange et Zimbra ; elles pouvaient être des alternatives fiables aux solutions propriétaires.
Les sociétés IBM, Microsoft et Novell ainsi que trois SS2L ont été rencontrées ; des démonstrations et des évaluations financières ont été présentées.
Parallèlement une démarche de recherche de retour d'expérience a été entreprise auprès d'utilisateurs des solutions qui avaient retenu l'attention : ministères, universités et banques. En 2006, peu de solutions entièrement libres étaient réellement déployées ; quelques maquettes dans certains ministères étaient en cours d'évaluation et montraient déjà des résultats mitigés, notamment sur les aspects « groupware ».
Un projet a été remarqué : le déploiement d'OpenXchange à l'université de Mulhouse (UHA) en version totalement libre pour les étudiants et sous contrat éditeur pour le personnel.
Ces retours d'expérience ont permis d'affiner le cahier des charges validé par la direction avant publication.
L'appel d'offre a été publié fin 2006 ; le cahier des charges rédigé mettait principalement en avant :
méthodologie de reprise des données existantes et de migration des comptes. Une exigence de réversibilité y était formulée afin de rendre possible le remplacement de la solution via un marché public au bout de quelques années ;
différenciation entre l'administration système, assurée de manière centralisée, et l’administration fonctionnelle (gestion des comptes, quotas, alias) devant pouvoir être déléguée aux responsables informatiques régionaux ;
pour la partie messagerie, compatibilité avec les clients usuels et utilisés à l’Inserm, accessibilité par client léger et utilisation des protocoles standard en versions sécurisées, filtrage antivirus et antispam ainsi que fonctionnalités usuelles ;
pour le groupware, l'exigence se limitait à la gestion des contacts personnels et partagés, la gestion des agendas professionnels et privés de personnes, de groupes et de ressources matérielles (salles, matériels, etc.), une gestion fine des droits et délégations sur ces éléments. La possibilité d'importer et exporter les données contacts et calendriers dans des formats connus ;
synchronisation des assistants numériques personnels (PDA) et téléphones mobiles avec les fonctionnalités collaboratives (agendas et contacts), mais aussi avec les principaux clients de courrier électronique (Thunderbird et Outlook) ;
la demande concernait dans un premier temps 8000 comptes utilisateurs ; la réponse devait pouvoir supporter le doublement de ces comptes, une préconisation d'architecture était exigée.
Sept réponses ont été obtenues : quatre solutions propriétaires (Exchange, Lotus, GroupWise, Oracle Collaboration Suite), deux solutions commerciales ouvertes à l’open source (OpenXchange et Zimbra) et OBM. Les propositions financières se sont situées dans une fourchette de 80 k€ à 500 k€.
La solution retenue a été OBM de la SS2L AliaSource. Seule solution soumise entièrement sous GPL, elle présentait l'avantage de reposer sur des briques logicielles maîtrisées au DSI et permettait un éventuel retour arrière. Elle était également intéressante financièrement car c'était la seule, alors, dont les coûts d'acquisition et de maintenance étaient indépendants du nombre de comptes. Absente de l'étude préalable, des retours d'expériences supplémentaires (ministères des finances et armée de l'air) ont été réalisés avant sa notification. Les choix réalisés par l'Assemblée Nationale et certains ministères ont naturellement conforté celui de l'Inserm. AliaSource, l'éditeur/intégrateur d'OBM, a par la suite été absorbé par la SS2L Linagora.
Figure
1: Architecture
L'architecture a été mise en place suivant les préconisations fournies (voir Figure 1: Architecture) ; le système d'exploitation choisi a été Redhat Enterprise Linux 4 avec les briques logicielles suivantes :
OBM version 2.1 (Mail, LDAP, Groupware, Sync)
Cyrus Imap, murder
Postfix, clamAV, SpamAssassin
OpenLDAP
Sympa
La seule concession aux logiciels non open source est Sophos PureMessage conservé pour maintenir la fonctionnalité des quarantaines gérées par les utilisateurs. Une supervision a été mise en place grâce à Nagios, Centreon et Nareto.
La redondance est assurée par une bascule des services à froid.
Deux architectures ont été mises en place sur deux sites différents (production et développement). La recette a été faite durant le dernier trimestre de 2007 ; une cinquantaine d'utilisateurs du DSI ont participé aux tests fonctionnels de la solution. Des tests de charge ont été réalisés : l'outil WebPerformance Trainer3 a été utilisé pour les parties web, l'outil libre Mstone4 a permis quant à lui de valider la tenue en charge de la partie messagerie.
Durant la période de recette, un planning de déploiement a été mis en place. Le choix d'intégrer les 8000 premiers comptes utilisateurs existants sur une période de 6 mois, en basculant sur cette nouvelle messagerie les régions une à une, était commandé par la nécessité de contrôler la montée en charge et de se donner une marge pour procéder à des ajustements éventuels.
Une charte de nommage des adresses internet a été rédigée afin de prendre en compte l'unification du nommage en « @inserm.fr » tant pour les adresses personnelles que pour les adresses fonctionnelles, ces dernières étant la plupart du temps associées à des groupes dans la partie collaborative de la solution. La charte intégrée dans le référentiel général d'interopérabilité de la DGME 5 (ex-ATICA) a servi de modèle. Très rapidement le problème des homonymies a pu être pris en compte et résolu. En effet, l'ancien nommage des adresses de messagerie (dupond@ville.inserm.fr) laissait prévoir des possibilités de collision d'adresses nouvelle formule. Un outil en ligne a été mis à disposition des responsables régionaux pour résoudre le problème. La résolution des conflits a été faite gré à gré par eux et les utilisateurs en se référant à la charte de nommage. Dans de nombreux cas, il s'agissait d'une même personne qui avait acquis plusieurs adresses au fil du temps du fait de sa mobilité géographique.
De janvier à juin 2008, les 8000 comptes existants avaient migrés. Après cette migration, un démarchage des structures de l'Inserm dont les personnels ne possédaient pas d'adresse en « @inserm.fr » a débuté. Le but n'était pas nécessairement de substituer une nouvelle adresse à leurs adresses usuelles (universitaire, Institut Pasteur, etc.) mais bien de pouvoir les référencer et de leur proposer le choix d'utilisation en activant des transferts de messagerie. Les DRSI ont préparé et fourni des fichiers texte de type CSV qui ont été injectés dans OBM pour créer ces comptes.
A ce jour (décembre 2009), près de 12000 comptes utilisateurs et 2900 groupes fonctionnels ont été intégrés à OBM ; 800 listes de diffusions ont été créées.
La préoccupation première était la centralisation des messageries régionales ; l'utilisation de la partie collaborative de la solution était limitée à quelques utilisateurs jusqu'à la fin 2008 ce qui a permis de constater rapidement que des aménagements étaient nécessaires. Des évolutions du produit OBM ont été demandées à l'éditeur avec l'exigence que celles-ci soient intégrées dans le produit générique. Un club d'utilisateurs a été créé, entre autres, à notre initiative afin de débattre et de statuer sur les évolutions avec le mainteneur d'OBM.
Le produit OBM avait été visiblement créé comme outil de gestion de la relation client (CRM) pour des PME, il ne prenait pas en compte la complexité d'entités comme celle de l'Inserm. Les demandes d'évolutions concernaient essentiellement :
D'un point de vue administration :
la possibilité de réaliser des traitements par lot sur des comptes à partir de sélection par champs multiples, ces traitements pouvant être des changement de délégation, de profil, de quota, de coordonnées ; d'activation ou désactivation de la messagerie ou de ces fonctionnalités (adresse nomade), mais aussi pour gérer l'expiration des comptes et leur mise en archive, etc. ;
un éditeur de profil utilisateur, pour lui allouer des droits spécifiques, des accès à certaines fonctionnalités collaboratives ;
une meilleure granularité d'administration : administration fonctionnelle déléguée par DRSI, un flux de travail (workflow) d'alimentation et d'édition des comptes depuis les structures de recherche ;
un ensemble d'outils pour générer des rapports d'état des comptes par structure Inserm, par délégation régionale ;
une table de « mappage » des attributs de Ldap pour intégrer d'autres schémas que celui d'OBM, ex : SUPANN ;
une API de type REST6 pour pouvoir interfacer les autres applications métier.
Pour l'utilisateur :
la possibilité de partager les contacts entre utilisateurs et groupes ;
une meilleure gestion des agendas de ressources : visibilités, délégations, droits, etc. ;
la possibilité d'intégrer des comptes externes dans les invitations à des réunions, dans les groupes fonctionnels ;
de meilleures impressions d'agendas partagés, d'organigramme ;
une amélioration des synchronisations vers les clients de messagerie et les PDA.
Ces évolutions ont amené à migrer successivement OBM de la version 2.1.9 à la 2.1.14 puis 2.2.14. Cette dernière étant une montée de version majeure d'OBM, elle a impliqué des modifications du modèle de données dans les bases. Elle a apporté également des possibilités nouvelles du fait des changements de version de l'OS (RHEL5), de PHP en V5, de MySql en V5, d'OpenLDAP en V2.3 (meilleur processus de réplication) et de Cyrus-imap en v2.3 (possibilité de répliquer les BAL en temps réels sur un autre site).
Le système mis en place a été complété par la suite de services annexes, une messagerie instantanée avec JABBER, un wiki intégrant les documentations « utilisateur » et une foire aux questions (FAQ).
Un apport majeur a été fait sur le constat du besoin depuis longtemps exprimé par les utilisateurs : l'échange sécurisé de fichiers volumineux avec leurs correspondants internes et externes. Un nouveau cahier des charges a été rédigé et a abouti à l'application Linshare réalisée par la SS2L Linagora. Les principales caractéristiques demandées ont été :
authentification à partir de l'annuaire d'OBM ;
interface Web simple et compréhensible, aide en ligne, (bulles informatives, vidéos de démonstration) ;
possibilité pour les utilisateurs authentifiés de créer des comptes « invité » temporaires, pour que ces derniers puissent déposer des documents depuis l'extérieur de l'Inserm ;
connecteurs pour les clients de messagerie.
Une API REST incluse dans Linshare a permis en interne de développer des clients (exemple : OBM, Iphone, …).
Cette application actuellement en recette rencontre un franc succès auprès des premiers utilisateurs.
Sur la base d'OBM, de nombreuses applications se sont greffées et utilisent par exemple son annuaire à des fins d'authentification. Un projet régional porté par la DRSI de Paris 5 a permis d'apporter une solution libre de serveur de fichiers et d'impression accessible aux structures de recherche. Il utilise Samba et OpenLdap dont l'interface de gestion locale est basée sur celle d'OBM. Ce système se synchronise avec l'annuaire national pour les comptes des utilisateurs et les groupes dont il ne reprend que les identités de la structure concernée.
Figure 2: Flux de réplication
L'architecture de développement, après une remise à niveau, a été dernièrement reconvertie pour intégrer un plan de reprise d'activité (PRA).
Situés sur deux sites distants raccordés au Réseau Académique Parisien, La reprise d'activité peut être assurée sous 4 heures en cas de sinistre majeur sur le site de production.
Les synchronisations sont assurée en temps réel : les boites de courrier électronique par Cyrus-imap ; les bases de données d'OBM et de Sympa par la réplication propre à MySql et la réplication d'OpenLdap est classique. Rsync complète le dispositif pour les fichiers (voir Figure 2: Flux de réplication).
La synchronisation des fichiers de configuration est actuellement manuelle, Quattor7 ou Puppet8 sont pressentis pour l'automatiser.
Le principal problème rencontré concerne les aspects de communication et de conduite du changement. L'équipe projet a sous-estimé ces aspects et a manqué d'un véritable plan de formation pour accompagner les utilisateurs, notamment pour la prise en compte des nouveaux services (outils collaboratifs).
Pour corriger une partie de ces problèmes un effort a été fait sur l'aspect documentation avec un wiki (aspect négligé dans le CCTP initial). Quelques formations ont été mises en place pour certains services du Siège ainsi qu'un accompagnement utilisateur sous forme de prestations.
Il est à noter que le produit OBM dispose de peu d'aide efficace en ligne. Cette négligence a été prise en compte lors des projets suivants pour lesquels une interface disposant d'une aide en ligne efficace a été exigée. Concernant OBM, la demande d'évolution documentaire a été faite auprès de l'éditeur.
Dans ce genre de solution, les assistants numériques personnels communicants (PDA) posent un vrai problème pour les synchronisations (contacts, agendas et tâches). En effet, la normalisation des formats de données et des protocoles de synchronisation entre constructeurs n'est pas toujours au rendez-vous. Il a été nécessaire de tester et de limiter le nombre de modèles de téléphones mobiles compatibles. Il est également important pour ce point précis de prendre en compte les exigences des décideurs (effet VIP) ainsi que des modes (iPhone, BlackBerry, etc.). Ce parc va pouvoir s'élargir avec l'arrivée de O-Push9, version libre du protocole ActiveSync en complément du protocole SyncML (Funambol10) existant dans OBM.
Très rapidement la tenue à jour de l'annuaire (coordonnées des utilisateurs, appartenance aux structures, etc.) a montré ses limites. Initialement réservée aux seuls administrateurs, un profil accessible à une personne désignée par le directeur de chaque structure de l'Inserm a été demandé et mis en place depuis. Ce profil permet la mise à jour des coordonnées et est également le point d'entrée dans le workflow d'alimentation des comptes de messagerie.
Le principal inconvénient d'une centralisation de la messagerie au sein d'un institut comme l'Inserm est l'impact qu'un problème amène en cas dysfonctionnement. Cet impact devient général au contraire du modèle précédent décentralisé sur plusieurs sites. Cependant, ce modèle offre une possibilité accrue d'investir pour améliorer la redondance et la qualité de service.
Globalement les objectifs de départ sont remplis, l'argumentaire présenté en 2.1 pour la centralisation est pleinement justifié : optimisation de gestion des ressources, meilleure industrialisation de l'exploitation de la messagerie, création d'un référentiel national utilisé par de nombreuses applications internes.
Au sein du club des utilisateurs d'OBM les évolutions sont suivies activement par l'équipe. La version 2.3 amènera miniG11, un webmail, entièrement intégré à OBM, plus convivial basé sur Google Web Toolkit, mais aussi O-push et CalDav12 qui ouvriront significativement les compatibilités entre applications et avec les matériels, ainsi que des améliorations de l'API REST.
Les procédures de redondance déjà mise en place seront automatisées, les bases de données MySQL d'OBM seront remplacées par PostgreSQL pour de meilleures performances. La répartition de charge est d'ores et déjà envisagée pour la partie messagerie.
D'une manière générale, cette expérience a valu des demandes de retours d'expérience personnalisés de la part du monde de l'éducation supérieure, de la recherche mais aussi d'associations et de sociétés. Une fiche concernant OBM a été publiée dans PLUME13.
L'équipe a bénéficié dès le début de très bons rapports avec l'éditeur qui a été dans le même temps l'intégrateur. Le mode de fonctionnement pro-actif avec cet éditeur en direct, ou au travers du club utilisateur a été bénéfique pour les préoccupations et le projet de l'Inserm, mais aussi pour la communauté par le reversement intégral sous licence GPL de la solution choisie et des évolutions demandées par l'Inserm et les membres du club utilisateurs.
Ont participé à ce projet : Patrick Lerouge et Julio Martins (conduite de projet), Laurent Moizo (messagerie, architecture), Frédéric Sené (groupware, système de documentation), Guillaume Stevens (sécurité), Martial Lebec (antivirus et antispam), Sylvain Gérard (supervision et PRA), Gwénaël Dumont et Sébastien Maury (bases de données), Ando Rakotonirina (tests de charge), Sarah Carbal (communication). Les personnels des Délégations Régionales du Système d'Information de l'Inserm ont quant eux, testé, préparé et effectué les déploiements ainsi que la mise en ligne des documentations. Louis Réchaussat, directeur du DSI.
1Open Business Management, http://obm.org/doku.php
2Société de services en logiciel libre
3http://www.webperformanceinc.com/
4http://mstone.sourceforge.net/
5https://www.ateliers.modernisation.gouv.fr/ministeres/domaines_d_expertise/architecture_fonctio/public/rgi/charte-nommage-internet9402
6http://fr.wikipedia.org/wiki/Representational_State_Transfer#Description_de_REST
Page