Décisions

---

---

TABLE DES MATIÈRES

• DÉCISION DU TRIBUNAL
• EXPOSÉ DES MOTIFS
• • PLAINTE
  • PROCÉDURE DE PASSATION DU MARCHÉ PUBLIC
  • POSITION DES PARTIES
  • • Position de TPSGC
    • Position d'ENI
  • DÉCISION DU TRIBUNAL
  • DÉCISION DU TRIBUNAL

---

Ottawa, le jeudi 27 décembre 2001

Dossier n^o PR-2001-025

EU ÉGARD À une plainte déposée par Empowered Networks Inc. aux termes du paragraphe 30.11(1) de la Loi sur le Tribunal canadien du commerce extérieur, L.R.C. 1985 (4^e supp.), c. 47;

ET EU ÉGARD À une décision d'enquêter sur la plainte aux termes du paragraphe 30.13(1) de la Loi sur le Tribunal canadien du commerce extérieur.

DÉCISION DU TRIBUNAL

Aux termes de l'article 30.14 de la Loi sur le Tribunal canadien du commerce extérieur, le Tribunal canadien du commerce extérieur détermine que la plainte n'est pas fondée.

Michel P. Granger
Michel P. Granger
Secrétaire

L'exposé des motifs suivra à une date ultérieure.
 
 

Date de la décision :	Le 27 décembre 2001
Date des motifs :	Le 8 janvier 2002
Membre du Tribunal :	Zdenek Kvarda, membre présidant
Gestionnaire de l'enquête :	Paule Couët
Conseiller pour le Tribunal :	Eric Wildhaber
Partie plaignante :	Empowered Networks Inc.
Conseiller pour la partie plaignante :	Nancy K. Brooks
Institution fédérale :	Ministère des Travaux publics et des Services gouvernementaux
Conseillers pour l'institution fédérale :	Susan D. Clarke
	Christianne Laizner

 
 
Ottawa, le mardi 8 janvier 2002

Dossier n^o PR-2001-025

EU ÉGARD À une plainte déposée par Empowered Networks Inc. aux termes du paragraphe 30.11(1) de la Loi sur le Tribunal canadien du commerce extérieur, L.R.C. 1985 (4^e supp.), c. 47;

ET EU ÉGARD À une décision d'enquêter sur la plainte aux termes du paragraphe 30.13(1) de la Loi sur le Tribunal canadien du commerce extérieur.

EXPOSÉ DES MOTIFS

PLAINTE

Le 13 août 2001, Empowered Networks Inc. (ENI) a déposé une plainte auprès du Tribunal canadien du commerce extérieur (le Tribunal) aux termes du paragraphe 30.11(1) de la Loi sur le Tribunal canadien du commerce extérieur ¹ à l'égard du marché public (invitation n^o M93980-012711/A) passé par le ministère des Travaux publics et des Services gouvernementaux (TPSGC) pour la fourniture d'un logiciel de gestion et de contrôle de réseau, y compris des services de formation optionnels, des services de maintenance et de soutien ainsi que des mises à niveau pour la Gendarmerie royale du Canada (GRC).

ENI a allégué que certains facteurs d'évaluation que renfermait la demande de propositions (DP) étaient ambigus ou imprécis et que certains critères d'évaluation ont été appliqués par erreur dans l'évaluation financière et technique. Plus précisément, ENI a allégué que des prix présentés dans sa proposition à l'égard de la formation ont été inclus dans le prix évalué, contrairement à ce que précisaient les procédures d'évaluation énoncées dans la DP, et que sa soumission n'a pas reçu de points à l'égard d'une exigence cotée parce que des critères d'évaluation inexacts et ambigus ont été utilisés dans l'évaluation technique.

ENI a demandé, à titre de mesure corrective, que toutes les soumissions conformes soient réévaluées, que les corrections appropriées soient apportées à l'évaluation de sa proposition et que le contrat adjugé à InfoVista Corporation (InfoVista) soit résilié et attribué à ENI à titre de soumissionnaire ayant obtenu la note globale la plus élevée sur le plan du mérite technique et du coût.

Le 20 août 2001, le Tribunal a avisé les parties qu'il avait décidé d'enquêter sur la plainte, puisque cette dernière répondait aux exigences du paragraphe 30.11(2) de la Loi sur le TCCE et aux conditions énoncées au paragraphe 7(1) du Règlement sur les enquêtes du Tribunal canadien du commerce extérieur sur les marchés publics ² . Le 28 septembre 2001, TPSGC a déposé un rapport de l'institution fédérale (RIF) auprès du Tribunal en application de l'article 103 des Règles du Tribunal canadien du commerce extérieur ³ . Le 12 octobre 2001, ENI a déposé ses observations sur le RIF auprès du Tribunal. Le 19 octobre 2001, TPSGC a déposé son exposé sur les observations d'ENI sur le RIF et, le 1^er novembre 2001, ENI a déposé ses observations en réponse.

