DataWarehouse. Cahier des Charges - Clauses Techniques

(1)

DataWarehouse

Cahier des Charges -

Clauses Techniques

(2)

Table des matières

1. Introduction ... 4

2. DataWarehouse ... 5

2.1 Cartographie des applications métiers du Pass et flux d’échange des données ... 5

2.2 Structure du DataWarehouse... 5

2.3 Inventaire des applications du Pass ... 5

2.4 Ecran d’encodage direct DataWarehouse ... 6

2.5 Matériel et Système d’exploitation requis ... 7

2.6 Formations ... 7

3. Système ETL ... 8

3.1 Fonctionnalités ETL - spécifications ... 8

3.2 Serveur ETL ... 9

3.3 Support ELT... 10

3.4 Qualité des données ... 10

3.5 Monitoring ... 11

4. Serveur de reporting ... 12

4.1 Fonctionnalités du Serveur de reporting... 12

4.2 Fonctionnalités d’analyse ... 14

4.3 Rapports à mettre en place –inventaire ... 14

4.4 Matériel et Système d’exploitation requis ... 15

5. Matériel et Système d’exploitation ... 16

5.1 Machine à mettre en place pour le DataWarehouse – approche requise ... 16

5.2 Contexte ... 16

6. Références ... 17

7. Gestion projet ... 18

7.1 Méthodologie ... 18

7.2 Planning ... 18

7.3 Chef de projet ... 19

7.4 Comité de Pilotage ... 19

7.5 Profils ... 19

(3)

8. Formations ... 20

9. Documentation ... 20

9.1 Manuels produits ... 20

9.2 Documentation projet ... 20

9.3 Documentation technique ... 20

10. Maintenance et support ... 21

10.1 Maintenance logicielle ... 21

10.2 Maintenance matérielle ... 21

10.3 Support ... 21

(4)

1. Introduction

Le Pass désire se doter d’outils de décision et de reporting rapides et précis permettant de piloter les activités de façon optimale et sans délais.

La volonté est également de disposer d’une plateforme de consolidation/regroupement des données, plateforme qui permettra d’intégrer plus aisément les applications actuelles du Pass et de simplifier la mise en place de nouvelles applications.

Pour ce faire, le Pass désire mettre en place une infrastructure informatique de « Business Intelligence ».

Cette infrastructure se composera des éléments suivants : 1. DataWarehouse

Ce DataWarehouse prendra la forme d’une base de données relationnelle.

Son rôle sera de consolider en un point central les données fonctionnelles de l’entreprise, de manière homogène (formats identiques pour des données de même type), exhaustive (consolidation de toutes les applications fonctionnelles du Pass) et qualitative (vérification de la qualité des données stockées).

Les éléments techniques liés au DataWarehouse sont détaillés au chapitre 2.

2. Système « ETL » (Extract-Transform-Load)

En amont du DataWarehouse, le système ETL permettra de :

 Extraire (Extract) les données des différentes sources de données fonctionnelles du Pass

 Transformer (Transform) ces données pour atteindre les règles d’homogénéité et de qualité voulues

 Charger (Load) ces données dans le DataWarehouse

Les éléments techniques liés au système ETL sont détaillés au chapitre 3.

3. Serveur de reporting

En aval du DataWarehouse, un serveur de reporting permettra de créer et de publier des rapports de façon simple et accessibles globalement pour l’ensemble des

utilisateurs du Pass.

Les éléments techniques liés au serveur de reporting ainsi que la description des rapports existants qui devront être repris par le soumissionnaire sont détaillés au chapitre 4.

En plus d’être responsable de l’installation, de la configuration et de la maintenance de la solution, le soumissionnaire aura la responsabilité de fournir une solution « clés en main » ce qui signifie entre autres que :

 le DataWarehouse sera connecté aux applications métiers du Pass et chargé avec les données de ces applications

 les rapports existants du Pass seront repris dans le nouveau serveur de reporting L’inventaire des applications métiers, des rapports existants ainsi que les autres éléments liés à la migration vers la nouvelle solution sont décrits tout au long du présent cahier des

