1 ville de nanterre fourniture, mise en œuvre, parametrage et

VILLE DE NANTERRE
FOURNITURE, MISE EN ŒUVRE, PARAMETRAGE ET MAINTENANCE D’UNE SOLUTION
INFORMATIQUE DE GESTION DES FILES D’ATTENTES ET D’ORGANISATION DE
L’ACCUEIL
CAHIER DES CLAUSES TECHNIQUES PARTICULIERES
(C.C.T.P.)
1
1
OBJECTIF DU MARCHE
4
2
ORGANISATION DE LA MAÎTRISE D’OUVRAGE
5
3
FORMALISME ET TERMINOLOGIE
6
3.1
3.2
3.3
NIVEAUX D’ACCUEIL
SITES ET ROLES DES AGENTS
FORMALISME FONCTIONNEL
6
6
7
4 ORGANISATION DE L’ACCUEIL ET EVOLUTIONS DU CHANTIER ACCUEIL A LA VILLE
DE NANTERRE : CONTEXTE DE L’ACQUISITION DE L’OUTIL
10
4.1 ACCUEIL PREVU DANS LE CADRE PROJET
4.1.1 EVOLUTIONS DE L’HOTEL DE VILLE
4.1.2 IMPACTS ORGANISATIONNELS
4.2 EVOLUTIONS EN REFLEXION
10
10
10
10
5
11
EXIGENCES FONCTIONNELLES
5.1 EXIGENCES FONCTIONNELLES GENERALES
Exigence 1 : Paramétrage des rôles
Exigence 2 : Evolutivité
Exigence 3 : Calcul des délais d’attente
5.2 EXIGENCES FONCTIONNELLES MODULE PRE-ACCUEIL
Exigence 4 : Enregistrement simple de visiteur
Exigence 5 : Edition de ticket d’attente
Exigence 6 : Gestion des démarches groupées
5.3 EXIGENCES FONCTIONNELLES MODULE ACCUEIL
Exigence 7 : Appel d’Usager
Exigence 8 : Enregistrement du motif de précision
Exigence 9 : Historisation des prises en charge
Exigence 10 : Transfert d’usager
5.4 EXIGENCES FONCTIONNELLES MODULE RENDEZ-VOUS
Exigence 11 : Paramétrage des rendez-vous
Exigence 12 : Prise de Rendez-vous
Exigence 13 : Gestion des Rendez-vous
Exigence 14 : Intégration dans l’outil de gestion du centre d’appel
5.5 EXIGENCES FONCTIONNELLES MODULE CONDUITE DE L’ACCUEIL
Exigence 15 : Visualisation de la situation d’accueil en temps réel
Exigence 16 : Seuils d’alerte
5.6 EXIGENCES FONCTIONNELLES MODULE STATISTIQUES
Exigence 17 : Accès au module de statistique
Exigence 18 : Fiabilité des données
Exigence 19 : Requêtes
Exigence 20 : Edition de Rapports Statistiques
5.7 EXIGENCES FONCTIONNELLES MODULE GESTION DE L’AFFICHAGE
Exigence 21 : Appel des Usagers
Exigence 22 : Intégration avec l’outil d’affichage multimédia
5.8 AUTRES FONCTIONNALITES
Exigence 23 : Fonctionnalités supplémentaires
5.9 PERIMETRE UTILISATEUR
11
11
11
11
11
11
11
11
12
12
12
12
12
12
12
12
12
12
13
13
13
13
13
13
13
13
13
13
14
14
14
14
2
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
ENVIRONNEMENT INFORMATIQUE
LES SERVEURS
CONFIGURATION DE BASE DES POSTES DE TRAVAIL
LE COMPTE UTILISATEUR
LES BASES DE DONNEES
LES SAUVEGARDES
LE RESEAU
LA TELEMAINTENANCE SERVEUR ET POSTE DE TRAVAIL
SALLE DE FORMATION
15
15
15
15
15
15
16
16
16
7 EXIGENCES TECHNIQUES D’INTEROPERABILITE ET D’INSERTION DANS LE SYSTEME
D’INFORMATION DE LA VILLE DE NANTERRE
17
7.1 EXIGENCES D’INTEROPERABILITE AVEC LES APPLICATIONS DE LA VILLE DE NANTERRE
17
Exigence 24 : Format des échanges
17
7.2 EXIGENCES TECHNIQUES RELATIVES AUX POSSIBILITES DE CENTRALISATION TECHNIQUE ET AU
FONCTIONNEMENT EN MODE DEGRADE
17
Exigence 25 : Définition de l’architecture de la solution
17
7.3 EXIGENCES TECHNIQUES RELATIVES A L’ACCES A L’APPLICATION
17
Exigence 26 : Raccordement technique client/serveur
17
7.4 EXIGENCES SUR LES REGLES D’EXPLOITATION DE LA DSIT
17
Exigence 27 : Automatisation des sauvegardes
17
Exigence 28 : Supervision applicative
17
8
EXIGENCES DE MATERIELS ET FOURNITURES
18
8.1 FOURNITURES COUVERTES PAR LA VILLE DE NANTERRE
Exigence 29 : Description des besoins du prestataire
8.2 FOURNITURES COUVERTES PAR LE PRESTATAIRE
Exigence 30 : Imprimantes de tickets
Exigence 31 : Licences applicatives
Exigence 32 : Ecrans d’appel
18
18
18
18
18
19
9
20
EXIGENCES D’ACCOMPAGNEMENT
9.1 EXIGENCES D’INSTALLATION
Exigence 33 : Configuration, installation et déploiement de l’application
9.2 EXIGENCES DE PARAMETRAGE
Exigence 34 : Paramétrage de l’application
9.3 EXIGENCES DE FORMATION
Exigence 35 : Formations
9.4 EXIGENCES D’ASSISTANCE AU DEMARRAGE
Exigence 36 : Assistance au démarrage
20
20
21
21
21
21
21
21
10 EXIGENCES DE GARANTIE ET MAINTENANCE
22
10.1 PERIMETRE DE LA GARANTIE
Exigence 37 : Garantie
10.2 PERIMETRE DE LA MAINTENANCE
Exigence 38 : Maintenance
10.3 GESTION DES INCIDENTS
Exigence 39 : Gestion des incidents
22
22
22
22
23
23
3
1 OBJECTIF DU MARCHE
Le présent marché vise à l’acquisition d’une solution informatique de gestion de l’accueil, dont la
fonctionnalité principale est la gestion des files d’attente.
La solution doit couvrir le périmètre suivant :
•
La gestion des files d’attente (distribution de ticket à l’usager en fonction de sa démarche
administrative, puis appel de cet usager par le guichet adapté pour répondre à sa demande) ;
•
La gestion et la supervision en temps réel par les responsables de l’accueil (envoi de renfort
en cas d’affluence, etc.) ;
•
Une gestion multi-site, c'est-à-dire avec des sites d’accueil déconcentrés, tout en assurant la
continuité du service en cas d’altération technique ;
•
L’adaptation à l’organisation actuelle de l’accueil mais aussi à ses évolutions à venir par sa
souplesse et son paramétrage ;
•
L’édition complète de statistiques sur les données de l’accueil :
données quantitatives telles que l’affluence, l’affluence par démarche,
l’affluence par période, etc. ;
données qualitatives telles que le temps moyen d’accueil, le temps moyen
d’accueil par démarche, etc. ;
données consolidées globales, par site d’accueil, etc. ;
•
La gestion de la prise de rendez-vous ;
•
La gestion d’un affichage évolué d’information sur l’accueil (temps d’attente, appel de
numéro d’accueil, etc.) mais aussi de pouvoir diffuser des informations multimédia en
s’interfaçant avec la solution de gestion d’affichage dynamique de la Ville de Nanterre.
La solution proposée gère de multiples sites d’accueil, tout en étant techniquement centralisée. Elle s’adapte
aux contraintes techniques de chaque site décentralisé, et assure de la continuité du service d’accueil en cas de
dysfonctionnement de l’infrastructure.
Les prestations d’installation, de paramétrage, d’accompagnement à la mise en œuvre, la formation des
utilisateurs et la maintenance sont également incluses dans le marché.
La solution informatique de gestion de l’accueil et des files d’attente doit être ouverte sur la bureautique,
conviviale et ergonomique, et permettra de :
•
s’adapter à l’organisation de l’accueil et à toutes ses possibles évolutions à venir, c'est-à-dire avoir
des possibilités étendues de paramétrage ;
•
optimiser la gestion de l’accueil de la Ville de Nanterre ;
•
disposer de tableaux de bord, d’indicateurs, de statistiques ;
•
s'intégrer dans le réseau informatique de la Ville et en conséquence, de bénéficier des services qui y
sont associés (sauvegarde, intervention à distance).
4
2 ORGANISATION DE LA MAÎTRISE D’OUVRAGE
Le maître d’ouvrage (MOa) est la Ville de Nanterre dont les services intervenant au titre du présent
marché sont organisés comme décrits ci-après.
La Direction de l’Accueil Logistique assure la MOa. Le service Accueil Général qui assure le pré-accueil
fait partie de cette direction. Le centre d’appel, qui aura la possibilité de prendre des rendez-vous, fait aussi
partie de cette direction.
Les autres Directions listées ci après sont transversalement impliquées dans l’accueil du public à la Mairie
de Nanterre et seront les utilisatrices finales de l’outil :
-
Direction de la Vie Citoyenne (5 Mairies de Quartier déconcentrées) ;
-
Directions de l’Enfance et de l’Enseignement (accueil commun) ;
-
Direction de l’Action Sociale (CCAS) ;
-
Service Affaires Générales (Etat-Civil, Cartes Nationales d’Identité, Passeports) ;
-
Direction de l’Habitat (logements) ;
-
Direction de la Première Enfance.
Les sites et directions non mentionnées sont aujourd’hui exclus du périmètre projet.
La Direction des Systèmes d’Information et des Télécommunication (DSIT) intervient dans l’intégration
de l’outil au Système d’Information, dans les relations avec le Maître d’Œuvre (MOe), dans l’exploitation, et
dans l’Assistance à Maîtrise d’Ouvrage (AMOa).
5
3 FORMALISME ET TERMINOLOGIE
3.1
Niveaux d’accueil
Définition 1 :
Niveau 1 - Pré-Accueil - Contact
Réponse aux questions des administrés, aux demandes de renseignement concernant tous les sujets et
démarches (date de la prochaine braderie, liste de pièces à fournir pour une demande de passeport
biométrique), dépôt de courrier, de dossier, de paiement par les administrés (fonction « boîte aux lettres »),
démarches rapides (prise de RdV, recensement militaire, retrait attestations d’accueil, etc.).
Définition 2 :
Niveau 2 - Pré-Accueil – Introduction, Orientation
Introduction au niveau 3 :
- Première vérification de dossier si la démarche de l’administré requiert la présentation de pièces ;
- Délivrance d’un ticket à l’administré en fonction de la démarche ;
- Orientation vers la zone d’attente ;
Orientation vers le niveau 4 :
- Orientation sans délivrance de ticket vers le service adéquat en cas de démarche particulière requérant
un traitement particulier.
Ainsi un accueil de niveau 2 est obligatoirement suivi d’un accueil de niveau 3 ou de niveau 4.
Définition 3 :
Niveau 3 - Accueil - Démarches
Appel de l’administré patientant dans la zone d’attente, puis réponse à la démarche de l’administré. C’est le
traitement d’accueil le plus important.
Définition 4 :
Niveau 4 - Gestion - Traitements particuliers
Réception de l’administré au niveau gestion dans le service adéquat et réponse à la démarche particulière.
3.2
Sites et rôles des agents
Définition 5 :
Sites d’Accueil
Les sites d’accueil entrant dans le cadre projet sont l’Hôtel de Ville et les 5 Mairies de Quartier
déconcentrées.
Définition 6 :
Pré-Accueil
C’est l’espace situé dans le Hall de l’Hôtel de Ville ou dans l’entrée d’une Mairie de Quartier. C’est le
premier lieu de passage obligé pour tout accueil d’usager, espace où s’effectuent les niveaux 1 et 2 d’accueil.
Définition 7 :
Agent de Pré-Accueil
Agent physiquement en poste au pré-accueil situé dans le Hall de l’Hôtel de Ville ou dans le Hall d’une
Mairie de Quartier. Il a en charge le niveau 1 et le niveau 2 d’accueil définis précédemment.
Définition 8 :
Zone d’attente
Espace où patiente l’usager après être passé au niveau 2 d’accueil (Pré-Accueil) et avant d’être appelé au
niveau 3 d’accueil (Guichet d’Accueil), où sa démarche sera prise en charge. Les Mairies de Quartier ont
chacune une unique zone d’attente. L’Hôtel de Ville a une zone d’attente principale, et une zone d’attente
spécifique pour le service Habitat et Première Enfance.
Définition 9 :
Guichet d’Accueil
6
Espace situé dans le Patio de l’Hôtel de Ville ou en Mairie de Quartier où l’on répond à une démarche de
l’administré, c'est-à-dire au niveau 3 d’accueil.
Définition 10 : Agent d’Accueil
Agent physiquement en poste à un guichet d’accueil situé dans le Patio de l’Hôtel de Ville ou en Mairie de
Quartier. Il a en charge le niveau 3 d’accueil défini précédemment.
Définition 11 : Bureau de Gestion
Espace situé au cœur d’un service. Les tâches principales qui y sont effectuées sont les tâches de gestion, de
conception, de fonctionnement du service. Néanmoins, cet espace peut être amené à accueillir un usager dans
le cadre du niveau 4 d’accueil défini précédemment.
Définition 12 : Agent Gestionnaire
Agent physiquement en poste à un bureau de Gestion d’un service. Au-delà de ses tâches de gestion en backoffice, qui forment son activité principale, il est amené à pouvoir prendre en charge le niveau 4 d’accueil
défini précédemment.
Définition 13 : Responsable d’Accueil
Agent encadrant les agents de Pré-Accueil ou d’Accueil. Il a en charge la bonne marche de l’accueil du public
et la gestion du personnel en fonction du flux d’usagers.
Définition 14 : Administrateur Fonctionnel
L’administration fonctionnelle et les paramétrages liés à la gestion de l’accueil sont assurés par les
Responsables d’Accueil définis.
Définition 15 : Administrateur Technique
Agent en charge de l’administration technique de l’outil (DSIT).
Définition 16 : Rôle d’un Agent
Le rôle d’un agent représente sa place dans l’organisation d’accueil. Il peut ainsi être Agent de Pré-Accueil,
Agent d’Accueil, Agent de Gestion, Responsable d’Accueil, Administrateur, Agent de Centre d’Appel, etc.
Un agent peut cumuler plusieurs rôles pour un site d’accueil. Un agent peut avoir des rôles différents en
fonction des sites d’accueil. Les rôles et les droits qui leurs sont associés sont paramétrables.
3.3
Formalisme fonctionnel
Définition 17 : Ticket d’Attente
Ticket délivré à l’usager au niveau 2 d’accueil (pré-accueil) lorsque sa démarche doit être prise en charge au
niveau 3 d’accueil (guichet d’accueil), c’est-à-dire lors de l’introduction au niveau 3. Ce ticket insère l’usager
dans une file d’attente, en lui attribuant un numéro de passage et un motif de démarche. Il patientera jusqu’à
son appel par un guichet d’accueil qui effectuera sa démarche.
Définition 18 : Motif de Démarche
Il existe plusieurs utilisations des motifs de démarche :
Motif d’enregistrement : c’est un motif de démarche qui est renseigné sans donner lieu à
une édition de ticket d’attente. Deux cas se présentent :
⋅
Enregistrement de l’action effectuée au niveau 1 d’accueil en pré-accueil
(contact) ;
⋅
Enregistrement d’une orientation directe vers le niveau 4 d’accueil ;
7
Motif de ticket : c’est un motif de démarche qui est renseigné et qui donne lieu à une
édition de ticket d’attente vers le niveau 3 d’accueil (motif d’introduction) ;
Motif de précision : c’est un motif renseigné au niveau 3 d’accueil après traitement de la
démarche, qui vient confirmer, infirmer et surtout préciser le motif de ticket renseigné au
niveau du pré-accueil. Un motif de précision peut aussi classer un motif de ticket « sans
suite », afin de l’annuler (l’usager ne se présente pas par exemple).
Les motifs, notamment les motifs de précision, sont un des éléments de base sur lesquels seront construites les
statistiques. L’accès aux motifs peut être organisé par thèmes. La disponibilité des motifs et leurs niveaux
possibles d’utilisation sont paramétrables et peuvent être paramétrés spécifiquement en fonction de chaque
site d’accueil.
Dans le cas de transfert d’usager entre guichets de niveau 3, un nouveau motif de ticket est ajouté ou substitué
à l’existant et associé au ticket déjà porté par l’usager.
Tout motif peut être défini comme étant un motif possible de rendez-vous.
Définition 19 : File d’Attente
Représentation utilisée ici de façon abstraite, une file d’attente est une suite d’usagers classés selon leur
arrivée chronologique et le motif de démarche. Les usagers sont ainsi regroupés en files d’attente virtuelles
par motif ou groupement de motifs. Ces regroupements sont paramétrables et peuvent être paramétrés
spécifiquement en fonction de chaque site d’accueil.
Définition 20 : Profil d’Accueil
Un profil d’accueil est défini pour tout agent qui a accès à un rôle Agent d’Accueil. Ce profil permet de
définir les motifs ou groupes de motifs de démarche qu’un agent est en capacité de recevoir, ainsi que la
priorité avec laquelle il les reçoit. Ainsi une priorité de réception peut être attribuée à chaque motif pour
chaque Agent d’Accueil. Des profils génériques peuvent être définis afin de faciliter le paramétrage pour des
Agents d’Accueil aux compétences identiques (Etat-Civil, Enfance, Action Social, Stagiaires d’Eté, etc.).
Définition 21 : Numéro de passage
Le numéro de passage est un code attribué à l’usager lors de l’utilisation d’un motif de ticket. Ce numéro est
un code d’insertion de l’usager dans la file d’attente adéquate. L’usager pourra ainsi être appelé au niveau 3
d’accueil grâce à ce numéro.
Définition 22 : Démarches groupées
Une démarche groupée se présente :
-
lorsqu’un niveau 3 d’accueil est nécessaire et lorsqu’un ticket est délivré pour une famille ou un
groupe venu effectuer la même démarche, mais pour plusieurs personnes (inscription de plusieurs
enfants, édition de plusieurs actes de naissance différents, etc.) ;
-
lorsqu’un niveau 3 d’accueil est nécessaire et lorsqu’un usager vient effectuer plusieurs démarches
différentes, soit totalement indépendantes, soit dans un ordre fixé (calcul du quotient familial, suivi
d’une inscription à la cantine par exemple). Ces différentes démarches ne sont pas forcément
exécutées au même guichet.
Définition 23 : Temps de prise en charge
La prise en charge d’un usager correspond au moment où il interagit avec un agent de pré-accueil ou d’accueil
dans le but de mener à bien sa démarche.
Le temps de prise en charge correspond au temps passé par l’usager avec l’agent d’accueil au niveau 3
d’accueil. Pour chaque motif de démarche est associé dans l’outil un temps de prise en charge théorique
paramétrable. L’outil s’appuie sur ces temps théoriques de prise en charge pour calculer les temps théoriques
d’attente, pour mettre en évidence des anomalies pouvant traduire un problème à un guichet, etc.
Définition 24 : Rendez-vous
8
Les rendez-vous concernent certains motifs. Les plages temporelles possibles de réception sur rendez-vous
pour un agent d’accueil sont paramétrables. A un rendez-vous est ainsi associé un motif de démarche, les
motifs pouvant donner lieux à rendez-vous sont paramétrables.
9
4 ORGANISATION DE L’ACCUEIL ET EVOLUTIONS DU CHANTIER
ACCUEIL A LA VILLE DE NANTERRE : CONTEXTE DE
L’ACQUISITION DE L’OUTIL
4.1
Accueil prévu dans le cadre projet
4.1.1
-
Evolutions de l’Hôtel de Ville
Pré-accueil (hall)
L’accueil général est physiquement déplacé pour devenir un pré-accueil centralisé :
• effectue le niveau 1 d’accueil (contacts) ;
• effectue le niveau 2 d’accueil :
- Les guichets d’accueil (patio) :
• tous les usagers ont déjà un ticket en arrivant dans le patio et peuvent donc se diriger
directement vers l’espace d’attente, l’étape d’introduction est centralisée au pré-accueil ;
4.1.2
Impacts organisationnels
Le pré-accueil est centralement impacté par ces évolutions :
- mise en place de référents au sein des agents de pré-accueil ;
- formations des agents de pré-accueil :
• formation au nouvel outil de gestion des files d’attentes ;
• formation « métier » : connaissances pour les prestations rapides, apprentissages « métiers »
pour les éventuelles vérifications de dossier, etc.
Au niveau des guichets d’accueil :
- formation au nouvel outil d’appel des administrés patientant en zone d’attente ;
- démarches facilitées par les premières vérifications du pré-accueil ;
- meilleure coordination avec le pré-accueil, en particulier à travers les référents.
Au niveau des services gestion :
- démarches particulières facilitées par une orientation adéquate ;
- meilleure coordination avec le pré-accueil, en particulier à travers les référents ;
- formation au module de conduite de l’accueil du nouvel outil de gestion des files d’attente.
La mise en place et le paramétrage initial de la solution s’appuiera sur l’organisation ici décrite. La
mise en place première interviendra peut-être dans une période transitoire de travaux dans le hall de l’Hôtel de
Ville (déplacement du pré-accueil). Dans ce cas, l’installation au niveau pré-accueil aurait donc à être
modifiée à la fin des travaux.
4.2
Evolutions en réflexion
Des évolutions sont en cours de réflexion (guichet d’accueil polyvalent), qui interviendront à plus long terme,
et entraîneront en temps voulu un re-paramétrage approprié de la solution pour s’adapter à la nouvelle
organisation.
10
5 EXIGENCES FONCTIONNELLES
5.1
Exigences fonctionnelles générales
Exigence 1 :
Paramétrage des rôles
Les utilisateurs de l’application sont associés à un ou plusieurs rôles possibles. En fonction du rôle choisi,
l’utilisateur a accès aux fonctionnalités de l’application qui ont été définies pour ce rôle. La définition des
accès aux fonctionnalités pour chaque rôle est paramétrable. La possibilité de paramétrer les accès par rôle est
elle-même une fonctionnalité qui peut être ou non attribuée à un rôle donné.
L’application met ainsi en œuvre un mécanisme permettant de décrire les droits d’accès aux données, aux
fenêtres, aux outils, etc. Tous les traitements de l’application sont accessibles et utilisables par n’importe quel
personnel, à condition qu’il en ait les droits, et depuis n’importe quel site.
Exigence 2 :
Evolutivité
La solution est capable de suivre les évolutions organisationnelles. Il ne faut notamment aucune limite en
nombre de sites, services, postes, etc.
Exigence 3 :
Calcul des délais d’attente
L’outil calcule en temps réel un temps d’attente moyen global, et un nombre de personnes en attente qui
peuvent être rendu disponible aux utilisateurs. L’outil calcule de même un temps d’attente moyen par file
d’attente définie (par motif de démarche ou groupe de motifs de démarche).
5.2
Exigences fonctionnelles Module Pré-Accueil
Exigence 4 :
Enregistrement simple de visiteur
Le visiteur peut être compté sur un motif d’enregistrement au pré-accueil, sans donner lieu à l’édition de
ticket d’attente (cas de prestation effectuée directement en niveau 1 pré-accueil et cas d’orientation sans ticket
vers le niveau 4).
Exigence 5 :
Edition de ticket d’attente
Lorsque la démarche de l’usager requiert un accueil de niveau 3, le pré-accueil édite un ticket d’attente en
fonction de la démarche. Le motif de ticket peut apparaître sur le ticket remis au visiteur. L’utilisation d’un
motif de ticket permet donc la remise d’un ticket à l’usager et insère ce dernier dans une file d’attente, en
fonction du motif de sa démarche, en lui attribuant un numéro de passage.
Le ticket sera un support de communication pouvant contenir, outre le numéro de passage de l’usager, le logo
de la ville, des messages d’information, l’heure et la date d’impression du ticket, etc.
Exigence 6 :
Gestion des démarches groupées
Le prestataire décrit le processus mis en place lorsque l’agent de pré-accueil est confronté à une démarche
groupée.
Par exemple il édite un ticket unique pour la famille ou le groupe de personne tout en renseignant au niveau
du motif de ticket le nombre de fois où il faudra répéter la démarche (« tickets virtuels »), afin que le temps
réel requis pour la prise en charge des usagers soit bien intégré dans l’outil. Ou il édite un ticket unique pour
l’ensemble des démarches d’un même usager, en rattachant les différents motifs de ticket au même ticket pour
chaque démarche composant la démarche groupée. Le logiciel doit être capable de gérer toutes les
combinaisons de démarches groupées.
11
5.3
Exigences fonctionnelles Module Accueil
Exigence 7 :
Appel d’Usager
L’Agent d’Accueil appelle un usager de façon transparente. En fonction du rôle d’accueil de l’agent,
paramétré au préalable, et de l’ordre des usagers dans les files d’attente, le logiciel choisit automatiquement et
judicieusement l’usager appelé.
L’appel de l’usager s’effectue sur les écrans adéquats. Un appel n’est ainsi pas diffusé sur tous les afficheurs
mais uniquement ceux qui ont été paramétrés pour le site considéré, pour la zone d’attente appropriée. Ces
paramétrages s’effectuent par les agents ayant droit à partir d’un module de gestion de l’affichage.
Exigence 8 :
Enregistrement du motif de précision
Une fois la démarche de l’usager effectuée, l’agent d’accueil peut renseigner le motif de précision, c'est à dire
confirmer, corriger si besoin, et surtout préciser le motif de ticket initialement renseigné au pré-accueil.
Exigence 9 :
Historisation des prises en charge
Les prises en charge d’usagers sont enregistrées dans un historique des prises en charge. L’historique contient
pour chaque entrée les informations sur la prise en charge (date, heure, motif de démarche, durée, etc.).
Exigence 10 : Transfert d’usager
La gestion des démarches groupées passe par le transfert d’usager de guichet à guichet, le renseignement des
différents motifs de ticket étant déjà effectué par le pré-accueil.
Si l’usager ne se trouve pas dans la bonne file d’attente (mauvaise définition du motif de démarche) ou s’il
exprime un nouveau besoin une fois sa première démarche effectuée, l’agent d’accueil a la possibilité de
rediriger l’usager. Le prestataire décrit le processus mis en place pour gérer ce cas (par exemple
remplacement ou ajout d’un autre motif de ticket rattaché au ticket). Lorsqu’un usager est ainsi redirigé, sa
place dans sa nouvelle file d’attente est calculée en fonction de son heure d’arrivée, c'est-à-dire du temps qu’il
a déjà passé à attendre.
5.4
Exigences fonctionnelles Module Rendez-vous
Exigence 11 : Paramétrage des rendez-vous
La possibilité de recevoir des rendez-vous est paramétrable par agent d’accueil.
Les plages temporelles où la prise de rendez-vous est possible pour un agent sont paramétrables. La
possibilité de paramétrer ces plages temporelles est attribuable ou non à un agent quel que soit son rôle
(responsable d’accueil, agent de gestion, etc.).
Exigence 12 : Prise de Rendez-vous
La possibilité de prise de rendez-vous pour un usager par un agent est paramétrable, quel que soit son rôle
(agent de pré-accueil, agent d’accueil, agent de gestion, responsable d’accueil, agent de centre d’appel, etc.) et
le site d’accueil auquel il appartient. La possibilité de prise de rendez-vous pour un rôle donné est aussi
paramétrable. A moyen terme la possibilité pour l’usager de prendre un rendez-vous à partir du site internet
de la ville peut être mise en place.
Exigence 13 : Gestion des Rendez-vous
L’outil permet de vérifier la validité du rendez-vous lorsqu’un usager se présente au pré-accueil. Le
prestataire décrit comment est gérée l’orientation des usagers ayant rendez-vous (édition de ticket spécifique
par exemple).
Le prestataire décrit comment est géré le fonctionnement de l’appel de personnes ayant rendez-vous. L’outil
gère notamment les situations où il y a concurrence entre usagers avec et sans rendez-vous (personne en retard
à son rendez-vous par exemple), quand il y a absence au rendez-vous, et quand il y a un intervalle disponible
pour l’accueil entre deux rendez-vous.
Exigence 14 : Intégration dans l’outil de gestion du centre d’appel
12
Le module de gestion de rendez-vous sera intégrable dans l’outil de gestion du centre d’appel : application
HERA de la suite Altitude uCI. Le prestataire décrit comment peut-être invoquée l’interface de gestion des
rendez-vous de son outil sous navigateur web, en passant une URL associée à des arguments de lancement
permettant d’afficher l’agenda correspondant au besoin. Ces arguments pourront éventuellement comprendre
un nom d’utilisateur et un mot de passe, avec un type d’accès. Le prestataire décrit si des informations
pourront être retournées de l’agenda vers HERA (confirmation, heure du rendez-vous pris, …) et quels
mécanismes il peut mettre en œuvre à cette fin (Web-service, active X, applet java, ...).
5.5
Exigences fonctionnelles Module Conduite de l’Accueil
Exigence 15 : Visualisation de la situation d’accueil en temps réel
Un agent responsable d’accueil peut suivre la situation d’accueil en temps réel sur un module de conduite de
l’accueil. Il peut ainsi voir l’état d’activité de l’équipe placée sous sa responsabilité. Les possibilités de
visualisation sont paramétrables en fonction de l’agent responsable d’accueil et du site d’accueil d’où il s’est
enregistré.
Exigence 16 : Seuils d’alerte
Des seuils d’alertes sont définis (en fonction du nombre d’usagers en attente, de la durée de prise en charge,
etc.) qui permettent à l’outil de prévenir le responsable d’accueil afin que celui-ci puisse gérer la fonction
accueil de son équipe (envoi de renfort en cas d’affluence, intervention en cas de problème sur une prise en
charge, etc.).
5.6
Exigences fonctionnelles Module Statistiques
Exigence 17 : Accès au module de statistique
L’accès au module de statistique par les agents est paramétrable en fonction des rôles et des agents. L’accès
aux fonctionnalités statistiques peut être total ou restreint.
Exigence 18 : Fiabilité des données
Les données fournies par le module statistiques sont fiables. Les données « erronées » (temps de prise en
charge inférieur à un certain seuil, doublons de prise en charge, etc.) sont exclues de la prise en compte pour
les calculs statistiques.
Exigence 19 : Requêtes
Le prestataire présente les requêtes statistiques de base qui sont déjà présentes dans l’outil : les données
quantitatives telles que l’affluence, l’affluence par démarche, l’affluence par période, l’affluence par site,
l’affluence par thème de motif, etc., les données qualitatives telles que le temps moyen d’accueil, le temps
moyen d’accueil par démarche, etc., et les données consolidées globales, par site d’accueil, etc.
De plus le prestataire présente dans quelle mesure il y a possibilité, de construire des requêtes adaptées aux
besoins.
Exigence 20 : Edition de Rapports Statistiques
Les données statistiques sont éditables sous forme de rapport personnalisable. Le prestataire présente dans
quelle mesure ces rapports sont exportables dans divers formats adaptés aux outils utilisés à la Ville de
Nanterre (suite bureautique Ms Office, Open Office, etc.). Ces rapports permettent aux responsables de
l’accueil d’analyser les flux et d’adapter ainsi l’organisation de l’accueil en fonction des affluences. Les
rapports générés sont imprimables.
5.7
Exigences fonctionnelles Module Gestion de l’Affichage
Exigence 21 : Appel des Usagers
Lorsqu’un agent d’accueil appelle un usager, le code de l’usager, inscrit sur son ticket, s’affiche sur les
différents écrans. Cet appel peut se composer au minimum du code appelé, du motif de l’appel, du numéro de
guichet où l’usager doit se rendre et d’un son alertant l’appel. Les paramètres et le contenu de l’affichage des
13
appels sont réglables (temps d’affichage de l’appel, volume sonore, informations affichées en cas de
confidentialité, etc.).
Un appel est diffusé uniquement sur les écrans adéquats en fonction du site d’appel, de la zone d’attente
appropriée, etc. Ces réglages sont paramétrables à partir du module de gestion de l’affichage.
Exigence 22 : Intégration avec l’outil d’affichage multimédia
Les écrans d’affichage peuvent diffuser des informations multimédias en parallèle des appels. L’outil
s’interfacera ainsi avec la solution de gestion d’affichage dynamique de la Ville, tant au niveau logiciel que
matériel. Le prestataire sera en mesure de fournir la description des interfaçages techniques et fonctionnels
qu’il sera possible de mettre en œuvre (web-services, protocoles, etc.). Une description de l’outil est
disponible en annexe (progiciel Scala de l’éditeur TMM Communication).
5.8
Autres fonctionnalités
Exigence 23 : Fonctionnalités supplémentaires
Le prestataire peut décrire toute fonctionnalité que son outil propose et qui n’a pas été mentionnée ci-avant.
5.9
Périmètre utilisateur
L’application sera utilisée par un périmètre utilisateur défini approximativement comme suit :
-
30 agents en capacité d’assurer le pré-accueil, sur 10 postes informatiques ;
-
65 agents en capacité d’assurer l’accueil, sur 55 postes informatiques ;
-
20 responsables d’accueil, sur 20 postes informatiques ;
-
dont 15 administrateurs fonctionnels ;
14
6 ENVIRONNEMENT INFORMATIQUE
La Ville met en œuvre une infrastructure de sécurité (firewall, antivirus, …).
6.1
Les serveurs
La configuration des serveurs est décrite en annexe 1.
6.2
Configuration de base des postes de travail
Tout poste de travail connecté au réseau informatique de la Ville de Nanterre est intégré au domaine
« Nanterre ». La configuration logicielle de base est décrite en Annexe 1.
La DSIT examine les conditions d’une migration de son parc pour:
-
le système d’exploitation (Windows 7) ;
-
La suite bureautique ;
-
Le serveur de messagerie.
Pour ces 2 derniers projets, compte tenu de leur impact notamment par rapport au standard unique jusqu’ici
retenu, il est demandé :
-
d’offrir une solution interopérante avec la suite bureautique Open Office dans sa version 3.1 ou
ultérieure ;
-
d’offrir une solution interopérante avec les serveurs de messagerie Zimbra et Ms Exchange ;
-
de privilégier une solution full-web fonctionnant tant avec Ms Internet Explorer qu’avec Mozilla
Firefox.
6.3
Le compte utilisateur
Tout utilisateur informatique possède un compte réseau intégré à l’Active Directory.
Est associé à ce compte :
•
Des droits sur les serveurs ;
•
Des droits sur les répertoires ;
•
Une boîte de messagerie (pré[email protected]);
•
Un espace de fichier personnel sauvegardé ;
•
Les données sur le répertoire utilisateur ne peuvent contenir des exe, des images, ou des films ;
•
Les données stockées sur le lecteur local ne sont pas sauvegardées.
Tout utilisateur quant il se connecte à son poste de travail se connecte en tant qu’utilisateur normal.
6.4
Les bases de données
Les bases de données administrées et maintenues par la DSIT sont les suivantes :
•
Oracle (versions 9i et 10g) ;
•
Sql-server (versions 2000 et 2005).
Tout autre SGBD proposé doit être open source.
6.5
Les sauvegardes
La Ville de Nanterre a mis en place une infrastructure de sauvegarde/restauration qui permet de sécuriser le
contenu des serveurs de données.
L’outil de sauvegarde TINA (Atempo) permet une sauvegarde sur disque des données, puis sur bande. L’outil
permet également des sauvegardes de l’infrastructure VMware de production. Aucun serveur de test ou de
15
pre-production n’est sauvegardé.
6.6
Le réseau
Le réseau physique est décrit en annexe 1.
6.7
La télémaintenance serveur et poste de travail
La DSIT dispose d’outils de prise de main à distance :
•
Netviewer (7 licences) pour les accès à partir de l’extérieur ;
•
De l’outil de prise de main Landesk pour les postes utilisateurs du LAN de la Ville de Nanterre.
Pour les Serveurs Unix, l’accès se fait à partir de l’outil Telnet, après avoir pris la main sur un poste de travail
grâce aux moyens précédemment cités.
6.8
Salle de formation
La DSIT dispose de 2 salles de formation comprenant 9 postes (PC avec Windows XP) mis à disposition des
agents à former. L’on peut se connecter à partir des postes physiques à des machines virtuelles. Une
imprimante réseau est disponible.
L’un des postes dispose d’un vidéoprojecteur. Les salles disposent d’un tableau de projection et d’un tableau
de papiers.
16
7 EXIGENCES TECHNIQUES D’INTEROPERABILITE ET D’INSERTION
DANS LE SYSTEME D’INFORMATION DE LA VILLE DE NANTERRE
7.1
Exigences d’interopérabilité avec les applications de la Ville de Nanterre
Exigence 24 : Format des échanges
La solution proposée sera jugée notamment sur son interopérabilité.
Le prestataire devra préciser dans sa réponse quels sont les normes, protocoles ou standards d’échanges de
données ou d’architecture de la donnée respectés par la solution.
Le prestataire privilégie les échanges sous la forme du protocole PrEStO.
7.2 Exigences techniques relatives aux possibilités de centralisation technique et au
fonctionnement en mode dégradé
Exigence 25 : Définition de l’architecture de la solution
La solution est techniquement centralisée, avec implantation d’un serveur unique pour l’ensemble des
structures, en tenant compte du nombre de structures concernées.
Le prestataire décrit quelles mesures techniques peuvent être mises en place pour que l’accueil puisse
se dérouler dans les meilleures conditions même en cas de rupture réseau entre le site central et les sites
déconcentrés. Il décrit le fonctionnement de l’application en mode dégradé, notamment en cas de perte
de connexion à l’infrastructure de l’application.
Le prestataire précise si une solution de backup réseau est compatible avec l’architecture et le paramétrage de
l’application. Dans l’affirmatif, il décrit l’infrastructure à mettre en œuvre.
La Direction des Systèmes d’Information et des Télécommunications (DSIT) de la ville de Nanterre s’oriente
préférentiellement vers une architecture full-web.
Le prestataire peut fournir un accès extranet. Le prestataire décrit la technologie employée.
7.3
Exigences techniques relatives à l’accès à l’application
Exigence 26 : Raccordement technique client/serveur
Le câblage entre postes clients, serveurs, afficheurs, et tout autre matériel nécessaire à la solution sera de type
standard (câbles Ethernet, prises RJ45, etc.).
Le câblage entre les postes clients et le serveur est mis en place par la mairie de Nanterre, ainsi que les
câblages avec les différents afficheurs.
7.4
Exigences sur les règles d’exploitation de la DSIT
Exigence 27 : Automatisation des sauvegardes
Le prestataire garantit que les données de l’application pourront entrer dans le plan de sauvegarde automatisé.
Le prestataire assure la configuration de l’outil de sauvegarde de la DSIT en collaboration avec la DSIT.
Exigence 28 : Supervision applicative
Le prestataire fournit une documentation décrivant les informations nécessaires à la supervision de
l’application (quoi surveiller, comment, …). L’outil de supervision utilisé est l’outil WitBe.
17
8 EXIGENCES DE MATERIELS ET FOURNITURES
8.1
Fournitures couvertes par la Ville de Nanterre
La Ville de Nanterre procède à la fourniture des matériels suivants :
•
Du (des) serveur(s) dans le cadre de son marché serveur, selon les caractéristiques techniques et les
performances précisées par le titulaire dans son architecture technique au mémoire technique ;
•
De l’infrastructure réseau ;
•
Des postes de travail.
Exigence 29 : Description des besoins du prestataire
Le prestataire décrit précisément les matériels et les périphériques nécessaires à l’installation et à l’utilisation
de son application.
•
•
•
Serveurs :
o
Nombre et CPU ;
o
Espaces disques associés ;
o
Mémoires ;
o
Système d’exploitation ;
Poste de travail (en respect du standard Ville de Nanterre) :
o
CPU ;
o
Espace disque associé ;
o
Mémoires ;
Périphérique USB ou IP
o
Imprimantes.
Le prestataire décrit dans sa réponse les niveaux minimum attendus en termes de réseau :
•
Vitesse
•
Qualité de service
•
Architecture (WAN, LAN, MPLS, …)
Toute fourniture matérielle ou logicielle et toute prestation autre que celles fournies par la ville de Nanterre
est à la charge du prestataire.
8.2
Fournitures couvertes par le prestataire
Exigence 30 : Imprimantes de tickets
Le pré-accueil de l’hôtel de ville sera équipé avec 5 imprimantes de tickets, chaque pré-accueil des 5 Mairies
de Quartier est équipé avec 1 imprimante de billet. Les 10 imprimantes de tickets ainsi commandées seront
fiables, rapides et facilement rechargeables.
Le pré-accueil de l’hôtel de ville sera équipé d’une borne automatique de distribution de ticket.
Exigence 31 : Licences applicatives
Le prestataire indique le nombre de licences nécessaires au fonctionnement de sa solution. La Ville souhaite
privilégier :
-
un système de « licence site » utilisateurs illimités ;
18
-
un système open source sans limite d’utilisation ou de contribution.
Exigence 32 : Ecrans d’appel
Le prestataire fournit dans le cadre du marché 3 écrans pour équiper la zone d’attente de l’Hôtel de Ville. Ces
écrans sont des écrans lcd qui peuvent assurer l’appel des usagers attendant ainsi que la diffusion simultanée
d’informations multimédia.
19
9 EXIGENCES D’ACCOMPAGNEMENT
9.1
Exigences d’installation
La Ville de Nanterre procède à la fourniture des logiciels suivants :
•
Les licences du système d’exploitation ;
•
Les licences comprises dans la définition du poste de travail type (ANNEXE 1) ;
•
Les licences serveur Oracle ou SQL server ;
•
Les licences clientes Oracle ou SQL server.
La Ville de Nanterre procède à la fourniture des prestations suivantes :
•
•
Installation du système d’exploitation sur les serveurs fournis, si celui-ci est conforme aux prérequis : système. La DSIT préparera en outre :
o
l’adresse IP ;
o
le nom de serveur(s) ;
o
l’intégration dans le domaine Windows.
Installation de l’ensemble des logiciels compris dans la définition du poste de travail type (ANNEXE
1)
Exigence 33 : Configuration, installation et déploiement de l’application
Le prestataire prévoit la configuration et l’installation de l’application sur les serveurs et les postes de travail
dans les environnements d’exécution demandés :
•
Un environnement de test :
o
Lié à une base de test ;
o
Utilisé pour :
Permettre la vérification d’aptitude du progiciel et des outils associés lors de la
première installation ;
Intégrer les nouvelles versions avant mise en production ;
Tester et valider les nouvelles versions successives de l’application ;
Les formations ;
•
Un environnement de production :
o
Lié à une base de production ;
o
Utilisé pour :
l’utilisation en production suite au démarrage ;
la vérification de service régulier du progiciel et des outils associés, incluant les
différentes versions ;
Une préférence est accordée à la mise en place des bases de données sur un environnement différent.
Le prestataire décrit un planning cible d’installation et de déploiement de l’application.
Le prestataire livre à la Ville l’ensemble des documents techniques nécessaires à l’installation, à la
maintenance et à l’administration technique de la base de données, du serveur applicatif et des postes clients.
20
9.2
Exigences de paramétrage
Exigence 34 : Paramétrage de l’application
Le prestataire prévoit le paramétrage de l’application en fonction des besoins de la Ville en gestion de
l’accueil. Il effectuera ainsi un audit de paramétrage qui donnera lieu à un rapport d’audit livré à la Ville. Il
mettra ensuite en œuvre le paramétrage de l’application. Ce paramétrage sera testé, affiné et conclu en accord
avec les directions utilisatrices. Un document récapitulant les paramétrages effectués sera livré à la Ville.
Le prestataire décrit un planning cible de mise en œuvre du paramétrage.
9.3
Exigences de formation
Exigence 35 : Formations
Le prestataire prévoit la formation des différents profils d’utilisateurs de l’application. Il définit le contenu des
formations et prévoit la diffusion de supports de formations (utilisateur, administrateur fonctionnel,
administrateur technique,…).
Le prestataire présente différents scenarii de formation (formation directe de tout le personnel, mise en place
de référents, …).
Le prestataire décrit un planning cible de mise en œuvre du plan de formation.
9.4
Exigences d’assistance au démarrage
Exigence 36 : Assistance au démarrage
Lors des jours prévus d’assistance au démarrage, le prestataire est présent sur site. Il a pour mission d’assister
les directions utilisatrices dans l’utilisation en production de l’outil. Il assure une assistance technique et
fonctionnelle, et répond dans ce cadre aux difficultés qui peuvent survenir. Il assure une présence de soutien
auprès des agents utilisateurs. Le prestataire définit le nombre de jours d’assistance au démarrage prévus.
21
10
EXIGENCES DE GARANTIE ET MAINTENANCE
10.1 Périmètre de la Garantie
Exigence 37 : Garantie
Le prestataire décrit le périmètre de la garantie contractuelle mise en œuvre :
-
périmètre de l’assistance corrective et de la fourniture des versions correctives (traitement et
résolution de toute anomalie sur le progiciel et les outils associés) ;
-
périmètre de l’assistance évolutive et de la fourniture des évolutions logicielles (fourniture
des nouvelles versions et des descriptifs détaillés des modifications techniques et
fonctionnelles de son progiciel et des outils associés) ;
-
périmètre de l’assistance fonctionnelle à l’utilisation (réponse à toute demande d’information
ou de compréhension sur les fonctionnalités et l’utilisation du Progiciel et des outils
associés).
La garantie inclut :
•
•
du point de vue fonctionnel :
-
la conformité du progiciel aux spécifications décrites par le titulaire et dans la documentation
remise ;
-
l’évolution fonctionnelle du progiciel en fonction des changements de législation (lois,
décrets, circulaires), des évolutions des normes d’accueil (Charte Marianne, etc.) et toutes
instructions émanant des autorités de tutelle ;
du point de vue technique :
-
l’absence d’anomalies graves du progiciel et des outils associés ;
-
la conformité du Progiciel et des outils associés à l’architecture technique en place ;
-
la correction des anomalies du progiciel et des outils associés au fonctionnement du
progiciel ;
-
la bonne performance du système installé par le titulaire : temps de réponse satisfaisants pour
un fonctionnement normal.
Cette garantie concerne les progiciels et outils, utilisés (dans les environnements d’exécution (production,
formation et test) et livrés par le titulaire. Dans le cadre de cette garantie, le titulaire les maintiendra en bon
état de fonctionnement et il procédera à toutes les réparations et les échanges éventuels qui s’avéreraient
nécessaires. D’une manière générale, durant toute la garantie, les mises à jour sur le progiciel et outils
associés, y compris les bases de données, devront être effectuées par le titulaire du marché.
10.2 Périmètre de la Maintenance
Exigence 38 : Maintenance
Le prestataire décrit le périmètre du contrat de maintenance mis en œuvre :
-
périmètre de la maintenance corrective et de la fourniture des versions correctives (traitement
et résolution de toute anomalie sur le progiciel et les outils associés) ;
-
périmètre de la maintenance évolutive et de la fourniture des évolutions logicielles (diffusion
des informations et mise à disposition des nouvelles versions du progiciel) ;
-
périmètre de l’assistance fonctionnelle à l’utilisation (réponse à toute demande d’information
ou de compréhension sur les fonctionnalités et l’utilisation du Progiciel et des outils
associés) ;
22
-
maintenance préventive (information des risques potentiels et de leurs impacts sur le bon
fonctionnement de l’application).
Du point de vue fonctionnel, le titulaire doit veiller à :
•
la conformité du progiciel aux spécifications décrites par le titulaire dans son mémoire technique et
dans la documentation remise ;
•
l’évolution fonctionnelle du progiciel en fonction des changements de législation (lois, décrets,
circulaires) et toutes instructions émanant des autorités de tutelle.
La maintenance évolutive inclut :
•
les améliorations décidées par la société ;
•
les adjonctions de fonctionnalités dans le cadre des nouveaux modules sous licence ;
•
les adaptations aux réglementations nouvelles, dans la mesure où il ne s'agit pas d'une reconsidération
mettant en cause la base du progiciel et nécessitant une réécriture du programme ;
•
les adaptations liées aux modules sous licence d'utilisation.
La société s'engage à procéder à l’évolution du progiciel en fonction des mises à jour réglementaires : avant la
date de mise en application de la réglementation.
10.3 Gestion des incidents
Exigence 39 : Gestion des incidents
Le prestataire décrit comment sont gérés les incidents (besoin d’assistance, problème logiciel). Il décrit s’il
utilise un outil de gestion de fiches de faits techniques, et si cet outil est disponible à travers un extranet. Il
décrit les modes utilisés pour pouvoir entrer en relations avec ses services d’assistance (hotline, courriels, …).
Il décrit la façon dont il envisage de pouvoir intervenir en cas d’incident (télémaintenance à distance,
intervention sur site, appel téléphonique, …) et les conditions de ces interventions.
Il décrit la gestion des incidents en fonction de leur criticité et donne les temps garantis d’intervention et les
temps garantis de remise en service en fonction de ces criticités dans le respect des délais maximum définis
aux CCAP.
La criticité des incidents est définie comme suit :
•
Mineure : les anomalies mineures sont celles qui ne perturbent l’utilisation normale d’une
fonctionnalité du progiciel. Cependant, elles révèlent des erreurs d’IHM ou de logique des IHM ;
•
Majeure : les anomalies majeures sont celles qui perturbent l’utilisation normale d’une fonctionnalité
du progiciel et des outils associés, et notamment dans les conditions prévues par la documentation.
Cependant, un mode opératoire de contournement permet de continuer d’utiliser le progiciel ;
•
Bloquante : les anomalies bloquantes sont celles qui empêchent toute exploitation normale ou
dégradée du système.
23