Classification : Confidentiel / Non sensible interne / Non sensible

Transcription

Classification : Confidentiel / Non sensible interne / Non sensible public
1 / 113
Demande d’information Téléphonie et Centre d’Appels
Sommaire
1
Présentation générale de la demande d’information ....................................................... 5
1.1
Programme SI-Samu............................................................................................... 5
1.2
Stratégie d’achat du programme SI-Samu ............................................................... 5
1.3
Objet de la demande d’information .......................................................................... 7
2
Processus de gestion de la demande d’information ........................................................ 8
2.1
Contenu de la demande d’information ..................................................................... 8
2.2
Modalités de réponse .............................................................................................. 9
2.3
Traitement des réponses et suites données à la demande d’information................. 9
3
Présentation du système SI-Samu ................................................................................10
3.1
Description du système envisagé ...........................................................................10
3.1.1
Présentation de l’architecture retenue .............................................................10
3.1.1.1
Principe d’architecture de téléphonie retenu.............................................10
3.1.1.2
Architecture détaillée de la solution SI-Samu ...........................................10
3.1.1.3
Rôles des opérateurs de télécommunication dans l’architecture SI-Samu11
3.1.2
Principe de distribution géographique des infrastructures techniques .............12
3.1.3
Logique nominale d’acheminement des appels ...............................................13
3.1.4
Logique nominale d’accès aux applicatifs........................................................14
3.1.5
Capacités d’échange avec les partenaires et les logiciels de santé .................14
3.1.6
Focus sur les modalités d’interaction entre le SI-Samu et Antarès ..................15
3.1.7
Capacité d’archivage du SI-Samu ...................................................................16
3.1.8
Dimensionnement technique du SI-Samu et gestion de crise ..........................16
3.1.9
Une architecture hautement disponible ...........................................................17
3.1.9.1
Les mécanismes de haute disponibilité du SI-Samu ................................17
3.1.9.2
Focus sur la sécurisation de l’étape de collecte........................................23
3.1.9.3
Focus sur les dispositifs de sécurisation de l’opérateur de service ...........24
3.1.10 Prise en compte de la dynamique d’évolution des technologies ......................25
3.2
Particularités du système attendu...........................................................................26
3.2.1
La capacité d’accueil téléphonique ..................................................................27
3.2.2
La gestion des modes dégradés......................................................................27
3.2.3
La qualité de service .......................................................................................28
3.2.4
Le respect des normes ....................................................................................28
3.2.5
La réversibilité .................................................................................................29
3.2.6
La haute disponibilité.......................................................................................29
3.3
Hypothèses de dimensionnement ..........................................................................32
4
Informations attendues par l’ASIP Santé .......................................................................33
4.1
Informations sur les orientations retenues ..............................................................33
4.2
Informations sur les composants cœur du système ................................................34
4.2.1
Serveurs vocaux interactifs .............................................................................34
4.2.1.1
Besoins ....................................................................................................34
4.2.1.2
Principes structurants ...............................................................................36
4.2.1.3
Demande d’informations ..........................................................................37
4.2.2
Fonctions de téléphonie ..................................................................................40
4.2.2.1
Besoins ....................................................................................................40
4.2.2.2
Principes structurants ...............................................................................42
Classification : Public
2 / 113
4.2.2.3
4.2.3
Intégration des fonctions IPBX dans un domaine opérateur ............................52
4.2.3.1
Besoins ....................................................................................................52
4.2.3.2
4.2.4
Fonctions d’ACD locale ou centrale.................................................................55
4.2.4.1
Besoins ....................................................................................................55
4.2.4.2
4.2.5
Conférence ou communications multi-lignes ...................................................62
4.2.5.1
Besoins ....................................................................................................62
4.2.5.2
4.2.6
Service de couplage de téléphonie..................................................................64
4.2.6.1
Besoins ....................................................................................................64
4.2.6.2
4.3
Informations sur les composants connexes au système .........................................69
4.3.1
Enregistrement des conversations téléphoniques ...........................................69
4.3.1.1
Besoins ....................................................................................................69
4.3.1.2
4.3.2
Affichage et diffuseurs des informations ..........................................................75
4.3.3
Gestion multicanal ...........................................................................................76
4.3.3.1
Besoins ....................................................................................................76
4.3.3.2
4.3.4
Autres fonctionnalités potentielles ...................................................................81
4.4
Informations liées à l’exploitation de la solution ......................................................82
4.4.1
Statistiques d’appels .......................................................................................82
4.4.2
Supervision des appels ...................................................................................82
4.4.3
Gestion des indicateurs de service ..................................................................83
4.4.4
Contraintes d’exploitation ................................................................................84
4.4.4.1
Gestion des environnements ....................................................................84
4.4.4.2
Configuration type de production ..............................................................85
4.5
Informations transverses ........................................................................................86
4.5.1
Références similaires ......................................................................................86
4.5.2
Gestion des tickets d’appels/communication et interaction ..............................86
4.5.2.1
Besoins ....................................................................................................86
4.5.2.2
4.5.3
Qualité de service ...........................................................................................90
4.5.3.1
Besoins ....................................................................................................90
4.5.3.2
4.5.4
Tarification ......................................................................................................94
4.5.4.1
Besoins ....................................................................................................94
4.5.4.2
4.6
Organisation des fournisseurs de solutions ............................................................97
4.6.1
Organisation de la maintenance ......................................................................98
4.6.2
Approvisionnement .........................................................................................99
4.6.3
Gestion des évolutions ....................................................................................99
4.6.4
Prise en compte des demandes spécifiques ...................................................99
4.6.5
Processus d’escalade .....................................................................................99
3 / 113
5
Annexes ......................................................................................................................100
5.1
Besoin métier .......................................................................................................100
5.2
Cinématique de l’appel et architecture..................................................................101
5.3
Cinématique de traitement du service d’accueil vocal ..........................................102
5.4
Cinématique de traitement d’un appel entrant ......................................................103
5.5
Intégration des réseaux Radio ..............................................................................104
5.5.1
Présentation du réseau ANTARES................................................................104
5.5.2
Les gestionnaires de voies radio ...................................................................105
5.5.3
Configuration des SDIS .................................................................................109
5.6
Glossaire ..............................................................................................................109
4 / 113
1 Présentation générale
d’information
de
la
demande
1.1 Programme SI-Samu
Le programme SI-Samu vise à apporter une réponse fonctionnelle et technique adaptée aux
difficultés constatées ces dernières années par les Centres de Réception et de Régulation des
Appels (Samu-Centre 15) et à garantir à la population une égalité d’accès à des soins de qualité
sur le territoire national. Cette modernisation constituera également une harmonisation et une
interopérabilité à l’échelle régionale et nationale des équipements de télécommunication et
d’information des Samu. Ainsi, l’entraide entre les Samu et la coopération avec leurs partenaires
seront facilitées, tant au quotidien que dans la gestion des situations exceptionnelles. En outre,
ce nouveau dispositif permet de développer des travaux de recherche multicentriques sur la
régulation médicale et sur les données qui en sont issues.
La Ministre chargée de la santé a pris la décision de poursuivre le programme de modernisation
du SI-Samu et en a fait l’annonce, le 4 juin 2014, au Congrès Urgences, en soulignant
notamment qu’il s’agissait de « permettre plus de coopération et une meilleure coordination de
l’ensemble des acteurs qui interviennent dans le champ des soins urgents ».
L’amorçage du programme constitue la première étape de la phase de réalisation du SI-Samu.
Cette étape qui a démarré en septembre 2014 est prévue pour durer 18 mois. Elle répond aux
objectifs suivants :




Mise en place de l’organisation et de la gouvernance du programme ;
Constitution de l’équipe de projet SI-Samu, avec le recrutement d’expertises spécifiques ;
Lancement des procédures de marchés publics requises ;
Démarrage des travaux d’expression détaillée du besoin métier.
L’étude de faisabilité, finalisée en 2014 et disponible sur le site esante.gouv.fr1, détaille les
enjeux et orientations de ce programme de modernisation SI-Samu.
1.2 Stratégie d’achat du programme SI-Samu
Comme présenté par l’ASIP Santé – organisme en charge de la maîtrise d’ouvrage
opérationnelle du programme SI-Samu – lors de la session d’information tenue le 27 janvier
2015 à la maison de la Chimie, la stratégie d’achat du SI-Samu (en cours de finalisation)
prévoit une réalisation de ce système de télécommunication et d’information mutualisé via 5
marchés distincts :

M1 - Marché de collecte et de distribution des appels des Samu ; hébergement
et fourniture des infrastructures télécommunications du SI-Samu (marché
« Hébergement, téléphonie et distribution »). Ce marché a notamment pour
objet la réalisation de prestations :
o De services de télécommunication standards et hautement disponibles (y
compris le SVI), avec une maîtrise de la bascule entre des architectures TDM
et VoIP ;
o D’hébergement de l’ensemble des infrastructures techniques centrales du SISamu ;
1
http://esante.gouv.fr/actus/politique-publique/lancement-de-la-phase-de-realisation-du-programmede-modernisation-si-samu
5 / 113




M2 - Marché de développement / maintenance des applicatifs opérationnels du
SI-Samu, et fourniture / exploitation des infrastructures nécessaires pour ces
applicatifs (marché « Logiciels applicatifs SI-Samu »). Ce marché vise à la
réalisation de la partie applicative du SI-Samu comprenant :
o Un logiciel de régulation médicale (LRM) ;
o Le couplage téléphonie informatique (CTI) et le bandeau téléphonique
étendu ;
o Le serveur vocal interactif (SVI). Le composant SVI est fourni par le marché
M1 tandis que le titulaire du marché M2 est responsable des développements
applicatifs relatifs au SVI ;
o Des outils de cartographie ;
o Des consoles d’administration technique et fonctionnelle ;
M3 - Marché de mise en place et de maintien du réseau SI-Samu (marché
« Réseau Wan IP MPLS »). Ce marché est relatif aux prestations de services de
télécommunication réseau banalisés ;
M4 - Marché de développement, de maintenance et de fourniture des
infrastructures du système décisionnel SI-Samu (marché « BI SI-Samu »). Ce
marché a pour objet de fournir aux acteurs du programme SI-Samu des outils de
pilotage et de suivi de l’activité (il nécessite une stabilisation préalable du périmètre
des marchés M1 et M2 et sera donc lancé dans un second temps) ;
M5 - Marché de prestation d’architecture, d’intégration / qualification et
d’exploitation / support du SI-Samu (marché « Architecture, Intégration &
Qualification, Exploitation & Support global). Ce marché porte sur :
o Des prestations de conseil en architecture, relativement aux différentes filières
techniques nécessaires à la maitrise du SI-Samu (téléphonie, réseau, radio,
applications) ;
o Des prestations de recette (intégration et qualification) des différents
composants du SI-Samu issus des marchés M1, M2, M3 et M4 ;
o La mise en place des processus d’administration et la fourniture des moyens
d’analyse et de coordination du support et de l’exploitation (technique et
applicative).
Les marchés M1 à M4 assurent l’exploitation applicative et le support de niveau 3 des
composants qu’ils réalisent ou fournissent.
Schématiquement, cette stratégie d’achat peut être représentée de la manière suivante :
6 / 113
1.3 Objet de la demande d’information
En amont des différents appels d’offres visant à construire le futur SI-Samu, le présent
document est à destination des industriels fournisseurs de solutions liées à la téléphonie,
centres d’appels et écosystèmes associés, fournisseurs qui ne seront pas a priori
directement destinataires des futurs appels d’offres, mais dont les solutions seront
proposées et incluses par les répondants à ces appels d’offres.
Dans ce contexte, les objectifs poursuivis par l’ASIP Santé via la présente demande
d’information sont de :





Présenter l’architecture cible du SI-Samu en mode nominal ainsi qu’en modes
dégradés, et, sur cette base, collecter auprès des industriels du marché les
remarques, conseils ou propositions alternatives à même d’améliorer les
caractéristiques de l’architecture cible du SI-Samu ;
Identifier la capacité des solutions et produits disponibles sur le marché à s’intégrer à
l’architecture préconisée ;
Mieux comprendre l’articulation entre le choix des différents composants de
l’architecture du SI-Samu, notamment entre les composants de type IPBX et les
composants de type CTI ;
Mieux identifier la répartition possible des fonctions d’intelligence de gestion des
contacts entre les composants IPBX installés à un niveau central et ceux installés
localement ;
In fine, d’accroître la capacité de l’ASIP Santé à publier des marchés de réalisation
du SI-Samu intégrant des spécifications conformes à l’état de l’art, en s’appuyant sur
une connaissance accrue des fournisseurs de solutions.
Relativement à la stratégie d’achat envisagée supra, les informations collectées via la
demande d’information auront pour l’ASIP Santé un intérêt particulier lors de la rédaction du
marché M1, relatif à la collecte et à la distribution des appels des Samu ainsi qu’à
l’hébergement et la fourniture d’infrastructures pour le SI-Samu et lors de la rédaction du
marché M2, portant sur le développement et la maintenance des applicatifs opérationnels du
7 / 113
SI-Samu ainsi que la fourniture et l’exploitation des infrastructures nécessaires pour ces
applicatifs.
2 Processus de gestion de la demande
d’information
2.1 Contenu de la demande d’information
La demande d’information est composée :


Du présent document, celui-ci visant à :
o Présenter le contexte général du programme SI-Samu et les modalités de
gestion de la demande d’information ;
o Sensibiliser les répondants au caractère vital de la solution mise en œuvre,
avec un focus sur la haute disponibilité demandée ;
o Permettre une meilleure connaissance des répondants ;
o Préciser le contexte technique de mise en œuvre du SI-Samu, selon une
approche thématique (SVI, CTI, etc.) et exposer, sur cette base, les
interrogations de l’ASIP Santé ;
o Obtenir du marché un regard critique sur les orientations prises par l’ASIP
Santé ;
o Préciser les questionnements transverses aux composants techniques mis en
œuvre (tarification, gestion de la qualité de service, etc.) ;
D’un cadre de réponse, reprenant l’ensemble des questions posées via le présent
document et permettant aux répondants de structurer leur réponse, chaque
répondant pouvant adresser tout ou partie des questions posées dans le
présent document (selon le périmètre de ses activités dans le domaine des
solutions de télécommunications).
La demande d’information est décomposée en 19 domaines, soit :





6 domaines liés au cœur du système :
o Les serveurs vocaux interactifs ;
o Les fonctions de téléphonie ;
o L’intégration des fonctions IPBX dans un domaine opérateur ;
o Les fonctions d’ACD centrales ou locales ;
o Les conférences ou communications multi-lignes ;
o Le service de couplage téléphonie-informatique ;
4 domaines connexes au système :
o L’enregistrement des conversations ;
o L’affichage et les diffuseurs d’informations ;
o La gestion du multicanal ;
4 domaines liés à l’exploitation du système :
o Les statistiques d’appels ;
o La supervision des appels ;
o La gestion des indicateurs de service ;
o Les contraintes liées à l’exploitation ;
4 domaines transverses :
o Les références du fournisseur;
o La gestion des tickets d’appels/communication et interaction ;
o La qualité de service ;
o La tarification ;
1 domaine lié à l’organisation du fournisseur.
8 / 113
Cette demande d’information est disponible sur le site esante.gouv.fr.
2.2 Modalités de réponse
La date limite de réponse à la présente demande d’information est fixée au 10 avril 2015.
Les répondants (équipementiers et les éditeurs souhaitant répondre à cette demande
d’information) sont invités à transmettre leur réponse à l’ASIP Santé par mail à l’adresse
suivante : [email protected] :


En utilisant le document « cadre de réponse » au format prévu à cet effet ;
En mettant en objet du mail « Demande d’Information Téléphonie et Centres
d’Appels ».
Les réponses sont attendues, de préférence, en langue française.
Au vu de la typologie des questions posées, cette demande d’information s’adresse
prioritairement aux fournisseurs et éditeurs de solution de type SVI, CTI, ACD, enregistreurs,
etc. Cependant, tout répondant peut transmettre sa réponse à l’ASIP Santé.
En fonction de l’étendue de ses propres capacités, chaque répondant est invité à répondre
aux domaines thématiques le concernant. Ainsi, il est demandé à chaque répondant de
bien vouloir préciser en annexe du cadre de réponse les domaines auxquels il répond.
Autant que possible, chaque répondant est invité à fournir les informations pertinentes
le concernant pour l’ensemble des domaines transverses.
Les informations fournies par les répondants sont susceptibles d’être publiées par
l’ASIP Santé dans le cadre du lancement de ses marchés. Aussi, il est demandé à chaque
répondant de bien vouloir préciser de manière expresse – au sein de sa réponse – les
éléments protégés par un secret industriel ou commercial ou qu’il juge confidentiels.
Eu égard au respect et à la protection du secret industriel et commercial, l’ASIP Santé
s’engage à ne communiquer aucun de ces éléments désignés comme tels par les
répondants. Pour ce faire, chaque répondant utilise une balise de début et de fin de
confidentialité au sein de sa réponse (<CONFIDENTIEL> ; </CONFIDENTIEL>).
2.3 Traitement des réponses et suites données à la
demande d’information
L’ensemble des réponses reçues dans les délais susmentionnés sera étudié par
l’ASIP Santé. Cette étude sera de nature à permettre à l’ASIP Santé d’affiner ses besoins
pour le programme SI-Samu et de préciser ses exigences relatives aux futurs marchés de
mise en œuvre du SI-Samu.
En revanche, la présente demande d’information ne constitue ni une consultation, ni un
appel d’offres, ni un quelconque engagement de l’ASIP Santé à lancer ultérieurement une
opération sur le même objet.
Réciproquement, les réponses à la demande d’information ne constituent pas des
engagements contractuels ou précontractuels de la part de leurs auteurs, y compris pour les
informations liées à la tarification des services.
Enfin, aucun répondant à cette demande d’information ne pourra prétendre à une
rémunération ou indemnisation pour les réponses apportées.
9 / 113
3 Présentation du système SI-Samu
3.1 Description du système envisagé
3.1.1 Présentation de l’architecture retenue
3.1.1.1 Principe d’architecture de téléphonie retenu
L’architecture retenue pour le SI-Samu s’appuie sur les principes fondamentaux suivants :





Une centralisation de l’ensemble des briques de téléphonie, centre d’appel et
écosystème associé dans deux datacenters nationaux ;
Une interconnexion de l’ensemble des CRRA et des Datacenters via un réseau WAN
MPLS ;
Le maintien de fonctions de téléphonie en local (Gateways au sein de chaque
CRRA) ;
Une gestion des flux de communication entrant/sortant :
o En TDM au niveau de chaque CRRA en mode nominal ;
o En IP via le WAN MPLS en mode secours ;
Une architecture hautement résiliente au niveau de tous les composants du service.
3.1.1.2 Architecture détaillée de la solution SI-Samu
Le schéma ci-dessous propose une représentation des infrastructures qui permettent de
mettre en œuvre un système SI-Samu à haute disponibilité :

Recours à un opérateur de collecte et à un opérateur de service. L’opérateur de
service offrira les fonctions de Serveur Vocal Interactif (SVI) et des fonctions de
routage et distribution de type IPBX (autocommutateur). L’accueil de l’appel est
déporté vers un opérateur de service : ceci permet d’augmenter considérablement la
capacité d’accueil, la capacité de routage, la possibilité de modifier dynamiquement
les appels, tout en conservant en nominal le fonctionnement actuel. En cas de crise
sanitaire aigue cet opérateur servira d’amortisseur de charge pour les CRRA,
permettant la qualification des appels par des systèmes interactifs vocaux avant de
présenter les appels aux Samu ou sites de crise ad hoc suivant une stratégie
configurable.
10 / 113

Mise en œuvre de deux datacenters téléphoniques chez un opérateur de
service (site primaire et site secondaire) :
o Chacun de ces datacenters hébergera les infrastructures de routage
téléphonique de type IPBX, ainsi que les applications SI-Samu ;
o Chaque datacenter est en capacité de traiter la charge liée à l’activité
nationale des Samu.

Conservation en local, au sein des Samu, de tous les matériels nécessaires à la
prise d’appel et à la gestion des appels en cas d’incidents graves impactant les
systèmes situés en amont. Les enregistreurs vocaux et les infrastructures de
radiocommunication sont également maintenus dans les centres de réception et de
régulation des appels. Ces principes garantissent le maintien de la capacité de prise
d’appel, dans le respect des obligations juridiques (enregistrement, …) en cas
d’indisponibilité des équipements centraux.

Mutualisation du système d’information afin de permettre un potentiel partage
des informations. Les informations et logiciels sont hébergés au sein de deux
datacenters applicatifs distincts. Les applications sont accessibles via un réseau
privé sécurisé à l’état de l’art de type WAN IP-MPLS.

Couplage téléphonie-informatique afin d’assurer une remontée directe automatisée
de l’ensemble des informations relatives à l’appel et au patient le cas échéant. L'ASIP
Santé souhaite également que les dossiers de régulation médicale (DRM) soient
enrichis de leurs données phoniques et plus généralement de leurs données
multicanales afin de réaliser un reporting multi dimensionnel.
Grâce à ce modèle d’architecture, en cas de défaillance locale d’un Samu pour des
problèmes techniques ou d’incapacité d’un Samu à traiter un pic de charge lié à un
évènement conjoncturel, le SI-Samu permet de basculer la charge vers un autre Samu
afin de fournir au niveau de service identique aux appelants.
3.1.1.3 Rôles des opérateurs de télécommunication dans l’architecture SI-Samu
Le schéma ci-dessous propose une vue plus détaillée de l’architecture retenue, et en
particulier de l’architecture prévue au niveau des différents opérateurs :
11 / 113
3 rôles d’opérateurs de télécommunication sont identifiés dans ce schéma :
 Opérateurs de boucle locale :
o Chaque opérateur fournit les appels émis par un tiers à l’opérateur de
collecte, enrichis par les données de géo-localisation. Cette partie de
l’acheminement de l’appel ne fait pas partie du SI-Samu mais constitue le
départ de l’appel téléphonique par le citoyen ;
 Opérateurs de collecte :
o L’opérateur de collecte est en charge de globaliser les appels et de leur
appliquer les règles de chaque PDAAU ;
o L’opérateur de collecte applique ensuite la stratégie de traitement unifiée en
fonction de la charge globale des appels ;
 Opérateur de service :
o Apporte des fonctionnalités avancées telles que :
 La prise en charge des fonctionnalités de pré-routage et de serveurs
vocaux, via les serveurs frontaux SVI qui sont capables de jouer les
scénarii fonctionnels d’accueil vocal et de qualification de l’appelant ;
 L’hébergement des composants de routage, en particulier ceux qui
doivent communiquer en voix sur IP avec les équipements opérateurs.
3.1.2 Principe de
techniques
distribution
géographique
des
infrastructures
Parmi les mécanismes de sécurisation mis en œuvre permettant de garantir la haute
disponibilité du système, l’architecture de type « cluster de haute disponibilité » permet de
répartir le traitement des données et des évènements entre plusieurs infrastructures, de
manière à permettre la continuité des traitements lors de la défaillance de l’un des nœuds.
Le schéma ci-dessous propose une représentation du cluster de haute disponibilité
envisagé.
12 / 113



Deux datacenters applicatifs (site primaire et site secondaire) en redondance l’un
de l’autre utilisés et qui sont synchronisés en quasi temps réel.
o Chacun de ces datacenters héberge l’ensemble des équipements du
Couplage Téléphonique Informatique (CTI) et l’ensemble des briques
applicatives du système d’information dénommé globalement Logiciel de
Régulation Médicale. Concernant le serveur LRM, il sera localisé dans le
datacenter ;
o Chaque datacenter seul peut gérer la charge d’activité nationale ;
Un large réseau dédié WAN (Wide Area Network) d’architecture IP MPLS
(MultiProtocol Label Switching) pour offrir de la qualité de service et permettre
l’interconnexion de l’ensemble des CRRA entre eux, avec les deux datacenters
applicatifs et avec les infrastructures de l’opérateur de service ;
Au sein de chaque CRRA, la présence d’équipement de téléphonie,
d’enregistrement des conversations vocales et de radiocommunication. Il s’agit
de gateway téléphoniques avec licence SAS (Stand Alone Survivability), de
gestionnaires de voix radio (GVR) permettant l’interconnexion avec Antarès,
d’enregistreurs des conversations vocales, d’équipements réseaux et d’une
connexion internet. Le maintien en local d’un nombre d’équipements non négligeable
introduit un maillage de l’architecture du SI-Samu à même de garantir une robustesse
forte au niveau phonie (téléphonie et radiocommunication).
Les infrastructures techniques hébergées par l’opérateur de service n’apparaissent pas au
sein de ce schéma.
3.1.3 Logique nominale d’acheminement des appels
L’ensemble des appels est acheminé vers l’opérateur de collecte, celui-ci délivrant ensuite
ces appels à l’opérateur de service. Il peut également être envisagé, pour les opérateurs
ayant des fonctions de type routage intelligent (changement de configuration rapide au sein
des réseaux), un acheminement direct entre leurs abonnés et l’opérateur de service.
Au sein des infrastructures SI-Samu localisées chez l’opérateur de service, des échanges
applicatifs sont initiés entre le service SVI, le service ACD (Automatic Call Distribution) et le
service CTI (Couplage Téléphonie Informatique) pour que l’intelligence centralisée de la
solution détermine le routage de chaque appel. Deux cas de figure peuvent se produire :


Situation standard : chaque appel est traité par le CRRA en charge de la zone
géographique de provenance de l’appel. Dans le cas où les T2 de ce CRRA sont
défectueuses, l’opérateur de service - qui aura la capacité technique nécessaire à
l’identification de ce problème - pourra continuer à acheminer ces appels vers ce
même CRRA via le WAN central ;
Situation d’entraide : l’appel sera envoyé vers un autre CRRA que celui
géographiquement en charge de l’appel (dit CRRA de référence pour l’appel)
pour des raisons de suractivité du CRRA de référence ou de défaillances de ses
infrastructures.
Chaque appel est donc acheminé par l’opérateur de service au sein d’un CRRA déterminé et
est traité par un équipement local de téléphonie (gateway) qui assure sa conversion en
téléphonie sur IP et son acheminement jusqu’au poste de l’agent (assistant à la régulation
médicale, médecin de régulation urgentiste, …).
13 / 113
3.1.4 Logique nominale d’accès aux applicatifs
Les agents d’un CRRA travaillent d’un point de vue applicatif avec deux outils principaux :

L’interface graphique de téléphonie (« bandeau ») : il s’agit d’une véritable
application à part entière qui offre une console de supervision de l’activité globale
d’un CRRA et permet de visualiser la totalité des appels en cours à tout instant ;
 Le logiciel de régulation médicale (LRM/SIG) : il s’agit de l’application métier
permettant de gérer le processus de prise en charge d’un appel médical urgent.
Ce logiciel intègre en particulier des outils de cartographie.
Ces deux applications sont accessibles depuis un poste de travail équipé d’un navigateur
internet (ou d’un autre client facilement déployable) qui accède en mode nominal aux
serveurs LRM et CTI via le réseau WAN.
3.1.5 Capacités d’échange avec les partenaires et les logiciels de santé
Les Samu sont en interconnexion avec de nombreux partenaires (SDIS, médecine libérale,
ambulanciers privés, pharmacie, forces de l’ordre, …). Le SI-Samu doit aussi pouvoir
s’interfacer avec les logiciels de santé structurants que sont le DMP, la MSSanté ou encore
le ROR.
L’architecture retenue vise à implémenter des échanges standardisés avec chaque type
d’acteurs au travers de la mise en place de connecteurs conformes aux spécifications de
référence des interfaces. Ces connecteurs sont disponibles depuis les datacenters
applicatifs du SI-Samu et accessibles via un canal sécurisé sur internet. Le SI-Samu
respecte suivant la nature du tiers les standards en vigueur. Le schéma ci-dessous présente
les quatre catégories existantes :
Interfaces du
DSFT-DMP
Parmi les partenaires, le cas des échanges informatiques avec les SDIS (lien 15-18) est
spécifique car les interfaces sont soumises aux exigences AFNOR NF-3992 « logiciels de
sécurité civile ». Le SI-Samu implémentera un interfaçage compatible à ces exigences.
2
*NF-399 est une marque gérée par la société INFOCERT par l’intermédiaire du GT399. L’ASIP
Santé aura accès à l’ensemble de la documentation utile pour le programme SI-Samu dans le respect
des règles fixées en accord avec la société INFOCERT.
14 / 113
3.1.6 Focus sur les modalités d’interaction entre le SI-Samu et Antarès
En plus des communications téléphoniques, les Samu utilisent la radio pour échanger avec
certains de leurs partenaires. Le programme Antares (Adaptation Nationale des
Télécommunication Aux Risques Et aux Secours) s’inscrit dans le cadre de ces échanges. Il
vise à une interopérabilité des moyens de communication des différents services publics
participant aux missions de la sécurité civile. À ce titre, il permet aux SDIS et aux Samu de
communiquer via un réseau radio numérique propriétaire crypté.
Selon une étude menée par la DGOS en 2013, 79% des Samu ont déployé Antares ou sont
en cours de déploiement. Dans le cadre de ce déploiement, certains Samu ont choisi de
s’équiper de leurs propres moyens radio Antares, alors que d’autres, pour des raisons
essentiellement économiques, ont choisi d’utiliser les moyens des SDIS.
Pour les premiers, le SI-Samu permettra une intégration des appels radio de sorte qu’un
appel radio reçu (sur un canal surveillé par un utilisateur) puisse :



Être réceptionné par un agent de régulation ;
Pris en compte par les fonctions de pilotage et de supervision de l’activité ;
Être réécouté en différé.
Antares permet également des échanges de données. Ces échanges qui doivent s’effectuer
conformément aux exigences AFNOR NF-399 « logiciels de sécurité civile » seront pris en
compte par le SI-Samu.
Pour les Samu n’ayant pas déployé Antares, l’architecture type proposée (cf. figure suivante)
permet à un Samu d’accéder à l’infrastructure Antares tout en conservant la maitrise totale
de ses moyens radios.
Dans cette configuration, le Samu devra déployer localement :





Un Gestionnaire de Voie Radio (GVR). Le GVR est l’équipement permettant la
gestion et l’orchestration des communications radio ;
Les postes opérateurs radio ;
Une « Access Gate » (AG) radio nominale (l’AG radio est le point d’accès au réseau
Antares) ;
Un lien vers une AG radio de secours localisée sur un site distant (en cas de
défaillance de l’accès nominal, le réseau Antares peut être atteint via l’AG de
secours) ;
Un enregistreur.
Le GVR et les enregistreurs présents dans un Samu garantissent à celui-ci la maitrise de ses
communications radios et de ses enregistrements. Le GVR offre également la possibilité de
piloter à distance d’autres postes opérateurs radio pour le compte d’autres Samu.
Dans le schéma présenté ci-après, le lien symbolisé entre le Samu et le SDIS permettra
l’accès aux données du serveur de localisation automatique des véhicules (AVL), aux
données du serveur de transmission automatique des alertes (TAA) et servira aux échanges
effectués dans le cadre du lien 15-18.
Les points notables de cette configuration sont :

L’indépendance des Samu par rapport au SDIS pour les communications radio ;

La maitrise totale du Samu sur les réseaux radio nécessaires à son fonctionnement ;

L’enregistrement numérique au sein du Samu de toutes les communications radio,
qu’elles soient prises en charge par l’AG nominale ou de secours ;

