Dossier no PR-2018-017 Critical Software S.A. c. Ministère des Travaux publics et des Services gouvernementaux

Décision et motifs rendus le lundi 3 décembre 2018

 

TABLE DES MATIÈRES

DÉCISION  i

EXPOSÉ DES MOTIFS  1

RÉSUMÉ DE LA PLAINTE  1

HISTORIQUE DE LA PROCÉDURE  1

QUESTIONS PRÉLIMINAIRES  3

La demande de l’intervenante  3

Demandes par Critical Software de renseignements additionnels de TPSGC  4

ANALYSE  5

Motif 1 : la conclusion selon laquelle la soumission de Critical Software n’était pas conforme au critère obligatoire O-2 était raisonnable.  6

Motif 2 : la démonstration du service de validation W3C n’était pas requise pour l’évaluation technique  9

Conclusion  12

FRAIS  13

DÉCISION  13

ANNEXE  14

MODALITÉS PERTINENTES DE L’APPEL D’OFFRES  14

 

EU ÉGARD À une plainte déposée par Critical Software S.A. aux termes du paragraphe 30.11(1) de la Loi sur le Tribunal canadien du commerce extérieur, L.R.C. (1985), ch. 47 (4^e suppl.);

ET À LA SUITE D’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.

ENTRE
CRITICAL SOFTWARE S.A.	Partie plaignante
ET
LE MINISTÈRE DES TRAVAUX PUBLICS ET DES SERVICES GOUVERNEMENTAUX	Institution fédérale

DÉCISION

Aux termes du paragraphe 30.14(2) 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.

Aux termes du paragraphe 30.16 de la Loi sur le Tribunal canadien du commerce extérieur, le Tribunal canadien du commerce extérieur accorde au ministère des Travaux publics et des Services gouvernementaux une indemnité raisonnable pour les frais encourus pour avoir répondu à la plainte, indemnité qui doit être versée par Critical Software S.A. Conformément à la Ligne directrice sur la fixation des frais dans une procédure portant sur un marché public, le Tribunal canadien du commerce extérieur détermine provisoirement que le degré de complexité de la plainte correspond au degré 1 et que le montant de l’indemnité est de 1 150 $. Si l’une ou l’autre des parties n’est pas d’accord en ce qui a trait à la détermination provisoire du degré de complexité ou du montant de l’indemnité, elle peut présenter des observations auprès du Tribunal canadien du commerce extérieur, en conformité avec l’article 4.2 de la Ligne directrice sur la fixation des frais dans une procédure portant sur un marché public. Il relève de la compétence du Tribunal canadien du commerce extérieur de fixer le montant définitif de l’indemnité.

Randolph W. Heggart

Randolph W. Heggart Membre présidant

 

Membres du Tribunal :	Randolph W. Heggart, membre présidant
Personnel de soutien :	Laura Little, conseillère juridique
Partie plaignante :	Critical Software S.A.
Conseiller juridique pour la partie plaignante :	Ranald McGillis
Institution fédérale :	Ministère des Travaux publics et des Services gouvernementaux
Conseiller juridique pour l’institution fédérale :	Susan Clarke Ian McLeod Roy Chamoun Kathryn Hamill
Partie intervenante :	EMS Technologies Canada Limited
Conseillers juridiques pour la partie intervenante :	Louis Sévéno Marie-Pier Cloutier

Veuillez adresser toutes les communications au :

Greffier
Secrétariat du Tribunal canadien du commerce extérieur
15^e étage
333, avenue Laurier Ouest
Ottawa (Ontario) K1A 0G7

Téléphone : 613-993-3595
Télécopieur : 613-990-2439
Courriel : tcce-citt@tribunal.gc.ca

 

EXPOSÉ DES MOTIFS

[1]  Le 27 juillet 2018, Critical Software S.A. (Critical Software), de Coimbra (Portugal), a déposé une plainte auprès du Tribunal canadien du commerce extérieur (le Tribunal) aux termes du paragraphe 30.11 de la Loi sur le Tribunal canadien du commerce extérieur [1] concernant un marché (invitation n^o W8474-17SM06/B) passé par le ministère des Travaux publics et des Services gouvernementaux (TPSGC) au nom du ministère de la Défense nationale (MDN). L’appel d’offres portait sur la conception, l’assemblage, la livraison ainsi que l’entretien et le soutien connexes d’une application du système de gestion de missions de recherche et de sauvetage (SGMR).

[2]  Le 2 août 2018, le Tribunal a accepté d’enquêter sur la plainte, puisque celle-ci répondait aux exigences du paragraphe 30.13(1) de la Loi sur le TCCE ainsi qu’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 [2] .

[3]  Le Tribunal a enquêté sur le bien-fondé de la plainte, conformément aux articles 30.13 à 30.15 de la Loi sur le TCCE. Pour les motifs qui suivent, le Tribunal conclut que la plainte n’est pas fondée.

RÉSUMÉ DE LA PLAINTE

[4]  Critical Software soutient que TPSGC a conclu à tort que sa soumission ne démontrait pas « une expérience en développement et en déploiement d’applications WEB HTML5 interactives nationales » conformément au critère d’évaluation technique obligatoire O-2 de la demande de propositions (DP) (« motif 1 »). Plus particulièrement, la soumission de Critical Software a été jugée non conforme à l’exigence de fournir un pourcentage de répartition des utilisateurs par région pour chacun de ses deux projets donnés en référence. Selon ses observations, l’exigence était ambiguë et non pertinente par rapport au critère O-2 et elle n’aurait donc pas dû être incluse dans la DP.

[5]  De plus, Critical Software soutient que TPSGC n’a pas respecté la procédure d’évaluation de la soumission technique indiquée dans sa DP en ce qui concerne le critère obligatoire O-2 parce qu’il n’a pas utilisé la démonstration du service de validation W3C pour vérifier la conformité de la soumission à ce critère (« motif 2 »). Critical Software fait valoir que le soumissionnaire retenu n’était pas en mesure de respecter le critère O-2 et qu’il n’aurait donc pas dû être recommandé pour l’adjudication du contrat.

