Solution logicielle destinée aux avertissements en cas d'urgence
(SLAU)

Entente sur le commerce : OMC-AMP/ALÉNA/Canada-Pérou
ALE/Canada-Colombie ALE
Processus de demande des soumissions : 
Pièce jointe : Aucune
Stratégie d'approvisionnement non concurrentielle : Droits
exclusifs
Entente sur les revendications territoriales globales : Non
Nom et adresse du fournisseur : 
ERMS Solutions Limited
2916 South Sheridan Way
Suite 200
Oakville Ontario
Canada
L6J7J8
Nature des besoins : 


Transport Canada - PAC pour la platforme ERMS Advantage


Un PAC est un avis public informant la collectivité des
fournisseurs qu'un ministère ou organisme a l'intention
d'attribuer un contrat pour des biens, des services ou des
travaux de construction à un fournisseur sélectionné à l'avance,
ce qui permet aux autres fournisseurs de signaler leur intérêt à
soumissionner en présentant un énoncé des capacités. Si aucun
fournisseur ne présente un énoncé des capacités qui satisfait
aux exigences établies dans le PAC, au plus tard à la date de
clôture indiquée dans le PAC, l'agent de négociation des
contrats peut procéder à l'attribution du contrat au fournisseur
sélectionné à l'avance.


Définition des besoins

Conformément à la Loi sur la sûreté du transport maritime (LSTM)
et au Règlement sur la sûreté du transport maritime (RSTM), il
incombe aux Opérations de la sûreté maritime de Transport Canada
(TC) d'informer immédiatement l'industrie maritime de toute
menace ou de tout événement qui aurait une incidence sur la
sûreté du système de transport maritime canadien, y compris les
installations maritimes, les ports et les bâtiments et les
traversiers. Les Opérations de la sûreté maritime, direction qui
relève de la Direction générale de la sûreté maritime de TC,
sont tenues d'utiliser une solution logicielle destinée aux
avertissements en cas d'urgence (SLAU) pour diffuser des
avertissements si ces menaces ou événements surviennent.

La SLAU fournie par le fournisseur de services doit être en
mesure de diffuser des avertissements de masse à au moins 5 000
intervenants différents, dont des ministères gouvernementaux
(fédéraux et provinciaux), des associations privées, des
entreprises et des particuliers. La SLAU sera utilisée dans les
bureaux régionaux de TC qui se trouvent partout au Canada et par
les autres secteurs de transport à TC comme outil
d'avertissement à l'intention des intervenants de l'industrie et
à des fins de continuité des activités.

TC prévoit entrer dans un marché à fournisseur unique avec ERMS
Corporation afin d'obtenir la suite de plate-forme « ERMS
Advantage » comprenant le service de maintenance et de support,
la formation et des services professionnels.


Critères d'évaluation de l'énoncé des capacités

Tout fournisseur intéressé doit démontrer au moyen d'un énoncé
des capacités que son produit/matériel/système (selon le cas)
satisfait aux exigences suivantes :

1.Expérience

1.1. Expérience: L'entrepreneur doit avoir fourni une SLAU sous
forme d'application hébergée par l'entrepreneur durant au moins
trois ans.			


2. Architecture du service

2.1. Conception du service: La SLAU doit être spécifiquement
conçue pour diffuser des avertissements en cas d'urgence et être
en mesure de diffuser, dans un délai de cinq minutes, des
avertissements de masse à de multiples contacts au moyen de
plusieurs méthodes (de façon simultanée ou en cascade).			

2.2. Conception du service: La SLAU devrait également permettre
l'envoi de messages courants qui se distinguent clairement des
messages d'urgence.

2.3. Régulation du trafic: La SLAU doit avoir la capacité de
contrôler le nombre d'appels qui entrent dans une organisation
pour éviter l'inondation des lignes pendant des avertissements
de masse.		

2.4. Propriété: L'ensemble du matériel, des logiciels et des
données (mis à part ceux qui proviennent des systèmes
appartenant au client) doivent être hébergés au Canada dans les
installations appartenant à l'entrepreneur ou louées par ce
dernier et où les activités et la sécurité sont assurées par
l'entrepreneur.			

