B U R E A U V I R T U E L

R é p u b l i q u e F r a n ç a i s e C A H I E R D E C L A U S E S T E C H N I Q U E S P A R T I C U L I E R E S B U R E A U V I R T U E L Appel d offres ouvert soumis aux dispositions des articles 58 à 60 du code des marchés adopté par le décret n 2001-210 du 7 mars 2001 78, route de Paris - B.P. 19-69751 Charbonnières-les-Bains Cedex Tél. 04 72 59 40 00 - Telex 305 177 F Télécopie 04 72 59 42 18

TABLE DES MATIERES 1 - GÉNÉRALITÉS 4 1.1. Terminologie 4 1.2. Introduction 4 1.3. Objet de la consultation 4 1.4. Calendrier d exécution 5 1.5. Variantes 5 1.6. Cadre d utilisation 5 1.7. Confidentialité 5 2 - PRÉSENTATION DE L EXISTANT 7 2.1. Infrastructures réseaux 7 2.1.1. Réseaux locaux des établissements 7 2.1.2. Réseaux fédérateurs 7 2.1.3. Internet 8 2.2. Systèmes d information 8 2.2.1. Annuaires 8 2.2.2. Portails 8 3 - SPÉCIFICATIONS DE BESOINS 9 3.1. Périmètre 9 3.2. Exigences fonctionnelles 9 3.2.1. Fonctionnalités du Bureau Virtuel 9 3.2.2. Langues 14 3.2.3. Gestion des comptes 14 3.2.4. Import et export de comptes 15 3.2.5. Personnalisation du Bureau Virtuel 15 3.2.6. Accès depuis d autres média 15 3.3. Exigences techniques 15 3.3.1. Architecture de la solution 15 3.3.2. Sécurité des accès 16 3.3.3. Dimensionnement des matériels 19 3.3.4. Pérennité des données en cas de panne 19 3.3.5. DNS 20 3.3.6. Routage SMTP 20 3.3.7. Support des principaux navigateurs web du marché 20 3.4. Conformité 21 3.5. Environnement 21 3.5.1. Hébergement des serveurs 21 3.5.2. Alimentation des serveurs 21 3.5.3. Contraintes des matériels 21 3.5.4. Connectivité à Amplivia et à Internet 22 4 - DESCRIPTION DES PRESTATIONS 23 4.1. Poste 1 : Licences logicielles 23 4.2. Poste 2 : Fourniture des matériels 23 4.2.1. Baies 23 4.2.2. Serveurs 24 4.2.3. Matériels réseaux 24 4.2.4. Onduleurs 24 4.2.5. Divers : Ecrans/claviers/souris, cordons 24 4.3. Poste 3 : Etude, Intégration et mise en œuvre 24 4.3.1. Prestations communes à l ensemble des établissements 24 4.3.2. Prestations spécifiques au déploiement de chaque établissement 26 14/10/2003 2003.059 CRRA CCTP Validé 2

4.4. Poste 4 : Formation et documentation 27 4.4.1. Formation 27 4.4.2. Documentation 27 4.5. Poste 5 : Exploitation technique et Maintenance corrective 27 4.5.1. Assistance aux administrateurs de comptes 27 4.5.2. Maintenance corrective de niveau 2 28 4.5.3. Maintenance corrective de niveau 3 29 4.5.4. Supervision 29 4.5.5. Exploitation technique et maintenance courante 29 4.5.6. Fermeture du site et suspension de diffusion de message 30 4.5.7. Tableaux de bords 30 4.5.8. Réunions mensuelles 31 4.6. Poste 6 : Maintenance évolutive 31 4.6.1. Evolutions des progiciels 31 4.6.2. Evolutions spécifiques du BVE 31 5 - ASSURANCE QUALITÉ 32 5.1. Organisation projet 32 5.2. Mise en œuvre du BVE 32 5.2.1. Phasage 32 5.2.2. Plan d Assurance Qualité 33 5.3. Exploitation technique / Maintenance 33 6 - RECETTES ET GARANTIE 35 6.1. Recettes 35 6.1.1. Recette des prestations communes à l ensemble des établissements 35 6.1.2. Recettes des prestations spécifiques au déploiement de chaque établissement 36 6.2. Garantie 37 6.2.1. Garantie de bon fonctionnement 37 6.2.2. Garantie de pérennité 37 7 - REVERSIBILITÉ ET SORTIE 38 8 - ANNEXES 39 8.1. Liste des établissements potentiellement concernés 39 14/10/2003 2003.059 CRRA CCTP Validé 3

1 - GENERALITES 1.1. TERMINOLOGIE Dans ce document, les termes suivants désignent : «CRRA» ou «Maître d Ouvrage» ou «la Personne Publique» : le Conseil Régional Rhône- Alpes (ou son représentant), partie contractante du projet «Candidat» : la société (ou le groupement de sociétés) qui répond au dossier de consultation qui inclut le présent cahier des charges «Titulaire» : le candidat qui sera retenu pour réaliser les prestations définies dans la consultation «Cahier des charges» ou «Cahier des Clauses Techniques Particulières» ou «CCTP» : le présent document, décrivant les prestations à réaliser. Le CCTP fait partie du dossier marché et a ainsi un caractère contractuel. «BV» ou «BVE» : le Bureau Virtuel (Etudiant) objet de ce cahier des charges «CURA» : Conférence Universitaire Rhône-Alpes «AGERA» : Alliance des Grandes Ecoles Rhône-Alpes «ENCORA» : Environnement Numérique Campus Ouvert Rhône-Alpes «AGALAN» : Académie de Grenoble / Académie de Lyon Annuaire «Utilisateur actif» : utilisateur connecté et utilisant activement le BV 1.2. INTRODUCTION Au sein du Conseil Régional Rhône-Alpes, la Direction de l Enseignement Supérieur (DESUP) a en charge l ensemble des relations avec les établissements d Enseignement Supérieur de la région. A ce titre, elle finance régulièrement des projets innovants dans le domaine des Nouvelles Technologies de l Information et de la Communication (NTIC), qui lui sont proposés par les établissements. En 2002, le projet ENCORA, porté par le GIP CURA (qui regroupe 13 établissements de la région) a été retenu par le FRT dans le cadre de son appel à projets sur les Espaces Numériques de Travail (E.N.T.). La Région Rhône-Alpes soutient également ce projet, en prenant en charge, à la demande de la CURA, le financement et la maîtrise d ouvrage du service «Bureau Virtuel», qui fait l objet de cette consultation. 1.3. OBJET DE LA CONSULTATION Fourniture, intégration, exploitation et maintenance d un Bureau Virtuel pour l ensemble des étudiants et des personnels des établissements d enseignement supérieur de la Région Rhône-Alpes. La Région Rhône-Alpes recherche un prestataire ou un groupement de prestataire pour déployer et exploiter un Bureau Virtuel pour l ensemble des étudiants rhônalpins, tel que décrit dans ce cahier des charges (CCTP). Les prestations à réaliser concernent la fourniture (logiciels et matériels), l intégration, la mise en oeuvre, l exploitation technique et la maintenance de ce Bureau Virtuel. La Région Rhône-Alpes recherche un service basé sur des progiciels du marché, afin de limiter le plus possible les développements et solutions spécifiques, générateurs de délais et de surcoûts importants, et de moindre évolutivité. L attention des candidats est attirée sur le fait que le service recherché est un service de masse (200 000 comptes), simple d emploi et à coût maîtrisé, dans un environnement «étudiant» et non «entreprise». 14/10/2003 2003.059 CRRA CCTP Validé 4

