· Web viewChaque passerelle doit pouvoir être accessible via un protocole de prise en main à...

Demande d’information Téléphonie et Centre d’AppelsCadre de Réponse

Sommaire1 Objet de ce document........................................................................................................5

2 Informations attendues par l’ASIP Santé...........................................................................52.1 Informations sur les orientations retenues.................................................................52.2 Informations sur les composants cœur du système...................................................6

2.2.1 Serveurs vocaux interactifs.................................................................................62.2.1.1 Présentation du Service d’Accueil Vocal.....................................................62.2.1.2 Parc et Gestion de Capacité........................................................................6

2.2.1.3 Gestion de la reconnaissance vocale..........................................................62.2.1.4 Support du TTS............................................................................................7

2.2.1.5 Interconnexion avec le service de collecte des flux d’appel........................72.2.1.6 Intégration avec des flux externes...............................................................7

2.2.1.7 Interconnexion avec un ACD.......................................................................72.2.1.8 Transfert de l’appel vers un conseiller.........................................................8

2.2.1.9 Supervision et Statistiques d’appel après transfert......................................82.2.1.10 Administration fonctionnelle.........................................................................8

2.2.2 Fonctions de téléphonie......................................................................................92.2.2.1 Présentation de la solution de téléphonie....................................................9

2.2.2.2 Gestion de la capacité.................................................................................92.2.2.3 Fonctionnalité du service de téléphonie.......................................................9

2.2.2.4 Routage intelligent/distribution...................................................................102.2.2.5 Téléphonie administrative..........................................................................11

2.2.2.6 Intégration avec flux externes....................................................................122.2.2.7 Qualité de la voix.......................................................................................13

2.2.2.8 Supervision/reporting.................................................................................132.2.2.9 Configuration..............................................................................................14

2.2.2.10 Administration............................................................................................152.2.2.11 Gateway dans les CRRA...........................................................................15

2.2.2.12 Modes dégradés........................................................................................162.2.2.13 Sécurité......................................................................................................17

2.2.2.14 Matériel et logiciel de base........................................................................172.2.2.15 IPv6............................................................................................................18

2.2.3 Intégration des fonctions IPBX dans un domaine opérateur.............................182.2.3.1 Acheminement des appels.........................................................................18

2.2.3.2 Acheminement WAN IP.............................................................................182.2.3.3 Traitement de la signalisation d’appel........................................................18

2.2.3.4 Supervision et SLA....................................................................................192.2.3.5 Qualité de la voix.......................................................................................19

2.2.4 Fonctions d’ACD locale ou centrale..................................................................192.2.4.1 Présentation de l’ACD................................................................................20

Classification : Public 2 / 51


2.2.4.2 Gestion de la capacité...............................................................................202.2.4.3 Administration de la solution......................................................................20

2.2.4.4 Routage......................................................................................................212.2.4.5 Distribution.................................................................................................22

2.2.4.6 Intégration..................................................................................................222.2.4.7 Pilotage et données historiques.................................................................23

2.2.4.8 Prérequis Techniques................................................................................232.2.4.9 Indicateurs / SLA........................................................................................23

2.2.4.10 Supervision................................................................................................242.2.4.11 Modes dégradés........................................................................................24

2.2.4.12 IPv6............................................................................................................242.2.5 Conférence ou communications multi-lignes....................................................24

2.2.5.1 Présentation de la fonctionnalité................................................................242.2.5.2 Intégration..................................................................................................25

2.2.5.3 Pilotage et données historiques.................................................................252.2.5.4 Modes dégradés........................................................................................26

2.2.6 Service de couplage de téléphonie...................................................................262.2.6.1 Présentation du service de Couplage Téléphonie Informatique................26

2.2.6.2 Intégration avec la téléphonie....................................................................262.2.6.3 Intégration avec applications tierces..........................................................27

2.2.6.4 Interconnexion avec le service ACD..........................................................272.2.6.5 Supervision activité du CRRA....................................................................28

2.2.6.6 Salles d’attente et gestion d’appel.............................................................282.2.6.7 IPv6............................................................................................................28

2.3 Informations sur les composants connexes au système..........................................282.3.1 Enregistrement des conversations téléphoniques............................................28

2.3.1.1 Catalogue de services...............................................................................282.3.1.2 Présentation de l’enregistreur....................................................................29

2.3.1.3 Gestion de la capacité...............................................................................292.3.1.4 Administration de la solution......................................................................29

2.3.1.5 Enregistrement...........................................................................................302.3.1.6 Stockage Archivage...................................................................................31

2.3.1.7 Intégration..................................................................................................322.3.1.8 Pilotage et données historiques.................................................................32

2.3.1.9 Prérequis Techniques................................................................................322.3.1.10 IPv6............................................................................................................33

2.3.1.11 Indicateurs / SLA........................................................................................332.3.1.12 Supervision................................................................................................33

2.3.1.13 Modes dégradés........................................................................................332.3.2 Affichage et diffuseurs des informations...........................................................332.3.3 Gestion multicanal.............................................................................................34



2.3.3.1 Catalogue de services...............................................................................342.3.3.2 Présentation du service de traitement multicanal......................................34

