CDC - Di - Engie V1

– Mise en place d’une solution de traitement des demandes d’interventions techniques et services -
MISE EN PLACE D’UNE SOLUTION DE GESTION DES

DEMANDES D’INTERVENTIONS TECHNIQUES ET
SERVICES SUR LE PATRIMOINE DES CSP ENERGIE ET
BELGIQUE EN MODE SaaS
CAHIER DES CHARGES
2016
Version Expressions Besoins Utilisateurs
Cahier des charges 1 / 49

CAHIER DES CHARGES ...................................................................................................................................... 1
1. CONTEXTE ................................................................................................................................................ 5
1.1. ENJEUX ET OBJECTIFS ................................................................................................................................... 5

1.2. PERIMETRE ................................................................................................................................................ 6
1.3. NOMBRE ET PROFILS DES UTILISATEURS ........................................................................................................... 6
1.4. SOLUTIONS RECHERCHEES ............................................................................................................................ 7
1.4.1. LOT 1 : SOLUTION OPERATIONNELLE DE GESTION IMMOBILIERE ................................ ERREUR ! SIGNET NON DEFINI.
1.4.2. LOT 2 : SYNTHESES DYNAMIQUES DE LA DONNEE IMMOBILIERE ................................ ERREUR ! SIGNET NON DEFINI.
1.5. PLANNING PREVISIONNEL DE LA CONSULTATION ET DE MISE EN PLACE DES SOLUTIONS .............................................. 7
2. ATTENTES FONCTIONNELLES .................................................................................................................... 8
2.1. REPRESENTATION DU TABLEAU DE BORD DU PATRIMOINE (LOT1) .................................. ERREUR ! SIGNET NON DEFINI.
2.2. REPRESENTATION DE LA CARTE D’IDENTITE DU SITE (LOT1) ........................................... ERREUR ! SIGNET NON DEFINI.
2.3. TABLEAUX DE BORD – REPORTING (LOT1) ................................................................. ERREUR ! SIGNET NON DEFINI.
2.4. INTERACTION LOT 1 ET 2 ....................................................................................... ERREUR ! SIGNET NON DEFINI.
3. ATTENTES TECHNIQUES ........................................................................................................................... 9
3.1. ACCES A LA SOLUTION.................................................................................................................................. 9

3.2. ERGONOMIE ET INTUITIVITE .......................................................................................................................... 9
3.3. GESTION DES HABILITATIONS....................................................................................................................... 10
3.4. RECHERCHE / CONSULTATION DES DONNEES .................................................................................................. 11
3.5. EXPORT DES DONNEES DE LA BASE ................................................................................................................ 11
3.6. HISTORISATION DES DONNEES ..................................................................................................................... 11
3.7. EDITIONS ................................................................................................................................................ 12
3.8. AIDE EN LIGNE.......................................................................................................................................... 12
3.9. CAPACITE D’OUVERTURE ET FACILITE D’INTEGRATION ....................................................................................... 12
3.10. MOBILITE................................................................................................................................................ 13
3.11. TRANSFERT, INITIALISATION DES DONNEES ET EXPORTS. .................................................................................... 13
3.12. MAINTENANCE, INCIDENTS ET ENVIRONNEMENTS ........................................................................................... 13
4. PHASE PROJET, LIVRAISON ET RECETTE .................................................................................................. 14
4.1. GROUPE DE PROJET ENGIE ........................................................................................................................ 14

4.2. COMITE DE PILOTAGE ................................................................................................................................ 14
4.2.1. COMITE DE PILOTAGE PHASE PROJET......................................................................................................... 14
4.3. ETAT ET QUALITE DE LA DONNEE AU DEMARRAGE DE LA MISSION ........................................................................ 15
4.4. ELABORATION ET VALIDATION DU DOSSIER DE SPECIFICATIONS FONCTIONNELLES ................................................... 15
4.5. INTERFACES ............................................................................................................................................. 16
4.6. MISE EN ŒUVRE DU PROJET ........................................................................................................................ 16
4.7. PROCESSUS DE RECETTE ............................................................................................................................. 17
4.8. FORMATION DES UTILISATEURS – ADMINISTRATEURS ....................................................................................... 17
5. PHASE EXPLOITATION – RUN ................................................................................................................. 18
5.1.1. COMITE DE PILOTAGE PHASE RUN ........................................................................................................... 18

5.1.2. REPORTING ......................................................................................................................................... 18
ANNEXES : ...................................................................................................................................................... 20
ANNEXE 1 : LOT 1 SYNTHESE DES DONNEES OPERATIONNELLES A INTEGRER ................................................. 21

1.1. COMPOSITION DU REFERENTIEL IMMOBILIER .................................................................................................. 21

1.1.1. GENERALITES.................................................................................................. ERREUR ! SIGNET NON DEFINI.
1.1.2. CARACTERISTIQUES ELEMENTAIRES A GERER DANS LA BASE DE DONNEES ..................... ERREUR ! SIGNET NON DEFINI.
1.1.2.1. CARACTERISTIQUES/DONNEES POUR UN SITE :....................................................... ERREUR ! SIGNET NON DEFINI.
1.1.2.2. CARACTERISTIQUES/DONNEES POUR UN TERRAIN : ................................................. ERREUR ! SIGNET NON DEFINI.
1.1.2.3. CARACTERISTIQUES/DONNEES POUR UN BATIMENT : .............................................. ERREUR ! SIGNET NON DEFINI.
1.1.2.4. CARACTERISTIQUES/DONNEES POUR UN ETAGE : ................................................... ERREUR ! SIGNET NON DEFINI.
1.1.2.5. GESTION DES SURFACES .................................................................................... ERREUR ! SIGNET NON DEFINI.
1.2. REFERENTIEL DES TIERS ET ORGANISATIONS .................................................................................................... 28
1.2.1. GENERALITES....................................................................................................................................... 28
1.2.2. CARACTERISTIQUES ELEMENTAIRES A GERER DANS LA BASE DE DONNEES ..................... ERREUR ! SIGNET NON DEFINI.
1.3. GESTION DES BAUX - CONVENTIONS ........................................................................ ERREUR ! SIGNET NON DEFINI.
1.4. GESTION D’ALERTES ............................................................................................. ERREUR ! SIGNET NON DEFINI.
1.5. GESTION DES DOCUMENTS (GED) .......................................................................... ERREUR ! SIGNET NON DEFINI.
1.6. OPTION : GESTION DES ENERGIES ET FLUIDES ............................................................ ERREUR ! SIGNET NON DEFINI.
1.6.1. OPTION 1 : TRAITEMENT DE FICHIERS PLATS.......................................................... ERREUR ! SIGNET NON DEFINI.
1.6.2. BESOINS SPECIFIQUES AU CSP I&L FRANCE : ........................................................ ERREUR ! SIGNET NON DEFINI.
1.6.3. OPTION 2 : INFRASTRUCTURE DE COLLECTE .......................................................... ERREUR ! SIGNET NON DEFINI.
1.7. OPTION : GESTION DE L’OCCUPATION ...................................................................... ERREUR ! SIGNET NON DEFINI.
1.7.1. OBJECTIF ....................................................................................................... ERREUR ! SIGNET NON DEFINI.
1.7.2. FONCTIONNALITES ATTENDUES........................................................................... ERREUR ! SIGNET NON DEFINI.
1.7.3. EXEMPLE DE REPORTING (ANNEXE 3)................................................................... ERREUR ! SIGNET NON DEFINI.
1.8. OPTION : GESTION TECHNIQUE (PLAN PLURIANNUEL DE TRAVAUX NOTAMMENT) ............. ERREUR ! SIGNET NON DEFINI.
1.9. OPTION : DATA ROOM IMMOBILIERE ...................................................................... ERREUR ! SIGNET NON DEFINI.
1.9.1. CONTEXTE & ENJEUX :...................................................................................... ERREUR ! SIGNET NON DEFINI.
1.9.2. OBJECTIFS : .................................................................................................... ERREUR ! SIGNET NON DEFINI.
1.9.3. AVANTAGES ATTENDUS DE LA SOLUTION : ................................................................................................. 29
1.9.4. EXIGENCES FONCTIONNELLES ET NON FONCTIONNELLES SOUHAITEES (LISTE NON EXHAUSTIVE) : ........................... 29
1.10. REPORTINGS ....................................................................................................... ERREUR ! SIGNET NON DEFINI.
1.11. LOT 2 : SYNTHESES DES ANALYSES DYNAMIQUES DE LA DONNEE IMMOBILIERE ................ ERREUR ! SIGNET NON DEFINI.
1.11.1. INFORMATIONS A TRAITER ET SOURCES ................................................................ ERREUR ! SIGNET NON DEFINI.
1.11.2. GESTION DE DONNEES BUDGETAIRES/FINANCIERES ET INDICATEURS ATTENDUS ............ ERREUR ! SIGNET NON DEFINI.
1.11.3. FORMAT ............................................................................................................................................. 30
1.11.4. MISE A JOUR DES INFORMATIONS ....................................................................... ERREUR ! SIGNET NON DEFINI.
ANNEXES 2 : RESPECT DES EXIGENCES DE SECURITE ....................................................................................... 31
2.1. BESOINS DE SECURITE ................................................................................................................................ 31

2.1.1. DISPONIBILITE DES DONNEES .................................................................................................................. 31
2.1.2. INTEGRITE ........................................................................................................................................... 31
2.1.3. CONFIDENTIALITE ................................................................................................................................. 31
2.1.4. TRAÇABILITE ........................................................................................................................................ 31
2.2. CERTIFICATIONS SECURITE DU PRESTATAIRE ................................................................................................... 32
2.3. DROIT D’AUDIT ........................................................................................................................................ 32
2.4. RESPONSABILITES TIERCE PARTIE .................................................................................................................. 32
2.5. GESTION DES IDENTITES ET DES HABILITATIONS ............................................................................................... 33
2.6. SESSION.................................................................................................................................................. 33
2.7. CONTROLE D’ACCES .................................................................................................................................. 34
2.8. PROTECTION DES DONNEES......................................................................................................................... 34

2.9. ARCHITECTURE SECURITE............................................................................................................................ 35

2.10. JOURNALISATION DES EVENEMENTS .............................................................................................................. 35
2.11. GESTION DES INCIDENTS ET GESTION DE CRISE ................................................................................................ 35
2.12. GESTION DES VULNERABILITES ..................................................................................................................... 35
2.13. LOCALISATION DES DONNEES....................................................................................................................... 35
2.14. GESTION DES EVOLUTIONS .......................................................................................................................... 36
2.15. REVERSIBILITE .......................................................................................................................................... 36
2.16. ANTI-VIRUS ET PROGRAMME MALVEILLANT .................................................................................................... 36
2.17. VEILLE .................................................................................................................................................... 36
2.18. GESTION DES PATCHS DE SECURITE ............................................................................................................... 36
2.19. DESTRUCTION DES DONNEES ....................................................................................................................... 36
2.20. JOURNAUX SYSTEMES ET APPLICATIFS............................................................................................................ 37
2.21. SYNTHESE DES EXIGENCES ........................................................................................................................... 37
ANNEXES 3 : RESPECT DES BESOINS IT (TECHNIQUES) .................................................................................... 39
3.1. CADRE DE COHERENCE TECHNIQUE GENERAL .................................................................................................. 39

3.1.1. ARCHITECTURE GENERALE DU SYSTEME D’INFORMATION ENGIE ................................................................... 39
3.1.2. DESCRIPTION DES POSTES ENGIE ET DES CONTRAINTES APPLICATIVES ............................................................. 40
3.2. ARCHITECTURE ......................................................................................................................................... 43
3.2.1. EXIGENCES D’HEBERGEMENT .................................................................................................................. 43
3.2.2. ACCESSIBILITE ...................................................................................................................................... 44
3.3. ECHANGES .............................................................................................................................................. 44
3.3.1. ECHANGES RESEAUX.............................................................................................................................. 45
3.3.2. SERVEUR MAIL ..................................................................................................................................... 45
3.3.3. EXPORT DE DONNEES ............................................................................................................................ 45
3.3.4. PLATEFORME D’ECHANGES ..................................................................................................................... 45
3.3.5. API ET CONNECTEURS ........................................................................................................................... 45
3.3.6. INTERFACES AVEC D’AUTRES SI ................................................................................................................ 46
3.3.7. CHIFFREMENT DES DONNEES................................................................................................................... 46
3.3.8. SAUVEGARDES ..................................................................................................................................... 46
3.3.9. DOCUMENTATION TECHNIQUE ................................................................................................................ 46
3.4. EXIGENCES SUR LES PERFORMANCES ............................................................................................................. 46
3.4.1. EXIGENCES SUR LES PERFORMANCES DE L’INTERFACE HOMME-MACHINE (IHM) .............................................. 46
3.4.2. EXIGENCES SUR LES PERFORMANCES DES TRAITEMENTS ................................................................................ 47
3.4.3. EXIGENCES SUR LES PERFORMANCES DES REQUETES ..................................................................................... 47
3.4.4. SYNTHESE DES EXIGENCES ...................................................................................................................... 47
3.5. ACCES MOBILE ......................................................................................................................................... 48