[6]  À titre de mesure corrective, Critical Software demande une compensation pour ses profits perdus en raison de l’adjudication du contrat et d’être indemnisée pour les frais de préparation de sa soumission et de sa plainte.

HISTORIQUE DE LA PROCÉDURE

[7]  La DP a été publiée par TPSGC le 13 octobre 2017, et la date de clôture de l’appel d’offres était le 27 novembre 2017. La date de clôture a ensuite été reportée au 18 décembre 2017. Cinq soumissions ont été reçues, dont celle de Critical Software.

[8]  L’évaluation technique des soumissions a commencé le 8 janvier 2018. Le service de validation W3C n’a pas été utilisé par les évaluateurs pour vérifier la conformité des soumissions au critère obligatoire O-2 [3] . La procédure d’évaluation technique est examinée plus en détail ci-dessous, dans la mesure où il est pertinent à l’analyse faite par le Tribunal des motifs de plainte susmentionnés. Elle a pris fin le 8 février 2018, et les feuilles d’évaluation par consensus signées ont été remises par le MDN à TPSGC [4] .

[9]  Le 28 juin 2018, TPSGC a avisé Critical Software qu’un contrat avait été attribué à MDA Systems Ltd. (MDA). TPSGC a indiqué dans sa lettre que la soumission de Critical Software avait été jugée non conforme au critère obligatoire O-2 de la DP et qu’elle avait donc été écartée de la procédure d’évaluation et n’avait pas obtenu de note technique [5] .

[10]  Le 29 juin 2018, Critical Software a demandé à TPSGC la tenue d’une réunion de compte rendu. À cette réunion tenue le 18 juillet 2018, Critical Software s’est opposée à l’adjudication du contrat selon les motifs de plainte susmentionnés. TPSGC a entrepris l’examen des préoccupations soulevées en ce qui concerne la démonstration du service de validation W3C relativement au critère obligatoire O-2 et le suivi à cet égard auprès de Critical Software. Toutefois, TPSGC a également indiqué à Critical Software que, même si sa soumission avait été jugée conforme à l’ensemble des exigences obligatoires de la DP et avait obtenu une note parfaite pour les critères techniques cotés, elle n’aurait pas obtenu le contrat [6] .

[11]  Le 19 juillet 2018, TPSGC a avisé le soumissionnaire gagnant, MDA, que, « conformément à l’alinéa 4.2(d) de la DP » [traduction], il voulait effectuer une démonstration du service de validation W3C relativement au critère obligatoire O-2 [7] . La démonstration a été effectuée le 27 juillet 2018 et elle s’est avérée réussie [8] .

[12]  Le 27 juillet 2018, Critical Software a déposé sa plainte auprès du Tribunal.

[13]  Le 2 août 2018, TPSGC a avisé Critical Software que les résultats de la démonstration du service de validation W3C en ce qui concerne le critère obligatoire O-2 avaient confirmé que MDA respectait pleinement les exigences obligatoires de la DP [9] .

[14]  Le 3 août 2018, le Tribunal a informé les parties qu’il avait décidé d’enquêter sur la plainte.

[15]  Le 4 septembre 2018, le Tribunal a reçu une lettre d’EMS Technologies Canada Ltd. (EMS), un autre soumissionnaire dans le cadre de l’appel d’offres en question, qui demandait l’autorisation d’intervenir dans l’enquête. Les parties ont déposé des commentaires sur cette demande le 7 septembre 2018.

[16]  Le 14 septembre 2018, le Tribunal a accordé un statut limité d’intervenante à EMS et a modifié le calendrier de dépôt des observations des parties. Par suite de la participation de l’intervenante et des délais de dépôt supplémentaires, le Tribunal a prolongé l’échéance pour rendre sa décision quant au bien‑fondé de la plainte à 135 jours, aux termes de l’article 12 du Règlement.

[17]  TPSGC a déposé son Rapport de l’institution fédérale (RIF) le 13 septembre 2018, et EMS a déposé ses observations à titre d’intervenante le 2 octobre 2018. Critical Software a déposé ses observations en réponse le 12 octobre 2018.

[18]  TPSGC et Critical Software ont déposé d’autres observations les 12 et 15 octobre 2018 respectivement. Dans ses observations du 15 octobre 2018, Critical Software a aussi demandé que TPSGC soit tenu de fournir des renseignements additionnels ayant trait à certaines pièces déposées en même temps que le RIF. Cette demande est examinée en tant que question préliminaire ci‑dessous.

[19]  Le 22 octobre 2018, EMS a déposé d’autres observations [10] .

[20]  Le Tribunal n’a pas jugé nécessaire de tenir une audience et a par conséquent rendu sa décision en se fondant sur les documents versés au dossier.

QUESTIONS PRÉLIMINAIRES

La demande de l’intervenante

[21]  Dans sa demande de statut d’intervenante du 4 septembre 2018, EMS a demandé de déposer des observations sur les questions suivantes :

• La capacité du soumissionnaire retenu de fournir le système requis parce que, selon EMS, MDA ne semble pas avoir d’expérience antérieure démontrable en ce qui concerne ce type d’exigence et que cette exigence de gestion de missions de recherche et de sauvetage ne semble pas être un domaine auquel MDA a déjà participé.

• Selon l’expérience approfondie d’EMS en ce qui concerne le système actuel, elle croit que le prix des travaux fourni par le soumissionnaire retenu est considérablement inférieur à ce qui est raisonnable pour l’étendue des travaux indiquée dans la DP.

[22]  Tel qu’indiqué ci-dessus, le Tribunal a accordé un statut limité d’intervenante à EMS. Dans sa lettre aux parties datée du 14 septembre 2018, le Tribunal a précisé que, dans son enquête, il doit limiter son étude à l’objet de la plainte, aux termes du paragraphe 30.14(1) de la Loi sur le TCCE.