La possibilité pour un Samu d’utiliser les ressources radio d’un autre Samu grâce à
l’interconnexion entre GVR.
15 / 113
SDIS
Samu
Site de secours
3.1.7 Capacité d’archivage du SI-Samu
Le SI-Samu archive l’ensemble des données qu’il produit ou dont il a besoin pour fournir le
service attendu (dossier de régulation médicale, enregistrements vocaux des conversations
téléphoniques ou radio, données référentielles, protocoles de prises en charge, logs
techniques, etc..).
Parmi ces données, certaines sont par nature volumineuses, comme par exemple les
enregistrements vocaux des conversations téléphoniques ou radio. De plus, certaines de ces
données sont soumises à des obligations légales de conservation.
D’un point de vue technique, le SI-Samu prévoit la conservation pendant 10 ans de
l’ensemble des données qu’il archive. Le dossier de régulation médicale devant être
conservé 20 ans, le SI-Samu doit être en capacité de restituer ces archives à chaque
établissement de santé concerné, afin que celui-ci assure l’archivage de ces données
pendant 10 années supplémentaires.
D’un point de vue technique, une interface spécifique du SI-Samu vers le SIH de chaque
établissement de santé sera mise en place afin d’assurer l’envoi régulier de ces données
archivées. Cette interface ne sera pas mise en place de manière prioritaire, puisqu’utile
uniquement après 10 ans d’utilisation du SI-Samu.
3.1.8 Dimensionnement technique du SI-Samu et gestion de crise
Le SI-Samu est dimensionné pour faire face, en mode nominal, à une volumétrie d’appels
simultanés supérieure de 10% au pic d’appels simultanés actuellement constaté et évalué à
4300 appels simultanés au niveau national. L’activité cyclique des Samu fait que ce
dimensionnement permet au SI-Samu de largement faire face à l’activité régulière et aux
pics d’activité liés à des crises locales.
En cas de gestion de crise sanitaire nationale, le nombre d’appels simultanés peut
augmenter de manière significative pour atteindre 10 000 à 15 000 appels simultanés. Il n’est
économiquement pas possible d’envisager de construire et de maintenir une infrastructure
SI-Samu nominalement dimensionnée pour ces très hautes volumétries de prise d’appels
alors que ces capacités ne seront quasiment jamais utilisés.
16 / 113
L’arrivée d’une crise sanitaire majeure n’est généralement pas immédiate et laisse le temps
(plusieurs semaines voire mois) nécessaire au lancement de projets d’infrastructure
d’augmentation capacitaire. En cas de crise sanitaire majeure immédiate (explosion,
accidents, évènement climatique), la fonctionnalité de SVI avec la pré-qualification de l’appel
permettra d’organiser au mieux la réponse aux appels d’urgence suivant une stratégie de
routage spécifique (par exemple en concentrant les appels liés à la catastrophe sur un
nombre limité de CRRA, laissant les autres CRRA fonctionner normalement).
3.1.9 Une architecture hautement disponible
3.1.9.1 Les mécanismes de haute disponibilité du SI-Samu
Par son activité de gestion des appels médicaux urgents, chaque Samu doit être une
organisation hautement fiable (High Reliability Organisation - HRO) du point de vue de ses
infrastructures physiques (par exemple avec la présence d’une salle de régulation distincte
de la salle de crise, etc.), du point de vue organisationnel (par exemple avec la disponibilité
d’une équipe formée de taille suffisante pour porter une activité 24h/24 et 7J/7, etc.) et donc
également du point de vue de ses équipements techniques et informatiques. Sur ce dernier
aspect, l’architecture du SI-Samu assure la continuité de fonctionnement à la fois par la
redondance de l’ensemble de ses équipements techniques, mais également par la mise en
place systématique d’au moins deux modes (un mode d’accès nominal, sécurisé par un ou
plusieurs modes d’accès alternatifs) pour l’acheminement des appels téléphoniques et
l’accès aux applicatifs métiers.
Le principal risque d’une solution unique est qu’en cas de défaillance de tout ou partie des
équipements mutualisés, l’ensemble des CRRA se retrouvent dans une incapacité d’action.
Pour cette raison, l’architecture technique retenue a été élaborée avec comme exigence
fondamentale d’offrir les meilleures garanties d’une disponibilité 24h/24 et 7J/7 et de
permettre la continuité du service même en cas de défaillance des équipements mutualisés
(destruction d’un datacenter, défaillance du réseau WAN, etc.).
Les mécanismes de haute disponibilité mis en place pour le SI-Samu se distinguent en six
familles de dispositifs décrits ci-après :

Les dispositifs de redondance matérielle et logicielle : ces dispositifs permettent
de garantir que, lorsqu’un composant connait une panne, un composant équivalent
prend immédiatement le relais pour assurer la continuité du service à qualité
constante. Ces dispositifs couvrent par conséquent un très grand nombre de pannes
et se déclinent sur des cas de panne agissant à des niveaux locaux ou globaux de
l’architecture, comme par exemple la perte d’un datacenter, la perte d’un serveur
applicatif ou téléphonique au sein d’un datacenter, la perte d’une carte de
processeur, etc.
o Au niveau central :
 Chaque datacenter SI-Samu de la solution, qu’il soit applicatif chez un
hébergeur ou qu’il soit téléphonique chez un opérateur de
télécommunication, est couplé avec un site secondaire en redondance
l’un de l’autre à chaud (selon un mécanisme actif-passif). En cas de
faillite du site primaire, le site secondaire reprend immédiatement le
traitement opérationnel ;
 Chaque datacenter du SI-Samu, pour la tâche qui lui incombe, est
dimensionné pour gérer la charge liée à l’activité nationale ;
 Les datacenters qui sont jumelés en site primaire et site secondaire
sont :
 Strictement équivalents en termes d’infrastructures et de
procédures techniques et fonctionnelles ;
 En synchronisation quasi temps-réel;
17 / 113

o
Au sein de chaque datacenter, l’ensemble des équipements applicatifs
et techniques présents est redondé et les mécanismes de virtualisation
sont largement utilisés.
Au niveau local (dans les CRRA) :
 Chaque équipement qu’il soit téléphonique ou réseau est redondé
pour garantir une haute disponibilité :
 Doublement des équipements gateway téléphoniques et
enregistreurs ;
18 / 113


Doublement des T2 ISDN qui acheminent les appels pour les
Samu gros et moyens ;
 Sécurisation des T2 ISDN avec une double pénétration dès
lors que l’établissement de santé offre cette possibilité ;
 Doublement des équipements réseaux d’interconnexion avec le
WAN ;
 Sécurisation des flux voix IP en local au CRRA avec séparation des
flux voix et des flux data dans des réseaux virtuels distincts (voix dans
un VLAN dédié prioritaire) ;
 Sécurisation des enregistrements grâce aux enregistreurs positionnés
devant les gateways téléphoniques ;
Une répartition des responsabilités entre opérateurs de télécommunication
tenant compte des logiques industrielles du secteur :
o Le service critique de collecte est confié à un des opérateurs de
télécommunication habilité à fournir ce type de services : le point critique
de l’architecture est celui de la collecte nationale des appels par un opérateur
de collecte. Seuls certains opérateurs de télécommunication sont habilités à
offrir ce service qui est assuré grâce des infrastructures de télécommunication
de classe opérateur et exploité par les équipes techniques expertes des
opérateurs de télécommunication. Suivant les accords avec les opérateurs
fixes (FNO) ou mobile (MNO) ayant une boucle locale et un réseau dit
« intelligent », l’architecture permet d’autoriser la remise directe, par ces
opérateurs, des appels destinés au 15 vers l’opérateur de service en charge
de la gestion du numéro d’appel des Samu ;
o Le service de collecte intègre la détection de saturation : un service de
détection de saturation des appels sera souscrit auprès de l’opérateur de
service afin qu’il puisse déclencher des traitements automatiques en cas de
saturation d’appel dans un ou plusieurs CRRA, afin de rerouter ces appels
vers d’autres CRRA. Ce dispositif permet aussi de gérer une défaillance des
T2 ISDN qui alimentent un Samu, comme par exemple la détérioration des
lignes téléphoniques physiques suite à incident de type génie civil ou
simplement en cas de détérioration de la qualité sonore, indispensable dans
le cadre des traitements des appels d’urgence. Avec l’architecture proposée,
la solution SI-Samu sera en capacité de détecter cette panne et de renvoyer
les appels via le réseau WAN (voir la section ultérieure dédié à ce sujet) ;
o L’opérateur de service fournit :
 Les fonctions de serveur vocal interactif (SVI) : c’est le premier
niveau d’arrivée de la pression téléphonique. En acquérant le service
SVI chez un opérateur de service, le SI-Samu bénéficie d’une
redondance d’équipements de type SVI en cluster d’un niveau
opérateur. Cela offre des capacités de montées en charge
(« scalability »), de réactivité optimale en cas de panne, tout en
conservant l’autonomie de gestion des Samu ;
 Les fonctions de routage et de gestion de la téléphonie de type
IPBX : le SI-Samu bénéficie d’une exploitation et d’une réactivité
optimale en cas de panne sur ces composants critiques de
l’architecture ;
19 / 113
L’architecture recherchera à homogénéiser autant que faire se peut
l’ensemble des équipements de téléphonie (IPBX, gateway téléphonique et
téléphone) dans le respect de la gestion du bug dit « fatal ». Lors de la phase
de conception et de la phase de dialogue compétitif, le niveau précis
d’homogénéisation des équipements sera défini, prenant en compte la
complexité d’intégration que des équipements différents induisent, afin de
faire le meilleur choix que préconisent les industriels ;
o Financement de T2 ISDN, technologie mature et éprouvée pour acheminer
les appels dans l’ensemble des CRRA. L’architecture, sans aménagement
spécifique, permettra de s’affranchir de certains coûts liés à la location des T2
ISDN, à la maturité des technologies et des réseaux VoIP ;
Dispositifs de double acheminement des ressources téléphoniques et
applicatives :
o Concernant le volet voix :
 Par construction de l’architecture, la voix arrive directement dans les
CRRA sans passer par le réseau WAN avec une qualité de T2 ISDN ;
 En cas de panne ou de défaillance de totalité ou parties des T2 ISDN
qui acheminent un appel, passage par le réseau WAN pour atteindre
le CRRA destinataire, ou choix d’une stratégie d’entraide inter- Samu ;
o Concernant le volet applicatif :
 L’accès nominal aux applications (interface graphique de la téléphonie
« bandeau » et LRM) pour les agents en CRRA se fait via protocole
WEB (HTTP/HTTPS) à travers le réseau WAN qui interconnecte les
CRRA avec les datacenters applicatifs ;
 En cas d’incapacité à accéder aux logiciels des datacenters applicatifs
suite à une panne du réseau WAN, l’accès se fera via un accès
internet sécurisé. Cet accès internet ne s’active qu’en situation
d’indisponibilité du réseau WAN ;
Les dispositifs natifs de mode dégradé pour garantir le service minimum :
o En cas d’incapacité d’accès d’un CRRA aux fonctions ACD centrales
(Automatic Call Distribution) et/ou au serveur CTI (par exemple suite à une
chute du réseau WAN), fonctions qui contiennent l’intelligence centrale de
distribution des appels s’appuyant sur la connaissance précise de l’activité de
chaque CRRA, le SI-Samu va mettre en action un mode dégradé. L’arrivée
des appels téléphoniques est sécurisée par l’arrivée des appels via l’opérateur
de service (pré-décroché) et l’acheminement par cet opérateur en direct dans
les CRRA. Les appels sont pris en charge par les gateways téléphoniques
locales qui, en cas d’incapacité à joindre les serveurs ACD et CTI centraux,
vont activer leur mode SAS (Stand Alone Survivability) permettant d’offrir une
distribution et un routage des appels via des logiques de salles d’attente
auprès des agents du CRRA, sans support d’une interface graphique
(bandeau) mais via les touches du téléphone (fonction ACD locale) ;
o


20 / 113


Les dispositifs de sécurisation du référentiel opérationnel des ressources
(ROR) :
o Une copie disponible en local dans le CRRA : les données opérationnelles
des ressources vers lesquelles envoyer les patients sont indispensables à
l’activité de régulation médicale. Ces données sont accessibles au travers de
l’application LRM disponible dans les datacenters applicatifs. Afin de garantir
dans tous les cas de figure l’accès à ces données, celles-ci sont copiées en
local dans le CRRA pour pouvoir être consultées. Le dispositif envisagé est de
télédistribuer toutes les semaines les données opérationnelles de ressources
du SI-Samu vers un poste de travail sanctuarisé au sein du CRRA sous forme
de fichier de type PDF ou EXCEL ;
o À terme, une copie des données issues du ROR : pour garantir la
performance et la disponibilité des données de type ROR, l’application SISamu fera une copie régulière de ces données en interne pour sécuriser le
temps d’accès à ces données critiques ;
Le dispositif de « Plan de Reprise d’Activité (PRA) » :
o Un datacenter applicatif et téléphonique est disponible pour être rendu
opérationnel dans un délai de 24h à 48h. Ce datacenter de reprise d’activité
doit être à même de gérer la charge d’activité nationale. Une fois le datacenter
PRA opérationnel, les actions pour remettre les datacenters primaires et
secondaires des parties téléphoniques et applicatives pourront être relancées
pour revenir à un mode nominal.
Fort de l’ensemble de ces mécanismes de sécurisation, l’ensemble de l’architecture a été
travaillé sous forme de scénario primaire – scénarii secondaires ou mode nominal – mode
secours. Les principes métiers ont été travaillés selon les mêmes principes : scénario
d’entraide, évènement géographique, centre de crise, crise sanitaire majeure.
Ainsi, le SI-Samu sécurise l’acheminement des appels suivant trois mécanismes successifs
pour garantir le service. Le schéma ci-dessous présente cette logique de mode nominal
(niveau 1) et les deux scénarios de sécurisation successifs (niveau 2, puis niveau 3) pour
garantir la continuité du service.
21 / 113
Continuité de service en cas de défaillance des infrastructures centrales et du réseau
d’interconnexion
De manière identique l’accès des CRRA aux applicatifs en client léger suit 3 niveau de
sécurisation et ce sans dégradation des fonctionnalités utilisées. En effet, en cas de
défaillance du réseau WAN, les CRRA accèdent aux applications du datacenter applicatifs
de manière sécurisé via un accès internet. Le troisième niveau de sécurisation consiste à
faire traiter les appels par un autre CRRA, si l’accès internet du CRRA en question est
également défaillant.
L’architecture de la solution technique SI-Samu intègre dans sa conception la haute
disponibilité et la capacité à augmenter son dimensionnement pour faire face à une
crise sanitaire majeure. La sécurisation est apportée par un assemblage complet de
dispositifs de haute disponibilité que sont principalement : la forte redondance des
équipements, l’existence de doubles chemins d’accès aux infrastructures
mutualisées, le caractère distribué du maillage local des équipements de téléphonie et
les capacités novatrices d’entraide natives entre les Samu.
Grâce à ces dispositifs HRO, même en cas de panne des infrastructures centrales
mutualisées (perte d’un datacenter, perte du réseau WAN, etc.) nécessitant la
survenue très peu probable de la défaillance de nombreux dispositifs de redondance
des infrastructures, les CRRA peuvent continuer à assurer leur régulation médicale.
22 / 113
3.1.9.2 Focus sur la sécurisation de l’étape de collecte
L’opérateur de l’abonné effectue le transcodage du numéro 15 selon une table fixe associée
à l’opérateur de service, sur plusieurs numéros noirs (appelés aussi numéros
géographiques) où il peut être joint.
Deux logiques de livraison distinctes des appels sont appliquées suivant la nature de
l’opérateur de boucle locale :

Pour les petits opérateurs, ils sont regroupés en plusieurs groupes et chaque
groupe est pris en charge par un opérateur de collecte distinct qui assure la
distribution sur les différents points de connexion de l’opérateur de service ;

Pour les grands opérateurs, la livraison vers l’opérateur de service se fait sur
plusieurs chemins différents (plusieurs points d’interconnexion directe) autant au
niveau lien que nœud (équipement totalement différent).
Cette alternative présente aussi une capacité de répartition des appels entre plusieurs
opérateurs de collecte, à des fins de sécurisation. Néanmoins, cette sécurisation est limitée
car en cas de chute de la collecte d’un des opérateurs, l’ensemble des appels concernés par
cette collecte ne seront pas acheminés. C’est pourquoi, dans l’ensemble des
implémentations présentant des fonctions de garantie d’acheminement intelligente de
l’appel, la distribution n’est opérée que par un seul et unique opérateur de service.
23 / 113
3.1.9.3 Focus sur les dispositifs de sécurisation de l’opérateur de service
3.1.9.3.1 Présentation de l’architecture du SI-Samu au niveau de l’opérateur de service
Le schéma ci-dessous présente un focus sur les liens entre l’étage de collecte, l’opérateur
de service et les CRRA.



Cercle jaune : distribution par les grands opérateurs et les opérateurs de collecte sur
les datacenters de l’opérateur de service. Pour les grands opérateurs, deux points
d’interconnexion minimum sont exigés par datacenter ;
Cercle noir : possibilité d’acheminer les appels entre datacenters par les
infrastructures internes ;
Cercle vert : distribution sécurisée en fonction de la géolocalisation ou selon les
scénarii définis dans une optique de prise en charge la meilleure et la plus rapide.
3.1.9.3.2 Scénarios d’architecture envisagés
Suite à l’analyse de deux scénarios :
 Scénario 1 : recours à un seul et unique opérateur de service ;
 Scénario 2 : recours à deux opérateurs de service.
Le scénario 1 a été retenu.
24 / 113
3.1.9.3.3 Mécanismes de sécurisation natif mis en œuvre chez les opérateurs de service
Des mécanismes de sécurisation très puissants sont mis en place chez les opérateurs de
télécoms :


L’architecture propose de multiples datacenters en redondance les uns des autres et
un « backbone » réseau de type MPLS / boucle SDH autorisant une rupture sans
incident (changement du sens de circulation de la voix et des données) ;
Les équipements de l’opérateur de service sont des équipements de classe
opérateur.
3.1.10
Prise en
technologies
compte
de
la
dynamique
d’évolution
des
Compte tenu de l’accélération du rythme de renouvellement des technologies, l’architecture
a été pensée en prenant en compte les différentes évolutions technologiques prévisibles
dans la prochaine décennie :



Le choix a été d’effectuer une distribution téléphonique par les réseaux classiques
RNIS éprouvés. En l’état actuel de la technologie ces réseaux disposent d’une
meilleure robustesse à la fois en termes de fiabilité et de supervision par les
opérateurs. D’autre part, l’utilisation de ces réseaux (RNIS) permet une conduite
du changement plus aisée car elle utilise l’architecture existante dans la plupart
des Samu. À moyen terme, les technologies Telecom vont vers un ensemble
de solutions tout IP : le choix de passer directement sur les technologies IP
engendre actuellement des risques, principalement du fait d’une moindre
robustesse et des risques relatifs à la qualité de voix (sensation d’éloignement,
hachage, voix métallique). Néanmoins, il est possible d’espérer une fiabilité de
ces technologies à un horizon de 5 ans, les expérimentations d’échange interopérateurs sur de gros volumes téléphoniques ayant commencé début 2012.
L’évolution de l’architecture sera alors une décision économique (inversion des
priorités, avec le flux téléphonique passant par le réseau privé IP WAN, secouru
par les T2) et technologique (en fonction du degré de fiabilité) ;
Le passage en IPV6 constitue une opportunité plus qu’un risque. Les
équipements réseaux commercialisés depuis trois ans disposent tous de la
dualité IPV4/IPV6, voire uniquement IPV6. L’IPV6 apporte principalement deux
type de fonctions : des fonctions de sécurité et un plan d’adressage plus large,
permettant d’éviter le recours à des solutions NAT (Network Translate Address,
afin d’effectuer des plans d’adressages privés et d’éviter le conflit d’adresses IP).
La capacité à faire évoluer les infrastructures du SI-Samu vers IPv6 est un
impératif ;
L’architecture a été pensée en prenant en considération les cycles de
persistance et de maturité des évolutions technologiques durant les 20
dernières années et les technologies émergentes. Par exemple, la voix sur IP,
considérée comme un épiphénomène au début des années 2000, est vue comme
incontournable depuis les années 2008 en termes d’évolutions technologiques
sur le LAN (Local Area Network), et comme une orientation raisonnable dans les
architectures télécoms (WAN) et les offres aux entreprises depuis 2011. Les
premiers retours observables dans les domaines télécoms sur des cycles de
production complets permettront de faire évoluer l’architecture, comme évoqué
précédemment. Les cycles télécoms sont des cycles longs (premier service en
reconnaissance vocale en France dans les télécoms en 2003 à base de
technologie définie en 1991). Même les technologies ayant été diffusées à grande
échelle dans le domaine – par exemple, la base des développements pour
iPhone (janvier 2007) vient des outils développés pour la NeXT station en 1992 –
ont des cycles très longs avant d’arriver à maturité. La stratégie choisie dans
25 / 113


l’architecture est de faire porter les évolutions futures relatives au traitement
de la voix par l’opérateur de service, la gestion du multicanal par connexion avec
le système de gestion centrale des centres d’appels, la mobilité et la vidéo par la
maîtrise des échanges IP ;
La mobilité et la gestion multicanale sont deux évolutions majeures actuelles
prises en compte dans le cadre du dossier. La mobilité a subi trois
révolutions majeures : en 2007, premier iPhone diffusant l’usage des
smartphones en France ; en 2010, les smartphone disposent de la puissance
nécessaire pour la gestion de la vidéo ; en 2012 l’apparition de la 4G en France
permet une utilisation de la vidéo sans perte de qualité d’information.
L’architecture dispose des entrées nécessaires pour intégrer ces technologies
sans remise en question du système établi. La gestion multicanale (interaction
par différents canaux, à la fois entrants et sortants, et de manière indifférente),
n’est pas à proprement parler une nouvelle technologie, mais un usage commun
depuis les années 2008 (appel, confirmation par SMS ou mail, information et
partage sur un portail vocal ou internet, tchat, etc.). Le degré de convergence est
plus à lier à l’usage du système que souhaitent les Samu, l’architecture
centralisée permettant un grand nombre d’usages. Le premier système multicanal
à grande échelle a été mis en place en France au profit de l’ANPE en 2002 (sans
toutefois prendre en compte la vidéo, l’usage étant peu répandu et les réseaux et
technologies non matures) ;
Un enjeu complémentaire dans les années futures sera l’assistance à distance
ou la télémédecine. L’assistance à distance (conseil) a été mise en place par le
NHS en Angleterre sous la forme de conseil par moyen multicanal, avec comme
canal principal la voix par téléphone. L’assistance à distance et l’aide au
diagnostic vont être plus un enjeu d’usages qu’un enjeu technologique : les
réseaux télécoms permettent de répondre à cet enjeu et les technologies,
dérivées des usages domotiques, sont matures. La supervision des systèmes à
distance est basée sur les réseaux IP et ne pose pas de problème d’intégration
technique, ni d’usage. Concernant ce dernier point, l’ensemble du système conçu
pour les Samu est bâti sur trois principes : le premier est la connaissance à un
instant t donné de la disponibilité d’un ARM ou d’un médecin, le second est la
possibilité par un ARM de « prendre » la main sur une demande de contacts, et
enfin le suivi des contacts et des dossiers. Le SI-Samu doit pouvoir être une
structure d’accueil pour accueillir progressivement les outils de diagnostics à
distance, et même de soins, au fur et à mesure de l’apparition des solutions dans
ce domaine.
3.2 Particularités du système attendu
Afin de faciliter la compréhension du système attendu, un focus est fait sur certains points
de vigilance et particularités du système attendu que l’ASIP Santé souhaite mettre en
évidence. Cette liste de points n’a pas pour objectif d’être exhaustive : elle apporte un
éclairage et précise certaines notions, afin d’éviter une mauvaise interprétation des réponses
attendues.
Il est à noter que les attentes formulées dans le présent document ne sont pas à ce
stade priorisées. Bien que l’ensemble des questionnements présentés au chapitre 4
porte sur une variété très large de composants, la priorité reste axée sur les
composants cœurs de système.
26 / 113
L’ASIP Santé souhaite donc, dans le cadre de la demande d’information ci-après, que les
réponses soient adaptées au contexte décrit dans le cadre d’architecture retenu
présenté dans ce document et ses annexes.
3.2.1 La capacité d’accueil téléphonique
Une caractéristique des appels aux numéros d’urgences est qu’il sont à la fois prévisibles et
imprévisibles :


Prévisible, car de par l’expérience acquise par l’observation de la typologie de trafic, il
est possible de déterminer les heures d’affluence d’appels entrants probables, ainsi
que les journées chargées, et la corrélation avec des évènements saisonniers. Cette
prévision permet de mettre en place un nombre d’agents (ARM) en adéquation avec
la demande de prise en charge, atténuant l’impact sur le nombre de ports
téléphoniques nécessaires pour l’accueil téléphonique automatique par les Serveurs
Vocaux Interactifs ;
Imprévisible, du fait d’évènements exceptionnels. Ces évènements peuvent se
classer en trois catégories :
o Des évènements générant une indisponibilité totale ou partielle d’un CRRA
(génie civil, défaillance de composants). Ce cas sera traité par la logique
d’entraide entre Samu. Néanmoins ces évènements diminuent le nombre
d’agents potentiellement disponibles pour répondre, entrainant un afflux
complémentaire d’appels à traiter en amont par les SVI, en aval par la prise
en charge des appels par d’autres CRRA. L’objectif de l’architecture duale
TDM/IP est de diminuer encore ces cas d’occurrence ;
o Des évènements à portée locale (par exemple explosion, accidents,
évènement climatique) impactant un CRRA ou un ensemble de CRRA, mais
en nombre limité. Ces évènements ont très souvent une cinétique rapide, ne
permettant pas l’approvisionnement en matériel et/ou logiciel pour pallier cette
augmentation. L’architecture prévue doit permettre à la fois la répartition de
ces appels dans d’autres CRRA (en utilisant notamment la possibilité de
salles de crise) mais également la possibilité de « parquer » les appels en
amont et faire une pré-qualification. De fait la capacité d’accueil vocal doit
pouvoir s’étendre de manière rapide ;
o Des évènements à portée nationale (par exemple, une pandémie grippale).
Ces évènements, souvent à cinétique lente, imposent à la fois une
augmentation du nombre d’agents (ARM/MR) mais également une
amélioration de la pré-qualification des appels, afin d’effectuer une prise en
charge des appels par degré de priorité d’urgence. Ces évènements
augmentent également la capacité d’accueil vocal.
L’ASIP Santé souhaite de fait ne pas être « bridée » sur le nombre de ports SVI, et de
fait ne souhaite pas faire l’acquisition d’une architecture surdimensionnée de ports
SVI pour pouvoir gérer des évènements exceptionnels. De fait la capacité SVI sera
louée en mode service à un opérateur de service télécom, à qui il est envisagé de
demander de proposer une architecture duale, avec certains ports SVI réservés au SI-Samu,
afin de garantir une qualité de service, avec un débordement sur des architectures
mutualisées, afin de gérer le caractère évènementiel.
L’ASIP Santé souhaite néanmoins connaître les caractéristiques des matériels effectuant le
service d’accueil vocal, afin de comparer les offres, l’accueil vocal étant un élément
prépondérant en cas d’afflux d’appels.
3.2.2 La gestion des modes dégradés
Le SI-Samu, comme tout système informatique ou télécom, peut subir un incident imprévu
endommageant la chaîne de traitement nominale des appels. L’objectif est de mettre en
27 / 113
place un ensemble de moyens permettant de suppléer une panne du système nominal. Il
sera désigné par mode dégradé tout modèle de fonctionnement différent du nominal, avec
une classification de ces modes par risque ou sensibilité (baisse de la disponibilité moyenne)
et par degré de perte de fonctionnalités. À ce titre, différents modes dégradés sont identifiés.
Les principaux modes dégradés sont :




Passage en mode dégradé par panne sur un composant sans défaillance de la
redondance : ce type de mode dégradé est caractérisé par une absence d’impact à
la fois sur l’appelant et sur la gestion des appels par les ARM. Il peut néanmoins
avoir des conséquences, que l’ASIP Santé souhaite minimiser, sur des systèmes
connexes (notamment statistiques) ;
Passage en mode dégradé par panne sur un composant avec défaillance de la
redondance, intra ou inter-sites : ce type de mode dégradé a un impact sur la
gestion des appels par les ARM/MR et sur le métier de la régulation médicale, sans
impact visible pour l’appelant. Une classification sera effectuée en fonction de
l’impact sur le métier de la régulation médicale ;
Passage dans des modes dégradés de fait classifiés de mode « ultime » : la notion
de distribution est faite de manière désordonnée et « basique », avec perte
d’efficacité des ARM/MR, seul l’acheminement de l’appel est garanti ;
Passage dans des modes dégradés de manière volontaire (cf. premier cas), soit à
des fins de maintenance, d’upgrade, ou de bascule ; à l’inverse du premier cas ces
modes dégradés peuvent être anticipés et donc beaucoup mieux maîtrisés. Ils seront
obligatoires à un moment ou un autre du cycle de production.
3.2.3 La qualité de service
L’ASIP Santé souhaite connaître la capacité de l’offre du marché à atteindre les niveaux de
SLA attendus dans le cadre du SI-Samu. Pour se faire, les répondants à la présente
demande d’information sont invités à fournir toute information utile relative à la qualité de
service fournie par les solutions logicielles et équipements en standard (voir chapitre de la
demande d’information dédié à la qualité de service).
L’ASIP Santé, lors des consultations à venir, portera particulièrement son attention sur trois
points très structurants, le SI-Samu ne pouvant être exposé à des temps de transition
importants (état entre mode nominal et mode dégradé) :



Le temps moyen entre deux pannes de chaque équipement ou composant logiciel
(désigné aussi par les acronymes MTBF ou Mean Time Between Failure), permettant
éventuellement d’opérer des opérations de maintenance préventive ;
La Garantie de Temps de Rétablissement (GTR). Si cet indicateur est un SLA au
niveau des engagements de l’opérateur économique soumissionnaire, il est
important, pour l’ASIP Santé, de connaître pour chaque équipement le temps de
« remontée » du système (temps de reboot, de réinitialisation du composant ou de la
chaîne des composants, si les composants sont interdépendants) ;
La durée de bascule, pour chaque équipement ou composant, entre l’élément en
mode normal et l’élément en mode secours.
L’ASIP Santé envisage par ailleurs de mettre en œuvre une supervision déportée fournie par
les titulaires des marchés M1 à M4. Cette supervision doit permettre de suivre les indicateurs
de qualité de service mais également de superviser les éléments fournissant ces indicateurs.
3.2.4 Le respect des normes
Un point d’attention sera apporté au respect des normes et de « l’état de l’art » lors de la
conception du SI-Samu. Ce critère est lié notamment à la volonté de l’ASIP Santé :

De créer un « patrimoine » applicatif et plus généralement, de capitaliser au niveau
des solutions mises en place ;
28 / 113


De faciliter la réversibilité du système, afin de pouvoir garantir la concurrence dans
le cadre du renouvellement des marchés ;
De pouvoir développer, le cas échant, des couches d’abstraction permettant de
changer de solutions logicielles ou matérielles dans le cadre de l’évolution du SISamu dans les années futures.
L’ASIP Santé portera un regard notamment sur les points suivants :





Le respect de la norme VXML pour faciliter la réversibilité sur les développements
vocaux et la reprise par un tiers ;
Le respect de la norme SIP (dans son intégralité, en indiquant les écarts éventuels)
pour les communications téléphoniques locales au sein des Samu ;
Respect de la norme définissant les interfaces entre IPBX et CTI ;
La gestion des compatibilités avec certains types de téléphone / softphone ;
L’adhérence des solutions à des logiciels tiers, notamment en cas d’intégration
propriétaire.
3.2.5 La réversibilité
Une réversibilité totale de la solution nominale du SI-Samu doit être garantie, y compris pour
les interfaces spécifiques développées dans le cadre du SI-Samu.
L’ASIP Santé souhaite acquérir l’ensemble des droits des développements et intégrations
effectués dans le cadre du SI-Samu.
De la même manière, afin d’assurer la réversibilité, les répondants à la présente demande
d’informations sont invités à mettre en évidence :