2.3.3.3 Fonctionnalités...........................................................................................342.3.3.4 Intégration avec la radio (ANTARES)........................................................35

2.3.3.5 Intégration avec des applications tierces...................................................352.3.3.6 Supervision................................................................................................35

2.3.3.7 Pilotage et données historiques.................................................................362.3.3.8 Salles d’attente et gestion des interactions................................................36

2.3.3.9 Prérequis Techniques................................................................................362.3.4 Autres fonctionnalités potentielles.....................................................................37

2.4 Informations liées à l’exploitation de la solution.......................................................372.4.1 Statistiques d’appels.........................................................................................372.4.2 Supervision des appels.....................................................................................372.4.3 Gestion des indicateurs de service...................................................................372.4.4 Contraintes d’exploitation..................................................................................38

2.4.4.1 Gestion des environnements.....................................................................38

2.4.4.2 Configuration type de production...............................................................382.5 Informations transverses..........................................................................................39

2.5.1 Références similaires........................................................................................392.5.2 Gestion des tickets d’appels/communication et interaction...............................39

2.5.2.1 Ticket d’appel dans la solution de téléphonie............................................392.5.2.2 Intégration..................................................................................................41

2.5.2.3 Mode dégradé............................................................................................412.5.2.4 Traçabilité et Consolidation des interactions au niveau DRM....................42

2.5.3 Qualité de service..............................................................................................422.5.3.1 Références similaires.................................................................................42

2.5.3.2 Engagements.............................................................................................422.5.4 Tarification.........................................................................................................44

2.5.4.1 Structure tarifaire.......................................................................................442.5.4.2 Structure tarifaire.......................................................................................45

2.5.4.3 Changement du mode d’achat de services................................................462.5.4.4 Gestion de la « scalability ».......................................................................46

2.5.4.5 Dégressivité de la tarification.....................................................................462.5.4.6 Révision et Indexation des prix..................................................................46

2.5.4.7 Déploiement de ressources complémentaires...........................................462.5.4.8 Maintenance...............................................................................................47

2.5.4.9 Prestations de projet et d’expertise............................................................472.6 Organisation des fournisseurs de solutions.............................................................47

2.6.1 Présentation générale du répondant.................................................................472.6.2 Organisation de la maintenance.......................................................................482.6.3 Approvisionnement............................................................................................492.6.4 Gestion des évolutions......................................................................................492.6.5 Prise en compte des demandes spécifiques.....................................................492.6.6 Processus d’escalade.......................................................................................50



1 Objet de ce documentCe document constitue le cadre de réponse à la demande d’information sur le périmètre téléphonie, centres d’appels et écosystème associé lancée par l’ASIP Santé en prévision des consultations qui seront émises dans le cadre du programme de modernisation des systèmes d’information et de télécommunication des Samu Centre 15.

L’ensemble des informations contextuelles expliquant les attentes formulées est présenté dans le document maître « Demande d’information ».

Il est demandé aux répondants à cet appel à information de respecter le cadre de réponse présenté ci-après. Ils ont toute latitude pour adjoindre en annexe à leur réponse l’ensemble des éléments qu’ils jugent pertinents et utiles à l’ASIP Santé pour une meilleure compréhension de leur offre.

2 Informations attendues par l’ASIP SantéLe présent chapitre, listant les demandes formulées par l’ASIP Santé, est décomposé en 4 parties :

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.

2.1 Informations sur les orientations retenuesCOM-COMM-1 – Vos commentaires et remarques sur les orientations présentées :

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 va-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 ?

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 cet appel à 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.

Réponse :



2.2 Informations sur les composants cœur du système2.2.1 Serveurs vocaux interactifs

2.2.1.1 Présentation du Service d’Accueil VocalSAV-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é.Réponse :

SAV-PRES-2 - Quelle norme/version de VXML supportez-vous ?

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);

Réponse :

2.2.1.2 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)

Réponse :

2.2.1.3 Gestion de la reconnaissance vocaleSAV-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?

Réponse :



2.2.1.4 Support du TTSSAV-TTS-1 - 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é ?

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 ?

Réponse :

2.2.1.5 Interconnexion avec le service de collecte des flux d’appelSAV-INTE-1 - 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 ?

Réponse :

2.2.1.6 Intégration avec des flux externesSAV-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 ?

Réponse :

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 ?

Réponse :

2.2.1.7 Interconnexion avec un ACDSAV-INTE-4 - Quelles sont les contraintes d’interconnexion du service SVI opéré avec un service de distribution d’appels fourni par un tiers ?

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.

Réponse :



SAV-INTE-5 - Préciser votre capacité et le cas échéant vos contraintes – limitations pour :

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).

Réponse :

2.2.1.8 Transfert de l’appel vers un conseillerSAV-INTE-6 - 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é) ?

Réponse :

2.2.1.9 Supervision et Statistiques d’appel après transfertSAV-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 parIP Trunking avec l’environnement ToIP ?

Réponse :

2.2.1.10 Administration fonctionnelleSAV-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 ?Réponse :

