PAC POUR UNE SOLUTION LOGICIELLE DESTINÉE AUX AVERTISSEMENTS EN CAS D’URGENCE HORS SITE (SLAUHS)

Entente sur le commerce : ALÉNA/ACI/et les ALE entre Canada et Pérou/Colombie/Panama
Processus de demande des soumissions : Tout fournisseur intéressé peut présenter une soumission
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 : 

Pour obtenir d’autres renseignements sur ce préavis d’adjudication de contrat ou une copie des critères d’évaluation de l’énoncé de capacités, veuillez communiquer avec l’autorité contractante suivante :

Ivy Pui
819-956-1560
Ivy.pui@tpsgc-pwgsc.gc.ca


SOLUTION LOGICIELLE DESTINÉE AUX AVERTISSEMENTS EN CAS D’URGENCE HORS SITE (SLAUHS) - PLATEFORME ERMS ADVANTAGE

Un préavis d’adjudication de contrat (PAC) est un avis public informant la collectivité des fournisseurs qu’un ministère ou un 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é de capacités. Si aucun fournisseur ne présente un énoncé de capacités qui satisfait aux exigences établies dans le PAC au plus tard à la date limite indiquée dans ce dernier, l’agent de négociation des marchés peut procéder à l’attribution du contrat au fournisseur sélectionné à l’avance.


DÉFINITION DU BESOIN POUR LE CONSEIL NATIONAL DE RECHERCHES DU CANADA

Le Conseil national de recherches du Canada (CNRC) est responsable de nombreux sites dans l’ensemble du pays et, à ce titre, il existe un besoin pour communiquer efficacement avec les contacts clés pendant une urgence ou un événement de planification de la continuité des opérations (PCO).

La capacité du CNRC de réagir à des situations de crise, notamment à des catastrophes naturelles et accidentelles, peut avoir des conséquences pour ses partenaires de l’industrie et ses collaborateurs ainsi que pour la population canadienne.

Le CNRC doit mettre en œuvre une solution logicielle destinée aux avertissements en cas d’urgence hors site (SLAUHS) afin de diffuser les avertissements de tels événements ou menaces. La SLAUHS fournie par le fournisseur de services doit permettre la diffusion des avertissements de menaces, d’urgences ou d’événements de PCO à au moins 4 800 intervenants différents. 

Le système servira à communiquer avec les employés, les partenaires, les stagiaires, les travailleurs invités, les entrepreneurs et les locataires du CNRC. 

Le CNRC a l’intention de conclure un contrat à fournisseur unique avec la société ERMS Solutions Limited pour se procurer la plateforme ERMS Advantage, y compris le service de soutien et de maintenance connexe, la formation et les services professionnels.

 
CRITÈRES D’ÉVALUATION DE L’ÉNONCÉ DE CAPACITÉS

Les fournisseurs intéressés doiventdémontrer, au moyen d’un énoncé de capacités, que leurs produits et services satisfont aux exigences suivantes.

EXIGENCES GÉNÉRALES OBLIGATOIRES

O1.
La SLAUHS proposée doit, pour répondre à la présente exigence, être un logiciel commercial, ce qui signifie que chaque élément de logiciel est offert sur le marché, n’exige aucune recherche ni aucun développement supplémentaire et fait partie intégrante d’une gamme de produits existante dont le fonctionnement est éprouvé (c.-à-d., qui n’a pas simplement fait l’objet d’essais en laboratoire ou dans un environnement expérimental).

O2.
Le fournisseur accepte de fournir au Canada une solution logicielle destinée aux avertissements en cas d’urgence hors site (SLAUHS) qui constitue un environnement informatique sécurisé, authentifié et fiable situé au Canada en tout temps; toutes les étapes de la préproduction, de la production et de la postproduction doivent se faire au Canada dans un environnement de niveau Protégé A pendant au moins trois ans.

EXIGENCE ESSENTIELLE RELATIVE AU FOURNISSEUR

O3.
Le fournisseur doit avoir livré un système d’avertissement d’urgence comme application hébergée depuis au moins trois ans.

EXIGENCES EN MATIÈRE d’architecture de services

O4.
La SLAUHS 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).

O5.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de contrôle du nombre d’appels vers une organisation pour éviter d’inonder les lignes pendant un avertissement de masse.

O6.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de diffusion des avertissements de masse à au moins 4 800 intervenants différents, dont des ministères fédéraux, des entreprises et des particuliers.

O7.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de l’envoi de messages courants qui se distinguent clairement des messages d’urgence.