2.5. Exigences relatives aux opérations du client: Le client ne
doit pas avoir à installer de matériel ou de logiciels
supplémentaires pour exploiter toutes les facettes de la SLAU.
Il n'est pas chargé de l'achat de dispositifs liés à la capacité
des bases de données, aux voies de transmission de données et
aux ports téléphoniques.			


3. Sécurité

3.1. Normes relatives à la sécurité industrielle: Il incombe au
fournisseur choisi d'être en mesure de gérer et de protéger les
renseignements de cote inférieure ou équivalente à la cote "
PROTÉGÉ A ", conformément aux normes relatives à la sécurité
industrielle de Travaux publics et Services gouvernementaux
Canada. Ces normes s'appliquent à l'ensemble des installations
et du matériel servant à entreposer et à traiter les
renseignements des administrateurs, des utilisateurs et des
contacts et tous les messages.			

3.2. Privilèges d'accès:	La SLAU doit permettre aux
administrateurs de contrôler les privilèges d'accès, dont des
demandes d'accès et des demandes de modification de
renseignements personnels et de mot de passe, pourvu que leurs
autorisations à l'égard du contrôle d'accès soient
appropriées.			

3.3. Modification du mot de passe: La SLAU doit autoriser chaque
administrateur, utilisateur ou contact à changer son mot de
passe à n'importe quel moment.			

3.4. Niveau de sécurité du mot de passe: La SLAU doit obliger
chaque administrateur, utilisateur et contact à configurer un
mot de passe de façon prédéterminée contenant un nombre minimal
de caractères, y compris des majuscules, des chiffres et des
symboles.			


4. Résilience

4.1. Reprise: Les données du client doivent être hébergées dans
des installations à taux élevé de disponibilité dont le temps de
basculement est nul et qui assurent une reprise automatique.			
4.2. Reprise après catastrophe: Si une catastrophe, une urgence
ou un danger empêche le centre de données principal de
l'entrepreneur de fonctionner, les données du client doivent
être réacheminées dynamiquement pour prévenir toute
interruption.			

4.3. Installations et services de sauvegarde: L'architecture de
la SLAU doit être multiniveau, dotée de multiples serveurs,
tolérante aux pannes et avoir une redondance complète; le
serveur de la base de données sur les contacts principaux et
l'ensemble des fonctions de la SLAU sont hébergés au Canada et
les fonctions de sauvegarde sont hébergées dans des endroits
distincts au Canada délimités par une frontière provinciale (au
moins 200 kilomètres) pour empêcher qu'une situation d'urgence
touchant une installation n'ait des effets sur d'autres
installations.			

4.4. Lieu des serveurs de données: La SLAU doit veiller à ce que
la base de données du client ne se trouve jamais à l'extérieur
des frontières terrestres du Canada.			

4.5. Autorisations et contrôles d'accès: La SLAU doit permettre
et appuyer la nomination d'au moins 10 administrateurs
principaux et régionaux ayant, respectivement, un accès complet
et limité. 			


5. Opérations générales

5.1. Interfaces utilisateurs: Le fournisseur veillera à ce que
la SLAU fournisse aux administrateurs et utilisateurs une
interface GUI en anglais et en français.			

5.2. Navigateurs: Les administrateurs et utilisateurs doivent
être en mesure d'accéder à la SLAU par des navigateurs Web, dont
Internet Explorer (version minimale 9.0), Apple Safari (version
minimale 5.1), Google Chrome (version minimale 17.0) et Mozilla
Firefox (version minimale 10.0) pour Windows, compatibles avec
un cryptage de 128 bits.			

5.3. Lancement rapide: La SLAU doit être dotée d'une fonction de
lancement rapide permettant à un administrateur ou utilisateur
d'envoyer un message à partir d'un seul écran après l'ouverture
d'une session.			