SAV-ADMN-2 - 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 queles caractéristiques de l’outil.Réponse :

SAV-ADMN-3 - 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.Réponse :



2.2.2 Fonctions de téléphonie

2.2.2.1 Présentation de la solution de téléphonieTLC-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 +logiciel, etc.), protocoles et standards supportés, interfaces d’intégration avec des applications ou périphériques tiers (APIs, etc.).

Réponse :

2.2.2.2 Gestion de la capacitéTLC-CAPA-1 - 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.

Réponse :

TLC-CAPA-2 - 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 ?

Réponse :

2.2.2.3 Fonctionnalité du service de téléphonieTLC-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.

Réponse :

TLC-FNCT-2 - Concernant votre service de messagerie vocale, quelles sont les interfaces disponibles ? Quelles sont les API disponibles pour une intégration informatique ?Réponse :

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 ?Réponse :

TLC-FNCT-4 - 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.Réponse :



TLC-FNCT-5 - 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.Réponse :

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 sera en charge en mode nominal. En cas de défaillance des fonctionnalités ACD nominales, le marché 1 devra assurer en backup des fonctionnalités de type ACD.

2.2.2.4 Routage intelligent/distributionL’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.TLC-DIST-1 - Préciser votre support des fonctions de routage suivantes :

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.Réponse :

TLC-DIST-2 - Préciser votre support des fonctions d’ACD/routage suivantes :



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é.

Réponse :

TLC-DIST-3 - Préciser votre mode de gestion des appels perdus :

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).Réponse :

TLC-DIST-4 - 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é.Réponse :

2.2.2.5 Téléphonie administrativeTéléphonie administrative : tout appel en dehors du cadre de l’activité SI-SamuPréciser la disponibilité des fonctions suivantes :

TLC-TLAM-1 - Dans notre contexte, quels modèles/possibilités envisagez-vous pour :

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).

Réponse :

TLC-TLAM-2 - Comment gérez-vous les appels de système bippeur et retour éventuel ?

Réponse :

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é).

Réponse :

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.

Réponse : 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).



Réponse :

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éfixales éventuels.

Réponse :

TLC-TLAM-7 - Précisez la capacité de vos matériels à accepter une communication de type visioconférence entre agents :

Intra CRRA ; Inter CRRA.

Réponse :

2.2.2.6 Intégration avec flux externesTLC-INTE-1 - S’agissant de l’intégration avec l’opérateur de collecte : quelle architecture préconisez-vous à l’interface avec les liens TDM de l’opérateur ou des opérateurs ?

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.

Réponse :

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.

Réponse :

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 ?

Réponse :

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.

Réponse :



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.Réponse :

2.2.2.7 Qualité de la voixTLC-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.

Réponse :

2.2.2.8 Supervision/reportingTLC-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.

Réponse :

TLC-SPRV-2 - Disposez-vous d'un outil de taxation? Le cas échéant, présenter cet outil.

Réponse :

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).

Réponse :

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) ?

Réponse :

TLC-SPRV-5 - Dans le cadre d’un processus de supervision globale :

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 ?



Réponse :

2.2.2.9 ConfigurationTLC-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 ?

Réponse :

TLC-ADMN-2 - Gateway pour l’acheminement local via les T2 des CRRA : 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 »).

Réponse :

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 ?

Réponse :

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).

Réponse :

TLC-ADMN-5 - Configuration des routes :

Préciser le mode de configuration des acheminements du trafic téléphoniqueAcheminement des appels entrants vers les CRRA :

Priorisation route DTM 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).



Réponse :

2.2.2.10 AdministrationTLC-ADMN-6 - 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.

Réponse :

TLC-ADMN-7 - 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).

Réponse :

TLC-ADMN-8 - 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 ?

Réponse :

2.2.2.11 Gateway dans les CRRATLC-FNCT-7 - 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 :

CRRA Nombre de Sites

Nombre de personnes moyen en pointe

Petit 25 10Moyen 52 15Grand 20 29Central 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.

Réponse :



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.).

Réponse :

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).

Réponse :

TLC-FNCT-10 - Préciser la visualisation par l’utilisateur sur le téléphone s’il est en mode « survie ».

Réponse :

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).

Réponse :

2.2.2.12 Modes dégradésTLC-RESL-1 - 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).

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.

Préciser la configuration des fonctions ACD en mode nominal (file de taille nulle par exemple).Réponse :



TLC-RESL-2 - 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.Réponse :

TLC-RESL-3 – 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.

Réponse :

2.2.2.13 SécuritéTLC-SECU-1 - 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)

Réponse :

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 dans l’architecture Samu ?

Réponse :

2.2.2.14 Matériel et logiciel de baseTLC-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é.

Réponse :

TLC-SEXP-2 - Préciser les contraintes de la solution sur : Les services DHCP, DNS, NTP ; L’adressage IP.

Réponse :



2.2.2.15 IPv6TLC-INTX-1 - La solution que vous proposez est-elle compatible IPv6 ? En mode nominal ou dual-stack ?

Réponse :

2.2.3 Intégration des fonctions IPBX dans un domaine opérateur