O8.
L’ensemble du matériel, des logiciels et des données doivent être hébergés au Canada dans des installations acquises ou louées et où les activités et la sécurité sont assurées en tout temps dans un environnement Protégé A.

O9.
Le client doit pouvoir utiliser toutes les fonctionnalités du système sans aucune installation de matériel ou de logiciel. 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.

EXIGENCES EN MATIÈRE DE SÉCURITÉ

O10.
Il incombe au fournisseur d’être en mesure de gérer et de protéger les renseignements de niveau inférieur ou équivalent à Protégé A dans l’ensemble des installations et du matériel servant à entreposer et à traiter les renseignements des administrateurs, des utilisateurs et des contacts et les messages.

O11.
La SLAUHS doit permettre aux administrateurs de contrôler les privilèges d’accès, dont les demandes d’accès et les demandes de modification de renseignements personnels et de mot de passe, pourvu qu’ils disposent des autorisations d’accès nécessaires.

O12.
La SLAUHS doit permettre à chaque administrateur, utilisateur ou contact dechanger son mot de passe à n’importe quel moment.

O13.
La SLAUHS doit permettre d’obliger chaque administrateur, utilisateur et contact à configurer d’une manière préétablie un mot de passe comportant un nombre minimal de caractères, y compris des majuscules, des chiffres et des symboles.

EXIGENCES EN MATIÈRE DE RÉSILIENCE

O14.
Le fournisseur doit être en mesure d’héberger les données du client dans des installations à taux élevé de disponibilité dont le temps de basculement est nul et qui assurent une reprise automatique.

O15.
Si une catastrophe, une urgence ou un danger empêche le centre de données principal de l’entrepreneur de fonctionner, la SLAUHS doit être en mesure de réacheminer dynamiquement les données du client afin de prévenir toute interruption.

O16.
L’architecture de la SLAUHS doit être multiniveau, dotée de multiples serveurs et tolérante aux défaillances et posséder une redondance intégrale. De plus, le serveur de la base de données des contacts de premier niveau ainsi que toutes les fonctions de la solution doivent être hébergés au Canada, tandis que leurs fonctions de sauvegarde doivent l’être 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 ait des répercussions sur d’autres installations.

O17.
Le fournisseur doit veiller à ce que la base de données du client ne se trouve jamais à l’extérieur des frontières terrestres du Canada.

O18.
La SLAUHS doit permettre la nomination d’au moins 10 administrateurs principaux et régionaux disposant respectivement d’un accès complet et limité.

EXIGENCES GÉNÉRALES EN MATIÈRE D’UTILISATION

O19.
La SLAUHS doit fournir aux administrateurs et aux utilisateurs une interface utilisateur graphique (GUI) en anglais et en français.

O20.
Les administrateurs et utilisateurs doivent être en mesure d’accéder à la SLAUHS au moyen de navigateurs Web, dont Internet Explorer (version 9.0 ou ultérieure), Google Chrome et Mozilla Firefox pour Windows, compatibles avec un chiffrement de 128 bits.

O21.
La SLAUHS doit être dotée d’une fonction de lancement rapide permettant à un administrateur d’envoyer un message à partir d’un seul écran après l’ouverture d’une session.

O22.
La SLAUHS doit proposer des modes d’entraînement (c’est-à-dire un environnement d’essai) permettant aux administrateurs et aux utilisateurs d’utiliser toutes les fonctionnalités de la solution sans qu’elles aient de répercussions sur le contenu ou les fonctions en temps réel de l’environnement de production.

EXIGENCES RELATIVES AUX MESSAGES SORTANTS

O23.
La SLAUHS doit permettre l’envoi de messages vocaux (locaux ou interurbains) pouvant durer jusqu’à une minute (sanscompter la durée de la numérotation, de la sonnerie et du message d’accueil de la boîte vocale) à au moins 4 800 contacts, y compris ceux du gouvernement du Canada, dans les cinq minutes suivant l’envoi.

O24.
La SLAUHS doit permettre l’envoi de messages vocaux en français et en anglais par des voix ayant un accent canadien contemporain.

O25.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de l’envoi de messages textes d’au moins 140 caractères ou de courriels allant jusqu’à 500 mots à au moins 4 800 contacts, y compris ceux du gouvernement du Canada, dans les cinq minutes suivant l’envoi.