charges.

(5)

2. DataWarehouse

2.1 Cartographie des applications métiers du Pass et flux d’échange des données

L’Annexe 1 reprend les principales applications du Pass et le flux global d’échange de données à mettre en œuvre via le DataWarehouse.

L’Annexe 2 (chapitre 2) détaille ce schéma et spécifie :

 Quels rôles ont les applications sur les données : « source principale», « source secondaire » ou « utilisatrice »

 Les raisons qui ont menés à ces choix

 Le sens des connexions à établir vers le DataWarehouse (uni/bi-directionnel)

 Les spécificités des données stockées

 Les spécificités et limites techniques éventuelles des bases de données liées (ex : la base de données d’IREC ne peut être accédée qu’en lecture, pas en écriture)

2.2 Structure du DataWarehouse

L’analyse fournie en annexe (Annexe 2, chapitres 3 à 5) propose un modèle de données pour le cœur du DataWarehouse.

Ce modèle supporte les flux d’échanges de données décrits ci-dessus.

Le soumissionnaire est libre de proposer sa propre structure de données à condition bien entendu qu’elle réponde aux exigences énoncées dans l’analyse et dans le présent cahier des charges.

2.3 Inventaire des applications du Pass

Nom Description sommaire Organisation

des données Utilisation des données

1 Irec

Outil de réservation, de gestion de ressources, de salle et de planning

voir schéma donné en

annexe 3

Voir annexe 2

SugarCRM : compléter la base client et générer un historique

Tous les rapports repris dans

l'inventaire des rapports (chapitre 4) 2 Expert M Outil de comptabilité

annexe 3

Voir annexe 2

3 SugarCRM

Outil de gestion de contact et de marketing, de prospection

annexe 3

Voir annexe 2

4 Site Web

Outil de communication officiel en ligne incluant des formulaires de réservations pour les différents publics du PASS:

- événement entreprise - famille (individuel)

annexe 3

(6)

- Ecole - Groupe

5 Desk inscription

Outil d'inscription aux activités du PASS + prises d'informations sur les clients.

annexe 3 et extraction écran doc n°1

Rapports

6

Enquête de satisfactio

n

Document papier destiné à collecter les

coordonnées et les appréciations des clients.

Il en existe 3 : - marque page public individuel

- marque page école - marque page

événements entreprise (B2B)

Les données sont ensuite encodés dans une base de données Access.

Voir : doc n°2, 3 et 4 et

schéma donné en

annexe 3

Rapports de satisfactions Rapport d'activité

7 Caméra rapide

Application informatique récoltant : Nom, Prénon et adresse mail afin d'envoyer un film

annexe 3

8 Taçabilité Ces applications n'ont pas encore été développées mais l'annexe 4 permet de comprendre leur fonctionnement futur. L'entreprise devra concevoir le datawarehouse en tenant compte de ces applications

9 Abonneme nts 10

Logiciel Boutique et Horeca (Chablis)

Logiciel de caisses

annexe 3

Rapports statistiques des chiffres d'affaire

En plus des données applicatives, diverses sources d’informations sont également disponibles sous forme de fichiers plats (listes Excel ou autres).

2.4 Ecran d’encodage direct DataWarehouse

Certains encodages se font actuellement via des fichiers disparates qui doivent ensuite être consolidés.

Afin d’optimiser et de centraliser ces encodages, le soumissionnaire développera un écran d’encodage intuitif et centralisé permettant d’enregistrer directement dans les tables du DataWarehouse des événements particuliers (non gérés par Irec).

Cet écran contiendra les champs d’encodage suivants :

 Type d'événement

 Date

 Nom de l’événement

 Effectif

 Catégorie

 Distinction individuelle/groupe

(7)

 Provenance géographique (pays)

2.5 Matériel et Système d’exploitation requis

Cf. chapitre 5.

2.6 Formations

Cf. chapitre 8.

(8)