Les modalités de transfert des droits de licences vers l’ASIP Santé et aux tiers
mandatés par l’ASIP Santé (notamment les droits d’usage, les droits liés aux
modifications et à la production) ;
Les droits liés à des œuvres dérivées éventuelles ;
L’utilisation d’éléments opensource au sein de la solution, en précisant la liste et
l’usage de ces éléments ;
L’utilisation de logiciel tiers, et les droits associés (Embedded OEM) ;
Toute autre information permettant d’assurer la réversibilité du SI-Samu, notamment
dans le cadre d’un renouvellement de marché public.
La réversibilité n’est pas abordée en tant que telle dans le cadre de la demande informations
ci-après, même si certaines questions y font référence.
3.2.6 La haute disponibilité
L’ASIP Santé souhaite inviter les répondants à cette présente demande d’informations à
détailler tout élément qui permettra de mettre en évidence la haute disponibilité de
l’équipement ou de la solution logicielle (CTI, ACD, SVI,…) qu’ils proposent en tant que tels,
ainsi que les mesures souhaitables à mettre en œuvre afin de garantir cette haute
disponibilité.
29 / 113
À cette fin dans ce document l’ASIP Santé a souhaité :


Fournir une définition claire des éléments caractérisant la haute disponibilité du
système attendu pour le SI-Samu, à savoir la disponibilité, la performance, la
réactivité et la résilience ;
Préciser ses attentes dans le cadre du SI-Samu et demander aux répondants de
compléter leurs réponses par tout élément qu’ils jugeront utile à des fins de
garantie de la haute disponibilité – à savoir l’état de l’art concernant la manière de
mettre en place ses produits et solutions.
Disponibilité
La disponibilité d’un équipement ou d’un système est une mesure (taux de disponibilité)
faisant le rapport entre la durée totale de fonctionnement de l’équipement ou du système
rapportée à la durée de fonctionnement demandée.
𝑇𝑎𝑢𝑥 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑡é =
𝐷𝑢𝑟é𝑒 𝑑𝑒 𝑓𝑜𝑛𝑐𝑡𝑖𝑜𝑛𝑛𝑒𝑚𝑒𝑛𝑡 𝑟é𝑒𝑙𝑙𝑒
𝐷𝑢𝑟é𝑒 𝑑𝑒 𝑓𝑜𝑛𝑐𝑡𝑖𝑜𝑛𝑛𝑒𝑚𝑒𝑛𝑡 𝑑𝑒𝑚𝑎𝑛𝑑é𝑒
Dans le cadre des conventions de services il sera rappelé la définition exacte de chacune de
ces durées :


La durée de fonctionnement réelle est la période mesurée, minorée des temps de
panne, des temps nécessaires à la remise en fonctionnement, et des temps de
maintenance effectuée s’ils engendrent une indisponibilité ;
La durée de fonctionnement demandée est la période « utile au fonctionnement » du
service. La particularité du SI-Samu est l’absence d’interruption du système. Dans le
cadre du SI-Samu, la durée de fonctionnement demandée du système est 24/24 et
365j/an, à l’instar des opérateurs d’importance vitale.
Un élément important dans la mesure est la notion de durée. La durée d’observation
envisagée sera le mois dans le cadre des engagements contractuel demandés, même si une
observation sera faite sur la disponibilité annuelle (par segment de mesure).
Cette définition est importante : les périodes de maintenance ne seront pas ôtées du
calcul des taux de disponibilité (la notion de taux de disponibilité « hors maintenance » ne
sera pas acceptée) sauf accord express de l’ASIP Santé.
Le fournisseur de solutions ou équipementier précisera les méthodes ou équipements
nécessaires à la prise en compte de cette contrainte (à l’instar de mécanismes de type
raid/hotswap).
Performance
La performance d’un équipement correspond, pour un ensemble de caractéristiques
environnementales et de conditions d’exploitation, à un indicateur ou une combinaison
d’indicateurs. L’un de ces indicateurs est le temps de réponse constaté par rapport à un
certain niveau d’activité. Les temps de réponse intéressants particulièrement l’ASIP Santé
sont :


Le temps de réponse du serveur de bandeau téléphonique, fonction du nombre
d’agents connectés ou à un nombre de supervisions actives ;
Le délai de réponse de l’ACD aux demandes de routage, en cas de flux d’appels
importants.
Le répondant est invité à fournir toute information qu’il jugera utile en annexe de sa réponse
à la demande afin de préciser :
30 / 113


Les taux de performance obtenus sur les produits envisageables dans le cadre des
SI-Samu ;
Les conditions environnementales dans lesquelles ont été effectués ces tests.
L’objectif, pour l’ASIP Santé, est de valider la possibilité d’utiliser les produits précités au
sein de la solution SI-Samu, eu égard au nombre d’utilisateurs / agents concurrents.
Réactivité
La notion de réactivité s’applique à la fois au domaine informatique et aux organisations
humaines qui permettent aux moyens informatiques de fonctionner. L’unité de mesure
principale de la réactivité est le temps, la valeur attribuée en terme d’engagement (SLA ou
OLA) est fonction de l’élément mesuré, et fonction de la criticité de l’élément au sein du
service (la criticité étant définie par l’association du couple urgence-importance de gestion
des risques).
Afin de pouvoir caractériser le degré de réactivité nécessaire dans les processus
d’exploitation, l’ASIP Santé souhaite avoir connaissance des logiques d’interdépendance
et le niveau de criticité des équipements et logiciels au sein des produits proposables
par chaque répondant à la demande d’information.
Résilience
La notion de résilience d’un système informatique vient des notions de mécaniques
(résistance des métaux, robustesse) et des domaines psychologiques (capacité à résister
aux conditions externes et à rebondir).
Chaque répondant est invité à fournir les indicateurs de résilience qu’il juge utiles en
annexe concernant les produits proposés, l’un de ces indicateurs étant notamment le MTBF
(voir ci-avant).
La notion de résilience d’un système est très souvent également assimilée à la capacité des
systèmes à résister à « l’effet du temps ».
31 / 113
3.3 Hypothèses de dimensionnement
Les hypothèses de dimensionnement à prendre en compte sont les suivantes :
Nombre de CRRA
Volumétrie d’appels
entrants
Volumétrie d’appels
sortants
97 CRRA en métropole et 5 CRRA dans les DOM.
31 millions d’appels entrants par an en base 2013.
Hypothèse d’évolution annuelle du nombre d’appels fixée à 2,5
%.
50% du volume total d’appels entrants soit 15,5 millions d’appels
par an :
Nombre d’appels en 3% du volume total d’appels entrants soit 900 000 appels par an.
rappel
46% du volume total d’appels entrants soit 14,3 millions d’appels
Nombre d’appels de
par an.
suivi de régulation
Nombre d’appels 1% du volume total d’appels entrants soit 300 000 appels par an.
« Callback »
5 minutes (moyenne sur tous les appels entrants – citoyens et
Durée des appels
professionnels).
75% des appels ne passent pas dans le SVI dynamique.
Passage dans le SVI
Durée moyenne d’un appel dans le SVI : 1 minute (qualification +
attente).
1250 agents en simultané en situation normale.
Nombre de postes de
2000 agents en simultané en situation de crise.
travail
Par volumétrie d’appels simultanés, nous considérons les volumétries de trafic d’appels
suivantes (appels pris par agent + appels en parcage sur le serveur vocal) :



5 000 appels simultanés en mode nominal : correspond à la capacité nominale que
devra supporter le système ;
6 000 appels simultanés en mode nominal crise (événement à portée locale) : le
système devra être dimensionné pour pouvoir résorber au moins un pic de charge de
6 000 appels simultanés ;
15 000 appels simultanés en mode crise (événement de portée nationale ex :
H1N1,..): en cas de situation de crise de portée nationale, un projet de renforcement
de l'infrastructure doit permettre d'anticiper une charge de 15 000 appels simultanés.
Le dimensionnement du service devra être effectué afin de supporter l’ensemble du trafic. La
solution devra être évolutive pour gérer un changement de volume d’appels, qu’il soit
permanent ou ponctuel (évènementiel par exemple).
32 / 113
4 Informations attendues par l’ASIP Santé
Le présent chapitre, listant les demandes formulées par l’ASIP Santé, est décomposé en 5
parties :





Les remarques et commentaires attendus des répondants sur les orientations
retenues pas l’ASIP Santé telles que présentées dans ce document ;
Le cœur de système, correspondant à la prise d’appels : comprend la partie accueil
téléphonique par service vocal interactif, la partie téléphonie, la partie
routage/distribution et la partie de couplage téléphonie informatique ;
Les parties connexes au système, à savoir notamment l’enregistrement et la
gestion multicanal ;
Les fonctions d’exploitation et d’administration des solutions ainsi que de
reporting, comprenant la gestion des statistiques, la supervision, la gestion des
indicateurs, l’intégration globale du système SI-Samu, les contraintes d’exploitation
liées à la mise en place de la solution et une description des environnements
associés aux solutions ;
Les domaines transverses tels que la gestion des tickets de communication, la
gestion de la qualité de service, les modèles tarifaires des solutions applicables au
SI-Samu.
Il est à noter que les exigences à ce stade ne sont pas priorisées. Bien que l’ensemble
des questionnements ci-dessous portent sur une variété très large de composants, la
priorité reste portée sur les composants cœurs de système.
4.1 Informations sur les orientations retenues
De par leur expertise et connaissance du marché, il est demandé aux répondants de
formuler un avis et l’ensemble des remarques qu’ils souhaitent sur les orientations retenues
par l’ASIP Santé pour construire les infrastructures téléphonie et centre d’appel du futur SISamu.
33 / 113
Id
Orientations prises par l’ASIP Santé dans le cadre du SI-Samu
Les informations de contexte vous semblent elles claires, pertinentes et
exhaustives ? Si ce n’est pas le cas, de quelle manière pouvons-nous
améliorer cette partie du document ?
Les grands choix d’architecture retenus vous semblent-ils pertinents ? Y a-t-il
des éléments critiquables dans ces choix et le cas échéant, lesquels ? Des
solutions alternatives sont-elles envisageables et le cas échéant, lesquelles ?
COM-COMM-1
Existe-t-il à votre connaissance des grands projets similaires, où le couplage
entre les applications métiers SI et la téléphonie dispose d’un volet métier très
contraignant et ceci dans un cadre très décentralisé, qui pourraient être cités
en référence et servir d’exemple à l’ASIP Santé pour le futur SI-Samu ?
Quels sont à votre avis les facteurs de succès clefs, limités au domaine des
technologies et choix de solution concernés dans cette demande
d’information, que l’ASIP Santé doit prendre en compte impérativement pour
réussir ?
À noter que vos remarques et réserves ne doivent pas remettre en cause
les orientations et les réponses aux questions attendues dans la suite du
document.
4.2 Informations sur les composants cœur du système
4.2.1 Serveurs vocaux interactifs
4.2.1.1 Besoins
Service d’accueil Vocal
Le « Service d’accueil Vocal » correspond aux services permettant la mise en œuvre
d’applications vocales de traitement automatique d’appels comme un menu vocal, la
diffusion de messages. Ce service intervient dans le cadre de la qualification de l’appel qui
permet de différencier les types d’appelants et d’identifier leurs problématiques pour
permettre leur routage (ou distribution) sur le personnel Samu le plus à même à répondre au
besoin de l’appelant.
Ces services couvrent des besoins :
 De qualification des appels ;
 D’annonce vocale, par exemple pour faire une annonce spécifique lors de conditions
spécifiques pour un CRRA, d’une région donnée ou au niveau national ;
 De parcage d’appels, pour gérer les appels mis en attente lorsqu’aucun ARM n’est
disponible ;
 D’écoute passive, pour activation de fonction par réception de signal DTMF.
Ces services peuvent être activés individuellement par numéro d’accès ou par CRRA sur le
numéro d’accès du 15 ou 112 (ou plus généralement d’autres numéros via le PDAAU, le
PDSA, des numéros à 10 chiffes, etc.).
Certains services devront disposer d’accueil (et de comportements) différents suivant à la
fois le numéro d’appels (médecine de garde, numéros régionaux) et la localisation
géographique de l’appelant.
34 / 113
Cas d’usage et de fonctionnement
D’une manière générale, le patient appelle le 15 ou le 112 (partie principale du trafic
concerné), alors qu’un effecteur peut également composer un numéro entrant dédié pour
entrer en relation avec le Samu.
Le traitement de l’appel est organisé en 4 grandes phases :





Test du numéro appelé afin de permettre une première personnalisation de l’accueil
vocal, si nécessaire ; un premier routage intelligent intervient ici :
o Dissuasion des appels malveillants ;
o Dissuasion des appels non vocaux ;
o Routage des appels non francophones ;
o Last call agent ;
o Re routage des appelants connus sur un flux spécifique.
Attente et saisie d’un code Pin : un code Pin peut être saisi durant le message
d’accueil diffusé lors du décroché. Le code Pin est fourni uniquement aux partenaires
et est différent pour chaque partenaire (SDIS, Ambulances privées, SOS Médecin,
Hôpital …). L'activation de cette fonctionnalité reposera sur des mécanismes
paramétrables selon des critères propres au CRRA appelé, de la région ou du
numéro appelé ;
Orientation de l’appel :
o Si l’appelant ne saisit pas de code Pin, il est alors orienté vers la file d’attente
dite « 15 ». Si un agent est disponible alors l’appel passe directement au
« Routage » puis à la « Distribution » afin de mettre en relation l’appelant et
l’agent ;
o Si au contraire l’appelant saisit un code Pin, il est alors orienté vers les files
d’attente dites « Partenaires / Professionnels » et un « SVI Professionnel ».
Le type d’appelant sera différencié à l’affichage en file d’attente suivant le
code Pin saisi ;
Gestion de l’attente : dans l’hypothèse où aucun agent n’est disponible, l’appel est
alors mis en attente sur une application vocale SVI 15-Samu spécifique. Cette
application vocale peut être personnalisée en fonction du CRRA, du n° appelé ou
bien en fonction de scénarii événementiels préalablement activés (ex :
déclenchement d’un scénario de crise sanitaire comme H1N1). Dès qu’un agent est
disponible l’appel passe directement au « Routage » puis à la « Distribution » afin de
mettre en relation l’appelant et l’agent ;
De ce principe de fonctionnement qui constitue le socle de base des services
d’accueil vocal du 15, quatre principales déclinaisons sont envisagées pouvant
associer et mettre en œuvre de nouvelles fonctionnalités de service vocal interactif :
o Parcours du patient qui appelle le 15 ou 112 (ou autres numéros pouvant être
gérés par le CRRA) ;
o Parcours de l’effecteur qui appelle le 15 ou des n° d’accès dédiés ;
o Parcours du professionnel via le 15 ou des n° d’accès dédiés ;
o Parcours en cas de crise ou d’événementiel activé spécifiquement, soit
nationalement soit localement sur un CRRA.
35 / 113
Fonctionnalités de services vocaux interactifs
Les fonctionnalités attendues de SVI du Service d’Accueil Vocal sont les suivantes :










Arborescence et menu vocal pour qualifier l’urgence vitale de l’appel afin d’en
définir la priorisation ;
Déclenchement du scénario vocal en fonction d’un calendrier ;
SVI dynamique : le SVI doit pouvoir changer en fonction de la provenance (15 et
Samu), permettre ainsi les entrées masquées (pour les professionnels de santé –
via code Pin ou par le numéro de l’appelé) ;
Capacité de faire un lien avec une application cliente (DRM dans notre cas) et
avec un annuaire interne (savoir si le numéro de l’appelant est référencé dans
l’annuaire interne du Samu (CHU, CTA,…)) ;
Masquage et activation à la demande des applications vocales SVI ; ces SVI
sont utilisés par exemple pour les crises ;
Personnalisation des messages d’accueil et d’attente par CRRA ;
Gestion programmée d’activation/désactivation de messages vocaux ou de
menus ;
Guides vocaux personnalisables et modifiables par le Samu, s’appuyant entre
autres sur la fonctionnalité de TTS (Text To Speech) qui permet de créer un
message vocal à partir de la saisie d’un texte ;
Reconnaissance vocale et identification linguistique afin de connaître le besoin
du client et/ou sa langue par interprétation des mots prononcés par l’appelant et
recueillis par l’application vocale ;
Détection de l’humeur et donc du stress de l’appelant afin de connaître son
degré de panique. Cette fonctionnalité est utilisée lors de l’attente de l’appelant.
4.2.1.2 Principes structurants
Pour délivrer le Service d’Accueil Vocal, les principes suivants sont considérés comme
structurants :



Le service vocal interactif sera centralisé et hébergé côté opérateur de
services : le SVI est placé au niveau de l’opérateur de service de façon à centraliser
l’intelligence et permettre une gestion simplifiée lorsqu’un Samu est coupé du réseau
ou en cas de pic d’activités. Ceci permet de plus une forte mutualisation des
équipements et des services ;
Le développement du service d’accueil vocal respecte les standards d’interface
du marché dont en particulier « Voice XML », de façon à développer les scénarios
vocaux rapidement et faciliter la portabilité et la réversibilité du service dans un autre
environnement. Ce point devra être précisé, afin de permettre une capitalisation des
développements ;
Forte disponibilité : la fonction phonie des Samu ne peut tolérer une panne de plus
de 5 minutes par an mettant en péril la téléphonie de plusieurs Samu. La solution de
téléphonie doit donc avoir une disponibilité 5-9. La perte du service SVI seul n’est pas
considérée comme perte de disponibilité du service de téléphonie. Toutefois le SVI
devient un élément critique en cas de crise car le service vocal devient le premier
élément d’accueil. De fait le répondant est invité à fournir tout indicateur, architecture
et méthodologie garantissant à la fois la disponibilité et la résilience du SVI (voir
chapitre haute disponibilité).
Pour plus d’informations, se référer aux annexes présentées au chapitre 5.2 pour la
cinématique de l’appel et l’architecture et au chapitre 5.3 pour la cinématique de traitement
du service d’accueil vocal.
36 / 113
4.2.1.3 Demande d’informations
Présentation du Service d’Accueil Vocal
Id
SAV-PRES-1
Pouvez-vous présenter votre service de Serveur d’Accueil Vocal en mettant
notamment en évidence par rapport à nos orientations ses avantages et précisant :
 Architecture de la solution : description générale, localisation des
composants, scalability, niveau de résilience ;
 Technologies utilisées pour le développement ; langages, protocoles et
standard supportés ;
 Dimensionnement : nombre maximum d’appels simultanés par entité.
Quelle norme/version de VXML supportez-vous ?
SAV-PRES-2
Préciser les protocoles et langages de développement des applications vocales, en
privilégiant les normes reconnues sur le marché, en particulier :
 MRCP (Media Resource Control Protocol) ;
 SSML (Speech Synthesis Markup Language) ;
 PLS (Pronunciation Lexicon Specification).
Si ces normes ne sont pas aujourd’hui entièrement implémentées, l’ASIP Santé
souhaite connaître la roadmap de leur intégration, ainsi que les écarts actuels par
rapport à la norme.
Id
Parc et Gestion de Capacité
SAV-CAPA-1
Les Samu doivent faire face à des pics de charge dus à des crises. Il peut s'agir de
crise à cinétique rapide (accident industriel type AZF) ou lente (épidémie de grippe).
Le SVI est dans ce cas activé pour palier la saturation du niveau 1 (ARM) des centres
15.
Pouvez-vous préciser votre capacité à provisionner X voies supplémentaires pour le
SVI et le délai associé (incluant les trunks voix supplémentaires) pour :
(Voir la taille des pics d’appels, 5 K appels simultanés en nominal et 15K en pic)
 100 voies ;
 500 voies ;
 1000 voies ;
 Multiplication de la capacité nominale par 3 (soit 15 000 voies).
Id
Gestion de la reconnaissance vocale
SAV-RECO-1
Quelles technologies de reconnaissance vocale employez-vous ?
Si ces technologies sont mises en œuvre, avec quelle technologie êtes-vous
interfacé ?
 Par mots clefs ?
 Par mots clefs dans un flot continu ?
 En langage naturel ? Comment opérez-vous la reconnaissance de langue
étrangère ?
Quelle technologie utilisez-vous pour lancer la reconnaissance vocale depuis une
application VXML ?
Quelles langues reconnaissez-vous nativement ?
37 / 113
Support du TTS
Id
Votre SVI VXML dispose-t-il d’une solution intégrée de text-to-speech ?
Dans le cas contraire avec quel(s) logiciel(s) votre SVI est-il intégré ?
SAV-TTS-1
Avez-vous des outils et interfaces permettant aux CRRA de synthétiser une voix
humaine, à partir d’éléments de texte écrits ?
Disposez-vous d’API permettant de développer un logiciel intégrant le dépôt de sons
dans une arborescence, sons issus de logiciels de text-to-speech ?
Avez-vous la capacité à offrir un service de voix ou une base de voix sur mesure,
personnalisée pour le SI-Samu ? Quelle technologie utilisez-vous ?
Id
SAV-INTE-1
Interconnexion avec le service de collecte des flux d’appels
Disposez-vous de références d’intégration de vos SVI chez un opérateur de service
français ? Le cas échéant le(s)quel(s) ?
Quelles sont les contraintes d’interconnexion de votre SVI avec le service de collecte
opérateur ?
Intégration avec des flux externes
Id
SAV-INTE-2
Quelles contraintes d’intégration voyez-vous avec des applications en back office du
SI-Samu (Logiciel de Régulation Médicale, à comparer avec un logiciel CRM en
architecture n-tiers) ?
Pouvez-vous préciser la capacité à appeler ces fonctions de back office depuis des
documents/application VXML ?
SAV-INTE-3
Quelles sont vos limitations et mécanismes offerts pour transférer dans le contexte de
l’appel tous les champs d’informations saisis ou collectés dans le SVI et les utiliser
dans des appels à des fonctions de back office (ex : numéro de dossier DRM, mot de
passe partenaire,….) ?
Pouvez-vous préciser les mécanismes offerts adaptés à notre contexte ?
38 / 113
Interconnexion avec un ACD
Id
Quelles sont les contraintes d’interconnexion du service SVI opéré avec un service de
distribution d’appels fourni par un tiers ?
SAV-INTE-4
Merci de bien vouloir préciser :
 Les contraintes d'interconnexion dans le cas d'un ACD associé à un
IBPX ;
 Les contraintes d'interconnexion dans le cas d’une solution ACD
logicielle ;
 L'architecture nécessaire à chaque type d'interconnexion (ACD logicielle
ou associée à un IPBX) : interconnexion directe ou via un connecteur,
langages de dialogue … ;
 La liste des éditeurs ACD avec lesquels votre service SVI VXML est
compatible.
P
Préciser votre capacité et le cas échéant vos contraintes – limitations pour :

SAV-INTE-5


Transfert de l’appel vers un conseiller
Id
SAV-INTE-6
Conserver tous les éléments de contexte de l’appel, collectés en
reconnaissance vocale et le parcours client ;
Transmettre tous les éléments de contexte de l’appel à la fonction ACD et
CTI ;
Transmettre des parcours abandonnés pour engager un call back par le
Samu (de manière manuelle ou sur un automate d’appels sortants).
Quelles sont les contraintes pour assurer le transfert d’un appel depuis le SVI vers
un conseiller :
 Via un aboutement par le réseau de collecte ?
 Via une double communication appelant-SVI et SVI-conseiller ?
Parmi ces différentes architectures, laquelle préconisez-vous ?
Quelles sont les raisons de cette préconisation, notamment au regard des
caractéristiques du programme SI-Samu (réversibilité, haute disponibilité) ?
Supervision et Statistiques d’appel après transfert
Id
SAV-STAT-1
Quelles sont les contraintes et prérequis pour la supervision (et la génération des
statistiques) d’un appel de bout-en-bout :
 Si l’appel est acheminé vers le téléphone d’un conseiller par aboutement ?
 Si l’appel est acheminé vers le téléphone d’un conseiller par double
communication ?
Quelles contraintes additionnelles pourrait apporter une interconnexion par
IP Trunking avec l’environnement ToIP ?
39 / 113
Administration fonctionnelle
Id
SAV-ADMN-1
Quels sont les services d’administration fonctionnelle que vous pouvez-mettre à
disposition de l’ASIP Santé, répondant notamment aux besoins suivants :
 Ajout/suppression/modification d’une branche de l’arborescence pour
l’acheminement des appels ?
 Enregistrement d’un message par synthèse vocale ?
Quels outils êtes-vous en mesure de proposer pour permettre cette administration
fonctionnelle, notamment pour la synthèse vocale ? Quels sont les prérequis
d’utilisation, notamment en matière de compétence technique ?
SAV-ADMN-2
SAV-ADMN-3
Quel type d’outil (type éditeur graphique) utilisez-vous pour décrire les applications
SVI ? Préciser s'il s'agit d'un outil du marché ou d'un outil propriétaire, ainsi que les
caractéristiques de l’outil.
Préciser les interfaces disponibles permettant aux CRRA de mettre à jour des
messages en Text To Speech dans des portions prédéfinies de l'arborescence vocale.
4.2.2 Fonctions de téléphonie
4.2.2.1 Besoins
4.2.2.1.1 Description générale
La solution recherchée est un système de téléphonie sur IP centralisé et à haute
disponibilité. La solution doit permettre plusieurs niveaux de modes dégradés (haute
disponibilité sur un datacenter, bascule entre datacenters, fonctionnement des CRRA isolés
des datacenters centraux).
Le système de téléphonie est couplé à un système de gestion de centre d’appels assurant le
routage intelligent, la distribution des appels et le couplage CTI avec le SI-Samu. La gestion
de centre d‘appels de même que les services d’enregistrement et de SVI sont décrits par
ailleurs.
Fonctionnellement, le service de téléphonie assure les fonctions suivantes :
Fonctions centrales







Service de téléphonie Samu ;
Service de téléphonie administrative sur les mêmes postes téléphoniques (dualité
centre d’appel/téléphonie administrative) ;
Acheminement des flux d’appels entrants sur les postes téléphoniques des CRRA, en
TDM en nominal, en IP en secours (la priorité pouvant être inversée dans le temps).
Les appels entrants (partie de l’appel entre la boucle locale de l’abonné et l’IPBX
central) sont aboutés aux appels sortants vers les CRRA (partie de l’appel partant de
l’IPBX central vers le CRRA) ;
Acheminement des flux d’appels sortants ;
Interface TDM avec le réseau téléphonique public, ou liaison avec d’autres organes
opérateurs ;
Interface avec :
o Applications externes (lien CTI par exemple) ;
o Fonction de SVI ;
o Fonction d’enregistrement ;
o Annuaire ;
Fonctions d‘ACD disponibles dans la solution de téléphonie. Ces fonctions peuvent
être activées en backup des fonctions ACD fournies par la solution de centre d’appels
externe à la solution de téléphonie ;
40 / 113


Messagerie vocale ;
Évolution vers des fonctions de visioconférence/chat entre agents.
Fonctions d’exploitation



Supervision/statistique ;
Administration ;
Configuration.
Fonctions fournies sur les sites locaux
Les besoins de téléphonie sont :





Interface RTC (lignes T2) en particulier pour la réception des appels 15 en
provenance du site central ;
Interface avec le WAN, ou une interface LAN ;
Interface avec la téléphonie hospitalière (téléphonie administrative) ;
Modes dégradés : capacité à maintenir le service de téléphonie dans le cas où le
réseau IP/MPLS est indisponible (mode « survie ») ;
Fourniture de téléphone IP.
4.2.2.1.2 Architecture envisagée
Ces éléments sont donnés à titre indicatif pour faciliter la compréhension. Toute solution qui
répond aux exigences fonctionnelles et non fonctionnelles exprimées reste acceptable,
quand bien même l’architecture proposée est différente, mais les principes structurants
présentés doivent cependant être pris en compte.
41 / 113
La solution centrale est un ensemble de « Call Manager » répartis sur deux datacenters. Le
second datacenter est passif.
Pour assurer la meilleure disponibilité du système, des gateways avec option de
« survabilité » sont prévues sur les sites locaux des CRRA. Elles permettent l'acheminement
nominal :

Du flux téléphonique TDM depuis l'opérateur de collecte vers le CRRA ou depuis le
CRRA vers l’extérieur ;
 De la signalisation depuis et vers les Datacenters centraux.
Elles permettent l’acheminement nominal du trafic en TDM depuis les datacenters centraux.
4.2.2.2 Principes structurants
Pour délivrer le service de téléphonie, les principes suivants sont considérés comme
structurants dans la solution pressentie :
 La stratégie d’achat prévue est la suivante :
o Les matériels et les licences de la solution de téléphonie sont achetés par le
SI-Samu ;
o Les datacenters sont également fournis par l'opérateur de service, les
solutions de téléphonie et logicielles (notamment le logiciel de régulation
médicale) étant colocalisées au sein de chaque datacenter (actif et passif) ;
 La solution doit être homogène entre les parties téléphonie, call management et
gateway afin d'éviter les problèmes d’interopérabilité ;
42 / 113

La collecte des appels est centralisée en TDM. L’acheminement vers les CRRA se
fait par aboutement sur réseau RTC en mode nominal et en IP en backup. En effet, la
qualité de la voix est primordiale : la tonalité de la voix, le stress etc. sont des
indicateurs indispensables à la pause d’un diagnostic efficace. Les phénomènes de
compression/décompression sont donc à éviter au maximum ;
La capacité à tenir la charge : la solution mise en place doit être capable d’absorber
des pics d’activité sans que le service soit interrompu ;
La capacité à croître de manière rapide en cas de phénomène à cinétique dite
« lente » (cas de grippe, épidémie, nécessité d’accroître le nombre de postes
téléphoniques et/ou d’agents) ;
Forte disponibilité : la fonction phonie des Samu ne peut tolérer une panne de plus
de 5 minutes par an. La solution de téléphonie doit donc avoir une disponibilité 5-9 ;
Une répartition sur deux datacenters (actif/passif) est prévue.




Id
Présentation de la solution de téléphonie
TLC-PRES-1
Pouvez-vous présenter la solution de téléphonie que vous envisagez pour répondre à
nos orientations:
 Architecture de la solution : localisation des composants, résilience, interaction
avec des logiciels ou équipements tiers sans oublier le CTI link ;
 Gamme/modèle d’équipements envisagés, technologies utilisées (hardware
spécifique, matériel IT standard +l ogiciel, etc.), protocoles et standards
supportés, interfaces d’intégration avec des applications ou périphériques tiers
(APIs, etc.).
Id
Gestion de la capacité
TLC-CAPA-1
TLC-CAPA-2
Quelles sont les limites de la solution en termes de positions, extensions,
d’interactions simultanées, etc. ?
Préciser notamment :
 Le nombre maximum d’appels simultanés ;
 Le nombre d’agents maximum ;
 Le nombre de nœuds de routage.
Pouvez-vous indiquer les durées d’approvisionnement matériel et logiciel types des
composants concernés pour le SI-Samu au niveau central et au niveau local ?
Quelles sont les solutions mises en œuvre pour pallier des défaillances matérielles ?
Id
Fonctionnalité du service de téléphonie
TLC-FNCT-1
Concernant la gestion de flux d’appels entrants, préciser la disponibilité ou le niveau
de couverture des fonctions suivantes :
 Fusion d’appels entrants sur un même poste sans avoir à passer par la
fonction conférence : fonction téléphonique qui permet de mettre en relation
deux communications téléphoniques sans être obligé de se connecter à l’une
d’entre elle et/ou de mettre en attente l’une d’entre elle ;
 Transfert accompagné ou non ;
 Usage de fréquence vocale ;
 Reprise d'appels internes.