O26.
La SLAUHS doit être entièrement fonctionnelle et opérationnelle 24 heures sur 24, 7 jours sur 7, avec un taux de disponibilité d’au moins 99,99 % 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 répercussions sur la SLAUHS. En cas d’interruption prévue, l’entrepreneur doit en aviser le client bien à l’avance.

O27.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de l’utilisation d’une composition abrégée afin de rendre possible l’envoi de messages textes réels plutôt que de courriels aux messages textes.

EXIGENCES RELATIVES À LA BASE DE DONNÉES

O28.
La SLAUHS doit permettre aux administrateurs de récupérer une fiche de contact qui a été supprimée dans les cinq jours suivant la suppression.

O29.
La SLAUHS doit effectuer des sauvegardes automatiques de la base de données à au moinsun endroit au Canada, au moins toutes les 24 heures.

EXIGENCES RELATIVES AU STOCKAGE DES COORDONNÉES

O30.
La SLAUHS doit permettre d’établir et de tenir à jour une base de données sur les profils d’administrateur et d’utilisateur qui comprendrontce qui suit :

nom complet;
poste;
région;
direction générale;
numéro d’identification personnel;
coordonnées principales en cas d’urgence (24 heures);
coordonnées secondaires en cas d’urgence (24 heures);
numéro de cellulaire;
numéro de télécopieur;
numéro de téléavertisseur;
adresse courriel;
remplaçant désigné;
numéro de BlackBerry;
autorisations accordées.

O31.
La SLAUHS doit permettre aux administrateurs principaux d’avoir une autorisation d’accès complet et d’accéder à toutes ses fonctions.

O32.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de l’importation  de façon sécuritaire les coordonnées des contacts provenant de bases de données existantes (transmises au fournisseur dans au moins un fichier électronique), dont Microsoft Active Directory, PeopleSoft/Oracle HR, logiciel BCP, SQL, MS SQL Server, fichiers CSV (p. ex. Excel), XMS, MS Outlook et fichiers MDB - sans aucune intervention manuelle (humaine) -, aux moments prévus par le client ou au besoin. Le client doit être en mesure d’importer manuellement les coordonnées des contacts, au besoin. Ce processus sera effectué à l’aide d’une interface de programmation Web qui utilise une architecture orientée services fondée sur des normes.

O33.
La SLAUHS doit permettre, offrir et appuyer la fonctionnalité de la création de 45 champs de données par fiche.

O34.
La SLAUHS doit permettre aux administrateurs, aux utilisateurs et aux contacts de consulter et de modifier manuellement les renseignements deleur profil, et ce, directement dans la solution, pourvu qu’ils disposent des autorisations d’accès nécessaires.

O35.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs d’ajouter, de modifier et de supprimer des contacts et leurs coordonnées, et ce, directement dans la solution, pourvu qu’ils disposent des autorisations d’accès nécessaires.

O36.
La SLAUHS doit pouvoir attribuer automatiquement un nom d’utilisateur et un mot de passe uniques à chaque administrateur et utilisateur. L’administrateur doit ensuite pouvoir créer un mot de passe temporaire que le détenteur du compte pourra ensuite modifier.

EXIGENCES LIÉES AUX GROUPES DE CONTACTS

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

O38.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de créer des groupes hiérarchiques qui peuvent compter jusqu’à 50 sous-groupes pour refléter adéquatement la structure d’une organisation.

O39.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de désigner un contact comme membre de jusqu’à 50 groupes.

O40.
La SLAUHS doit permettre aux administrateurs et aux 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 SLAUHS doit également permettre la création rapide de groupes uniques à l’aide des résultats découlant de la fonction de recherche.

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

O42.
La SLAUHS doit permettre d’énumérer les intervenants par langue decorrespondance afin de rendre possible l’envoi de messages en français aux intervenants francophones et en anglais aux intervenants anglophones.

EXIGENCES RELATIVES À LA CRÉATION DE MESSAGES

O43.
La SLAUHS doit permettre aux administrateurs et aux 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 câblée ou Wi-Fi);
ii) téléphoneconventionnel;
iii) téléphone cellulaire;
iv) téléphone intelligent;
v) assistant numérique personnel;
vi) appareil de télécommunication pour personnes malentendantes; 
vii) voix sur le protocole Internet;
viii) téléphone satellite. 

O44.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de créer et d’enregistrer des messages vocaux et textes en français et en anglais pour un usage immédiat ou ultérieur.

O45.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de personnaliser les messages préenregistrés en y ajoutant une phrase d’accueil et de clôture.

O46.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs d’écouter le message vocal et de lire le message texte avant l’envoi.