1. Contexte
Le présent document constitue le cahier des charges pour le déploiement d’une solution logicielle
immobilière de gestion opérationnelle pour le Groupe ENGIE.
L’organisation de l’immobilier dans le Groupe ENGIE repose sur :
Une Direction de l’Immobilier Groupe (DIG), en charge de la politique immobilière, de la
gouvernance d’ensemble et du pilotage de la performance de la filière,
De trois Business Services Immobiliers (BS Energie, BS Services et BS Belgique) en charge de
la gestion opérationnelle du patrimoine immobilier occupé par le Groupe et des Tiers. Ces 3
BS sont pilotés et sous l’autorité de Global Business Services Ligne Immobilier (GBS Ligne
Immobilier).
Seule une partie du parc géré par GBS est concerné par la présente demande : le BS Belgique et une
partie du BS Energie (sites centraux).
1.1. Enjeux et objectifs

Le Groupe ENGIE dispose actuellement d’une solution de gestion des demandes d’interventions dont
le contrat arrive à échéance et qui n’est plus en adéquation avec l’évolution des activités, ni avec les
processus et les besoins des opérationnels des BS.
Les objectifs attendus pour la mise en place d’une nouvelle solution de gestion et pilotage
patrimoniale centralisée sont ainsi de :
fournir aux utilisateurs – clients et aux opérationnels une interface particulièrement intuitive
et ergonomique pour piloter et gérer l’ensemble des activités liées à la gestion
opérationnelle du parc immobilier,
disposer d’une solution / application disponible sur les principaux smartphone du marché,
constituer un référentiel unique partagé par les trois BS et l’ensemble des collaborateurs
(voir document des exigences fonctionnelles). Cet outil doit permettre une connaissance et
un suivi du patrimoine immobilier géré au niveau de chaque entité (sélection, centralisation,
unicité et fiabilité de l’information patrimoniale),
disposer d’informations opérationnelles centralisées,
permettre une analyse des évènements sur le patrimoine, pouvoir en apprécier ses
évolutions et ses coûts afin de faciliter le pilotage de la stratégie immobilière.
D’un point de vue opérationnel, cette solution doit répondre aux objectifs majeurs suivants :
Solution permettant de traiter l’ensemble des demandes techniques et services des
occupants des sites,
Solution permettant de constituer et de gérer simplement des référentiels descriptifs
(patrimoine, tiers, organisation, baux …), à géométrie évolutive concernant le nombre de
données gérées,

Solution intégrant nativement des fonctionnalités permettant de générer des états de

reporting simples,
Solution intégrant nativement des fonctionnalités permettant de classer/archiver/consulter,
des documents ou proposant à défaut des passerelles vers tous types d’outils de GED,
Solution permettant de gérer l’historique des données,
Solution évolutive dans le temps (possibilité d’enrichissement de la solution avec l’ajout de
champ/fonctionnalités/domaines fonctionnels complémentaires non prioritaires à ce jour),
Solution conviviale et intuitive pour les utilisateurs
Solution permettant dès la page d’accueil de faciliter l’accès aux informations de la base (par
thématique) et proposant des fonctions de recherche avancées.
1.2. Périmètre
Le patrimoine d’ENGIE objet du présent appel d’offres et sur lequel la solution doit être déployée se
décompose comme suit :
BS I&L Energie :
o 8 sites : T1/T2, Jean Monet et Le Colisée à Paris La Défense, Le Landy à La Plaine
Saint Denis, EuroAtrium à Saint Ouen, Eole et Djinn à Bois Colombes,
BS Belgique :
o 11 sites : ENGIE Tower et Quai des Usines à Bruxelles, Gent (Gand), Jumet (Charleroi),
2 sites à Namur (dont Printshop), ENGIE Tower à Anvers, Liège, Linkebeek, Louvain-
La-Neuve.
L’implantation multi pays impose une solution multilingue français, flamand et anglais.
1.3. Références actuelles d’utilisateurs et de demandes d’interventions

Une première estimation du nombre d’utilisateurs et du nombre d’interventions annuelles, est
décrite dans le tableau ci-dessous :
BS Energies BS Belgique
Nombre d’utilisateurs 4.200 4.000
Nombre de demandes
annuelles
31.000 13.074

1.4. Solutions recherchées

La solution devra permettre de définir plusieurs types de reporting pour répondre aux besoins et
attentes des groupes de profils définis. Les besoins d’information entre un opérationnel, un
responsable d’activité ou une vision direction consolidée sont fondamentalement différents. Les
tableaux de bord pourront être soit pré formatés et fournis avec la solution lors de la mise en œuvre,
soit modifiables et paramétrables par l’utilisateur – l’administrateur.
Il est impératif que le futur système puisse être utilisé dans le contexte d’une organisation
décentralisée en fonction des périmètres spécifiques :
Référentiel commun maintenu de façon centrale
Gestion opérationnelle par chaque BS
Définition et suivi des tableaux de bord communs et pour chaque BS
Possibilité faire varier le niveau de détail de la gestion en fonction du BS
Souplesse dans la gestion des profils qui permette de s’adapter à l’organisation locale
(autoriser la saisie directe lorsqu’il n’est pas possible ou souhaitable de s’interfacer à un
système amont par exemple)
Possibilité de définir et de mettre en œuvre chaque workflow en fonction du BS
L’ergonomie doit être agréable quelle que soit la taille du site
Le périmètre du projet inclut :

La reprise des données contenues dans les systèmes actuels
La réalisation des interfaces
Le paramétrage des règles de gestion
L’accompagnement et la formation des utilisateurs en back office
1.5. Planning prévisionnel de la consultation et de mise en place des

solutions
Date prévisionnelle
Ateliers de définition des besoins utilisateurs Mars – avril 2017
Spécifications techniques et fonctionnelles Mai – juin 2017
Recette et reprises des données Juillet 2017
Reprise des données et mise en œuvre en parallèle Septembre 2017

du système actuel
Mise en production mi-octobre 2017

2. Attentes fonctionnelles
2.1. Fonctionnalités majeures attendues de la solution

Au regard des besoins identifiés, la solution recherchée devra offrir les principales
fonctionnalités suivantes :
Création, saisie, enregistrement et validation de formulaires de demandes,
Automatisation des étapes des processus (workflow de validation),
Suivi de l’avancement des processus de demandes, notamment avec gestion d’alertes
sur les délais,
Déclenchement d’alertes et de notifications en cas de non-respect des délais (ou de tout
autre règle de gestion),
Accès à l’historique des demandes,
Gestion d’arborescence et de classifications documentaires,
Modélisation graphique des processus et modification souple des éléments du process,
Filtres et requêtes pour édition de listes spécifiques,
Extraction et import/export de données.
2.2. Principales prestations :

Le traitement des demandes d’interventions recouvre différents types de prestations, dont
notamment :
Les prestations techniques :

o Gestion des demandes d’interventions techniques
o Connexion avec la maintenance des bâtiments (GMAO)
Les prestations de services :

o Gestion et réservation des salles de réunion
o Gestion des réceptions / expéditions, des courses et manutention
o Gestion des badges et des visiteurs
o Gestion des demandes de nettoyage
o Gestion des mouvements
o Espace commun d’information
Pilotage des prestations :
o Gestion du reporting et des budgets.
Le détail des prestations est mentionné en annexe 1.

3. Attentes techniques
3.1. Accès à la solution

La solution doit pouvoir être accessible simplement à partir d’un navigateur Internet, sans qu’il soit
nécessaire d’installer des composants informatiques sur les postes clients (full web). Elle devra
également être accessible via des outils de mobilité tels que des tablettes numériques ou des
Smartphones afin de prendre en compte les contraintes opérationnelles. Elle devra également
pouvoir supporter l’import de fichiers plats (notamment financiers, consommations énergies et
fluides).
3.2. Ergonomie et intuitivité

Il sera porté une attention toute particulière à l’ergonomie de la solution et surtout à la navigation au
travers des masques pour mettre en œuvre les fonctionnalités. A ce titre des masques de saisie
spécifiques à chaque domaine d’activité (baux, cessions, travaux, etc.) devront être mis à disposition
des utilisateurs concernés, pour remplir ou modifier les données pour lesquelles ces derniers sont les
garants. Ce point est fondamental car il conditionne la bonne acceptation de la solution par
l’ensemble des utilisateurs et surtout une utilisation optimale.
Chaque utilisateur (tous les profils confondus) pourra modifier l’affichage d’utilisation de la solution
au niveau de sa session, lui offrant la possibilité d’afficher à l’écran les informations (données /
indicateurs / documents en lien avec la GED) qu’il utilise dans le cadre de ses activités quotidiennes
(principes de favoris ou de fonctionnalités les plus utilisées). Ce paramétrage du contexte de
l’utilisateur doit pouvoir être sauvegardé et réutilisé à chaque connexion.
Les principaux points (non exhaustifs) qui seront examinés :
Rapidité et aide à la saisie,
La limitation contextuelle des éléments affichés,
L’utilisation de nomenclatures (boîtes déroulantes avec visibilité limitée selon les
habilitations et le contexte),
Le nombre réduit d’écrans pour gérer un processus donné,
Aucune double saisie au travers de l’application pour fiabiliser les données,
Possibilité de paramétrer la terminologie utilisée dans les écrans,
Format d’impression ne doit pas nécessiter de remise en forme par l’utilisateur,
Aide contextuelle pour tous les écrans notamment pour chaque type de demande,
Ergonomie / homogénéité des écrans,
La disponibilité des interfaces dans les langues attendues (Français, Néerlandais, Anglais),
Affichage des étapes du cheminement pour accéder à l'écran utilisé
Possibilité d'utilisation de la souris ou du clavier indifféremment pour les déplacements
Distinction des champs de saisie obligatoires ou facultatifs
Demande de confirmation si suppression / abandon / déconnexion / modification
Utilisation indifféremment du point ou de la virgule dans les montants
Formatage des données numériques (séparateur de milliers avec 2 décimales)

Saisie simplifiée des dates possible (ex.: 230614 pour 23/06/2014)

Existence de menus contextuels par clic droit
Fonctionnalité de duplication pour les créations en série
Affichage d’un indicateur permettant de savoir si une donnée a fait l’objet d’une validation
La solution doit offrir des possibilités de personnalisation (masquer, modifier, ajouter …) en fonction
des utilisateurs ou a minima des profils d’utilisateur au niveau :
Des écrans
Des menus
Des champs
Des libellés
La solution doit permettre de rendre certains champs/zones obligatoires.
La solution doit permettre de sauvegarder des "favoris" dans le menu afin de permettre un accès
direct aux écrans les plus fréquemment utilisés.
La solution doit comporter à minima les fonctionnalités de recherche suivantes :
Recherches multicritères sur les données de la base,
Recherche possible sur des chaînes de caractères,
Existence d'un caractère joker pour les recherches alphanumériques.
La charte graphique du Groupe (logo, couleur des interfaces utilisateurs, polices de caractère) doit
pouvoir être intégrée dans la solution.
La solution devra permettre de tracer et d’horodater les actions réalisées par les différents
utilisateurs. Afin de permettre à l’ensemble des utilisateurs de connaitre la date de mise à jour des
informations (concerne les profils « contributeur et administrateur »), chaque information
mentionnée dans la solution, doit permettre d’identifier :
Le nom du dernier utilisateur à avoir ajouté / modifié / supprimé / archivé la donnée,
La date de la modification.
Ces informations devront apparaitre de manière discrète. Le Prestataire pourra être force de
proposition sur la représentation de ces informations.
3.3. Gestion des habilitations