La quantité de renseignements au dossier étant suffisante pour déterminer le bien-fondé de la plainte, le Tribunal a décidé qu'une audience n'était pas nécessaire et a statué sur la plainte sur la foi des renseignements au dossier.

PROCÉDURE DE PASSATION DU MARCHÉ PUBLIC

Le 19 mars 2001, TPSGC a reçu de la GRC une demande pour une solution logicielle de gestion et de contrôle de réseau destinée à surveiller le Réseau des services nationaux de police⁴ . Le 20 avril 2001, un avis de projet de marché et une DP portant la date de clôture du 30 mai 2001 ont été publiés sur le Service électronique d'appel d'offres du Canada (MERX). Le marché public était assujetti aux dispositions de l'Accord de libre-échange nord-américain ⁵ , de l'Accord sur les marchés publics ⁶ et de l'Accord sur le commerce intérieur ⁷ .

Au total, six clarifications ont été émises pendant la période de présentation des soumissions afin de répondre à des questions des fournisseurs et d'apporter des révisions mineures à la DP. Au total, sept propositions ont été reçues à la date de fermeture. L'évaluation des propositions techniques a été effectuée entre le 1^er juin et le 17 juillet 2001. Quatre propositions ont été jugées non conformes aux exigences obligatoires et une autre n'a pas obtenu la note globale minimale de passage de 60 p. 100. On a invité les deux derniers soumissionnaires à installer leur logiciel sur place afin d'effectuer un essai de validation. Les deux soumissionnaires, dont ENI, ont réussi à l'étape de validation. Une fois l'évaluation financière terminée, on a attribué une cote pour le mérite technique et calculé le coût de chaque proposition. La proposition d'ENI s'est classée seconde.

Dans une lettre du 27 juillet 2001⁸ , TPSGC a informé les soumissionnaires qu'un contrat avait été adjugé à InfoVista, du Maryland, pour un montant de 952 063,90 $CAN. Le 3 août 2001, un entretien final a eu lieu entre ENI, TPSGC et la GRC. Le 13 août 2001, ENI a déposé sa plainte auprès du Tribunal.

Les dispositions suivantes de la DP, avec modifications, sont pertinentes en l'espèce.

A.12 RESPONSABILITÉS DES SOUMISSIONNAIRES

Il est essentiel que les éléments reproduits dans votre soumission soient exprimés avec clarté et concision. Si vous ne fournissez pas tous les renseignements demandés, vous serez défavorisé.

B.7 FORMATION (OPTION)

Il faudra peut-être donner une formation aux administrateurs de réseau pour qu'ils se familiarisent avec les caractéristiques du produit proposé, de même qu'avec les techniques d'installation et de configuration. L'entrepreneur devra peut-être affecter un instructeur et fournir de la documentation nécessaire à la GRC. Le responsable du projet de la GRC aura la responsabilité de l'établissement du calendrier et des installations de formation. La formation doit être suffisante pour permettre aux administrateurs de réseau de configurer l'application.
Le soumissionnaire doit décrire son programme de formation, sa méthodologie, ses documents de formation et les thèmes abordés. Le soumissionnaire doit démontrer qu'il possède les ressources et les compétences nécessaires pour assurer toute la formation voulue. Il doit au moins fournir :
a) la liste de prix et les calendriers des cours;
b) la description des cours;
c) les mécanismes grâce auxquels le soumissionnaire s'assurera que les administrateurs de réseau ont réussi à maîtriser les connaissances et les compétences requises.

C.1 PROPOSTITION FINANCIÈRE
C.1.4 Base de paiement - Option de formation

D.3 PROCESSUS D'ÉVALUATION
Étape 3 - VALIDATION - ÉVALUATION TECHNIQUE
Les propositions retenues à la fin des étapes 1 et 2 seront soumises à une évaluation pour ce qui est des fonctions du logiciel et des objectifs définis dans les modalités et dans l'énoncé des besoins - appendice B, parties I et II... Les soumissionnaires ne seront pas présents pendant l'étape de validation - évaluation technique. Le gouvernement se réserve le droit d'évaluer, en tout ou en partie, la totalité ou une partie des critères obligatoires, les critères cotés et les critères de rendement.
Étape 4 : ÉVALUATION FINANCIÈRE

c) Le coût total évalué correspond à la valeur totale de la soumission ce qui représente le besoin immédiat, plus le coût total de toutes les options. On calculera le coût total évalué de la proposition de chaque soumissionnaire et on l'indiquera dans la formule décrite à l'article D.4 pour établir la cote numérique de la proposition du soumissionnaire du point de vue du mérite technique et du coût.
Le coût total évalué de chaque soumission correspond aux résultats du calcul des éléments suivants, qui ont été fournis par le soumissionnaire dans sa proposition (partie C de la DP).