Cet appel d offres est composé d un lot unique. 1.4. CALENDRIER D EXECUTION Le calendrier d exécution des prestations sera établi par le Maître d Ouvrage et le titulaire lors de la réunion de lancement du projet. Le planning suivant, donné à titre indicatif, sous réserve de la durée des procédures administratives, indique les principales étapes du projet : 14 octobre 2003 : Lancement de la consultation 8 décembre 2003 : Réponses des candidats 13 Janvier 2003 : Choix du titulaire Février 2003 : Notification Février - Avril 2003 : Déploiement sur un périmètre initial restreint Avril - Août 2003 : Déploiement généralisé sur l ensemble des établissements Nota : Les candidats tiendront compte de l activité réduite des services informatiques des établissements pendant le mois d août. Le Maître d Ouvrage est susceptible de modifier le planning de mise en œuvre. Il s engage à en notifier les candidats ou le titulaire concernés dans des délais compatibles avec les objectifs de la réalisation demandée. Lorsque le délai d exécution de l intégralité des travaux, éventuellement prolongé avec l accord du Maître d Ouvrage, est dépassé, le titulaire peut encourir après mise en demeure préalable, une pénalité selon les modalités définies dans le CCAP. 1.5. VARIANTES Les variantes sont acceptées. Par exemple, dans les cas où les produits «standards» du candidat respecteraient l esprit de ce cahier des charges sans être 100% conformes aux exigences techniques et fonctionnelles, le candidat est invité dans le cadre d une variante à chiffrer une solution «de base» correspondant aux fonctionnalités «standards» de ses produits, et de chiffrer en option l intégration des fonctionnalités supplémentaires «non standards» qui sont demandées dans ce cahier des charges. La volonté du Maître d Ouvrage est de limiter le plus possible les développements spécifiques, générateurs de délais et de surcoûts importants. 1.6. CADRE D UTILISATION Le présent document est un des éléments constitutifs du marché public qui sera signé avec le titulaire. Il convient de signaler que cette description n est pas limitative et que le titulaire devra tous les travaux de sa spécialité sans restriction ni réserve, conformément aux documents du dossier marché. Le candidat se doit de signaler au Maître d Ouvrage toute erreur, omission, imprécision ou contradiction décelée dans l un des documents ou entre deux documents constituant le dossier de consultation. En cas de litige lié à une différence d interprétation du cahier des charges durant la réalisation des prestations, l interprétation du Maître d Ouvrage fera foi. 1.7. CONFIDENTIALITE De convention expresse, le titulaire s engage à tenir pour strictement confidentielles les informations dont il aura pu disposer dans l'exécution du présent marché et ne les divulguer à quiconque ni lors de l'exécution du marché ni après sa réalisation. Les méthodes et le savoir-faire du titulaire étant compris dans l'objet du marché, le Maître d Ouvrage n'est pas tenu de les garder confidentiels. 14/10/2003 2003.059 CRRA CCTP Validé 5

Les opérations de communication éventuelles du titulaire au sujet de ce projet, telles que communiqués de presse, articles publicatoires ou rédactionnels, conférences, seront soumises à l'accord du Maître d Ouvrage. Le titulaire, pour l'exécution de la présente clause, répond de ses salariés et partenaires comme de lui-même. 14/10/2003 2003.059 CRRA CCTP Validé 6

2 - PRESENTATION DE L EXISTANT Ce chapitre a pour but de décrire les infrastructures techniques dans lequel devra s intégrer le Bureau Virtuel objet de cette consultation. 2.1. INFRASTRUCTURES RESEAUX 2.1.1. Réseaux locaux des établissements Le réseau local de chaque établissement est un réseau privé haut-débit (10Mbps, 100Mbps, voire 1000Mbps) permettant la communication de l ensemble des ordinateurs connectés. Il permet notamment les échanges entre les stations de travail et les serveurs de l intranet, ainsi que les communications vers d autres établissements et vers Internet au travers de leur connexion avec Amplivia ou un réseau métropolitain. Ce réseau local est un espace sécurisé qui n est pas accessible depuis l extérieur (autres établissements, Internet) à l exception de certains serveurs bien identifiés (web, mail,...). 2.1.2. Réseaux fédérateurs Renater 2,5Gbps Bourg en Bresse 2Mbps Oyonnax Archamps Roanne 6Mbps 100Mbps 100Mbps 4Mbps 2Mbps RMU Lyon 100Mbps St Etienne 2Mbps 6Mbps L Isle d Abeau Le Bourget du Lac 24Mbps Annecy 100Mbps Chambéry Les Houches R- Mess Vienne 2,5Gbps 100Mbps 100Mbps Tigre Grenoble Valence 100Mbps 2Mbps 2,5Gbps Le Cheylard 2Mbps Le Pradel 2Mbps Die Renater Figure 1 : Architecture des réseaux fédérateurs en Rhône-Alpes (Amplivia 2004) 2.1.2.1. Réseaux Métropolitains Sur Lyon (RMU), Grenoble (Tigre) et St Etienne (R-Mess), un réseau relie entre eux les établissements de chaque agglomération. Les réseaux métropolitains sont des réseaux haut-débit (10 à 155Mbps) qui permettent les communications : avec les autres établissements de l agglomération, 14/10/2003 2003.059 CRRA CCTP Validé 7