TLC-FNCT-2
Concernant votre service de messagerie vocale, quelles sont les interfaces
disponibles ? Quelles sont les API disponibles pour une intégration informatique ?
TLC-FNCT-3
Est-il possible de s’intégrer avec l’annuaire des abonnés au système (au SI-Samu) et
selon quels mécanismes ?
43 / 113
TLC-FNCT-4
TLC-FNCT-5
Gestion des appels sortants : confirmez-vous qu’il est possible d’afficher :
 Le numéro « 15 » à la place du numéro de la ligne sortante lors d’un appel
sortant du SI-Samu vers l’extérieur ;
 Le numéro de l’agent ou du poste physique, si aucun agent n’est logué sur le
poste téléphonique de la personne appelée lors d’un appel interne.
Concernant le téléphone supportant les fonctions de gestion de flux téléphoniques
décrites plus haut, l’ASIP Santé souhaite les caractéristiques suivantes :
 La possibilité de gérer plusieurs conversations simultanées (6) et des
conférences (minimum 3 personnes) avec mixage local ;
 Gestion du casque :
o Depuis le téléphone ;
o Depuis un PC ;
 Sécurité :
o Support authentification 802.1x ;
o Gestion des VLAN ;
o Signature des logiciels téléchargés sur le téléphone ;
o SIP/TLS ;
o HTTPS.
Préciser les modèles de téléphones/gammes correspondant à ces besoins.
Préciser également :
 La liste des touches paramétrables, le moyen de les paramétrer ainsi que les
différentes fonctions paramétrables par le biais de ces touches, y compris des
fonctions avancées, en cas de dysfonctionnement de l’organe de couplage
téléphonie informatique ;
 La taille de l’écran (nombre de lignes, caractères par ligne) pour chaque
poste.
Le schéma ci-dessous décrit de manière simplifiée le périmètre de responsabilité des
fonctionnalités ACD. Le marché M2 (cf. chapitre 1.2) sera en charge en mode nominal. En
cas de défaillance des fonctionnalités ACD nominales, le marché M1 devra assurer en
backup des fonctionnalités de type ACD.
44 / 113
Id
Routage intelligent/distribution
L’objet des questions sur le routage/distribution est d’apprécier les capacités propres du système de
téléphonie en termes de routage/distribution des appels, dans le cas où la solution de gestion de
centre d'appels (solution ACD/CTI externe) est hors service.
Préciser votre support des fonctions de routage suivantes :

TLC-DIST-1




Blacklist : fonction qui permet de gérer les appels malveillants et d’appliquer
un traitement particulier, dynamique dans le temps ou selon les actions du
« malveillant ». Même question pour la gestion des whitelist (numéro
privilégié) et graylist (numéro à traitement spécifiquement) ;
Traitement des appels inappropriés : exemple d'un fax sur le 15 ;
Traitement des appelants connus : annuaire interne du Samu ; DRM récents
connus au sein du LRM ;
Fonction « Last Call Agent » : fonction téléphonique qui permet de distribuer
l'appelant sur le dernier agent avec qui il a été en contact, par la
reconnaissance de son numéro de téléphone ;
Traitement des numéros étrangers avec identification du pays d'origine.
Préciser votre support des fonctions d’ACD/routage suivantes :



TLC-DIST-2


Gestion des débordements ;
Mise en retrait, en pause, en wrap-up (pause traitement post-appel) ;
Intrusion : fonction téléphonique qui permet à un agent logué comme
« superviseur » de pouvoir se connecter à une conversation et le cas échéant
d'intervenir dans la conversation en cours ;
Double écoute : fonction téléphonique qui permet à un agent logué comme «
superviseur » de pouvoir se connecter à une conversation sans possibilité
d'intervenir dans les échanges ;
Gestion des fermetures de salle d’attente (téléphone) : la gestion des
fermetures de salle est l'action qui suit la prise en compte de l'indisponibilité
d'une salle. Une salle peut être indisponible soit parce qu'un calendrier indique
qu'elle est fermée, soit parce qu'aucun agent n'est connecté.
Préciser votre mode de gestion des appels perdus :

TLC-DIST-3
TLC-DIST-4
Identification et visualisation des appelants ayant été mis en attente dans une
file ou salle d’attente et qui ont raccroché avant que la fin du traitement de
l’appel soit intervenue ;
 Surveillance de certaines salles d'attente ;
 Alerte en cas de perte de communication ;
 Proposition de rappel dans le groupe de traitement à l'origine du transfert en
salle d’attente (Last Call Agent).
Est-il possible de placer l’appel dans 2 files d’attentes simultanément ?
Par exemple, l’appel est présent dans la file de l’agent « lambda » car c’est l’agent qui
a pris cette interaction lors d’un précédent appel mais il est souhaité que cet appel soit
dans la file globale du CRRA pour être pris dès qu’un agent est disponible même si ce
n’est pas lui le dernier agent appelé.
45 / 113
Id
Téléphonie administrative
Téléphonie administrative : tout appel en dehors du cadre de l’activité SI-Samu.
Préciser la disponibilité des fonctions suivantes :
Dans notre contexte, quels modèles/possibilités envisagez-vous pour :

TLC-TLAM-1
L’accès au plan de numération du Samu par l’ES ou l'accès au plan de
numérotation de l’ES de rattachement du Samu par la solution ;
 L’accès à l’annuaire de l’ES/du Samu.
Pouvez-vous décliner votre réponse en fonction :


Du point de vue de l’usager (utilisation de préfixes) ;
Du point de vue de la configuration (impact sur la solution Samu).
TLC-TLAM-2
Comment gérez-vous les appels de système bippeur et retour éventuel ?
TLC-TLAM-3
Précisez vos modèles de gestions des appels sur DECT (dualité téléphonie fixe
physique - téléphonie fixe en situation de mobilité).
TLC-TLAM-4
Précisez l’intégration possible d’un appel (signalisation de présence sur un interphone
commandant une porte) vers le système de téléphonie.
TLC-TLAM-5
Précisez la capacité à intégrer un système d’interphonie (permettant des appels
d’interphone à partir de la ligne téléphonique d’un agent).
TLC-TLAM-6
Cas des configurations téléphoniques issues des PABX (ou IPBX) de l’ES de
rattachement (groupes d’appel, filtrage) :
 Préciser les fonctions disponibles sur le poste via une interface intra PABX
(type QSIG ou autres – précisez par signalisation utilisable) ;
 Préciser la possibilité de limiter l’usage de ces fonctions aux appels
« administratifs » ;
 Préciser les besoins en préfixages éventuels.
TLC-TLAM-7
Précisez la capacité de vos matériels à accepter une communication de type
visioconférence entre agents :
 Intra CRRA ;
 Inter CRRA.
Id
Intégration avec flux externes
S’agissant de l’intégration avec l’opérateur de collecte : quelle architecture préconisezvous à l’interface avec les liens TDM de l’opérateur ou des opérateurs ?
TLC-INTE-1
Même question concernant d’une livraison en trafic IP ?
Préciser la modularité des équipements envisagés (compte tenu de la capacité
envisagée) et leur résilience.
TLC-INTE-2
Interface avec les PABX (majorité) ou IPBX des Établissements de Santé :
 Préciser les signalisations supportées ;
 Précisez la liste de PABX classiques/IPBX déjà interfacés en cas de
protocoles propriétaires ;
 En particulier, préciser votre support de la signalisation QSIG.
TLC-INTE-3
Intégration avec le Serveur Vocal Interactif :
 Préciser les interfaces et protocoles supportés ;
 Préciser les SVI tiers compatibles.
Cela nécessite-il un développement spécifique ?
46 / 113
TLC-INTE-4
Intégration avec les enregistreurs :
Préciser les interfaces et modes d’intégration supportés :
 Actif : établissement d’un appel avec l’enregistreur ;
 Passif : duplication du flux media ;
 Passif : utilisation d’un service de conférence.
Préciser les interfaces (media, signalisation).
Préciser les équipements avec lesquels vos solutions sont déjà intégrées.
TLC-INTE-5
Solution call center tiers :
 Préciser les solutions supportées avec votre solution de téléphonie ;
 Préciser si le protocole SIP standard est supporté et les éventuelles
limitations ;
 Préciser les interfaces disponibles pour l’intégration (interface CTI) et les
limitations en termes d’échanges de données entre les deux systèmes ;
 Préciser les informations fournies au CTI/ACD notamment sur le login/logout
et les états de l’agent.
Id
Qualité de la voix
TLC-QOSV-1
Qualité auditive :
Préciser les outils disponibles de mesure de la qualité audio (mesure qualité
objective), ou du moins ceux que vous préconiseriez ?
Préciser les paramètres suivis :
 Mesure issue des recommandations P800 (type PESQ) ;
 Délais de transit moyen, minimum et maximum constatés, gestion de la
latence ;
 Écho, gigue, diaphonie, niveau du signal acoustique, niveau de bruit, perte de
paquets, temps d’établissement des appels.
Id
Supervision/reporting
TLC-SPRV-1
Est-il possible de superviser :
 Tous composants de la solution ?
 Le trafic sur les liens ?
 D’autres éléments ?
Précisez les possibilités d’intégration de cette supervision avec un système tiers.
TLC-SPRV-2
Disposez-vous d'un outil de taxation? Le cas échéant, présenter cet outil.
TLC-SPRV-3
La supervision est-elle compatible avec un outil d’hypervision ?
Préciser :
 Le type d’interface : SNMP, autres ;
 La capacité à filtrer/agréger des alarmes significatives (franchissement de
seuil).
TLC-SPRV-4
Pouvez-vous confirmer la possibilité d’export des différents compteurs/mesures vers
une solution de reporting ?
Pouvez-vous décrire le principe (format, export, durée de conservation) ?
Dans le cadre d’un processus de supervision globale :
TLC-SPRV-5


Pouvez-vous préciser les indicateurs que votre solution est capable de
remonter ?
Pouvez-vous préciser d’autres indicateurs qu’il vous semble pertinents de
remonter ?
47 / 113
Id
Configuration
TLC-ADMN-1
Configuration des utilisateurs :
Concernant la mise à disposition de service de configuration des abonnés en masse
(une unique opération pour configurer un groupe d’abonnés), l’ASIP Santé
souhaiterait :
 Des fonctions d’export de base de données de tous les paramètres
d’abonnés ;
 Un outil de vérification de la cohérence des configurations des abonnés
(cohérence entre différents paramètres des postes d’abonnés) ;
 Le paramétrage des fonctions téléphoniques pris en compte de manière
dynamique (ou différée selon les besoins).
Pouvez-vous confirmer et préciser la capacité de votre solution à couvrir ces points ?
Gateway pour l’acheminement local via les T2 des CRRA :
TLC-ADMN-2
Précisez la faisabilité des deux points suivants :
 L’interface de configuration permet de modifier l’ensemble des paramètres de
chaque passerelle d’interconnexion avec le RTC (activation / désactivation
des interfaces, modification de la configuration des interfaces, modification
des options de secours de la téléphonie locale embarquées sur la passerelle) ;
 Chaque passerelle doit pouvoir être accessible via un protocole de prise en
main à distance. La configuration de chaque passerelle doit pouvoir être
stockée et sauvegardée.
Décrire les possibilités d’administration de la passerelle même en cas d’isolement de
site (administration « out of band »).
TLC-ADMN-3
Paramétrage de masse de la configuration IP :
L’ensemble des paramètres IP d’un ou de multiples composants doit pouvoir
être changé à distance au travers de l’interface d’administration :
 Paramètres du serveur DHCP ;
 Paramètres liés aux options DNS, DHCP et IP éventuellement nécessaires au
bon fonctionnement de la solution.
Pouvez-vous confirmer et préciser la capacité de votre solution à couvrir ces points ?
TLC-ADMN-4
Configuration des composants centraux :
La solution doit permettre la modification de l’ensemble des paramètres des serveurs
centraux.
La solution permet-elle :
 La gestion des plans de numérotation (préciser, la problématique étant
nationale et locale) ;
 La configuration des paramètres de routage ;
 La configuration des matrices de distribution (fonction ACD).
TLC-ADMN-5
Configuration des routes :
Préciser le mode de configuration des acheminements du trafic téléphonique.
Acheminement des appels entrants vers les CRRA :
 Priorisation route TDM versus IP (et réciproque) ;
 Répartition entre deux T2 sur un CRRA (en supposant qu’ils ont un NDI
distinct) ;
 Cas où l’un des T2 est indisponible ;
 Limitation du trafic IP vers certains sites (dimensionnés à 50% du trafic
nominal) ;
 Trafic sortant :
o Choix de la route en Least Cost Routing (T2 local, lien QSIG ou SIP,
route par le central).
48 / 113
Id
TLC-ADMN-6
Administration
Préciser les impacts des mises à jour sur les fonctionnalités de téléphonie (durée de
coupure, nécessité de redémarrage compte tenu de l’architecture 5-9 envisagée).
Préciser les capacités de retour arrière en cas de bug critique.
TLC-ADMN-7
TLC-ADMN-8
Pour un accès par un administrateur local à un CRRA, préciser les possibilités de
restriction sur les données (ex : gestion des abonnés limités au CRRA de
rattachement).
La solution propose-t-elle nativement une interface graphique permettant de réaliser
des actions simples telles que la création/modification/suppression d’un agent, d’un
poste ?
Le cas échéant, pouvez-vous la décrire ?
Dans le cas contraire, existe-t-il une API permettant le développement d’une telle
IHM ?
49 / 113
Id
Gateway dans les CRRA
Fonctions demandées pour la gateway :




Service assurant nominalement l’interopérabilité avec le réseau RTC (liens
T2) local pour la réception des appels entrants ;
Fonction de « survie » : dans le cas où le site est isolé du site central : les
téléphones IP doivent pouvoir continuer à recevoir et émettre des appels tout
en conservant leur configuration ;
Possibilité d’interface analogique ;
Interface avec les PABX des ES (interface QISG).
Préciser les modèles de gateways en fonction de la typologie de sites suivante :
TLC-FNCT-7
CRRA
Nombre de
Sites
Nombre de personnes moyen en
pointe
Petit
25
10
Moyen
52
15
Grand
20
29
Central
97
2200
Un utilisateur traite en général plusieurs appels simultanément.
Préciser la connectivité (types d’interface), la capacité, le type de hardware et l’OS.
Un site comporte 1 ou 2 T2. Dans le cas à deux T2, les T2 arrivent a priori dans deux
locaux techniques distincts et il peut y avoir deux gateways.
Préciser le modèle de redondance.
TLC-FNCT-8
Mode « survie » (survivability) :
Préciser le mode de fonctionnement en cas de perte des liens avec l’IBPX principal :
 Critère de passage en mode local ;
 Fonctions disponibles sur le téléphone ;
 Éléments de configuration préservés (restriction d’appels, programmation des
touches, etc.) ;
 Temps de bascule (réenregistrement des téléphones) ;
 Pertes ou pas des sessions en cours.
Décrire la remontée en mode nominal (polling du site central par les téléphones, la
gateway) ?
Comment s’assure- t-on de la stabilité du retour au mode nominal avant de
rebasculer ?
Préciser les échanges et le protocole liés au service de survie (échanges gateway/CM
pour dupliquer la configuration, déclaration des gateways dans les terminaux; etc.).
TLC-FNCT-9
Préciser le fonctionnement (nominal et survie) s’il y a deux gateways (pour deux T2)
sur le site (fonctionnement actif/actif ou maître/esclave).
TLC-FNCT-10
Préciser la visualisation par l’utilisateur sur le téléphone s’il est en mode « survie ».
TLC-FNCT-11
Préciser les mécanismes de maintien de l’intégrité de la configuration /
resynchronisation en cas de changement de configuration (modification locale).
50 / 113
Id
Modes dégradés
Rappel: une disponibilité de type 99,999% est envisagée. Elle est répartie sur deux
datacenters.
Cas envisagés :
 Perte du Call Server (appelée aussi Call Manager dans le document) principal
sur un site, bascule sur un call server de backup ;
 Perte d’un datacenter, passage sur le second datacenter.
Préciser le mode de fonctionnement nominal que vous envisagez entre les calls
managers pour permettre d’assurer la reprise en cas de besoin (propagation des
configurations).
TLC-RESL-1
En cas de déclenchement, préciser :
 Événement déclencheur ;
 Conséquence pour les appels en cours ;
 Temps de bascule pour les téléphones ;
 Mode de retour à la normale.
Perte des fonctions call center (nominal et backup) : en cas de perte des fonctions
CTI/routage/distribution, préciser selon quel processus les fonctions natives d’ACD de
la solution de téléphonie peuvent reprendre la distribution des appels.
Préciser si la reprise est automatique.
TLC-RESL-2
TLC-RESL-3
Préciser la configuration des fonctions ACD en mode nominal (file de taille nulle par
exemple).
Pouvez-vous préciser la capacité de votre solution à réaliser des upgrades ou
opérations de maintenance sans arrêt ou dégradation de service ?
Préciser la stratégie type à adopter pour mettre à niveau les datacenters.
Préciser la possibilité de votre solution de continuer à fonctionner (signalisation,
acheminement des appels) en cas :
 D’indisponibilité des gateways sur les sites locaux ;
 Ou en cas d’indisponibilité des fonctions centrales de téléphonie.
Préciser les mécanismes mis en place ainsi que les éventuelles limitations
fonctionnelles.
Id
TLC-SECU-1
Sécurité
Préciser les mécanismes de sécurité pouvant être mis en œuvre dans la solution :
 Poste IP ;
 Administration des équipements ;
 Sécurisation des échanges entre les différents équipements qui composent
l’architecture de téléphonie ;
 Le contrôle d’accès au réseau ;
 La vérification de signature de fichiers.
Préciser comment les mécanismes cryptographiques employés dans la solution sont
gérés (ex : usage de certificats : stockage, diffusion).
Note : le cryptage des flux media n’est pas retenu (SRTP).
TLC-SECU-2
Disposez-vous d’une offre de Session Border Controler (ou à défaut précisez les
matériels fréquemment utilisés avec vos solutions) ?
Quelles sont le cas échéant vos recommandations de positionnement de ces SBC
51 / 113
dans l’architecture Samu ?
Id
Matériel et logiciel de base
TLC-SEXP-1
Préciser pour chaque élément les plates-formes matérielles et les OS et logiciels de
bases utilisés.
Préciser s’il s’agit de composants banalisés ou propriétaires.
Préciser si les éléments peuvent être installés dans un environnement virtualisé.
TLC-SEXP-2
Préciser les contraintes de la solution sur :
 Les services DHCP, DNS, NTP ;
 L’adressage IP.
Id
IPv6
TLC-INTX-1
La solution que vous proposez est-elle compatible IPv6 ? En mode nominal ou dualstack ?
4.2.3 Intégration des fonctions IPBX dans un domaine opérateur
4.2.3.1 Besoins
Le service d’Acheminement intervient dans le cadre de la distribution de l’appel depuis
l’opérateur de service vers le meilleur agent se trouvant dans un CRRA local via l’opérateur
de boucle locale.
Le service d’Acheminement concerne tout le trafic téléphonique entrant, reposant bien sur le
15 et le 112 mais aussi tous les numéros d’accès direct propres à chaque CRRA, ainsi que
potentiellement d’autres numéros gérés par les personnels du Samu.
En mode nominal, un appel arrive sur les infrastructures télécoms de l’opérateur de service
des Samu (IPBX + T2, ou autre architecture définie par l’opérateur de service), puis il est
qualifié par le système CTI qui détermine le meilleur agent cible pour la distribution. L’appel
est alors acheminé vers le CRRA local par un lien T2 et une gateway afin de mettre en
relation l’appelant et l’agent.
Plusieurs cas de modes dégradés sont possibles :




Le site local est en panne ;
La liaison T2 est tombée ;
Le réseau MPLS est tombé ;
L’opérateur de Service présente un dysfonctionnement.
Le site local est en panne (par exemple coupure d’électricité)
Dans ce cas, il faut nécessairement que l’entraide soit activée pour distribuer les appels sur
les autres CRRA suivant les stratégies de débordement mises en place. L’acheminement de
l’appel se fait normalement via le lien T2 vers le CRRA d’entraide identifié.
La liaison T2 entre l’opérateur de service et le CRRA local est tombée
Dans ce cas, l’appel est acheminé vers le site local via le réseau IP-MPLS.
52 / 113
Le réseau IP-MPLS entre l’opérateur de service et le CRRA local est tombé
Dans ce cas :


Les gateways locales sont en mode autonome et assurent la distribution locale des
appels ;
L’IPBX central doit pouvoir distribuer et déclencher l’acheminement des appels en
TDM (au moins les numéros accessibles publiquement des CRRA : numéro de tête
de ligne de la T2 et/ou numéros des agents en SDA).
L’état des agents peut être connu dans la mesure où les applications sur le poste de travail
de l’agent peuvent communiquer avec le central via un réseau VPN Internet en secours du
WAN MPLS.
Les modes de distribution envisageables peuvent donc être :



Basés sur les états du CTI ;
Basés sur l’ACD (test de la disponibilité des agents par appel) ;
Aveugles (pas de connaissance de l’état des agents).
L’opérateur de service présente un dysfonctionnement
Dans ce cas, l’appel est acheminé vers le site local depuis l’opérateur de collecte ou les
premiers équipements de l’opérateur de service via des tables de routage statiques.
La fourniture du service d’Acheminement est encadrée par des exigences opérationnelles
fortes :





Une haute disponibilité du service en 24/24 7/7 ; la fonction phonie des Samu ne
peut tolérer une panne de plus de 5 minutes par an mettant en péril toute la
téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une
disponibilité 5-9 ;
Une résilience forte de la solution pour répondre à tout type d’incident de
fonctionnement et permettre la continuité du service ;
Une capacité d’absorption de pics d’appels, tout en préservant la qualité vocale et
la performance de traitement des appels ;
Une capacité industrielle de la solution du service vocal pour faciliter son
déploiement et maitriser l’évolutivité et la pérennité de la solution ;
Une capacité à gérer la dualité d’acheminement TDM/IP, à des fins de
résilience de chemin d’accès. L’acheminement vers le CRRA est fait
nominalement en T2 et par aboutement avec l’appel entrant. L’aboutement est
privilégié pour garantir le meilleur contrôle de l’appel en cas de défaillance et pour
maintenir certaines fonctions en central (ex : enregistrement).
Pour plus d’informations, se référer à l’annexe du chapitre 5.1 présentant la cinématique de
l’appel.
53 / 113
Acheminement des appels
Id
Reprise de l'appel acheminé vers le CRRA (via TDM ou via WAN) :
ACH-ACHC-1
ACH-ACHC-2
Selon votre expérience, l'acheminement par aboutement est-elle la solution la plus
appropriée ? Y a-t-il des alternatives ?
Préciser si votre solution est capable de gérer la commutation d’appel visioconférence
(Le cas échéant, une description générale des grands principes sera appréciée).
Préciser les spécificités sur l’acheminement (route WAN/MPLS en QoS visio par
exemple).
Acheminement WAN IP
Id
Les liens de raccordement des sites au WAN ne sont pas nécessairement
dimensionnés pour traiter 100% du trafic dans un premier temps (usage de backup par
rapport au TDM).
ACH-ACHC-3
Pouvez-vous préciser vos recommandations liées :
 Aux règles d’ingénierie/dimensionnement concernant la saturation d’un lien
WAN d’acheminement des appels ;
 Aux mécanismes permettant de s’appuyer entre autres sur la remontée d’une
information de saturation, pour permettre le déclenchement d'un scénario
d'entraide.
Traitement de la signalisation d’appel
Id
ACH-RESL-1
ACH-RESL-2
ACH-RESL-3
ACH-RESL-4
Avez-vous la capacité à discriminer et gérer les différents cas d'échecs d'un appel :
 L'agent ne répond pas ou est occupé ;
 T2 saturée ;
 T2 hors service ;
 Gateway(s) du CRRA hors service (plus de service de téléphonie) ;
 WAN/IP hors service ;
 Autres (préciser).
De quelle "intelligence en propre " dispose l'acheminement pour traiter les « retentatives » en respectant les règles pré définies :
 Bascule de chemin TDM vers le WAN sur un même CRRA (T2 du CRRA
toutes saturées ou hors service par exemple) ;
 Bascule vers un CRRA d'entraide lorsque ce CRRA est injoignable ou lien
data du CRRA saturé.
Pouvez-vous préciser votre capacité à remonter ces informations de signalisation vers
le CTI pour que des décisions de « réacheminement » puissent être prises ? (scénario
d'entraide par exemple) ?
La solution de téléphonie est répartie sur deux datacenters. Un opérateur de collecte
assure la fourniture des flux d’appels en amont vers le datacenter actif.
En cas de bascule entre deux datacenters, pouvez-vous préciser les conséquences :
 Sur les communications en cours (via TDM ou via WAN) ;
 Sur les statistiques ;
 Sur la bascule des postes IP (reconnexion au second datacenter).

54 / 113
ACH-RESL-5
ACH-RESL-6
En complément de RESL-1, dans le cas de perte du WAN IP/MPLS, pouvez-vous
fournir une description « de bout en bout » de votre fonctionnement ?
 Capacités résiduelles à distribuer/acheminer les appels (préciser les numéros
accessibles) ;
 Notification à la solution centre d’appels pour que celle-ci se limite aux agents
accessibles en cas de perte du WAN.
Dans le cadre d’une communication tripartite provenant d’un autre centre d’appel (par
exemple l’appelant a contacté le centre d’appel du 18, qui met en conférence à 3 avec
un CRRA), vous semble-t-il possible malgré l’entrée initiale externe au SI-Samu (appel
sur le 18) de maintenir l’aboutement direct entre l’appelant et le CRRA et sortir de la
boucle le correspondant 18 ?
Supervision et SLA
Id
ACH-SVLA-1
Pouvez-vous préciser, selon vos retours d’expérience, le temps d'établissement
d'appel atteignable :
 En dégradé, pour un appel transitant par le WAN/IP après échec du T2 ;
 Pour un appel transitant par le WAN/IP après avoir testé que les deux T2 sont
Hors Service.
Le temps d’établissement, exprimé en secondes, est défini comme suit : temps entre
la désignation d’une extension (un agent) par la solution de centre d’appels et la
présentation de l’appel à l’agent (première sonnerie).
ACH-SVLA-2
Pouvez-vous préciser les informations de supervision de l'acheminement (alarmes,
indicateurs) pouvant être remontées à un système d'hypervision (signalisation, autre) ?
Par quel outil et quelle interface ?
Id
Qualité de la voix
ACH-QOSV-1
Pouvez-vous préciser votre capacité à diagnostiquer les problèmes de voix sur des
trajets IP (LAN/WAN) ?
4.2.4 Fonctions d’ACD locale ou centrale
4.2.4.1 Besoins
Le service de « Routage et Distribution » intervient dans le cadre de la qualification et de la
segmentation des interactions entrantes ou sortantes puis leur distribution depuis l’opérateur
de service vers l'agent (ARM ou médecin régulateur) se trouvant dans un CRRA local selon
des règles définies par les Samu. Le service de routage et de distribution ici décrit n'intègre
pas le SVI.
La qualification et la segmentation des appels (ou interactions) permettent d’enrichir la
connaissance de l’appel, de l’appelant et de son historique interactionnel et d’orienter la
décision de routage – distribution de l’appel.
Les mécanismes mis en œuvre reposent sur la capacité à :

Collecter tous les éléments amont de qualification de l’appel comme par exemple :
o
La définition du département de provenance de l’appel (donnée fournie par
l’opérateur télécom ou de collecte) ;
o
Le numéro appelé pour contacter le Samu et la typologie de l’appelant
(particulier, professionnel de santé, pompier,..) ;
55 / 113
o
Les éléments de qualification de la demande connus du SVI ;

Interroger des systèmes de base de données (SI-Samu ou base de données
d’interactions : réitération d’appels et historique interactionnel) en vue de segmenter
l’appel ;

Gérer des priorités d’appels pour la distribution, fonction de la combinatoire de tous
les éléments de qualification – segmentation collectés ;

Identifier le CRRA nominal en charge du traitement de l’appel et les compétences
nécessaires ;

Orchestrer la gestion de mécanismes d’entraide vers d’autres CRRA ;

Enrichir et stocker la connaissance de l’appel, des informations collectées et de leur
traitement selon des mécanismes à définir ultérieurement.
La distribution des appels (ou d’interactions) rend les services suivants :

Établir la décision de distribution de l’appel sur :
o
La base du statut de la personne à même de prendre l’appel (principalement
ARM), remonté via le bandeau téléphonique ;
o
La base des principes de routage (paramétrage de files d’attentes) ;

Piloter les appels en attente de traitement au travers de files d’attente (ou salles
d’attente) spécifiques ;

Engager, si besoin, des mécanismes de débordement vers d’autres CRRA selon des
principes d’activation soit manuelle soit automatique en fonction des règles définies
par les Samu ;

Dans le cadre des Samu, contrairement à la logique de centre d’appels habituels, les
mécanismes de dissuasion ne seront pas mis en œuvre ; par ailleurs, il est mis en
place un système de rappel des appels raccrochés :
o
Pendant le parcours vocal dont la durée de communication est supérieure à X
secondes ;
o
En salle ou file d'attente après prise en compte par un agent, quelle que soit
la durée de communication.
Principales caractéristiques de la solution attendue :
 Capacité à gérer des services et stratégies de routage – distribution soit communs
à tous les CRRA, soit par ensemble de CRRA présentant des besoins communs, soit
de manière spécifique à un CRRA donné ;


Gestion de compétences et de profils communs/spécifiques :
o
Compétences métiers communes à tous les Samu ;
o
Compétences locales spécifiques à chaque Samu (département, métier
spécifique,..) ;
o
Profils métiers communs pour les utilisateurs de centre d’appels mais
différenciés par la compétence locale. Par exemple, mise en place d’un profil
général ARM pour lequel on affecte la compétence géographique 94 afin de
cibler un ARM du Samu de Créteil.
Forte disponibilité de la solution : la fonction phonie des Samu ne peut tolérer une
panne de plus de 5 minutes par an mettant en péril toute la téléphonie de plusieurs
Samu. La solution de téléphonie doit donc avoir une disponibilité 5-9 ;
56 / 113


Administration métier de la solution, offrant des interfaces orientées « utilisateur
final » apportant souplesse et réactivité ;

Urbanisation des développements et des paramétrages des fonctions ou des
services, sous-services de routage et distribution (pour augmenter la réutilisabilité de
développements de routage – distribution et faciliter sa maintenance et évolutivité) ;

Capacité pour un utilisateur de réaffecter manuellement un appel en file d’attente
vers une autre file d’attente ou à prendre un appel dans une file d’attente pour le
traiter même si cette interaction ne lui est pas destinée ;

Capacité à mettre des appels en attente par un agent et de gérer plusieurs
conversations en parallèle.
Résilience et modes dégradés de la solution



En mode nominal, le service est assuré par la solution de traitement des appels ou
interactions qui gère l’ensemble des fonctionnalités (hors SVI) ;
En mode dégradé, une distribution de backup de type ACD intégrée à l’IPBX
(distribution des appels par compétence dans le système téléphonique) est mise en
place ;
La solution doit être hautement disponible et la bascule primaire/backup de la
solution ne doit pas perturber les interactions en cours. Il ne doit pas y avoir de perte
de communication ni de statistiques.
Plusieurs cas de mode dégradé sont possibles :







