Acquisition d`une solution de gestion de données de références

Transcription

Acquisition d’une solution de
gestion de données de références
Cahier des Clauses Techniques Particulières
22/03/2012
Université de Strasbourg
22/03/2012
Acquisition d’une solution de gestion de données de références
Table des matières
1.
Objet du marché .......................................................................................................................... 3
2.
Présentation du projet ................................................................................................................. 3
3.
2.1
Présentation du contexte ................................................................................................... 3
2.2
Objectif du projet .............................................................................................................. 4
2.3
Organisation du projet ...................................................................................................... 4
Exigences fonctionnelles ............................................................................................................ 5
3.1
Ergonomie......................................................................................................................... 5
3.2
Modélisation des modèles métiers .................................................................................... 5
3.3
Gestion des versions ......................................................................................................... 6
3.4
Workflow .......................................................................................................................... 6
3.5
Gestion des règles métiers ................................................................................................ 7
3.6
Gestion des droits d'accès ................................................................................................. 7
3.7
Intégration au Système d'Information ............................................................................... 7
3.8
Qualité de données ............................................................................................................ 8
3.9
Gestion des données ......................................................................................................... 9
3.10
Intégration des différents modules de la solution ....................................................... 10
4.
Exigences non-fonctionnelles et techniques ............................................................................. 10
5.
Scénario de déploiement ........................................................................................................... 11
6.
7.
8.
5.1
Référentiel « personnes »................................................................................................ 12
5.2
Référentiel « structures organisationnelles» ................................................................... 14
5.3
Exigences de disponibilité .............................................................................................. 15
Prestations attendues ................................................................................................................. 16
6.1
Fourniture du logiciel ..................................................................................................... 16
6.2
Support et maintenance................................................................................................... 16
Modalités de la consultation ..................................................................................................... 16
7.1
Contenu de l’offre ........................................................................................................... 17
7.2
Critères de jugement des offres ...................................................................................... 18
Annexes .................................................................................................................................... 19
8.1
Description du poste client standard ............................................................................... 19
8.2
Grille de réponse ............................................................................................................. 20
2/24
22/03/2012
1. Objet du marché
Le présent document constitue le Cahier des Clauses Techniques et Particulières (CCTP) d'un
Marché À Procédure Adaptée (MAPA) visant à doter l'Université de Strasbourg (Unistra) d'un
logiciel de gestion de données de références (« Master Data Management » en anglais, ou MDM).
2. Présentation du projet
2.1 Présentation du contexte
2.1.1 L'Université de Strasbourg
L’Université de Strasbourg a pris naissance le 1 janvier 2009 suite à la fusion des trois universités
Louis Pasteur, Marc Bloch et Robert Schuman et de l’IUFM. Avec plus de 42 000 étudiants, 7000
stagiaires en formation continue et quelques 5 000 personnels, elle est une des premières universités
de France.
Pluridisciplinaire, son activité de recherche et son offre de formation couvrent les quatre secteurs
reconnus par le Code de l'Éducation : les disciplines juridiques, économiques et de gestion, les lettres
et les sciences humaines et sociales, les sciences et technologies et les disciplines de santé.
S’appuyant sur tous les domaines du savoir, elle entend mener une politique innovante en termes de
formation initiale et continue, de recherche, d’insertion professionnelle de ses étudiants tout en
jouant un rôle majeur au cœur de la cité et sur la scène internationale. Elle inscrit son action au cœur
de nombreux partenariats. Citons, entre autres, EUCOR, (Confédération des Universités du Rhin
supérieur), qui comprend la Suisse avec Bâle et l’Allemagne avec Karlsruhe et Fribourg (deux
universités parmi les 10 universités d’excellence allemande) et, la LERU (Ligue des Universités
Européennes de Recherche), deux réseaux dont elle est membre fondateur.
L’Université de Strasbourg figure parmi les 20 universités qui se sont dotées dès janvier 2009 des
compétences élargies. Elle est par ailleurs lauréate de l’opération campus initiée par le Ministère de
l’enseignement supérieur et de la recherche. Elle s’est lancé le défi d’occuper bientôt une place de
choix dans le paysage universitaire international. Son premier contrat quadriennal est le reflet de
cette ambition.
Les résultats récents aux appels à projets investissement d’avenir (EquipEx, LabEx, IdEx...)
renforcent sa visibilité nationale et internationale.
2.1.2 Le Schéma Directeur Numérique
L’Université de Strasbourg est la première université française à s’être dotée d’un Schéma Directeur
Numérique (SDN). Sa stratégie est ambitieuse : elle vise à accompagner l’Université dans sa position
de leadership européen par la mise en place de tous les projets identifiés au cours de l’étude sur les
aspects d’infrastructures, d’accès, de gestion, de vie universitaire et de pédagogie.
Les résultats du Schéma Directeur Numérique ont permis de donner les ordres de grandeurs des
investissements à effectuer et de définir les projets à exécuter répartis sur les quatre prochaines
années.
Le SDN, actualisé en 2010 et 2011, comporte une quarantaine de projets majeurs couvrant
l'ensemble des champs du numérique, depuis les infrastructures techniques, les évolutions de
système d’information jusqu'au développement des usages. Ces projets intègrent des chantiers
3/24
22/03/2012
structurants tels que la refonte des processus, et l’accompagnement au changement. Ce schéma
directeur s’accompagne d’un plan de recrutement et de développement des compétences pour
conduire la mise en œuvre du Schéma Directeur Numérique, ainsi que d’un renforcement des
maîtrises d’ouvrage, par recrutement et par apport d’expertise et d’assistance externe.
2.2 Objectif du projet
Le Schéma Directeur Numérique de l’université comprend des projets de refonte de ses SI métiers
principaux. Un nouveau SI financier a ainsi été mis en production en janvier 2011, un projet de
déploiement du SI « scolarité » est en cours, et le SI « ressources humaines » suivra. La refonte de
ces briques du système d’information est une opportunité unique d’effectuer des travaux de fonds sur
les référentiels de l’université, ainsi que leur intégration.
Une étude réalisée au sein de l’université a ainsi proposé comme axe prioritaire la création d’un
référentiel des personnes et d’un référentiel des structures organisationnelles. Ces données sont en
effet manipulées par plusieurs SI métiers, et nécessitent donc une consolidation au sein d’une entité
tierce, qui deviendra maître de ces données.
L’université souhaite s’équiper d’un produit de gestion des données de références, afin de disposer
des fonctionnalités offertes par cette gamme de produit pour faciliter la création de ces référentiels et
surtout en maintenir la cohérence et la qualité des données.
2.3 Organisation du projet
2.3.1 Logiciel et prestations
Le présent marché représente la première étape de ce projet. Il concerne l'acquisition de l'outil qui
permettra d'implémenter les deux référentiels sus-cités, ainsi que la prestation de support associée.
La prestation d'intégration du produit acquis par la présente procédure fera l'objet d'un marché
subséquent au lot 3 de l'accord-cadre d'assistance à maîtrise d'ouvrage à la réalisation du Schéma
Directeur Numérique. La formation à l’administration de la solution et au développement sera
effectuée dans le cadre de cette prestation.
La constitution des deux référentiels « Personnes » et « Structures » sera réalisée avec une prestation
d'assistance à maîtrise d'ouvrage. Celle-ci fera l'objet d'un marché subséquent au lot 2 de l'accordcadre d'assistance à maîtrise d'ouvrage à la réalisation du Schéma Directeur Numérique.
2.3.2 Équipe projet université
L'équipe projet de l'université sera composée des membres suivants :

l'architecte fonctionnel assurant la fonction de chef de projet métier ;

des représentants du Service d'Aide au Pilotage (SAP) de l'université ;

des représentants métiers de l'université ;

un chef de projet technique ;

l'architecte du système d'information ;

un gestionnaire d'application ;

un développeur/intégrateur d'application ;
4/24
22/03/2012

un administrateur système SGBD.
2.3.3 Planning
L'université souhaite coordonner la mise en place de ses référentiels « Personnes » et « Structures »
avec son projet de refonte du système d'information de « scolarité » pour la gestion des formations et
le suivi des étudiants (projet « Alisée »). À titre indicatif, le planning prévisionnel de l'université sur
le projet « Référentiel » est le suivant :

avril 2012 : notification au candidat retenu dans le cadre du présent marché ;

mai 2012 : notification des marchés subséquents d’assistance à maîtrise d’ouvrage et
d’assistance à maîtrise d’œuvre ;

juin 2012 : comité de pilotage de lancement du projet « Référentiel » ;

octobre 2012 : mise en production d'une première version du référentiel permettant
l'interfaçage avec le nouveau SI scolarité.
3. Exigences fonctionnelles
3.1 Ergonomie
Les interfaces homme-machine doivent être intuitives, compréhensibles et utilisables par des
personnes occupant des fonctions métiers. Le soumissionnaire est invité à intégrer des copies
d'écrans dans son dossier de réponse, afin d’exposer les avantages ergonomiques de la solution.
3.2 Modélisation des modèles métiers
Les objets « personnes » et « structures » manipulés dans l'outil doivent correspondre au mieux au
fonctionnement de l'université. A terme, l'outil pourrait être utilisé pour gérer d'autres données de
références. Il devra donc permettre la modélisation d'objet métier, sans imposer de modèles
prédéfinis.
3.2.1 Modèles métiers préétablis adaptables
Des modèles métiers préconfigurés peuvent être proposés avec l'application pour aider à la
modélisation. Ceux-ci doivent être adaptables et extensibles par l'université.
3.2.2 Héritage entre objets
Le candidat précisera si la solution permet d'établir une hiérarchie entre les modèles, permettant ainsi
à un objet fils d'hériter des attributs de son père.
3.2.3 Relations entre objets
La solution doit permettre de modéliser des relations entre objets sur plusieurs niveaux. Ces relations
doivent pouvoir être hiérarchiques ou associatives. Un objet feuille doit pouvoir appartenir à
plusieurs hiérarchies différentes. Les limites en nombre de niveaux ou de relations par objet seront
précisées.
5/24
22/03/2012
3.2.4 Typage des attributs
La solution doit permettre de typer les attributs associés aux objets. Les types de données gérés par la
solution devront à minima être les suivants : numériques, texte, date, liste de valeurs. L'exhaustivité
étant privilégiée, le candidat listera l'ensemble des types de données gérés par le produit (ex : images,
document texte, etc.).
3.3 Gestion des versions
Le candidat précisera si la solution permet de créer des versions des modèles pour des besoins
d'historisation et d'évolution du modèle (version de travail). Le candidat détaillera la procédure et les
contraintes de mise en production d'une nouvelle version du modèle. Pour faciliter l'adaptation
décalée des SI consommateurs, la possibilité d'avoir deux versions consécutives du modèle en
production sera un plus.
3.4 Workflow
La solution doit fournir un moteur de workflow pour gérer le cycle de vie de l'objet de référence.
3.4.1 Outil de modélisation
La modélisation des workflows via une interface graphique sera privilégiée.
3.4.2 Actions couvertes
Le candidat précisera les opérations pouvant être couvertes par des workflows, l'exhaustivité étant
privilégiée. Les actions à couvrir à minima sont : création, modification, suppression, validation.
3.4.3 Processus multiples par objet
Des instances d'un même objet devraient pouvoir être pilotées, pour une même action, par un
workflow différent selon leur appartenance à une population spécifiée. Par exemple, la création des
individus de l'Université de Strasbourg et des individus de l'ENGEES (école d’ingénieur extérieure à
l’Unistra mais dont l’Unistra gère certaines applications et dont les personnels doivent être dans le
référentiel) pourrait suivre un processus différent.
3.4.4 Gestion des versions
Le candidat précisera si la solution permet de créer des versions des workflows pour des besoins
d'historisation et d'évolution du modèle (version de travail). Le candidat détaillera la procédure et les
contraintes de mise en production d'une nouvelle version du workflow (ex : gestion des processus en
cours d'exécution lors de la migration).
3.4.5 Exécution
L'interface homme-machine d'exécution des processus sera mise à disposition d'utilisateurs métiers
et se doit en conséquence d'être ergonomique tout en restant complète. Chaque utilisateur devrait
disposer d'un tableau récapitulatif de suivi de ses actions. L'utilisateur devrait pouvoir s'abonner à un
système d'alerte (courrier électronique, flux RSS ou autre à préciser) pour être informé des actions le
concernant (actions sur les workflows qu'il a pu initier, ou actions le concernant).
Un tableau récapitulatif des workflows en cours d'exécution devrait pouvoir être proposé aux
6/24
22/03/2012
administrateurs de la plate-forme.
3.5 Gestion des règles métiers
La solution doit permettre la gestion de règles métiers.
3.5.1 Gestion des règles métier
La solution doit permettre l’implémentation de règles métiers. Le candidat doit documenter les
possibilités d’implémentation de ces règles.
3.5.2 Outil de modélisation
Un outil graphique de modélisation des règles métiers sera privilégié.
3.6 Gestion des droits d'accès
La solution doit permettre la gestion de droits d'accès fins aux fonctionnalités et données qu'elle
héberge.
3.6.1 Niveaux de droits
Les droits d'accès devraient pouvoir être attribués à plusieurs niveaux :

actions autorisées : création, modification, suppression, validation, instanciation d'un
workflow, etc. ;

modèles et leurs attributs : limiter l'accès à certains modèles, ou plus finement à certains
attributs d'un modèle. Exemple : le nom et prénom des personnes;

groupe d'objets : limiter l'accès aux instances d'un objet liées par leur valeur commune d'un
attribut. Exemple : les personnes affectées à la composante X.
Ces niveaux de droits doivent pouvoir être cumulables. Exemple : droit de modification des noms et
prénoms des personnes affectées à la composante X.
3.6.2 Gestion des rôles
Les droits sus-cités devraient pouvoir être affectés directement à des utilisateurs nommés, mais
également à des rôles. Ces derniers étant attribués à un ou plusieurs utilisateurs. Un utilisateur doit
pouvoir cumuler les rôles.
3.7 Intégration au Système d'Information
L'outil doit pouvoir s'interfacer aisément au système d'information de l'université. Les données
gérées par l'outil doivent pouvoir être mises à disposition des SI fonctionnels en respectant les
standards d'architecture de l'université.
3.7.1 Exposition de web-services
Les opérations de manipulation des données doivent être exposées via des webservices respectant les
normes SOAP ou REST. Ces webservices doivent être générés automatiquement en regard des objets
métiers modélisés. Le candidat précisera les fonctions exposées. Les opérations de création,
7/24
22/03/2012
modification, suppression, validation et exécution d'un workflow sont souhaitées.
3.7.2 Outil de d'échange de données batch intégré
Le candidat précisera si la solution inclut un outil d'échange et de transformation des données (ETL :
Extract-Transform-Load). Si c'est le cas, cet outil sera décrit notamment sur les points suivants :

ergonomie de l'outil ;

connecteurs livrés en standard ;

possibilité de créer des connecteurs propres à l'université ;

fonctions de transformation livrées en standard,

possibilité de créer des transformations propres à l'université ;

fonctionnalité de déploiement des travaux en production

fonctionnalité de planification et ordonnancement des travaux

gestion des versions des travaux
3.7.3 Intégration standard avec des outils ETL tierces
Le candidat présentera les modes d'interfaçage supportés par la solution pour l'intégration avec des
outils ETL tierces. Les applications ayant déjà fait l'objet d'une intégration avec la solution seront
listées.
3.7.4 Échange de données temps réel
Certaines données gérées par la solution devront être échangées dans des délais très courts (≤
5minutes) avec des SI tierces. Le candidat précisera si la solution permet :

l'émission en temps réel des modifications vers d'autres SI ;

la détection de mise-à-jour de données dans des SI tierces.
Les technologies employées, les contraintes et les éventuels prérequis (application middleware
tierces compatibles) seront précisés.
3.8 Qualité de données
L'amélioration de qualité des données du SI de l'université étant un des objectifs principaux du
projet, la solution devra être dotée de fonctionnalités de vérification de la qualité des données.
3.8.1 Moteur de gestion de la qualité des données
La solution devrait permettre de positionner des contraintes sur les attributs afin d'assurer le respect
d'un format commun (ex : valeur non-vide, format de date, etc.). Ces contraintes seraient vérifiées
lors de l'alimentation de données.
La possibilité de paramétrer des corrections automatiques est un plus. Le candidat listera les
fonctions de corrections automatiques disponibles (ex : capitalisation, remplacement de valeur selon
une base de connaissance, etc.).
8/24
22/03/2012
3.8.2 Dé-doublonnage et rapprochement
La solution doit proposer un moteur de détection de doublons. Les critères de dé-doublonnage et le
niveau de tolérance doivent être paramétrables. Selon ce dernier critère, la résolution des doublons
doit pouvoir être effectuée automatiquement ou demander une intervention humaine. Les résolutions
manuelles doivent être effectuées via une interface graphique permettant de comparer les entrées et
de constituer l'enregistrement final.
3.8.3 Surveillance
La solution devrait permettre le paramétrage de déclenchement d'actions sur certains événements. Le
candidat listera les événements et actions gérées par la solution. L'université souhaiterait à minima
gérer les événements de modification de données et d'expiration de dates. Les actions essentielles
seraient la remontée d'alerte et le démarrage d'un workflow.
3.9 Gestion des données
La solution doit proposer un ensemble de fonctionnalités permettant d'assurer la gestion des données
et de garantir leur fiabilité.
3.9.1 IHM métier gestion des données
La solution doit proposer une interface homme-machine à destination des usagers métiers pour la
gestion quotidienne des données. Les opérations proposées doivent être à minima la lecture, la
création, la modification et la suppression. Cette interface doit être générée automatiquement selon le
modèle de données.
3.9.2 Requêtes des données
La solution devra proposer des fonctionnalités d'écriture de requêtes permettant d'accéder à des
échantillons d'éléments stockées dans le référentiel. Les critères de sélection peuvent aussi bien être
des valeurs d'attributs que des informations opérationnelles (état de validation, d'erreur, etc.). La
génération de statistiques associées (ex : taux d'erreurs, taux d'alimentation, etc.) est souhaitée.
3.9.3 Traçabilité des actions
Les opérations effectuées sur les données doivent être journalisées. L’université souhaite pouvoir
conserver les informations suivantes :

la date de l'opération ;

l'auteur de l'opération (cas d’une modification manuelle) ou la source de données (cas
d’import de données depuis un SI métier) ;

la nature de l'opération (création, modification, suppression, etc.) ;

l'élément impacté (objet ou attribut).
La conservation des informations suivantes serait un plus :

l'ancienne valeur de l'élément ;

sa nouvelle valeur le cas échéant.
9/24
22/03/2012
3.9.4 Gestion de version des données
La solution doit permettre la gestion de version des données à des fins d'historisation. Une version
antérieure doit pouvoir être restaurée en version « de production ». La possibilité d'anticiper une
mise-à-jour et d'attribuer une date d'effet sur les mises-à-jour est souhaitable.
3.9.5 Expiration des données
Un mécanisme d’archivage et de suppression automatique des données, basé sur des dates définies
manuellement ou automatiquement par une règle métier, est souhaitable.
3.10 Intégration des différents modules de la solution
Les différents modules et fonctionnalités doivent être pleinement intégrés. Les différents procédés
d'alimentation, qu'ils soient manuels via une IHM ou automatique via un ETL intégré, doivent tenir
compte des règles métiers implémentées et faire appel au moteur de qualité de données. De la même
manière, les droits d'accès doivent être pris en compte au sein de tous les modules de l'application.
L'accès aux différentes fonctionnalités par l'utilisateur doit se faire via un seul point d'accès. Une
tolérance est faite pour les administrateurs devant utiliser des outils de paramétrages et
développement particuliers.
4. Exigences non-fonctionnelles et techniques
La solution se doit d'être le plus en adéquation possible avec l'environnement technique de
l'université, synthétisé dans le tableau suivant. Le candidat détaillera les spécifications de sa solution
concernant les exigences décrites.
Domaines des
Exigences
1. Général
N°
Description
1.1
Accès Web pour les utilisateurs standards
1.2
Client Lourd toléré pour les gestionnaires, développeurs et
administrateurs
1.3
Architecture N-Tiers
2.1
Architecture x86-64
2.2
Systèmes d’exploitation : Linux (Ubuntu 10.04, RedHat 5
minimum) préféré, Windows Serveur 2008
2.3
Système de virtualisation KVM
3. Base de données
3.1
Oracle, MySQL et PostreSQL prioritaires, SQL Server
acceptable
4. Stockage
4.1
Baies NetApp, accès iSCSI ou NFS
5. Réseau
5.1
10Gb en cœur de réseau
5.2
1Gb en extrémité
5.3
Couche 3: cohabitation IPv4 et IPv6, multicast
5.4
Sans-fil: 802.11a/b/g/n
2. Serveurs
10/24
22/03/2012
Domaines des
Exigences
N°
Description
5.5
Pare-feux routés et bridgés
6. Sauvegarde
6.1
Solution "Atempo Time Navigator"
7. Postes clients
7.1
Compatibilité avec les postes de travail standards de l’université
(cf. annexe « 8.1 Description du poste client standard »)
7.2
Postes Microsoft Windows intégrés dans un Active Directory
8.1
Services d'authentification :
 annuaire OpenLDAP
 single sign-on : CAS, Shibboleth, Kerberos
Chiffrement des flux entre postes clients et serveurs
8. Sécurité
8.2
8.3
Les systèmes doivent permettre l’installation des mises-à-jour de
sécurité régulières.
8.4
Possibilité de mettre en place une détection de tentative
d’intrusion souhaitable
9. Messagerie
électronique
9.1
Serveurs de messagerie :
· Service d'envoi SMTP (RFC 2821)
· Service de consultation IMAP4S (RFC 3501) / POP3S (RFC
1939)
10. Logiciels serveurs
10.1 Apache et Tomcat privilégiés. IIS acceptable
11. Exploitation
11.1 Journalisation des évènements sur les serveurs. Une
journalisation de type « syslog » sera privilégiée pour permettre
la centralisation des journaux sur un serveur dédié de l’université
(hors du cadre du présent marché).
11.2 Prise en main des serveurs à distance par VPN IPSEC en SSH
pour Linux et RDP pour Windows
11.3 Supervision du service par les outils en place à l’université :
Nagios et Centreon
11.4 La solution doit permettre un fonctionnement en hautedisponibilité : tolérance à la panne d’un composant applicatif à
chaque niveau. À terme, fonctionnement en datacenter sur deux
sites permettant une disponibilité 24h/24
12. Écologie
12.1 Limiter le nombre de serveurs physiques
5. Scénario de déploiement
Le présent chapitre présente une hypothèse de déploiement de la solution au sein de l'université de
Strasbourg dans le cadre de la réalisation des référentiels personnes et structures. Ce scénario a pour
but de permettre au candidat de :
 prendre sommairement connaissance du SI de l'université
 pouvoir proposer une offre en adéquation au besoin
11/24
22/03/2012
 pouvoir évaluer les coûts en licences logicielles au plus juste
Ce scénario est basé sur l'organisation aujourd'hui en place à l'université. La phase de conception
détaillée des référentiels pourra amener à revoir cette organisation. Le candidat remplira la grille de
réponse fournie en tenant compte de ce scénario.
Dans les tableaux suivants, la colonne « phase initiale » indique si l’élément concerné sera mis en
place en phase initiale. Les valeurs possibles pour cette colonne sont :
 O : Oui
 N : Non
Les licences acquises dans la commande initiale devront permettre la mise en place des éléments mis
en place en phase initiale. Si nécessaire, des licences complémentaires seront acquises par
l’université par des commandes ultérieures dans le cadre du présent marché (cf. « 6.1 Fourniture du
logiciel ») pour permettre la réalisation des autres éléments ou couvrir une extension de besoin sur
les éléments fournis.
5.1 Référentiel « personnes »
L'architecture du référentiel des personnes sera basée sur un modèle coopératif. Les données relatives
aux personnes seront intégrées dans l'outil de MDM depuis plusieurs SI producteurs. Ces derniers
seront également consommateurs des données consolidées fournies par le référentiel.
5.1.1 Typologie de personnes gérées
Description
SI source
Employés Unistra SI RH Unistra (Harpège AMUE)
Étudiants Unistra SI Scolarité Unistra
(Banner - Sungard)
Nombre
Commentaire
Phase
initiale
- A terme, migration vers le
6.000 produit de l'AMUE en cours de
conception
O
- Formation initiale et continue
- Banner : projet en cours
O
50.000
Extérieurs Unistra Référentiel des personnes
(présent marché)
- Chercheurs hébergés,
consultants, etc.
4.000
- Saisie décentralisée en
composante, services et
laboratoires
O
- jusqu'à 300 gestionnaires
Anciens étudiants SI Scolarité Unistra
Unistra
(Banner - Sungard)
Lecteur externes
de bibliothèques
Unistra
Système d'information de
gestion de bibliothèque
(SIGB) ou référentiel des
1.000
- Actuellement gérés par une
application développée en interne
- Mise en service 2014 (cf.
remarques)
Noter qu’il y a actuellement 4
1.000 SIGB différents, la mise en place
d’un SIGB unique est prévue pour
O
N
12/24
22/03/2012
Description
SI source
Nombre
personnes (présent
marché)
INSA étudiants et Annuaire LDAP INSA
personnels
ENGEES
étudiants
SI Scolarité Unistra
(Banner - Sungard)
ENGEES
personnels
Annuaire LDAP ENGEES
ENSAS étudiants Annuaire LDAP ENSAS
et personnels
Autres
établissements
Phase
initiale
Commentaire
début 2014.
Le SI source sera à déterminer
selon les possibilités du SIGB
choisi.
3.000
800
N
- Banner : projet en cours
O
100
N
1.500
N
500
N
Référentiel des personnes
(présent marché)
Remarques :
 Le nombre total de personnes à considérer dans la phase initiale du projet sera 70.000 ;
 Le développement de la politique de gestions des anciens étudiants pourra porter ce type de
personne au nombre de 40.000 dans les 4 ans ;
 De nouveaux partenariats pourront ultérieurement faire naître de nouvelles typologies de
personnes
5.1.2 Systèmes d'informations connectés
 Systèmes producteurs
Les systèmes d’informations producteurs de données vers le référentiel des personnes sont listés dans
le tableau suivant.
Système d’information producteur
Phase initiale
Ressources humaines Unistra (Harpège – AMUE)
O
Scolarité Unistra/ENGEES (Banner – Sungard)
O
Recherche (Graal – AMUE)
O
Annuaire OpenLDAP Unistra
O
Annuaire OpenLDAP ENGEES
N
Annuaire OpenLDAP INSA
N
Annuaire Active Directory ENSAS
N
13/24
22/03/2012
Système d’information producteur
Phase initiale
SIGB Unistra (potentiel)
N
La création des « Extérieurs Unistra » devra être effectuée directement dans le référentiel des
personnes. La gestion de ces personnes est aujourd’hui décentralisée au sein des composantes,
services et laboratoires de l’université, pour un total d’environ 300 gestionnaires. L’université
souhaite conserver ce mode de gestion de cette catégorie de personnes et ce dès la phase initiale.
Selon les capacités du produit retenu comme SIGB de l’université et les choix organisationnels qui
seront effectués dans le cadre de ce projet, la création des lecteurs externes pourra également être
effectuée directement dans le référentiel des personnes.
 Systèmes consommateurs
Les systèmes d’information consommateurs recensés sont à minima :
Système d’information consommateur
Phase initiale
O
Scolarité Unistra/ENGEES (Banner – Sungard)
O
O
O
Finances (SIFAC – AMUE)
N
Pilotage (Business Object)
N
SIGB Unistra
N
Potentiellement, plusieurs autres applications pourront être consommatrices directes du référentiel
des personnes. Elles seront interfacées au référentiel dans des phases ultérieures.
Le temps de propagation de l’information de création d’une personne est un point important. Un
nouvel arrivant (employé, étudiant ou tout autre utilisateur des services numériques de l’université)
doit bénéficier d’une entrée valide dans l’annuaire OpenLDAP Unistra moins de cinq minutes après
sa saisie dans les SI producteurs.
5.2 Référentiel « structures organisationnelles»
Le référentiel des structures sera géré de manière centralisée dans l'outil de MDM. Les données
seront saisies directement dans le référentiel des structures, puis consommées par les SI métiers.
5.2.1 Typologie des structures gérées
Le tableau suivant liste le type de structures organisationnelles à gérer, ainsi qu'une approximation de
leur nombre respectif.
Type
Nombre
Phase initiale
Composantes d'enseignement
38
O
Services centraux
35
O
14/24
22/03/2012
Type
Nombre
Collegiums
Phase initiale
9
O
Unités de recherches
80
O
Équipes de recherche
440
O
10
O
7
O
Écoles doctorales
Organes légaux
Cette liste des types de structures n'est pas exhaustive. Le niveau de granularité définitif n’étant pas
aujourd’hui fixé, des types de structures supplémentaires pourront faire leur apparition en phase de
conception détaillée du projet. Pour couvrir l'ensemble du besoin en phase initiale, l'université
extrapole donc le nombre maximum de structures à 1.000.
5.2.2 Systèmes d'informations connectés
Les systèmes d’information consommateurs recensés sont à minima :
Système d’information consommateur
Phase initiale
O
Scolarité Unistra (Banner – Sungard)
O
O
O
Finances (SIFAC – AMUE)
N
Pilotage (Business Object)
N
SIGB Unistra
N
Potentiellement, plusieurs autres applications pourront être consommatrices directes du référentiel
des personnes. Elles seront interfacées au référentiel dans des phases ultérieures.
5.3 Exigences de disponibilité
Dans ce scénario, le soumissionnaire présentera une architecture dite de « haute-disponibilité »,
c’est-à-dire tolérante à la panne d’un de ses composants logiciels, sur toutes les couches applicatives
(IHM, accès aux données, SGBD, etc.). Les impacts en termes de matériels et licences
supplémentaires seront précisés. Les composants logiques et matériels indiqués dans la grille de
réponse (cf. Annexe 8.2) doivent être décrits pour un fonctionnement sur ce principe. Si un ou
plusieurs modules de la solution ne pouvaient bénéficier d’un fonctionnement en haute-disponibilité,
le candidat le précisera explicitement.
L’architecture proposée doit être en mesure d’implémenter les éléments décrits dans ce scénario sans
impact sur les performances et l’expérience utilisateur. Elle doit être extensible aisément pour
supporter une augmentation ultérieure de la quantité de données gérées, d’utilisateurs ou de SI tierces
interfacés, mais également pour supporter des pics d’activités anticipés.
15/24
22/03/2012
6. Prestations attendues
Le présent marché sera composé :
 d’une partie forfaitaire dans laquelle le candidat fournira :
o les licences permettant une utilisation complète de l’application en réponse au besoin
spécifié dans le présent CCTP et permettant de réaliser la phase initiale spécifiée dans le
scénario de déploiement ;
o la maintenance de la solution sur une durée initiale d’un an ;
 d’une partie à bon de commande dans laquelle il proposera :
o des tranches d’achats complémentaires de licences pour les phases ultérieures du projet ;
o la prolongation de la maintenance par tranche supplémentaire d'un an (dans la limite de 3
périodes annuelles supplémentaires).
Le candidat s’engage à respecter les tarifs proposés pendant toute la durée du marché. Le montant
total du présent marché ne pourra en aucun cas atteindre 90.000 euros H.T.
6.1 Fourniture du logiciel
Le candidat retenu par le présent marché fournira le logiciel prêt à l’installation sur un support
physique.
Les licences acquises doivent autoriser l’installation d’au moins trois environnements d’exécution de
la solution :
 Production
 Pré-production
 Développement
6.2 Support et maintenance
Le candidat proposera une prestation de maintenance de la solution incluant :
 l’accès à la documentation technique et fonctionnelle de la solution. La documentation
fonctionnelle doit être disponible en langue française ;
 l’accès à un service d’assistance joignable à minima les jours ouvrés (du lundi au vendredi);
 la maintenance applicative.
Le candidat précisera les éléments suivants qui permettront d’évaluer la qualité de sa proposition :
 jours et horaires d’ouverture du service d’assistance ;
 une garantie de temps de réponse sur ouverture d’un incident ;
 une garantie de temps de résolution sur ouverture d’un incident ;
 le périmètre couvert par la maintenance applicative : préventive, corrective, évolutive, etc.
La maintenance, qui débute à la date de réception de la solution, est rémunérée par application du
montant annuel mentionné par le candidat sur la grille de réponse jointe à son offre pour chacune des
quatre années potentielles de maintenance de la solution.
16/24
22/03/2012
7. Modalités de la consultation
7.1 Contenu de l’offre
L’offre remise par le candidat sera composée de trois documents :
 Les conditions d’achat complétées et signées ;
 Un mémoire technique ;
 La grille de réponse complétée.
7.1.1 Conditions d’achat
Le candidat joindra à son dossier les conditions d’achats applicables au présent marché fournies avec
le présent CCTP, qu’il aura complétées et signées.
7.1.2 Mémoire technique
Le candidat fournira un mémoire technique présentant sa solution et son adéquation avec les besoins
exprimés dans le présent CCTP. Afin de faciliter l’analyse des offres, le candidat est invité à
respecter la trame suivante dans ce document.
7.1.2.1 Présentation de la société
Le candidat présentera sa société. Si le candidat est uniquement revendeur du produit, il présentera
également la société éditrice de la solution.
7.1.2.2 Présentation générale du produit
Le candidat présentera de manière globale le produit. Il évoquera l’historique des évolutions du
produit. Il listera les références de déploiements aboutis du produit dans la version proposée, pour
des projets similaires.
7.1.2.3 Réponse aux exigences fonctionnelles
Le candidat indiquera de manière détaillée l’adéquation de sa solution avec les exigences
fonctionnelles décrites dans le présent CCTP. Il pourra intégrer des copies d’écrans de la solution en
lien avec les fonctionnalités demandées.
7.1.2.4 Environnement technique de la solution
Le candidat présentera les technologies employées par la solution. Il détaillera les pré-requis
techniques nécessaires au déploiement de la solution. Il précisera l’adéquation technique de la
solution, en précisant les points listés dans le chapitre « 4 Exigences non-fonctionnelles et
techniques » du présent CCTP.
7.1.2.5 Scénario de déploiement
Le candidat présentera un exemple d’architecture technique et applicative de sa solution pour
répondre au scénario de déploiement proposé par l’université dans le chapitre « 5 Scénario de
déploiement ». Il détaillera les besoins en matériels et logiciels additionnels nécessaires à la mise en
place de la solution. Ces éléments seront également recensés dans la grille de réponse fournie en
17/24
22/03/2012
annexe.
7.1.2.6 Modèle de licences
Le candidat expliquera le mode de calcul du coût de licence du produit. Il détaillera les conditions
d’extensibilité du périmètre des modules (Augmentation du nombre d’enregistrement, du nombre de
SI connectés, d’utilisateurs, etc.). Les coûts seront recensés dans la grille de réponse fournie en
annexe.
7.1.2.7 Garantie et maintenance
Conformément au besoin exprimé en « 6.2 Support et maintenance », le candidat détaillera les
conditions de garanties de la solution ainsi que l’offre de support et maintenance. Le candidat
indiquera le mode de tarification de cette prestation et effectuera une proposition financière sur une
maintenance de 4 ans.
7.1.3 Grille de réponse
Le candidat joindra à son dossier technique la grille de réponse de synthèse fournie en annexe
dûment remplie.
7.2 Critères de jugement des offres
Les critères retenus pour le jugement des offres sont pondérés de la manière suivante :
Libellé
%
1 – Valeur technique de l’offre
70
2 – Coût global de la solution
30
A noter que :
 la « Valeur technique de l’offre » sera analysée sur la base :

des caractéristiques fonctionnelles de la solution (50%) ;

des caractéristiques non-fonctionnelles et techniques de la solution (25%) ;

des caractéristiques de la prestation de maintenance proposée (25%).
 Le « Coût global de la solution » évalué sera le résultat de la somme des éléments suivants :

prix d’acquisition des licences nécessaires à la réalisation de la phase initiale décrite dans
le chapitre « 5 Scénario de déploiement » du présent CCTP ;

prix d’acquisition des tranches de licences supplémentaires nécessaires à la réalisation
complète du scénario décrit dans le chapitre 5 du présent CCTP ;

coût de la maintenance sur 4 ans (considérant que l’ensemble des licences
complémentaires soit acquise 2 ans après notification du marché) ;

coût de licences estimé des logiciels non fournis par le candidat et nécessaires pour
garantir le bon fonctionnement de la solution, selon les éléments fournis dans la grille de
18/24
22/03/2012
réponse ;

coût de l’achat des matériels informatiques par l’université et de leur maintenance sur 4
ans à partir des éléments fournis par le candidat dans la grille de réponse
8. Annexes
8.1 Description du poste client standard
Poste MS Windows
Système d'exploitation
Antivirus
Logiciel de gestion de parc
Lecture de PDF
Générateur de PDF
Retouches d'image
Navigateur par défaut (et ses plugins)
Navigateur secondaire
Java
Messagerie principale
Messagerie instantanée
Compression
Lecteurs de vidéo
Suite bureautique
Windows 7
Symantec EndPoint
Symantec Altiris
Adobe Acrobat Reader
PDF Creator
Paint.net
Firefox ESR
IE
Version de java 1.6
Thunderbird 10 ESR
Jitsi
7zip
Windows Media Player, VLC, QuickTime, Itunes
MS Office 2010 (principale)
LibreOffice (secondaire)
Poste Mac
Antivirus
Suite bureautique
Navigateur par défaut
MacOS X
Symantec EndPoint
Symantec Altiris
MS Office 2011 (principale)
LibreOffice (secondaire)
Mozilla Thunderbird 10 ESR
Firefox ESR
Jitsi
Poste Linux
Windows Manager
Suite bureautique
Navigateur par défaut
Linux Ubuntu LTS
le gestionnaire standard de la distribution
Symantec Altiris
LibreOffice
Firefox ESR
Mozilla Thunderbird 10 ESR
19/24
22/03/2012
Système de virtualisation
Jitsi
VMWarePlayer
8.2 Grille de réponse
20/24
22/03/2012
Grille de réponse
Acquisition pour la phase initiale
Nom du composant
Limite de la licence
Coût H.T. (€)
Coût total
Remarque :
 Les coûts de licences seront spécifiés dans ce tableau
 La « Limite de la licence » indiquera les limites d’utilisation du produit induites par le coût
proposé
Prestation de maintenance sur les acquisitions initiales
Année
Coût H.T. (€)
1
2
3
4
21/24
22/03/2012
Remarque :
 Le candidat doit préciser dans son mémoire technique les conditions détaillées de l’offre de
support et maintenance applicative
Acquisition de licences supplémentaires
Détail de la tranche d’acquisition
Coût H.T. (€)
Prestation de maintenance sur les acquisitions de licences complémentaires
Année
Coût H.T. (€)
1
2
3
4
Remarque :
Si coût est dépendant du montant de licences complémentaires acquises, le candidat précisera le
mode de calcul dans la colonne « Coût H.T. »
22/24
22/03/2012
Composants logiciels non fournis par le candidat
Nom du composant
Version
Coût indicatif
Composants matériels estimés
Rôle
Virtuel
CPU
RAM
Espace disque
Qté.
Remarques :
 Ces informations seront utilisées pour évaluer les coûts complémentaires induits par le
déploiement de la solution
 Détail des colonnes :
23/24
22/03/2012
o Rôle : description succincte du rôle du serveur
o Virtuel : indique si le serveur peut-être virtualisé (oui/non)
o CPU : Nombre de processeurs/cores
o RAM : mémoire vive requise
o Espace disque : le candidat distinguera deux types d’espace disque :
 « système » comprenant le système d’exploitation, les applicatifs et les fichiers de
configuration
 « données » contenant les données métiers hébergées par l’application
Deux valeurs doivent donc être précisées pour les serveurs hébergeant des données.
24/24

Acquisition d`une solution de gestion de données de références

Transcription

Documents pareils

CONSULTATION : Achat d`une autolaveuse à batterie pour le stade

info document - Collège Pierre Paul Prud`hon

Epreuve CPAP - Techniques bancaires

2012 - AAPC -hammam centre nautique

professorat de sport 2014 epreuve d`admission n°3 video : 1404

Rencontre débat avec - Sciences Po Strasbourg

La nouvelle épreuve PDUC

Before the Muses : an anthology of Akkadian literature

Fiche d`inscription AS 2016

Titre professionnel secrétaire assistant