[Traduction]

Les dispositions suivantes de l'énoncé des besoins (ÉB) sont pertinentes aux questions en litige en l'espèce.

PARTIE I - EXIGENCES TECHNIQUES OBLIGATOIRES

Le tableau ci-dessous contient les critères fonctionnels nécessaires à la GRC pour la solution logicielle de gestion et de contrôle de réseau.

PARTIE II - EXIGENCES TECHNIQUES COTÉES
Les points pour les critères cotés seront accordés comme suit : 1) la solution logicielle soumise avec la proposition qui répond entièrement aux critères (c.-à-d. un produit d'emploi courant qu'il n'est pas nécessaire d'adapter) se verra accordé le maximum des points; 2) la solution logicielle soumise avec la proposition qui ne répond pas aux critères ne recevra aucun (0) point.

[Traduction]

La question et la réponse n^o 25, qui faisaient partie de la mise à jour n^o A004 envoyée à tous les fournisseurs potentiels le 9 mai 2001, expliquaient l'exigence technique cotée PR4 de la DP (exigence PR4). Le n^o 25 se lit ainsi :

QUESTION n^o 25
En ce qui concerne l'exigence PR4, « Être en mesure de réunir des renseignements de disponibilité pour n'importe quel noeud de réseau », cette condition s'applique-t-elle uniquement aux « noeuds de réseau » indiqués en B.9.2? Sinon, pour quels « noeuds de réseau » faudra-t-il réunir des « renseignements de disponibilité »?
RÉPONSE n^o 25
Pour tous les routeurs et serveurs Solaris énumérés en B.9.2, en plus de 25 autres systèmes (tous disponibles au moyen du SNMP) .

[Traduction]

POSITION DES PARTIES

Position de TPSGC

Dans son premier motif de plainte, ENI a allégué que seule sa proposition de prix pour le premier cours de formation précisé au tableau C.1.4 de sa proposition aurait dû être correctement incluse dans son prix évalué. ENI a prétendu que TPSGC n'a pas suivi les procédures d'évaluation décrites dans la DP en incluant les six cours de formation indiqués dans le tableau. ENI a allégué que l'article B.7 de la DP fait deux demandes distinctes de prix, qui devraient toutes deux être incluses dans la proposition financière d'un soumissionnaire, mais qu'une seule devrait faire partie du prix évalué de la proposition d'ENI.

TPSGC a soutenu que l'interprétation faite par ENI de l'article B.7 de la DP est inexacte et qu'elle n'est pas appuyée par le libellé de l'article B.7. TPSGC a aussi soutenu que l'exigence énoncée à l'article B.7 est claire puisqu'elle établit une exigence pour la formation et une demande de prix. TPSGC a en outre soutenu que, contrairement à l'allégation d'ENI, le premier paragraphe de l'article B.7 ne fait aucune demande de prix; cette dernière figure uniquement dans le second paragraphe. TPSGC a fait valoir que l'interprétation d'ENI portant sur deux types de formation et deux types de prix ne trouve aucune justification dans le libellé du deuxième paragraphe de l'article B.7. TPSGC a soutenu que tous les autres soumissionnaires ont correctement interprété cette exigence.

TPSGC a aussi soutenu qu'il incombait aux soumissionnaires de déterminer le type et le nombre de cours de formation nécessaires pour répondre à l'exigence quant à la formation des administrateurs de réseau. Par conséquent, si un soumissionnaire offrait plus d'un cours pour satisfaire à cette exigence de formation des administrateurs de réseau, le prix de tous les cours serait calculé et additionné pour obtenir le coût total évalué conformément à l'article D.3 de la DP portant sur l'évaluation financière. TPSGC a affirmé que l'absence d'une ligne « Total » au tableau C.1.4 indique que le montant reflète le coût total de tous les cours indiqués par le soumissionnaire en regard de l'unique exigence de formation.

De plus, TPSGC a soutenu que, même si le prix proposé par ENI seulement pour le premier cours de formation indiqué au tableau C.1.4 de sa proposition figurait dans son prix évalué, le résultat serait resté le même et ENI se serait quand même classée au second rang.