3. Système ETL

3.1 Fonctionnalités ETL - spécifications

Extract

Le système ETL devra permettre d’extraire des données provenant des sources suivantes :

 Solutions métiers

L’inventaire des applications métiers du Pass est repris aux paragraphes 2.1 et 2.3. Le soumissionnaire spécifiera les applications métiers qui sont supportées en natif par le système ETL proposé.

 Bases de données relationnelles

Les bases de données suivantes sont utilisées par le Pass : o Microsoft SQL Server

o Microsoft Access o PostgreSQL o MySQL

o Oracle Express Edition 10g/11g

Le système ETL proposé devra disposer de connecteurs vers ces différentes bases de données.

 Fichiers plats

Divers types de fichiers plats sont utilisés par le Pass et devront pouvoir être intégrés au DataWarehouse.

Le système ETL devra donc disposer des connecteurs pour les fichiers suivants : o Microsoft Excel

o Fichiers textes délimités o XML

Transform

Une fois les données extraites, le système ETL permettra de les transformer grâce à des outils simples et flexibles.

Il devra entre autres être possible de :

 Faire correspondre les champs des tables sources et destinations (mapping entre les sources et le DataWarehouse)

 Filtrer des enregistrements sur base de requêtes SQL

 Filtrer des colonnes

 Joindre (join SQL) les informations venant de tables différentes vers une même destination

 Faire appel aux procédures stockées (« stored procedures ») des bases de données connectées

 Transformer les types de champ entre entrée et sortie (ex : Integer => String)

 Appliquer des règles de formatage entre les données d’entrée et de sortie.

Entre autres :

o format standardisé de date, o de numéro de téléphone, o de numéro de TVA,

(9)

o forcer l’encodage en majuscule du nom de famille

 Permettre l’adjonction de code/script permettant d’ajouter des fonctions développées sur mesure. Le soumissionnaire décrira le langage utilisé et les fonctionnalités supportées.

Load

Les données extraites et transformées seront ensuite chargées dans le DataWarehouse.

La structure du DataWarehouse est décrite au chapitre 2. Le système ETL devra supporter cette structure et les fonctionnalités décrites.

Informations à mentionner dans l’offre

En plus de répondre aux demandes exprimées ci-dessus, le soumissionnaire mentionnera dans son offre :

 Les fonctionnalités supplémentaires éventuelles supportées par sa solution.

 Quels connecteurs/méthodes/moyens techniques il propose concrètement pour extraire, transformer et charger les données et ce pour chaque application du Pass répertoriée dans le cahier des charges

3.2 Serveur ETL

Matériel et Système d’exploitation requis Cf. chapitre 5.

Fréquence de mise à jour des données

Le système ETL devra permettre de créer des routines (jobs) automatiques permettant la mise à jour des données (séquences complètes ou partielles de Extract-Transform-Load) au minimum toutes les 24 heures.

Le soumissionnaire décrira comment les routines de mises à jour automatiques sont créées/gérées. Si elles peuvent se faire avec une fréquence supérieure au minimum demandé, il le spécifiera également.

Gestion

La gestion des fonctionnalités ETL devra se faire à travers un outil d’administration graphique simple et intuitif.

Les scénarios que le soumissionnaire aura développés pour le Pass pourront être visualisés et éventuellement modifiés par le(s) administrateur(s) du Pass. Ceux-ci

pourront également créer de nouveaux scénarios pour répondre à de nouveaux besoins.

Le système ne peut donc en aucun cas être une « boîte noire » mais doit au contraire être ouvert.

(10)

3.3 Support ELT

En plus des fonctionnalités ETL de base, le système proposé devra également être capable de supporter les fonctionnalités ELT éventuellement disponibles sur les bases de données concernées.

En d’autres termes : si une base de données utilisée par le Pass peut être utilisée en mode ELT (ex : PostgreSQL), le système proposé ne doit pas bloquer l’utilisation de cette fonctionnalité.

3.4 Qualité des données