L’authentification des utilisateurs est réalisée via l’annuaire de sécurité LDAP, avec identification par
un compte applicatif.
Dans l’optique d’un démarrage à court terme, il est possible d’envisager que la gestion des
habilitations soit totalement incluse dans la solution, y compris la réalisation de
l’authentification des utilisateurs via l’application.
Les fonctionnalités suivantes doivent être assurées par l’outil :
Création / mise à jour / suppression des comptes utilisateur
Création / mise à jour / suppression des profils fonctionnels

Définition des droits d’accès aux écrans/menus/données de la base pour les profils
fonctionnels
Association comptes utilisateurs / profils fonctionnels
Définition des droits d’accès aux écrans/menus/données de la base pour les comptes
utilisateurs
Association comptes utilisateurs / périmètres géographiques / profils fonctionnels
Les droits d’accès doivent pouvoir être décomposés a minima en :
Droits de saisie / création
Droits de saisie / modification
Droits de lecture / consultation
Par défaut, tous les utilisateurs de tous les BS ont accès à toutes les données de tous les BS en lecture
seule.
3.4. Recherche / Consultation des données
Les résultats de recherche / consultation par les utilisateurs sont contrôlés par la restriction de leur
accès aux seules données de leur périmètre d’habilitation.
Les utilisateurs doivent pouvoir faire des recherches multicritères sur les données.
Tous les champs de la base constituent des critères de recherche facultatifs.
Les résultats sont affichés sous forme de liste. La sélection d'un des items de la liste permet d’en
visualiser le détail.
3.5. Export des données de la base

Les données de la base doivent pouvoir être extraites sous forme de fichiers à des formats standards
exploitables sous Excel. L’export Excel doit pouvoir se faire :
A partir d’une recherche de données (seules les données recherchées sont exportées) ;
En générant un fichier reprenant l’intégralité des données de la base, en vue de son
utilisation dans le cadre de la génération d’états de reporting existant à ce jour sous Excel.
3.6. Historisation des données
La solution doit conserver l’historique de toutes les données afin de permettre :

De suivre dans le temps l’évolution des données brutes et des indicateurs produits à partir de
ces données ;
De réaliser des analyses comparatives sur plusieurs périodes.
Les données historisées doivent être :
Stables,
En lecture seule,

Non modifiables par les utilisateurs.

Dès qu’une donnée est historisée, elle ne peut donc plus être altérée, modifiée ou supprimée
(jusqu'à un certain délai de purge).
Une même requête sur les données historisées, lancée à plusieurs reprises et à différents
moments, doit ainsi restituer les mêmes résultats.
Chaque donnée historisée doit être datée ou se voir affecter un numéro de version pour :
Eviter de recouvrir une information déjà présente dans la base de données ;
Permettre de suivre son évolution au cours du temps.
3.7. Editions
La solution doit disposer des fonctionnalités nécessaires pour faire des éditions sur tout type
d’imprimantes. Ces éditions concernent aussi bien les masques de travail (à tout moment dans le
contexte d’utilisation), les rapports, les résultats de requêtes. Elles doivent pouvoir être lancées à
partir de tout poste de travail sur les imprimantes reconnues par le poste informatique et également
être visualisées avant le lancement.
3.8. Aide en ligne

Une aide à la saisie doit être disponible pour l’alimentation de certains champs.
Une « aide en ligne contextuelle » ainsi qu’un glossaire doivent être disponibles pour préciser la
définition du contenu :
De certaines fonctions
De certains champs / terminologies complexes
L'aide en ligne doit être actualisée à chaque montée de version.
L'aide en ligne et le glossaire doivent être personnalisables en fonction des paramétrages retenus.
3.9. Capacité d’ouverture et facilité d’intégration

La capacité d'ouverture de la solution à d'autres applications et la facilité d'intégration dans un
Système d’Information Groupe sont indispensables.
La solution doit être conçue comme un ensemble ouvert dialoguant avec les autres systèmes au
moyen de passerelles établies à partir de modes standard d’échange de données.
Les échanges de données, de pièces jointes et d'images entre les modules de l'outil doivent être
totalement transparents et ne doivent pas entraîner de délais en termes de temps de traitement
dans le processus.

3.10. Mobilité
Une version « mobile » de la solution, compatible avec chacun des 3 systèmes d’exploitation
existants sur le marché (iOS / Androïd / Windows Mobile), doit être proposée par le Prestataire.
Le périmètre fonctionnel couvert (actuellement et en cible) par la solution en termes de mobilité doit
être détaillé par le Prestataire.
La solution doit être Web Responsive design (i.e. l’interface utilisateur s’adapte automatiquement au
format d’affichage de l’équipement utilisé – Smartphone, tablette …).
3.11. Transfert, initialisation des données et exports.

L’initialisation des données et la création des objets doivent pouvoir être réalisées de manière
unitaire mais également par volume. La solution doit permettre d’initialiser des équipements, les
occupants ou d’autres éléments à partir de fichier Excel ou CSV par l’intermédiaire d’une procédure
appropriée.
ENGIE prévoit d’établir un fichier regroupant l’ensemble des données disponibles, à jour. Ce fichier
servira de base à l’import de masse devant être réalisé par le Prestataire. ENGIE dispose également
sur un serveur dédié, de documents scannées et intégrés dans la solution actuelle. Le Prestataire
devra préciser dans son offre :
Les modalités précises de reprises des informations par typologie (fichier préparé et données
disponibles sur serveur),
Les contraintes pouvant avoir un impact en termes financiers ou organisationnels pour
assurer une telle reprise.
Les principales fonctionnalités attendues devront disposer de fonctionnalités d’export. Les formats
d’export exigés sont CSV, XLS, Word. Il devra être possible pour les administrateurs, d’activer ou non
ces fonctionnalités d’exports pour chaque profil d’utilisateur.
3.12. Maintenance, incidents et environnements

Il est attendu que le Prestataire assure la maintenance de la solution qu’il propose. Cette
maintenance doit couvrir à la fois :
L’assistance aux utilisateurs. Le support aux utilisateurs de niveau 1 sera assuré par chacun
des administrateurs des BS. Seuls les administrateurs adresseront directement leurs
demandes d’assistance. Le mode d’échange privilégié est le mail.
La maintenance corrective,
Le suivi logiciel.
La maintenance applicative ne pourra se dérouler durant les heures de fonctionnement des services
soit :
Du lundi au vendredi, hors jours fériés officiels communs à la France et la Belgique,
De 8h à 19h.

La maintenance corrective prendra en compte les niveaux d’incidences suivants :

Bloquantes : accès à l’outil impossible, indisponibilité d’un module, suppression des données
saisies,
Majeurs : donnée qui n’est pas correctement restituée, reporting non conforme aux données
présentes (manques, mauvais calcul)
Mineures : mise en forme non conforme, édition non conforme, etc.
Les contraintes décrites s’appliquent à l’environnement de production tout comme à celui de pré-
production.
4. Phase projet, livraison et recette
4.1. Groupe de projet ENGIE
Un groupe de projet ENGIE dédié, sera composé des personnes suivantes :
2 représentants et pilotes pour le CSP I&L France (complété par les expertises métiers selon
besoin)
2 représentants et pilotes pour le CSP Belgique
3 consultants informatiques Groupe
1 coordinateur Ligne de Service Immobilier de la GBS.
Durant la phase d’exploitation du projet, l’organisation prévue est la suivante :
1 « super administrateur », qui coordonnera les demandes spécifiques d’évolutions avec le

Prestataire et qui sera également le référent des autres administrateurs,
1 administrateur par BS et pour la DIG, soit 4 administrateurs locaux.
4.2. Comité de pilotage
4.2.1. Comité de pilotage phase projet

Afin de consolider l’avancement du projet global et de respecter les atteintes en termes de coût, de
délais et de qualité, un Comité de Pilotage (COPIL), sera organisé entre :
Les équipes du Prestataire,

Les équipes d’ENGIE (MOA),
Les équipes de la Ligne Immobilière qui assureront le rôle de maitrise d’Ouvrage Déléguée
(MOD).
L’ensemble des représentants des équipes se retrouveront à date fixe, pour une réunion tous les
mois, afin de mesurer l’état d’avancement et les points bloquants.

Le Comité de Pilotage a pour rôle de prendre toutes les mesures nécessaires à la bonne exécution du
programme fixé. Il doit en particulier :
Piloter le projet et prendre toute mesure adéquate pour réorienter tant le projet que son
organisation en cas de nécessité,
Planifier à titre indicatif la disponibilité des ressources adéquates dans les mois à venir en
fonction des objectifs posés,
Suivre le déroulement des prestations :
o établir un rapport périodique écrit de l’avancement des prestations réalisées
o suivre la facturation et les règlements
Veiller à la mise à jour des modalités pratiques de fonctionnement et informations relatives
aux intervenants,
Vérifier le respect du contrat,
Identifier les difficultés rencontrées et les alertes,
Les PV de réunion sont établis par le Prestataire sous 48 heures et approuvés sous 5 jours par tous à
partir de la date de diffusion. En l’absence de remarques par ENGIE, le compte-rendu est considéré
comme validé.
Une réunion de projet (COPROJ), se tiendra hebdomadairement entre le chef de projet de la MOD et
le chef de projet du Prestataire.
Le détail des livrables attendus sera validé conjointement entre la MOA et le Prestataire. Le planning
prévisionnel du Prestataire devra intégrer l’ensemble de ces réunions.
4.3. Etat et qualité de la donnée au démarrage de la mission
L’ensemble des équipes réaliseront avant le démarrage de la mission avec le Prestataire, une
synthèse à jour de la donnée immobilière au sein des BS. Ces données, de volume variable, seront
regroupées dans un « métafichier » par CSP, regroupant l’ensemble des données et des informations
validées et à jour et devant être intégrées dans la solution.
Ces 3 fichiers tendront à avoir une trame commune, toutefois la diversité des patrimoines ne
permettra pas obligatoirement d’atteindre cet objectif.
Il est attendu dans la phase projet, que le Prestataire se charge de transformer ces différents fichiers
pour qu’ils correspondent aux formats d’import de sa solution.
Un état de la GED actuelle sera également réalisé. Les volumes de documents actuellement stockés
sont précisés dans le périmètre de chacun de ces BS.
4.4. Elaboration et validation du dossier de spécifications fonctionnelles
Le Prestataire est réputé sachant dans les domaines de la gestion patrimoniale. Aussi il devra
accompagner et conseiller les équipes d’ENGIE dans la formalisation opérationnelle des attentes
fonctionnelles exprimées dans le CCTP.

En fonction du planning qui sera validé conjointement entre le Prestataire et ENGIE, la phase de
conception débutera le jour suivant la date de signature du contrat pour s’achever le jour de la
réception définitive (purgée de toutes réserves même mineures). Cette phase correspond à la
réalisation du dossier de spécifications fonctionnelles qui doit permettre aux représentants des
utilisateurs de définir avec les équipes du Prestataire l’ensemble des fonctionnalités et process
devant être mis en place. Le Prestataire élaborera, suite aux différentes réunions réalisées (autant
que nécessaires) une synthèse et un descriptif détaillé des fonctionnalités attendues. Ce dossier sera
validé par les équipes d’ENGIE. La validation définitive permet le passage à l’étape de réalisation du
projet.
4.5. Interfaces
Les interfaces envisagées concernent :
- Lot 1 :
o 1 interface type web service avec les outils des administrateurs de biens type Altaïx
o 1 interface avec un pilotage des énergies et fluides (si option non levée dans la
solution du Prestataire) : fichiers plats, csv ou web services
o 1 interface avec un outil de gestion des surfaces (si option non levée dans la solution
du Prestataire) : fichiers plats, csv ou web services
o 1 interface avec un outil de pilotage dédié de la DIG : fichiers plats, csv ou web
services
- Lot 2 : mise à jour de la donnée trimestrielle ou semestrielle (rythme sera validé en fonction
des propositions du Titulaire)
o 1 interface avec Sigma,
o 1 interface avec Star,
o 1 interface avec Rapsodie
o 1 interface avec le lot 1
o 1 interface avec outil RH
o 1 interface avec pilotage des fluides
4.6. Mise en œuvre du projet
L’objectif de la mise en œuvre du projet, consiste en la réalisation des paramétrages et adaptations

spécifiques de la solution, nécessaires au fonctionnement selon les préférences décrites dans le
dossier de spécifications fonctionnelles.

La mise en œuvre du projet intègre la reprise des données existantes dans la solution au format
ENGIE. Les processus de reprise des données devront être définis par le Prestataire dans son offre.
Toutefois, ENGIE prévoit de consolider l’ensemble des informations dont elle dispose sous un format
commun et unique sous Excel.
La reprise des documents, quand à elle, reste à préciser. Il est toutefois attendu de pouvoir faire des
imports en masse, sous un format simple permettant de rattacher les documents aux sites.
4.7. Processus de recette
Le prestataire avant livraison de l’outil devra procéder à des tests unitaires. Il fournira à ENGIE
l’ensemble des tests unitaires qui feront référence au dossier de conception (spécification
fonctionnelle détaillée) et les écarts potentiels constatés. Le prestataire est tenu de corriger les
anomalies constatées suite à ces tests préalablement à la recette fonctionnelle d’ENGIE.
Le Prestataire proposera un cahier de recette fonctionnelle. Ce cahier doit pouvoir aider les
utilisateurs à tester la solution tant sur un plan fonctionnel (temps de réponse, cohérence des liens,
passage d’un onglet à l’autre), que sur un plan qualitatif de la donnée reprise. Ce cahier de recette
sera partagé et amendé avec les équipes d’ENGIE.
Durant la recette, réalisée sur plusieurs jours avec différents groupes d’utilisateurs (envisager 5 jours
à minima), les anomalies détectées seront classées selon une échelle de priorité à 3 niveaux :
Anomalie bloquante : ne permet pas de réaliser la recette, une fonctionnalité manquante,

process bloquant dans la gestion opérationnelle.
Anomalie majeure : processus non cohérent avec le dossier de spécifications, informations
non exploitable.
Anomalie mineure : erreur dans la reprise de donnée, process opérationnel malgré tout.
La levée des réserves devra intervenir sous un délai maximum de 15 jours, la réception définitive
n’étant réalisée qu’à la levée de l’ensemble des réserves exprimées durant et après la phase de
recette, suivant les réponses apportées par le Prestataire.
4.8. Formation des utilisateurs – administrateurs
Le Prestataire devra former les utilisateurs et administrateurs à l’utilisation de la solution. Pour ce

faire, il devra prévoir la mise en place d’une plateforme ponctuelle de formation sur laquelle les
personnels ENGIE pourront retrouver une copie de la base réelle. Pour garantir la pérennité et
l’intégrité de la base d’exploitation, aucune formation ne devra se dérouler sur la plateforme de
production.
Une formation spécifique sera faite en amont des utilisateurs standards auprès des administrateurs.
Cette formation devra permettre aux personnels ENGIE identifiés, de maitriser l’ensemble des
fonctionnalités relevant de leurs responsabilités. Le Prestataire supervisera le travail des
administrateurs qui animeront la formation des utilisateurs standards.

5. Phase exploitation – RUN
5.1.1. Comité de pilotage phase RUN

Le Comité de Pilotage a pour rôle de prendre toutes les mesures nécessaires à la bonne exécution du
programme fixé. Il doit en particulier :
Piloter le projet et prendre toute mesure adéquate pour réorienter tant le projet que son
organisation en cas de nécessité,
Etudier des évolutions à venir (court ou moyen terme),
Piloter synthétiquement le mode récurrent par une analyse des interventions et/ou incidents
de la période écoulée,
Suivre le déroulement des prestations :
o établir un rapport périodique écrit de l’avancement des prestations réalisées
o suivre la facturation et les règlements
Veiller à la mise à jour des modalités pratiques de fonctionnement et informations relatives
aux intervenants,
Vérifier le respect du contrat,
Proposer aux signataires du contrat, le cas échéant, leur réorientation, extension, annulation,
prise en compte contractuelle des modifications (les signataires devront être présents lors de
ces décisions),
Identifier les difficultés rencontrées et les alertes,
Analyser le reporting de la période.
Les PV de réunion sont établis par le Prestataire sous 48 heures et approuvés sous 5 jours par tous à
partir de la date de diffusion. En l’absence de remarques par ENGIE, le compte-rendu est considéré
comme validé.
Le rythme du COPIL en phase RUN reste à définir en collaboration avec le Prestataire mais devra à
minima se tenir une fois par trimestre. En cas de difficultés, ENGIE pourra modifier le rythme de ces
réunions.
5.1.2. Reporting
La qualité de service sera mesurée lors des COPIL grâce aux indicateurs de suivis mensuels. Le
Prestataire s’engage à fournir le reporting suivant sur la période analysée par type d’anomalie
(critique, majeure ou autre) et demande fonctionnelle :
Le nombre de nouveau(x) ticket(s)

Le nombre de ticket(s) en cours
Le nombre de ticket(s) résolu(s)
Uniquement pour les anomalies critiques et majeures :

Le délai total de résolution

La durée de dépassement
Ces indicateurs seront présentés sous forme d’un reporting dont le format (graphiques et tableaux)
sera à la discrétion du Prestataire. Ce reporting sera présent dans l’ordre du jour des COPIL, qui sert
de support d’échange lors de cette instance.
Le mode de calcul sur ces indicateurs sera communiqué lors du COPIL. Une annexe à l’ordre du jour
du COPIL listera dans 2 tableaux distincts les tickets ouverts et les demandes ouvertes nécessitant
une offre. Ces tableaux afficheront les colonnes suivantes :
N° du ticket
Libellé du ticket
Statut du ticket
Détenteur actuel du ticket (Prestataire/ENGIE)
Date de création d’un ticket
Date prévisionnelle de livraison
Tickets associés/liés
Commentaires

Annexes :

Annexe 1 : Lot 1 Synthèse des données opérationnelles à intégrer
Le présent chapitre, définit les besoins collectés auprès des opérationnels. Le classement par
thématique ne préjuge en rien des modules ou fonctionnalités attendus, il regroupe simplement les
besoins, attentes et les principales données devant être intégrées selon de grandes thématiques. Le
Prestataire devra :
définir dans son offre la présence ou non des fonctionnalités attendues,
la faisabilité de traiter l’ensemble des informations listées,
tenir compte des contraintes de chaque BS.
Dans ce chapitre, un focus est fait sur certaines activités, ce dernier a pour objectif de souligner les
informations usuelles qui doivent être saisies par les contributeurs dans la solution, via l’utilisation de
masques « ad-hoc ». Ces masques seront accessibles en natif par les contributeurs (permettre de
faire des contrôles des données enregistrées) mais également par d’autres utilisateurs qui ont besoin
dans le cadre de leurs activités d’avoir une vision détaillée d’une activité (habilitation en consultation
uniquement).
1.1. Prestations techniques :
1.1.1. Plomberie
motifs : Accessoires sanitaires, Fuite d’eau, Pas d’eau, Pas d’eau chaude, Problème chasse
d’eau, Toilettes bouchées, Urinoir bouché
1.1.2. Serrurerie
motifs : Demande de clé de mobilier, Modification de signalétique, Problème de digicode
Armoire Vestiaire, Problème de fonctionnement d’une porte sous lecteur de badges),
Problème de portes, Problèmes de portes hors lecteur de badges, Problème de serrure,
Problème de serrure mobilier
1.1.3. Chauffage Ventilation Conditionnement
motifs : installation bruyante, problème d’odeur, présence de courant d’air, trop chaud, trop
froid
1.1.4. Electricité éclairage
motifs : pas de courant, problème prise de courant, problème éclairage