[23]  Le Tribunal n’a pas considéré qu’EMS était en mesure d’aider à régler le motif 1 de la plainte, puisqu’il concerne l’évaluation de la soumission de Critical Software. Le Tribunal a donc accordé à EMS un statut limité d’intervenante aux fins de la formulation d’observations en ce qui concerne le motif 2 de la plainte uniquement. Dans la mesure où la demande d’EMS faisait référence à des questions qui ne relèvent pas du motif 2 de la plainte, comme le prix des travaux de la soumission retenue, le Tribunal a avisé EMS que ces questions ne pouvaient être examinées dans la présente enquête.

[24]  Dans ses commentaires sur le RIF, EMS soutient que le soumissionnaire gagnant ne respectait pas une clause uniformisée incorporée par renvoi dans la DP, obligeant que les exigences d’expérience de l’appel d’offres soient satisfaites par le soumissionnaire seul (plutôt que par une société mère ou une filiale). Selon le Tribunal, ces allégations n’entrent pas dans le cadre de la plainte et, par conséquent, de la présente enquête. En particulier, le motif 2 porte sur le non-respect présumé par le soumissionnaire retenu du critère O-2 et ne fait pas référence aux exigences d’expérience figurant ailleurs dans les documents de l’appel d’offres. Par conséquent, ces allégations ne seront pas abordées dans l’analyse du Tribunal [11] .

Demandes par Critical Software de renseignements additionnels de TPSGC

[25]  Critical Software a demandé, dans ses observations déposées le 15 octobre 2018, que TPSGC soit tenu de fournir d’autres renseignements sur certaines affirmations dans le RIF et les pièces déposées. En particulier, le RIF indique que, le 20 juillet 2018, un membre de l’équipe d’évaluation technique a écrit à l’autorité contractante de TPSGC pour l’aviser que trois des cinq soumissions reçues (y compris celle de Critical Software) ne comprenaient pas suffisamment de renseignements pour permettre la tenue de la démonstration du service de validation W3C, alors que la soumission retenue comprenait suffisamment de renseignements [12] . Comme indiqué ci-dessus, une démonstration a par la suite été effectuée avec le soumissionnaire retenu, MDA, le 27 juillet 2018, et elle s’est avérée réussie.

[26]  Critical Software a contesté la preuve indiquant que seul le soumissionnaire retenu respectait l’exigence d’inclure dans sa soumission ce qui était nécessaire pour effectuer le test de service de validation W3C. Selon Critical Software, cette affirmation est inexacte quant aux faits et elle a demandé plus de renseignements à cet égard à TPSGC.

[27]  Le Tribunal n’a pas cru nécessaire d’obtenir plus de renseignements sur ce point étant donné sa décision, pour les motifs indiqués ci-dessous, selon laquelle TPSGC avait raisonnablement conclu que la soumission de Critical Software n’était pas conforme au critère O-2 et que l’évaluation de cette exigence n’exigeait pas la tenue d’une démonstration du service de validation W3C.

[28]  Dans ses commentaires sur le RIF, Critical Software a demandé que TPSGC fournisse d’autres renseignements en ce qui concerne la procédure d’évaluation technique décrite dans le RIF. En particulier, contrairement à ce qui est indiqué dans la lettre de rejet de TPSGC du 28 juin 2018 [13] , le RIF indiquait que les évaluateurs avaient procédé à l’évaluation des critères techniques cotés avant de conclure leur évaluation finale des exigences obligatoires techniques de la DP [14] . Critical Software a soulevé une préoccupation selon laquelle cette méthode « aurait introduit un parti pris en faveur de la solution technique classée au premier rang et influencé la réévaluation des exigences obligatoires » [traduction]. Elle a aussi fait valoir que TPSGC avait participé à tort à la tenue de la procédure d’évaluation, contrairement à sa propre politique, à savoir la section 5.40 du Guide des approvisionnements, qui indique que le ministère client (dans ce cas-ci, le MDN) est responsable d’évaluer la partie technique des soumissions.

[29]  TPSGC, en tant qu’entité contractante dans le cadre de l’appel d’offres, a la responsabilité d’engager le Canada à l’égard de tout contrat subséquent découlant de l’appel d’offres et de s’assurer que celui‑ci, y compris l’évaluation technique, a été effectué conformément aux accords commerciaux applicables. À ce titre, la communication avec l’équipe d’évaluation technique du MDN au cours de la procédure d’évaluation n’est pas inhabituelle et ne constitue pas automatiquement une violation des dispositions de la DP ou des accords commerciaux applicables. En l’espèce, les communications écrites entre TPSGC et les évaluateurs techniques comprenaient des discussions sur l’évaluation technique, la façon dont elle a été effectuée ou les résultats. Le Tribunal conclut que rien dans ces communications ne constitue une violation des modalités de la DP ou des accords commerciaux applicables.

[30]  En ce qui concerne la DP elle-même, la section 4.2 indique que l’évaluation technique est composée de quatre parties distinctes. Il s’agit a) des critères techniques obligatoires, b) des critères techniques cotés, c) de la vérification des références et d) de la démonstration. Même s’il semble logique à des fins d’efficacité qu’une évaluation suive l’ordre indiqué, cette section ou la section 4.4 (« Méthode de sélection ») n’indique pas expressément que l’évaluation des exigences techniques obligatoires doit être effectuée avant l’évaluation des critères techniques cotés. Des expressions explicites indiquant que ces éléments sont discrétionnaires et que toute vérification des références s’appliquerait uniquement aux « soumissionnaires dont la candidature n’a pas été jugée irrecevable à ce stade de l’évaluation » et que toute démonstration viserait uniquement le « soumissionnaire classé au premier rang (position établie après l’évaluation financière) » figurent dans le libellé des éléments c) Vérification des références et d) Démonstration. Cela laisse entendre que ces étapes se dérouleraient logiquement après l’évaluation des exigences obligatoires et techniques cotées.

[31]  Enfin, le Tribunal n’a pas obtenu suffisamment d’éléments de preuve pour appuyer la prétention selon laquelle la séquence d’une évaluation initiale des critères obligatoires puis d’une évaluation des critères cotés en l’espèce introduisait une partialité inhérente dans la procédure d’évaluation. À cet égard, il convient de noter que le nom des soumissionnaires n’a pas été fourni aux évaluateurs; ils étaient identifiés par une lettre uniquement [15] . En outre, les circonstances dans la preuve soumise au Tribunal n’ont pas soulevé de crainte raisonnable de partialité.