Le site local est en panne ;
L’un des deux datacenters hébergeant la solution de traitement des interactions
présente des dysfonctionnements majeurs ;
Le SVI est totalement ou partiellement indisponible ;
Le SI-Samu ne répond pas (partie informatique) ;
Les deux datacenters hébergeant la solution de traitement des interactions
présentent des dysfonctionnements majeurs ;
L’opérateur de service présente un dysfonctionnement majeur ;
Le réseau IP_MPLS entre l’opérateur de service et le CRRA local est coupé.
Le site local est en panne (par exemple coupure d’électricité) :
Dans ce cas, il faut nécessairement que l’entraide soit activée pour distribuer les appels
sur les autres CRRA suivant les stratégies de débordement mises en place.
L’acheminement de l’appel se fait normalement via le lien T2 vers le CRRA d’entraide
identifié.
L’un des deux datacenters hébergeant la solution de traitement des interactions
présente des dysfonctionnements majeurs :
Dans ce cas, la solution étant hautement disponible, une bascule doit se faire
automatiquement vers le second datacenter sans impact sur l’activité en cours,
notamment sans perte d’appels ni de statistiques.
Le SVI est totalement ou partiellement indisponible :
Dans ce cas, c’est la solution de gestion des interactions qui réalise une qualification par
défaut des interactions en fonction de règles définies par l'ASIP Santé.
57 / 113
Le SI-Samu ne répond pas :
Dans ce cas, c’est la solution de gestion des interactions qui réalise un traitement par
défaut des interactions en fonction de règles définies par l'ASIP Santé.
Les deux datacenters hébergeant la solution de traitement des interactions
présentent des dysfonctionnements majeurs
Dans ce cas, c’est la couche ACD de l’IPBX qui prend la main afin de distribuer avec un
minimum d’intelligence les interactions vers l’ARM ou le médecin régulateur le plus
pertinent.
L’opérateur de service présente un dysfonctionnement majeur
Dans ce cas, l’appel est acheminé vers le site local depuis l’opérateur de collecte via des
tables de routage statiques de type réseau intelligent de l’opérateur de collecte, ou par
routage statique par l’opérateur de service.
Le réseau IP_MPLS entre l’opérateur de service et le CRRA local est tombé
Dans ce cas, l’IPBX teste la disponibilité des conseillers via la tonalité de retour d’appel
(ou sonnerie de retour d’appel) afin d’acheminer l’interaction téléphonique vers le site
local par un mécanisme à préciser de l’opérateur de service ou depuis l’opérateur de
collecte via des tables de routage statiques de type réseau intelligent.
Pour plus d’informations, se référer à l’annexe du chapitre 5.4 présentant la cinématique de
traitement d’un appel entrant.
Id
Présentation de l’ACD
ACD-PRES -1
Pour répondre à nos besoins, pouvez-vous présenter les éléments
structurants/différenciants de votre service de distribution des appels notamment :
 Architecture de la solution : dédiée ou mutualisée, localisation des
composants, résilience ;
 Éditeur de la solution, technologies utilisées, langages, protocoles et standard
supportés ;
 Dimensionnement : nombre maximum d’appels simultanés, nombre d’agents
maximum ;
 Gestion des appels en parcage (attente de mise en relation) et mise en attente
(conservation de l’appel dans la salle de l’agent).
Id
ACD-CAPA-1
Quelles sont les limites de la solution en termes de positions, d’interactions
simultanées, etc... ?
ACD-CAPA-2
Pouvez-vous préciser votre capacité à provisionner X positions supplémentaires et le
délai associé (entrant et sortant) pour les rendre opérationnelles :
 100 positions agent ;
 500 positions agent ;
 1000 positions agent.
Id
Administration de la solution
ACD-ADMN-1
Pouvez-vous préciser si des outils d'administration fonctionnelle sont disponibles ainsi
que la listes exhaustives des fonctionnalités couvertes, avec par exemple :
 La mise en place de parcours simple ;
58 / 113






L’activation d’un segment dans une stratégie de routage ;
La modification de calendrier d’ouverture fermeture ;
L’activation de la lecture d’un message ;
L’activation du débordement ;
L'activation d'un scenario de crise ;
Etc.
Quel est le niveau d'autonomie en termes de configuration pour chacun des sites?
Quels outils d'imports ou de provisioning mettez-vous à disposition (exemple : ajout
d'un nouveau CRRA) ?
L’IHM d’administration (à préciser par outil) est-elle intégrable dans un portail web ?
ACD-ADMN-2
Pouvez-vous préciser s’il s’agit d’un client lourd ou léger ?
Existe-il une application smartphone permettant d’opérer des actions d’administration
fonctionnelle ou orientées métier? (le cas échéant, préciser les fonctionnalités offertes)
Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles ?
ACD-ADMN-3
Est-il possible de coupler l’IHM à un annuaire LDAP ? Pouvez-vous préciser les
contraintes et les incompatibilités éventuelles ?
Id
Routage
La solution dispose-t-elle d’une fonction native permettant de gérer une « blacklist »
d’appels malveillant et d’appliquer un traitement particulier, dynamique dans le temps
ou selon les actions du « malveillant » ?
ACD-ROUT-1
Pouvez-vous préciser son fonctionnement ? Préciser également les mécanismes de
« whitelist » (numéro prioritaire) et « graylist » (traitement sur listes de numéros en
pré-routage).
La solution dispose-t-elle d’une fonction native permettant de traiter les appels
inappropriés (gestion des appels de type fax) ?
ACD-ROUT2
ACD-ROUT3
ACD-ROUT4
ACD-ROUT5
ACD-ROUT6
Pouvez-vous préciser son fonctionnement, notamment sur le périmètre de la détection
du signal ?
Quel est impact sur l’architecture à mettre en place ?
Si la présentation du préfixage du n° appelant n’est pas réalisée, la solution est-elle
capable d’identifier nativement le pays d’origine de l’appelant ?
Le cas échéant, comment ? Faut-il alimenter manuellement une table des préfixes
téléphoniques ?
La solution permet-elle de réaliser (de manière native ou intégrée à un produit) :
 De la reconnaissance vocale avec analyse linguistique ?
 De l’analyse contextuelle du stress vocal ?
Ces fonctions liées à la question ACD-ROUT-4 peuvent être utilisées pendant les
moments d’attente pour identifier la charge émotionnelle (cris), le nom, le motif de
recours. Est-il possible de re-prioriser l’appel ou de lui affecter un traitement particulier
en fonction des informations obtenues ?
Est-il possible d’activer un scénario de routage (une branche spécifique) en fonction
du login d’un agent ayant une compétence donnée ou dans une file d’attente donnée ?
La solution est-elle capable de router des appels visio ?
ACD-ROUT7
Pouvez-vous préciser les éventuels prérequis et spécificités pour gérer les appels
visio? Dans le cas contraire, cette fonctionnalité est-elle dans votre roadmap, à quelle
date ?
59 / 113
ACD-ROUT-8
Si l’appelant raccroche avant que l’appel ne soit pris par un agent du CRRA, le Samu
souhaite qu’une campagne de rappel soit alimentée (appel sortant unitaire).
Cette fonctionnalité est-elle proposée en standard par la solution ? Ou bien nécessitet-elle des développements spécifiques ?
Id
Distribution
ACD-DIST-1
De quelle façon préconisez-vous le déclenchement du débordement sur un autre
CRRA ? est-ce faisable ou recommandé :
 À partir d’indicateurs techniques ;
 Selon un paramétrage de seuils ;
 Manuellement via une IHM ;
 Suite à détection d’une déconnexion du CRRA ;
 Selon un autre mécanisme (merci de préciser).
Comment est détecté le fait qu’un CRRA n’est pas disponible ?
La fonction « Last Call Agent » est-elle proposée nativement par la solution ?
ACD-DIST-2
ACD-DIST-3
Dans le cas où l’appel initial a été débordé sur un autre CRRA, est-il possible de
distribuer le second appel du patient :
 Sur l’agent ayant reçu le premier appel (fonction LCA) ?
 Sur un agent du CRRA qui aurait dû prendre l’appel s’il n’y avait pas eu de
débordement ?
Pouvez-vous préciser s’il s’agit de paramétrage ou de développement spécifique ?
Est-il possible de placer l’appel dans 2 files d’attentes simultanément ?
Par exemple, l’appel est présent dans la file de l’agent « lambda » car c’est l’agent qui
a pris cette interaction lors d’un précédent appel mais il est souhaité que cet appel soit
dans la file globale du CRRA pour être prise dès qu’un agent est disponible même si
ce n’est pas lui le dernier agent appelé.
La solution permet-elle de sélectionner le type d’acheminement (via T2 ou IP MPLS,
voir un load balancing entre les deux) ?
ACD-DIST-4
La solution permet-elle de choisir la règle en fonction du CRRA appelé ? Préciser si
des développements spécifiques sont nécessaires.
ACD-DIST-5
La solution permet-elle le media blending (rappel automatique en période d’activité
basse) ? Quelles en sont les contraintes ou les limites ?
Id
Intégration
ACD-INTE-1
Quels sont les différents IPBX supportés par la solution ?
Quels sont les types de liens possibles vers ces solutions ?
ACD-INTE-2
Quelles sont les éventuelles limitations de votre solution liées au protocole SIP ?
ACD-INTE-3
Un des besoins majeurs est l’intégration du canal voix radio au centre de contacts
Samu.
La problématique principale de l’interopérabilité de la radio sur le plateau du centre
d’appels est le manque d’échanges d’évènement entre la radio et la téléphonie. Cette
non-communication engendre donc une difficulté de gestion de l’activité pour un ARM
ou un MR (Médecin Régulateur) qui peut recevoir un appel téléphonique alors qu’il est
en train de traiter un appel radio. Idéalement, il faudrait qu’un appel radio puisse être
traité comme un appel téléphonique (sans SVI).
Quelle solution proposez-vous pour répondre à ce besoin ?
Avez-vous des expériences et références mettant en œuvre ce besoin ?
ACD-INTE-4
Quelles sont les différentes méthodes d’interfaçage supportées avec le SI-Samu ?
Utilisation de requêtes SQL, Web services ?
60 / 113
Id
ACD-STAT-1
Pilotage et données historiques
La solution propose-t-elle une IHM de pilotage permettant, quel que soit le média
(même la radio) :
 D’afficher des rapports statistiques temps réel ? En client lourd ou léger ?
Existe-il une application Smartphone ?
 D’afficher des rapports standards ? Des données statistiques unitaires ?
Agrégées ? (préciser l’agrégat le cas échéant)
Un outil de reporting est-il fourni ? En un client lourd ou léger ?
Des rapports standards sont-ils inclus ? Pouvez-vous donner des exemples judicieux
dans ce contexte ?
Id
Prérequis Techniques
ACD-TECH-1
Quels sont les types de bases de données compatibles avec la solution ?
ACD-TECH-2
Pouvez-vous nous fournir la matrice de compatibilité avec les systèmes d’exploitation
pour la partie serveur ?
La solution privilégiée est LINUX ; si cet OS n’est pas supporté merci d’en préciser la
raison ?
ACD-TECH-3
La virtualisation est-elle supportée ? Le cas échéant, sur quelle plateforme ? Préciser
les mécanismes concernés.
Id
Indicateurs / SLA
Pouvez-vous préciser le taux de disponibilité maximale de la solution ?
ACD-SVLA-1
ACD-SVLA-2
Merci de préciser quel est ou quels sont les éléments les plus sensibles de la solution.
Quels sont les différents SLA sur lesquels vous pouvez-vous engager ?
Id
Supervision
Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant
être remontées à un système d'hypervision du Samu ?
ACD-SPRV-1
Quels sont les intégrations possibles, l’objectif pour le SI-Samu étant d’avoir une vue
unifiée ?
ACD-SPRV-2


remonter ?
remonter ?
61 / 113
Id
Modes dégradés
ACD-RESL-1
ACD-RESL-2
En cas de bascule entre deux datacenters, pouvez-vous préciser les conséquences :
 Sur les communications en cours (via TDM ou via WAN) ;
 Sur les statistiques ;
 Sur la bascule des bandeaux (reconnexion au second datacenter).
En cas de pandémie, le besoin peut être de fonctionner avec des agents dispersés
(ex : télétravail) avec des téléphones banalisés (non reliés à la solution de téléphonie
du SI-Samu).
Pouvez-vous préciser vos offres pour faire face à de telles situations ?
Quel est le délai de déploiement de ces offres ?
Id
IPv6
ACD-INTX-1
4.2.5 Conférence ou communications multi-lignes
4.2.5.1 Besoins
Le service de conférence intervient dans le cadre de la gestion des interactions
téléphoniques afin de faciliter le traitement d’un dossier et coordonner les moyens à mettre à
œuvre sollicitant plusieurs intervenants.
L’agent régulateur du CRRA dispose de plusieurs lignes téléphoniques entrantes ou
sortantes lui permettant de décrocher plusieurs appels ou d’émettre plusieurs appels depuis
un même poste téléphonique. A minima, il doit disposer de 2 lignes, voire plus. Chaque ligne
peut recevoir des appels ACD, internes (entre 2 CRRA) ou administratifs (entre un CRRA et
l’Établissement de Santé par exemple).
1 : Gestion de double appel. En cours de communication avec un premier tiers, l’agent doit
pouvoir décrocher un deuxième appel avec la mise en garde du premier et pouvoir basculer
d’un appel en communication vers l’appel en garde. Pour chaque appel, l’agent doit pouvoir :



Soit engager un transfert accompagné ou supervisé ;
Soit mettre en conférence les 2 appels ;
Soit raccrocher un des 2 appels.
Il est à noter que tout appel peut être mis en attente dans la salle d'attente personnelle
de l'agent. Cette fonctionnalité sera néanmoins déclarée sous cette appellation de « gestion
de double appel ».
2 : Gestion de conférence à n tiers. En cours de communication avec un premier tiers,
l’appelé peut décrocher un deuxième appel et piloter les 2 appels selon le principe de la
bascule d’états d’appels décrit ci-dessus (communication / mise en garde). L’agent met en
conférence de 1 à n appels. L’agent peut mettre fin à un appel (avec son raccroché) tout en
maintenant la conférence des appels en cours et ajouter un nouvel appel dans la
conférence.
3 : Organisation de secours. Le principe est identique à la gestion de conférences à n tiers,
mais appliqué à l’émission d’appels sortants. L’agent doit pouvoir émettre et gérer une
conférence d’appels à n tiers et également associer dans la conférence un ou n appels
entrants.
Par défaut et a minima, la mise en conférence est calibrée pour pouvoir gérer 3 tiers
(entrants ou sortants).
62 / 113
4 : Gestion d’écoute discrète. L’ASIP Santé envisage de pouvoir mettre en place lors d’une
conversations le fonctionnement dit « d’écoute discrète », qui consiste à mettre la
conversation en cours en liaison avec un canal ou plusieurs canaux d’écoute, à des fins
d’enregistrement, ou d’amélioration de traitement (la fonction dite de « chuchotement »,
grâce à laquelle un superviseur peut parler à l’ARM sans que l’appelant ne l’entende, peut
être envisagée).
5 : Fusion de file d’attente. En complément de ces fonctionnalités de base, il est envisagé
un nouveau cas d’usage de fusion d’appels en file d’attente. Cette fonction s’entend par le
fait qu’un agent régulateur en communication sur un appel ou en conférence à n appels,
puisse sélectionner un appel en file d’attente et créer soit une mise en conférence soit
l’associer à la conférence en cours. Ce cas d’usage repose sur la capacité de la solution à
présenter les appels en file d’attente avec des éléments de qualification (exemple : saisie du
numéro de DRM dans le SVI, n° appelant,…). L’agent régulateur peut ainsi identifier
l’appelant ou l’appel correspondant.
La fourniture du service de conférence est encadrée par des exigences opérationnelles
fortes :

Une haute disponibilité du service en 24/24 7/7 ; la fonction phonie des Samu ne
peut tolérer une panne de plus de 5 minutes par an mettant en péril toute la
téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une
disponibilité 5-9 ;
Une capacité d’absorption de pics d’appels, tout en préservant la qualité vocale et
la performance de traitement des appels ;
Une capacité industrielle de la solution du service vocal pour faciliter son
déploiement et maitriser l’évolutivité et la pérennité de la solution ;
La mise en conférence d’appels ACD et non ACD, tout en sachant qu’il est
nécessaire de disposer de statistiques complètes sur les interactions ;
Une souplesse dans la mise en place de la conférence.





Id
Présentation de la fonctionnalité
CFR-PRES-1
Quelles fonctionnalités de mise en conférence préconisez-vous à l’ASIP Santé selon :
 Besoin classique ;
 Besoin spécifique de « fusionner » des appels ;
 Dimensionnement : nombre maximum d’intervenants sur une conférence
(ACD et non ACD).
CFR-PRES-2
Pouvez-vous préciser s’il est possible pour un agent de rejoindre une conférence
téléphonique en cours ? Préciser les modes envisageables.
CFR-PRES-3
Est-il possible de réaliser une conférence entre un appel ACD et un appel non ACD ?
(réconciliation d’appels de type « centre d’appels » et d’appels de type « accès direct
sur SDA »)
CFR-PRES-4
Dans l’hypothèse où un ARM possède deux lignes ACD, s’il réalise une conférence
avec ses deux appels ACD, peut-il recevoir un nouvel appel ACD ?
Autrement dit, la mise en conférence de 2 ou 3 appels ACD, libère-t-elle une ligne
ACD ?
63 / 113
Id
Intégration
CFR-INTE-1
Préciser de quelle manière la fonctionnalité est implémentée notamment pour la
« fusion » d’appels.
CFR-INTE-2
Quelles sont les éventuelles limitations liées au protocole SIP, à l’IPBX ou autres ?
Un des besoins majeurs est l’intégration du canal voix radio au centre de contacts
Samu.
CFR-INTE-3
Est-il possible d’envisager une conférence voix radio et voix téléphonie ?
Dans l’affirmative, quelle solution proposez-vous pour répondre à ce besoin ?
Avez-vous des expériences et références mettant en œuvre ce besoin ?
Id
La solution propose-t-elle des données statistiques historiques sur les conférences ?
Comment sont gérés les identifiants des appels, pendant et après la conférence ?
CFR-STAT-1
À combien de lignes d’enregistrements en base de données correspond une mise en
conférence ? La réconciliation de ces lignes est-elle possible et le cas échéant
comment ?
CFR-STAT-2
Lors d’une conférence à 4, suite à un appel entrant, si l’agent initialement ciblé
raccroche, comment est géré l’appel entrant (maintien de communication sur « lâché »
d’appel) ? Qui en devient « propriétaire » (responsabilité de raccroché) et comment ?
Qu’en est-il au niveau statistique ? Est-il possible de tracer les différentes étapes ?
Id
Modes dégradés
En cas de bascule entre deux datacenters, quelles conséquences voyez-vous :
CFR-RESL-1


Sur les conférences en cours (via TDM ou via IP) ?
Sur les statistiques ?
4.2.6 Service de couplage de téléphonie
4.2.6.1 Besoins
Ce chapitre décrit les besoins et les informations structurantes pour offrir un Service de
couplage Téléphonie-Informatique dans le cadre du SI-Samu.
Il présente les principales fonctionnalités attendues, les principes structurants qui
encadrent la solution à mettre en œuvre ainsi que certaines hypothèses prises.
Service de Couplage Téléphonie Informatique
Le service de couplage téléphonie-informatique intervient dans un premier temps dans le
processus de traitement d’un appel téléphonique, mais devra par la suite être en mesure de
traiter des interactions au sens large : radio, vidéo, mail, fax, SMS, et des tâches de back
office. Les modalités de traitement sont différentes pour chaque CRRA, en fonction des
processus et organisation mis en place.
Le couplage est réalisé au travers d’une application dite « application téléphonique » qui
réalise la passerelle entre le monde des télécoms (réception des appels, des interactions et
64 / 113
acheminement intelligent) et le monde de l’informatique (création et gestion d’un dossier de
régulation médicale).
Cette application téléphonique est utilisée par les agents des CRRA (notamment ARM, MR)
pour réceptionner les demandes des patients et faire la connexion avec des logiciels tiers
tels que le LRM et l’application de cartographie SIG (annuaire inversé, localisation des
appels).
Le service de couplage combine à la fois des fonctions de bandeau téléphonique (et par
extension multimédia) et des fonctions de supervision de l’activité téléphonique (et par
extension multimédia).
Les utilisateurs (ARM, MR, superviseur) disposent sur leur poste informatique de toutes les
fonctionnalités standards de téléphonie, d’une vue synthétique de leur activité, d’une vue de
l’état des salles d’attente personnelles, fonctionnelles et dynamiques avec la possibilité
d’interagir directement via l’interface graphique.
L’application téléphonique est ainsi à la fois une IHM, le point d’entrée et le point de liaison
entre les demandes d’un patient, le système d’information et son utilisateur.
D’une manière générale, le traitement d’un appel par un agent téléphonique est organisé en
4 grandes phases :

Attente et réception d’un appel :
o Concerne la distribution automatique de l’appel vers l’agent. En fonction de sa
disponibilité, de ses compétences, de règles d’équité, l’agent reçoit une
notification visuelle et/ou sonore de l’arrivée d’un appel ;
o Par défaut, nous sommes dans un mode de décroché manuel avec un
système de prévisualisation de l’appel. Il est cependant envisagé de gérer une
distribution en décroché automatique, à paramétrer en fonction de certaines
typologies d’utilisateurs, de salles d’attente et/ou de CRRA ;
o La notification s’accompagne de l’affichage des informations disponibles
relatives à l’appel, l’appelant (issues de la PFLAU) et au motif d’appel (issues
du Service d’Accueil Vocal) ;
Se référer au chapitre 4.2.4 pour plus de détail sur le service de routage et
distribution.


Prise d’appel :
o L’agent peut accepter l’appel qui vient de lui être proposé, soit en décrochant
physiquement son téléphone soit via l’interface graphique de l’application
téléphonique. Le décroché automatique est également possible selon le
paramétrage. Cette fonction doit être paramétrable par CRRA ;
o L’agent peut également, à son initiative, sélectionner via l’IHM un appel d’une
des salles d’attente dont il a la visibilité selon un principe de picking de l’appel
dérogeant à la règle de premier arrivé, premier servi. Ce mode de
fonctionnement est très largement utilisé car il permet aux agents de traiter
des appels plus prioritaires arrivant dans une même salle d’attente, et de faire
gérer par l’agent des règles dites d’élargissement ;
Traitement de l’appel : lorsqu’un appel est pris en traitement, l’état de l’agent passe
automatiquement en non prêt et l’interfaçage applicatif déclenche automatiquement :
o La création d’un DRM (dossier de régulation médicale) dans le LRM, ou
l’appel à un DRM existant (rappel) ;
o L’affichage de la position géographique de l’appelant dans le SIG (information
en provenance de la PFLAU : adresse de facturation pour une ligne fixe,
coordonnées géographiques pour une ligne mobile) ;
65 / 113

Fin d’appel : à la fin de l’appel, l’état de l’agent passe temporairement en
AfterCallWork (d’une durée paramétrable) avant le retour à l’état disponible.
Il est à noter que les fonctions de picking restent actives, permettant à l’agent de mettre de
manière automatique un appel en attente afin de prendre un autre appel.
Fonctionnalités du service de couplage téléphonie attendues








Le pilotage graphique des fonctions standards de téléphonie : composition par
numéro ou par nom (d’un CRRA), le décroché, le transfert direct/accompagné, le
changement d’état, la mise en attente, la mise en conférence, ... ;
La mise à disposition d’un annuaire interne Samu : CRRA, CHU, SDIS, ROR
(annuaire téléphonique des moyens liés à la mission des Samu, ….) ;
La visualisation des informations de l’appel : numéro appelant, origine
15/17/18/112, parcours SVI, annuaire inversé PFLAU, etc. ;
La visualisation des salles d’attentes personnelles/fonctionnelles/dynamiques, des
salles de crises et d’entraide le cas échéant. La liste est personnalisable en fonction
du CRRA dans lequel opère l’agent ;
La visualisation de l’historique : appels reçus, sortants, manqués, complétés des
informations associés à l’appel ;
La gestion graphique des appels : picking d’appel depuis une salle d’attente,
transfert vers autre salle d’attente ;
La capacité de communication avec des applications clientes : LRM et SIG dans
notre cas ;
Le pilotage de l’enregistrement : bien que 100% des conversations avec des
patients soient enregistrées, l’agent peut interrompre l’enregistrement dans le cadre
des appels non liés à la régulation médicale : (appels internes, personnels, …) voire
réécouter des appels enregistrés.
Dans le cadre de ce besoin l’interface graphique de l’application téléphonique devra être
adaptable selon le profil utilisateur (ARM, MR) et son CRRA d’appartenance.
Principes structurants
Pour délivrer le Service de Couplage Téléphonie Informatique, les principes suivants sont
considérés comme structurants dans la solution pressentie :



L’application téléphonique est de type client léger et hébergée dans un
datacenter où sont colocalisés les services de téléphonie et le SI Santé.
Disponible par une simple connexion web, de préférence, l’application téléphonique
ne nécessite aucune installation en local et est diffusée directement à tous les
utilisateurs à chaque nouveau déploiement. Pour des raisons de robustesse et de
sécurisation, l’application sera déployée sur plusieurs serveurs répartis sur plusieurs
sites. Un développement tirant profit des nouvelles techniques de programmation
telles que le WebSocket est souhaitable ;
L’application téléphonique est de type « stand alone » (versus un mode intégré
au LRM et/ou au SIG). Le type « stand alone » permet de limiter l’adhérence entre le
fonctionnement du LRM/SIG et celui de la téléphonie, il diminue ainsi les cas de
pannes potentielles ;
L’application téléphonique dispose d’un écran entier en zone d’affichage. Les
agents disposent a minima de trois écrans : un pour la gestion de l’application
téléphonique, un pour LRM, un pour le SIG ou autres systèmes à la décision. Il est
envisagé un quatrième écran, permettant d’avoir le SIG affiché en permanence ;
66 / 113

Un couplage « faible » avec le LRM et le SIG, bidirectionnel par échange de
message est souhaitée. L’intégration peut-être « server side » ou « client side » :
o Soit l’application téléphonique diffuse des événements (prise d’appel,
raccroché, …) aux applications clientes (LRM, SIG). L’application cliente est
libre d’agir ou non suivant le type d’informations véhiculées ;
o Soit l’application téléphonique expose une API lui permettant d’être pilotée par
une application cliente (composer un numéro, raccrocher, mise à jour de
données attachées à l’appel, changement d’état, …) ;
Une capacité à tenir la charge : l’application téléphonique doit être capable
d’absorber les pics de charges sur un seul datacenter sans dégradation de la qualité
de service ;
Forte disponibilité.


Id
CTI-PRES-1
CTI-PRES-2
CTI-PRES-3
Présentation du service de Couplage Téléphonie Informatique
structurants/différenciants de votre service CTI notamment :
 Architecture de la solution : produit éditeur/développement spécifique,
localisation des composants, résilience ;
 Éditeur de la solution, technologies utilisées, langages, protocoles et
standard supportés ;
 Dimensionnement : nombre maximum d’appels simultanés, nombre
d’agents maximum (conseiller et superviseur).
Votre solution est-elle capable d’interagir avec des bandeaux externes ? Quelles
interfaces, APIs, utilisez-vous ?
Préciser les éventuelles contraintes et limitations, liées notamment à des actions
faites depuis le poste téléphonique. Par exemple, désynchronisation du bandeau et
du téléphone si le décroché/raccroché (ou changement d’état…) est fait depuis le
téléphone ou un softphone.
La solution permet-elle nativement une personnalisation avancée de l’interface à
plusieurs échelons : globale, CRRA et agent ? Préciser.
Intégration avec la téléphonie
Id
Quelles sont les contraintes d’interconnexion du service de Couplage Téléphonie
Informatique avec le service de téléphonie ?
CTI-INTE-1
Préciser les architectures utilisées (connecteur spécifique, protocole/langage) et les
fonctionnalités offertes pour chacune des interconnexions : pilotage de l’état du
téléphone, fonctionnalités téléphonique depuis le bandeau, statistiques sur l’appel,
statistique sur le centre d’appel, etc.
Préciser les normes et interfaces supportées (en particulier CSTA - ECMA-269, 6th
Edition).
Préciser la liste des constructeurs et opérateurs ToIP avec lesquels le service de
Couplage Téléphonie Informatique est compatible et/ou certifié (préciser).
CTI-INTE-2
Préciser les prérequis techniques et économiques en termes de licence.
Quelles sont les contraintes et limitations pour le service de Couplage Téléphonie
Informatique dans un environnement SIP ?
Préciser les impacts éventuels au niveau de l’architecture.
CTI-INTE-3
Dans l’hypothèse où vos solutions couvrent les fonctionnalités IPBX et CTI, pouvezvous nous indiquer les avantages et inconvénients de recourir à une solution
intégrée plutôt qu’à deux solutions dissociées ?
67 / 113
Intégration avec applications tierces
Id
CTI-INTE-3
CTI-INTE-4
CTI-INTE-5
CTI-INTE-6
CTI-INTE-7
Préciser les modalités d’interfaçage avec le LRM (en client léger) pour la création
automatique d’un DRM sur traitement d’un appel :
 Lien d’intégration client side, server side ;
 Protocole de communication ;
 Prérequis technique.
Préciser les modalités d’interfaçage avec le SIG (en client léger) pour l’affichage de
la localisation de l’appelant :
Préciser les modalités d’interfaçage avec l’enregistreur pour piloter
l’enregistrement :
 Connecteur ;
Préciser les bénéfices et limitations d’une intégration client side et d’une intégration
server side.
Préciser les modalités d’interfaçage avec des annuaires du marché :
 Connecteur ;
Interconnexion avec le service ACD
Id
Quelles sont les contraintes d’interconnexion du service CTI avec le service de
distribution d’appels ? Pouvez-vous distinguer les cas d’un ACD associé à un IBPX,
de celui d’un ACD associé à une solution ACD logicielle ?
CTI-INTE-8
Quelle est l’architecture nécessaire (interconnexion directe ou via un connecteur,
langages de dialogue …) ?
CTI-INTE-9
Préciser la liste des éditeurs ACD avec lesquels le service CTI est compatible.
Préciser le cas échéant les contraintes et limitations à la transmission des éléments
de contexte de l’appel du service ACD au service CTI.
Id
Supervision activité du CRRA
CTI-SPRV-1
Précisez votre capacité à proposer à chaque agent une vue synthétique de :
 L’état des positions du centre d’appels (du CRRA d’où il opère) ;
 L’état des salles d’attentes propres au CRRA.
CTI-SPRV-1


remonter ?
remonter ?
68 / 113
Salles d’attente et gestion d’appel
Id
CTI-CAPA-1
CTI-CAPA-2
CTI-CAPA-3
Quelles sont les possibilités d’interaction offertes à l’agent (via l’IHM) sur les appels
des salles d’attentes ?
 Sélection et prise de l’appel ;
 Modification de priorité ;
 Déplacement vers une autre salle d’attente ;
 Autre possibilité (à préciser).
Préciser votre capacité et les prérequis à l’implémentation d’une fonction de gestion
d’une « blacklist » et « graylist » pour les appelants malveillants/fax/etc. (dépriorisation, renvoi permanent ou temporaire vers SVI) ?
Préciser votre capacité à implémenter une fonction de gestion d’une « whitelist »
pour les appelants « VIP » (priorisation) ?
Id
IPv6
CTI-INTX-1
4.3 Informations sur les composants connexes au
système
4.3.1 Enregistrement des conversations téléphoniques
4.3.1.1 Besoins
Cette partie décrit les besoins et les informations structurantes pour offrir un Service
d’enregistrement dans le cadre du projet de modernisation du SI-Samu.
Dans le cadre des appels au Samu, la communication et tous les échanges réalisés (et donc
l’enregistrement sonore associé), sont considérés comme des éléments du dossier médical.
Cela implique :