2.2.3.1 Acheminement des appelsACH-ACHC-1 - Reprise de l'appel acheminé vers le CRRA (via TDM ou via WAN) :

Selon votre expérience, l'acheminement par aboutement est-elle la solution la plus appropriée ? Y va-t-il des alternatives ?

Réponse :

ACH-ACHC-2 - 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).

Réponse :

2.2.3.2 Acheminement WAN IPACH-ACHC-3 - 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).

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.Réponse :

2.2.3.3 Traitement de la signalisation d’appelACH-RESL-1 - 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).

Réponse :

ACH-RESL-2 - De quelle "intelligence en propre " dispose l'acheminement pour traiter les « re-tentatives » 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é.

Réponse :



ACH-RESL-3 - 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) ?

Réponse :

ACH-RESL-4 - 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).

Réponse :

ACH-RESL-5 - 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.Réponse :

ACH-RESL-6 - 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 ?

Réponse :

2.2.3.4 Supervision et SLAACH-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).

Réponse :

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 ?

Réponse :

2.2.3.5 Qualité de la voixACH-QOSV-1 - Pouvez-vous préciser votre capacité à diagnostiquer les problèmes de voix sur des trajets IP (LAN/WAN) ?

Réponse :

2.2.4 Fonctions d’ACD locale ou centrale

2.2.4.1 Présentation de l’ACD



ACD-PRES -1 - Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciant 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).Réponse :

2.2.4.2 Gestion de la capacitéACD-CAPA-1 - Quelles sont les limites de la solution en termes de positions, d’interactions simultanées, etc... ?

Réponse :

ACD-CAPA-2 - 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).

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.

Réponse :

2.2.4.3 Administration de la solutionACD-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 ; 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 scénario 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) ?

Réponse :

ACD-ADMN-2 - L’IHM d’administration (à préciser par outil) est-elle intégrable dans un portail web ?

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)

Réponse :

ACD-ADMN-3 - Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles ?

Est-il possible de coupler l’IHM à un annuaire LDAP ? Pouvez-vous préciser les contraintes et les incompatibilités éventuelles ?



Réponse :

2.2.4.4 RoutageACD-ROUT-1 - 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 » ?

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).

Réponse :

ACD-ROUT-2 - La solution dispose-t-elle d’une fonction native permettant de traiter les appels inappropriés (gestion des appels de type fax) ?

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 ?

Réponse :

ACD-ROUT-3 - 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 ?

Réponse :

ACD-ROUT-4 - 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 ?

Réponse :

ACD-ROUT-5 - 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 ?Réponse :

ACD-ROUT-6 - 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 ?Réponse :

ACD-ROUT-7 - La solution est-elle capable de router des appels visio ?

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 ?Réponse :

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écessite-t-elle des développements spécifiques ?Réponse :



2.2.4.5 DistributionACD-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 ?

Réponse :

ACD-DIST-2 - La fonction « Last Call Agent » est-elle proposée nativement par la solution ?

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 ?

Réponse :

ACD-DIST-3 - 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é.

Réponse :

ACD-DIST-4 - La solution permet-elle de sélectionner le type d’acheminement (via T2 ou IP MPLS, voir un load balancing entre les deux) ?

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.

Réponse :

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 ?

Réponse :

2.2.4.6 IntégrationACD-INTE-1 - Quels sont les différents IPBX supportés par la solution ? Quels sont les types de liens possibles vers ces solutions ?Réponse :

ACD-INTE-2 - Quelles sont les éventuelles limitations de votre solution liées au protocole SIP ?Réponse :



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 ?Réponse :

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?Réponse :

2.2.4.7 Pilotage et données historiquesACD-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)

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 ?Réponse :

2.2.4.8 Prérequis TechniquesACD-TECH-1 - Quels sont les types de bases de données compatibles avec la solution ?

Réponse :

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 ?

Réponse :

ACD-TECH-3 - La virtualisation est-elle supportée ? Le cas échéant, sur quelle plateforme ? Préciser les mécanismes concernés.

Réponse :

2.2.4.9 Indicateurs / SLAACD-SVLA-1 - Pouvez-vous préciser le taux de disponibilité maximale de la solution ?

Merci de préciser quel est ou quels sont les éléments les plus sensibles de la solution.

Réponse :

ACD-SVLA-2 - Quels sont les différents SLA sur lesquels vous pouvez-vous engager ?



Réponse :

2.2.4.10 SupervisionACD-SPRV-1 - Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision du Samu ?

Par quel outil et quelle interface ?

Quels sont les intégrations possibles, l’objectif pour le SI-Samu étant d’avoir une vue unifiée ?

Réponse :

ACD-SPRV-2 - Dans le cadre d’un processus de supervision globale :


Réponse :

2.2.4.11 Modes dégradésACD-RESL-1 - 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).

Réponse :

ACD-RESL-2 - 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 ?

Réponse :

2.2.4.12 IPv6ACD-INTX-1 - La solution que vous proposez est-elle compatible IPv6 ? En mode nominal ou dual-stack ?

Réponse :

2.2.5 Conférence ou communications multi-lignes

2.2.5.1 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).