avec les autres établissements de la région (via Amplivia), avec les autres établissements en France et avec Internet (via Renater Lyon et Grenoble ou via Amplivia St Etienne) Les réseaux métropolitains de Lyon et Grenoble sont connectés à Amplivia (Lyon, Grenoble et St Etienne) et à Renater (Lyon et Grenoble). 2.1.2.2. Réseau régional haut-débit : Amplivia Amplivia est le réseau fédérateur haut-débit de la région Rhône-Alpes, interconnectant notamment les établissements d enseignement supérieur. Amplivia 2004 prévoit l interconnexion de l ensemble des villes principales par une boucle à 100Mbps. Amplivia permet les communications entre établissements et avec Internet, via Renater (connectivité à 2,5Gbps sur Lyon et Grenoble). 2.1.2.3. Renater Le réseau Renater est composé d une infrastructure métropolitaine et de liaisons internationales à haut débit. Il comprend une épine dorsale nationale multi-gbps qui fédère les réseaux de collecte régionaux tels qu Amplivia. Outre les connexions aux autres réseaux de recherche européens, américains et asiatiques, Renater est connecté à Internet à 1Gbps (Internet français) et 2x2,5Gbps (Internet mondial). 2.1.3. Internet Les établissements ont, par l intermédiaire de Renater, accès à l ensemble des ressources d Internet : web, mail, news, ftp et tous les autres services disponibles sur le réseau mondial, dans le respect des règles d usage imposées par Renater. 2.2. SYSTEMES D INFORMATION Chaque établissement dispose d une informatique propre. Il n y a pas d homogénéité entre les différents établissements. 2.2.1. Annuaires On distingue trois catégories d établissements : Les établissements sans annuaire : ces établissements disposent d une simple base de données qui fait office d annuaire. Les établissements avec un annuaire LDAP : ces établissements disposent d un annuaire compatible LDAP, mais dont les structures ne sont pas homogènes Les établissements avec un annuaire AGALAN : ces établissements disposent d un annuaire compatible LDAP avec une structure commune. Cet annuaire sera implémenté au fur et à mesure dans les établissements du consortium AGALAN. 2.2.2. Portails Quelques établissements disposent aujourd hui d un portail (commercial ou développé en interne), la plupart n en n ont pas. Le projet ENCORA en cours prévoit la mise en place d un portail pour certains des établissements de la CURA, utilisant le produit Sun One de Sun Microsystems. Ce portail inclura un service d authentification unique (SSO). 14/10/2003 2003.059 CRRA CCTP Validé 8

3 - SPECIFICATIONS DE BESOINS 3.1. PERIMETRE Le projet de Bureau Virtuel adresse a priori l ensemble des établissements d enseignements supérieurs de la région Rhône-Alpes, dont une liste indicative figure en annexe (cf 8.1). Les populations concernées sont toutes celles inscrites dans les annuaires des établissements, en particulier : L ensemble des étudiants L ensemble des personnels (inclut le personnel enseignant, le personnel IATOS, les vacataires, les intervenants ) Au total, les étudiants et personnels représentent potentiellement 200 000 utilisateurs répartis ainsi : ~ 120 000 utilisateurs potentiels sur le pôle de Lyon (Rhône/Loire/Ain) (=60%) ~ 80 000 utilisateurs potentiels sur le pôle de Grenoble (Isère/Savoies/Drôme/Ardèche) (=40%) 3.2. EXIGENCES FONCTIONNELLES Le Bureau Virtuel se présentera sous la forme d un ensemble d applications accessibles par un navigateur web. L utilisateur, une fois authentifié, accède à son environnement de travail personnel, composé de diverses fonctionnalités. 3.2.1. Fonctionnalités du Bureau Virtuel Les besoins fonctionnels peuvent être groupés en 6 catégories : Messagerie Carnet d adresses Agendas Stockage et gestion de documents Annuaire et pages blanches Outils de communication de groupe La solution intégrera également une aide en ligne que le candidat décrira précisément. Le Maître d Ouvrage insiste sur l interopérabilité des fonctionnalités, de façon ergonomique : Les outils doivent communiquer entre eux et être prévus pour une utilisation conjointe. Outre l ensemble des fonctionnalités évoquées ci-après, le candidat donnera la feuille de route des évolutions fonctionnelles prévues de sa solution, à 3, 6 et 12 mois. 3.2.1.1. Messagerie Le Bureau Virtuel intégrera des fonctionnalités de messagerie Internet. Le Bureau Virtuel conservera les e-mails des utilisateurs, dans la limite d un volume maximum (= quota, cf 3.3.3.2). Les utilisateurs seront notifiés par e-mail lorsqu ils dépassent 80% du quota qui leur est alloué. Les fonctionnalités attendues de base sont toutes celles rencontrées dans les webmails courants, et notamment les suivantes : Réception et stockage des mails envoyés à l utilisateur. Le candidat précisera s il est possible de recevoir des mails envoyés à des alias à l adresse principale (sous réserve que l adresse souhaitée ne soit pas déjà utilisée). Lecture des e-mails en texte «en clair» et en html. 14/10/2003 2003.059 CRRA CCTP Validé 9