Dans son deuxième motif de plainte, ENI a allégué que sa proposition n'a pas reçu de points pour l'exigence PR4 du fait que des critères d'évaluation inexacts et ambigus ont été utilisés dans l'évaluation technique. Dans sa réponse, TPSGC a indiqué qu'ENI avait présenté, eu égard à l'exigence PR4, une solution limitée qui ne répondait pas à l'exigence PR4 énoncée dans la DP. TPSGC a fait valoir que l'exigence PR4, qu'expliquait la réponse n^o 25, était claire et non ambiguë. De plus, il a prétendu que, pour obtenir les 10 points alloués à cette exigence, il ne fallait pas qu'une proposition se limite à réunir des renseignements⁹ de disponibilité uniquement pour les noeuds de réseau conformes à la base d'information de gestion (MIB) II et appuyés par le protocole de gestion de réseau simple (SNMP)¹⁰ .

TPSGC a soutenu que le problème concernant la solution d'ENI était que celle-ci était limitée à une conformité à la MIB I et à la MIB II. Il a aussi soutenu que, même si l'exigence PR4 et la réponse n^o 25 autorisaient la solution à être limitée au SNMP, elles ne précisaient pas que la solution pourrait être limitée à une conformité à MIB I et II du SNMP. En outre, TPSGC a soutenu que le SNMP appuie d'autres MIBs en sus des MIB I et MIB II. Il a donné l'exemple suivant : presque tous les périphériques ou systèmes sur le réseau recourent aussi à une structure de sous-arbres privée (MIB privée). Par conséquent, il peut y avoir sur le réseau des noeuds que le SNMP appuie mais qui ne sont pas conformes à la MIB I ou à la MIB II. TPSGC a aussi soutenu que la réponse n^o 25 énonçait clairement que les noeuds de réseau mentionnés dans l'exigence PR4 n'étaient pas limités aux noeuds de réseau énumérés à l'article B.9.2 de la DP¹¹ . TPSGC a soutenu qu'ENI n'avait aucune raison de conclure que l'exigence PR4 était limitée à une conformité à la MIB II. L'exigence PR4 obligeait nécessairement que la solution logicielle proposée soit en mesure de réunir des renseignements de disponibilité pour n'importe quel noeud de réseau, et non pas uniquement pour les noeuds conformes à la MIB II du SNMP.

En conclusion, TPSGC a demandé que la plainte soit rejetée et que les dépens, le cas échéant, lui soient remboursés étant donné que les dispositions de la DP étaient claires et conformes aux exigences des accords commerciaux et que l'évaluation des propositions s'est déroulée de façon équitable.

Dans une lettre présentée au Tribunal en date du 19 octobre 2001, TPSGC a soutenu que la réponse d'ENI au RIF soulevait de nouvelles questions sur la façon dont avait été évaluée l'exigence PR4. TPSGC a soutenu que, contrairement à la prétention d'ENI, le problème vient du fait que la proposition d'ENI ne peut surveiller que les noeuds de réseau qui eux-mêmes accommodent au moins MIB II. TPSGC a prétendu que l'exigence PR4 ne s'applique pas au type de structures appuyées par le logiciel proposé, mais qu'elle touche uniquement la capacité du logiciel proposé de surveiller la disponibilité des noeuds sur le réseau. Citant la propre proposition d'ENI, TPSGC a fait remarquer qu'« il est très clair dans ce contexte que l'énoncé "au moins la MIB II du SNMP" sert à limiter la proposition et à indiquer que les noeuds qui utilisent le SNMP mais qui n'accommodent pas la MIB II sont exclus » [traduction].

TPSGC a aussi soutenu qu'ENI fait erreur lorsqu'elle signale qu'une conformité à l'exigence PR4 s'impose si l'évaluation établit que la solution satisfait à l'exigence M15. TPSGC a affirmé que ces exigences ne sont pas liées et que l'exigence M15 oblige le logiciel proposé à appuyer l'utilisation de toute MIB du SNMP, tandis que l'exigence PR4 est une exigence cotée servant à évaluer la capacité du logiciel de surveiller la disponibilité de n'importe quel noeud de réseau. Il a aussi soutenu qu'ENI avait clairement précisé dans sa réponse à l'exigence M15 qu'elle n'excluait aucune MIB du SNMP pour la fonction planification de la capacité et rapports.

Concernant l'affirmation d'ENI selon laquelle sa proposition a été validée en regard de l'exigence PR4, TPSGC a prétendu que ce n'était pas le cas. TPSGC a soutenu que, eu égard aux exigences cotées, seuls les aspects des propositions qui répondaient aux exigences pendant l'évaluation des exigences cotées (étape 2) ont fait l'objet d'un essai de validation (étape 3) au cours du processus d'évaluation.

Concernant le redressement demandé, TPSGC a précisé qu'il n'était pas raisonnable pour ENI de demander compensation pour les bénéfices perdus, les coûts de préparation de la soumission et le manque à gagner pour le renouvellement des services de maintenance et de soutien stipulés dans le contrat pour quatre périodes d'un an.

Position d'ENI