1.1.5. Diverses interventions
motifs : dépannage de fenêtre (sifflement, joints), dépannage de store, fixations diverses,

infiltration d’eau, moquette décollée / abimée, panne ascenseur, plafonds / faux plafonds
(dalles de plafonds), plancher / Faux plancher (dalles de moquette), problème lié aux
extincteurs, problème télécommande.
1.1.6. Aménagements –Travaux
motifs : demande de plans ou de travaux
1.2. Prestations de Services :
1.2.1. Gestion des salles de réunion

Nom ou numéro de la salle,
Type de ressource (salle de réunion, auditorium, bureau de passage…),
Localisation (lien avec référentiel),
Organisation de rattachement (lien avec référentiel),
Plage administrative des horaires d’accès,
Photo et plan d’accès,
Fichier associé (consignes de bon usage de la salle…),
Description,
Regroupements possibles (salle 1 + salle 2 = salle 3),
Sélection des types d'aménagement possible avec capacité associée,
Sélection des équipements fixes existants ainsi que le nombre,
Stocks d’équipements associés.
o Règles
La capacité d'une salle dépend de l'aménagement,
L’aménagement de la salle dépend du nombre de personnes prévues,
Plusieurs aménagements possibles par salle, chacun induisant une capacité
différente,
Les réservations doivent pouvoir tenir compte des salles modulables,
Le système devra tenir compte dans la réservation des temps de préparation
et de remise en place des salles,
Des profils d’accès seront définis (gestion de profil utilisateur),
L’outil devra pouvoir s’interfacer avec l’annuaire de l’entreprise (LDAP),
Les salles peuvent être banalisées (réservation ouverte à tous), dédiées
(réservation limitée à un groupe défini) ou prioritaires (réservation ouverte à
tous mais possibilité de préemption par des entités définies comme
prioritaires).
o Fonction de réservations des salles de réunions. La solution devra permettre :

La saisie des demandes de réservation,

La recherche d'une salle,
La gestion des réservations récurrentes,
La validation des demandes de réservation,
Le suivi des mouvements (annulation, changements de dates ou de lieux, ...),
La refacturation des prestations demandées (en fonction du demandeur).
o Modalités de réservation :
Une personne habilitée réserve une salle à partir d’une date et d’un mode
(avec ou sans récurrence) avec la possibilité de définir une capacité et/ou
une configuration.
Si la réservation est récurrente, la personne définit son type (quotidienne,
hebdomadaire, toutes les 2 semaines, mensuelle…) et la date de fin.
Un planning des salles correspondant aux droits de la personne et à ses
critères de sélection doit être accessible.
Pour chaque salle, la personne doit pouvoir consulter ses caractéristiques
(heures d’accès, équipements fixes, services associés, photo, plan d’accès,
description, modularité avec d’autres salles, configurations possibles,
équipements des stocks associés, réservations déjà effectuées par qui et
pour qui).
Le choix des tranches horaires de réservation doit pouvoir se faire par
créneau paramétrable (à l’heure, la demi-heure, 10 minutes …).
En mode récurrence, la solution doit pouvoir calculer le pourcentage de
réservations satisfaites en fonction des réservations déjà existantes et lister
toutes les occurrences de réservation en indiquant celles qui ne sont pas
réalisables (créneaux déjà réservés). Elle doit permettre d’éditer chacune
d’elle afin de changer éventuellement les salles déjà réservées.
Saisie d’une demande de réservation
La saisie d’une demande de réservation par l’utilisateur implique les
informations suivantes :
Coordonnées du demandeur : Nom, téléphone, société, organisation (saisie
automatique en fonction du login),
Coordonnées de la personne pour qui est faite la demande : Nom, téléphone,
société, organisation, localisation (saisie automatique suite au choix de la
personne dans l’annuaire),
Date de la réunion,
Créneau horaire de réservation,
Configuration souhaitée (type d’aménagement de salle),
Capacité souhaitée (le système doit proposer les salles satisfaisant cette
demande selon une tolérance définie en administration),
Commentaires (type de réunion, objet de la réunion, spécificité de la
réunion…),
Mode (avec ou sans récurrence),

Equipements (sélection d’équipements disponibles dans le stock pour ce

créneau),
La délégation de demande doit pouvoir être contrôlée par des habilitations.
Un temps de reconfiguration de salle sera défini dans le logiciel. Ce temps se
rajoutera à la durée de la réunion, de façon invisible pour le demandeur, de
façon à prévoir une plage horaire plus large pour permettre l’intervention
des prestataires.
Une demande de réservation de salle doit pouvoir s’accompagner d’une
demande de prestations associées (prestations de room services définies en
administration). Une demande de ce type doit être associée aux
Type de service (prestations définies en administration)
Heure de livraison,
Code d’imputation,
Commentaires.
o Le système doit dresser la liste des prestations commandées au fil de la saisie en
offrant la possibilité de comptabiliser le montant des commandes (par ligne et au
total).
o L’outil devra vérifier, lors de l’enregistrement de la demande, que le délai nécessaire
de préparation est bien respecté par le « demandeur ». Sinon, en avertir l’utilisateur
(ex : la commande d’une prestation hôtelière confiée à un traiteur doit se faire au
minimum x jours avant la réunion)
o Une demande de réservation de salle doit aussi pouvoir s’accompagner d’une
demande de pré enregistrement de visiteurs à l’accueil. Elle serait alors associée aux
Nom du visiteur,
Société,
Adresse email,
Envoi automatique d’un mail d’information au visiteur (oui/non),
Site concerné par la visite,
Date et heure d’arrivée du visiteur,
Commentaires,
Pièce jointe (envoyée avec le mail d’information)
Les demandes seront ensuite traitées individuellement par le système qui les
orientera automatiquement vers les bons opérants suivants (approbateur,
prestataires, accueil…). Par contre, l’annulation de la réservation d’une salle
devra annuler automatiquement les demandes associées dans la limite des
règles fixées en administration (ex : impossibilité d’annuler un room service x
heures avant sa livraison).
o Validation de la demande de réservation
Si cette option est active, les personnes ayant les droits adéquats devront
pouvoir valider ou non chacune des demandes de réservation.