Possibilité de transférer un e-mail reçu. Possibilité de répondre à l auteur et/ou à tous les destinataires d un e-mail reçu. Rédaction et envoi des e-mails, à des destinataires principaux, en copie et en copie cachée, avec possibilité de joindre des pièces attachées. Les destinataires doivent pouvoir être choisis dans le carnet d adresses (cf 3.2.1.2) Le candidat précisera s il est possible de rédiger des e-mails en html (intégrant par exemple des caractères mis en forme, des liens hypertextes, des images ), via une interface WYSIWYG Possibilité de créer des dossiers pour classer les mails. Possibilité de déplacer un e-mail, possibilité de le supprimer. Le candidat précisera s il est possible de sélectionner plusieurs e-mails pour les déplacer ou les supprimer en une seule fois. Le candidat précisera s il est possible de créer également des sous-dossiers. Tri des mails par ordre anti-chronologique (le plus récent en premier) Le candidat précisera si d autres tris sont possibles (ex : par auteur, par destinataire ) Possibilité de faire des recherches dans les titres et les textes des e-mails Le candidat précisera si la recherche peut également être réalisée sur les pièces jointes. Possibilité de rerouter automatiquement les mails vers une autre adresse e-mail. Message d absence paramétrable Le candidat précisera s il est possible de paramétrer des dates d activation et de désactivation. Possibilité d utiliser des règles pour filtrer et/ou déclencher des actions Le candidat précisera quels sont les filtres et les actions possibles (ex : réponse automatique, déplacement dans un dossier donné, forward automatique ). Fichier de signature Le candidat précisera s il est possible de gérer plusieurs fichiers de signature. Possibilité de relever ses e-mails depuis un client POP3. Le candidat précisera s il est également possible de relever ses e-mails depuis un client IMAP4. Possibilité de relever d autres comptes externes en POP3 (par ex : laposte.net) Le candidat précisera s il est également possible de les relever en IMAP4. Le candidat précisera en outre le nombre maximum d autres comptes externes qu il sera possible de relever par utilisateur. Le candidat précisera également s il est possible de laisser ou non les e-mails sur les serveurs lors de la relève POP3/IMAP4 de comptes externes. Le candidat précisera enfin s il est possible de supprimer automatiquement les e-mails laissés sur le serveur au bout de X jours. Gestion des adresses indésirables par l utilisateur (anti-spamming) Le candidat pourra également proposer un système anti-spam de son choix, plus performant qu une simple «blacklist» d adresses e-mails gérée utilisateur par utilisateur. Scan antivirus systématique des e-mails entrant et sortant (y compris les pièces jointes, même zippées) Le candidat aura la responsabilité de la mise à jour l antivirus et des définitions de virus. En option facultative, le Maître d Ouvrage souhaiterait également que les utilisateurs aient la possibilité d envoyer depuis le Bureau Virtuel des SMS (et éventuellement des fax) vers un ou plusieurs destinataires cette fonctionnalité étant nécessairement couplée à un système de paiement sécurisé en ligne permettant aux utilisateurs de «créditer» leur compte d un certain nombre de SMS et/ou fax. Le Maître d Ouvrage souhaiterait en outre que les utilisateurs aient la possibilité d importer les messages de leur ancienne messagerie (par exemple : Microsoft Outlook et Outlook Express, Netscape Mail et Messenger, Eudora Pro et Light ) dans leur nouvelle messagerie (Bureau Virtuel). Le candidat indiquera si des mécanismes standards sont proposés pour réaliser cet import, sans toutefois nécessiter de développement spécifique. Si une fonctionnalité d import est effectivement disponible, le candidat précisera quelles sont les messageries compatibles et si cet import est réalisable simplement par l utilisateur ou s il nécessite l intervention de l administrateur du compte. 14/10/2003 2003.059 CRRA CCTP Validé 10

Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour la gestion de la messagerie. 3.2.1.2. Carnet d adresses Le Bureau Virtuel intégrera des fonctionnalités de carnet d adresses personnel. Les fonctionnalités attendues de base sont toutes celles rencontrées dans les carnets d adresses courants, et notamment les suivantes : Gestion des contacts personnels (avec fiche descriptive). L ensemble des items de la fiche descriptive sera défini ultérieurement (ex : nom, prénom, adresse postale, n téléphones, n mobile, fax, adresse e-mail principale, adresses e-mail alternatives ) Le candidat proposera un format de contacts compatible avec la norme vcard. Possibilité de créer un alias pour un groupe de contacts. Intégration complète avec la messagerie, à savoir : Possibilité de choisir les adresses des destinataires (ou de groupes de destinataires) d un mail dans le carnet d adresses Possibilité d ajouter les adresses de l auteur et des destinataires d un mail reçu dans le carnet d adresses. Possibilité de synchroniser le carnet d adresses dans les deux sens, avec les PDA (notamment les Palm Pilot et les PocketPC) et les applications communément utilisées pour gérer les carnets d adresses (notamment Microsoft Outlook et Microsoft Outlook Express) Le candidat donnera la liste des PDA et des applications synchronisables avec le carnet d adresses du Bureau Virtuel. Le candidat précisera en outre s il est possible d importer et/ou d exporter des contacts (ex : fichier texte au format CSV, format vcard ) Possibilité de partager des contacts avec un groupe d utilisateurs du BV (cf 3.2.1.6). Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour la gestion du carnet d adresses. 3.2.1.3. Agendas Le Bureau Virtuel offrira des fonctionnalités d agenda. Les fonctionnalités attendues de base sont toutes celles rencontrées dans les applications de gestion d agenda courants, et notamment les suivantes : Visualisation de l agenda privé. Le candidat précisera les différentes visualisations possibles (par jour, par semaine, par mois ) Gestion de l agenda privé. Le candidat précisera les différentes fonctionnalités proposées (au minimum sont souhaitées les actions suivantes : ajouter une tâche, éditer une tâche, supprimer une tâche, programmer le rappel automatique d une tâche). Le candidat proposera un format d agendas compatible avec la norme vcalendar. Possibilité de partager son agenda privé avec un groupe d utilisateurs du BV (cf 3.2.1.6). Possibilité de consulter et de gérer l agenda d un groupe d utilisateurs du BV (cf 3.2.1.6). Le candidat précisera s il est possible de superposer l agenda privé avec un ou plusieurs agendas de groupes. Possibilité de consulter un agenda pédagogique. Cet agenda sera alimenté soit par les personnels, soit de façon automatique par des flux de données provenant des progiciels de gestion d emploi du temps. Le candidat précisera s il est possible de superposer l agenda privé avec l agenda pédagogique. Possibilité de créer des tâches et d organiser des réunions, avec notification par e-mail des utilisateurs concernés. 14/10/2003 2003.059 CRRA CCTP Validé 11