Pour ce qui est du premier motif de plainte, plus précisément à savoir si TPSGC a correctement évalué la proposition de coût d'ENI pour l'option de formation, ENI a prétendu que le libellé de l'article D.3, phase 4, alinéa c), appuie son argument que le coût des options qu'elle a proposées n'aurait pas dû être inclus dans le coût total évalué. ENI a soutenu que le renvoi au terme « option » dans cet article ne signifie pas que les options proposées par le soumissionnaire feraient partie du coût total évalué, mais plutôt que les options énumérées dans la DP feraient partie du coût total évalué. ENI a fait valoir que le tableau au paragraphe c) énumère trois autres points facultatifs en plus de l'option de formation, et que ce sont ces « options », spécifiquement mentionnées comme « options » dans la DP, qui doivent faire partie du prix total dans le « coût total évalué de chaque soumission ». ENI a aussi soutenu que seule la première rubrique de sa proposition financière à l'article C.1.4 aurait dû être incluse et que toute option non requise proposée par ENI en sus de l'option de formation énoncée aux articles B.7 et C.1.4 n'aurait pas dû être incluse. ENI a conclu que le calcul erroné de TPSGC a gravement défavorisé sa proposition.

Pour ce qui est du second motif de plainte, à savoir si la proposition d'ENI a été bien évaluée eu égard à l'exigence PR4, ENI a soutenu que, dans sa lettre du 27 juillet 2001, TPSGC a erré lorsqu'il a conclu que la proposition d'ENI était limitée aux MIB I et MIB II. De fait, ENI a prétendu que sa soumission n'était clairement pas limitée aux MIB I et MIB II, mais qu'elle était plutôt compatible avec tous les SNMPs, y compris ceux qui sont expressément énumérés dans le RIF, du fait que TPSGC a jugé la soumission d'ENI conforme à l'exigence M15. ENI a indiqué que l'interprétation faite par TPSGC de la réponse d'ENI à l'exigence PR4 est incohérente avec les conclusions de TPSGC selon lesquelles la proposition d'ENI répondait, en effet, à l'exigence M15 et qu'elle était en mesure de réussir à l'étape de validation.

ENI a aussi soutenu que TPSGC semble avoir mal compris ENI lorsque celle-ci a indiqué que sa proposition appuyait au moins la MIB II. ENI a prétendu que les mots « au moins » indiquent clairement que, par définition, sa proposition appuie le SNMP en plus de la MIB II, comme l'exigeait la DP. Comme la proposition d'ENI appuyait au moins la MIB II, elle appuyait aussi des MIBs privées. En conclusion, ENI a fait valoir que sa réponse à l'exigence PR4 est claire en elle-même; la proposition d'ENI répond au moins à la norme MIB II du SNMP. Toute autre interprétation n'est pas compatible avec les conclusions de TPSGC selon lesquelles la proposition d'ENI répondait à l'exigence M15, qui obligeait la proposition d'ENI à « appuyer l'utilisation de toute MIB du SNMP » [traduction]. De plus, ENI a prétendu que toute autre interprétation est également incompatible puisque sa proposition a réussi à l'étape de validation. ENI a soutenu que sa proposition aurait dû recevoir 10 points à l'égard de l'exigence PR4. Si cela avait été le cas, sa cote aurait dépassé celle d'InfoVista et le contrat lui aurait été adjugé.

ENI a demandé plusieurs correctifs en plus de ceux qui sont énumérés dans sa plainte initiale. ENI a soutenu que, si la plainte est jugée être fondée, elle devrait être dédommagée pour les bénéfices perdus et le manque à gagner pour le renouvellement des services de maintenance et de soutien stipulés dans le contrat pour quatre périodes consécutives d'un an. Elle a aussi demandé à ce que les coûts engagés dans la préparation d'une proposition en réponse à l'appel d'offres ainsi que les coûts liés à la préparation et au traitement de sa plainte lui soient remboursés.

Dans sa réponse du 1^er novembre 2001 à la suite de celle de TPSGC en date du 19 octobre 2001, ENI a soutenu que le Tribunal ne devrait tenir compte que des motifs de rejet, liés à l'exigence PR4, énumérés dans la lettre de TPSGC en date du 27 juillet 2001, car la décision de TPSGC, à l'origine de la plainte, de n'accorder aucun point se fonde sur lesdits motifs. Elle a aussi soutenu que les arguments avancés après coup par TPSGC, c'est-à-dire après son évaluation de la proposition d'ENI, sont à toutes fins pratiques sans fondement. ENI a aussi prétendu que sa proposition avait établi une conformité minimale ou, autrement dit, fondamentale aux normes du SNMP et de la MIB, comme l'exigeaient tous les noeuds de réseau.