O47.
La SLAUHS doit permettre de reconnaître et de comprendre les fuseaux horaires.

EXIGENCES RELATIVES À LA TRANSMISSION DE MESSAGES

O48.
La SLAUHS doit pouvoir envoyer des messages aux contacts au moyen des supports suivants :
ii) téléphone conventionnel;
ii) téléphone cellulaire;
iii) téléphone intelligent, y compris les communications téléphoniques, les messages textes et les courriels;
iv) assistant numérique personnel;
v) message texte;
vi) courriel;
vii) télécopieur;
viii) téléavertisseur;
iv) appareil de télécommunication pour personnes malentendantes;
x) téléphone satellite.

O49.
La SLAUHS 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.

O50.
La SLAUHS 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 internationaux et des numéros assortis d’un poste.

O51.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de choisir l’ordre par défaut des appareils utilisés pour aviser les contacts. Elle doit également permettre aux utilisateurs et aux contacts de faire abstraction de l’ordre établi s’ils ont les autorisations appropriées.

O52.
La SLAUHS doit permettre aux administrateurs et aux 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 parle contact.

O53.
La SLAUHS 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 de tous les supports.

O54.
Que ce soit pour l’ensemble des messages ou pour un seul message, la SLAUHS doit permettre aux administrateurs et aux 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, etde l’adresse courriel dans le cas d’un message texte.

O55.
La SLAUHS 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 pendant une période donnée, le message doit être renvoyé à un autre contact désigné, le cas échéant (voir l’exigence O52).

O56.
La SLAUHS doit permettre aux utilisateurs et aux administrateurs de choisir le nombre de tentatives d’envoi à l’ensemble des contacts. 

O57.
La SLAUHS doit permettre 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.

O58.
La SLAUHS doit permettre à un administrateur ou à un 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, et ce, à n’importe quel moment du processus d’envoi.

O59.
La SLAUHS 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.

O60.
La SLAUHS doit permettre l’envoi systématique d’avertissements jusqu’à ce qu’un nombre prédéterminé de réponses affirmatives soient reçues.

O61.
La SLAUHS doit permettre l’envoi d’avertissements sollicitant une réponse positive ou négative de la part du destinataire, comme « Est-ce que tout va bien? » ou « Ça ne va pas. »

EXIGENCES RELATIVES AUX CARACTÉRISTIQUES D’ENVOI DE MESSAGES

O62.
La SLAUHS doit permettre aux contacts d’écouter un message vocal aussi souvent qu’ils le souhaitent en appuyant sur une seule touche.

O63.
La SLAUHS doit permettre de demander et de recevoir des accusés de réception de messages transmis au moyen des supports mentionnés plus haut, à l’exception du télécopieur, du téléavertisseur et des messages textes.

O64.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de renvoyer un avertissement uniquement aux contacts qui n’ont pas répondu à l’avertissement initial.

O65.
La SLAUHS 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 solution doit également permettre de communiquer avec le contact de relève.

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

O67.
La SLAUHS doit permettre aux contacts d’envoyer des messages textes personnalisés en réponse aux messages.

EXIGENCES RELATIVES À LA GESTION DES MESSAGES

O68.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de préparer des messages récurrents.

O69.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs de prévoir l’envoi d’un avertissement à une date et à une heure ultérieures.

O70.
La SLAUHS 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.

EXIGENCES EN MATIÈRE DE RAPPORTS

O71.
La SLAUHS doit fournir un tableau de bord en temps réel de chaque diffusion active d’avertissement, de façon à permettre aux administrateurs et aux 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).

O72.
LaSLAUHS doit permettre aux administrateurs et aux utilisateurs de consulter l’historique des messages transmis pendant toute la période prévue au contrat.

O73.
La SLAUHS 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 l’auteur de la diffusion;
iv) statistiques sommaires, y compris le nombre total de contacts avisés ainsi que le nombre total et le taux d’accusés de réception. S’il s’agit d’une invitation à diffuser, le nombre total de chaqueréponse doit être fourni. On doit recueillir les statistiques de chaque message et des messages cumulatifs;
v) information détaillée des appels, y compris le résultat de chaque tentative d’appel de la transmission concernée, les adresses et les numérosde téléphone associés que le système a tenté de rejoindre, le nombre de tentatives et le résultat (p. ex., confirmé avec date et heure, occupé, aucune réponse ou messagerie vocale).

O74.
La SLAUHS doit pouvoir 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 un utilisateur.