Les tâches et réunions pourront aussi bien concerner les agendas privés que les agendas de groupes. Possibilité de synchroniser l agenda privé dans les deux sens, avec les PDA (notamment les Palm Pilot et les PocketPC) et les applications communément utilisées pour gérer les agendas (notamment Outlook) Le candidat donnera la liste des PDA et des applications synchronisables avec l agenda privé du Bureau Virtuel. Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour la gestion de l agenda. 3.2.1.4. Stockage et gestion de documents Le Bureau Virtuel offrira aux utilisateurs un espace de stockage de fichiers qu ils pourront organiser à leur gré dans la limite d un volume maximum (= quota, cf 3.3.3.3). Les utilisateurs seront notifiés par e-mail lorsqu ils dépassent 80% du quota qui leur est alloué. A la création du compte, l arborescence de l espace de stockage sera, par défaut, structurée conformément à une organisation qui sera définie en phase étude (par établissement, formation, niveau ) Les fonctionnalités attendues de base sont les suivantes : Gestion des fichiers personnels au travers de l interface Web. Le candidat précisera les différentes fonctionnalités proposées (au minimum sont souhaitées les actions suivantes : «downloader», «uploader», renommer, supprimer, déplacer, envoyer par e- mail, créer un dossier). En option, le candidat chiffrera la possibilité de filtrer systématiquement les fichiers de type sons (mp3, CD audio...) et images animées (divx, mpg, mpeg, avi ) Possibilité de «monter» l espace de stockage personnel sous forme de disque réseau (via le protocole WebDav). Le candidat pourra proposer une solution alternative pour les systèmes d exploitation ne supportant pas de base WebDav (par exemple via le protocole FTP) Scan antivirus systématique des fichiers «up-loadés» et «downloadés» (y compris les fichiers zippés) Le candidat aura la responsabilité de la mise à jour l antivirus et des définitions de virus. Possibilité de partager des fichiers/dossiers avec un groupe d utilisateurs du BV (cf 3.2.1.6). Possibilité de stocker, de gérer et de consulter des favoris Internet (signets). Le candidat précisera s il est possible de les importer et/ou de les exporter vers les navigateurs web du marché (ex : Internet Explorer, Netscape ) Possibilité de partager des favoris avec un groupe d utilisateurs du BV (cf 3.2.1.6). Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour le stockage et la gestion de documents. 3.2.1.5. Annuaire et pages blanches Le Bureau Virtuel offrira des fonctionnalités d annuaire et de recherche sur l annuaire (pages blanches). Les fonctionnalités attendues de base sont les suivantes : Possibilité d éditer le contenu de sa page blanche personnelle. La page blanche inclut toutes les informations personnelles de l utilisateur. L ensemble des items sera défini ultérieurement (ex : nom, prénom, adresse postale, n téléphone, n mobile, fax, adresse e-mail principale, adresses e-mail alternatives, URL du site web personnel ) Le candidat précisera s il est également possible d y inclure une partie Curriculum Vitae et/ou une liste de publications, avec éventuellement possibilité d ajouter des pièces jointes. Possibilité de modifier son mot de passe. Cette possibilité ne sera active que pour les utilisateurs des établissements sans annuaire LDAP, la modification du mot de passe se faisant alors dans la base interne du Bureau Virtuel. 14/10/2003 2003.059 CRRA CCTP Validé 12

Pour les autres établissements, il n est pas prévu d accès en écriture dans les annuaires, donc pas de modification du mot de passe possible. La modification du mot de passe relève alors de l application de gestion des mots de passe de l établissement. Possibilité d effectuer des recherches sur l annuaire. La recherche doit pouvoir être réalisée sur les différents items de la page blanche. La recherche se fera en premier lieu sur la base des utilisateurs du Bureau Virtuel, puis (si aucune occurrence n est trouvée) en interrogeant les annuaires LDAP des différents établissements. NOTA : la recherche n est possible qu aux utilisateurs authentifiés. NOTA2 : La recherche sur les annuaires des établissements pourra éventuellement être restreinte en fonction des contraintes juridiques liées à cette fonctionnalité (par exemple annuaire des personnels non accessible depuis le BV). Possibilité d ajouter une page blanche issue d une recherche sur l annuaire au carnet d adresses personnel. Possibilité d être en liste rouge. Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour la gestion de l annuaire et des pages blanches. 3.2.1.6. Outils de communication de groupe Le Bureau Virtuel offrira diverses fonctionnalités pour la communication de groupe. Les fonctionnalités attendues de base sont les suivantes : Possibilité de créer et de gérer des groupes d utilisateurs du BV, par les utilisateurs Le BV proposera des procédures de type inscription/desinscription/invitation/radiation des utilisateurs, et gestion des droits (groupes privés, publics, visibles, invisibles ) La gestion des groupes doit permettre la création simple de groupes correspondant aux classes pour les communications «professeur vers élèves». Rappel : Possibilité de partager des contacts (cf 3.2.1.2), partager un agenda (cf 3.2.1.3), des fichiers/dossiers et des favoris (cf 3.2.1.4) entre utilisateurs d un même groupe. Possibilité de participer à une communication de groupe «en asynchrone». Par exemple au travers de listes de diffusions et/ou de forums de discussion (forums internes au Bureau Virtuel et non accessibles aux utilisateurs non authentifiés) Le candidat décrira le mode d administration de ces listes et/ou forums. Possibilité de participer à une communication de groupe «en temps réel». Par exemple au travers d un outils de «chat». Le candidat décrira le mode d administration de ces «chats». Le candidat précisera en outre si le BV offrira des outils de type «tableau blanc» et/ou «conférence audio» voire «conférence vidéo». Le candidat présentera en outre toutes les autres fonctionnalités proposées en standard pour la communication de groupe. 3.2.1.6.1 Administration des forums de discussion Si la solution du candidat propose un outil de forums de discussion, les dispositions suivantes devront être intégrées : Possibilité de modération des forums par le créateur du forum, les établissements ou des représentants du Maître d Ouvrage (les prestations de modération n entrent pas dans le cadre de la présente consultation). Conservation des données de nature à permettre l identification de toute personne ayant participé aux forums de discussion. La solution du candidat doit permettre de retrouver l auteur de tous les messages qui auraient été postés, même après suppression du message par l auteur. 14/10/2003 2003.059 CRRA CCTP Validé 13