De plus, eu égard aux critères M15 et PR4, ENI a soutenu que tout logiciel capable d'appuyer l'utilisation de la MIB II du SNMP est également en mesure de surveiller la disponibilité de tout noeud de réseau disponible au moyen du SNMP. Concernant l'étape de validation, ENI a prétendu qu'il n'est nulle part fait mention dans la DP qu'une exigence cotée ne sera pas évaluée pendant l'étape de validation si elle ne répond pas aux exigences. Selon la réponse de TPSGC, ENI a soutenu que TPSGC a négligé de valider l'exigence PR4 pendant la validation de sa proposition; par conséquent, ENI a soutenu qu'il s'agit là d'une violation des obligations qui incombent au TPSGC aux termes du processus d'évaluation.

DÉCISION DU TRIBUNAL

Aux termes de l'article 30.14 de la Loi sur le TCCE, le Tribunal doit, lorsqu'il a décidé d'enquêter, limiter son étude à l'objet de la plainte. En outre, à la fin de l'enquête, le Tribunal doit déterminer la validité de la plainte en fonction des critères et procédures établis par règlement pour le contrat spécifique. L'article 11 du Règlement prévoit, notamment, que le Tribunal doit déterminer si le marché public a été passé conformément aux accords commerciaux applicables.

Le paragraphe 506(6) de l'ACI prévoit, notamment que les « documents d'appel d'offres doivent indiquer clairement les conditions du marché public, les critères qui seront appliqués dans l'évaluation des soumissions et les méthodes de pondération et d'évaluation des critères ». Le paragraphe 1013(1) de l'ALÉNA et l'article XII de l'AMP prévoient les mêmes obligations réelles. Par conséquent, le Tribunal doit décider si TPSGC a mal appliqué les critères d'évaluation dans son évaluation de la proposition d'ENI.

En ce qui concerne l'allégation d'ENI selon laquelle TPSGC a incorrectement évalué sa proposition de coût en incluant les six cours de formation énumérés au tableau C.1.4 dans le coût total évalué, et non seulement le premier cours de formation, le Tribunal juge cette allégation sans fondement. Selon le Tribunal, l'exigence relative à l'option de formation, énoncée à l'article B.7 de la DP, ne comprenait pas plus d'une demande de formation et de prix, comme l'alléguait ENI. Le Tribunal estime que le premier paragraphe de l'article B.7 décrit la portée de la formation demandée, tandis que le deuxième paragraphe précise les renseignements requis au sujet de la seule exigence de formation exprimée dans le premier paragraphe. Par conséquent, le Tribunal est d'accord avec TPSGC que le tableau C.1.4 ne présentait qu'une seule demande de prix.

Le Tribunal est convaincu que le total de tous les prix indiqués au tableau C.1.4 de la proposition d'ENI reposait sur le fait que ce tableau ne présentait qu'une seule exigence. Le Tribunal note aussi que rien n'indiquait dans la réponse d'ENI au tableau C.1.4, comme le présente sa proposition financière, que tous les prix ne devraient pas être additionnés ni que certains des cours inscrits au tableau étaient énumérés à titre d'information seulement ou faisaient suite à une deuxième demande présumée de formation et de prix. Le Tribunal est d'avis que l'article A.12 de la DP impose au soumissionnaire le fardeau de présenter sa soumission d'une façon claire et concise.

De plus, le Tribunal est convaincu que l'évaluation financière a été effectuée indépendamment de l'évaluation technique, comme elle devrait l'être, conformément aux exigences de la DP. Par conséquent, le Tribunal n'a aucune peine à comprendre comment l'agent de TPSGC responsable de l'évaluation financière a additionné tous les prix figurant au tableau C.1.4 de la proposition financière d'ENI, puisque l'évaluation technique n'était pas de la compétence de cet agent. La situation est d'autant plus compréhensible lorsqu'on sait que le tableau C.1.4 ne présentait qu'une seule exigence pour une option de formation.

