CAHIER SPÉCIAL DES CHARGES - IBZ/DGCC/AL/2015/BE-Alert/001
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Description du marché BE-Alert 2015-2019 - Version 1
SPF INTERIEUR – CENTRE DE CRISE
Rue ducale, 53 à 1000 Bruxelles
DAVIER Thierry Tel 02/500.21.87 - Fax 02/503.14.31
– thierry.davier@ibz.fgov.be
CAHIER SPÉCIAL DES CHARGES
IBZ/DGCC/AL/2015/BE-Alert/001
PROCEDURE NEGOCIEE AVEC PUBLICITE PREALABLE POUR LA FOURNITURE D’UN
SYSTEME D’ALERTE ET D’INFORMATION A LA POPULATION
POUR LE COMPTE DU SPF INTERIEUR – DIRECTION GENERALE DU CENTRE DE CRISE
AVIS DE MARCHE
APERCU DES BESOINS TECHNIQUES
Mai 2015Partie II – Description du marché
1 Objectif du marché
L’objectif du marché est de mettre à disposition des autorités fédérales belges en charge de la gestion
de crise, un Système d’Alerte et d’Information à la Population (SAIP), à la fois efficient, performant et
évolutif. Le nom de cet outil est BE-Alert. Cet outil sera géré par le niveau fédéral et mis à disposition
des autorités locales sur base volontaire
La solution proposée devra être spécifiquement conçue pour les communications d'urgence et devra
être fournie comme une solution entièrement hébergée. Dès lors, la solution ne devra pas exiger
d’achat de matériel, de logiciels ou de lignes de communications supplémentaires, qui ont besoin
d'être achetés, entretenus ou pris en charge par le pouvoir adjudicateur, sauf mention contraire.
Le soumissionnaire doit fournir une solution de support de maintenance afin d'inclure les nouvelles
versions, mises à jour et les correctifs qui sont émis pendant la durée du contrat. Les choix
technologiques guidant le soumissionnaire pour les évolutions de sa solution doivent être conformes à
l’état de l’Art et doivent également être « Future-Proof ».
Dans un premier temps, la solution sera proposée dans une version de départ, avec des
spécifications de base obligatoires. Cependant, l’autorité fédérale se propose de faire évoluer la
version de base par des améliorations continues, par l’intermédiaire de développements de nouvelles
fonctionnalités (modules) et par l’ajout de nouveaux canaux de communication (intégrations) au fur et
à mesure du projet.
2 Architecture physique de la solution
La solution offre de manière transparente et entièrement intégrée une application de gestion de
communications et d’alertes, et la connectivité avec les différents canaux (Vocal, sms, e-mail, …) de
communication liée à cette application.
Les canaux de communication minimaux sont la voix (fixe et des appels mobiles), SMS, MMS, fax,
email, ... Dans un stade ultérieur, les canaux de communication et des alertes de médias sociaux
(Twitter Public Alert, Google Alert, …), le principe de IP PUSH/streaming seront ajoutés.
Le mode de mise à disposition est du type « Solution de services logiciels » (S-a-a-S pour Software-
as-a-Service), assorti de services d’accompagnement complets. Le client peut bénéficier de services
applicatifs modulables à ses besoins, sans se soucier du détail technique fonctionnel.
La solution doit fournir à ses utilisateurs un accès sécurisé par l’utilisation d’un ordinateur non dédié,
équipé d’un navigateur et d’une connexion internet. La plateforme et ses services devront également
être accessibles via une application mobile téléchargeable sur un smartphone ou une tablette.
Les logiciels, ainsi que toutes les données dans le système, sont hébergés sur des serveurs sécurisés
dans des infrastructures du soumissionnaire ou de ses partenaires. Le système est prévu
techniquement pour pouvoir opérer pendant une durée de vie minimale de sept (7) ans.
er
Le protocole CAP (Common Alerting Protocol) publié par l’OASIS dans sa dernière version 1.2 du 1
juillet 2010 devra être supporté.
2
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
La solution du soumissionnaire sera déployée sur deux emplacements physiques différents, dans des
bâtiments indépendants et distants de minimum vingt (20) kilomètres à vol d’oiseau. A défaut de
posséder une infrastructure sur le territoire belge à la notification du marché, le soumissionnaire
s’engage, par le simple fait de répondre à ce cahier des charges, à installer une nouvelle
infrastructure, dans les douze (12) mois à partir de la notification du marché.
Le soumissionnaire devra assurer la sécurité de l'infrastructure, la cyber-sécurité des informations et
des données. Le système dans sa configuration de base devra respecter des minimas de
configuration pour les canaux existants suivants :
Canaux vocaux : minimum 2 sites avec 300 canaux sur chaque site, soit 600 canaux ;
Canaux SMS : minimum 100 SMS/seconde
Le système doit mémoriser, sur support informatique (Logbook) situé chez le soumissionnaire, les
opérations effectuées par les différents administrateurs, pendant une période d’un an minimum, et
permettre la consultation de cet historique par les utilisateurs ayant reçus ce droit.
La solution fournira un environnement aussi bien pour :
l’apprentissage lors des formations (Simulation mode) ;
le test par tous les utilisateurs des paramètres utilisés dans des scénarios (Test mode) ;
l’essai occasionnel, par des utilisateurs avancés, de nouvelles fonctionnalités (Pilote mode) ;
et, bien sûr, le mode normal d’alerte (Live mode).
Pour les utilisateurs avancés, susceptibles de faire également du support d’autres utilisateurs à
distance (du pouvoir adjudicateur et/ou d’un Help-Desk du soumissionnaire), le soumissionnaire
présentera des solutions techniques pour une intervention par prise de contrôle du terminal distant
(Remote Control) et des possibilités de communication interactives (chat, appel vocal, visio-
conférence, …) possibles dans ce type de configuration.
Le soumissionnaire précisera les possibilités techniques de supervision continue (Heartbeat/ keep a
live signal) et à distance de ses installations techniques par des gestionnaires « avancés » du pouvoir
adjudicateur.
Il existe deux (2) types d’entités qui seront amenées à utiliser le système, en plus du pouvoir adjudicateur :
- Entités de type 1 : les autorités administratives responsables de l’alerte des citoyens, à savoir les
gouverneurs de province et les bourgmestres.
- Entités de type 2 : les organisations professionnelles, publiques ou semi-publiques, actives dans le
domaine de la sécurité civile telles que les zones de secours, les zones de police, la S.A. ASTRID, les
unités permanentes de la Protection Civile.
Le pouvoir adjudicateur ainsi que les entités de type 1 ont une utilisation complète du système (alerte de la
population et alerte de groupes spécifiques) tandis que les entités de type 2 n’auront qu’une utilisation limitée du
système (alerte de groupes spécifiques – par exemple : liste de volontaires, personnel de garde … etc. ).
Un des besoins des autorités belges consiste en une authentification la plus claire possible de
l’expéditeur, mais également de la teneur de la communication : de la simple information à l’alerte
urgente.
Pour ce faire, d’une part, le pouvoir adjudicateur possède différents numéros ou identifications
réservés qu’il compte réutiliser dans ce projet :
be-alert@ibz.fgov.be , CrisiscentreBE et CrisiscenterBE
0477/77.77.55
3
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
1771 (Contact Center fédéral pour l’information en situation d’urgence)
1789 (Spécifique pour l’alerte)
ALERTE1789, ALARM-1789, ALERT-1789
Remarque : aucune identification présentant des numéros étrangers ne sera acceptée par le pouvoir
adjudicateur.
3 Services standards
3.1 Préparation de l’alerte par les autorités
L’interface permettra à l’utilisateur de préparer à l’avance et de sauvegarder dans le système central
différents éléments. Ensuite, ceux-ci peuvent être utilisés pour constituer une campagne d’alerte.
L’interface permettra, durant la préparation de l’alerte, de choisir la combinaison de canaux de
communication utilisée de manière totalement flexible. L’interface permettra donc, au minimum, de ne
sélectionner, qu’un seul (au choix) des canaux de communication disponible, mais l’interface
permettra également, de sélectionner plusieurs, voire tous les canaux de communication présents sur
la plateforme.
3.2 Activation de l’alerte par les autorités
La solution permettra de sélectionner un des scénarios préenregistrés sur la plateforme pour activer
une campagne d’alerte vers les destinataires désirés.
Pour donner un maximum de flexibilité aux autorités, la solution sera capable de supporter les
différents types d’activations (immédiate ou différée) suivantes :
- par encodage sur un ordinateur relié à internet (via navigateur) ;
- et/ou par utilisation d’une application mobile pour tablette ou smartphone.
- et/ou par simple appel vers un serveur vocal via un téléphone classique ;
La possibilité d’activer la solution par l’envoi d’un message SMS ou e-mail n’est pas retenue pour des
raisons de fiabilité et de sécurité.
3.3 Rapports aux autorités
La solution comprendra un système de rapportage intégré, qui sera à même de collecter les
informations, de les résumer et de les visualiser au moyen d'un 'dashboard (tableau de bord) de
rapportage'. Pour ce faire, les rapports devront être disponibles dans différents formats exploitables
suivant l’appareil recevant l’information : format CSV, PDF, HTML, XLS,...
Il doit également être possible d'exporter un ensemble de données des bases de données et du
journal de bord afin de permettre une reconstruction historique des actions relatives à l'envoi de
l'alerte, le suivi, etc. ainsi que des rapportages complexes (rapports contenant plusieurs ensembles de
données et définition des liens).
4
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
La surveillance en direct d'une alarme qui a démarrée, également appelé Géo-Suivi, peut être
comprise comme une visualisation de certaines données en temps réel d'une manière ordonnée. Les
données sont visualisées sur une carte à la fois avec les codes appropriés de couleurs et de
symboles, et d'autre part, les données sont également visualisés dans une table ou un tableau de
bord. Toutes les données doivent être visualisées sur la même interface et donc sur un seul écran.
3.4 Inscription des citoyens dans le système
La fiche d’inscription permettra d’ajouter jusqu’à cinq (5) adresses différentes (Domicile, bureau, école
des enfants, …) et pourra également mentionner plusieurs numéros fixes et portables, ainsi que
plusieurs adresses e-mails.
Pour les inscriptions par internet, le citoyen sera dirigé vers un site internet dédié avec un URL
(Uniform Resource Locator) simple à mémoriser et utilisant un protocole de transfert hypertexte
sécurisé (HTTPS : HyperText Transfer Protocol Secure). Tous les frais liés à la mise à disposition de
cette infrastructure sont à charge du soumissionnaire.
Pour pouvoir gérer ses informations, le citoyen devra passer par un formulaire web. Différentes
mesures seront présentes pour rendre l’inscription la plus « intelligente » possible (Captcha,
vérification de la validité de l’adresse,…)
3.5 Alerte à la population ou aux autorités
Une fois l’activation demandée par un des utilisateurs, la plateforme permet d’envoyer les types de
messages suivants vers les contacts enregistrés :
- Messages vocaux vers téléphones fixes ou mobiles ;
- Messages écrits vers les téléphones mobiles (SMS- Short Messages Service);
- Messages écrits vers des appareils de télécopie (fax) ;
- Messages électroniques (e-mail avec ou sans fichier attaché) ;
Le système doit permettre l’envoi de messages selon la langue du destinataire ; les 3 langues
nationales (néerlandais, français, allemand) et l’anglais (pour les touristes) seront disponibles.
La solution proposée dispose d’un TTS (Text-To-Speech) dans ces quatre langues, permettant de
transmettre vocalement par téléphone les messages textes encodés au clavier. Il y aura également
possibilité d’injecter dans le système des messages préenregistrés par l’intermédiaire d’un combiné
téléphonique ou d’un fichier son téléchargé au départ de l’interface de la solution.
Concernant les SMS, la solution permettra de choisir entre la rédaction d’un SMS de longueur
classique ou d’un SMS long. La table de codage (sur 7 bits) utilisée par défaut sera celle définie par la
3GPP (GSM 03.38). Dès lors qu’un autre caractère (par exemple « ê ») est saisi, il y a basculement
dynamique du codage de l’un à l’autre système (de 160 caractères vers 70 caractères avec soit
l'Unicode codé sur 16 bits).
La solution permettra la rédaction et le formatage (gras, souligné,…) de messages télécopies (faxs),
ainsi que la rédaction et le formatage (couleurs, gras, souligné,…) de messages électroniques (e-
mail). La solution permettra l’ajout de plusieurs fichiers attachés, avec une limite de maximum 2 Mo.
La solution du soumissionnaire permet à l’utilisateur de définir un compte Facebook/Twitter, de le
nommer de manière explicite, de lui attribuer un login et mot de passe qui permettra ensuite à la
solution d’exploiter ce compte, suivant les droits des utilisateurs.
5
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
3.6 Module GIS (Geographic Information System)
Le module GIS du système aura un rôle de soutien essentiel dans le module d'alerte :
- Affichage des cartes et visualisation des objets divers ;
- système de Géocodage ;
- système de Géo-filtrage (Geofiltering) ;
- module de dessin et mesure ;
- Possibilité d’importation/exportation ;
- (Géo) bibliothèque d’éléments GIS.
La fonctionnalité de Géocodage permettra à un opérateur de renseigner l’adresse postale d’un
destinataire. La saisie est assistée en ne présentant que les provinces/villes/noms de rues valides à
l’utilisateur. Cette adresse sera automatiquement enrichie des coordonnées géographiques (longitude
et latitude) et représenté sur la carte.
Le résultat de la géocodage doit être visualisé sur la carte et l'adresse sera automatiquement enrichie
avec des données géographiques (latitude et longitude)
Du point de vue de l'utilisateur, la fonction GIS de Géo-filtrage consiste d’abord en la possibilité de
sélectionner les bénéficiaires de l'alerte en fonction de leur adresse postale ou de leur situation
géographique (temporaire ou préenregistré). La saisie d'un groupe géographique est réalisée
graphiquement par la définition d’une zone sur la carte et par l'enregistrement de cette zone sous un
nom symbolique. Il devrait être possible, avec un module de dessin intégré, de dessiner une zone
géographique sur la carte de base.
Le module de dessin permet de dessiner différentes formes (cercle, polygone, …) sur la carte :
Une bibliothèque GIS comprend un aperçu de toutes les couches de GIS contenues dans le système.
Via un menu de sélection, il doit être possible d'indiquer quelle(s) couche(s) doivent ou ne doivent pas
être visualisées.
6
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
4 Intégrations (canaux de communications)
4.1 Intégration du réseau de sirènes (ELSI – ELectronic SIrens)
Le réseau actuel de sirènes compte environ 570 sirènes réparties dans tout le territoire, dans les
zones situées autour des entreprises à risques SEVESO ou nucléaires. L’ossature du réseau actuel
se compose de 25 d’émetteurs radio interconnectés vers un ensemble de centraux de commande et
de contrôle (RKC), situés dans les unités permanentes de la Protection Civile.
L’intégration logicielle du réseau de sirènes consisterait à offrir la possibilité aux utilisateurs de la
solution de l’activation du réseau de sirènes par sélection de sirènes, groupes de sirènes ou zones
dans l’interface de la solution et envoi des instructions vers le serveur de commande des sirènes
(Centrales de commandes ou RKC) des Unités Permanentes de la Protection Civile.
4.2 Enrichissement des données (Data enrichment)
Le système d'alerte à la population va faire usage d’une base de données BE-Alert avec des
informations d'utilisateurs enregistrés (citoyens). Cette base de données est également enrichie avec
des informations provenant de sources externes, comme par exemple, des bases de données
d’annuaires téléphoniques, des données disponibles pour les centres de secours, au sein des
Partenariats Locaux de Prévention, ...
Le pouvoir adjudicateur désire travailler, pour cette partie, en attribuant un marché distinct à un
partenaire externe spécialisé. Un autre marché public sera donc lancé en cours d’exécution dans le
but de confier cette mission spécifique à un tiers. Le pouvoir adjudicateur compte sur une pleine
collaboration entre les soumissionnaires de ces deux procédures de marché public, pour un échange
harmonieux des données.
4.3 Intégration Database 112 (Sourds et malentendants)
Les centres d’appels d’urgence 112 ont décidés d’ouvrir la possibilité à certains groupes-cibles de
contacter les centres par le biais de messages SMS. Les personnes concernées sont soit, des
personnes ayant des troubles de l’audition (sourdes ou malentendantes), mais également des
personnes ayant des troubles de l’élocution (trachéotomisés, …).
Afin de restreindre l’accès à ces groupes-cibles, il est nécessaire de les enregistrer dans une base de
données, avec un champ d’identification particulier, leur garantissant l’accès au service avec le
numéro de portable enregistré. La base de données de référence qui a été choisie par le projet 112
est la base de données de BE-Alert.
4.4 Alertes publiques sur réseaux sociaux
En parallèle des offres classiques destinées au grand public, les sociétés comme TWITTER ou
Google développent, pour les autorités nationales en charge de la gestion de crise, des collaborations
7
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
pour l’envoi de messages d’alerte publique. Le pouvoir adjudicateur désire employer ces nouveaux
moyens dès que ceux-ci seront disponibles en Belgique.
4.5 Intégration ALERT-SMS
Un des projets du Centre de Crise du SPF Intérieur concernant l’envoi de messages d’alerte à la
population, est de pouvoir intégrer dans les moyens de télécommunications à disposition de la
plateforme BE-Alert, l’envoi de messages vers des portables situés dans une zone de danger, et ceci,
sans connaissance préalable des numéros des citoyens concernés.
Suite aux discussions avec les opérateurs de réseaux mobiles (MNO) et les conclusions de l’étude
d’un consultant externe, l’architecture qui pourrait être mise en place, pour rencontrer les objectifs de
BE-Alert pour l’envoi de messages sur les téléphones mobiles dans une zone de danger, est celle de
l’Alert-SMS.
L’Alert-SMS se base sur l’infrastructure existante chez les opérateurs et deux processus
successifs inédits :
La capture des données des mobiles concernés dans la zone de danger par BE-Alert;
La campagne SMS optimisée vers les mobiles.
Pour ce faire, le SPF Intérieur passera accord avec tous les opérateurs de téléphonie mobile pour
pouvoir établir des connexions vers leurs infrastructures, dans le but de recueillir l’information sur les
usagers dans leurs réseaux et d’ensuite lancer des SMS vers leurs abonnés respectifs identifiés.
Une initiative législative est également en cours pour rendre obligatoire la collaboration des
opérateurs mobiles à la réalisation de ce nouveau moyen d’alerte à la population.
Dans ce type de développement, plusieurs modèles de déploiement sont possibles et resteront
envisagés par le pouvoir adjudicateur. Le choix de l’approche architecturale n’est pas encore tranché
actuellement, mais il est évident que pour réaliser l’ajout de la fonctionnalité Alert-SMS sur la plate-
forme BE-Alert, il sera nécessaire pour le soumissionnaire de procéder à des discussions techniques
avec les trois opérateurs mobiles actuels (Proximus, Mobistar et Base) pour la mise en place concrète
de ce nouveau service.
4.6 Intégration d’autres applications via IP
L’intégration vers d’autres applications via IP permettra aux autorités de diffuser des messages en
incrustation sur les écrans électroniques de différents supports accessibles via des réseaux sécurisés
IP, comme, par exemple, des intégrations avec des panneaux d’affichages intelligents routiers, avec
des panneaux d’information dans les villes, à des grands réseaux PC d’entreprise (Pop-up sur PC
LAN), ou à des réseaux de diffusion radio ou TV.
4.7 Intégration avec un module de Gestion de crise
Le pouvoir adjudicateur, dans une autre procédure de marché public, compte se doter d’un portail de
sécurité. L'objectif de l’intégration avec ce futur système serait, par exemple, de pouvoir importer ou
exporter des données de contact à partir du portail de sécurité vers BE-Alert.
L'échange d'informations entre les deux bases de données devrait être entièrement automatique.
8
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
5 Développements (modules complémentaires)
5.1 Module PLP (Partenariat Local de Prévention)
Le PLP ou « Partenariat Local de Prévention » (ancien réseau d'information de quartier ou RIQ) est un
accord de collaboration entre les citoyens et la police locale au sein d’un quartier déterminé. Les
acteurs du projet sont les citoyens (collaborer), le coordinateur (diriger) et la police locale (concerter).
Grace au développement du module PLP, les membres et le coordinateur d’un PLP auront accès à un
site Web où ils pourront compléter et/ou mettre à jour leurs coordonnées. Le pouvoir adjudicateur
désire que le fonctionnement du PLP soit parfaitement intégré dans le système BE-Alert.
Si nécessaire, l’agent de police et/ou le coordonnateur peut lancer une procédure basée sur ces listes
de coordonnées et les membres du PLP seront automatiquement contacté (e-mail, SMS ou vocal) par
le système de communication.
5.2 Module RECRUTEMENT AUTOMATISE :
Ce module spécifique sert à traiter le recrutement automatisé de personnel, en cas de besoin de
renforts occasionnels, spécialement s’il s’agit de volontaires en appui (plongeurs, maîtres-chiens,…)
Ceci permet donc par exemple à un responsable de pouvoir lancer un rappel automatisé de manière
très rapide et de visualiser très clairement la liste des personnes qui auront répondus « présent ».
6 Travaux non prévus
Pour pallier à l’éventualité d’un module ou une intégration non prévue (évolution technologique,
redéfinition du scope du projet, nouveaux utilisateurs ou partenaires, …) le pouvoir adjudicateur se
réserve le droit de solliciter le soumissionnaire pour de nouveaux besoins identifiés au cours du
marché. La méthodologie décrite en introduction du présent document sera alors également utilisée.
7 Services d’accompagnement
Le soumissionnaire est tenu d’adapter sa structure et son organisation afin d’apporter un support
adéquat, non seulement à la bonne marche de son système, mais également au déploiement réussi
et rapide du projet vers les différentes autorités locales.
Pour ce faire, le soumissionnaire participera à toutes les initiatives nécessaires pour la publicité du
projet auprès des autorités et la mise en place du service dans l’organisation de ces autorités locales.
9
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
7.1 Versions de mise-à-jour et travaux
Lors de la planification des travaux à l'infrastructure, aux logiciels et aux bases de données connexes,
le soumissionnaire :
- Informera toujours par e-mail le pouvoir adjudicateur (équipe BE-Alert) ainsi que les
utilisateurs finaux concernés du planning des travaux réalisés. Pour chaque planning, il
indiquera également l'impact pour l'utilisateur final. Le pouvoir adjudicateur doit donner son
accord pour le planning et l'exécution des travaux. Le pouvoir adjudicateur se réserve le droit
de refuser le planning proposé des travaux et de demander un autre planning.
- Quelques jours avant le début des travaux prévus, les utilisateurs finaux susceptibles d'être
impactés reçoivent un rappel des travaux par e-mail. Ce message précise les processus et les
fonctionnalités susceptibles d'être impactés.
7.2 Manuel
Le soumissionnaire fournira d’office un mode d'emploi en français, néerlandais et allemand en format
PDF. Il doit être possible de consulter le manuel à l'aide du bouton "Aide" ou "F1" lorsqu'un utilisateur
final travaille dans le système.
Outre le manuel, une fiche comprenant les spécifications matérielles et logicielles qui sont supportées
par les applications devra être développée et tenue à jour continuellement, en fonction des nouvelles
versions mises à disposition.
La formation se déroulera principalement selon le principe "train the trainer". Dans un premier temps,
un groupe restreint de collaborateurs sera formé. Vu que, à court terme, de nombreux utilisateurs
finaux devront être formés, le soumissionnaire se chargera également de la formation.
7.3 Réunions de suivi
Un suivi de la prestation du soumissionnaire sera organisé via des réunions de travail régulières avec
l’adjudicateur. Sauf accord préalable et suivant une demande, au cas par cas, du soumissionnaire,
toutes les réunions auront lieu dans les locaux de l’adjudicateur. Les décisions d’organiser la réunion
par téléphone seront toujours préalablement approuvées par le pouvoir adjudicateur.
Les réunions permettront aux deux parties de communiquer sur les services délivrés, sur les
problèmes rencontrés et sur les services en développement sur base régulière, toutes les semaines
pour les réunions de Kick-Off, tous les mois pour les réunions opérationnelles, tous les trois mois pour
les réunions stratégiques, et tous les ans pour les audits, tel que décrit dans les points suivants.
7.4 Incident management & customer care contact center
Le soumissionnaire élaborera également une proposition de Help-Desk. BE-Alert est un processus
"business critical", donc toutes les composantes doivent toujours être disponibles pour les utilisateurs
finaux. Un incident peut être considéré comme tout événement entraînant une perte partielle ou totale
de fonctionnalité ou de la possibilité de fonctionnement.
Une dégradation de la qualité est également considérée comme un incident. La personne qui notifie
un problème sera toujours aidée par le Help-Desk dans sa langue, à savoir en français et néerlandais.
10
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
Le soumissionnaire assurera la réparation complète du problème signalé dans les délais impartis, tels
que décrits dans le SLA ou mettra au point un "work around" avec l'utilisateur final. Un "work around"
est une solution temporaire qui remet le service à un niveau acceptable pour le client ou l'utilisateur
final.
Le problème sera toujours traité dans la langue de l'utilisateur. En cas de problèmes, les utilisateurs
finaux doivent pouvoir le notifier de manière simple. Aucune question des utilisateurs ne peut être
refusée par le Help-Desk.
Le Help-Desk prend connaissance du problème et attribue une priorité à l'incident.
Les problèmes sont classés selon trois niveaux de priorité : critique, majeur, mineur. La priorité
attribuée à un problème est fonction de la nature du problème et de l'indisponibilité d'une
fonctionnalité.
e
Le Help-Desk est le front office et sera chargé du traitement de 1 ligne du problème. Le back-office
e
(traitement de 2 ligne) sera créé par le pouvoir adjudicateur. Le Help-Desk assurera l'escalade du
e
problème notifié vers le traitement de 2 ligne.
7.5 Service Level Agreement (SLA)
Le soumissionnaire présentera également dans son offre les paramètres qu’il est à même de mesurer
et qui pourraient faire l’objet d’une garantie (SLA) supplémentaire qui n’est pas reprise dans ce cahier
des charges. Après évaluation des Service Level Agreement (SLA) supplémentaires fournis, le
pouvoir adjudicateur se réserve le droit de négocier avec tous les soumissionnaires afin d’adapter
leurs offres en fonction de ces nouvelles garanties.
Pour les installations, une mise en service de la solution dans ses services standard sera mise en
place dans un délai maximum de trente (30) jours ouvrables après réception de la commande. Ce
délai est garanti par le soumissionnaire, pour autant qu’un autre accord n’ait pas été conclu, pour
toutes les mises en service standards. Les intégrations et les migrations, étant considérées comme
complexes, ne tombent pas sous cette garantie et font toujours l’objet d’une négociation avec
l’adjudicateur.
Pour le help-Desk, le temps de résolution ou "resolution time" est le temps total prévu dans le SLA
(Service Level Agreement). Le « resolution time » est le temps total de détection du problème, le délai
de réponse (cf. enregistrement et communication afférente) pour la réparation et le contrôle de la
fonctionnalité afin de vérifier si le problème a été résolu.
Conformément aux trois niveaux de priorité, critique (Critical), majeur (Major) et mineur (Minor), le SLA
comporte trois niveaux de normes et de pénalités, décrites ci-dessous :
Priorité critique (Critical priority) : Cette catégorie de problèmes comporte donc des problèmes
ayant un impact total sur le système et qui empêchent l'exécution de processus critiques
relatifs aux alertes ;
Priorité majeure (Major priority) :Il s'agit de toutes les notifications liées aux groupes de
problèmes ayant un impact critique sur les fonctionnalités, mais où les fonctions de base de
l'alerte restent possibles ;
11
CSC Système Alerte et Information à la PopulationPartie II – Description du marché
Priorité mineure (Minor priority) : Il s'agit de toutes les notifications de problèmes
subordonnés aux fonctionnalités et qui n'ont donc quasi aucun impact sur les processus
critiques d'alerte.
Au début, le soumissionnaire est responsable de l'infrastructure d’hébergement (hosting) du système,
de l'élaboration de l'accès et de la disponibilité du système. Le SLA STANDARD relatif à ces 3
composantes doit être de minimum 99,90 % et est inclus dans l’offre de base du soumissionnaire.
Le pouvoir adjudicateur se réserve le droit d’opter, à tout moment du contrat, pour des SLA plus
restrictifs. Pour ce faire, le soumissionnaire joindra également une offre de prix (options) pour les
niveaux de SLA suivants :
- 99,95% : SILVER SLA
- 99,99% : GOLD SLA
- 99,999 % : DIAMOND SLA
En sus des pénalités normales, le pouvoir adjudicateur se réserve le droit d’évoquer une pénalité
supplémentaire « de récidive ». Le SLA est actualisé une (1) fois par an après concertation entre le
pouvoir adjudicateur et le soumissionnaire. Le soumissionnaire assurera un rapportage SLA mensuel
avec les KPI (Key Performance Indicator)
7.6 ALERT-DESK (Option) :
A la demande, le « Alert-Desk » pourra répondre à l’appel d’un représentant de l‘autorité, l’identifier et
déclencher la campagne décrite par téléphone. Le service de l’Alert-Desk doit toujours être disponible:
7 jours/7, 24 heures/24 et 365 jours par an.
L’Alert-Desk est un service payant qui doit obligatoirement être offert comme une option, et qui peut
être commandé à n’importe quel moment du contrat. Le pouvoir adjudicateur se réserve le droit de
commander cette option ou non, pour l’ensemble des autorités concernées. Le service ne pourra être
commandé pour une partie des utilisateurs de la solution.
7.7 Module de facturation
Le soumissionnaire assurera la facturation et la perception des factures. Le système permet de gérer
la facturation des services et des messages connexes de manière indépendante pour un nombre
considérable d'entités différentes. Une facturation globale au pouvoir adjudicateur dirigeant n'est pas
autorisée. Chaque pouvoir adjudicateur non-pilote, qui signe la convention d'adhésion et passe une
commande, sera considéré comme une entité de facturation distincte, sauf mention expresse du
pouvoir adjudicateur.
Une attention particulière sera consacrée au fait que le soumissionnaire doit prévoir dans sa
comptabilité et son système de facturation la gestion des amendes prévues dans la partie «Service
Level Agreement (SLA)».
12
CSC Système Alerte et Information à la PopulationVous pouvez aussi lire