Page d information à la connexion au Bureau Virtuel relative aux responsabilités encourues par l utilisateur qui diffuserait des données étrangères à la finalité du Bureau Virtuel et au droit que se réserve le Maître d Ouvrage de supprimer ces informations. Possibilité d arrêter, à tout moment, la diffusion d un message sur le forum, à la demande du Maître d Ouvrage, ou par le modérateur (sans destruction du message). Fermeture anticipée du site, à la demande du Maître d Ouvrage ou d une autorité judiciaire, avec restitution intégrale du site au jour de la fermeture (moyens techniques à développer dans la proposition du candidat). Le candidat précisera dans son offre si la solution proposée met en œuvre tout ou partie de ces dispositions. 3.2.2. Langues Le Bureau Virtuel devra être multilingue, et proposer de base les langues suivantes (au choix de l utilisateur) : Français Anglais Allemand Italien Espagnol Le candidat listera en outre toutes les autres langues proposées en standard. 3.2.3. Gestion des comptes 3.2.3.1. Création des comptes Les comptes des utilisateurs ne seront pas créés a priori. 3.2.3.1.1 Utilisateurs référencés Les comptes des utilisateurs référencés dans l annuaire LDAP de leur établissement (ou dans une base interne du BVE préalablement renseignée par les établissements concernés, cf 3.3.2.1.3) seront automatiquement créés et activés à leur première connexion au Bureau Virtuel (cf 3.3.2 pour l authentification des utilisateurs), après avoir lu et validé une charte d usage en ligne, qui sera définie ultérieurement par le Maître d Ouvrage. 3.2.3.1.2 Utilisateurs non référencés Les établissements auront également la possibilité de créer des comptes pour des utilisateurs non référencés dans leur annuaire LDAP (ex : intervenants extérieurs, enseignants dans des universités partenaires mais d une autre région ). Dans ce cas, la création ne sera donc pas automatique, mais manuelle, au travers de l interface d administration du 3.2.3.2. 3.2.3.2. Administration des comptes L administration des comptes (gestion des droits, des quotas, suppression des comptes ) sera effectuée directement par chacun des établissements. Pour cela, la solution offrira une interface d administration des comptes, pour que chaque établissement puisse gérer à distance les comptes dont il a la responsabilité. Le candidat décrira cette interface d administration des comptes, et l ensemble des fonctionnalités proposées en standard. Il décrira notamment comment seront gérés les changements pour les grandes masses d élèves : Pour les établissements avec annuaire LDAP : suppression des comptes des utilisateurs référencés lorsqu ils ne figurent plus dans l annuaire LDAP des établissements (en fin de cycle) 14/10/2003 2003.059 CRRA CCTP Validé 14

création de groupes d utilisateurs correspondants à un niveau de formation (par exemple tous les élèves de 2 ème année de Deug d histoire de l université X information contenue dans l annuaire LDAP des établissements) Pour les établissements sans annuaire LDAP : renseignement dans la base interne du BVE d une liste des nouveaux utilisateurs potentiels (cf 3.3.2.1.3) suppression d une liste de comptes correspondant aux utilisateurs arrivés en fin de cycle création de groupes d utilisateurs à partir d une liste correspondant à un niveau de formation 3.2.4. Import et export de comptes La solution du candidat devra permettre l import de comptes (messages, carnet d adresses, agendas, fichiers, favoris, et pages blanches) depuis une structure normée qu il précisera. Ainsi, les établissements ayant déjà un autre outil de bureau virtuel devront pouvoir transférer les comptes existants de leurs étudiants et personnels sur le Bureau Virtuel régional. De même, la solution du candidat devra permettre l export des comptes (messages, carnet d adresses, agendas, fichiers, favoris, et pages blanches) dans une structure normée qu il précisera. Ainsi, les comptes des utilisateurs du Bureau Virtuel régional devront pouvoir être transférés simplement sur une autre solution au terme du présent marché. L export des comptes devra également permettre aux utilisateurs de récupérer l ensemble de leurs données dans une structure normée, à la fin de leur scolarité. 3.2.5. Personnalisation du Bureau Virtuel Le candidat précisera l étendue des possibilités de personnalisation de sa solution, par exemple : Ajout de logos de la Région Rhône-Alpes et de l établissement d origine de l utilisateur connecté Police de caractère Personnalisation des couleurs Personnalisation de l organisation des pages (ex : menu à gauche ou en haut ) 3.2.6. Accès depuis d autres média Le candidat précisera si sa solution est accessible depuis d autres média, par exemple depuis un téléphone ou un navigateur WAP. 3.3. EXIGENCES TECHNIQUES 3.3.1. Architecture de la solution Les serveurs seront hébergés dans des locaux universitaires à Lyon et à Grenoble, mais les prestations d exploitation technique et de maintenance seront néanmoins assurées par le titulaire (cf 4.5). Les utilisateurs des établissements du Rhône, de la Loire, et de l Ain accéderont aux serveurs situés à Lyon, tandis que ceux des établissements de l Isère, des Savoies, de la Drôme et de l Ardèche accéderont aux serveurs situés à Grenoble. Ceci, indépendamment du lieu à partir duquel ils y accèdent (depuis leur établissement d origine ou depuis Internet). La figure ci-après présente l architecture générale de la solution. 14/10/2003 2003.059 CRRA CCTP Validé 15

Utilisateurs internautes des établissements du Rhône, de la Loire et de l Ain Utilisateurs internautes des établissements de l Isère, des Savoies, de la Drôme et de l Ardèche Internet Renater Bureau Virtuel Lyon Locaux universitaires à Lyon Locaux universitaires à Grenoble Bureau Virtuel Grenoble Amplivia Etablissement Etablissement Utilisateurs des établissements du Rhône, de la Loire et de l Ain Utilisateurs des établissements de l Isère, des Savoies, de la Drôme et de l Ardèche Figure 2 : Architecture générale de la solution Les utilisateurs accèderont au Bureau Virtuel au travers du portail ou du site web de leurs établissements. Deux cas de figure sont possibles : «Avec portail» : Dans le cas des établissements avec portail, les utilisateurs accèdent au Bureau Virtuel via ce portail. De plus, si le portail dispose d un système d authentification unique (SSO), l utilisateur est automatiquement authentifié (cf 3.3.2.1.1). «Autonome» : Dans le cas des établissements sans portail, les utilisateurs accèdent au Bureau Virtuel via le site web de leur établissement (lien vers le Bureau Virtuel). NOTA : Certains établissements n ont aujourd hui pas de portail mais s en doteront ultérieurement. Dans ce cas, le Bureau Virtuel sera utilisé dans un premier temps en mode «autonome», puis dans un second temps en mode «Avec portail». 3.3.2. Sécurité des accès 3.3.2.1. Authentification des utilisateurs L authentification des utilisateurs s effectuera sur la base du triplet «login / mot de passe / nom de l établissement». 14/10/2003 2003.059 CRRA CCTP Validé 16