Le système ETL devra permettre de contrôler la qualité des données stockées dans le DataWarehouse et de veiller au maintien de cette qualité.

Contrôle des données sources

Le système devra disposer d’un outil permettant de juger de la qualité des données sources avant leur intégration dans le DataWarehouse.

Cet outil de contrôle de qualité doit permettre de tirer des statistiques sur les fichiers sources, selon des règles fixes ou configurables (ex : détecter la présence dans un fichier Excel d’IDs manquants ou doubles, alors que l’ID est obligatoire et unique une fois intégré dans la base de données DataWarehouse).

Contrôle et actions en cours de routine

Durant la routine ETL, le système doit être capable de détecter des problèmes de qualité éventuels et d’agir en conséquence, notamment au niveau :

 Doublons

L’algorithme de détection des doublons doit être flexible et intelligent : o Prise en compte de combinaisons de champs configurables (nom,

prénom, numéro de téléphone, …)

o Prise en compte de correspondances proches (« like ») et pas uniquement de correspondances exactes (ex : dupond<>dupont) Les doublons détectés doivent pouvoir être gérés suivant des règles configurables.

En cas de conflits (informations différentes pour un même champ), les actions suivantes peuvent être prises :

o Action automatique : le système concatène (merge) les doublons suivant une règle établie sans intervention humaine

o Action manuelle : le système transmet la liste des doublons à un utilisateur qui décide quelles informations sont à conserver/écraser

 Incohérence de types de données

Exemple : import d’une valeur décimale dans un champ entier

 Incohérence de format

Exemple : import d’un mauvais format de date

 Incohérence de valeurs

Exemple : import dans un champ String d’une valeur « A » alors que les seules valeurs supportées par l’application sous-jacente sont « B » ou « C ».

(11)

Contrôles et actions a posteriori

Il doit également être possible de « sonder » ponctuellement le DataWarehouse pour vérifier la qualité des données et prendre les actions nécessaires.

Les algorithmes de contrôles et d’actions décrits ci-dessus doivent donc également être disponibles dans le cadre de contrôles ponctuels.

3.5 Monitoring

Le système doit pouvoir mentionner une erreur de traitement de manière automatique.

Il s’agit entre autres :

 de blocages système

 d’erreurs dans l’exécution des routines ETL

 de détection d’enregistrements non transférés

 de détection de doublons

Ces erreurs doivent pouvoir être transmises au minimum :

 par email vers le(s) administrateur(s) système

 via trappes SNMP vers un système de monitoring informatique (Nagios ou semblable)

 vers le système de gestion de parc informatique du Pass (solution GLPI)

3.6 Formations

Cf. chapitre 8.

(12)

4. Serveur de reporting

4.1 Fonctionnalités du Serveur de reporting

Fonctionnement

Le serveur de reporting pourra fonctionner :

 en environnement isolé (fonctionnement « stand-alone »)

 ou être intégré à d’autres applications, ce qui permettait d’afficher des rapports à l’intérieur d’applications tiers (fonctionnement « embedded »)

Interface pour les utilisateurs du système

Les utilisateurs standards (qui afficheront les rapports en lecture sans les créer/gérer) disposeront au minimum des fonctionnalités suivantes :

 tous les rapports disponibles seront accessibles à travers un portail Web interne central (accessible au minimum via Mozilla Firefox, MS Internet Explorer et Google Chrome)

 le portail sera sécurisé et ne donnera accès aux rapports qu’après authentification de l’utilisateur

 l’authentification pourra également se baser sur des serveurs d’authentification externes (support minimum de OpenLDAP et MS Active Directory ; si d’autres serveurs ou standards sont supportés, veuillez les préciser)

 les ressources (rapports et autres données propres au serveur) auxquelles l’utilisateur aura accès seront définies par le rôle qui lui aura été attribué (cf.

point « Roles et utilisateurs » ci-dessous)

 le système proposé disposera d’une interface de consultation des rapports intuitive et efficace permettant entre autres de :

o visualiser les rapports par catégorie