[32]  Par conséquent, le Tribunal n’a pas estimé qu’il était pertinent ou nécessaire aux fins de sa décision de demander à TPSGC de fournir d’autres renseignements en ce qui concerne la séquence de la procédure d’évaluation technique, comme le demandait Critical Software.

ANALYSE

[33]  Le paragraphe 30.14(1) de la Loi sur le TCCE exige que, dans son enquête, le Tribunal limite son étude à l’objet de la plainte. À la conclusion de l’enquête, le Tribunal doit décider si la plainte est fondée selon la question de savoir si les procédures et les autres exigences prescrites en ce qui concerne le contrat spécifique ont été respectées.

[34]  L’article 11 du Règlement stipule que le Tribunal doit déterminer si la procédure du marché public a été suivie conformément aux exigences de l’accord commercial applicable, l’Accord révisé sur les marchés publics de l’Organisation mondiale du commerce [16] .

[35]  En l’espèce le Tribunal doit décider du bien‑fondé des motifs de plainte suivants :

1. la question de savoir s’il était raisonnable pour l’équipe d’évaluation technique du MDN de conclure que la soumission de Critical Software ne respectait pas l’exigence technique obligatoire O-2, en particulier la fourniture de références de clients pour au moins deux projets qui comprend le « [p]ourcentage de répartition des utilisateurs par région » [traduction] pour chaque projet;

2. la question de savoir si l’évaluation technique des soumissions (y compris la soumission retenue) a été menée conformément à la procédure indiquée dans la DP en ce qui concerne l’exigence obligatoire O-2.

Motif 1 : la conclusion selon laquelle la soumission de Critical Software n’était pas conforme au critère obligatoire O-2 était raisonnable.

[36]  L’accord commercial applicable prévoit qu’une soumission doit, au moment de son ouverture, être conforme aux prescriptions essentielles énoncées dans la documentation relative à l’appel d’offres pour être considérée en vue d’une adjudication [17] . De plus, une entité contractante doit adjuger le contrat conformément aux critères et aux prescriptions essentielles énoncés dans la documentation relative à l’appel d’offres [18] .

[37]  Lorsqu’il examine s’il y a eu violation des obligations qui précèdent, le Tribunal accorde habituellement crédit dans une large mesure aux évaluations des soumissions faites par les évaluateurs. De façon générale, le Tribunal n’interviendra dans une évaluation que si elle est déraisonnable [19] et substituera son jugement à celui des évaluateurs uniquement si ces derniers n’ont pas évalué consciencieusement une soumission, ont mal interprété la portée d’une condition requise, n’ont pas tenu compte de renseignements cruciaux fournis dans une soumission, ont fondé leur évaluation sur des critères non spécifiées ou que, de toute autre façon, ils n’ont pas respecté la procédure [20] .

[38]  Il incombe aux soumissionnaires de démontrer que leur soumission respecte les critères obligatoires d’un appel d’offres [21] . En d’autres termes, le Tribunal a clairement indiqué que les soumissionnaires ont la responsabilité de préparer leur soumission avec attention conformément aux instructions de l’appel d’offres et de prendre soin de s’assurer que les renseignements fournis démontrent clairement la conformité.

[39]  En l’espèce, la soumission de Critical Software prévoyait des références de clients pour deux projets en réponse à l’exigence obligatoire O-2. L’exigence, qui est indiquée à la pièce jointe 4.1 de la DP, indiquait que le « soumissionnaire doit avoir une expérience en développement et en déploiement d’applications WEB HTML5 interactives nationales » et que « [p]our démontrer cette expérience, on utilisera le service de validation du W3C [...] » (comme on le verra en détail ci-dessous). L’exigence indiquait aussi que le « soumissionnaire doit également fournir des références de clients pour chaque projet (au moins deux projets) pour prouver que le soumissionnaire a bien développé et déployé des applications WEB HTML5 interactives nationales à [au] moins 1 000 utilisateurs », ainsi qu’une liste de renseignements que « doit » comprendre chaque référence [22] .

[40]  L’une des exigences énoncées susmentionnées concernait l’inclusion d’un « pourcentage de répartition des utilisateurs par région » [traduction] pour chaque référence de client. Pour le projet 1 (« Blue Eye »), la soumission de Critical Software abordait cette exigence ainsi [23]  :

Cette application comporte aujourd’hui plus de 1 000 utilisateurs. Les utilisateurs accèdent à l’application de(s) :

trois (3) centres d’opération navale portugais;

l’autorité maritime nationale portugaise;

diverses administrations portuaires;

navires en mer (ou au port).

À l’exception des utilisateurs qui ont accès au système des bâtiments navals dans les zones d’intérêt portugaises (déployés dans les régions comme la mer Méditerranée, le golfe de Guinée, la Corne de l’Afrique, etc.), tous les utilisateurs accèdent au système de la région nationale portugaise.

[Traduction]

[41]  Pour le projet 2 (« Vision Centre »), la soumission de Critical Software indiquait ce qui suit [24]  :

Cette application est utilisée par plus de 1 000 utilisateurs dans plus de 30 pays d’Europe, d’Asie, d’Afrique et d’Amérique du Sud.

[Traduction]

[42]  Dans l’évaluation initiale de la soumission de Critical Software par rapport aux exigences techniques obligatoires, les évaluateurs ont conclu qu’elle n’était pas conforme au critère O-2 (« aucune répartition par pourcentage pour le projet 1 et le projet 2 » [traduction]) [25] . En fait, les cinq soumissions ont toutes été jugées non conformes par les évaluateurs à cette étape [26] .

[43]  Dans le cadre d’une réévaluation recommandée par l’autorité contractante (TPSGC), les évaluateurs ont conclu que Critical Software n’était toujours pas conforme en ce qui concerne l’exigence obligatoire O‑2, une note par consensus indiquant que cette conclusion avait été formulée pour le projet 2 seulement [27] .