O75.
La SLAUHS doit permettre aux administrateurs et aux utilisateurs d’imprimer des rapports en temps réel directement à partir de l’interfaceGUI.

O76.
Sur demande, le fournisseur doit être en mesure 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 d’effectuer des recherches à l’aide de caractères génériques. De plus, il incombe au fournisseur de conserver un dossier permanent de tous les rapports.


APPLICATION DES ACCORDS COMMERCIAUX À L’ACHAT

- Accord sur le commerce intérieur (ACI)
- Accord de libre-échange nord-américain (ALENA)


JUSTIFICATION DU RECOURS À UN FOURNISSEUR SÉLECTIONNÉ À L’AVANCE

ERMS Advantage est une solution de gestion et d’avertissement d’urgence commerciale, entièrement hébergée et fondée sur le Web utilisée par des organisations afin de gérer leurs processus vitaux d’urgence,de permettre des communications efficaces et de gérer les situations de crise et les incidents. ERMS Advantage appuie les exigences du CNRC en matière d’avertissements d’urgence, sans configuration supplémentaire de son infrastructure de TI.

ERMS Advantage permettra au CNRC de gérer et de tenir à jour efficacement les données des contacts auto-enregistrés et d’émettre des avertissements sur les menaces pour la sécurité dans des installations d’hébergement entièrement redondantes et protégées. 

ERMS Advantage répond entièrement aux exigences du CNRC relatives à un système bilingue (anglais et français) d’avertissement d’urgence de masse selon les critères énoncés.

ERMS Advantage répond entièrement aux exigences en matière de sécurité du CNRC relativement à une solution hébergée au niveau Protégé A. 


EXCEPTION AU RÈGLEMENT SUR LES MARCHÉS DE L’ÉTAT

L’article 6 du Règlement sur les marchés de l’État est invoqué dans le cadre de cet achat, car une seule personne ou entreprise est en mesure d’exécuter le contrat.


EXCLUSIONS OU MOTIFS JUSTIFIANT LE RECOURS À L’APPEL D’OFFRES LIMITÉ

L’alinéa 506.12(b) de l’annexe 4.4 de l’ACI est applicable en fonction de l’appel d’offres limité, car 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 de services de remplacement, respectivement.

L’alinéa 1016.2(b) de l’ALENA est applicable en fonction de l’appeld’offres limité, car, 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

Tout titre de propriété intellectuelle d’aval découlant de l’exécution du marché proposé demeurera celui de l’entrepreneur.



PÉRIODE DU CONTRAT PROPOSÉ OU DATE DE PRESTATION

Le contrat proposé est d’une période d’un (1) an, plus quatre (4) options irrévocables d’un an chacune. Toute prestation mentionnée dans l’exigence doit être exécutée dans un délai de 10 jours à partir de l’attribution du contrat.


NOM ET ADRESSE DU FOURNISSEUR SÉLECTIONNÉ À L’AVANCE

ERMS Solutions Limited
2916, chemin Sheridan Sud, bureau 300
Oakville (Ontario)  L6J 7J8


DROIT DES FOURNISSEURS DE PRÉSENTER UN ÉNONCÉ DE CAPACITÉS

Les fournisseurs qui se jugent entièrement qualifiés et qui sont disponibles pour fournir les biens, les services ou les travaux de construction décrits dans le PAC peuvent présenter par écrit un énoncé de capacités à la personne-ressource dont le nom figure dans le présent préavis, au plus tard à la date de clôture du préavis.  L’énoncé de capacités doit clairement démontrer comment le fournisseur répond aux exigences indiquées.

L’État n’accepte pas les modalités de la licence d’adhésion par déballage du réalisateur. Ce logiciel est propriétaire et l’entrepreneur proposé doit être autorisé à négocier les conditions du contrat, ainsi que les conditions de la licence logicielle connexe, y compris, entre autres, la limitation de responsabilité, l’indemnité, la cession de licence, la résiliation ou le remboursement à l’État. Les documents peuvent être présentés dans l’une ou l’autre des langues officielles du Canada.


DEMANDES DE RENSEIGNEMENTS ET PRÉSENTATION DES ÉNONCÉS DE CAPACITÉS

Les demandes de renseignements et les énoncés de capacités doivent être envoyés à l’adresse suivante :

Ivy Pui
Autorité contractante
Travaux publics et Services gouvernementaux Canada
Gatineau (Québec) Canada  K1A 0S5
ivy.pui@tpsgc-pwgsc.gc.ca
Téléphone : 819-956-1560
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.