Concernant l'allégation selon laquelle TPSGC a mal évalué la proposition technique d'ENI eu égard à l'exigence PR4, le Tribunal juge également cette allégation sans fondement. Le Tribunal a examiné attentivement les dispositions de la DP, la question et la réponse pertinentes à cette exigence ainsi que les longs exposés des parties. L'exigence PR4 se lit en partie comme suit : « la solution logicielle doit être en mesure de réunir des renseignements de disponibilité pour n'importe quel noeud de réseau » [traduction]. Le Tribunal comprend que cette exigence désigne expressément la surveillance¹² de noeuds de réseau. De plus, il note que cette exigence ne fait aucune mention d'une conformité ou d'un soutien du SNMP ou de MIBs. Autrement dit, le Tribunal comprend que la solution logicielle devait être en mesure de réunir des renseignements pour tous les noeuds de réseau, peu importe la conformité aux MIBs, spécifiques ou autres, du SNMP. Le Tribunal constate qu'ENI a utilisé, dans sa réponse à l'exigence PR4, des termes qui nuancent ou tempèrent sa réponse. Après un examen attentif de la réponse d'ENI à l'exigence PR4, le Tribunal constate que, en ayant ajouté des mots qui précisent que les noeuds eux-mêmes supportent « au moins » une MIB, ENI a nuancé le type de noeud que sa solution était en mesure de surveiller. Le Tribunal a examiné à fond les dispositions de la DP pour savoir si un tel qualificatif était nécessaire ou même requis dans la réponse à l'exigence PR4 ou dans la réponse n^o 25. Le Tribunal n'a trouvé aucune indication qu'un tel qualificatif était justifié. Le Tribunal est d'avis que l'exigence PR4 était complète en elle-même et qu'elle ne limitait pas la capacité de la solution logicielle à un type particulier de noeud, mais à n'importe quel noeud, et, par conséquent, à tous les noeuds. Pour cette raison, le Tribunal est d'avis que TPSGC a correctement interprété les mots qu'ENI a utilisés pour décrire sa conformité à l'exigence PR4 comme une limitation de la solution d'ENI à des noeuds qui étaient uniquement conformes à la MIB II du SNMP. Par conséquent, le Tribunal est d'accord avec TPSGC que, en limitant sa capacité à des noeuds qui acceptaient une MIB spécifique, ENI a exclu des noeuds qui n'acceptaient pas d'autres MIBs. Par conséquent, le Tribunal estime que TPSGC était en droit de ne pas attribuer à ENI les 10 points réservés à une solution qui respectait entièrement cette exigence.

En outre, le Tribunal interprète la réponse n^o 25 au sens que la solution logicielle doit être en mesure de réunir des renseignements de disponibilité pour tous les noeuds énumérés à l'article B.9.2 plus 25 autres systèmes, c'est-à-dire 25 systèmes non énumérés à l'article B.9.2. De l'avis du Tribunal, la question était claire puisqu'elle demandait des renseignements sur les noeuds de réseau précisés à l'article B.9.2. Dans sa réponse, TPSGC indique que ces 25 autres systèmes sont tous accessibles au moyen du SNMP, fournissant ainsi des renseignements aux soumissionnaires au sujet des 25 autres systèmes non décrits à l'article B.9.2. Le Tribunal croit que rien dans cette réponse n'obligeait expressément à une conformité à toute MIB. De l'avis du Tribunal, la réponse n^o 25 ne limitait pas la solution logicielle à une conformité à une MIB spécifique. Par conséquent, le Tribunal est d'accord avec TPSGC que l'exigence PR4 et la réponse n^o 25 permettaient à une solution d'être limitée au SNMP et il est convaincu que l'exigence PR4 et la réponse n^o 25 ne précisaient pas que la solution était limitée à la MIB I et à la MIB II.

Le Tribunal n'est pas convaincu par l'argument d'ENI selon lequel sa solution aurait dû être jugée conforme à l'exigence PR4 du fait qu'elle répondait entièrement à l'exigence M15. Le Tribunal se range plutôt du côté de TPSGC qui prétend que les deux exigences n'ont aucun lien entre elles. Selon le Tribunal, le fait de satisfaire à l'exigence obligatoire M15 n'entraînait pas nécessairement une conformité complète à l'exigence PR4, puisque ces deux exigences visent deux besoins spécifiques différents. TPSGC a jugé la solution d'ENI conforme puisqu'elle proposait une solution logicielle qui appuyait l'utilisation de toute MIB du SNMP, comme le demandait l'exigence M15. En revanche, l'exigence PR4 portait spécifiquement sur la capacité du logiciel de vérifier ou de surveiller la disponibilité des noeuds de réseau qui, de l'avis du Tribunal, constitue un besoin entièrement différent.

L'allégation d'ENI selon laquelle le Tribunal devrait limiter son enquête aux motifs de rejet contenus dans la lettre de TPSGC en date du 27 juillet 2001 est sans fondement. Cette lettre informait ENI des résultats de l'invitation. Le Tribunal est conscient que la lettre a fourni à ENI des renseignements au sujet de l'évaluation de sa proposition, en l'occurrence des endroits où la proposition n'a pas reçu de points techniques. Toutefois, le Tribunal ne croit pas que cette lettre a pour but de fournir un examen détaillé et complet de l'évaluation technique des propositions. Le Tribunal la considère plutôt comme un moyen d'informer les soumissionnaires du nom du soumissionnaire retenu et de la valeur du contrat adjugé. La lettre ne vise pas à présenter un rapport technique complet. Le Tribunal croit que l'information contenue dans cette lettre ne peut être interprétée comme une présentation complète des résultats de l'évaluation de la proposition. Par conséquent, le Tribunal ne se voit aucunement restreint d'examiner uniquement les raisons fournies dans cette lettre.