Réponse :

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.

Réponse :



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 »)

Réponse :

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 ?

Réponse :

2.2.5.2 IntégrationCFR-INTE-1 - Préciser de quelle manière la fonctionnalité est implémentée notamment pour la « fusion » d’appels.

Réponse :

CFR-INTE-2 - Quelles sont les éventuelles limitations liées au protocole SIP, à l’IPBX ou autres ?

Réponse :

CFR-INTE-3 - Un des besoins majeurs est l’intégration du canal voix radio au centre de contacts Samu.

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 ?

Réponse :

2.2.5.3 Pilotage et données historiquesCFR-STAT-1 - 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 ?

À 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 ?

Réponse :

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 ?

Réponse :



2.2.5.4 Modes dégradésCFR-RESL-1 - En cas de bascule entre deux datacenters, quelles conséquences voyez-vous :

Sur les conférences en cours (via TDM ou via IP) ? Sur les statistiques ?

Réponse :

2.2.6 Service de couplage de téléphonie

2.2.6.1 Présentation du service de Couplage Téléphonie InformatiqueCTI-PRES-1 - Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciant 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).Réponse :

CTI-PRES-2 - Votre solution est-elle capable d’interagir avec des bandeaux externes ? Quelles interfaces, APIs, utilisez-vous ?Réponse :

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.

Réponse :

CTI-PRES-3 - La solution permet-elle nativement une personnalisation avancée de l’interface à plusieurs échelons : globale, CRRA et agent ? Préciser.

Réponse :

2.2.6.2 Intégration avec la téléphonieCTI-INTE-1 - Quelles sont les contraintes d’interconnexion du service de Couplage TéléphonieInformatique avec le service de téléphonie ?

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).

Préciser les prérequis techniques et économiques en termes de licence.Réponse :

CTI-INTE-2 - Quelles sont les contraintes et limitations pour le service de Couplage TéléphonieInformatique dans un environnement SIP ?

Préciser les impacts éventuels au niveau de l’architecture.

Réponse :



CTI-INTE-3 - Dans l’hypothèse où vos solutions couvrent les fonctionnalités IPBX et CTI, pouvez-vous nous indiquer les avantages et inconvénients de recourir à une solution intégrée plutôt qu’à deux solutions dissociées ?Réponse :

2.2.6.3 Intégration avec applications tiercesCTI-INTE-3 - 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.

Réponse :

CTI-INTE-4 - Préciser les modalités d’interfaçage avec le SIG (en client léger) pour l’affichage de la localisation de l’appelant :


Réponse :

CTI-INTE-5 - Préciser les modalités d’interfaçage avec l’enregistreur pour piloter l’enregistrement : Lien d’intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique.

Réponse :

CTI-INTE-6 - Préciser les bénéfices et limitations d’une intégration client side et d’une intégration server side.

Réponse :

CTI-INTE-7 - Préciser les modalités d’interfaçage avec des annuaires du marché : Lien d’intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique.

Réponse :

2.2.6.4 Interconnexion avec le service ACDCTI-INTE-8 - 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 ?

Quelle est l’architecture nécessaire (interconnexion directe ou via un connecteur, langages de dialogue …) ?

Préciser la liste des éditeurs ACD avec lesquels le service CTI est compatible.

Réponse :

CTI-INTE-9 - 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.



Réponse :

2.2.6.5 Supervision activité du CRRACTI-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.

Réponse :

CTI-SPRV-2 - Dans le cadre d’un processus de supervision globale : 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 ?

Réponse :

2.2.6.6 Salles d’attente et gestion d’appelCTI-CAPA-1 - 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).

Réponse :

CTI-CAPA-2 - 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) ?Réponse :

CTI-CAPA-3 - Préciser votre capacité à implémenter une fonction de gestion d’une « whitelist » pour les appelants « VIP » (priorisation) ?Réponse :

2.2.6.7 IPv6CTI-INTX-1 - La solution que vous proposez est-elle compatible IPv6 ? En mode nominal ou dual-stack ?

Réponse :

2.3 Informations sur les composants connexes au système

2.3.1 Enregistrement des conversations téléphoniques

2.3.1.1 Catalogue de servicesRCR-CTLS-1 - Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciant 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.

Réponse :



2.3.1.2 Présentation de l’enregistreurRCR-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 (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).Réponse :

2.3.1.3 Gestion de la capacitéRCR-CAPA-1 - 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... ?

Réponse :

RCR-CAPA-2 - 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).

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)

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).

Réponse :

2.3.1.4 Administration de la solutionRCR-ADMN-1 - 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) ?

Réponse :

RCR-ADMN-2 - L’IHM d’administration est-elle intégrable dans un portail web ?

Pouvez-vous préciser l’outil correspondant ?

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.

Réponse :

RCR-ADMN-3 - Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles ?

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 ?

Réponse :



2.3.1.5 EnregistrementRCR-FNCT-1 - 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 ?

Réponse :

RCR-FNCT-2 - 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) ?

Réponse :

RCR-FNCT-3 - 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 ?

Réponse :