o rechercher un rapport particulier sur base de mots-clés o trier les rapports selon leurs propriétés principales o filtrer les rapports

 Une fois un rapport sélectionné, l’utilisateur aura la possibilité de lancer son affichage. Le rapport sera alors exécuté et affiché au format défini par l’administrateur du système (cf. point « Interface pour les administrateurs du système »).

 En option, l’utilisateur devrait avoir la possibilité de définir lui-même le format d’affichage du rapport, ce qui rendra plus flexible l’utilisation de la solution.

Le soumissionnaire précisera si cette option est incluse en standard dans son offre. Si ce n’est pas le cas, il précisera alors les fonctions, le prix et les conditions techniques éventuelles liées à l’ajout de cette fonctionnalité.

Interface pour les administrateurs du système

 Les fonctionnalités d’administration seront accessibles à travers un portail Web interne central (accessible au minimum via Mozilla Firefox, MS Internet Explorer et Google Chrome).

Pour des raisons de standardisation, ce portail devrait idéalement être le même que le portail destiné aux utilisateurs.

(13)

 le portail sera sécurisé et ne sera accessible qu’après authentification de l’administrateur

 les administrateurs du système pourront réaliser 2 types de fonctions : o Gestion

Le gestionnaire pourra gérer les utilisateurs et rôles du système, gérer les droits d’accès des utilisateurs aux ressources et charger/publier les rapports sur le serveur. Il pourra également spécifier le mode d’affichage des rapports.

o Design

Le « designer » définira les rapports (forme et contenu)

 les administrateurs ne devront pas avoir de compétences informatiques particulières pour gérer le système.

Outil de création des rapports

La solution proposée doit disposer d’un outil graphique intuitif permettant de créer des rapports dynamiques contenant :

 des variables,

 des fonctionnalités de filtre et

 des fonctionnalités de tri Ces rapports seront créés sur base de :

 librairies d’objets graphiques préexistants

 requêtes de données faites en direct sur le DataWarehouse et pourront être testés/visualisés (WYSIWYG) avant leur publication.

Formats d’affichage des rapports

Les formats d’affichage minimaux suivants doivent être supportés :

 affichage direct à l’écran (dans une fenêtre permettant au minimum de se déplacer/zoomer dans le rapport et de l’imprimer)

 sauvegarde du rapport sous forme de fichier : o PDF

o HTML o XML o CSV o EXCEL

 impression papier

Génération directe ou différée des rapports

Le système doit permettre de générer des rapports qui seront soit :

 affichés directement

 programmés et envoyé par email à un ou plusieurs destinataires prédéfinis. La fréquence de l’envoi doit être configurable

(14)

Rôles et utilisateurs

 Comme précisé ci-dessus, le système doit permettre de gérer des droits d’accès différents par type d’utilisateurs (utilisateurs classiques et administrateurs du système)

 Le système doit permettre de créer un minimum de 100 utilisateurs classiques

 Le système doit permettre de créer un minimum de 10 administrateurs Interfaces

Le système doit être ouvert :

 Il doit s’intégrer totalement à la solution de DataWarehouse proposée par le soumissionnaire

 Il doit fournir des interfaces de type « Web Services » permettant l’échange d’informations avec des applications tiers

 Les données des rapports (requêtes faites sur le DataWarehouse) doivent pouvoir être exportées dans un fichier Excel

4.2 Fonctionnalités d’analyse

Le soumissionnaire précisera si la solution proposée offre également des fonctionnalités avancées de traitement analytique via l’utilisation d’un serveur OLAP (ou solution équivalente).

Il est important de souligner que ces fonctions ne sont pas, à l’heure actuelle, nécessaires au Pass. Ces fonctions, si elles étaient proposées, ne seraient donc en tout état de cause pas prises en compte dans l’évaluation technique de la solution.

4.3 Rapports à mettre en place – inventaire

En plus de la mise en place du serveur de reporting, le soumissionnaire aura la responsabilité de créer et de déployer les rapports décrits ci-dessous.