Une traçabilité de l’appel ;
La possibilité de réécouter l’appel immédiatement ;
L’archivage et la conservation afin de réécouter et réutiliser l’appel à n’importe quel
moment.
Chaque établissement de santé est tenu de constituer un dossier médical pour chaque
patient hospitalisé, comme indiqué dans l’article R1112-2 du Code de la Santé Publique.
Le service d’enregistrement intervient dès que l’appel est pris en charge par l’opérateur de
service.
L’intégralité de la communication doit être enregistrée, ce qui inclut naturellement tout le
cycle de vie de l’appel :




Le passage dans le SVI ;
La mise en garde de l’appel ;
L’appel de consultation vers un tiers ;
La conférence.
Par extension, et au-delà des échanges téléphoniques, il est essentiel de pouvoir enregistrer
toutes les communications échangées quels que soient les supports et/ou médias utilisés.
Aussi le service d’enregistrement doit pouvoir prendre en compte toutes les communications
suivantes :

La téléphonie entrante (incluant le SVI) ;
69 / 113





La téléphonie sortante ;
La radio voix entrante ;
La radio voix sortante ;
Les communications internes ;
Les autres canaux (vidéo par exemple).
L’enregistrement des échanges téléphoniques et radio sont des documents à joindre au
dossier médical, à des fins de traitement opérationnels mais également si besoin à des fins
juridiques. À ce titre, ils sont régis par les règles de conservation et de destruction identiques
à celles d’une archive publique.
Les hypothèses à ce jour sont un délai de conservation sur les enregistreurs avant le
stockage dans les archives légales de 30 jours, le délai de conservation en archivage étant
de 10 ans.
Il est nécessaire que l’enregistrement réponde aux exigences suivantes :




L’enregistrement doit continuer de fonctionner dans tous les modes dégradés dont
celui de l’ultime secours (perte du site central) ;
L’intégralité de la communication doit être enregistrée ;
L’enregistrement doit être ré-écoutable immédiatement ;
L’enregistrement doit pouvoir être indexé dans le LRM afin de pouvoir remonter
l’ensemble des enregistrements lié à un dossier médical.
À noter que les infrastructures « Radio » sont déployées en local sur chaque Samu et que la
fonctionnalité d’enregistrement des communications radio est déjà implémentée dans tous
les Samu bénéficiant d’un Gestionnaire de Voie Radio (une présentation des services radio
est fournie en annexe 5.5 du présent document).
Par ailleurs, du fait qu’il est légalement interdit d’enregistrer des appels personnels, seuls les
appels passés dans le cadre des missions du SI-Samu seront enregistrés.
De par les exigences et les contraintes juridiques, il est à priori nécessaire de mettre en
place des équipements centraux d’enregistrement, répartis sur les datacenters de l’opérateur
de service mais aussi des équipements locaux d’enregistrement, répartis sur les sites locaux
des CRRA.
En mode nominal, le service est assuré aussi bien par les enregistreurs en local avec
remontée des informations en central.
En mode dégradé, il est nécessaire que les enregistrements soient toujours disponibles
pour être écoutés en local.
La solution doit être hautement disponible et la bascule primaire/backup de la solution ne
doit pas perturber les enregistrements en cours. Il ne doit pas y avoir de perte
d’enregistrement des communications ni d’impact sur les statistiques associées.
Plusieurs cas de mode dégradé sont possibles :





L’un des deux datacenters hébergeant la solution d’enregistrement est en
dysfonctionnement total ou partiel ;
Les deux datacenters hébergeant la solution d’enregistrement sont en
dysfonctionnement total ou partiel ;
La solution d’enregistrement en local est en dysfonctionnement total ou partiel ;
Le CRRA n’est plus accessible (partie voix) en TDM mais en IP via le réseau MPLS ;
Le réseau IP-MPLS entre l’opérateur de service et le CRRA local est en panne.
L’un des deux datacenters hébergeant la solution d’enregistrement est en
dysfonctionnement
70 / 113
Dans ce cas, la solution étant hautement disponible, une bascule doit se faire
automatiquement sans impact sur l’activité en cours.
Les deux datacenters
dysfonctionnement
hébergeant
la
solution
d’enregistrement
sont
en
Dans ce cas, c’est la solution d’enregistrement en local qui assure seule le service.
La solution d’enregistrement en local est en dysfonctionnement total ou partiel
Dans ce cas, c’est la solution d’enregistrement en central qui assure seule le service.
Le CRRA n’est plus accessible en TDM mais en IP via le réseau MPLS
Dans ce cas, la solution de d’enregistrement doit pouvoir continuer à fonctionner
normalement.
Le réseau IP-MPLS entre l’opérateur de service et le CRRA local est en panne
Dans ce cas, c’est la solution d’enregistrement en local qui assure seule le service.
La fourniture du service d’enregistrement est encadrée par des exigences opérationnelles
fortes :


Une haute disponibilité du service en 24/7 ;
La capacité à enregistrer la communication de bout en bout, en particulier avec
tous les segments d’appels que l’on peut rencontrer lors de transfert d’appel et/ou de
mise en conférence ;
Une souplesse dans la réécoute des enregistrements qui doit pouvoir se faire
immédiatement par les agents du CRRA ;
Une capacité industrielle de la solution du service d’enregistrement pour faciliter
son déploiement et maitriser l’évolutivité et la pérennité de la solution.




L'orientation actuelle est de préférer un enregistrement dual/central (double enregistrement)
à un risque de perte d’enregistrement.
Pour plus d’information sur l’intégration des réseaux radio, se référer à l’annexe 5.5.
Catalogue de services
Id
RCR-CTLS-1
structurants/différenciants de votre service d’enregistrement, notamment :
 Gestion de la réécoute ;
 Gestion de l’enregistrement en local et en central ;
 Intégration éventuelle avec gestion des autres médias (radio, desktop,
vidéo,..) ;
 Stockage/archivage.
Présentation de l’enregistreur
Id
RCR-PRES-1
Pouvez-vous mettre en évidence les points forts de votre solution notamment sur les
points suivants :
 Architecture de la solution : composants, résilience ;
 Éditeur de la solution (si solution tierce), technologies utilisées, langages,
protocoles et standards supportés ;
 Dimensionnement : nombre maximum d’appels simultanés
71 / 113

Id
RCR-CAPA-1
(enregistrement concurrent) ;
Gestion de l’enregistrement des appels en « parcage » (attente de mise
en relation) et mise en attente (conservation de l’appel dans la salle de
l’agent).
Quelles sont les limites de la solution en termes de positions, d’interactions
simultanées, de volume de stockage, de capacité de réécoute, etc... ?
RCR-CAPA-2
Pouvez-vous préciser votre capacité à provisionner X canaux supplémentaires et le
délai associé (entrante et sortant) pour les rendre opérationnels :
(Voir la taille des pics d’appels, 5 K appels simultanés en nominal, 15K en pic)



Id
RCR-ADMN-1
100 canaux voix ou autres média (ex radio) ;
500 canaux voix ou autres média (ex radio) ;
1000 canaux voix ou autres média (ex radio).
Administration de la solution
Pouvez-vous préciser si des outils d'administration fonctionnelle sont disponibles ainsi
que la liste exhaustive des fonctionnalités couvertes.
Quels outils d'imports ou de provisioning mettez-vous à disposition (exemple : ajout
d'un nouveau CRRA) ?
L’IHM d’administration est-elle intégrable dans un portail web ?
Pouvez-vous préciser l’outil correspondant ?
RCR-ADMN-2
Pouvez-vous préciser s’il s’agit d’un client lourd ou léger ?
Fournissez-vous des API permettant une intégration informatique des interfaces
d’administration ? Précisez.
Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles ?
RCR-ADMN-3
Est-il possible de coupler les IHM de la solution à un annuaire LDAP afin de gérer les
droits d'accès ? Pouvez-vous préciser les contraintes et les incompatibilités
éventuelles ?
Id
RCR-FNCT-1
RCR-FNCT-2
RCR-FNCT-3
RCR-FNCT-4
Enregistrement
Pouvez-vous préciser la capacité de la solution à enregistrer l’intégralité de l’appel
incluant notamment le passage dans le SVI, les phases d’attente ?
Pouvez-vous préciser la capacité de la solution à prendre en compte des
métadonnées (par exemple le numéro de DRM) et à les restituer (« enrichissement de
l’appel ») ?
Pouvez-vous préciser les limitations éventuelles de la solution (par exemple, le
nombre de données métier) ?
Pouvez-vous préciser la capacité de filtrage des enregistrements, archivés ou non, et
lister les filtres potentiels tels que, par exemple, les données métiers, la date ?
Pouvez-vous préciser la capacité de réconciliation des enregistrements locaux et
centraux :
 Pour un même appel sur un seul CRRA ?
 Pour un même appel sur plusieurs CRRA ?
72 / 113
RCR-FNCT-5
RCR-FNCT-6
RCR-FNCT-7
RCR-FNCT-8
RCR-FNCT-9
RCR-FNCT10
RCR-FNCT11
 Pour des appels liés à un même DRM ?
Pouvez-vous préciser si la solution a la capacité, en standard, d’enregistrement :
 De la radio ;
 Des échanges de type communication par écrit en temps réel ;
 De la session du poste de travail ;
 De la visio ;
 Autres (à préciser le cas échéant).
Pouvez préciser les mécanismes éventuels et les typologies d’intégration sur les
médias qui ne seraient pas couverts en standard ?
Pouvez-vous préciser la capacité de la solution à gérer différents types
d’enregistrements :
 T2 ;
 Poste physique ;
 Agent.
Précisez l’organe auquel l’enregistreur doit être couplé.
Pouvez-vous préciser la capacité de la solution à permettre la réécoute immédiate
d’une communication non terminée ? L’intégralité de la communication doit pouvoir
être réécoutée.
Y a-t-il une limitation en termes de nombre d’enregistrements ré-écoutables
immédiatement ?
Pouvez-vous préciser si la solution permet de télécharger un enregistrement ou une
conversation sur le poste de l’agent ? (par conversation s’entend l’ensemble des
enregistrements liés à un appel et/ou à un DRM)
Quels sont :
 Les formats de compression possibles ?
 Les taux d'échantillonnage / taux de compression ?
Pouvez-vous préciser si la solution permet d’anonymiser la voix afin de la rendre
méconnaissable, tout en restant compréhensible, et ceci à des fins d’enseignement ?
Pouvez-vous préciser si la solution permet de retranscrire la voix en fichier texte :
 En temps réel ?
 A postériori ?
Préciser si cette fonctionnalité est disponible en standard ou à l’aide d’une
interconnexion avec un produit tiers.
Pouvez-vous préciser si la solution permet la traduction instantanée des
enregistrements d’appels en langue étrangère ?
Le cas échéant, pouvez-vous préciser les langues gérées ?
Id
RCR-STAR-1
Stockage Archivage
Pouvez-vous préciser l’espace de stockage nécessaire pour prendre en compte les
volumétries du SI-Samu ?
Merci de présenter les hypothèses retenues pour le calcul.
Pouvez-vous préciser l’espace d’archivage, en précisant les hypothèses retenues pour
le calcul ?
RCR-STAR-2
RCR-STAR-3
RCR-STAR-4
Pouvez-vous préciser si les enregistrements sont compressés et l’impact sur la qualité
audio du message archivé ?
Pouvez-vous préciser si un outil d’extraction des fichiers audio et des données
relatives à une communication est fourni en standard ?
Pouvez-vous présenter l’outil et les objets en sortie ?
Pouvez-vous présenter le système de purge ?
73 / 113
RCR-STAR-5
Disposez-vous d’interfaces de sauvegarde vers des systèmes tiers (NAS, autres) ?
Précisez.
Id
RCR-INTE-1
RCR-INTE-2
RCR-INTE-3
Intégration
Pouvez-vous préciser la compatibilité de la solution d’enregistrement avec :
 Les IPBX du marché ?
 Le protocole SIP ?
Pouvez-vous préciser les limites et contraintes éventuelles ?
Précisez les modalités d’enregistrement en fonction des liaisons.
Pouvez-vous préciser les éventuelles licences tierces nécessaires au bon
fonctionnement de la solution d’enregistrement ?
Pouvez-vous préciser les capacités d’intégration des fonctionnalités de pilotage et de
réécoute des enregistrements ?
Une API pour les fonctions de réécoute/recherche/consultation est-elle disponible ?
Pouvez-vous préciser l’environnement et les contraintes de développement ?
Id
RCR-STAT-1
La solution propose-t-elle une IHM de pilotage permettant, quel que soit le média
(même la radio) :
 D’afficher des rapports statistiques temps réel ? En client lourd ou léger ?
Existe-il une application Smartphone ?
 D’afficher des rapports standards ?
 Des données statistiques unitaires ? Agrégées ? (préciser l’agrégat le cas
échéant)
Id
RCR-TECH-1
Pouvez-vous nous fournir la matrice de compatibilité des IHM avec :
 Les systèmes d’exploitation ?
 Les navigateurs ?
RCR-TECH-2
RCR-TECH-3
raison.
RCR-TECH-4
RCR-TECH-5
Pouvez-vous préciser si la solution d’enregistrement est compatible avec le fait qu’en
mode nominal l’acheminement est effectué par le réseau TDM et en mode dégradé
par le réseau IP MPLS ?
Pouvez-vous préciser les impacts éventuels ?
Id
Indicateurs / SLA
Pouvez-vous préciser le taux de disponibilité maximale de la solution ?
RCR-SVLA-1
RCR-SVLA-2
Merci de préciser l’élément ou les éléments les plus sensibles de la solution.
Quels sont les différents SLA sur lesquels vous pouvez-vous engager ?
74 / 113
Id
Supervision
RCR-SPRV-1
être remontées à un système d'hypervision des Samu et celles que vous préconisez
particulièrement ?
Quels sont les intégrations possibles, l’objectif pour le SI-Samu étant d’avoir une vue
unifiée de son système ?
RCR-SPRV-2


Id
remonter ?
remonter ?
Modes dégradés
RCR-RESL-1
RCR-RESL-2
En cas de mode dégradé, pouvez-vous préciser les conséquences sur les
enregistrements des communications ?
En cas de pandémie, le besoin peut être de fonctionner avec des agents dispersés
(ex : télétravail) utilisant des téléphones banalisés (non reliés à la solution de
téléphonie du SI-Samu).
Pouvez-vous préciser vos offres pour faire face à de telles situations ? Quel est le
délai de déploiement de ces offres ?
Id
IPv6
RCR-INTX-1
4.3.2 Affichage et diffuseurs des informations
Les agents du SI-Samu disposent de plusieurs écrans de travail, et de manière générale à
minima de 3 écrans :




Un écran destiné au LRM. Le multifenêtrage éventuel (fenêtre de recherche) se fait
sur le même écran de travail ;
Un écran destiné au « bandeau » : le bandeau comprend la vision des salles
d’attentes, de l’état des autres personnels, et plus généralement tout information utile
liée à l’interaction téléphonique (et en cible, multicanal) ;
Un écran destiné à la vision géographique des DRM, de l'offre de soins, des moyens
engagés pour un DRM ou à réaliser des actions géodécisionnelles ;
Dans le cas d’écrans supplémentaires (certains postes de travail possèdent 4 à 6
écrans), l’ensemble des éléments supports nécessaires (ROR, recherche
d’information, intranet, etc.). Si cet écran n’existe pas il est partagé avec la partie
SIG.
Dans le cadre du projet SI-Samu, et du fait de la particularité du métier des ARM, il est
envisagé d’utiliser l’écran bandeau à des fins de diffusions d’information (de niveau CRRA
ou national, non personnelle) :

Certaines informations de supervision sont déjà présentes dans le cadre du bandeau
tel qu’il est envisagé (état des salles, nombre d’appels en attente dans le CRA, état
des agents des groupes d’appartenance et des personnels en escalade dans le
processus) ;
75 / 113


De manière complémentaire est envisagée la diffusion des messages
complémentaires :
o Message informationnel (absence, évènement particulier, MOTD – message
of the day, etc…) de type local ;
o Message urgent de type local (métier ou technique) ;
o Message urgent de type national (crise sanitaire, ou évènementiel) ;
État synthétique de situation : il s’agit de l’affichage sur l’écran de la situation de
supervision chiffrée, qui sera défini par CRRA ou au niveau national (taux de
décroché, TMC, ou autre). Il s’agit d’informations opérationnelles (prise de décision)
source de motivation au niveau des agents.
L’ASIP Santé envisage également le déport d’écran et l’adaptation de ces informations au
support de visualisation :



Il n’est pas envisagé de déport d’information sur des supports de type centre d’appels
classiques (bandeaux lumineux) ;
Il est envisagé un déport d’informations sur des supports fixes classiques (télévision),
éventuellement couplées à d’autres fonctions d’informations (mashup) ;
Il est envisagé le déport de ces informations sur des supports mobiles (tablette,
smartphone).
Le répondant est invité à décrire de manière sommaire :


Sa capacité à fournir une solution répondant à ces besoins, ou sa capacité à
s’interfacer avec des solutions tierces ;
Un ou des exemples de réalisations effectuées dans ce domaine (en propre ou par
une société tierce de type intégrateur).
4.3.3 Gestion multicanal
4.3.3.1 Besoins
Service multicanal
Pour tenir compte des usages actuels et futurs (mobilité, téléassistance, télémédecine),
l’ASIP Santé souhaite intégrer au SI-Samu des outils de communication prenant en compte
les différentes évolutions technologiques prévisibles dans la prochaine décennie.
Le « Service multicanal » permet la mise en œuvre de fonctionnalités liées à la réception et
à l’émission de flux d’interactions multicanaux et complète ainsi le service téléphonique a
minima par les flux suivants :








Les fax ;
L’email ;
La visiophonie ;
Les demandes de rappels ;
Le chat interne ;
SMS ;
La radio ;
Une ou plusieurs applications smartphone à usage grand public et professionnel.
La multicanalité repose sur le socle « CTI » afin d’ offrir un routage / distribution homogène
étendu à ces nouveaux canaux.
Le couplage CTI, destiné en premier lieu au traitement des appels téléphoniques, sera
complété du couplage radio informatique, puis devra progressivement intégrer d’autres
médias d’interaction permettant ainsi des nouveaux usages, comme par exemple la téléconsultation ou la télé-expertise et une meilleure efficacité de la coordination et la
mobilisation des moyens d’intervention.
76 / 113
D’une manière générale, le traitement des flux multicanaux conserve la logique de
distribution d’un appel téléphonique. Les principaux usages et fonctionnements de multicanal
envisagés sont illustrés et détaillés ci-après.








L’appel radio : les Samu utilisent la radio pour échanger avec certains de leurs
partenaires et ce simultanément à un appel téléphonique (avec le patient et les
pompiers sur les lieux). Le programme Antares s’inscrit dans le cadre de ces
échanges et permet aux SDIS et aux Samu de communiquer via un réseau radio
numérique propriétaire crypté. À ce titre, les agents des CRRA sont équipés de
postes radio en plus de l’équipement téléphonique. Lors de la prise en charge
volontaire d’une communication radio, le statut de l’agent passe automatiquement en
indisponibilité afin de ne plus recevoir d’autre sollicitation (téléphonique par exemple).
Cette gestion du statut nécessite, en plus du couplage CTI, un couplage radio
informatique rendu possible par l’intermédiaire de Gestionnaire de Voie Radio. Ce
couplage peut être réalisé au niveau des IPBX ou de l’informatique ;
Le Fax : le canal fax est principalement utilisé pour l’échange de documents avec les
professionnels de santé et avec les unités opérationnelles du Smur pour l’émission
des feuilles de route. Compte-tenu de la criticité de l’émission de la feuille de route,
une stratégie multicanale devra être envisagée. Des règles pourront être spécifiées
en cas d’alerte d’un dysfonctionnement d’un des canaux, ou encore d’émission
d’information sur plusieurs canaux en parallèle avec des mécanismes d’acquittement
après plusieurs envois en parallèle, par exemple. L’ASIP Santé souhaite également
que le flux "Fax" intègre une stratégie de messagerie unifiée et soit donc traité dans
le même workflow que les emails ;
l’email : le canal email est principalement utilisé pour l’échange d’information avec
les professionnels de santé, comme par exemple pour la transmission d’un ECG par
le cardiologue d’un patient. Ils ont possiblement vocation à venir enrichir ou être
rattachés à un DRM et/ou un patient. Le routage / distribution doit pouvoir se faire
suivant des critères issus du destinataire, de l’objet du mail ou de l’analyse
sémantique du contenu ;
Les demandes de rappels : dans certaines situations, le patient peut solliciter un
rappel par le Samu, les rappels sont automatiquement proposés (mode prédictif ou
« preview » selon le paramétrage) aux agents du CRRA. L’agent reçoit le rappel avec
la visualisation de l’ensemble des informations de contexte : type de rappel, cause du
rappel, heure du dernier appel du patient. Les rappels peuvent être également initiés
via le SVI (surcharge, demande d’information non urgente), par une application
smartphone Samu ou automatiquement programmés dans le cadre des campagnes
de suivi des régulations médicales (lorsqu’une intervention a été déclenchée). Les
logiques de demandes de rappel sont différentes suivant les organisations internes
des différents Samu ;
Le chat interne : le chat interne permet les échanges entre agents au sein du centre
d'appels ou entre agents de CRRA différents. Ce canal vise à faciliter l’entraide
même si une communication est déjà en cours (par exemple lorsqu’un ARM sollicite
l’expertise d’un MR pour traiter son appel en cours) ;
SMS : une solution de gestion des SMS peut être mise en place aussi bien sur des
flux entrants que sortants pour permettre par exemple les échanges avec les
effecteurs, voire les patients ;
MMS : la gestion des MMS en entrant peut permettre à l’appelant d’envoyer une
image du patient, ou de l’environnement, afin de faciliter le diagnostic, voire la
localisation ;
Module d’alerte : le SI-Samu intègre un annuaire de ses usagers (et en particulier
des urgentistes) permettant une alerte ou une mobilisation rapide de ces personnels
(engagement des équipes en situation normale, rappel de personnel en cas de plan
77 / 113

ORSEC « nombreuses victimes » par exemple). Cet outil est multicanal et interfacé
avec le SI-Samu ;
Application smartphone : une application de type « smartphone » est envisagée
afin d’être mise à disposition des patients et des professionnels de santé. Cette
application s’apparente à un moyen de communication multicanal avec le Samu.
L’usage « patient » permettra de solliciter le Samu en signifiant le degré de l’urgence
(permettant de prioriser l’appel ou au contraire de l’inscrire dans une filière de
rappel), de transmettre sa géolocalisation exacte et des éléments non vocaux
(Identifiant National de Santé, documents, flux vidéo ou audio, etc.). L’usage
« professionnels de santé » a pour objet de faciliter les échanges entre
professionnels de santé et médecins régulateurs, d’accélérer l’accès à la régulation
médicale, de déclarer des informations administratives.
Par ailleurs, le SI-Samu souhaite mettre en place un système d’escalade :


A minima multicanal, pour pouvoir adresser un message d’alerte sur plusieurs
canaux à la fois en fonction des acteurs engagés et des besoins propres, et de piloter
le renvoi d’une information critique si son premier envoi a échoué ou n’a pas été
acquitté sur un canal donné ;
Voire cross canal, pour envisager le traitement du message sur plusieurs canaux et
gérer les situations de mobilité (par exemple : je reçois l’alerte par SMS et j’acquitte
ou j’informe sur les actions à donner sur une application smartphone).
Fonctionnalités attendues du service de multicanal













Le routage intelligent des flux multicanaux au même titre que les appels
téléphoniques. Si le demandeur est un patient et qu’il figure dans le référentiel
patient, l’interaction est routée vers le CRRA rattaché à son lieu de résidence, quel
que soit le média utilisé ;
La visualisation graphique des interactions entrantes dans les salles d’attentes. Les
salles d’attentes sont multicanales et contiennent indifféremment tous types
d’interactions classées selon leur priorité, avec un indicateur sur le media concerné ;
L’affichage des informations sur l’interaction lors de la soumission à l’agent ;
Le pilotage graphique des interactions entrantes: sélection pour traitement d’un
email/fax/visio, le transfert direct (appelé aussi transfert aveugle) /accompagné (appel
du destinataire au préalable) / transfert supervisé (conférence à trois pour transfert de
contexte), le changement d’état, la mise en attente, la mise en conférence, etc.
La priorisation du flux suivant le degré d’urgence lorsque l’analyse est possible ;
La distribution des flux multicanaux selon la compétence, la disponibilité de l’agent,
et les organisations en place ;
La gestion des flux radiophoniques ;
L’historisation des interactions multicanales ;
La détection de la langue et la traduction simultanée en langue étrangère ;
L’émission d’appels sortants en mode prévisualisation ou prédictif ;
Les échanges entre agents au sein du CRRA ou entre CRRA ;
La capacité de communication avec des applications clientes : LRM pour la
création du DRM et SIG lorsque les informations de géolocalisation sont disponibles ;
L’enregistrement et la réécoute : enregistrement des appels sortants, des appels
radio et la réécoute de ces enregistrements.
Pour répondre aux besoins, l’interface graphique de l’application multicanale devra être
adaptable selon le profil utilisateur (ARM, MR, autres personnels de santé) et son CRRA
d’appartenance.
Principes structurants
Pour délivrer le service multicanal, les principes suivants sont considérés comme
structurants dans la solution pressentie :
78 / 113

En termes d’IHM, le service multicanal en reprend les principes déjà énoncés (client
léger, stand alone, couplage lâche, scalabilité, disponibilité) ;
Le media blending : l’agent doit être en capacité de traiter simultanément plusieurs
interactions dont un appel téléphonique et une communication radio, un ou plusieurs
emails ;
Dans le cas des communications sortantes critiques, le système doit permettre la
mise œuvre de scénarii d’escalade sur un autre média, voire plusieurs, en cas
d’échec de la transmission initiale (ex : impression feuille de route).


Pour plus d’information sur l’intégration des réseaux radio, se référer à l’annexe 5.5.
Catalogue de services
Id
MCN-CTLS-1
structurants/différenciants de vos services contribuant au multicanal notamment :
 Type de média pris en charge et intégrés dans une même solution ;
 Affichage des informations de l’interaction ;
 Identification et authentification ;
 Media blending, multi-interaction ;
 Statistiques personnelles ;
 Supervision de l’activité du centre d’appels ;
 Fonctionnalité de messagerie instantanée.
Présentation du service de traitement multicanal
Id
MCN-PRES-1
MCN-PRES-2
Pouvez-vous présenter les caractéristiques et fonctionnalités du traitement d’email :
 Méthode de classification ;
 L’éditeur (si outil ou moteur tiers intégré dans la solution, précisez).
La solution permet-elle nativement une personnalisation avancée de l’interface à
plusieurs échelons : globale, CRRA et agent ?
Fonctionnalité
Id
Dans le cadre de son activité, un ARM a des tâches à réaliser après le traitement de
la communication. Par exemple, il doit rappeler un ES sous 4h pour valider le bon
accueil du patient.
MCN-FNCT-1
Pouvez-vous préciser si la solution a la capacité de générer des tâches de type
back office ou demande de rappel planifiée x heures après la gestion d’une
interaction ? Le cas échéant, en présenter le fonctionnement.
La solution est-elle capable d’annuler la tâche si celle-ci a été effectuée avant la
date/heure prévue, y compris par un agent tiers ?
Pouvez-vous présenter la fonctionnalité de Media blending ?
MCN-FNCT-2
À quel niveau est effectué le paramétrage/configuration : au niveau de l’agent, d’un
groupe d’agents, à un autre niveau ? Pouvez-vous préciser ?
Peut-on appliquer un calendrier (par exemple, un agent traite de l’email et de la voix
le matin, et l’après-midi il ne traite que de la voix) ?
MCN-FNCT-3
Pouvez-vous préciser comment est réalisée l’adjonction et l’activation de nouveaux
média (API, méthode d’intégration) ?
79 / 113
Intégration avec la radio (ANTARES)
Id
Avez-vous déjà réalisé une intégration avec de la radiophonie ?
MCN-INTE-1
Le cas échéant pouvez-vous préciser les architectures utilisées (connecteur,
composant spécifique, protocole/langage) et les fonctionnalités offertes :
fonctionnalités à partir du poste radio, fonctionnalités depuis le bandeau …
Pouvez-vous fournir la liste des constructeurs et éditeurs radio avec lesquels le
service de Couplage Téléphonie Informatique est compatible et/ou certifié ?
Pouvez-vous préciser les prérequis en termes de licence ?
Intégration avec des applications tierces
Id
MCN-INTE-2
MCN-INTE-3
MCN-INTE-4
Pouvez-vous préciser les modalités d’interfaçage avec le SIG (en client léger) pour
l’affichage de la localisation de l’appelant ?
Pouvez-vous préciser les modalités d’interfaçage avec l’enregistreur pour piloter
l’enregistrement ?
 Connecteur ;
 Prérequis technique ;
 Prérequis en termes de licences.
Pouvez-vous préciser les bénéfices et limitations d’une intégration client side et
d’une intégration server side ?
Supervision
Id
MCN-SPRV-1
Pouvez-vous préciser votre capacité à proposer une solution permettant à un
hyperviseur (au niveau CRRA ou national) de visualiser les usages de canaux ?
être remontées à un système d'hypervision du Samu ?
MCN-SPRV-2
Quels sont les intégrations possibles, sachant que l’objectif pour le SI-Samu est
d’avoir une vue unifiée ?
MCN-SPRV-3


Id
MCN-STAT-1
remonter ?
remonter ?
Pouvez-vous préciser votre capacité à proposer à l’agent l’affichage :
 Des statistiques « multicanal » individuelles ?
 Des statistiques « multicanal » du centre d’appels (CRRA) ?
 Des statistiques individuelles par canal ?
 Des statistiques par canal du centre d’appels (CRRA) ? De son
historique personnel de la journée ?
80 / 113

De l’historique de dernières interactions traitées par le CRRA ?
Id
Salles d’attente et gestion des interactions
MCN-CAPA-1
Pouvez-vous préciser la capacité de la solution proposée à gérer une file d’attente
unique mariant des interactions « multicanal » et à permettre une gestion de picking
de l’interaction par un collaborateur donné dans cette même file d’attente ?
MCN-CAPA-2
Pouvez-vous préciser votre capacité et les prérequis à l’implémentation d’une
fonction de gestion d’une « blacklist » et « graylist » pour les interactions
malveillantes/fax/etc. (dé-priorisation) mais appliquée aux différents canaux ?
Id
MCN-TECH-1
MCN-TECH-2
MCN-TECH-3
raison ?
4.3.4 Autres fonctionnalités potentielles
Le temps estimé pour la mise en place et le déploiement du SI-Samu est de plusieurs
années. De fait l’ASIP Santé souhaite connaître les prochaines évolutions et usages
potentiels qui sont d’ores et déjà envisageables.
Par exemple, la révolution du smartphone, depuis 2007, a modifié les usages rendant
« normal » l’usage du téléphone en mode multimédia, apportant sur le même appareil
l’utilisation de la photo et de la vidéo, principalement en mode asynchrone (prise de photo et
envoi). L’arrivée de la 4G, et bientôt de la 5G (prévue en 2020) permettront des échanges
synchrones d’informations multimédia (débit et pénétration dans les bâtiments). La
réconciliation de l’image et de l’appel sera de fait un plus pour le SI-Samu (voir paragraphe
4.3.3 Gestion multicanal).
De la même manière, l’usage de la reconnaissance vocale pour banaliser la demande et la
qualification devient usitée et peut être d’utilité pour le SI-Samu, usage rendu grand public
notamment par le système Siri d’Apple.
À l’inverse, alors que la technologie est mature, l’usage des SVVI ou IVVR n’a pas
d’application potentielle pour le SI-Samu.
Le répondant est invité à donner une vision de l’évolution de ses produits :