[44]  Pour ce qui est du projet 1, les évaluateurs ont été « en mesure de comprendre la répartition (région nationale portugaise) et le pourcentage (100 %, parce que tous les utilisateurs étaient dans une région) » [traduction] [28] . Par conséquent, cette exigence a été jugée respectée au motif que, même si aucune répartition des utilisateurs par pourcentage n’était explicitement mentionnée dans la soumission de Critical Software, les évaluateurs ont pu conclure que 100 % d’entre eux se trouvaient dans une seule région, à savoir le Portugal. À l’inverse, pour ce qui est du projet 2, même si la soumission indiquait des régions dans sa réponse, les évaluateurs n’ont pas pu, avec certitude, déduire de cette réponse que la répartition des utilisateurs par pourcentage visait chaque région [29] .

[45]  Critical Software a admis (dans sa plainte) que sa soumission ne prévoyait pas de pourcentages de répartition des utilisateurs, par région, pour l’un ou l’autre des deux projets qu’elle a présentés en réponse au critère obligatoire O-2. Néanmoins, elle fait valoir qu’il s’agissait d’un « sous-élément ambigu et non pertinent » [traduction] du critère [30] . En particulier, Critical Software soutient que l’exigence de répartition des utilisateurs était imprécise parce que le terme « région » n’était pas défini dans la DP. Dans ses commentaires sur le RIF, Critical Software a également soutenu que l’exigence de fournir un pourcentage de répartition des utilisateurs par région n’était pas un critère d’évaluation obligatoire légitime.

[46]  Le Tribunal fait remarquer que, si Critical Software n’était pas certaine de la signification du terme « région » ou de la façon dont elle devait répondre à l’exigence O-2, elle aurait dû soulever ces préoccupations auprès de TPSGC avant la clôture de l’appel d’offres ou déposer une plainte auprès du Tribunal dans les délais prescrits par l’article 6 du Règlement [31] . Il en va de même pour son affirmation selon laquelle le pourcentage de répartition des utilisateurs par région n’était pas une exigence pertinente ou légitime. Ces allégations sont maintenant forcloses et elles ne peuvent donc pas être examinées par le Tribunal dans la présente instance.

[47]  En outre, TPSGC ni le MDN n’avait l’obligation de demander des précisions à Critical Software quant à sa réponse dans sa soumission au critère O-2. Même si des précisions avaient été demandées, les évaluateurs n’auraient pu en tenir compte si ces renseignements avaient substantiellement modifié la soumission, ce qui aurait constitué une modification inadmissible de la soumission [32] . Même si les évaluateurs pouvaient déduire, en ce qui concerne le projet 1, que 100 % des utilisateurs se trouvaient au Portugal, cette déduction a été faite selon les renseignements qui avaient déjà été fournis dans la soumission [33] . Le Tribunal conclut qu’une déduction semblable n’aurait pu raisonnablement être faite en ce qui concerne le projet 2 selon les renseignements fournis dans la soumission.

[48]  Selon ce qui précède, le Tribunal estime qu’il était raisonnable pour TPSGC de conclure que la soumission de Critical Software ne respectait pas pleinement le critère O-2.

Motif 2 : la démonstration du service de validation W3C n’était pas requise pour l’évaluation technique

[49]  L’AMP exige qu’une entité contractante adjuge le contrat conformément aux exigences obligatoires mentionnées dans la DP. Par conséquent, le Tribunal doit examiner la question de savoir si l’équipe d’évaluation a contrevenu à cette obligation en ne menant pas la démonstration du service de validation W3C dans le cadre de l’évaluation du critère obligatoire O-2. Contrairement aux observations de Critical Software selon lesquelles la procédure de validation était une exigence essentielle pour le respect du critère O-2, TPSGC est d’avis que la procédure de validation était facultative selon les dispositions de la DP. Par conséquent, il s’agit savoir si TPSGC et/ou les évaluateurs ont mal interprété les exigences obligatoires en ce qui concerne le critère O-2.

[50]  Comme mentionné ci-dessus, le critère O‑2 indiquait que, « [p]our démontrer cette expérience, on utilisera le service de validation du W3C [...] » (« [t]o demonstrate this experience, the W3C validation will be used [...] »). Cette phrase, interprétée seule, pourrait être mal comprise, laissant croire que les soumissionnaires pouvaient s’attendre, dans le cadre de la procédure d’évaluation, à ce que TPSGC mène une démonstration en utilisant le service de validation W3C pour vérifier la conformité des soumissions au critère O-2 [34] . TPSGC soutient que cette phrase devait être interprétée avec l’alinéa 4.2(d) de la DP, qui décrit précisément l’utilisation du service de validation W3C afin de démontrer la conformité au critère O-2 et qui indique qu’il s’agit d’une procédure discrétionnaire. Selon l’interprétation que fait le Tribunal de cette phrase, durant une démonstration, TPSGC serait obligé d’utiliser une méthode donnée, le « service de validation W3C », pour vérifier la conformité. Il s’agit d’une obligation volontaire qui montre de façon transparente aux soumissionnaires comment leurs propositions seraient évaluées si une démonstration était menée. 

[51]  La démonstration de l’exigence O-2 est-elle discrétionnaire? La procédure d’évaluation technique figurant à la section 4.2 de la DP crée une distinction entre l’évaluation des soumissions en vue de la conformité avec les exigences obligatoires (en vertu de l’alinéa « a ») et la démonstration de cette conformité, y compris en ce qui concerne le critère O-2, et, en particulier, la procédure de démonstration du service de validation W3C (en vertu de l’alinéa « d »). Cette procédure est décrite ainsi :

(d) Démonstration