Une fois la réservation confirmée, un mail de confirmation est transmis au

demandeur. A ce mail pourra être joint automatiquement un lien donnant
accès à une fiche de consignes de « bon usage » de la salle, un coupon
d'évaluation du service réservation et, le cas échéant, des messages adaptés
à une époque ou à un événement (par exemple des travaux en cours dans
une pièce proche).
Recherche de salles libres via un moteur de recherche
Simple ou avec récurrence
Multicritères (date, capacité, configuration)
Avec élargissement de la recherche à d’autres salles (si droits associés),
L’outil doit pouvoir proposer en priorité les salles disponibles à l’étage du
demandeur.
o Suivi des réservations et alertes
Un processus de suivi sera clairement défini afin de garantir la satisfaction du
client.
La solution permettra donc de suivre la réservation, de la demande client
jusqu’à la confirmation définitive avec possibilité de notification par mail à
toutes les étapes du processus. La forme et le contenu du mail devront être
prédéfinis lors de la mise en œuvre du système. Ce suivi sera rendu possible
par des tableaux listant de façon séparée :
• Les demandes en cours (demandes faites par soi pour soi),
• Les demandes qui concernent la personne connectée (demandes
faites pour soi par quelqu’un d’autre),
• Les demandes pour lesquels on est intervenu en tant qu’opérant (ex :
validation d’une demande de réservation),
• Les demandes pour lesquels on doit intervenir (tâches en cours),
• Les demandes pour lesquels on doit intervenir et dont notre action
est en retard (tâches en retard).
A tout moment, dans la limite des délais définis en administration, une
réservation de salle doit pouvoir être modifiée et/ou annulée. Ces
changements devront également être soumis à validation.
Un historique devra être conservé. Ces données seront exploitables par un
moteur de recherche permettant de retrouver une demande à partir d’un
mot clef. Cet historique permettra aussi d’accéder à toutes les demandes en
bénéficiant d’un classement par statut : En brouillon, En cours, à traiter, en
retard, où je suis intervenu, terminées, annulées…
o Contrôle Qualité de la prestation
Après le déroulement de chaque réunion, un formulaire d’enquête de
satisfaction devra pouvoir être envoyée au demandeur. Les réponses
devront être historisées afin de permettre la réalisation de statistiques.
Les rapports devront pouvoir être mis en forme à partir d’un générateur.

Un reporting transversal concernera tous les processus (réservation de salle,

commande de room service, pré enregistrement d’un visiteur). Il permettra
l’analyse de la volumétrie en fonction des types de services :
• Courbe mensuelle pour les 12 mois précédents,
• Courbe des valeurs cumulées,
• Tableau des valeurs,
• Tendance sur 12 mois mobiles,
• Courbe d’évolution sur plusieurs exercices.
Par processus, les rapports suivants devront pouvoir être paramétrés lors de
la mise en œuvre de la solution :
• Fiche de synthèse regroupant les indicateurs suivants :
• Un délai à définir,
• La répartition géographique et organisationnelle,
• La répartition par statut,
• L’évolution volumétrique mensuelle
• Liste des demandes filtrées par période pour export Excel.
• Processus de réservation de salles de réunion :
• Taux d’occupation,
• Volumétrie des équipements audiovisuels
• Processus de commande de room services :
• Volumétrie par type de prestation
• Processus de pré-enregistrement des visiteurs :
• Volumétrie par horaire
o La solution devra impérativement disposer d’une application utilisable sur un
smartphone et permettant de visualiser la disponibilité d’une salle par flashcode /QR
Code. La validation de la réservation devra automatiquement être enregistrée dans
l’agenda outlook des collaborateurs et envoyer des invitations aux invités externes.
1.2.2. Badge
o motifs : modification des habilitations de badge, perte de badge, problème de badge

d’accès, problème de fonctionnement d’une porte sous lecteur de badges

1.2.3. Approvisionnement (en) papier (du) point copie
1.2.4. Audiovisuel
o motifs : demande d’assistance pour l’audiovisuel d’une salle de réunion, demande
d’une prestation audiovisuelle (conférence audiovisuelle1), demande de
visioconférence, défaut de fonctionnement d’un matériel audiovisuel, télé présence
1.2.5. Courrier
o motifs : case courrier (information sur la case courrier (référence) ou création) ,
demande de bordereau de recommandé, problème lié au courrier, problème lié aux
colis, problème lié aux coursiers, problème lié aux journaux
1.2.6. Distributeurs de Boissons / friandises
o motifs : absence de gobelets sur distributeur de boissons, absence de gobelets sur

fontaine à eau, anomalie sur une fontaine à eau, distributeur en panne, problème
monnayeur, rupture de produit
1.2.7. Mobilier
o motifs : demande de mobilier, déplacement de mobilier, réparation de mobilier
1.2.8. Nettoyage - Propreté Hygiène
o motifs : demande de consommables sanitaires ( savon, essuie - mains, etc),

Dératisation / Désinsectisation, Désinfection, Enlèvement de cartons, Moquette
tachée, Nettoyage divers, Sanitaire sale, Vitre sale intérieure)
1.2.9. Déchets divers

o motifs : demande de bac confidentiel, demande de container papier, demande de
container pour DB (déchets banaux), Enlèvement container (CONIBI2) cartouches
imprimantes, enlèvement de containers papier, enlèvement de déchets divers
+verre, enlèvement des bacs confidentiels, vidage broyeur papier
1.2.10. Pause et plateau- repas
o motifs : Demande de pause, Demande de plateau- repas
1
Ce qui ne relève pas de la visioconférence

1.2.11. Transfert – Déménagement
o motifs : demande de cartons de déménagement, demande de déménagement,

Déplacement de cartons
1.2.12. Communication et information
o Publier des informations sur la vie des bâtiments ou les interventions

techniques en cours
Le besoin consiste à pouvoir informer les collaborateurs de tout événement relatif à
la vie du bâtiment ou à des interventions techniques déclenchées par les
équipes des BS, sur un site déterminé. A cet effet, les équipes des BS doivent
disposer de fonctions de diffusion et de publication de news.
o Mettre en ligne une bibliothèque de procédures ou de modes opératoires
Le besoin consiste à mettre à disposition des collaborateurs, ainsi que des
équipes des BS ou des équipes informatiques, tout type de document relatifs
aux procédures à appliquer. Il s’agit donc de pouvoir disposer des
fonctionnalités classiques de gestion de contenu (gestion des dates de début/fin
de mise en ligne, gestion d’archivage, référentiel documentaire, publication de
documents…)
1.3. Composition du Référentiel immobilier
En s’appuyant sur les fonctions du référentiel commun, le système d’information doit permettre de
suivre et gérer l’ensemble des implantations immobilières périmètre du présent contrat.
Ce référentiel devra intégrer :
La sémantique des sites et de leurs composants et mettre à disposition un glossaire,
L’organisation (structure) en immeubles, bâtiments, zones, niveaux,
Les principales caractéristiques des sites,
L’organisation du Groupe ENGIE et l’ensemble des structures sociales le composant,
L’ensemble des intervenants en lien avec le patrimoine géré,
Les baux gérés par les différents BS en tant que donneur ou preneur,
1.4. Référentiel des tiers et organisations
1.4.1. Généralités
La solution doit permettre de gérer un référentiel des tiers regroupant les entités, internes et
externes au Groupe, qui :
Sont propriétaires/locataires/copropriétaires d’un élément de patrimoine,
Occupent un élément de patrimoine,
Sont bailleurs d’un élément de patrimoine,

Interviennent sur un élément de patrimoine,

…
La solution doit permettre de décrire aussi bien :
Les entités (organisationnelles et structures juridiques) internes du Groupe,
Les personnes physiques/morales externes au groupe (propriétaire, bailleur, gestionnaires …)
Il doit être possible de positionner les tiers dans une structure arborescente (notion de hiérarchie) et
de décrire ainsi une organisation (interne ou externe au Groupe).
1.4.2. Avantages attendus de la solution :

Mettre à disposition l’information en même temps auprès de tous les utilisateurs ;
Passer outre les limites de capacité des messageries et en particulier la taille des pièces
jointes ;
Offrir une accessibilité optimale 24h/24 ;
Permettre un suivi des accès : qui, quand, quels documents sont ajoutés / consultés /
archivés / supprimés ;
Eviter les problèmes de coûts logistiques (déplacements, synchronisation des intervenants,
…) ;
Pour les documents qui ont une durée de validité limitée, être alerté de leur caducité à venir
via un système de workflow.
1.4.3. Exigences fonctionnelles et non fonctionnelles souhaitées (liste non

exhaustive) :
Avoir une solution permanente « virtuelle » permettant, l’échange, l’édition et la distribution
de documents (confidentiels ou non) ;
La solution doit présenter des mécanismes de chiffrement et de protection des données
permettant de se prémunir contre tout acte de malveillance ;
l’ensemble des actions réalisées au sein de la solution par les utilisateurs doivent être tracées
par cette dernière et accessible depuis un rapport spécifique ;
l’accès à cette solution se fera sur la base d’un accès centralisé et géré via la solution interne
OKTA
la solution doit être accessible depuis les terminaux suivants disposant d’une connexion
Internet (poste informatique, tablette, smartphone)
tous les formats de fichiers usuels (extension : PDF / Suite Microsoft Office / e-mails, …)
doivent être compatibles avec les fonctions d’import et d’export de la solution ;
avoir une fonction de recherche multicritères portant sur l’intitulé du document et son
contenu ;
avoir une personnalisation de la solution conformément à la charte graphique demandée par
le Groupe ;

des rapports permettant d’exporter un état récapitulatif de l’ensemble des documents

disponibles dans la solution, ou de suivre les différentes interactions survenues dans la
solution sont nécessaire (liste non exhaustive) ;
avoir la possibilité de donner des accès sur une période donnée (notamment pour les
utilisateurs externes au Groupe ENGIE) ;
le travail simultané doit être possible ;
un système d’alerte doit être disponible pour relancer le cas échéant la complétude
documentaire de certains dossiers ;
les guides utilisateurs et une assistance technique sont une nécessité.
1.4.4. Format
L’ensemble de ces informations devra être restitué sous format graphique exportable (suite MS
Office).
Le format devra permettre de filtrer les informations selon des axes :
Géographique :
o International,
o National,
o Régional,
o Local, site.
Organisationnel
o BS,
o Entités,
o Gestionnaire,
o Occupants,
o Propriétaire.

Annexes 2 : Respect des exigences de sécurité
2.1. Besoins de sécurité
2.1.1. Disponibilité des données
Le Prestataire devra préciser les dispositions techniques prises dans la mise en œuvre de sa solution
pour atteindre les niveaux de disponibilité (par exemple les mécanismes de clustering applicatif « à
chaud » et/ou les mécanismes de reconstruction applicative « à froid » prévus).
Le Prestataire devra préciser les dispositions techniques prises dans la mise en œuvre de sa solution
et les mécanismes prévus de sauvegarde et de restauration de données.
Une indisponibilité de 48 H est tolérée en cas de sinistre majeur. L’activité doit pouvoir cependant
être exécutée de manière dégradée.
2.1.2. Intégrité
Le Prestataire devra expliciter le mécanisme de détection de perte d’intégrité des données et le