Dans le domaine de l’accueil vocal ;
Dans les usages complémentaires liés à la téléphonie IP ;
Dans le domaine de la convergence voix-data ;
Dans les domaines du stockage de volume d’informations importants
(enregistrement) et de leur pérennisation ;
Dans le domaine de l’usage des informations volumineuses (Big Data) ;
Ou tout autre domaine permettant de contribuer à l’amélioration de la gestion des
appels d’urgence ou de la coordination des moyens d’urgence.
81 / 113
4.4 Informations liées à l’exploitation de la solution
4.4.1 Statistiques d’appels
Dans le cadre du SI-Samu, afin d’améliorer à la fois la qualité de prise en charge des appels
et permettre une organisation optimale, l’ASIP Santé a des attentes fortes relatives à
l’exploitation des statistiques.
Les statistiques auront plusieurs sources de provenances :




L’opérateur de service, afin d’avoir des statistiques fiables de décrochés/prédécrochés et d’aboutement ;
L’IPBX, afin de connaitre l’état des téléphones, les durées d’appels, et autres
données utiles à la compréhension des cheminements d’appels ;
L’ACD/CTI, qui sera dans un premier temps le référentiel d’analyse ;
Les autres organes (SVI, enregistreurs, etc.) permettant l’enrichissement de
l’analyse.
Trois points particuliers sont portés à l’attention des répondants :



L’unification des tickets (tickets uniques enrichis) du fait des sources hétérogènes,
besoin spécifique décrit ci-après (voir chapitre 4.5.2 Gestion des tickets
d’appels/communication et interaction) ;
L’enrichissement des tickets par les données métiers du LRM. Ce point n’est pas
traité dans le cadre de cette demande d’information, faisant appel à une chaîne
externe à la chaîne de traitement téléphonique ;
La conservation des tickets et indicateurs dans la durée, afin de pouvoir analyser de
manière rétroactive les évolutions et améliorations constatées depuis la mise en
place du SI-Samu.
De fait, les outils de reporting (à froid), permettant l’analyse, seront ceux délivrés directement
par les fournisseurs de solutions logicielles et d’équipements. Trois éléments sont importants
pour l’ASIP Santé :



La capacité à restituer de manière simple les informations/indicateurs issus des
appels, sans soucis d’intégration d’autres outils d’analyse ;
La richesse des informations fournies en standard par les outils d’analyse ;
La corrélation des données entre les différents éléments de la chaîne de traitement
des appels (voir également 4.5.2 Gestion des tickets d’appels/communication et
interaction).



Les interfaces graphiques et logiciels fournis en standard à des fins d’observation,
d’analyse, et de compréhension ;
La capacité de la solution fournie à s’intégrer en standard avec d’autres solutions du
marché (utilisation de modèles de représentation préexistants) ;
La capacité d’export des données et les formats associés, à des fins d’analyse par
des produits tiers.
Par ailleurs le répondant est invité à fournir toute précision qu’il juge utile quant à l’analyse
des statistiques d’appels dans le contexte du SI-Samu.
4.4.2 Supervision des appels
À des fins de bonne compréhension des attentes du SI-Samu, le terme supervision étant très
large, il sera distingué deux types de supervisions :

La supervision technique, qui correspond à une vue de l’état du système global en
terme de fonctionnement nominal (fonctionnement des processus, état des systèmes
82 / 113

supportant les processus, état des équipements). Ce point ne fait pas partie
expressément de cette demande d’information ;
La supervision ou les mécanismes de supervision métier, détaillés ci-après.
Dans le cadre du SI-Samu sont attendus quatre niveaux de vues :




Au niveau de l’agent. L’agent a une vue globale de l’état des salles d’attentes du
CRRA auquel il appartient, et de l’état des agents du CRRA. Il dispose de fonctions
traditionnellement utilisées par le superviseur :
o Picking d’appel : prise d’un appel dans l’une des salles d’attentes à laquelle il
est abonné (chaque agent dispose également de sa propre salle d’attente) ;
o Dépôt d’un appel dans une salle d’attente ;
o Déplacement d’appels entre salles d’attente ;
Au niveau du CRRA. L’attente à ce niveau correspond aux fonctions classiques de
supervision (vue de l’état des salles, vue d’indicateurs avec visuel et alertes, capacité
à déplacer des appels, interception d’appels, écoute avec « chuchotement », etc.). Il
est à noter que le rôle de superviseur d’un CRRA peut être mutualisé entre plusieurs
CRRA à certains instants de la « journée » (en particulier pour la gestion des horaires
de nuit, gestion des absences ou du fait de la simple taille du CRRA concerné) ;
Au niveau régional. Pour certains numéros d’appels, non 15, mais gérés par les
Samu, il pourra être intéressant de disposer d’une supervision spécifique liée aux
salles d’attentes de ces numéros. Dans ce cas il s’agira de vues d’états statiques
(agrégat sur fréquence définie) et dynamiques (temps réels tels que risques de
saturation, alertes sur taux de raccroché), sans fonctions d’administration, celles-ci
étant de la responsabilité des CRRA. Ces indicateurs seront des indicateurs
classiques de centre d’appels (par exemple le TMC ou temps moyens de
communication, EWT ou Estimated Waiting Time, etc..) ;
Au niveau national (désigné par hypervision). L’ASIP Santé souhaite disposer d’une
vue générale de l’état du SI-Samu vu comme un centre d’appels virtuel. En plus des
fonctions précitées sont attendues des représentations graphiques (cartes de France,
avec drill-down potentiel, vue des entraides notamment).
Un modèle envisagé est l’activation de fonctions d’administration du système (au sens
métier) depuis la vue de l’hyperviseur, voire du superviseur : activation des scénarios
d’entraide, élargissement, activation d’arborescence SVI. Le couplage pourra être fort
(solution intégrée) ou faible (actuellement favorisé, activation de la fenêtre d’administration
avec passage de contexte).
Pour répondre à ces besoins, le répondant est invité à décrire de manière sommaire :



Sa capacité à répondre sur sa solution en standard aux besoins exprimés ci-avant ;
Sa capacité à répondre à l’aide de produits tiers, à l’aide d’une offre sur étagère,
aux besoins exprimés ci-avant, en précisant les parties couvertes et les logiciels
concernés ;
Sa capacité à fournir des interfaces permettant de remplir le besoin exprimé (le
cas échéant, donner une description générale des interfaces fournies).
Par ailleurs, le répondant est invité à fournir toute précision qu’il juge utile quant à la
supervision des appels dans le contexte du SI-Samu.
4.4.3 Gestion des indicateurs de service
L’ASIP Santé souhaite pouvoir bénéficier des indicateurs de services traditionnels dans les
centres d’appels virtuels (vue à plusieurs niveaux, par regroupement géographique,
organisationnel ou métier, par numéro appelé).
Ces indicateurs peuvent être :
83 / 113


Des indicateurs agrégés de composant de service (par exemple durée moyenne des
appels en attente). L’ASIP Santé attend de la solution qu’un certain nombre de ces
indicateurs, classiques et état de l’art dans le domaine des centres d’appels, soient
fournis en standard par l’équipement ou la solution, ou à minima par des solutions
tierces associées. Le SI-Samu devra bénéficier de ces indicateurs en fonction des
critères énoncés ci-avant ;
Des indicateurs « métier » (par exemple corrélation entre motif d’appels et durée de
traitement moyenne de l’appel). L’ASIP Santé envisage de mettre en place des
indicateurs complémentaires à ceux fournis en standard par la solution du fait de la
spécificité des besoins du SI-Samu. L’ASIP Santé envisage de mettre en place des
« points de comptage », à savoir des points de mesure associés à un contexte
(exemples : nombre de passage journalier dans une branche du SVI pour les story
board définis, nombre d’appels moyens en rappel associés à des motifs d’appels).
Pour répondre à ces besoins, le répondant est invité à décrire de manière sommaire :



La liste des indicateurs fournis en standard et pouvant correspondre aux besoins
exprimés ci-avant ;
Les interfaces et/ou méthodes permettant la mise en place des indicateurs
« métier », tel qu’envisagé précédemment ;
L’influence éventuelle de la mise en place de ces points de mesure sur les
performances de la solution logicielle ou de l’équipement.
Par ailleurs, le répondant est invité à fournir toute précision qu’il juge utile quant à la mise en
place de points de mesure dans le contexte du SI-Samu.
4.4.4 Contraintes d’exploitation
4.4.4.1 Gestion des environnements
La mise en place du SI-Samu est complexe du fait de deux facteurs principaux :


La haute disponibilité du système et la mise en place de mécanisme de résilience. Ce
point sera abordé dans le paragraphe suivant (voir chapitre4.4.4.2 Configuration type
de production) ;
La capacité d’évolution demandée à la solution, afin de prendre en compte à la fois
l’évolution des besoins, les spécificités de chaque Samu lors des déploiements, et
l’évolution des technologies.
Du fait de la deuxième contrainte, l’ASIP Santé souhaite mettre en place une structure
d’intégration continue, tant sur le plan organisationnel que sur le plan des plates-formes qui
supportent le processus d’intégration. Le terme de plate-forme désignera tout équipement
et/ou logiciel concourant à l’objectif visé ; dans ce cadre, l’ASIP Santé souhaite disposer :




D’une plate-forme de développement, permettant à la fois le développement et le
paramétrage des solutions logicielles (et/ou matérielles issues d’équipementiers) ;
D’une plate-forme de test, à vocation de réalisation des tests de qualification
(ensemble de tests unitaires sur un objet), de tests d’intégration (ensemble de tests
relatifs à plusieurs objets) et de tests de vérification (plan de tests d’intégration,
incluant la VNR ou Vérification de Non Régression) ;
D’une plate-forme de benchmark, permettant les tests de performance, incluant la
robustesse ; cette plate-forme pourra éventuellement être utilisée pour les tests de
migration logicielle majeure (progiciel, base de données, équipement, système), du
fait d’une utilisation non-permanente ;
D’une plate-forme de pré-production, à l’identique de la production, à des fins de
mise en production (« change management »), de reproduction d’incident (« incident
management ») et de mise en place de correctif (« patch management ») ;
84 / 113

La présente demande d’informations a pour objectif de connaître et de quantifier les
contraintes potentielles des équipements et solutions logicielles du point de vue du
répondant afin que ses équipements et logiciels soient mis en œuvre selon l’état de
l’art.



Ses préconisations, de par son expérience et les contraintes liées à ses solutions,
quant à la constitution de ces plates-formes / environnements et leur maintien en
condition ;
À des fins de coûts, notamment pour les plates-formes de tests (unitaires) et de
développement, sa capacité à virtualiser sa solution ou à simuler ces
environnements ;
Sa capacité à fournir des outils complémentaires facilitant la mise en place des
plates-formes (gestions de configurations et de restoring), leur utilisation (analyse de
logs ou traces), ou leur usage (injecteurs), en propre ou dans le cadre de partenariat
(dans ce cas préciser le nom des outils concernés).
Les questions relatives à la tarification associée à ces environnements sont traitées au
paragraphe 4.5.4 Tarification.
place des environnements préparatoires à la production dans le contexte du SI-Samu.
4.4.4.2 Configuration type de production
La stratégie de production du SI-Samu est la suivante :




L’accueil vocal sera acheté en mode service à base de serveurs vocaux VXML, afin
de garantir la réversibilité ;
Un IPBX (au sens logique et physique du terme) sera hébergé dans chacun des
datacenters de l’opérateur/hébergeur ;
Il est envisagé de dupliquer les gateways dans les centres Samu ;
L’ensemble des autres composants de la chaine primaire (ACD, CTI, enregistreur,
etc..) seront redondés au sein de chaque datacenter et dupliqués entre datacenters.
Le besoin de l’ASIP Santé est de qualifier de manière plus précise l’architecture et de
quantifier les besoins en hébergement et pour l’environnement de production des solutions
issues des fournisseurs de solutions ou d’équipements, avant l’émission des appels d’offres,
et de soumettre une expression de besoin, en corrélation avec les architectures de
production supportées par les solutions et équipements.
Le questionnement se pose notamment autour des problématiques suivantes :




Capacité de la solution à être virtualisée en production, tout en conservant
performance et disponibilité ;
Capacité de la solution à être mise en place sur un cloud privé d’hébergeur ;
Capacité à accepter des solutions de réplication de données (géoclustering,
contraintes pour les réplications, etc.) ;
Capacité à augmenter de manière rapide, de manière ponctuelle ou permanente, la
capacité (scalability).
De manière plus générale, le questionnement porte sur l’architecture de la solution,
notamment sur l’identification d’une part des éléments devant nécessairement être hébergés
sur une machine physique et d’autre part des éléments logiques.
Le fournisseur de solutions ou d’équipements est invité à répondre à ces problématiques :

En précisant, à chaque fois qu’une solution est possible, les contraintes associées,
tant sur le plan technique que sur les impacts générés ;
85 / 113


En étayant la réponse, à chaque fois que possible, par un exemple de référence
client ayant mis en place ce type d’architecture ;
En fournissant une description, sous forme de schéma, d’un exemple
d’architecture de production correspondant à la problématique exposée ci-dessus.
Les questions relatives à la tarification associée à cette configuration de production sont
traitées au paragraphe 4.5.4 Tarification.
place et au maintien des environnements de production dans le contexte du SI-Samu.
4.5 Informations transverses
4.5.1 Références similaires
Id
Références similaires
REFS-1
De combien de références similaires et actives disposez-vous ? Pouvez-vous en en
présenter quelques-unes couvrant selon l’étendue de vos produits le plus large spectre de
fonctionnalités décrites ci-dessous?
Précisez en cochant les cases ci-dessous les thématiques couvertes par les
références présentées:
Référence 1 :
Référence 2 :
Serveurs vocaux interactifs
Serveurs vocaux interactifs
Fonctions de Téléphonie
Fonctions de Téléphonie
Intégrations des fonctions IPBX dans un
domaine intégrateur
Intégrations des fonctions IPBX dans un
domaine intégrateur
Fonctions ACD locale ou centrale
Fonctions ACD locale ou centrale
Conférences ou communications multi-lignes
Conférences ou communications multi-lignes
Service de couplage Téléphonie-Informatique
Service de couplage Téléphonie-Informatique
Enregistrement des conversations
Enregistrement des conversations
Affichage et diffuseurs d’informations
Affichage et diffuseurs d’informations
Service de Workforce Management
Service de Workforce Management
Statistiques d’appels
Statistiques d’appels
Supervision des appels
Supervision des appels
Gestion des tickets d’appels/communication et
interaction
Gestion des tickets d’appels/communication et
interaction
Qualité de Service
Qualité de Service
Gestion du multicanal
Gestion du multicanal
4.5.2 Gestion des tickets d’appels/communication et interaction
4.5.2.1 Besoins
La solution recherchée est un système de téléphonie sur IP centralisé et à haute
disponibilité. Elle est couplée entre autres à :

Un système de gestion de centre d’appels assurant le routage intelligent, la
distribution des appels et le couplage CTI avec le SI-Samu ;
86 / 113

Des services d’enregistrement et de SVI.
Dans le cadre de ces communications, à des fins de statistiques, mais également à des fins
de marquage d’enregistrements (date, heure, durée), il est nécessaire d’unifier les tickets
issus d’équipements et solutions différents. Ce point est important car il permet d’avoir des
statistiques fiables remontées vers et par les centres d’appels, de mieux appréhender des
phénomènes conjoncturels (analyse à froid), et également d’injecter les statistiques
recueillies dans des modèles de simulation.
Le suivi du trafic téléphonique unifié et consolidé sert trois usages principaux :

Suivi d’un appel de « bout en bout »
o Suivi de la qualité de service fournie ;
o Suivi de l’activité dans les CRRA ;
 Réconciliation des tickets de toutes les interactions liées à un même dossier de
régulation médicale. Cette notion correspond à l’ensemble des appels associés à un
dossier de régulation médicale ;
 Référencement des enregistrements des appels à valeur probante pour les appels au
15.
Le service de ticket unifié doit couvrir et répondre aux besoins suivants :

La possibilité de reconstituer un appel de bout en bout avec un identifiant unique à
partir des tickets émis par les différentes briques de la solution :
o En mode nominal ;
o En mode dégradé ;
 L’enrichissement du ticket : la capacité à attacher un dossier de régulation médicale
l’ensemble des appels téléphoniques ainsi que les communications radio en y
associant des données liées à l’appel (qualification, rappel, entraide, …).
Le service de ticket doit être intégrable à la solution SI via la fourniture des connecteurs
permettant au SI-Samu d’exploiter les tickets du système de téléphonie.
À titre d’illustration, la réconciliation des informations envisagée par le service de ticket unifié
doit couvrir le scénario d’appel type suivant :









Appel TDM au 15 entrant sur le datacenter central ;
Traitement par le Call Manager ;
Prise en charge par la solution routage/distribution/CTI incluant la recherche d’un
DRM existant ;
Passage éventuel par le SVI (et des serveurs de reconnaissance vocale) ;
Après identification d’un agent, génération d’un appel sortant (en TDM ou via WAN)
vers l’agent situé dans un CRRA ;
Réception par la gateway locale de l’appel ;
Décroché de l’appel par l’agent avec création automatique du DRM si c’est un
nouveau patient ;
Transfert d’appel : l’appel peut ensuite faire l’objet de transfert local au CRRA ou non
(entraide sur compétence spécialisée) ;
Enregistrement des appels (en central et/ou en local).
Par ailleurs, un appel entrant produit en général des appels sortants ainsi que des
communications radio (Antares), des fax ou impressions, voire des emails. On souhaite
pouvoir corréler ces différents appels à un même DRM.
Les tickets liés à la mise en conférence des appels sont traités avec les conférences (voir
chapitre dédié 4.2.5 Conférence ou communications multi-lignes) :


Suivi d’un appel (identifiants de l’appel avant/pendant une conférence) ;
Réconciliation des appels appartenant à une même conférence.
87 / 113
Id
Ticket d’appel dans la solution de téléphonie
Génération de tickets d’appels
Préciser les composants de la solution qui génèrent des tickets et les principaux
champs générés :






TUN-STRD-1
Call managers ;
Gateway ;
ACD ;
SVI ;
Enregistreur local et/ou central ;
Application routage/distribution/CTI (par serveur au besoin).
Pour le scénario type, préciser les tickets générés au fur et à mesure de la progression
de l’appel, et les champs significatifs du ticket :
TUN-STRD-2
TUN-STRD-3
 Identifiant de l’appel ;
 Appelant ;
 Appelé ;
 Liaison ;
 Sens (sortant/entrant) ;
 Durée ;
 Agent ;
 Salle d‘attente ;
 Statut de terminaison inefficace, abandonné, etc. ;
 Autres (à préciser).
Préciser les sous-ensembles de composants qui partagent la même référence d’appel
dans la solution proposée ?
Préciser comment une référence commune peut être partagée entre les sousensembles de la solution utilisant chacun sa référence propre.
Préciser les mécanismes permettant de partager/transmettre une référence commune
d’appel pour disposer d’une vue de bout en bout d‘un appel ?



TUN-STRD-4
TUN-STRD-5
Par échange de signalisation ?
Via le lien CTI ?
Stockage dans un champ du ticket d’appel ?
Exemple de liens à illustrer dans la réponse :
 Entre la solution IPBX et l’application routage/distribution/CTI ;
 IPBX avec des éléments périphériques tels que les enregistreurs le SVI ;

Autres.
Préciser comment peut être modifiée (si besoin) la logique par défaut d’association
(règles, développements) ?
Aboutement d’appels entre le datacenter et le CRRA :
TUN-STRD-6
Préciser comment une consolidation entre l’appel entrant en central et l’appel abouté
est réalisée?


Cas d’un appel sortant TDM : appel TDM entrant enregistré sur la gateway
et appel entrant enregistré sur le datacenter ?
Cas d’un appel sortant via le WAN ?
88 / 113
Transferts d’appel :
TUN-STRD-7
Dans le cas de transfert d’appel, pouvez-vous préciser l’aptitude de la solution
proposée au :


TUN-STRD-8
Maintien d’un identifiant unique d’appel lors d’un transfert d‘appel ?
Maintien de l’appelant d’origine (A) dans le ticket (A appelle-> B transfert
vers C destinataire) ?
Cas de l’appel attaché/détaché dans une conférence
Y a-t-il un impact sur l’identification des appels liés à une conférence ?
Id
Intégration
Préciser l’architecture de stockage/exploitation des tickets.
TUN-INTE-1
Préciser le niveau de consolidation pouvant être obtenu dans le cadre de
l’architecture SI-Samu pressentie (ex : ticket agrégé représentant la communication
de bout en bout et masquant les multiples bases de tickets utilisées).
Relativement aux outils de statistiques :
TUN-INTE-2
TUN-INTE-3
TUN-INTE-4



Quels sont les outils de reporting standards mis à disposition ?
Quelles sont les statistiques disponibles ?
Y a-t-il des agrégats générés (relatifs au ticket d’appel et au besoin
décrit ci-avant) ?

Quels sont les outils de requêtage standards ?
Préciser les interfaces/outils d’export mis à disposition permettant d’explorer les
tickets dans un outil BI ?



Export de fichier ;
Formats de fichier : csv, etc. ;
Web service ;

Autre (à préciser).
Dans l’hypothèse où des développements sont nécessaires pour disposer d’un ticket
unique : ces développements peuvent-ils être conduits par des tiers (autre que le
fournisseur et/ou intégrateur certifié) ? Sur la base de quels prérequis ?
Id
Mode dégradé
Dans le cas d’une perte du réseau WAN (sites téléphoniques isolés), quel est l’impact
sur :
TUN-RESL-1
TUN-RESL-2
TUN-RESL-3


La production des informations de tickets décrite précédemment ?
La production et stockage local de tickets par les gateways ?