Nom Description sommaire

Présentation des données (voir annexe 6 )

Données sources

1 Comparatif Comparatif des réservations entre année n, n-

1, n-2 (voir depuis l'ouverture) Rapport 1 Irec

2 Répartition

Répartition calendaire des prises de réservation pour un type de public des années passées (pourrait remonter à l'ouverture) pour une période de l'année.

Rapport 2 Irec

3

Fréquentatio n

fiche mensuelles, trimestrielles et annuelle Rapport 3.a

Irec + écran d'encodage direct dans le

DataWarehouse (*1)

4 OTW Rapport 3.b

Etabli sur base des infos de la fiche mensuelle 5 comparatif mensuel, trimestriel et annuel des

fréquentations entre année (pourrait Rapport 3.c Etabli sur base de l'historique des fiches

(15)

remonter à l'ouverture) 6

Statistiques

de fréquentations annuelles de 2002 – 2012

(année en cours) Rapport 4.a Irec

7

de chiffre d'affaire billetterie annuel de 2002 – 2012 (année en cours)

Existe aussi pour le chiffre d'affaire horeca et boutique

Rapport 4.b Irec

Irec + Logiciel Chablis pour l'horeca et la boutique + fichier Excel pour l'historique avant Chablis

9

pour période précise (été)

Fréquentation et chiffre d'affaire billetterie de 2002 – 2012 (année en cours)

Rapport 4.c Même sources que le point précédent

10

pour période précise (été)

de chiffre d'affaire boutique (idem pour horeca )de 2002 – 2012 (année en cours)

Rapport 4.d Même sources que le point précédent 11 Photographie

des publics Rapport 5 Irec + fiches

mensuelles

12 Planning Animation Rapport 7.a Irec (+ macro Excel)

13 occupation des salles Rapport 7.b Irec

14 Etat résa

Rapport d'information transmis de manière hebdomadaire à l'horeca pour évaluer les quantité de nourriture à prévoir.

Rapport 8 Irec

*1 Voir paragraphe 2.4

Les rapports produits par le soumissionnaire devront avoir un niveau de qualité au moins équivalent à ceux présentés en annexe.

Le soumissionnaire veillera également au transfert des compétences vers les équipes internes du Pass.

4.4 Matériel et Système d’exploitation requis

Cf. chapitre 5.

4.5 Formations

Cf. chapitre 8.

(16)

5. Matériel et Système d’exploitation

5.1 Machine à mettre en place pour le DataWarehouse – approche requise

Le Pass travaille dans une infrastructure à 80 % Opensource pour des raisons d'optimisation des ressources.

Le choix stratégique choisi est de virtualiser un maximum de serveurs et de dupliquer les services derrière un loadbalancer.

Afin de pouvoir répondre au mieux au cahier de charge, le soumissionnaire aura le choix de travailler en serveur physique ou virtuel.

Pour la machine physique :

Le soumissionnaire devra présenter une description détaillée qui supportera le Datawarehouse et devra rentrer dans les normes Green IT (critère de sélection).

Le Pass se réserve le droit d'acheter la machine physique sur base du descriptif proposé.

Toutefois, les licences externes à la solution (licence de système d'exploitation) devront être prises en charge par le prestataire et le coût devra figurer dans le détail de l'offre.

Pour le choix de machine virtuelle, celle-ci devra fonctionner dans un environnement optimisé.

Exemple : un Windows 2008 avec 16 go de RAM n'est pas envisageable.

De plus, toutes les licences externes à la solution Datawarehouse devront être prises en compte par le prestataire dans l'ensemble de la réponse à l'offre et le coût devra figurer dans le détail de l'offre.

Les données avec lesquelles le Datawarehouse devra travailler se trouveront dans une infrastructure Cluster Postgresql 8.4 ou plus derrière un loadbalancer.

Des mesures moyennes des ressources et charges de l'ensemble de la solution pourraient nous aider à faire notre choix.

Un exemple d’atout favorable pour la décision :

 Machine virtuelle

 OS : Linux (Debian si possible) CPU : Max 6 Coeurs

RAM : Max 4G à 6 G

5.2 Contexte

Les schémas fournis à l’Annexe 5 résument le fonctionnement informatique/réseau du Pass.

(17)

6. Références

Il est demandé au soumissionnaire de produire au minimum 3 références démontrant ses compétences et son expérience dans la mise en place de solutions de « Business Intelligence ».

Ces références devront :

 Reprendre l’ensemble des solutions techniques décrites dans le présent cahier des charges

 Être déployées dans un environnement de production complet depuis plus de 6 mois et moins de 5 ans

 Être validées par des certificats de bonne exécution émis par les maîtres d’ouvrage Le soumissionnaire fournira pour chaque référence une fiche détaillant :

 Le contexte fonctionnel (raisons du changement) et technique (infrastructure en place)

 Les solutions techniques déployées (technologies et produits)

 La validation du maître d’ouvrage (signature)

 Les coordonnées d’une personne de contact (maître d’ouvrage) qui pourra être contactée par nos soins

(18)

7. Gestion projet

7.1 Méthodologie

Le soumissionnaire proposera une méthodologie de gestion projet itérative permettant le contrôle et la validation à différents moments clés du projet.

La méthodologie suivra le modèle du « cycle en V » et reprendra au minimum les étapes suivantes :

 Analyse des besoins

 Spécifications fonctionnelles et techniques

 Recettes partielles (par lots)

 Recette globale avant la mise en service opérationnelle

 Recette définitive après la mise en service opérationnelle

Pour chacune de ces étapes, le soumissionnaire prévoira dans son offre le temps nécessaire pour (e.a.) :

 prendre de connaissance du contexte fonctionnel et technique du Pass

 assister aux réunions internes

 documenter le projet (ex : cahier de spécifications fonctionnelles, PV de recette,

…)

En ce qui concerne les livraisons et recettes, le soumissionnaire prévoira :

 des livraisons partielles de ses solutions (livraisons en lots) ; chaque livraison donnera lieu à une recette partielle.

Il appartient au soumissionnaire de proposer le nombre de lots qui lui semble le plus approprié en fonction de l’environnement du Pass.

Un minimum de 2 lots est cependant requis : o 1^er lot : DataWarehouse et système ETL o 2^ème lot : serveur de Reporting

 une recette globale avant la mise en service opérationnelle.

Si cette recette est validée, la solution globale sera alors déployée dans un environnement pilote.

 une recette définitive

Celle-ci aura lieu au minimum 2 mois après la mise en service opérationnelle. Elle marquera l’acceptation définitive du projet.

7.2 Planning

La durée du projet, du lancement à la recette globale (cf. le paragraphe ci-dessus pour la description des étapes) ne pourra dépasser 4 mois calendrier.

Le soumissionnaire précisera dans son offre :

 le planning proposé

 la méthodologie utilisée

 le détail des tâches

(19)

7.3 Chef de projet

Le soumissionnaire prévoira un chef de projet ayant pour rôle la planification et la gestion de la mise en place du système.

Il veillera entre autres :

 à la détermination des étapes importantes et au planning du projet

 à la gestion journalière du projet

 au contrôle de la qualité et la concordance avec les spécifications et procédures convenues

 à l’élaboration des rapports sur l’évolution du projet

 à prendre les mesures nécessaires en cas de modification des paramètres projet

 à la gestion et au contrôle des livraisons

 à la préparation, au planning et à la coordination de l’installation

 à l’organisation d’une réunion de démarrage avec toutes les parties concernées

 aux phases de tests et d’acceptations (recettes)

 au respect des procédures

 à la coordination et le contrôle des éventuelles tierces parties.

Il est le point de contact principal entre le Pass et le maître d’œuvre.

7.4 Comité de Pilotage

Un Comité de Pilotage se tiendra 1 fois par mois et rassemblera les décideurs principaux des services concernés par la solution. Le maître d’œuvre y sera représenté par son chef de projet.

7.5 Profils

Le soumissionnaire fournira dans son offre les CV détaillés de toutes les personnes qui feront partie de l’équipe projet.

(20)

8. Formations

Le soumissionnaire prévoira des formations pour les différentes solutions proposées dans son offre et décrites aux chapitres 2, 3 et 4 du présent cahier des charges.

DataWarehouse et Système ETL

 Formation des administrateurs du système

Formation permettant aux administrateurs de prendre en main les solutions proposées, de les configurer et de développer de nouveaux scénarios ETL

Serveur de Reporting

 Formation des utilisateurs du système

Formation destinée aux utilisateurs du système, sous la forme « train-the-trainer » (formation multiplicative). L’objectif est de former les utilisateurs à l’utilisation du portail Web permettant l’accès et l’affichage des rapports

 Formation des administrateurs du système (gestionnaires) Formation sur les fonctionnalités de gestion du système

 Formation des administrateurs du système (designers des rapports) Formation sur l’outil de création des rapports

En plus de ces formations, le soumissionnaire veillera à former :

 l’équipe informatique du Pass sur tous les aspects informatiques des solutions mises en place.

 le Pass sur le travail de paramétrage qui aura été réalisé par ses soins (ex : création de rapports, de scénarios ETL, …).

Les formations seront toujours accompagnées d’un support de cours en français.

9. Documentation 9.1 Manuels produits

Chaque solution sera livrée avec :

 un mode d’emploi utilisateur en français

 un manuel d’installation et de configuration en français ou en anglais.

Ces documents contiendront toutes les informations et schémas permettant l’installation, la configuration et la gestion des éléments déployés.

9.2 Documentation projet

Comme spécifié au chapitre « Gestion projet », le maître d’œuvre devra documenter les livrables associés à chaque étape du projet.

9.3 Documentation technique

Le maître d’œuvre détaillera l’architecture informatique mise en place (schémas synthétiques et descriptions techniques).

(21)

10. Maintenance et support

10.1 Maintenance logicielle

Le soumissionnaire proposera dans son offre une maintenance logicielle couvrant :

 La mise à disposition pro-active des correctifs

 Le déploiement préventif de ces correctifs sur l’infrastructure du Pass (maintenance préventive)

 La mise à disposition des mises à jour fonctionnelles mineures

 Le déploiement de ces mises à jour fonctionnelles sur l’infrastructure du Pass (rem : tout déploiement de mise à jour devra d’abord être validé par le Pass)

 L’accès au support technique fourni par le maître d’œuvre et par les éditeurs de logiciel (cf. paragraphe « Support » ci-dessous)

10.2 Maintenance matérielle

Si le soumissionnaire propose du matériel, il veillera à proposer un contrat de maintenance pour ce matériel. Le coût de remplacement du matériel en panne et les prestations liées seront totalement couvertes par ce contrat.

10.3 Support

Le soumissionnaire proposera dans son offre un contrat de support couvrant :

 La gestion des incidents

 Les demandes de support technique et fonctionnel

 La prise en charge de la communication avec les éditeurs de logiciel Le support sera accessible 5 jours sur 7 (jours ouvrables) de 9h à 17h, en français.

Le soumissionnaire réalisera lui-même le support (il ne pourra pas contracter une autre société pour le faire). En cas de bugs ou d’escalade, il devra pouvoir faire appel au support direct de l’éditeur du logiciel.

En cas d’incident, le soumissionnaire devra réagir :

 Endéans les 4 heures ouvrables en cas d’incident critique (incident ayant un impact sur la qualité du service rendu aux clients du Pass)

 Endéans les 2 jours ouvrables en cas d’incident majeur (incident occasionnant un dysfonctionnement important en interne mais sans influence sur les clients du Pass)

 Endéans les 5 jours ouvrables en cas d’incident mineur (incident occasionnant un dysfonctionnement limité)

Le soumissionnaire décrira son offre de service et joindra la copie d’un contrat de service à son offre.