mécanisme de correction proposé.
Les informations doivent rester intègres pendant la période d'utilisation.
2.1.3. Confidentialité
Le Prestataire devra expliciter les mécanismes de chiffrement des données, de gestion d’accès et de
cloisonnement entre les différentes données.
Les informations sont sensibles, elles sont diffusées ou accessibles par des populations ENGIE (accès
limité à des personnes ou à un groupe de diffusion bien définis).
La fuite des informations contenues dans l'application pourrait avoir des conséquences non
négligeables sur l'image du Groupe ENGIE.
2.1.4. Traçabilité
Le Prestataire devra préciser les fonctionnalités et mécanismes prévus dans sa solution permettant
de répondre à ce besoin de traçabilité.
Notamment, l’ensemble des actions utilisateurs sur les données doivent être tracées par l’outil et
doivent être rendues disponibles, soit directement dans l’interface utilisateur de l’outil, soit dans
l’interface administrateur, soit via une demande explicite de ENGIE au Prestataire, avec fourniture
des traces demandées sous 2 jours ouvrés (en particulier dans le cadre du traitement d’incidents).

2.2. Certifications sécurité du Prestataire
Le Prestataire mettra à disposition de ENGIE tous les documents (certification, rapport d’audit,
déclaration d’applicabilité, etc.) attestant de ses certifications en matière de sécurité (SAS 70, ISO
27001…) ainsi que de leurs périmètres.
2.3. Droit d’audit
ENGIE se réserve le droit d’effectuer, après avertissement préalable, les contrôles décrits ci-dessous,
par ses propres moyens ou par un Prestataire de son choix lié à ENGIE par un engagement de
confidentialité :
contrôle de sécurité applicative : exécution d’un outil contrôlant les interactions avec
l’utilisateur, notamment les formulaires, les fonctions d’authentification et tout autre
dispositif de sécurité assuré par l’application. Le contrôle sera effectué avant la mise en
production et répété en cas de livraison d’une nouvelle version majeure ;
contrôle de la sécurité de l’infrastructure : inspection du réseau et du système hébergeant
l’application grâce à un outil de scan de vulnérabilités. Le contrôle sera effectué à la mise en
production et répété tous les 3 mois ;
des tests d’intrusion : mise en évidence de l’impact de l’exploitation des vulnérabilités
présentes, au travers de scénarios d’attaque menés manuellement par des auditeurs. Le
contrôle sera effectué avant l’ouverture du service et renouvelé tous les 2 ans ;
une revue de l’hébergeur/éditeur : vérification de la maturité en matière de sécurité grâce à
un audit (sur la base du référentiel ISO 27002) portant sur les aspects organisationnels,
techniques, physiques, etc. Le contrôle sera effectué avant l’ouverture du service et
renouvelé tous les 2 ans.
Le Prestataire mettra à disposition toutes le ressources nécessaires afin de réaliser ces tests (moyens
humains, environnement de test, etc.).
Le Prestataire se devra de corriger les éventuelles vulnérabilités qui lui sont imputables (tierces
parties incluses), selon un planning qui sera défini en collaboration avec ENGIE.
Dans le cas où le Prestataire mandate des sociétés externes indépendantes pour la réalisation de ces
contrôles ou équivalents, il devra mettre à disposition de ENGIE leurs résultats, et ce afin de juger de
l’utilité de reconduire ces contrôles.
2.4. Responsabilités tierce partie
Le Prestataire devra s’engager à déclarer l’existence de sous-traitants et la nature des relations avec
ces derniers sur le plan des responsabilités. Les exigences de sécurité décrites dans ce document
s’appliquent également aux tierces parties du Prestataire.

2.5. Gestion des identités et des habilitations
Le Prestataire présentera les moyens permettant à ENGIE de réutiliser ses propres identifiants. Il
déterminera s’il est possible de faire de la fédération d’identité et les technologies employées dans
ce cas.
Le Prestataire détaillera également la gestion des comptes administrateur (applicatif et système) et