Y a-t-il une consolidation a posteriori après rétablissement du réseau ?
Dans le cas de la perte du datacenter actif et donc de la bascule sur le datacenter
passif, préciser les contraintes et prérequis permettant de conserver la notion de ticket
unifié.
Préciser comment le dispositif permet d'enregistrer et signaler explicitement une
rupture/un incident (de type perte d'information le cas échéant) dans l'enregistrement
des tickets.
89 / 113
Id
Traçabilité et Consolidation des interactions au niveau DRM
Le Dossier de Régulation Médicale correspond au traitement d’un patient par le Samu, pour un
évènement donné. Sa durée de vie type est de quelques heures.
À un DRM sont liés n appels successifs ou parallèles, entrants ou sortants et des communications
radio voire des emails. Les appels sont couplés (ou pas) à un DRM via l’application CTI.
Enregistrement des communications radio
TUN-STRD-1
Contexte : un agent régulateur « prend » une communication radio ce qui modifie
son état d’occupation dans le système CTI (non disponible).
Préciser comment il est possible d’intégrer, dans les métadonnées de
l’enregistrement, la référence du DRM concerné par la communication radio prise en
charge par l’agent ?
TUN-STRD-2
Pouvez-vous préciser la capacité de la solution à retrouver/exporter des
communications (log, enregistrement) à partir de la référence (DRM) ?
4.5.3 Qualité de service
4.5.3.1 Besoins
L’objectif de la demande est de connaître les éléments, fournis en standard par les
répondants, permettant un contrôle du fonctionnement des composants (disponibilité,
efficacité, performance).
Cette connaissance des composants de l’architecture technique doit permettre d’identifier les
possibilités de supervision globale du système.
Chaque répondant à la présente demande d’information est invité à présenter ses
engagements standards et à préciser les moyens mis en œuvre pour les respecter.
Outre les engagements minimaux demandés ici, les répondants sont libres de proposer tout
autre indicateur pertinent, à condition de respecter le formalisme demandé, c'est-à-dire
décrire pour chaque indicateur :



Sa définition (texte et formule de calcul) ;
La valeur de l’engagement ;
Les limites éventuelles de l’engagement.
Engagements de qualité de service
L’ASIP Santé a besoin d’une solution fiable et performante, ayant une haute résilience de
fonctionnement et une forte résistance aux pannes.
Des engagements sur la disponibilité et les performances du service sont donc demandés.
Les activités du Samu Centre 15 étant en 24*7, ces engagements sont pris sans restriction
d’application horaire.
Ainsi, la fonction de phonie des Samu ne peut tolérer une panne de plus de 5 minutes par
an. La solution de téléphonie doit donc avoir une disponibilité 5-9. Toutefois la perte de
disponibilité de certains services non critiques, comme par exemple le service de reporting
seul, n’est pas considérée comme une perte de disponibilité du service de téléphonie.
De ce fait, le répondant sera invité à fournir tout indicateur, architecture et méthodologie
garantissant à la fois la disponibilité et la résilience (voir chapitre 3.2.6 La haute
disponibilité).
L’ASIP Santé a également besoin d’une réactivité forte de l’opérateur économique titulaire
du marché en cas d’incident.
90 / 113
Dans ce cadre, l’ASIP Santé souhaite avoir 4 niveaux d’engagement de qualité de service :




SLA Niveau 1 : correspond aux biens (composants) de sensibilité classée faible ;
SLA Niveau 2 : correspond aux biens (composants) de sensibilité classée sensible ;
SLA Niveau 3 : correspond aux biens (composants) de sensibilité classée
stratégique ;
SLA Niveau 4 : correspond aux biens (composants) de sensibilité classée maximale.
SLA : Service Level Agreement ou Engagement de Qualité de Service
Typologies des services versus niveaux d’engagement de service
Le tableau ci-dessous propose et décrit des grandes typologies de services par niveau
d’engagement de services. Cette liste (non exhaustive) et le découpage sont donnés à titre
d’illustration donnant une idée de l’orientation de la volonté de l’ASIP Santé et n’ont aucune
valeur contractuelle.




Sensibilité classée « faible » :
o Service de reporting ;
o Service Workforce management ;
o Service de synthèse vocale ;
o etc.
Sensibilité classée « sensible» :
o Service ticket unifié ;
o etc.
Sensibilité classée « stratégique » :
o Service routage et distribution appel ;
o Service couplage téléphonique informatique ;
o Service supervision ;
o Serveur vocal interactif ;
o Serveur d’enregistreur ;
o etc.
Sensibilité classée « maximale » :
o Service de téléphonie ;
o Service de commutation ;
o Gestion des fax ;
o etc.
Engagements de disponibilité
Le service est ouvert et en service 24h sur 24, 7j sur 7 toute l’année.
Les opérations de maintenance ne doivent pas entrainer de perturbation du service perçu
par les utilisateurs. Toute opération de maintenance devra faire au préalable l'objet d'une
analyse d'impact sur la disponibilité théorique du système.
Les engagements en termes de disponibilité (voir section « Engagement de Performance »)
de la solution porteront notamment (liste non exhaustive) sur les points suivants (par
composant unitaire, hors redondance des datacenters) :
91 / 113
Stratégique
Maximale
Sensibilité
Faible
Sensible
Thème
Désignation
Disponibilité
IPBX
Disponibilité de l’équipement central
99,99%
Gateway Téléphonie
Disponibilité de la téléphonie locale
99,99%
Fax
Disponibilité de la réception des feuilles
de route
99,99%
Disponibilité de la
solution d’enregistrement
Disponibilité des équipements
d’enregistrement
99,97%
Service vocal interactif
Accès pour l’appelant
99,97%
ACD
Solution ACD couplée à la brique CTI
99,97%
Service de couplage
téléphonie informatique
Brique CTI (interconnexion avec IPBX)
Serveurs de bandeaux
Organe gérant les bandeaux des ARM
(Agents)
99,97%
Supervision
Supervision métier des appels
99,97%
Gestion des tickets
d’appels
Gestion des tickets unifiés et enrichis
Reporting
Gestion des statistiques et des exports
99,80%
Workforce Management
Voir description des fonctions chapitre
Workforce management
99,80%
Synthèse Vocale
Synthèse des messages de type
asynchrone
99,80%
99,97%
99,90%
Engagements de performance
Les engagements de performance sont envisagés par partie de système. Chaque répondant
est invité à apporter les commentaires qu’il juge utiles dans son domaine d’activité.
Voix
Domaine
Désignation
Taux de reconnaissance vocale en Keywords spotting
99,5%
Taux de reconnaissance vocale en langage naturel
95,0%
Qualité de la voix
Appels
Performance
À proposer
Délai de décroché d’appel SVI, à 100% de taux d’occupation des
ports de communication
<0,3 s
Délai d’établissement d’un appel (mesuré depuis la demande de
routage (fin de qualification) jusqu’à la mise en relation en décroché
automatique
<0,8s
Taux d’aboutement d’appels (mesuré par semaine, hors saturation
99,999%
92 / 113
d’agent et hors raccroché volontaire appelant)
Taux de charges des équipements (mémoire et capacité processeur)
gérant le routage ou la distribution d’appel, l’enregistrement ou la
supervision (par serveur, par période de 10 min mesurée, en
capacité maximum théorique)
Enregistrement
Bandeaux (*)
Temps d’établissement de communication (appel sortant)
<70%
<1s
Temps de réponse du bandeau sur évènement téléphonique (hors
latence réseau)
<0,3s
Temps de réponse sur message urgent (diffusion des messages sur
l’ensemble des bandeaux, base 1 000 agents connectés)
< 2s
Temps de rafraîchissement des files d’attente (nécessité d’une vue
cohérente pour le métier lié aux ARM, bases 1 000 agents
connectés)
<1s
Taux d’enregistrement des appels
99,99%
Temps d’accès à un enregistrement (son) enregistré dans la minute
<1s
Temps d’accès à un enregistrement (son) enregistré à moins d’1
mois
<3s
(*): Le bandeau téléphonique sera redéveloppé spécifiquement pour le SI-Samu sur la base
d'API mises à disposition par le logiciel CTI.
Références similaires
Id
Avez-vous des références similaires et significatives offrant et mettant en œuvre des
exigences de disponibilité telles qu’envisagées par l’ASIP Santé ?
QOS-REFS-1
Pouvez-vous décrire les principaux indicateurs utilisés, les éléments d’architecture mis
en œuvre ainsi que la méthodologie employée permettant de garantir la disponibilité et
la résilience de la solution ??
Engagements
Id
Les questions ci-dessous réfèrent aux paragraphes engagements de disponibilité et
engagements de performance. Il est demandé aux répondants de répondre à chaque
question dans un premier temps concernant les critères de disponibilité et dans un second
temps concernant les critères de performance.
QOS-ENGA-1
QOS-ENGA-2
Pour chaque objectif de disponibilité listé ci-dessus, préciser si :
 Vous souscrivez sans réserve à l’atteinte de cet objectif ;
 Le niveau d’engagement standard pour le critère défini ;
 Le niveau d’engagement maximal envisageable avec votre solution.
Pour atteindre le niveau d’engagement de service proposé par le répondant, quelles
sont les contraintes, préconisations et éléments d’architecture de la solution
(composant applicatifs/techniques) à mettre en œuvre ?
Quelles seraient les limitations et les restrictions au respect de ces engagements ?
93 / 113
QOS-ENGA-3
QOS-ENGA-4
Définition et formule de calcul de SLA
Pour chaque objectif de disponibilité fixé, le répondant précise la formule ou la
définition qui encadrent les engagements désignés dans la question QOS-DISP-1.
Y a-t-il d’autres indicateurs pertinents qui pourraient aménager ou compléter le
dispositif de SLA envisagé ?
Préciser les objectifs poursuivis par ces indicateurs.
QOS-ENGA-5
Le répondant précise les modalités conseillées de réalisation des opérations de
maintenance, dans un contexte de disponibilité 24/7, 365 jours par an.
4.5.4 Tarification
4.5.4.1 Besoins
L’ASIP Santé souhaite connaitre le ou les modèles de tarification standards de chaque
vendeur de solutions de centre d’appels et de mesurer leur possibilité de souplesse et
d’adaptation au contexte du SI- Samu.
Chaque répondant précise les différents modèles tarifaires qu’il peut engager :


Achat en mode services ou en mode licences (nommée, flottante, ou à l’usage) ;
Intégration au modèle de tarification de la scalabilité de la solution (évolutivité,
capacité à absorber de manière temporaire ou permanente les quantités d’appels
simultanés), liée à la montée progressive des CRRA (étalée sur plusieurs années) au
sein du SI-Samu et à la gestion de pics d’appels pour des évènements de portée
nationale.
L’ASIP Santé étudie également l’opportunité d’acquérir les licences de la solution de centre
d’appels en lieu et place d’un modèle d’achats de services soit dès le début du projet, soit en
cours de contrat. Chaque répondant de solution présente la possibilité d’un tel mode d’achat
sur tout ou partie du périmètre de services de centre d’appels et les modalités de sa mise en
œuvre.
94 / 113
Id
TRF-TARF-1
Structure tarifaire
Présenter la structure et les modalités tarifaires de l’offre couvrant tout le périmètre
de services de centre d’appels demandés par l’ASIP Santé, à savoir les services
suivants :
 Service d’acheminement ;
 Service d’appels sortants ;
 Service d’accueil vocal :
o Min d’appel, canaux voix ;
o Prix d’activation, usage ;
o Maintenance ;
o Préciser votre tarification pour l’usage des fonctions de
reconnaissance vocale et TTS ;
o Décrire votre catalogue d’unités d’œuvre pour les prestations qui ne
sont pas incluses dans le prix à l’usage du SVI ;
 Service téléphonique ;
 Service de conférence ;
 Service d’enregistrement :
o Nb appels enregistrés, simultanés ;
o Durée et volumétrie enregistrées ;
o Type de média enregistré (voix, radio, …) ;
o Par fonctionnalité offerte (enregistrement, réécoute,
administration,…) ;
o Maintenance ;
o Autre modalités ou métriques tarifaires (à préciser) ;
 Service de distribution ;
 Service de statistique ;
 Service de supervision ;
 Service de téléphonie administrative ;
 Service d’afficheurs muraux ;
 Service de multicanal ;
 Service de couplage téléphonique informatique :
o Mode de tarification position fixe, flottante ;
o Maintenance ;
 Service de ticket unifié.
Préciser les métriques utilisées pour les différents composants (hardware, licences,
maintenance, nouvelles version, adaptations spécifiques), les prérequis et les règles
d’usage sous-jacente.
Quels éléments auront un fort impact sur le coût de la solution ?
Pouvez-vous engager un modèle de tarification unique portant sur l’ensemble de votre
réponse?
TRF-TARF-2
Avez-vous un modèle de tarification englobant en standard la fourniture d’un ensemble
de services ? Préciser les services couverts par un même modèle de tarification et les
conditions de tarification associées.
Préciser les métriques de tarification et les principes qui encadrent leur tarification.
95 / 113
TRF-TARF-3
Pouvez-vous détailler les métriques sur lesquelles se basent vos modèles de
tarification, en précisant notamment les possibilités offertes suivantes:
 Position installée ;
 Position nommée ;
 Position simultanée ;
 Nb d’appels simultanés ;
 Nb d’appels ;
 Nb de minutes d’appels ;
 Durée moyenne d’appels ;
 Autres métriques, etc.
Avez-vous des modèles de tarification à la licence nommée et flottante ?
TRF-TARF-4
TRF-TARF-5
Quel est leur fonctionnement ?
Y a-t-il des limitations ou des prérequis en termes de nombre de licences, de nombre
d’utilisateurs simultanés et de nombre d’appels simultanés ?
Id
TRF-TARF-7
Changement du mode d’achat de services
Proposez-vous des modèles d’achat de services de Centre d’appels : À l’usage du
service ET basé sur un modèle d’acquisition de licences ?
Id
Gestion de la « scalability »
La « scalability » désigne la capacité à absorber de manière temporaire ou
permanente une augmentation de trafic d’appels Cette scalabilité nécessite une
augmentation du nombre de licences d’agents.
TRF-TARF-8
Pouvez-vous préciser votre politique tarifaire, ses prérequis et modalités d’application
pour :
 Une augmentation temporaire (pour couvrir entre autres la gestion de pics de
trafic) ?
 Une augmentation permanente (pour couvrir en particulier la montée en
puissance de déploiement de nouveaux CRRA) ?
Pourriez-vous en particulier détailler les aspects touchant à la gestion des serveurs
vocaux et les besoins de licences pour les utilisateurs ?
Id
TRF-TARF-9
Dégressivité de la tarification
Pouvez-vous et sans engagement nous indiquer les mécanismes de dégressivité de
tarification qu’il vous arrive d’appliquer. Par exemple en fonction de :
 La volumétrie des appels ;
 Le nombre de conseillers ;
 La durée du contrat ;
 Autre paramètre (à préciser).
Id
Révision et Indexation des prix
TRF-TARF-10
Pouvez-vous et sans engagement nous indiquer les moyens que vous envisagez pour
garantir la compétitivité des prix des services ? Détailler en particulier les possibles
modalités de dégressivité des prix selon un axe temporel ou conjoncturel :
 La procédure de révision des prix ;
 Les conditions de révision annuelle ;
 Les critères et taux d’évolution ;
 Les conditions de sortie anticipée avant la fin de période initiale.
96 / 113
Id
Déploiement de ressources complémentaires
TRF-TARF-11
Préciser votre politique tarifaire concernant des ressources en stand-by (datacenter de
backup) versus des ressources nominales ?
Disposez-vous d’une politique tarifaire adaptée à une gestion de trafic de pointes
(évènement ponctuel type AZF) ? Préciser cette politique.
TRF-TARF-12
Dans le cas d’un déploiement successif des CRRA, pouvez-vous préciser s’il est
possible de n’acheter les licences et la maintenance associée qu’à la mise en
production de chaque CRRA / groupe de CRRA ?
TRF-TARF-13
Quelle est votre politique quant à la mise à disposition de ressources et de capacités
logicielles concernant des environnements de DEV, de RECETTE, de FORMATION et
de PRE-PRODUCTION ?
Id
Maintenance
Pouvez-vous préciser les principes tarifaires de la maintenance des services proposés
en indiquant le prix de la maintenance annuelle en % du prix d’acquisition et
éventuellement sur des développements complémentaires réalisés ?
TRF-MNTC-1
Détailler l’étendue de la maintenance pour les modules logiciels (évolutive, corrective,
etc.).
Préciser la date d’effet de la maintenance pour les éléments matériels et logiciels : à
l’issue de la réception définitive, avec le principe d’une période de gratuité pour la
garantie ?
Id
TRF-CTLS-1
Prestations de projet et d’expertise
Pouvez-vous préciser les prestations projet que vous jugez importantes, voire
indispensables, que vous devriez réaliser en tant que fournisseur de solutions ou que
l’intégrateur (ou l’opérateur) de votre solution devrait mettre en place ?
4.6 Organisation des fournisseurs de solutions
Cette section doit permettre à l’ASIP Santé d’avoir une connaissance générale de
l’organisation du répondant.
Présentation générale du répondant
Id
PRE-GENE-1
Préciser la localisation de votre société en France (adresse postale).
PRE-GENE-2
Préciser l’identité du point de contact de votre société dans le cadre du programme SISamu : nom, prénom, fonction, e-mail, numéro de téléphone.
PRE-GENE-3
Préciser la date de création de votre société et de sa représentation en France.
PRE-GENE-4
Préciser les activités de votre société en France (fournitures de solution, intégration,
maintenance, consulting, …).
97 / 113
PRE-GENE-5
Quel est le chiffre d’affaires de votre société :
 En France ?
 En Europe ?
 Dans le monde ?
PRE-GENE-6
Quelle est la répartition de ce chiffre d’affaires entre les différentes activités de votre
société (vente de licences / matériels, prestations, …) ?
PRE-GENE-7
Quels sont les effectifs de votre société :
 En France ?
 En Europe ?
 Dans le monde ?
PRE-GENE-8
Votre société a-t-elle établi des partenariats avec des intégrateurs du marché ? Le cas
échéant pouvez-vous les lister ?
4.6.1 Organisation de la maintenance
Présentation de l’organisation de la maintenance
Id
PRE-MNTC-1
PRE-MNTC-2
Quels sont le soutien et les garanties apportés en cas d’incident :
 A vos utilisateurs finaux (en l’occurrence à l’ASIP Santé dans le cadre du SISamu) ?
 A vos partenaires / revendeurs (Value-Added Resellers)?
 Aux opérateurs / hébergeurs revendant vos solutions en mode service?
Quels sont le soutien et les garanties apportés à vos utilisateurs finaux dans le cadre
de la gestion des problèmes (en l’occurrence à l’ASIP Santé dans le cadre du SISamu) ?
PRE-MNTC-3
Quels sont le soutien et les garanties apportés à vos partenaires / revendeurs (ValueAdded Resellers) dans le cadre de la gestion des problèmes ?
PRE-MNTC-4
Quels sont le soutien et les garanties apportés aux opérateurs / hébergeurs revendant
vos solutions en mode service dans le cadre de la gestion des problèmes ?
PRE-MNTC-5
Quelle est votre politique de versionning dans le cadre de la gestion des problèmes :
fréquence, obligation de montée de version, support, etc. ?
PRE-MNTC-6
Quelle est votre politique de gestion des patchs dans le cadre de la gestion des
incidents : fréquence, obligation d’installation, support, etc. ?
PRE-MNTC-7
Disposez-vous d’équipes en charge du support de vos produits :
 En France ?
 En Europe ?
 Dans le monde ?
Préciser la taille de vos équipes de support en France, en Europe et dans le monde.
PRE-MNTC-8
Un support à vos produits est-il disponible en français ? Via quel canal et sur quelles
plages horaires ?
PRE-MNTC-9
Quelle est la langue par défaut utilisée pour vos communications relatives au
support ?
PRE-MNTC-10
Du fait de la durée de mise en place du SI-Samu, pouvez-vous fournir votre politique
en termes de maintien de versions et de dépôt des éléments constituant les produits
proposables, en cas de défaillance de la société ?
98 / 113
4.6.2 Approvisionnement
Approvisionnement
Id
PRE-APPR-1
En cas de nécessité de remplacement d’un équipement défectueux, pouvez-vous
détailler les délais d’approvisionnement matériel et logiciel ?
4.6.3 Gestion des évolutions
Gestion des évolutions
Id
PRE-EVOL-1
Quelle est la politique de montée de versions de vos éléments logiciels :
 Fréquence ;
 Modalités pratiques de montée de version ;
 Obligation contractuelle de montée de version.
PRE-EVOL-2
La compatibilité ascendante de votre solution est-elle garantie contractuellement ?
Quelles sont les limites à cette garantie ? Quels sont les risques de régression ?
PRE-EVOL-3
Quelles sont les possibilités / limites d’une gestion d’un parc hétérogène de versions
de votre solution ?
PRE-EVOL-4
Fournissez-vous un outillage particulier permettant de faciliter les montées de
version ?
PRE-EVOL-5
Quel est l’impact constaté des montées de version au sein de votre client ? Quelles
sont les bonnes pratiques à mettre en œuvre ? Quels sont les impacts en termes de
disponibilité ?
4.6.4 Prise en compte des demandes spécifiques
Gestion des demandes spécifiques
Id
PRE-SPEC-1
Dans le cas de la mise en place par un intégrateur d’une fonction non native au sein
de votre produit :
 Avez-vous une politique de « progicialisation » permettant d’intégrer cette
fonction au sein de votre produit standard ?
 Est-il possible d’intégrer ces évolutions lors d’une de vos futures montées de
version majeure? Le cas échéant, selon quelles modalités ?
PRE-SPEC-2
Comment garantissez-vous la compatibilité ascendante sur l’ensemble de vos API et
vos interfaces ? À défaut, comment documentez-vous les écarts entre les interfaces ?
4.6.5 Processus d’escalade
Processus d’escalade
Id
PRE-ESCA-1
En cas de difficulté contractuelle rencontrée avec un intégrateur de l’un de vos
produits, proposez-vous un dispositif d’escalade ad hoc pour vos clients finaux ?
PRE-ESCA-2
En cas de difficulté contractuelle rencontrée avec un intégrateur de l’un de vos
produits, disposez-vous d’une politique client (et des moyens correspondants) à même
de permettre une mise sous contrôle d’un projet mené par un de vos clients finaux ?
99 / 113
5 Annexes
5.1 Besoin métier
Le schéma ci-dessous présente à titre illustratif et de manière macroscopique la cartographie
fonctionnelle cible du futur SI-Samu.
Cette synthèse est issue des nombreux travaux préparatoires conduits par les équipes de
l’ASIP Santé avec les représentants métier d’un grand nombre de Samu.
100 / 113
5.2 Cinématique de l’appel et architecture
La cinématique proposée dans ce schéma est donc la suivante :
Le Patient ou un effecteur appelle le 15 ou le 112.
L’opérateur de boucle locale fournit l’appel à l’opérateur de collecte, enrichis par les
données de géolocalisation.
L’opérateur de collecte est en charge de globaliser les appels et de leur appliquer
les règles de chaque PDAAU. L’opérateur de collecter applique ensuite la stratégie
de traitement unifiée en fonction de la charge globale des appels,
L’opérateur de service apporte des fonctionnalités avancées telles que :
a. Prise en charge des fonctionnalités de pré-routage et de serveurs
vocaux, via les serveurs frontaux SVI qui sont capables de jouer les
scénarios fonctionnels d’accueil vocal et de qualification de
l’appelant, paramétrés au niveau de l’administration fonctionnelle par
les Samu ;
b. Hébergement des composants serveurs, en particulier ceux qui
doivent communiquer en voix sur IP avec les équipements
opérateurs :
i. Serveurs centraux d’enregistrement des appels ;
ii. Équipements de téléphonie de type IPBX ;
iii. Hébergement des composants applicatifs CTI & LRM.
L’acheminement de l’appel en nominal vers le site local est fait par des liens
télécoms traditionnels de type T2.
L’acheminement de l’appel en dégradé vers le site local est fait par IP MPLS.
Acheminement en cas de saturation du CRRA-1 ou sur compétence spécialisée
(entraide),
Distribution vers le meilleur agent.
5.3 Cinématique de traitement du service d’accueil
vocal
D’une manière générale, le patient appelle le 15 ou le 112 alors qu’un effecteur peut aussi
composer un numéro entrant dédié.
De ce fait un test sur le numéro appelé est effectué afin de permettre une première
personnalisation de l’accueil vocale.
Dans un second temps, un SVI (Serveur Vocal Interactif) « muet » (qui ne joue pas de
message et implique un blanc de quelques secondes pour tous les appelants) est activé et
attend un code Pin. Le code Pin est fourni aux partenaires et est différent suivant le type
partenaire (SDIS, Ambulances privées, SOS Médecin, Hôpital …).
Si l’appelant ne saisit pas de code Pin, il est alors orienté vers la file d’attente dite « 15 ». Le
numéro de l’appelant est testé dans un premier temps afin de savoir s’il est connu du
système (appel malveillant, patient remarquable, …). Une fois ces tests réalisés :


si un agent est disponible alors l’appel passe directement au « Routage » puis à la
« Distribution » afin de mettre en relation l’appelant et l’agent ;
sinon, l’appel est alors mis en attente sur une application vocale SVI 15-Samu. Dès
qu’un agent est disponible l’appel passe directement au « Routage » puis à la
« Distribution » afin de mettre en relation l’appelant et l’agent.
Si au contraire l’appelant saisit un code Pin, il est alors orienté vers les files d’attente dites
« Partenaires / Professionnels » et un « SVI Professionnel ». Le type d’appelant sera
différencié à l’affichage en file d’attente suivant le code Pin saisi.
102 / 113
5.4 Cinématique de traitement d’un appel entrant
La cinématique proposée dans ce schéma est donc la suivante :
Lorsque l’appelant émet un appel, la voix est acheminée sur l’organe télécom où
sont acheminés les appels. Cet appel est décroché et parqué sur l’organe télécom
le temps que les fonctions centre d’appels trouvent le meilleur agent disponible
103 / 113
pour répondre à l’appel ou appliquent les règles de gestion des appels
Une fois l’appel arrivé sur les infrastructures télécoms, le système CTI qualifie
l’appel et le type d’appelant à l’aide de requêtes en bases de données système
et/ou SI via des Web Services. Cette partie de la qualification fait la jonction entre
les métadonnées fournies par l’opérateur télécom lors de la collecte (numéro de
l’appelant, département de provenance, …) et les informations contenues dans le
SI-Samu. Cette étape permet, par exemple, d’identifier un numéro de téléphone
connu du SI-Samu (BDD Centre d’appels) et de trouver les DRM récentes associés
à ce numéro de téléphone. Le système peut aussi proposer à l’appelant de saisir
des informations numériques (par ex, les quatre derniers chiffres du DRM) ou de
prononcer le motif de l’appel.
Une fois toutes les données de qualification récoltées, le système définit la priorité
(immédiate et dynamique dans le temps) et les compétences nécessaires pour
pouvoir répondre au mieux à la problématique de l’appelant, suivant un ensemble
de règles préétablies.
Le système trouve l’appel le plus urgent et recherche ensuite l’agent disponible le
plus à même de répondre à l’appel. Si aucun n’est disponible, l’appel est alors mis
en attente.
Une fois les règles de routage de l’appel implémentées, la distribution regarde si
l’appel peut être distribué automatiquement. Si un agent est disponible, alors nous
passons directement à l’étape 7, sinon si tous les agents sont indisponibles alors
l’appel est éventuellement routé sur un SVI selon la stratégie de routage qui lui est
applicable (ce SVI nécessite des actions de l’appelant), puis est mis en attente de
la disponibilité d’un agent. Dans notre cas, le SVI demande à l’appelant de qualifier
l’urgence vitale de son appel et ainsi de définir sa priorité.
Si un agent est ciblé (avec ou sans attente), le système envoie l’information au
poste de collecte afin de réserver l’agent.
Le système envoie la notification de l’arrivée d’un appel au poste de travail de
l’utilisateur via l’application téléphonique CTI et le poste de collecte envoie l’appel
sur le poste téléphonique associé à ce poste de travail.
L’application téléphonique CTI envoie la notification de l’arrivée d’un nouvel appel
au système de gestion de régulation médicale. Il envoie la notification au LRM qui
crée un nouveau dossier de régulation médicale en cas de nouvelle demande, ou
qui ouvre le ou les DRM probablement en rapport avec l’appel en cas de suivi d’une
demande déjà initialisée.
Remarque : Ce schéma est illustratif et représente le fonctionnement des appels « publics »
faits aux Samu, constituant la majorité des appels.
5.5 Intégration des réseaux Radio
5.5.1 Présentation du réseau ANTARES
L'Infrastructure Nationale Partagée de Télécommunications (INPT) est organisée autour de
milliers de sites-Relais qui couvrent environ 95 % du territoire métropolitain français. L’INPT
est un réseau radio national pour les services de l’état, notamment la police (TETRAPOL), la
104 / 113
gendarmerie (RUBIS), et tous les services de la protection civile. L’INPT est découpée
logiquement en plusieurs organisations indépendantes.
Le réseau ANTARES (Adaptation Nationale des Transmissions Aux Risques Et Secours)
s’appuie sur l’INPT. C’est un réseau numérique crypté qui permet des communications
sécurisées entre ces utilisateurs. ANTARES est découpée en réseau de base ayant une
couverture départementale. Chaque terminal radio possède un numéro d’identification sur le
réseau appelé RFGI
Les Services d’Incendie et de Secours (SDIS), Les Services de Secours et des Urgences
(Samu, Smur...), utilisent ce réseau national numérique sécurisé, en remplacement des
réseaux analogiques historiques.
ANTARES permet aux réseaux radio des SDIS et des Samu d'avoir :
 Une cohérence technologique pour tous les services d'urgences ;
 Une interopérabilité des réseaux de communication radioélectriques des services
publics concourant aux missions de sécurité civile selon un ensemble de règles et
normes techniques ;
 Une assurance de la continuité des communications en intervention en toutes
circonstances (milieux souterrains, confinés, bâtiments...).
Ces services offerts peuvent être découpés en trois catégories :
-
-
-
Communication phonie
 Appel de group ou talk group (identique à une fréquence sur les réseaux
analogiques) ;
 Appel individuel (identique à un téléphone) ;
 Appel de détresse ;
 Appel direct (communication tactique) ;
 Appel RIP relais mobile (communication tactique relayée) ;
 Gestion des priorités ;
 Préemption ;
Réception de données via des messages cours
 Statut ;
 Géo localisation ;
Réception de données via des messages longs
 Rapports d’intervention ;
 ECG ;
 Bilans médicaux.
5.5.2 Les gestionnaires de voies radio
Un gestionnaire de voies radio ou GVR est à la fois :



Un pont de conférence ;
Une passerelle radio / IP ;
Un équipement de traitement du signal.
Cette solution permet de gérer les équipements radio et de communiquer à l’aide de la radio
numérique, analogique.
Elle permet également de s’interconnecter de façon plus ou moins intégrée avec la partie
téléphonie.
105 / 113
Un même GVR peut s’interfacer



Directement avec un ou plusieurs équipements radio analogiques ;
Directement avec un ou plusieurs équipements radio numériques comme Antares ;
En IP via une passerelle radio IP ou un autre GVR.
Chaque personne du Samu peut être abonnée à un ou plusieurs «flux radio». Un canal
préférentiel peut être spécifié. L’utilisateur peut alors être à l’écoute des messages radios sur
plusieurs canaux en les multiplexant, sur son canal préféré. Il peut être averti par son IHM
qu’une communication a été reçue sur l’un des canaux autorisés sur son plan de veille ce qui
est très utile dans le cas où il a baissé le volume sonore de sa réception.
Pour devenir voie opérateur, une ressource du type voie analogique ou conférence, doit être
dans le plan de veille. Une communication reçue sur un canal est notifiée comme un appel
téléphonique dans une salle d’attente. Il est possible d’écouter le message en différé sur le
poste opérateur.
Cette prise de main sur cette communication est vue par le système de communication :


Soit l’agent communique avec le distant, il est vu alors comme indisponible dans la
téléphonie ;
Soit l’agent quitte la voie opérateur sans en prendre une autre. Il doit être vu comme
disponible par le centre d’appels.
106 / 113
L’écoute peut être effectuée dans un casque ou par haut-parleur. Généralement les voies
radio du plan de veille sont multiplexées dans le haut-parleur, alors que la voie opérateur
passe dans le casque.
L’accès au réseau Antares peut être effectué par une AG radio, par AG filaire (ou de façon
extrêmement rare en IP si la préfecture a autorisé un déport du GVR en préfecture).
Il existe plusieurs types de configuration entre les Samu et les SDIS
La performance limitée du réseau pour le transfert de données ne permet pas d’envisager
des échanges importants en volumes, mais les fonctions à faible niveau de trafic peuvent
être envisagées. Elles nécessitent la mise en place de liaisons vers les serveurs du SDIS et
la mise en œuvre des applications correspondantes.
Actuellement une liaison point à point filaire (type xDSLs) ou FH (Faisceau Hertzien) est
utilisée entre le Samu et le SDIS, elle doit permettre la communication applicative avec les
serveurs AVL et d’alerte.
L’utilisation d’un VPN sur Internet est possible mais non souhaitable. Elle est très rarement
utilisée car elle ne permet pas de garantir une qualité de service compatible avec la voix.
Cette solution est toutefois utilisée entre le GVR du Samu de Besançon et ceux des SDIS
(25, 39, 70) de la région.
La fonction AVL installée au SDIS est implémentée sur un serveur dédié disposant
généralement de deux interfaces IP :


Une interface pour communiquer avec le CG situé à la préfecture ;
Une interface associée au réseau informatique opérationnel du SDIS pour
communiquer avec les applications clientes au SDIS et au Samu.
Le serveur AVL communique avec les terminaux radio Antares des véhicules pour collecter
les statuts, les informations de géolocalisation, et transmettre des messages courts. Les
107 / 113
agents peuvent aussi transmettre des messages libres aux véhicules et qui seront affichés
sur le terminal radio associé à ce dernier. Le serveur Alerte est dédié aux messages longs.
Les applications utilisatrices de ces données doivent venir les récupérer sur les serveurs
AVL et Alerte du département concerné.
L’ensemble des matériels et logiciels doit être conforme à la norme AFNOR issue du GT
399.
La norme NF399 a été conçue pour permettre l’interopérabilité entre différents équipements.
Elle est basée sur une architecture orientée services impliquant des échanges au niveau IP,
SOAP, XML.
Plusieurs interfaces ont été spécifiées, notamment les suivantes :






R11 Connexion vers le serveur AVL (Statu et géolocalisation) ;
R17 Enregistrement en IP vers enregistreur légal ;
R18 Interopérabilité dans le cadre de la RGPP. Pilotage depuis le système d’aide à la
régulation ou de téléphonie avancée des ressources radio (synoptique des moyens
ou cartographie) ;
R19 Synchronisation avec bases de données système tiers. Lancer en priorité les
projets d’interopérabilité sur les besoins communs des acteurs (information
géographique, vidéo, géolocalisation) ;
R20 Relier les centres opérationnels ;
R33 Interconnexion avec Systèmes de Gestion de la Phonie tiers.
Les principaux fournisseurs de solutions GVR utilisées par les Samu sont Prescom, IMPI et
SYSOCO.
108 / 113
Les installations mises en place sont dans 70% des cas des configurations Type 2, et 30%
des cas des configurations de type 1 ou 1bis. Seule une configuration est de type 3, elle
n’existe qu’à Marseille. Les différentes configurations sont présentées au sein des schémas
infra.
5.5.3 Configuration des SDIS
Généralement le SDIS se connecte à la préfecture où se trouve le commutateur général par
une liaison multiplexée permettant d’accéder à plusieurs AG filaires distantes et de fournir un
lien IP pour que les serveurs AVL et Alerte puissent recevoir les messages du réseau
Antares. Les routeurs effectuent les fonctions de filtrage des flux et de translation d’adresse
NAT nécessaires.
5.6 Glossaire
Acronyme
ACD
AG
AMU
ANTARES
AP
API
AR
ARM
AVL
BDD
BDSP
Signification
Automatic Call Distributor
Access Gate
Aide Médicale Urgente
Adaptation Nationale de la Téléphonie Aux Risques Et Secours
Ambulance Privée
Application Programming Interface
Ambulance de Réanimation
Assistant de Régulation Médicale
Automatic Vehicle Location
Base De Données
Base de Données de Sécurité Publique – Public Security Database
109 / 113
CAV
CRM
CRRA
CSTA
CTA
CTI
DECT
DHCP
DMP
DNS
DRM
DSFT
DTMF
EBIOS
ECG
ES
EWT
FNO
FNSPF
GED
GPS
GTR
GV
GVR
HRO
IHM
INPT
IPBX
ISDN
LAN
LCA
LDAP
LRM
MCO
MMS
MNO
MOTD
MPLS
MR
MRCP
MRG
MRU
MSSanté
MTBF
MU
NAS
NAT
NDI
NOC
NTP
OEM
OIV
Centre d'Appel Virtuel (Voir aussi : VCC)
Customer Relationship Management
Centre de Réception et de Régulation des Appels
Computer-Supported Telecommunications Applications
Centre de Traitement d'Alertes
Couplage Téléphonie Informatique
Digital Enhanced Cordless Telephone
Dynamic Host Configuration Protocol
Dossier Médical Personnel
Domain Name System
Dossier de Regulation Médicale
Dossier de Spécifications Fonctionnelles et Techniques
Dual-Tone Multi-Frequency
Expression des Besoins et Identification des Objectifs de Sécurité
ElectroCardioGramme
Établissements de santé
Estimated Wasting Time
Fixe Network Operations
Fédération Nationale des Sapeurs-Pompiers de France
Gestion Electronique de Document
Global Position System
Garantie de Temps de Rétablissement
Guide Vocal
Gestionnaire de Voies Radio
High Reliability Organization
Interface Homme Machine
Infrastructure Nationale Partageable des Transmissions
Internet Private Branch eXchange
Integrated Services Digital Network
Local Area Network
Last Call Agent
Lightweight Directory Access Protocol
Logiciel de Régulation Médicale
Maintien en Condition Opérationnelle
Multimedia Messaging Service
Mobile Network Operations
Message Of The Day
MultiProtocol Label Switching
Médecin Régulateur
Media Resource Control Protocol
Médecin Régulateur Généraliste
Médecin Régulateur Urgentiste
Messagerie Sécurisée de Santé
Mean Time Between Failure
Médecine d’Urgence
Network Attached Storage
Network Adress Translation
Numéro de Désignation d'Installation
Network Opération Center (Voir aussi : SOC)
Network Time Protocol
Original Equipment Manufacturer
Opérateur d'Importance Vitale
110 / 113
OLA
ORSEC
PDAAU
PDSA
PESQ
PFLAU
PLS
POI
POM
PS
RFI
Operational Level Agreement
Organisation de la Réponse de Sécurité Civile
Plan Départemental d'Acheminement des Appels d'Urgence
Permanence des Soins Ambulatoires
Perceptual Evaluation of Speech Quality
Plateforme de Localisation des Appels d'Urgence
Pronunciation Lexicon Specification
Point d'intérêt, en anglais « Point Of Interest »
Pays d'Outre-Mer
Professionnel de Santé
Request For Information ("Demande d’information")
RIE
RNIS
ROR
RTC
RTU
Samu
SAV
SBC
SDA
SDH
SDIS
SI
SI des ES
SICAP
SIG
SIH
SIN
SIP
SLA
SMS
Smur
SmurM
SNMP
SOC
SQL
SRM
SRTP
SSML
SVI
TAA
TDM
TETRAPOL
TLS
TMC
ToIP
TOM
TSU
TTS
TXT
VCC
VHF
Réseau Interministériel de l’État
Réseau Numérique à Intégration de Services
Répertoire Opérationnel des Ressources
Réseau Téléphonique Commuté
Réponse Téléphonique à l’Urgence
Service d’Aide Médicale Urgente
Service d'Accueil Vocal
Session Border Controllers (éEquipement de sécurité réseau)
Sélection Directe à l'Arrivée
Synchronous Digital Hierarchy
Service Départemental d'Incendie et de Secours
Système d’Information
Système d’Information des établissements de santé
Système d’Information des centres antipoison
Système d’Information géographique
Système d’Information hospitalier
Système d’Information national
Session Initiation Protocol
Service Level Agreement
Short Message Service
Service Mobile d'Urgence et de Réanimation
Smur Maritimes
Simple Network Management Protocol
Security Opération Center (Voir aussi : NOC)
Structured Query Language
Système de Régulation Médicale
Secure Real-time Transport Protocol
Speech Synthesis Markup Language
Serveur Vocal Interactif
Transmission Automatique des Alertes
Time Division Multiplexing
TETRAPOL est une norme de radiocommunication numérique
Transport Layer Security
Temps Moyen de Communication
Telephony over Internet Protocol.
Territoires d'Outre-Mer
Transport sanitaire urgent
Text To Speech
Abréviation du mot texte
Virtual Call Center
Very High Frequency (bande des très hautes fréquences)
111 / 113
VIP
VLAN
VoIP
VPN
VXML
WAN
XML
Very Important Person
Virtual Local Area Network
Voice over Internet Protocol
Virtual Private Network
Vocal XML
Wide Area Network
Extensible Markup Language
***
112 / 113
113 / 113

Classification : Confidentiel / Non sensible interne / Non sensible

Transcription

Documents pareils

l`IP - Quonex

Téléphonie IP Comprendre la différence entre IPBX et Centrex

Plan : ALAIN ROLLAND - Hôtel Alpen Roc, La Clusaz

TÉLÉPHONIE D`ENTREPRISE : PASSER À LA VOIX SUR IP EN

Dossier de Presse

cahier des charges - Ecole Nationale Supérieure d`Architecture de

les télécoms, Un appel d`air pour le channel

Bundles de services

Livre blanc « téléphonie d`entreprise en mode SaaS ou

Service Téléphonie IP