Pour ce qui est de l'argument présenté par ENI selon lequel sa proposition a été validée eu égard à l'exigence PR4 au cours de l'étape de validation, le Tribunal fait remarquer l'argument d'ENI selon lequel la DP n'indique pas expressément qu'une exigence cotée ne serait pas évaluée pendant l'étape 3 du processus d'évaluation si elle ne répondait pas aux exigences. Après avoir lu en entier l'article au sujet de l'étape 3, « VALIDATION - ÉVALUATION TECHNIQUE », le Tribunal est convaincu que le gouvernement s'est effectivement réservé le droit d'évaluer, en tout ou en partie, la totalité ou une partie des critères obligatoires, les critères cotés et les critères de rendement. Par conséquent, le Tribunal n'estime pas que le gouvernement était tenu de vérifier toutes les exigences, mais qu'il pouvait plutôt limiter ses essais à une partie des exigences et non à d'autres, à sa discrétion.

Dans le RIF, TPSGC a demandé que des dépens lui soit accordés en l'espèce. Le Tribunal a jugé que les circonstances en l'espèce ne justifiaient pas un dédommagement contre ENI. Même si ENI n'a pas été le soumissionnaire retenu, elle a agi, de l'avis du Tribunal, en toute bonne foi. Le Tribunal ne voit aucune raison d'accorder des dépens à TPSGC en l'espèce¹³ . Par conséquent, le Tribunal a décidé de ne demander aucun exposé sur cette question et de n'accorder aucuns dépens.

DÉCISION DU TRIBUNAL

À la lumière de ce qui précède, le Tribunal détermine que le marché public a été passé conformément aux exigences de l'ACI, de l'ALÉNA et de l'AMP et que la plainte n'est donc pas fondée.

1 . L.R.C. 1985 (4^e supp.), c. 47 [ci-après Loi sur le TCCE].

2 . D.O.R.S./93-602 [ci-après Règlement].

3 . D.O.R.S./91-499.

4 . Le Réseau des services nationaux de police est le réseau des systèmes d'information et de communication de la police qu'utilisent la GRC et les services de police régionaux et locaux. On y trouve des renseignements comme les dossiers criminels, les véhicules volés, les personnes recherchées, les criminels dangereux, les détenus en liberté conditionnelle et les personnes disparues.

5 . 32 I.L.M. 289 (entré en vigueur le 1^er janvier 1994) [ci-après ALÉNA].

6 . 15 avril 1994, en ligne : Organisation mondiale du commerce <http ://www.wto.org/french/docs_f/legal_f/final_f.htm> [ci-après AMP].

7 . 18 juillet 1994, Gaz. C. 1995.I.1323, en ligne : Secrétariat du commerce intérieur <www.intrasec.mb.ca/fre/it.htm> [ci-après ACI].

8 . La lettre fournissait aussi des renseignements à ENI afin de l'aider à évaluer les avantages de sa proposition. Elle donnait aussi des renseignements de base sur les endroits où ENI a perdu des points à l'évaluation.

9 . Dans le RIF, TPSGC a aussi présenté des renseignements statistiques au sujet de la disponibilité.

10 . SNMP est un jeu de spécifications qui sert à la gestion de réseaux et à la collecte de renseignements auprès de périphériques ou de systèmes (« noeuds »). Les divers systèmes ou périphériques du réseau ont un logiciel de gestion appelé un « agent ». Ce logiciel de gestion, ou « agent », recueille des renseignements sur le périphérique ou système, stocke les données, les envoie à un centre de gestion sur demande, etc. Le logiciel de gestion SNMP stocke l'information selon la MIB. La MIB est une structure spécifique de données qui contient des renvois ou qui répertorie des renseignements sur les périphériques ou les systèmes d'un réseau. L'information dans la MIB est structurée selon certains types de sous-arbres. Les MIB I et MIB II sont deux exemples de sous-arbres dans la MIB. La MIB II comprend la MIB I et est compatible avec celle-ci.

11 . L'article B.9.2 de la DP décrit l'environnement actuel de la GRC, y compris divers types de matériel, comme des routeurs et des serveurs.

12 . Le Tribunal interprète le verbe « surveiller » comme « l'observation et la vérification de quelque chose dans le temps » et « maintenir une surveillance régulière de quelque chose ».

13 . À cet égard, le Tribunal reprend la position prise dans Flolite Industries, Addenda (7 août 1998), PR-97-045 (TCCE).

---

[ Table des matières]

---

Publication initiale : le 7 février 2002