utilisateur :
la procédure de création/habilitation ;
la procédure d’inactivation et de révocation ;
les moyens mis à disposition pour effectuer la revue annuelle des habilitations ;
pour les comptes administrateur système, le processus de revue de leurs habilitations.
Il devra en particulier préciser s’il est possible d’avoir des habilitations d’administrateurs locaux (ex :
1 administrateur local ne peut créer des comptes que sur un périmètre donné, et par sur l’ensemble
du périmètre).
La solution devra offrir des mécanismes d’identification et d’authentification sécurisés (support du

protocole HTTPS pour l'authentification depuis les écrans utilisateurs), qui permettront de connaître
et de vérifier l’identité d’une entité (personne, système, …), afin d’autoriser ou non l’accès souhaité.
Le Prestataire proposera pour les utilisateurs une solution d’interfaçage sécurisé supportant
l’intégration en mode fédération (compatible SAML 2.0).
La fédération des identités utilisée par ENGIE est la solution groupe mise à disposition des
collaborateurs et partenaires ENGIE pour les accès aux applications.
Elle permet de gérer l’authentification des collaborateurs et Prestataires du groupe aux

applications Web éligibles.
Elle offre un service de Web SSO d’un point de vue utilisateurs entre les applications Web
raccordées au fournisseur d’identités groupe.
Le contrôle d’accès sera réalisé par le Prestataire au niveau de l’application. Le Prestataire précisera
également s’il est possible de mettre en place un filtrage d’IP pour ce périmètre d’utilisateurs ainsi
que les modalités d’administration de cette fonctionnalité. Les utilisateurs ne devront saisir qu’une
seule fois leur identifiant et mots de passe pour accéder, en fonction de leur profil et habilitation, aux
différentes fonctionnalités et/ou modules de la solution proposée.
La solution cible devra pouvoir assurer la gestion des mots de passe, dans le respect de la politique
sécurité de ENGIE.
2.6. Session
Il est nécessaire de prévoir une possibilité de clôturer des sessions inactives au bout d’un certain
délai (ce délai devra être paramétrable).

En revanche cette possibilité de clôture ne devra pas être obligatoire et pourra être levée de façon
simple.
Dans le cas d’une application Web, les cookies de session ne doivent pas contenir d’information
permettant de réaliser l’authentification de l’utilisateur.
Dans le cas d’une application Web, les cookies de session doivent être en mode «secure» dans le cas
des applications reposant sur le protocole HTTPS.
2.7. Contrôle d’accès

Le Prestataire expliquera comment il est possible de configurer son service afin de mettre en place
de l’authentification semi-forte. Exemples d'authentification semi-forte : certificat utilisateur,
certificat machine, OTP (One-Time Password) logiciel…
Le Prestataire exposera les moyens mis en œuvre pour protéger la confidentialité des données
d’authentification.
Le Prestataire doit appliquer sur tous les environnements (production, recette) dédiés à ENGIE une
politique de mot de passe respectant à minima les critères suivants :
Longueur : 8 caractères minimum (les mots de passe administrateurs peuvent être plus
longs) ;
Modification obligatoire au premier accès ;
Composition : lettres + chiffres + caractères spéciaux ;
Période de validité maximale : trois (3) mois avec alerte 1 semaine avant l’échéance ;
Contrôle sur historique : 4 derniers mots de passe ;
Nombre d’essais avant désactivation du compte : 7 essais.
2.8. Protection des données
ENGIE reste propriétaire des données qui seront intégrées dans la solution fournie par le Prestataire.
Le Prestataire présentera les moyens qui seront mis en œuvre pour assurer la protection des
données et notamment :
la transmission des données sur le réseau (ex : chiffrement) ;

le cloisonnement vis-à-vis de ses autres clients ;
le stockage des données en base (ex : chiffrement) ;
les processus de sauvegarde et la conservation des supports de sauvegarde (ex : périodicité,
lieux de stockage).
Le Prestataire devra mettre en place les dispositifs qui permettent d’assurer la protection des
données lors de leur transmission ainsi que lors de leur stockage (base de données, stockage,
sauvegarde, archivage). En particulier, tous les échanges de données ayant lieu sur Internet seront
chiffrés et les données devront obligatoirement être cryptées. Cette protection des données devra

être constamment en conformité avec les dispositions du droit applicable en la matière (droit
français).
2.9. Architecture sécurité
Le Prestataire décrira l’architecture de son système garantissant la sécurité des données de ENGIE
(firewall, IDS et autres équipements de sécurité). Il doit garantir qu’aucun serveur ou poste de travail
contenant des données de ENGIE ne sera connecté en direct sur Internet.
Les serveurs de production et les postes de travail doivent être à minima derrière un Firewall
permettant de filtrer les flux et de les protéger.
2.10. Journalisation des événements
ENGIE souhaite avoir un droit d’accès sur les événements ayant eu lieu sur son instance applicative
notamment dans le cas de traitement d’incidents. Ainsi, le Prestataire présentera ses capacités de
journalisation des événements tant sur les serveurs dédiés à ENGIE (ex : tâches d’administration) que
sur l’application (ex : actions utilisateurs). Il démontrera les capacités d’analyse et d’exploitation de
ces journaux.
2.11. Gestion des incidents et gestion de crise

Le Prestataire devra s’engager à signaler tout incident de sécurité qui pourrait avoir un impact au
service rendu à ENGIE. Il devra formaliser le processus de gestion de crise (notamment préciser les
canaux de communication mis en place avec ENGIE) et sa capacité à mettre en place une cellule de
crise en cas de besoin.
Enfin, le Prestataire présentera ses Plans de Continuité d’Activités et de Reprise d’Activités (PCA et
PRA).
2.12. Gestion des vulnérabilités
Le Prestataire devra justifier d’une procédure de patch management lui permettant de déployer
rapidement les correctifs recommandés par les fournisseurs de solutions matérielles et logicielles. Il
devra également présenter la solution antivirale qui sera déployée sur les serveurs hébergeant les
données de ENGIE.
2.13. Localisation des données
Les lieux d’hébergement des données doivent satisfaire aux exigences de sécurité physique de ENGIE
et aux dispositions de la loi du 6 janvier 1978 modifiée, relative à la protection des données
personnelles. Le Prestataire devra préciser la liste de tous les lieux de stockage des données de
ENGIE (site d’hébergement principal, sites de secours, etc.). Les lieux de stockage devront être
obligatoirement dans l’espace de l’UE.

Le Prestataire s’engagera à tenir informé ENGIE en cas de changement de localisation des données.
2.14. Gestion des évolutions
Le Prestataire présentera les moyens mis en œuvre pour suivre et formaliser les demandes
d’évolution émanant de ses clients.
Les évolutions fonctionnelles ou techniques ne devront pas remettre en cause le respect des
exigences de sécurité ou compromettre une éventuelle opération de réversibilité. Le Prestataire
devra vérifier que sa mise en œuvre est conforme aux exigences contractuelles et en apporter la
justification auprès de ENGIE, avant la validation de ce dernier.
2.15. Réversibilité
Le Prestataire décrira les moyens mis en œuvre pour assurer la réversibilité en fin de contrat ou suite
à l’activation de la clause de réversibilité, et notamment :
la manière dont seront restituées les données de ENGIE (ex : format, documentation, délai de
restitution) ;
les moyens permettant de s’assurer de la sécurité des données lors de la restitution ;
les procédures permettant de s’assurer de la destruction définitive de ces données sur les
environnements du Prestataire et de ses tierces parties.
2.16. Anti-virus et programme malveillant
Le Prestataire s’engage sur le fait que la solution logicielle et les prestations sont exemptes de virus
et/ou de programme malveillant. Les serveurs et postes d’administration posséderont un anti-virus
activé, correctement configuré et mis à jour très régulièrement (au moins 1 fois par jour).
2.17. Veille
Le Prestataire assure une veille sécurité sur les OS et les applicatifs sur les serveurs et postes
d’administration.
2.18. Gestion des patchs de sécurité
Le Prestataire devra disposer et appliquer une politique de gestion des patchs de sécurité formalisée
et appliquée avec rigueur. Cette politique sera transmise à ENGIE.
2.19. Destruction des données
En fin de projet, le Prestataire détruira ou effacera de manière sécurisée les données, sans en
conserver de copies à l’exception de toute obligation légale sur le sujet, appartenant à ENGIE

contenues sur quelques supports que ce soit en sa possession et/ou celle de ses préposés et/ou sous-
traitants et cotraitants.
Un Procès-verbal d’effacement ou de destruction doit être établi et transmis à ENGIE sous un délai
de deux jours calendaires à compter de sa rédaction.
2.20. Journaux systèmes et applicatifs
Le Prestataire fournira sur demande une copie des journaux applicatifs relatifs au service fourni.
Toute modification dans l’application, avec historique et nom d’utilisateur à l’origine de la
modification, pourra être identifiée.
Le « dossier sécurité » ainsi que le résultat de l’audit sécurité sont des éléments nécessaires à la
validation de la solution avant mise en production.
2.21. Synthèse des exigences
Le tableau ci-contre présente les exigences pour l’Axe « Respect des besoins en sécurité » :
Exigence Description
Gestion des droits d'accès Les propriétaires d'informations doivent mettre en

place un processus d'habilitation, dont les règles
devant respecter le principe du moindre privilège
sont communiquées aux utilisateurs.
Suivi des habilitations Une revue d'habilitations doit être réalisée au
moins une fois par semestre.
Traçabilité des identités Les opérations sur les identités utilisateurs sont
tracées dans le respect de la législation locale
Traçabilité des accès - tracer les succès et échecs de connexion
- tracer les accès réseau
- durée de rétention des journaux de minimum 6
mois
- centraliser les journaux et procéder à des
vérifications régulières
Authentification Mettre en place de l'authentification semi-forte.
Exemples d'authentification semi-forte : certificat
utilisateur, certificat machine, OTP (One-Time
Password) logiciel…
Les flux d'authentification doivent être chiffrés.
Comptes administrateur Tous les administrateurs techniques doivent avoir
un compte administrateur dédié (de type login/mot
de passe) différent de leur compte utilisateur
personnel usuel.
Ces comptes administrateur doivent être gérés
comme décrit dans le contrôle INCOME ITM5C090-
C2.
Les flux d'administration doivent être chiffrés.
Séparation des tâches Les administrateurs de l'infrastructure IT technique
doivent être différents des administrateurs de

l'application des SI (Cf. ITM5C090-C1).

Protection des données Mettre en place du chiffrement pendant la
transmission des données, ainsi que sur les serveurs
de production et de sauvegardes.
Destruction des informations Processus formalisé garantissant que les données
sont détruites de façon sécurisée à la fin de leur
durée de vie, avec un rapport formel de
destruction, ainsi qu'en fin de contrat. La mise au
rebus du matériel contenant des informations
(exemple : disques de baies de stockage) doit se
faire également de façon sécurisée (exemple :
destruction physique des disques).
Engagement de confidentialité Les fournisseurs doivent signer un accord de
confidentialité.
Recette de sécurité applicative Réaliser une recette de sécurité applicative avant la
mise en production.
Revue de sécurité de l'hébergeur Réaliser une revue de sécurité de l'hébergeur.
Contrôle sécurité des points de présence Réaliser des scans de vulnérabilités à l'aide de l'outil
adapté
Veille L'hébergeur/éditeur effectue une veille sécurité sur
les OS et applications installés sur les serveurs et
postes de travail hébergeant des données de ENGIE.
Alerte et traitement d'incidents Processus de gestion des incidents et des crises
chez l'hébergeur et l'éditeur, tel que décrit dans la
politique, vous permettant d'être informé de tout
incident sur un équipement sous leur responsabilité
Antivirus Les fichiers déposés dans l'application sont scannés
par un antivirus.
Gestion de crise et reprise d'activité L'éditeur doit rédiger un plan de gestion de crise et
mettre en œuvre un plan de reprise d'activité avec
ses hébergeurs.
Référentiel Prise en compte des référentiels Sécurité ENGIE

Annexes 3 : Respect des besoins IT (Techniques)
3.1. Cadre de cohérence technique général
3.1.1. Architecture générale du système d’information ENGIE

ENGIE a fait le choix d’une application de type SaaS (Software As A Service) afin de faciliter le
déploiement dans ses entités. Aucun environnement ne sera hébergé dans les infrastructures du
groupe ENGIE.
Le Prestataire doit décrire comment il gère la configuration logicielle (versioning...) de la solution et

de chaque environnement.
Le réseau de ENGIE est constitué de bulles métiers permettant aux différentes B.U. (Business Units)
d’interconnecter leurs réseaux informatiques.
Les accès depuis l’extérieur ne sont autorisés que via une DMZ externe.
Des accès distant sécurisés (ADS) peuvent également être envisagés selon la population ciblée. Ils
permettent de se connecter de manière sécurisée aux systèmes d'information de ENGIE
Dans tous les cas, les accès aux applications doivent respecter a minima, la Politique Groupe Sécurité
SI et la politique des accès internet sécurité de ENGIE dans le référentiel sécurité SI.
Les messages clés sont :
L’ensemble des flux doit être contrôlé et analysé ;

Des zones d’échange avec limitation des flux doivent être mises en place entre réseau
interne et Internet ;
Les accès Internet doivent être authentifiés et tracés ;
Un filtrage d’URL doit être mis en place ;
L’administration des infrastructures doit se faire via un réseau dédié ;
La haute disponibilité des infrastructures est recherchée.
Le Prestataire s’engage à fournir une solution satisfaisant l’ensemble des exigences métier,
fonctionnelles, applicatives et techniques exprimées dans le présent Cahier des Charges en
respectant les contraintes et le cadre présenté. En cas d’incompatibilité du niveau d’engagement
demandé avec le cadre présenté, le Prestataire devra proposer les évolutions à prévoir et des
moyens pour les adresser. Si des demandes de dérogations aux politiques applicables sont
nécessaires, ces justifications seront indispensables pour décider de la durée de validité de ces
dérogations si elles sont accordées.

3.1.2. Description des postes ENGIE et des contraintes applicatives
La description des postes ENGIE (configuration standard = environ 50 % du parc) est fournie ci-après :
Postes Plimpot (périmètre historique France)
Critère Caractéristique Versions Remarque

minimales
Système Windows VISTA SP1

d’exploitation
Ecran Pas de contrainte Utilisation de la résolution 1024X768

de taille
CPU Dépend du Le produit doit fonctionner sur CPU de type « Pentium III
matériel 600 Mhz » a minima
Mémoire Dépend du Le produit doit fonctionner à partir de 1 Go de mémoire

matériel RAM.
2 gigas
Bureautique Microsoft Office 2007 SP1 Le format d’échange de documents bureautiques

version Pro+ retraitables doit être «Office 2007 ». Le kit de
Standard compatibilité Office 2000/2007 est également installé
Groupware / Exchange/Outlook 2007 Le parc est en cours d’évolution vers Exchange Outlook
Messagerie 2013 la solution doit être compatible
Lotus
Navigateur Internet Explorer, IE 7 SP1

Google Chrome
Machine virtuelle JRE 6u3 Seule version compatible sous Vista à cette date
JAVA
Plug-in Flash Version Ce « plug-in » standard est installé sur l’ensemble des
(Macromedia) 9.0 souches de base des postes de travail.

Postes UWP2 (périmètre historique Belgique)

minimales
Système d’exploitation Windows XP SP3
Utilisation de la résolution 1024X768

Ecran
Dépend du
CPU Intel Pentium III Xeon Processor minimum
matériel
Dépend du
Mémoire 2 Gbs minimum
matériel
Microsoft Office
Bureautique 2007 SP3
Professional
Groupware / Server: Exchange

2007 / 2013
2007 SP3
messagerie Client: Outlook
8
Internet Explorer
Navigateur 46.0.2490.71
Google Chrome
m
Machine virtuelle Montée de version prévue vers la dernière version

Java Runtime 1.7.0.55
Java 7
Java
28% have 19.0.0.207 installed as latest version

Flash ActiveX At least
Plug-in 62% have 19.0.0.226 installed as latest version
Flash Player 19.0.0.207
10% have 19.0.0.245 installed as latest version

Futur Poste Skynote v3 (déploiement prévu en 2016-2017)

minimales
Système Windows 7
d’exploitation
Ecran Pas de contrainte Utilisation de la résolution 1024X768

de taille
CPU Dépend du 2 Ghz minimum

matériel
Mémoire Dépend du
matériel
4 Gigas minimum
Bureautique Microsoft Office 2007 Le format d’échange de documents bureautiques

version Pro+ minimum retraitables doit être «Office 2007 ». Le kit de
Standard compatibilité Office 2000/2007 est également installé
2013/2013
possible
Groupware / Exchange/Outlook 2007 Le parc est en cours d’évolution vers Exchange Outlook
Messagerie 2013 la solution doit être compatible
Lotus
Navigateur Internet Explorer, IE 10
Machine virtuelle JRE 7

JAVA
Plug-in Flash Version 15 Ce « plug-in » standard est installé sur l’ensemble des
(Macromedia) souches de base des postes de travail.
Nota : d’autres logiciels sont présents sur les postes (compression, antivirus, Acrobat Reader, chiffrement de
données (Security Box)….) ; ils ne sont pas mentionnés ici, n’ayant pas d’impact sur les choix des logiciels «
métiers » en particulier et/ou sur les développements spécifiques aux postes de travail.
Le Prestataire devra également présenter la compatibilité de sa solution avec les principaux

navigateurs du marché, en indiquant les versions supportées (Internet Explorer, Firefox, Chrome et
Safari notamment).

D’autre part, il est explicitement demandé que la solution proposée soit compatible avec Internet
Explorer IE7, IE8, IE9 et IE10, ainsi que Google Chrome.
Le parc des postes de travail est en cours d’évolution, le Prestataire devra également indiquer la
compatibilité de sa solution avec le socle applicatif suivant le système d’exploitation Windows 7 avec
le pack linguistique FR / EN /ES / DE / NL / IT,
Microsoft Office 2007,

le navigateur Internet Explorer (IE 10) ainsi que les « plugins » (Flash et Silverlight),
des environnements d’exécution (« runtime ») : Microsoft Dotnet, Visual C++, Java JRE 7,…
ENGIE met en place un certain nombre de moyens pour protéger les informations transitant sur ses
systèmes d'information. Certains sont obligatoires et directement mis en place. C'est le cas par
exemple de l'antivirus ou de l'outil de détection d'intrusion. Certains paramétrages peuvent conduire
à bloquer des applications.
Le Prestataire devra préciser tous les protocoles et applications nécessaires sur le poste de travail
indispensables à l’utilisation de la solution afin de vérifier la compatibilité avec les systèmes de
protections. Par exemple, un filtrage des Applets JAVA est activé sur les sites internet qui n’ont pas
été spécifiquement autorisés. Les postes de travail des utilisateurs ENGIE sont protégés par la mise
en œuvre de stratégies systèmes qui restreignent les droits d’accès au système de fichiers des
postes. En conséquence, les applications doivent respecter les contraintes suivantes :
Aucune écriture ne doit être effectuée dans les répertoires systèmes, ni dans les parties
«systèmes » de la base de registre des postes ;
L’installation des produits doit être indépendante de l’architecture interne de la machine
(organisation des disques de données, …) ; les répertoires d’installation doivent donc être
paramétrables ;
L’utilisation d’applet est possible. L’utilisation de contrôles "active X" est quant à elle
restreinte; seuls les « active X » Microsoft signés sont acceptés. L’utilisation d’ « Internet
Explorer » doit se faire sans mise en œuvre de greffons particuliers.
3.2. Architecture
ENGIE fait le choix d’une solution SaaS, le Prestataire doit s’assurer que le dimensionnement de son
infrastructure répond au besoin de service de ENGIE. Il pourra indiquer comment le
dimensionnement de l’infrastructure mis en œuvre pour la solution répond à ses préconisations
techniques.
3.2.1. Exigences d’hébergement
Le Prestataire proposera des solutions adaptées au mode SaaS, en cohérence avec les exigences de
ENGIE en termes de sécurité et d’architecture.

Dans le cas d’un hébergement externalisé :
La localisation des serveurs doit être indépendante de la localisation des postes de travail ;
Les serveurs de données, de traitement, de sauvegarde doivent être installés dans des sites
d'exploitation spécialisés ;
Les produits d’exploitation et d’administration sont du ressort et dépendent de l’hébergeur.
Dans ce contexte, il est nécessaire de décrire les solutions de sauvegarde, de surveillance et
de planification mises en œuvre ;
Les processus de traitement, de contournement ou d’attente en cas d’indisponibilité de
l’application, seront décrits, dans un plan de continuité de service (PCS).
3.2.2. Accessibilité
L’accès à l’application ne doit nécessiter aucune modification :
De l’infrastructure intranet du groupe ENGIE et de ses filiales,

De l’ensemble des équipements réseaux de ENGIE et de ses filiales (routeurs, switchs),
De l’ensemble des postes de travail ou des PC personnels (hors éventuels plug-ins).
Un filtrage IP pourra être mis en place pour limiter l’accès à l’application qu’à partir du réseau
interne ENGIE.
3.3. Echanges
Aucun flux entrant de l’internet n’est autorisé sur l’intranet. Les acquisitions de données utiliseront
impérativement un flux chiffré. En outre, aucun flux direct de l’interne vers l’externe n’est permis, les
flux devant être obligatoirement relayés par un ou plusieurs proxies en DMZ.
Ces passerelles applicatives sont susceptibles de faire des contrôles avancés sur le contenu qui y
transite. Les structures de données doivent donc être parfaitement spécifiées et aucune technique
de chiffrement non standard ne pourra être utilisée.
De manière générale, les flux vers l’externe doivent être déclenchés à l’initiative d’un composant
interne, et non l’inverse. Néanmoins, l’ouverture d’autres flux supplémentaires à ceux déjà permis et
contrôlés, doit être signalée dans la réponse technique pour évaluer les conséquences sur la sécurité
de notre réseau.
Il est souhaitable que les interrogations vers les serveurs de données externes utilisent des
protocoles de Web services s’appuyant sur https tels que :
XML pour les échanges de données,

SOAP pour les transactions inter-applicatives,
WSDL pour la description de services.
Toute utilisation d’un autre protocole fera l’objet d’une étude préalable de sécurité de notre part.

3.3.1. Echanges réseaux
La famille des protocoles TCP/IP et UDP/IP est la seule autorisée à l’intérieur du réseau ENGIE, les
numéros de ports IP doivent être standards et paramétrables afin de permettre la gestion des
priorités de trafic sur le réseau des Entreprises.
Tous les flux sont identifiés et déclarés pour l’ensemble des plates-formes (développement,
intégration qualification, pré-production et production) auprès de l’O.S.T. (Opérateur Sécurité et
Télécom). Cette déclaration est réalisée par la fourniture d’une « matrice des flux » intégrée au
Dossier d’Architecture Technique présenté en comité de validation technique de la DSI centrale
ENGIE.
Les flux autorisés en interne seront, entre autres :
Les flux SQL Net (Oracle)

Les flux MySQL
Les flux http
3.3.2. Serveur mail

Le Prestataire devra préciser les configurations possibles de leur serveur de mail pour permettre
l’envoi de mail par sa solution.
3.3.3. Export de données
La solution devra permettre la réalisation d'exports simples de données par des applications externes
(XML, SQL, Office, en particulier Excel, ...).
3.3.4. Plateforme d’échanges
Le Prestataire devra préciser s'il dispose d'une plate-forme d'échange sécurisée avec ses clients ou
d'un autre mécanisme de gestion de flux (avec suivi et traçabilité des flux entrants/sortants
accessible à ENGIE). S'il dispose d'une telle plate-forme, le Prestataire précisera obligatoirement
quels protocoles peuvent être utilisés.
3.3.5. API et connecteurs
Le Prestataire devra préciser si des API/connecteurs (JDBC, JMS, …) permettent de s’interfacer avec
la solution. Si oui, le Prestataire précisera si certains de ces API/connecteurs prennent la forme de
services WEB. Dans tous les cas, le Prestataire devra les lister avec précisions et exhaustivement.