Nota : Tous les échanges entre le Bureau Virtuel et les portails ou les annuaires devront être sécurisés. Au minimum, il ne devra pas y avoir de transmission de mots de passe en clair (mais les niveaux de sécurisation plus élevés seront appréciés). Le candidat précisera les mécanismes de sécurisation proposés dans le cadre de sa solution. De plus, le système devra conserver les logs des connexions de façon à permettre l identification des utilisateurs sur le BVE (stockage des adresses IP des utilisateurs, des logins de connexion, et des date et heure de connexion). Selon les établissements, 3 cas sont possibles : L établissement dispose d un mécanisme d authentification unique (SSO) L établissement dispose d un annuaire LDAP (mais pas de SSO) L établissement ne dispose pas d annuaire LDAP Le Bureau Virtuel doit pouvoir fonctionner avec ces trois types d établissements. 3.3.2.1.1 Etablissements avec SSO Pour les établissements avec SSO, l utilisateur doit s authentifier au préalable sur le portail. Ensuite, en accédant au Bureau Virtuel, il est automatiquement identifié et authentifié. Il n a pas besoin d entrer de nouveau son «login / mot de passe». C est le portail qui transmet directement au Bureau Virtuel les données d authentification via l une des interfaces d authentification supportées par le Bureau Virtuel, que décrira le candidat. La figure ci-après présente le mécanisme d authentification pour ce type d établissements. Bureau Virtuel connexion au BV via le portail Portail authentification Jeton ou autres données d authentification Base utilisateurs (profils) LDAP Figure 3 : Authentification des utilisateurs d établissements avec SSO 3.3.2.1.2 Etablissements avec annuaire LDAP (sans SSO) Pour les établissements avec annuaire LDAP (mais sans SSO), l utilisateur doit s authentifier lorsqu il accède au Bureau Virtuel. Il entre son «login / mot de passe / établissement», et le Bureau Virtuel authentifie l utilisateur directement auprès de l annuaire LDAP de l établissement. La figure ci-après présente le mécanisme d authentification pour ce type d établissements. 14/10/2003 2003.059 CRRA CCTP Validé 17

Site web Bureau Virtuel connexion au BV via le site web authentification Base utilisateurs (profils) LDAP Figure 4 : Authentification des utilisateurs d établissements avec annuaire LDAP (sans SSO) 3.3.2.1.3 Etablissements sans annuaire LDAP Pour les établissements sans annuaire LDAP, l utilisateur doit s authentifier lorsqu il accède au Bureau Virtuel. Il entre son «login / mot de passe / établissement», et le Bureau Virtuel authentifie l utilisateur d après une base interne, qui aura été renseignée à partir d une liste de logins / mots de passe fournie par les établissements concernés. La figure ci-après présente le mécanisme d authentification pour ce type d établissements. Site web Bureau Virtuel authentification connexion au BV via le site web Base utilisateurs (profils) Figure 5 : Authentification des utilisateurs d établissements sans annuaire LDAP 3.3.2.2. Sessions sécurisées Le candidat indiquera si sa solution propose en standard la possibilité de sessions sécurisées (sessions SSL, avec un certificat valide, délivré par une autorité de certification reconnue, préparamétrée dans la plupart des navigateurs web). Cette fonctionnalité, qui doit rester au choix de l utilisateur, permettrait de crypter l ensemble des transmissions entre l utilisateur et le Bureau Virtuel. Si la solution du candidat n offre pas de possibilité de sessions sécurisées en standard, le candidat la chiffrera en option. 3.3.2.3. Sécurisation des accès TCP/IP Le titulaire aura également en charge la sécurisation (filtrage) des accès entre Internet et le BVE, sur chacun des sites d hébergement. Seuls les accès strictement nécessaires au fonctionnement du BVE seront autorisés, par exemple : d Internet vers le BVE : HTTP, HTTPS, SMTP, POP3, IMAP du BVE vers les serveurs LDAP des établissement : LDAP sécurisé du site de maintenance du titulaire vers les serveurs BVE : SSL, Les candidats préciseront dans leur offre les règles de filtrage qu ils comptent mettre en œuvre sur le BVE. Ces règles de filtrages seront à préciser et à valider avec le maître d ouvrage lors de la phase de mise en œuvre. 14/10/2003 2003.059 CRRA CCTP Validé 18

3.3.2.4. Protection des données Le données stockées dans le BVE (Mail, espace de stockage) ne devront être accessibles qu à leurs utilisateurs préalablement authentifiés, ainsi qu aux administrateurs authentifiés. Les candidats décriront les mécanismes mis en œuvre pour assurer la protection de données, contre des tentatives d accès non autorisées. 3.3.3. Dimensionnement des matériels 3.3.3.1. Serveurs Pour le bon dimensionnement des matériels, le candidat considérera que le nombre d utilisateurs actifs simultanés en pic sera de 5%. Le dimensionnement initial des CPU sera calculé sur une base de 100 000 utilisateurs, soit : 60 000 utilisateurs sur la plate-forme de Lyon, donc 3 000 utilisateurs actifs simultanés en pic 40 000 utilisateurs sur la plate-forme de Grenoble, donc 2 000 utilisateurs actifs simultanés en pic Le candidat indiquera comment sa solution sera dimensionnée et quels seront les mécanismes mis en œuvre (ex : load balancing, clusters ) pour supporter la charge des milliers d utilisateurs pouvant potentiellement se connecter simultanément au Bureau Virtuel. Le candidat présentera des schémas d architecture pour 100 000 utilisateurs et pour 200 000 utilisateurs, ainsi que les évolutions possibles si les performances ne sont pas satisfaisantes. Le candidat précisera notamment le nombre de serveurs prévus pour chaque composants. 3.3.3.2. Messagerie Chaque utilisateur disposerait, pour stocker ses e-mails, d un espace disque maximum (= quota) de : 50Mo pour les étudiants jusqu en master (~90% des utilisateurs potentiels) 100Mo pour les doctorants et les personnels (~10% des utilisateurs potentiels) Le dimensionnement initial des disques sera au minimum de 20% de la somme des quotas théoriques, soit : 1,5 To sur la plate-forme de Lyon 1 To sur la plate-forme de Grenoble Un système de «formules de quotas» (ex : 50Mo, 100Mo) par «type d utilisateur» (ex : étudiants jusqu en master, doctorants, enseignants, personnels administratifs ) sera mis en place pour faciliter la gestion des quotas. L établissement responsable de l administration des comptes pourra ainsi, au cas par cas, changer un utilisateur de formule de quota, ou encore changer d un coup les quotas de l ensemble des utilisateurs correspondant à une formule de quota donnée. 3.3.3.3. Espace de stockage Chaque utilisateur disposera, pour stocker ses fichiers, d un espace disque maximum (= quota) de : 150Mo pour les étudiants jusqu en master (~90% des utilisateurs potentiels) 300Mo pour les doctorants et les personnels (~10% des utilisateurs potentiels) Le dimensionnement initial des disques sera au minimum de 20% de la somme des quotas théoriques, soit : 4,5 To sur la plate-forme de Lyon 3 To sur la plate-forme de Grenoble Le système de «formules de quotas» présenté au 3.3.3.2 sera étendu aux quotas pour l espace de stockage des fichiers. 3.3.4. Pérennité des données en cas de panne Le candidat doit prévoir des mécanismes permettant d assurer la pérennité des données en cas de panne. 14/10/2003 2003.059 CRRA CCTP Validé 19