5.4. Mode pratique: La SLAU doit avoir un mode pratique (c. à d.
un environnement d'essai) qui permet à un administrateur ou
utilisateur d'utiliser toutes les facettes du service sans
qu'elles aient de répercussions sur le contenu en temps réel ou
sur les fonctions du service et de la base de données (c. à d.
l'environnement de production).			


6. Données sortantes

6.1. Messages vocaux: La SLAU doit permettre l'envoi de messages
vocaux (locaux ou interurbains) qui durent jusqu'à une minute
(qui ne comprend pas la durée de la numérotation, ni de la
sonnerie, ni du message d'accueil de la boîte vocale) à au moins
5 000 contacts, y compris ceux du gouvernement du Canada, dans
les cinq minutes suivant l'envoi.			

6.2. Langue des messages vocaux: Les messages vocaux doivent
être transmis en français et en anglais par des voix ayant un
accent canadien contemporain.			

6.3. Messages textes: La SLAU doit permettre l'envoi de messages
textes d'au moins 140 caractères ou de courriels allant jusqu'à
500 mots à au moins 5 000 contacts, y compris ceux du
gouvernement du Canada, dans les cinq minutes suivant l'envoi.			

6.4. Fiabilité: La SLAU doit être entièrement fonctionnelle et
opérationnelle 24 heures sur 24, 7 jours sur 7 et être
disponible au moins 99,99 % du temps tout au long de la période
prévue au contrat. En cas d'interruption, l'entrepreneur avisera
le client de l'interruption et des effets sur la SLAU. En cas
d'interruption prévue, l'entrepreneur en avisera le client bien
à l'avance.	

6.5 SMS indigène au Canada: La SLAU doit utiliser un code court
pour permettre l'envoi des Service de message court (SMS)
véritables et non pas de courriel à SMS.		


7. Base de données

7.1. Récupération de données: La SLAU doit permettre aux
administrateurs de récupérer une fiche de contact qui a été
supprimée, dans les cinq jours suivant la suppression. 			

7.2. Sauvegarde de la base de données: La SLAU doit effectuer
des sauvegardes automatiques de la base de données à au moins un
endroit au Canada, au moins toutes les 24 heures.			


8. Gestion des renseignements des administrateurs, des
utilisateurs et des contacts

8.1. Profils d'administrateur et d'utilisateur: La SLAU doit
permettre d'établir et de tenir à jour une base de données sur
les profils d'administrateur et d'utilisateur qui comprendront
ce qui suit :
i.	nom complet;
ii.	poste;
iii.	région;
iv.	direction;
v.	numéro d'identification personnel;
vi.	coordonnées principales en cas d'urgence (24 heures);
vii.	coordonnées secondaires en cas d'urgence (24 heures);
viii.	numéro de téléphone cellulaire;
ix.	numéro de télécopieur de l'entreprise;
x.	numéro de téléavertisseur;
xi.	adresse courriel;
xii.	remplaçant désigné;
xiii.	numéro de BlackBerry;
xiv.	autorisations accordées.

La SLAU doit permettre aux administrateurs principaux d'avoir
une autorisation d'accès complet et d'accéder à toutes les
fonctions de la SLAU.			

8.2. Formats d'importation des renseignements sur les contacts:
La SLAU doit permettre d'importer de façon sécuritaire les
renseignements des contacts provenant de bases de données
existantes (fournies au fournisseur dans au moins un fichier
électronique), dont Microsoft Active Directory,
PeopleSoft/Oracle HR, logiciel BCP, SQL, MS SQL Server, NetHris,
base de données HRIS et fichiers CSV (c. à d. Excel), XML, MS
Outlook et MDB - sans aucune intervention manuelle (humaine)
soit nécessaire -, aux moments prévus par le client ou s'il y a
lieu. Le client doit être en mesure d'importer manuellement les
renseignements des contacts, au besoin. Ce processus sera
effectué au moyen d'une interface de programmation
d'applications offrant des services Web qui utilise une
architecture axée sur les services et fondée sur des normes.			

8.3. Champs de données sur les contacts: La SLAU doit permettre
la création de 45 champs de données par fiche.			

8.4. Révision des données: Les administrateurs, utilisateurs et
contacts doivent être en mesure de consulter et de modifier
manuellement les renseignements de leur profil, et ce,
directement dans la SLAU, pourvu qu'ils aient les autorisations
appropriées liées au contrôle d'accès.			

8.5. Révision des données: Les administrateurs et utilisateurs
doivent être en mesure d'ajouter, de modifier et de supprimer
des contacts et des renseignements sur ces derniers, et ce,
directement dans la SLAU, pourvu que les autorisations qui leur
ont été accordées à l'égard du contrôle d'accès soient
appropriées.			

8.6. Données liées à l'ouverture de session: La SLAU doit
attribuer automatiquement un identifiant d'utilisateur  unique 
pour chaque administrateur et utilisateur. L'administrateur doit
alors être autorisés à fixer un mot de passe temporaire qui
peuvent ensuite être modifiés par le titulaire du compte.		


9. Groupes de contacts

9.1. Création: La SLAU doit permettre aux administrateurs et
utilisateurs de créer des groupes de contacts selon des
variables (p. ex. secteur, groupe, région ou tout autre critère
figurant dans les champs de données de la fiche de chaque
contact).			

9.2. Groupes hiérarchiques: Les administrateurs et utilisateurs
doivent être en mesure de créer des groupes hiérarchiques qui
peuvent compter jusqu'à 50 sous-groupes pour refléter
adéquatement la structure d'une organisation.			

9.3. Nombre de groupes: La SLAU doit permettre aux
administrateurs et utilisateurs de désigner un contact comme
membre d'un groupe, et ce, jusqu'à 50 groupes.			

9.4. Fonction de recherche: La SLAU doit permettre aux
administrateurs et utilisateurs d'effectuer une recherche ou de
filtrer les contacts selon des critères figurant dans les champs
de données de la fiche de chaque contact. La SLAU doit également
permettre la création rapide de groupes uniques à l'aide des
résultats découlant de la fonction de recherche.		

9.5. Fonction de tri:	La SLAU doit permettre aux administrateurs
et utilisateurs de trier les contacts par ordre alphabétique ou
selon tout autre critère figurant dans les champs de données de
la fiche de chaque contact. La SLAU doit également permettre la
création rapide de groupes uniques à l'aide des résultats
découlant de la fonction de recherche.

9.6. Tri des intervenants, selon leur langue: La SLAU doit avoir
la capacité de lister les intervenants par la langue de
correspondance afin de permettre l'envoi de messages en français
pour les intervenants francophones et en anglais aux
intervenants anglophones.


10. Création de messages

10.1. Accès au service: La SLAU doit permettre aux
administrateurs et utilisateurs d'accéder aux services de
gestion des contacts, de création de messages (vocaux ou textes)
ou de transmission de messages à l'aide des méthodes et des
appareils suivants :
i.	ordinateur (connexion Internet par câble ou WI FI);
ii.	téléphone conventionnel;
iii.	téléphone cellulaire;
iv.	téléphone intelligent;
v.	assistant numérique personnel;
vi.	appareil de télécommunication pour sourds; 
vii.	voix sur le protocole Internet;
viii.	téléphone satellite.			

10.2. Création de messages: La SLAU doit permettre aux
administrateurs et utilisateurs de créer et d'enregistrer des
messages vocaux et textes en français et en anglais pour usage
actuel ou futur.			

10.3. Personnalisation des messages: La SLAU doit permettre aux
administrateurs et utilisateurs de personnaliser les messages
préenregistrés en ajoutant une phrase d'accueil et de clôture.			

10.4. Vérification des messages: La SLAU doit permettre aux
administrateurs et utilisateurs d'écouter le message vocal et de
lire le message texte avant l'envoi.

10.5 Reconnaissance du Fuseau Horaire: La SLAU doit avoir la
capacité de reconnaître et de comprendre les fuseaux horaires.			


11. Transmission de messages

11.1. Support: La SLAU doit permettre l'envoi de messages à des
contacts au moyen de ce qui suit :
i.	téléphone conventionnel;
ii.	téléphone cellulaire;
iii.	téléphone intelligent, y compris toute communication par
téléphone, par message texte et par courriel;
iv.	assistant numérique personnel;
v.	message texte;
vi.	courriel;
vii.	télécopieur;
viii.	téléavertisseur;
ix.	appareil de télécommunication pour sourds;
x.	téléphone satellite;
xi.	tout autre moyen accessible.			

11.2. Mesures de sécurité: La SLAU doit être dotée d'une mesure
de sécurité efficace (p. ex. message-guide) qui empêche des
messages courants d'être envoyés comme des avertissements en cas
d'urgence.			

11.3. Types de numéros de téléphone: La SLAU doit permettre
d'effectuer des appels locaux et interurbains au Canada et aux
États Unis. Elle doit également permettre de composer des
numéros de téléphone à l'étranger et des numéros assortis d'un
poste.		

11.4. Méthodes d'ordonnance des contacts: La SLAU doit permettre
aux administrateurs et utilisateurs de choisir l'ordre par
défaut des appareils utilisés pour aviser les contacts et aux
utilisateurs et contacts de faire abstraction de l'ordre établi
s'ils ont les autorisations appropriées.			
11.5. Langue des messages et des contacts: La SLAU doit
permettre aux administrateurs et utilisateurs de sélectionner
les messages en français ou en anglais et de les transmettre
automatiquement dans la langue de correspondance présélectionnée
par le contact.			
11.6. Transmission simultanée: La SLAU doit permettre aux
utilisateurs d'envoyer un message vocal enregistré et un message
texte dans un seul avertissement à tous les contacts
sélectionnés au moyen des appareils énumérés au point 11.1.			

11.7. Identification de l'appelant: Que ce soit pour l'ensemble
des messages ou pour un seul message, la SLAU doit permettre aux
administrateurs et utilisateurs qui créent un message de choisir
les paramètres liés à l'affichage du numéro de téléphone
(identification de l'appelant) dans le cas d'un message vocal et
de l'adresse courriel dans le cas d'un message texte.			
11.8. Renvois: La SLAU doit permettre de renvoyer les messages
(trois échelons) lorsque le contact visé n'a pas accusé
réception de la correspondance au cours d'une période donnée. Si
aucun accusé de réception n'est reçu durant une période donnée,
le message sera renvoyé à un autre contact, si ce dernier a été
désigné (voir le point 11.12).			

11.9. Tentatives d'envoi: La SLAU devrait permettre aux
utilisateurs et administrateurs de choisir le nombre de
tentatives d'envoi à l'ensemble des contacts.			

11.10. Pièces jointes aux courriels: Les administrateurs ou
utilisateurs doivent être en mesure de joindre plusieurs
fichiers (p. ex. texte, feuille de calcul et image) aux
courriels et de les envoyer à un appareil permettant de
consulter des courriels.			

11.11. Contrôle des messages: La SLAU doit permettre à un
administrateur ou utilisateur d'interrompre, de reprendre ou de
remplacer un message qu'il a créé ou un message créé par un
autre administrateur ou utilisateur ayant le même niveau
d'autorisations à n'importe quel moment du processus d'envoi.
Pouvons nous préciser ce qu'on entend par " autorisations
correspondantes " ?			

11.12. Contacts de relève: La SLAU doit permettre l'envoi
automatique de messages à un contact de relève si le contact
principal n'accuse pas réception du message initial dans une
période prévue par l'expéditeur.

11.13. Premièrs à réagir: La solution proposée doit avoir la
capacité d'envoyer des avertissments systématiquement jusqu'à ce
qu'un nombre prédéterminé de réponses affirmatives ont été
reçues.

11.14. Appel nominal: La solution proposée doit avoir la
capacité d'envoyer des avertissments dans le but de solliciter
un reponse affirmative ou négative du destinataire, telles que "
Ça va? ", " Ça va pas? "	


12. Caractéristiques liées à l'envoi de messages

12.1. Écoute répétée d'un message vocal: La SLAU doit permettre
aux contacts d'écouter un message vocal aussi souvent qu'ils le
souhaitent en appuyant sur une seule touche.	

12.2. Accusés de réception: La SLAU doit permettre de demander
et de recevoir des accusés de réception de messages transmis au
moyen des appareils mentionnés au point 11.1, à l'exception du
télécopieur, du téléavertisseur et des messages textes.			

12.3. Message envoyé de nouveau: La SLAU doit permettre aux
administrateurs ou utilisateurs de renvoyer un avertissement
uniquement aux contacts qui n'ont pas répondu à l'avertissement
initial.			

12.4. Boîte vocale: La SLAU doit permettre de laisser un message
vocal sur un répondeur ou une boîte vocale. Dans le cas d'un
message laissé sur la boîte vocale du contact principal, la SLAU
doit également permettre de communiquer avec le contact de
relève.			

12.5. Voix électronique: Le transmetteur vocal électronique doit
avoir un accent canadien (en anglais et en français).			

12.6. Réponse personnalisée: La SLAU doit permettre aux contacts
d'envoyer des messages textes personnalisés en réponse aux
messages.			


13. Gestion de messages

13.1. Messages récurrents: La SLAU doit permettre aux
administrateurs et utilisateurs de préparer des messages
récurrents.			

13.2. Calendrier: La SLAU doit permettre aux administrateurs et
utilisateurs de prévoir l'envoi d'un avertissement à une date et
à une heure ultérieures.			

13.3. Boîte vocale: La SLAU doit distinguer une communication
établie avec un contact réel d'un message d'accueil provenant
d'un répondeur ou de la boîte vocale d'un appareil permettant de
transmettre des messages vocaux.			


14. Production de rapports

14.1. Tableau de bord: La SLAU doit fournir un tableau de bord
en temps réel de chaque diffusion active d'avertissement pour
permettre aux administrateurs et utilisateurs de consulter les
paramètres de diffusion (p. ex. appareils, heure de début, durée
et nombre de cycles) et l'état des résultats de diffusion (p.
ex. confirmation et réponses).			

14.2. Historique: Les administrateurs et utilisateurs doivent
être en mesure de consulter l'historique des messages transmis
durant toute la période prévue au contrat.			

14.3. Piste de vérification: La SLAU doit produire des rapports
portant sur les messages diffusés en temps réel à l'aide de
toutes les données d'applications qui contiennent, entre autres,
les renseignements suivants :
i.	nom, date et heure du message;
ii.	nom de l'administrateur ou de l'utilisateur qui est à
l'origine de la diffusion;
iii.	nombre de tentatives de recomposition demandées par le
responsable;
iv.	statistiques sommaires, y compris le nombre total de
contacts avisés, le nombre total d'accusés de réception et le
taux d'accusés de réception. S'il s'agit d'une invitation à
diffuser, le nombre total pour chaque réponse doit être fourni.
Ces renseignements doivent être recueillis pour chaque message
et pour les messages cumulatifs;
v.	renseignements détaillés sur les appels effectués, y compris
les résultats de chaque tentative visée par la diffusion, les
adresses courriel et les numéros de téléphone connexes des
contacts qu'on a tenté de joindre, le numéro auquel on a tenté
d'appeler et le résultat (p. ex. étayé par la date et l'heure,
ligne occupée, aucune réponse ou boîte vocale).			
14.4. Exportation: La SLAU doit exporter tous les types de
données de rapports en format CSV, XLS, HTML ou PDF, tels qu'ils
sont définis par un administrateur ou utilisateur.			

14.5. Impression: La SLAU doit permettre aux administrateurs et
utilisateurs d'imprimer des rapports en temps réel de
l'interface GUI.			

14.6. Rapports: Sur demande, le fournisseur de services est tenu
de rechercher et de générer des rapports fondés sur des critères
établis par l'utilisateur et sur des mots clés, y compris des
recherches à l'aide de caractères de remplacement. De plus, il
incombe au fournisseur de services de conserver un dossier
permanent de tous les rapports.			
			

Applicabilité des accords commerciaux à l'achat

Accord sur le commerce intérieur (ACI)
Accord sur les marchés publics de l'Organisation mondiale du
commerce (AMP-OMC)
Accord de libre-échange nord-américain (ALENA)

    Inscrire, le cas échéant, l'énoncé suivant lorsque l'achat
est réservé en vertu de la Stratégie d'approvisionnement auprès
des entreprises autochtones (SAEA).


Justification du recours à un fournisseur sélectionné à l'avance

ERMS Advantage est une solution de notification et de gestion
d'urgence  commerciale, disponible immédiatement, entièrement
hébergée et basé sur le Web, qui est employée par des organismes
afin de contrôler leurs processus essentiels d 'urgence,
permettant les communications et la gestion efficace des
situations et des incidents de crise. ERMS Advantage soutien les
besoins de notification d'urgence de Transports Canada sans
n'importe quelle configuration additionnelle a leur
infrastructure d'TI.

ERMS  Advantage permettra Transports Canada de contrôler et
maintenir efficacement les informations de contact de ses
intervenants de l'industrie et d'envoyer des avis de menace de
sûreté a partir des installations d'hébergement ERMS qui sont
entièrement redondant et sécurisé. ERMS Advantage est composé de
modules logiciels qui sont indépendants et au même temps
entièrement intégrés partageant une base de données commune. Nos
clients utilisent de divers modules de logiciel de ERMS, en même
temps que la téléphonie de ERMS et les services "messages", pour
accéder et employer les données de contact des intervenants pour
créer exécutez et contrôlez les campagnes de notifications et
restez au courant dans des situations de crise. Les données des
intervenants peuvent être importées par plusieurs méthodes, y
compris les dossiers de .csv et peuvent être courues d'un seul
trait, ou d'une manière cumulative. A travers les API flexibles
de ERMS, il est également possible d'intégrer la solution
Advantage avec pratiquement n'importe quel logiciel de tiers (p.
ex. PeopleSoft) pour les mises à jour automatiques de données. 

L'Access et le contrôle est accompli par un certain nombre de
sauvegardes avancées comprenant ; utilisation des mots de passe
(NIP), les contrôles d'accès autorisés fonctionnels, les droites
de reçu et la participation et d'autres protocoles de sécurité.
Les rôles prédéfinis existent dans la solution comprenant les
administrateurs du système (accès à toute la fonctionnalité du
système), les " agents " (indiqués des directeurs de campagne de
notification désigné) et les intervenants (destinataires de
notification). De plus, chaque type de rôle peut être adapté aux
besoins du client pour permettre ou interdire l'accès aux
capacités spécifiques et aux modules.

ERMS Advantage  est " un service partagé " du fait que beaucoup
de clients partagent l'infrastructure; ce qui réduit le coût par
client au niveau le plus bas possible tout en fournissant la
plus grande quantité de ressources possibles. La base de données
" carte d'organisation " et toute autre information spécifique
du client sont protégées d'une maniere securitaire pour être
conformes aux besoins du client et aux exigences réglementaires
de confidentialité.


Exception(s) au Règlement sur les marchés de l'État

L'article6 du Règlement sur les marchés de l'État est invoqué
relativement à ce marché d'approvisionnement puisqu'il marché ne
peut être exécuté que par une seule personne ou entreprise.


Exclusions et/ou raisons justifiant le recours à l'appel
d'offres limité

L'alinéa506.12b) de l'annexe4.4 de l'ACI s'applique pour
justifier le recours à un appel d'offres restreint lorsque, pour
des raisons d'ordre technique, il y a absence de concurrence et
que les produits ou services ne peuvent être fournis que par un
fournisseur donné et qu'il n'existe aucune solution de rechange
ou encore de produits ou services de remplacement.

L'alinéa1016.2b) de l'ALENA s'applique pour justifier le recours
à un appel d'offres restreint lorsque, du fait qu'il s'agit de
travaux d'art ou pour des raisons liées à la protection de
brevets, de droits d'auteur ou d'autres droits exclusifs ou de
renseignements de nature exclusive, ou en l'absence de
concurrence pour des raisons techniques, les produits ou
services ne pourront être fournis que par un fournisseur
particulier et qu'il n'existera aucun produit ou service de
rechange ou de remplacement raisonnablement satisfaisant.

L'alinéaXV(b) de l'AMP-OMC s'applique pour justifier le recours
à un appel d'offres restreint lorsque, du fait qu'il s'agit de
travaux d'art ou pour des raisons liées à la protection de
droits exclusifs, tels que des droits de brevet ou de
reproduction, ou en l'absence de concurrence pour des raisons
techniques, les produits ou services ne pourront être fournis
que par un fournisseur particulier et qu'il n'existera aucun
produit ou service de rechange ou de remplacement
raisonnablement satisfaisant.


Titre de propriété intellectuelle

Le titre de propriété intellectuelle découlant du contrat
proposé reviendra à l'entrepreneur.


Période du contrat proposé ou date de livraison

Le contrat proposé est pour une période de 1 ans qui inclut 4
options d'une année supplémentaires. Toute la livraison
mentionnée dans la definition du besoin sera fournie dans les 10
jours suivant l'attribution du contrat.

        

Nom et adresse du fournisseur sélectionné à l'avance 

ERMS Solutions Limited, Oakville, Ontario, Canada


Droit des fournisseurs de présenter un énoncé des capacités
 Les fournisseurs qui estiment être pleinement qualifiés et
prêts à fournir les biens, les services ou des services de
construction décrits dans ce PAC peuvent présenter par écrit un
énoncé des capacités à la personne-ressource dont le nom figure
dans cet avis d'ici la date de clôture, laquelle est aussi
précisée dans cet avis. L'énoncé de capacités doit clairement
démontrer que le fournisseur satisfait aux exigences publiées.

L'énoncé des capacités doit clairement démontrer comment le
fournisseur répond aux exigences faites dans l'énoncé du besoin.

Les conditions de la licence de logiciel du développeur sont
inacceptables à l'État. Ce logiciel est de type «propriétaire»,
et l'entrepreneur proposé doit pouvoir négocier les modalités du
marché et de la licence de logiciel connexe y compris, entre
autres choses, les limites de responsabilité, l'indemnisation,
la transférabilité, l'annulation et le remboursement à l'État.

Tout les documents peuvent être soumis dans l'un ou l'autre de
langue officielle de Canada


Demande de renseignements et présentation des énoncés des
capacités

Les demandes de renseignements et les énoncés des capacités
doivent être adressés à :

Jonathan Vinet
Chef D'équipe d'approvisionnement p.i.
Travaux publics et Services gouvernementaux Canada
Gatineau, Québec, Canada (K1A 0S5)
Jonathan.vinet@tpsgc-pwgsc.gc.ca
Téléphone 819-956-2940
Télécopieur 819-953-3703 
Gouvernement du Canada

Date de livraison : Indiquée ci-dessus

L'État fait savoir par la présente qu'il a l'intention de
n'inviter à soumissionner que l'entreprise susmentionnée et de
ne négocier qu'avec elle.  Pour de plus amples renseignements
concernant ce marché, communiquer avec l'agent de négociation
des marchés dont le nom est indiqué ci-dessus.

Un préavis d'adjudication de contrat (PAC) permet aux ministères
et aux organismes de publier un avis, pendant un minimum de
quinze (15) jours civils, pour informer la collectivité des
fournisseurs de leur intention de passer un marché pour un bien,
un service ou des travaux de construction à un fournisseur
sélectionné d'avance. Si pendant la période d'affichage, aucun
fournisseur ne présente d'énoncé de compétences répondant aux
exigences précisées dans le PAC, l'agent de négociation des
marchés pourra alors procéder à l'attribution du marché. S'il
est jugé, toutefois, qu'un énoncé de compétences répond aux
exigences précisées dans le PAC, l'agent de négociation des
marchés doit lancer le processus complet d'appel d'offres.

Les fournisseurs qui estiment être pleinement qualifiés et prêts
à fournir les produits ou les services décrits dans cet avis
peuvent présenter un énoncé de compétences à la
personne-ressource dont le nom figure dans le présent avis d'ici
la date de clôture, laquelle est aussi précisée dans l'avis.
L'énoncé de compétences doit démontrer clairement la façon dont
le fournisseur compte s'y prendre pour répondre aux exigences
indiquées dans le préavis.

Le numéro de dossier de TPSGC, le nom de l'agent de négociation
des marchés et la date de clôture du préavis d'adjudication de
contrat (PAC) doivent figurer en lettres moulées sur
l'enveloppe, ou sur la feuille d'accompagnement, s'il s'agit
d'un envoi par télécopieur.

L'État se réserve le droit de négocier les conditions de tout
marché avec les fournisseurs.

Les documents peuvent être présentés dans l'une ou l'autre des
langues officielles du Canada.