3.3.6. Interfaces avec d’autres SI
La solution devra se baser sur les standards d’interopérabilité du marché (XML, fichiers plats,...) leur
permettant de mettre facilement en œuvre de nouvelles interfaces avec des applications internes ou
externes au SI ENGIE.
Le Prestataire devra préciser si la solution a déjà été interfacée avec des solutions de type ETL, EAI
ou ESB et si oui, précisera lesquelles.
3.3.7. Chiffrement des données

Le Prestataire, présentera les solutions de chiffrement et de protection des données utilisées dans sa
solution.
3.3.8. Sauvegardes
Le Prestataire devra préciser comment sont gérées les sauvegardes, les purges et les archivages
(modalités de paramétrage, possibilité d’automatisation, sauvegardes sur disques, sur bandes,
externalisation, ...) et selon quelle fréquence.
Les sauvegardes seront conservées et disponibles pendant une certaine durée (encore à définir). Le
Prestataire fournira une estimation du volume des sauvegardes et de la durée totale.
3.3.9. Documentation technique
Le Prestataire doit fournir au minimum les documentations techniques suivantes :
Documentation d’Architecture Technique (DAT),

Documentation d’Exploitation et d’administration technique. Elle décrit tout ce qui est
nécessaire au bon fonctionnement de la solution et à son administration technique (dont les
traitements et les interfaces)
Documentation du Plan de Reprise d’Activité
3.4. Exigences sur les performances
3.4.1. Exigences sur les performances de l’Interface Homme-Machine (IHM)

Le temps moyen des transactions (passage d’un écran à un autre, affichage d’un résultat,
rafraîchissement d’un écran, …) doit être inférieur à 2 secondes dans 95% des cas.
Le temps moyen de connexion au système (affichage de l’écran d’accueil) doit être inférieur à
5 secondes dans 95% des cas.
Remarque : Les performances attendues sur l’IHM concernent uniquement le passage d’un écran ou
pop-up de l’application à un autre écran ou pop-up de l’application. Le Titulaire s’engage à remettre
un rapport à la demande de ENGIE pour le calcul de ces performances.

3.4.2. Exigences sur les performances des traitements
Le temps moyen des traitements doit être inférieur à 10 minutes dans 95% des cas.
Le Titulaire s’engage à remettre un rapport à la demande de ENGIE pour le calcul de ces

performances.
3.4.3. Exigences sur les performances des requêtes
Le temps moyen d’exécution des états et des requêtes doit être dans 95 % des cas :
Inférieur à 30 secondes dans le cas d’états et requêtes dits simples,

Inférieur à 5 minutes dans le cas d’états et requêtes dits moyens,
Inférieur à 15 minutes dans le cas d’états et requêtes dits complexes.
Le Titulaire s’engage à remettre un rapport à la demande de ENGIE pour le calcul de ces
performances.
3.4.4. Synthèse des exigences
Le tableau ci-contre présente les exigences pour l’Axe « respect des besoins IT» :
Exigence Description
Le prestataire devra fournir la description de

l'architecture applicative de la solution cible (n-tiers
ou autres ...), détailler chacune des briques
Architecture applicative applicatives constituant la solution et fournir les
principes généraux de fonctionnement de la solution.
En particulier, la manière dont seront gérées les

instances applicatives et de bases de données
(mutualisées, dédiées, ...).
La solution devra se baser sur les standards

d’interopérabilité du marché (XML, fichiers plats, ...)
leur permettant de mettre facilement en œuvre de
nouvelles interfaces avec des applications internes ou
Ouverture sur les autres systèmes et standards externes au SI ENGIE. Cette ouverture devra
d'interopérabilité également se traduire :
- par des accès aux API documentés ;

- par des modèles de bases de données clairs,
communiqués et accessibles (en lecture et
éventuellement en écriture, règles d’intégrité
connues, …).
Le système devra être basé sur une architecture

Scalabilité extensible (dite aussi « scalable ») de façon à
accepter sans contrainte particulière (hors
modifications d’architecture technique) une
croissance du volume des données gérées et/ou du

nombre d'utilisateurs.
Le système sera dimensionné initialement pour

répondre aux besoins métiers identifiés et pourra
recevoir de manière additionnelle des ressources
informatiques supplémentaires, sans nécessité de
passer par une nouvelle phase de conception pour
l’exploitation. Cet ajout de ressources devra être
rapide et sans impact sur les applications existantes,
ce qui suppose des architectures logicielles
évolutives.
Serveur Mail Le prestataire devra préciser si un serveur mail sera

fourni pour permettre l'envoi de mail.
La solution devra permettre la réalisation d'exports

Exports de données
simples de données par des applications externes
(XML, SQL, Office, en particulier Excel, ...).
Le prestataire devra préciser s'il dispose d'une plate-

forme d'échange sécurisée avec ses clients ou d'un
Plate-forme d'échange
autre mécanisme de gestion de flux. S'il dispose d'une
telle plate-forme, le prestataire précisera quels
protocoles peuvent être utilisés.
Le prestataire devra préciser si des API/connecteurs

(JDBC, JMS, …) permettent de s’interfacer avec la
API et connecteurs
solution. Si oui, le prestataire précisera si certains de
ces API/connecteurs prennent la forme de services
WEB.
Interfaçage avec d'autres solutions de gestion des Le prestataire devra préciser si la solution a déjà été
échanges ou des SI externes interfacée avec des solutions de type ERP ou non ERP
ou des outils Décisionnel
Les infrastructures d'hébergement devront respecter

les différentes politiques sécurités du groupe ENGIE
Hébergement
(isolement physique, isolement logique,
administration et monitoring, chiffrement, audit, site
de secours, sécurité des sites, ...).
Documentation Le prestataire devra fournir l'ensemble des

documents techniques demandés.
Performance
Cf. Paragraphe concerné
3.5. Accès mobile
L’accès via mobile (BBY, iPhone, Android, iPad) aux applications du groupe est un besoin émergent
au sein de ENGIE.

A ce titre, la solution mobile (mail ou application dédiée) devra a minima permettre la validation ou
le refus des demandes, commandes et réceptions par les valideurs hiérarchique, budgétaire,
technique, gouvernance.
Le Prestataire pourra également préciser les autres fonctionnalités accessibles via mobile en natif
disponibles pour son application.

CDC - Di - Engie V1

Transféré par

Droits d'auteur :

Formats disponibles

CDC - Di - Engie V1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CDC - Di - Engie V1

Transféré par

Droits d'auteur :

Formats disponibles

– Mise en place d’une solution de traitement des demandes d’interventions techniques et services -

MISE EN PLACE D’UNE SOLUTION DE GESTION DES

CAHIER DES CHARGES

Version Expressions Besoins Utilisateurs

Cahier des charges 1 / 49

CAHIER DES CHARGES ...................................................................................................................................... 1

1.1. ENJEUX ET OBJECTIFS ................................................................................................................................... 5

2. ATTENTES FONCTIONNELLES .................................................................................................................... 8

3. ATTENTES TECHNIQUES ........................................................................................................................... 9

3.1. ACCES A LA SOLUTION.................................................................................................................................. 9

4. PHASE PROJET, LIVRAISON ET RECETTE .................................................................................................. 14

4.1. GROUPE DE PROJET ENGIE ........................................................................................................................ 14

5.1.1. COMITE DE PILOTAGE PHASE RUN ........................................................................................................... 18

ANNEXE 1 : LOT 1 SYNTHESE DES DONNEES OPERATIONNELLES A INTEGRER ................................................. 21

Cahier des charges 2 / 49

1.1. COMPOSITION DU REFERENTIEL IMMOBILIER .................................................................................................. 21

ANNEXES 2 : RESPECT DES EXIGENCES DE SECURITE ....................................................................................... 31

2.1. BESOINS DE SECURITE ................................................................................................................................ 31

Cahier des charges 3 / 49

2.9. ARCHITECTURE SECURITE............................................................................................................................ 35

ANNEXES 3 : RESPECT DES BESOINS IT (TECHNIQUES) .................................................................................... 39

3.1. CADRE DE COHERENCE TECHNIQUE GENERAL .................................................................................................. 39

Cahier des charges 4 / 49

1.1. Enjeux et objectifs

Cahier des charges 5 / 49

Solution intégrant nativement des fonctionnalités permettant de générer des états de

1.3. Références actuelles d’utilisateurs et de demandes d’interventions

Cahier des charges 6 / 49

1.4. Solutions recherchées

Le périmètre du projet inclut :

1.5. Planning prévisionnel de la consultation et de mise en place des

Ateliers de définition des besoins utilisateurs Mars – avril 2017

Spécifications techniques et fonctionnelles Mai – juin 2017

Recette et reprises des données Juillet 2017

Reprise des données et mise en œuvre en parallèle Septembre 2017

Mise en production mi-octobre 2017

Cahier des charges 7 / 49

2.1. Fonctionnalités majeures attendues de la solution

2.2. Principales prestations :

Les prestations techniques :

Les prestations de services :

Le détail des prestations est mentionné en annexe 1.

Cahier des charges 8 / 49

3.1. Accès à la solution

3.2. Ergonomie et intuitivité

Cahier des charges 9 / 49

Saisie simplifiée des dates possible (ex.: 230614 pour 23/06/2014)

3.3. Gestion des habilitations

Cahier des charges 10 / 49

3.4. Recherche / Consultation des données

3.5. Export des données de la base

3.6. Historisation des données

La solution doit conserver l’historique de toutes les données afin de permettre :

Cahier des charges 11 / 49

Non modifiables par les utilisateurs.

3.8. Aide en ligne

3.9. Capacité d’ouverture et facilité d’intégration

Cahier des charges 12 / 49

3.11. Transfert, initialisation des données et exports.