RCR-FNCT-4 - 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 ? Pour des appels liés à un même DRM ?

Réponse :

RCR-FNCT-5 - 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 ?

Réponse :

RCR-FNCT-6 - Pouvez-vous préciser la capacité de la solution à gérer différents types d’enregistrements :

T2 ; Poste physique ; ARM.

Précisez l’organe auquel l’enregistreur doit être couplé.

Réponse :

RCR-FNCT-7 - 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 va-t-il une limitation en termes de nombre d’enregistrements ré-écoutables immédiatement ?

Réponse :

RCR-FNCT-8 - 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 ?Réponse :

RCR-FNCT-9 - 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 ?Réponse :

RCR-FNCT-10 - 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.Réponse :

RCR-FNCT-11 - 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 ?Réponse :

2.3.1.6 Stockage ArchivageRCR-STAR-1 - 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.

Réponse :

RCR-STAR-2 - Pouvez-vous préciser l’espace d’archivage, en précisant les hypothèses retenues pour le calcul ?

Pouvez-vous préciser si les enregistrements sont compressés et l’impact sur la qualité audio du message archivé ?

Réponse :

RCR-STAR-3 - 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 ?

Réponse :

RCR-STAR-4 - Pouvez-vous présenter le système de purge ?

Réponse :

RCR-STAR-5 - Disposez-vous d’interfaces de sauvegarde vers des systèmes tiers (NAS, autres) ? Précisez.

Réponse :



2.3.1.7 IntégrationRCR-INTE-1 - 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.

Réponse :

RCR-INTE-2 - Pouvez-vous préciser les éventuelles licences tierces nécessaires au bon fonctionnement de la solution d’enregistrement ?

Réponse :

RCR-INTE-3 - 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 ?

Réponse :

2.3.1.8 Pilotage et données historiquesRCR-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)

Réponse :

2.3.1.9 Prérequis TechniquesRCR-TECH-1 - Pouvez-vous nous fournir la matrice de compatibilité des IHM avec :

Les systèmes d’exploitation ? Les navigateurs ?

Réponse :

RCR-TECH-2 - Quels sont les types de bases de données compatibles avec la solution ?

Réponse :

RCR-TECH-3 - 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.

Réponse :

RCR-TECH-4 - La virtualisation est-elle supportée ? Le cas échéant, sur quelle plateforme ? Préciser les mécanismes concernés.

Réponse :

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 ?

Réponse :

2.3.1.10 IPv6ACD-INTX-1 - La solution que vous proposez est-elle compatible IPv6 ? En mode nominal ou dual-stack ?

Réponse :

2.3.1.11 Indicateurs / SLARCR-SVLA-1 - Pouvez-vous préciser le taux de disponibilité maximale de la solution ?

Merci de préciser l’élément ou les éléments les plus sensibles de la solution.

Réponse :

RCR-SVLA-2 - Quels sont les différents SLA sur lesquels vous pouvez-vous engager ?

Réponse :

2.3.1.12 SupervisionRCR-SPRV-1 - Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision du 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 ?

Réponse :

RCR-SPRV-2 - Dans le cadre d’un processus de supervision globale :


Réponse :

2.3.1.13 Modes dégradésRCR-RESL-1 - En cas de mode dégradé, pouvez-vous préciser les conséquences sur les enregistrements des communications ?

Réponse :

RCR-RESL-2 - 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 ?

Réponse :

2.3.2 Affichage et diffuseurs des informations 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).

Réponse :

2.3.3 Gestion multicanal

2.3.3.1 Catalogue de servicesMCN-CTLS-1 - Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciant 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.

Réponse :

2.3.3.2 Présentation du service de traitement multicanalMCN-PRES-1 - 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).

Réponse :

MCN-PRES-2 - La solution permet-elle nativement une personnalisation avancée de l’interface à plusieurs échelons : globale, CRRA et agent ?

Réponse :

2.3.3.3 FonctionnalitésMCN-FNCT-1 - 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.Réponse :

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 ?

Réponse :

MCN-FNCT-2 - Pouvez-vous présenter la fonctionnalité de Media blending ?

À 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) ?

Réponse :



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) ?

Réponse :

2.3.3.4 Intégration avec la radio (ANTARES)MCN-INTE-1 - Avez-vous déjà réalisé une intégration avec de la radiophonie ?

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 ?

Réponse :

2.3.3.5 Intégration avec des applications tiercesMCN-INTE-2 - 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 ?


Réponse :

MCN-INTE-3 - Pouvez-vous préciser les modalités d’interfaçage avec l’enregistreur pour piloter l’enregistrement ?

Lien d’intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique ; Prérequis en termes de licences.

Réponse :

MCN-INTE-4 - Pouvez-vous préciser les bénéfices et limitations d’une intégration client side et d’une intégration server side ?

Réponse :

2.3.3.6 SupervisionMCN-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 ?

Réponse :

MCN-SPRV-2 - Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision du Samu ?


Quels sont les intégrations possibles, sachant que l’objectif pour le SI-Samu est d’avoir une vue unifiée ?



Réponse :

MCN-SPRV-3 - Dans le cadre d’un processus de supervision globale :