En cas d incident mineur (ex : panne d un disque), les données doivent pouvoir être restituées simplement et rapidement. L utilisateur retrouve alors toutes ses données enregistrées, éventuellement après reconnexion. En cas d incident majeur (ex : destruction d une baie de disques), les données doivent pouvoir être restituées au minimum dans l état où elles se trouvaient la veille de l incident. Le Maître d Ouvrage acceptera par exemple les solutions techniques reposant sur 2 jeux de disques «échangeables à chaud» configurés en mode RAID 0+1 (mirroring), dont l un des deux jeux serait échangé chaque jour avec un 3 ème jeu de disques et placé dans un coffre ignifuge. Le candidat présentera l ensemble des mécanismes et procédures qu il propose pour assurer la pérennité des données. 3.3.5. DNS Le candidat devra prévoir des services DNS primaire et secondaire pour le bon fonctionnement du BVE. Le titulaire aura en charge la gestion des noms de domaines du BVE, au titre des prestations d exploitation technique (Poste 5, cf 4.5.5). 3.3.6. Routage SMTP La politique liée au routage SMTP sera définie avant le démarrage du projet. 3 possibilités sont actuellement envisagées : 3.3.6.1. Les noms de domaines existants des établissements sont réutilisés Par exemple : login@établissement.fr Dans ce cas, il n y a pas de routage SMTP spécifique à prévoir ; ce sont les établissements qui se chargeront de rediriger les messages vers les plates-formes BVE de Lyon ou Grenoble, selon l établissement. 3.3.6.2. Les noms de domaines qui seront utilisés seront nouveaux, mais spécifiques à chaque établissement Par exemple : login@établissement.rhone-alpes.fr Dans ce cas, le candidat devra prévoir (via un paramétrage du DNS) un routage spécifique des mails vers les plates-formes BVE de Lyon ou Grenoble, selon l établissement. 3.3.6.3. Le nom de domaine qui sera utilisé sera unique et ne permettra pas de reconnaître un établissement particulier Par exemple : login@bve.rhone-alpes.fr Dans ce cas, le candidat devra prévoir (via un paramétrage du DNS) un routage systématique des mails vers un serveur central (éventuellement placé sur l un des deux sites) reroutant les mails vers la plate-forme BVE adéquate (sur la base du login). Cette solution nécessitera l installation d un relais de messagerie qui devra faire l objet d une option chiffrée dans le Bordereau des Prix (Poste 2). 3.3.7. Support des principaux navigateurs web du marché Le Bureau Virtuel devra impérativement fonctionner sans client lourd. Le candidat indiquera quelles sont les navigateurs (Internet Explorer, Netscape Navigator et Mozilla) compatibles avec le Bureau Virtuel, en précisant les versions minimales (sous Windows, sous MacOS, sous Linux). Nota : Le Maître d Ouvrage privilégie les solutions fonctionnant au minimum sur les navigateurs web suivants : Internet Explorer v5.x et suivantes Netscape Navigator v6 et suivantes 14/10/2003 2003.059 CRRA CCTP Validé 20

Le candidat indiquera les différences fonctionnelles (pour l utilisateur) qu il pourrait y avoir selon l OS du poste client et selon le type et la version du navigateur web utilisés. Nota : Le Maître d Ouvrage privilégie les solutions ne nécessitant pas le téléchargement d add-ons et de plugins, ou les limitant à des fonctionnalités très spécifiques (audio-conférence, synchronisation PDA, etc). Dans ces cas exceptionnels, le candidat indiquera pour quelles fonctionnalités des add-ons ou des plugins sont nécessaires et leur mode de téléchargement, par exemple : automatique ou manipulation nécessaire? par l utilisateur ou par un administrateur? à chaque fois ou seulement à la première utilisation? 3.4. CONFORMITE Le candidat confirmera que la solution proposée est conforme aux normes et standards en vigueur et que ses prestations seront conçues et exécutées selon les règles de l art. En particulier, la solution proposée devra tenir compte des standards d accessibilité aux personnes handicapées. 3.5. ENVIRONNEMENT 3.5.1. Hébergement des serveurs Les serveurs seront hébergés dans des locaux universitaires (un local à Lyon et un local à Grenoble), dans des baies fournies et installées par le titulaire. NOTA : les travaux d aménagement des salles d hébergement ne seront pas à la charge du titulaire. Variante possible : S il l estime plus avantageuse pour la Région, le candidat pourra décrire (en plus de la solution de base), et chiffrer, une solution variante dans laquelle c est le titulaire qui héberge les serveurs dans ses propres locaux et qui fournit la connectivité à Amplivia, Renater ou Internet). Dans ce cas, le candidat prévoira (et intégrera dans son chiffrage) un relais SMTP pour le BVE. En cas d'indisponibilité de la connexion vers le BVE (dysfonctionnement serveur ou réseau), le système devra stocker les messages pendant au minimum 48H. 3.5.2. Alimentation des serveurs Dans le cadre de l installation des serveurs, le titulaire prend en charge les raccordements électriques nécessaires au fonctionnement complet du système. Le candidat considérera que le courant mis à disposition est du 230V. Le titulaire aura également en charge l ondulation du courant électrique. La durée d autonomie du système en cas de coupure de courant doit être d au moins 30 minutes. L ondulation du courant (technologie «online») doit protéger le système des surintensités, courts-circuits, surtensions (dont foudre) et soustensions. 3.5.3. Contraintes des matériels Les travaux d aménagement des salles d hébergement ne seront pas à la charge du titulaire. Néanmoins le candidat précisera les contraintes particulières des matériels proposés, en particulier : dégagement calorique des équipements et les besoins en climatisation (température, hygrométrie...), la nécessité d'une terre avec ses caractéristiques, la protection contre la foudre besoins en alimentation électrique, qualitativement (nombre de prises,...) et quantitativement (puissance électrique nécessaire) L encombrement nécessaire pour loger les équipements proposés et la charge au sol requise, ou autres contraintes de fixation ou de maintien (fixation sur un mur, par exemple) 14/10/2003 2003.059 CRRA CCTP Validé 21