Le Canada peut, sans toutefois y être obligé, demander au soumissionnaire classé au premier rang (position établie après l’évaluation financière) de faire la preuve des fonctions, fonctionnalités et capacités décrites dans la présente demande de soumissions ou dans la soumission fournie, afin de confirmer la conformité aux exigences obligatoires O2 et O3 de la présente demande. Pour démontrer la conformité à l’exigence O2, le soumissionnaire doit mettre à la disposition du personnel du MDN une copie de son application ou de ses modules proposés décrits à l’exigence O2 en ligne par Internet. Le MDN utilisera le service de validation de balisage du Consortium World Wide Web (W3C) (https://validator.w3.org/#validate_by_uri+with_options) pour valider au hasard un maximum de quatre (4) pages Web générées par l’application Web HTML5 décrite à l’exigence O2, à l’égard de leur conformité avec la norme HTML5. Le résultat doit indiquer une conformité totale avec la norme HTML5. L’application ou les modules proposés par le soumissionnaire décrits à l’exigence O2, ainsi que le service de validation de balisage W3C seront consultés par Internet. La démonstration sera effectuée par le personnel du MDN situé à Ottawa. Le soumissionnaire doit fournir un soutien hors site par téléphone ou par une communication en ligne à l’appui de la démonstration. Aucun soutien sur place n’est exigé de la part du soumissionnaire. Pour démontrer la conformité à l’exigence O3, [...] [m]algré la soumission écrite, si le Canada détermine pendant une démonstration que la solution proposée par le soumissionnaire ne satisfait pas aux exigences obligatoires de cette demande de soumissions, la soumission sera déclarée irrecevable.

[Nos italiques]

[52]  Selon le Tribunal, comme le fait valoir TPSGC, la disposition qui précède, lorsqu’elle est interprétée avec le critère O-2, indique la nature discrétionnaire de la démonstration de la conformité au moyen du service de validation W3C. Cela est appuyé par le fait que le critère O-2 fournissait la même description des renseignements sur lesquels la validation serait fondée conformément au paragraphe 4.2(2), des détails supplémentaires étant fournis dans ce paragraphe.

[53]  En outre, la lecture des deux dispositions indique que l’entité contractante, au nom du Canada « peut, sans toutefois y être obligé[e] », utiliser le service de validation W3C pour effectuer une démonstration de la conformité au critère O-2. L’alinéa 4.2(d) indique aussi que la tenue de cette démonstration viserait le soumissionnaire classé au premier rang, ce qui signifie qu’elle devait être effectuée après la fin des évaluations techniques et financières [35] . Comme il est également indiqué à l’alinéa 4.2(d), si le Canada exerçait son pouvoir discrétionnaire d’exiger une telle démonstration par le soumissionnaire classé au premier rang et que cette démonstration démontrait que la solution proposée par le soumissionnaire ne satisfaisait pas aux exigences obligatoires de l’appel d’offres, alors, « [m]algré la soumission écrite », la soumission classée au premier rang serait jugée irrecevable.

[54]  Critical Software et EMS soutiennent toutes deux que l’alinéa 4.2(d) de la DP doit, au mieux, être interprété comme accordant à TPSGC le pouvoir discrétionnaire d’exiger qu’une nouvelle démonstration soit effectuée par le soumissionnaire classé au premier rang, si TPSGC choisissait de le faire. Selon elles, il était nécessaire que tous les soumissionnaires fassent une démonstration initiale en vertu des modalités du critère O-2.

[55]  Le renvoi à la démonstration du service de validation W3C figurant dans la description du critère O-2 aurait pu être plus clair en répétant la nature discrétionnaire de la procédure de démonstration, comme indiqué ci-dessus, mais une interprétation contextuelle des modalités de la DP dans leur ensemble appuie l’interprétation selon laquelle le recours au service de validation W3C était une option à la disposition de TPSGC, s’il choisissait de demander une démonstration de la conformité au soumissionnaire classé au premier rang et désigné après l’évaluation technique et financière des soumissions. À ce titre, TPSGC n’avait aucune obligation d’exiger une démonstration pendant l’évaluation technique de chaque soumission selon le critère O-2.

[56]  Subsidiairement, Critical Software et EMS font toutes deux valoir que les modalités de la DP en ce qui concerne la procédure de démonstration étaient ambiguës et qu’elles viciaient toute la procédure d’évaluation. Pour appuyer son argument selon lequel les attentes liées à cette exigence étaient imprécises, EMS renvoie aux questions portant sur le critère O-2 des soumissionnaires éventuels qui ont été publiées dans diverses modifications à la DP, les soumissions techniques de Critical Software et de MDA, les grilles d’évaluation technique et la correspondance interne des fonctionnaires en ce qui concerne la démonstration qui a été menée auprès de MDA après l’adjudication du contrat [36] .

[57]  Le Tribunal a examiné avec soin les documents au dossier, y compris ceux qui invoqués par EMS à cet égard, et il conclut que rien n’appuie l’affirmation selon laquelle la procédure de démonstration indiquée dans la DP était incertaine pour les soumissionnaires éventuels, l’entité contractante ou les évaluateurs. En particulier, les questions des soumissionnaires éventuels mentionnées par EMS ne soulèvent aucune ambiguïté en ce qui concerne la procédure de démonstration du service de validation W3C lié au critère O-2. Le Tribunal n’a obtenu aucune preuve que Critical Software ou un autre fournisseur éventuel a soulevé des questions ou des préoccupations pendant la procédure de l’appel d’offres en ce qui concerne les dispositions de la DP liées à une ambiguïté ou à une confusion quant à la procédure de démonstration, ou au fait qu’une telle démonstration n’a pas été menée durant l’évaluation de la soumission technique. Au contraire, la preuve indique que Critical Software a d’abord soulevé ses préoccupations à cet égard auprès de TPSGC à la réunion de compte rendu qui s’est déroulée le 18 juillet 2018 (c’est-à-dire après l’adjudication du contrat).

[58]  Comme indiqué ci-dessus, TPSGC a entrepris de mener une démonstration de la soumission de MDA après la réunion de compte rendu avec Critical Software. À cet égard, le dossier comprend un courriel d’un fonctionnaire du MDN envoyé à l’autorité contractante à TPSGC pour demander des précisions sur la raison pour laquelle on a demandé au soumissionnaire retenu d’effectuer une démonstration et sur la façon dont les résultats de cette démonstration pourraient influer sur le contrat subséquent. Toutefois, ce courriel indiquait que le fonctionnaire du MDN qui demandait ces précisions n’avait pas participé à la DP et ne connaissait pas les détails de l’appel d’offres [37] . Par conséquent, le Tribunal ne considère pas que cet élément indique que l’autorité contractante ou les évaluateurs ont mal compris la procédure de démonstration facultative indiquée dans la DP.

[59]  Par conséquent, le Tribunal est convaincu que la démonstration mentionnée au critère O-2 devait être interprétée conjointement avec toute la procédure de ces démonstrations en vertu de l’alinéa 4.2(d) de la DP et que, lue dans son ensemble, la DP n’exige pas une démonstration du service de validation W3C par MDA ou un autre soumissionnaire au cours de la procédure d’évaluation technique. Par conséquent, le Tribunal conclut que TPSGC et les évaluateurs ont correctement interprété le critère O-2.

[60]  Quoi qu’il en soit, TPSGC a fourni la preuve que la démonstration menée après l’adjudication du contrat a validé la soumission de MDA en ce qui concerne le critère O-2. Pour ce qui est de l’évaluation qui a eu lieu avant l’adjudication du contrat et la démonstration effectuée après l’adjudication, les commentaires regroupés des évaluateurs, appuyés par leurs notes individuelles, indiquent que la soumission de MDA était conforme au critère O-2 [38] . Selon cette preuve, le Tribunal ne voit rien qui indique que les évaluateurs n’ont pas effectué l’évaluation consciencieusement, n’ont pas tenu compte de renseignements cruciaux fournis dans la soumission de MDA, ont mal interprété l’exigence, ont fondé leur évaluation sur des critères non spécifiés ou que, de toute autre façon, ils n’ont pas respecté la procédure [39] .

Conclusion

[61]  Selon ce qui précède, le Tribunal conclut que TPSGC n’était pas tenu de mener une démonstration afin de vérifier la conformité d’un soumissionnaire au critère obligatoire O-2; toutefois, si TPSGC choisissait de mener cette démonstration, il devait utiliser le service de validation W3C pour démontrer cette conformité. Le Tribunal conclut également que l’évaluation de ce critère, en ce qui concerne les soumissions présentées par Critical Software et MDA respectivement, était raisonnable. Par conséquent, la plainte n’est pas fondée.

FRAIS

[62]  Aux termes de l’article 30.16 de la Loi sur le TCCE, le Tribunal accorde à TPSGC une indemnité raisonnable pour les frais encourus pour avoir répondu à la plainte, indemnité qui doit être versée par Critical Software. Conformément à la Ligne directrice sur la fixation des frais dans une procédure de plainte portant sur un marché public (la Ligne directrice), le Tribunal détermine provisoirement que le degré de complexité de la plainte correspond au degré 1. Même si le degré de complexité de l’approvisionnement peut être considéré comme supérieur au degré 1, le Tribunal est d’avis que la complexité de la plainte et de l’instance ne le dépasse pas. Pour ce qui est de la plainte, elle a soulevé des questions relativement simples qui étaient liées à un critère obligatoire unique de l’évaluation technique des documents de l’appel d’offres. L’instance a été prolongée à 135 jours en raison de la participation de l’intervenante et du délai nécessaire, mais elle n’était pas excessivement compliquée et aucune audience n’a été tenue. À ce titre, le Tribunal détermine provisoirement que le montant de l’indemnité est de 1 150 $.

DÉCISION

[63]  Aux termes du paragraphe 30.14(2) de la Loi sur le TCCE, le Tribunal conclut que la plainte n’est pas fondée.

[64]  Aux termes de l’article 30.16 de la Loi sur le TCCE, le Tribunal accorde à TPSGC une indemnité raisonnable pour les frais encourus pour avoir répondu à la plainte, indemnité qui doit être versée par Critical Software. Conformément à la Ligne directrice, le Tribunal détermine provisoirement que le degré de complexité de la plainte correspond au degré 1 et que le montant de l’indemnité est de 1 150 $. Si l’une ou l’autre des parties n’est pas d’accord en ce qui a trait à la détermination provisoire du degré de complexité ou du montant de l’indemnité, elle peut déposer des observations auprès du Tribunal, en conformité avec l’article 4.2 de la Ligne directrice. Il relève de la compétence du Tribunal de fixer le montant définitif de l’indemnité.

Randolph W. Heggart

Randolph W. Heggart Membre présidant

 

ANNEXE

MODALITÉS PERTINENTES DE L’APPEL D’OFFRES

PARTIE 4 – PROCÉDURES D’ÉVALUATION ET MÉTHODE DE SÉLECTION

4.1  Procédures d’évaluation

(a)  Les soumissions reçues seront évaluées par rapport à l’ensemble des exigences de la demande de soumissions, y compris les critères d’évaluation techniques et financiers.

(b)  Une équipe d’évaluation composée de représentants du Canada évaluera les soumissions.

(c)  En plus de tout autre délai prescrit dans la demande de soumissions :

(i)  Demandes de précisions : Si le Canada demande des précisions au soumissionnaire au sujet de sa soumission ou s’il veut vérifier celle-ci, le soumissionnaire disposera d’un délai de deux jours ouvrables (ou d’un délai plus long précisé par écrit par l’autorité contractante) pour fournir les renseignements nécessaires au Canada. À défaut de respecter ce délai, la soumission sera jugée non recevable.

(ii)  Demande de renseignements supplémentaires : Si le Canada demande d’autres renseignements supplémentaires pour l’une des raisons qui suivent (selon la section intitulée « Déroulement de l’évaluation » du document 2003, Instructions uniformisées – biens ou services – besoins concurrentiels) :

(A)  vérifier tout renseignement fourni par le soumissionnaire dans sa soumission;

(B)  communiquer avec une ou plusieurs des références citées par le soumissionnaire (références citées dans les curriculum vitæ des ressources individuelles) dans le but de valider les renseignements fournis par le soumissionnaire,

  le soumissionnaire doit soumettre les renseignements demandés par le Canada dans les deux jours ouvrables suivant la demande de l’autorité contractante.

(iii)  Prolongation du délai : Si le soumissionnaire a besoin de davantage de temps, l’autorité contractante, à sa seule discrétion, peut accorder une prolongation du délai.

4.2  Évaluation technique

(a)  Critères techniques obligatoires :

(i)  Chaque soumission fera l’objet d’un examen pour en déterminer la conformité avec les exigences obligatoires de la demande de soumissions. Tous les éléments de la demande de soumissions qui constituent des exigences obligatoires sont désignés précisément par les termes « doit », « doivent » ou « obligatoire ». Les soumissions qui ne sont pas conformes à chacune des exigences obligatoires seront déclarées non recevables et rejetées.

(ii)  Les critères techniques obligatoires sont décrits dans la pièce jointe 4.1.

(b)  Critères techniques cotés :

Chaque soumission sera cotée en attribuant une note aux exigences cotées, qui sont précisées dans la demande de soumissions par le terme « cotées » ou par voie de référence à une note. Les soumissionnaires qui ne présentent pas de soumissions complètes contenant tous les renseignements exigés dans la demande de soumissions verront leurs soumissions cotées en conséquence. Les critères techniques cotés sont décrits dans la pièce jointe 4.1.

[...]

(d)  Démonstration

Le Canada peut, sans toutefois y être obligé, demander au soumissionnaire classé au premier rang (position établie après l’évaluation financière) de faire la preuve des fonctions, fonctionnalités et capacités décrites dans la présente demande de soumissions ou dans la soumission fournie, afin de confirmer la conformité aux exigences obligatoires O2 et O3 de la présente demande. Pour démontrer la conformité à l’exigence O2, le soumissionnaire doit mettre à la disposition du personnel du MDN une copie de son application ou de ses modules proposés décrits à l’exigence O2 en ligne par Internet. Le MDN utilisera le service de validation de balisage du Consortium World Wide Web (W3C) (https://validator.w3.org/#validate_by_uri+with_options) pour valider au hasard un maximum de quatre (4) pages Web générées par l’application Web HTML5 décrite à l’exigence O2, à l’égard de leur conformité avec la norme HTML5. Le résultat doit indiquer une conformité totale avec la norme HTML5. L’application ou les modules proposés par le soumissionnaire décrits à l’exigence O2, ainsi que le service de validation de balisage W3C seront consultés par Internet. La démonstration sera effectuée par le personnel du MDN situé à Ottawa. Le soumissionnaire doit fournir un soutien hors site par téléphone ou par une communication en ligne à l’appui de la démonstration. Aucun soutien sur place n’est exigé de la part du soumissionnaire. Pour démontrer la conformité à l’exigence O3, [...] [m]algré la soumission écrite, si le Canada détermine pendant une démonstration que la solution proposée par le soumissionnaire ne satisfait pas aux exigences obligatoires de cette demande de soumissions, la soumission sera déclarée irrecevable.

[...]

4.4  Méthode de sélection

(a)  Évaluation des soumissions

Processus de sélection : Le processus de sélection suivant sera suivi pour chaque soumission.

(i)  Pour être déclarée recevable, une soumission doit respecter les exigences de la demande de soumissions, satisfaire à tous les critères d’évaluation obligatoires et obtenir la note de passage indiquée pour les critères cotés indiqués dans la demande de soumissions.

(ii)  La soumission recevable obtenant la note totale la plus haute sera recommandée pour l’attribution d’un contrat. La note maximale qu’un soumissionnaire peut obtenir pour le mérite technique est de 60; la note maximale en ce qui concerne le prix est établie à 40.

• (A) Calcul de la note technique totale : On calculera la note technique totale pour chaque soumission recevable en convertissant la note technique obtenue pour les critères techniques cotés par points à l’aide de la formule suivante (le résultat étant arrondi à deux décimales).

Note technique      ×   60 = Note technique totale

Note technique maximale

• (B) Calcul de la note financière totale : On calculera la note financière totale pour chaque soumission recevable en convertissant la note financière obtenue pour l’évaluation financière à l’aide de la formule suivante (le résultat étant arrondi à deux décimales).

Prix total le plus bas      ×   40 = Note financière finale

Prix total de la soumission du soumissionnaire

• (C) Calcul de la note totale du soumissionnaire – La note totale du soumissionnaire sera calculée pour chaque soumission recevable selon la formule suivante :

Note technique totale + note financière totale = note totale du soumissionnaire

[...]

PIÈCE JOINTE 4.1

CRITÈRES D’ÉVALUATION DES SOUMISSIONS

[...]

SECTION 1 : CRITÈRES D’ÉVALUATION OBLIGATOIRES

[...]

O-2 Application WEB

Le soumissionnaire doit avoir une expérience en développement et en déploiement d’applications WEB HTML5 interactives nationales.

Pour démontrer cette expérience, on utilisera le service de validation du W3C pour vérifier jusqu’à quatre (4) pages générées par l’application, sélectionnées de façon aléatoire, pour vérifier si elles respectent bien la norme HTML5. Le résultat doit indiquer que les pages sont entièrement conformes, ce qui signifie qu’elles répondent aux critères obligatoires de la présente évaluation.

Le soumissionnaire doit également fournir des références de clients pour chaque projet (au moins deux projets) pour prouver que le soumissionnaire a bien développé et déployé des applications WEB HTML5 interactives nationales à moins [sic] 1 000 utilisateurs. Chaque référence doit inclure les éléments suivants :

a.  nom de l’application,

b.  nom et coordonnées du client (y compris le nom et le numéro de téléphone ou l’adresse de messagerie électronique de la personne de l’organisation responsable du projet;

c.  date de début et de fin du projet;

d.  description du projet en mettant l’accent sur les éléments WEB (cases à cocher, boutons, glissières, etc.);

e.  description des composantes interactives utilisées dans l’application;

f.  répartition des utilisateurs par pourcentage et par région.