Réponse :

2.3.3.7 Pilotage et données historiquesMCN-STAT-1 - 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 ? De l’historique de dernières interactions traitées par le CRRA ?

Réponse :

2.3.3.8 Salles d’attente et gestion des interactionsMCN-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 ?

Réponse :

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 ?

Réponse :

2.3.3.9 Prérequis TechniquesMCN-TECH-1 - Quels sont les types de bases de données compatibles avec la solution ?

Réponse :

MCN-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 ?

Réponse :

MCN-TECH-3 - La virtualisation est-elle supportée ? Le cas échéant, sur quelle plateforme ? Préciser les mécanismes concernés.

Réponse :

2.3.4 Autres fonctionnalités potentiellesLe 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.Réponse :

2.4 Informations liées à l’exploitation de la solution2.4.1 Statistiques d’appelsLe répondant est invité à décrire de manière sommaire :

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.Réponse :

2.4.2 Supervision des appels 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é (si oui, 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.Réponse :

2.4.3 Gestion des indicateurs de servicePour répondre à ces besoins, le répondant est invité à décrire de manière sommaire :

La liste des indicateurs fournie 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 point de mesure dans le contexte du SI-Samu.Réponse :



2.4.4 Contraintes d’exploitation

2.4.4.1 Gestion des environnementsLe répondant est invité à décrire de manière sommaire :

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 « Tarification » ci-après.

Par ailleurs, le répondant est invité à fournir toute précision qu’il juge utile quant à la mise en place des environnements préparatoires à la production dans le contexte du SI-Samu.Réponse :

2.4.4.2 Configuration type de productionLe répondant 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 ;

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 « Tarification » ci-après.

Par ailleurs, le répondant est invité à fournir toute précision qu’il juge utile quant à la mise en place et au maintien des environnements de production dans le contexte du SI-Samu.Réponse :



2.5 Informations transverses2.5.1 Références similairesREFS-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 :

Serveurs vocaux interactifs

Fonctions de Téléphonie

Intégrations des fonctions IPBX dans un domaine intégrateur

Fonctions ACD locale ou centrale

Conférences ou communications multi-lignes

Service de couplage Téléphonie-Informatique

Enregistrement des conversations

Affichage et diffuseurs d’informations

Statistiques d’appels

Supervision des appels

Gestion des tickets d’appels/communication et interaction

Qualité de Service

Gestion du multicanal

Référence 2 : Serveurs vocaux interactifs

Fonctions de Téléphonie

Intégrations des fonctions IPBX dans un domaine intégrateur

Fonctions ACD locale ou centrale

Conférences ou communications multi-lignes

Service de couplage Téléphonie-Informatique

Enregistrement des conversations

Affichage et diffuseurs d’informations

Statistiques d’appels

Supervision des appels

Gestion des tickets d’appels/communication et interaction

Qualité de Service

Gestion du multicanal

Réponse :

2.5.2 Gestion des tickets d’appels/communication et interaction.

2.5.2.1 Ticket d’appel dans la solution de téléphonieTUN-STRD-1 - 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 :

Call managers ; Gateway ; ACD ; SVI ; Enregistreur local et/ou central ; Application routage/distribution/CTI (par serveur au besoin).

Réponse :



TUN-STRD-2 - 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 :

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).

Réponse :

TUN-STRD-3 - Préciser les sous-ensembles de composants qui partage la même référence d’appel dans la solution proposée ?

Réponse :

TUN-STRD-4 - Préciser comment une référence commune peut être partagée entre les sous-ensembles 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 ?

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.

Réponse :

TUN-STRD-5 - Préciser comment peut être modifiée (si besoin) la logique par défaut d’association (règles, développements) ?

Réponse :

TUN-STRD-6 - Aboutement d’appels entre le datacenter et le CRRA :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 ?

Réponse :

TUN-STRD-7 - Transferts d’appel :

Dans le cas de transfert d’appel, pouvez- vous préciser l’aptitude de la solution proposée au :

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) ?Réponse :



TUN-STRD-8 - Cas de l’appel attaché/détaché dans une conférence Y va-t-il un impact sur l’identification des appels liés à une conférence ?

Réponse :

2.5.2.2 IntégrationTUN-INTE-1 - Préciser l’architecture de stockage/exploitation des tickets.

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).

Réponse :

TUN-INTE-2 - Relativement aux outils de statistiques :

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 ?

Réponse :

TUN-INTE-3 - 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).

Réponse :

TUN-INTE-4 - 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 ?

Réponse :

2.5.2.3 Mode dégradéTUN-RESL-1 - Dans le cas d’une perte du réseau WAN (sites téléphoniques isolés), quel est l’impact sur :

La production des informations de tickets décrite précédemment ? La production et stockage local de tickets par les gateways ?

Y va-t-il une consolidation a posteriori après rétablissement du réseau ?

Réponse :

TUN-RESL-2 - 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é.

Réponse :

TUN-RESL-3 - 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.

Réponse :



2.5.2.4 Traçabilité et Consolidation des interactions au niveau DRMLe 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.

TUN-STRD-1 - Enregistrement des communications radio 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 ?

Réponse :

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) ?

Réponse :

2.5.3 Qualité de service

2.5.3.1 Références similairesQOS-REFS-1 - 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é ?

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 ??Réponse :

2.5.3.2 EngagementsLes 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 - 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.

Réponse concernant les engagements de disponibilité:

Réponse concernant les engagements de performance:



QOS-ENGA-2 - 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 ?


Réponse concernant les engagements de performance :

QOS-ENGA-3 - 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.Réponse concernant les engagements de disponibilité:


QOS-ENGA-4 - Y va-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.





2.5.4 Tarification

2.5.4.1 Structure tarifaireTRF-TARF-1 - 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 ?Réponse :

TRF-TARF-2 - Pouvez-vous engager un modèle de tarification unique portant sur l’ensemble de votre réponse?

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.

Réponse :



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.

Réponse :

TRF-TARF-4 - Avez-vous des modèles de tarification à la licence nommée et flottante ?

Quel est leur fonctionnement ?

Réponse :

TRF-TARF-5 - Y va-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 ?

Réponse :

2.5.4.2 Structure tarifaireTRF-TARF-2 - Pouvez-vous engager un modèle de tarification unique portant sur l’ensemble de votre réponse?

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.

Réponse :

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.

TRF-TARF-4 - Avez-vous des modèles de tarification à la licence nommée et flottante ?

Quel est leur fonctionnement ?Réponse :

TRF-TARF-5 - Y va-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 ?Réponse :



2.5.4.3 Changement du mode d’achat de servicesTRF-TARF-7 - 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 ?Réponse :

2.5.4.4 Gestion de la « scalability »TRF-TARF-8 - 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.

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 ?

Réponse :

2.5.4.5 Dégressivité de la tarificationTRF-TARF-9 - 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).

Réponse :

2.5.4.6 Révision et Indexation des prixTRF-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.

Réponse :

2.5.4.7 Déploiement de ressources complémentairesTRF-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.Réponse :

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 ?

Réponse :



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 ?

Réponse :

2.5.4.8 MaintenanceTRF-MNTC-1 - 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 ?

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 ?Réponse :

2.5.4.9 Prestations de projet et d’expertiseTRF-CTLS-1 - 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 ?

Réponse :

2.6 Organisation des fournisseurs de solutionsCette section doit permettre à l’ASIP Santé d’avoir une connaissance générale de l’organisation du répondant.

2.6.1 Présentation générale du répondantPRE-GENE-1 - Préciser la localisation de votre société en France (adresse postale).

Réponse :

PRE-GENE-2 - Préciser l’identité du point de contact de votre société dans le cadre du programme SI-Samu : nom, prénom, fonction, e-mail, numéro de téléphone.

Réponse :

PRE-GENE-3 - Préciser la date de création de votre société et de sa représentation en France.

Réponse :

PRE-GENE-4 - Préciser les activités de votre société en France (fournitures de solution, intégration, maintenance, consulting, …).

Réponse :

PRE-GENE-5 - Quel est le chiffre d’affaires de votre société : En France ? En Europe ? Dans le monde ?

Réponse :



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, …) ?

Réponse :

PRE-GENE-7 – Quels sont les effectifs de votre société : En France ? En Europe ? Dans le monde ?

Réponse :

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 ?

Réponse :

2.6.2 Organisation de la maintenancePRE-MNTC-1 - 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 SI-Samu) ? A vos partenaires / revendeurs (Value-Added Resellers)? Aux opérateurs / hébergeurs revendant vos solutions en mode service?

Réponse :

PRE-MNTC-2 - 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 SI-Samu) ?

Réponse :

PRE-MNTC-3 - Quels sont le soutien et les garanties apportés à vos partenaires / revendeurs (Value-Added Resellers) dans le cadre de la gestion des problèmes ?

Réponse :

PRE-MNTC-4 - els 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 ?

Réponse :

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. ?

Réponse :

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. ?

Réponse :

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.

Réponse :



PRE-MNTC-8 - Un support à vos produits est-il disponible en français ? Via quel canal et sur quelles plages horaires ?

Réponse :

PRE-MNTC-9 - Quelle est la langue par défaut utilisée pour vos communications relatives au support ?

Réponse :

2.6.3 ApprovisionnementPRE-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 ?

Réponse :

2.6.4 Gestion des évolutionsPRE-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.

Réponse :

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 ?

Réponse :

PRE-EVOL-3 - Quelles sont les possibilités / limites d’une gestion d’un parc hétérogène de versions de votre solution ?

Réponse :

PRE-EVOL-4 - Fournissez-vous un outillage particulier permettant de faciliter les montées de version ?

Réponse :

2.6.5 Prise en compte des demandes spécifiquesPRE-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 ?

Réponse :

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 ?

Réponse :



2.6.6 Processus d’escaladePRE-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 ?

Réponse :

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 ?

Réponse :

***


· Web viewChaque passerelle doit pouvoir être accessible via un protocole de prise en main à...

Documents

Transcript of · Web viewChaque passerelle doit pouvoir être accessible via un protocole de prise en main à...