Dossier no PR-2019-068 SoftSim Technologies Inc.

Décision prise le mercredi 25 mars 2020 Décision rendue le jeudi 26 mars 2020 Motifs rendus le lundi 6 avril 2020

 

EU ÉGARD À une plainte déposée 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.).

PAR

SOFTSIM TECHNOLOGIES INC.

CONTRE

INSTITUTS DE RECHERCHE EN SANTÉ DU CANADA

DÉCISION

Aux termes du paragraphe 30.13(1) de la Loi sur le Tribunal canadien du commerce extérieur, le Tribunal canadien du commerce extérieur décide de ne pas enquêter sur la plainte.

EXPOSÉ DES MOTIFS

[1]  En vertu du paragraphe 30.11(1) de la Loi sur le Tribunal canadien du commerce extérieur [1] , tout fournisseur potentiel peut, sous réserve du Règlement sur les enquêtes du Tribunal canadien du commerce extérieur sur les marchés publics [2] , déposer une plainte auprès du Tribunal canadien du commerce extérieur concernant la procédure des marchés publics suivie relativement à un contrat spécifique et lui demander d’enquêter sur cette plainte. En vertu du paragraphe 30.13(1) de la Loi sur le TCCE, après avoir jugé la plainte conforme au paragraphe 30.11(2) de la Loi sur le TCCE et sous réserve du Règlement, le Tribunal détermine s’il y a lieu d’enquêter.

RÉSUMÉ DE LA PLAINTE

[2]  La présente plainte concerne une demande de propositions (DP) (invitation n^o TBIPS-RFP-CIHR-JAVA-01-2020) publiée par les Instituts de recherche en santé du Canada (IRSC) pour la prestation des services d’un programmeur/analyste (niveau 2) pour le Volet 1 sous l’arrangement en matière d’approvisionnement pour les services professionnels en informatique centrés sur les tâches (n^o EN578-170432).

[3]  La partie plaignante, SoftSim Technologies Inc. (SoftSim), soutient que les IRSC ont 1) rédigé les documents de l’appel d’offres de manière à avantager le titulaire; 2) modifié la DP de manière erronée; 3) conclu à tort que la soumission de SoftSim ne remplissait pas le critère obligatoire O3. À titre de mesure corrective, SoftSim demande que l’adjudication du marché soit différée, qu’un nouvel appel d’offres soit publié, que le contrat spécifique soit résilié et lui soit attribué, et que le Tribunal lui accorde une compensation d’un montant à déterminer par ce dernier. SoftSim demande également le remboursement des frais liés à la plainte et à la préparation de sa soumission.

CONTEXTE

[4]  L’appel d’offres a été publié le 20 janvier 2020. Les critères O2 et O3, entre autres critères obligatoires, exigeaient ce qui suit :

Programmeur/analyste (niveau 2)

No de critère	Exigences obligatoires	Satisfaite/non satisfaite	Renvoi dans la soumission (no de page) et commentaires
[...]	[...]	[...]	[...]
O2	Le soumissionnaire DOIT démontrer que la ressource proposée a au moins trois (3) années d’expérience de l’utilisation de chacune des technologies suivantes pour le développement d’applications Web : · J2EE · Cadres Struts et Spring · JSP · JMS · AJAX · iText · JavaScript · JUnit · XML · SQL · PL/SQL · Oracle WebLogic Server 11g/Oracle Application Server 11g · Oracle Database 11g · Services Web (RESTful et protocole SOAP) · OpenId Le soumissionnaire DOIT fournir l’information suivante pour chaque application et système : a) le nom de l’organisation cliente; b) le nom de la référence du client, son numéro de téléphone ou son adresse de courriel; c) une brève description du rôle, y compris la portée, les livrables, les objectifs à atteindre et les résultats (résultat des travaux); d) les dates de début et de fin du projet ou des projets.
O3	Le soumissionnaire DOIT démontrer que la ressource proposée a de l’expérience en développement d’applications Web au moyen de toutes les technologies suivantes : a) Angular b) OAuth 2 c) Hibernate d) Java 11 e) WebLogic 12c Le soumissionnaire DOIT fournir l’information suivante pour chaque application et système : a) le nom de l’organisation cliente; b) le nom de la référence du client, son numéro de téléphone ou son adresse de courriel; c) une brève description du rôle, y compris la portée, les livrables, les objectifs à atteindre et les résultats (résultat des travaux); d) les dates de début et de fin du projet ou des projets.
[...]	[...]	[...]	[...]

[Traduction]

[5]  Le 29 janvier 2020, SoftSim a envoyé un courriel aux IRSC dans lequel elle manifestait son intérêt à l’égard de l’appel d’offres et disait espérer que l’évaluation serait équitable. SoftSim y soulignait également que « [l]es critères obligatoires et cotés ont manifestement été rédigés pour le titulaire, MindWire. Nous vous demandons de bien vouloir assouplir les exigences afin d’éliminer les restrictions qui font que seul le titulaire pourra être retenu » [traduction].

[6]  Le 30 janvier 2020, les IRSC ont répondu à SoftSim que l’appel d’offres avait été rédigé de manière juste, honnête et transparente, en conformité avec la procédure d’appel d’offres. Les IRSC demandaient également à SoftSim d’expliquer sa demande d’assouplissement des exigences.

[7]  SoftSim a répondu le même jour que les libellés des critères obligatoires et des critères cotés étaient rédigés de telle sorte qu’il était impossible de satisfaire aux exigences à moins d’être le titulaire. En particulier, SoftSim déplorait qu’il faille avoir trois ans d’expérience de l’utilisation de versions particulières de 15 technologies, de la version 11 de Java et de la version 11g d’Oracle. SoftSim proposait que le candidat puisse avoir de l’expérience dans seulement 75 p. 100 des technologies demandées, de deux à trois ans d’expérience acquise au cours des cinq années précédentes dans le cas de Java, et que la version 11g d’Oracle soit remplacée par la version 9 [3] .

[8]  Le 31 janvier 2020, les IRSC ont répondu à SoftSim qu’ils tiendraient compte de ses commentaires et fourniraient une réponse au plus tard le 3 février 2020, sous la forme d’une modification officielle. Le même jour, SoftSim a encore une fois répondu que l’appel d’offres avait été rédigé pour le titulaire, qu’il reprenait le curriculum vitæ du titulaire et que l’autorité contractante avait pour responsabilité de veiller à ce que son client ne favorise pas un fournisseur en particulier.

[9]  Le 3 février 2020, la modification n^o 004 a été publiée [4] . Cette modification prévoyait ce qui suit en ce qui concerne les critères obligatoires O2 et O3 :

Modification n^o 004

[...]

Question 6

O2 :

Les IRSC pourraient-ils envisager de retirer certaines technologies?

Réponse 6

Les IRSC conviennent de ce qui suit :

a)  retirer OpenID;

b)  exiger plutôt Oracle 11g Application/WebLogic Server (ou version supérieure);

c)  exiger plutôt Oracle 11g Database (ou version supérieure).

Question 7

O3 :

Les IRSC retireront-ils la version 11 de Java et certaines autres technologies?

Réponse 7

a)  OpenId est ajouté à la liste des technologies;

b)  Java 11 est remplacé par Java 8 ou une version supérieure;

c)  Weblogic 12c est retiré.

[Traduction]

[10]  Le 11 février 2020, SoftSim a envoyé un courriel aux IRSC dans lequel elle réitère notamment que l’appel d’offres a été rédigé de manière à favoriser le titulaire. SoftSim a également déposé auprès du Tribunal une copie d’une série de messages texte non datés qui auraient été échangés avec son candidat vers cette date, et où ce dernier affirme : « Simplement pour dire que j’ai parlé à mon ancien patron aux IRSC et que le poste s’adresse à quelqu’un qui est déjà là depuis au moins dix ans. Donc nous n’avons aucune chance » [traduction].

[11]  Le 12 février 2020, SoftSim a déposé sa soumission. La date de clôture de l’appel d’offres était le 13 février 2020.

[12]  Le 14 février 2020, SoftSim a écrit à l’autorité contractante des IRSC pour s’assurer encore une fois que sa soumission serait évaluée équitablement. SoftSim prétendait par ailleurs que l’autorité technique des IRSC avait proféré des menaces au candidat de SoftSim afin qu’il ne réponde pas à l’appel d’offres.

[13]  Le 9 mars 2020, les IRSC ont avisé SoftSim que Mindwire Systems Ltd., le titulaire, était le soumissionnaire retenu. Ils informaient également SoftSim que sa soumission ne répondait pas au critère obligatoire O3, l’équipe d’évaluation n’ayant pas été en mesure d’y trouver de référence à l’expérience au regard d’OpenID. Les IRSC l’informaient qu’elle avait en revanche obtenu le pointage maximal aux critères cotés.

[14]  Le même jour, SoftSim a déposé une plainte incomplète auprès du Tribunal. Elle a également envoyé un courriel aux IRSC pour signaler qu’OpenID avait été retiré de la liste des technologies exigées, selon la question et réponse n^o 6 de la modification n^o 004.

[15]  Le 10 mars 2020, SoftSim a écrit à l’autorité contractante des IRSC pour répéter que l’autorité technique avait demandé au candidat de SoftSim de ne pas répondre à l’appel d’offres.

[16]  Entre le 10 et le 19 mars 2020, SoftSim a soumis des documents supplémentaires en réponse aux demandes répétées du Tribunal en ce sens, et la plainte a finalement été dûment déposée le 19 mars 2020.

ANALYSE

[17]  Le 25 mars 2020, aux termes du paragraphe 30.13(1) de la Loi sur le TCCE, le Tribunal a décidé de ne pas enquêter sur la plainte pour les raisons qui suivent.

Dépôt en temps opportun

[18]  Premièrement, le Tribunal conclut que les deux premiers motifs de plainte sont forclos. Le paragraphe 6(1) du Règlement exige qu’un fournisseur potentiel dépose une plainte dans les 10 jours ouvrables suivant la date où il a découvert ou aurait dû vraisemblablement découvrir les faits à l’origine de la plainte. Le paragraphe 6(2) du Règlement exige qu’un fournisseur potentiel qui a présenté à l’institution fédérale concernée une opposition dépose une plainte auprès du Tribunal dans les 10 jours ouvrables suivant la date où il a pris connaissance, directement ou par déduction, du refus de réparation.

[19]  En outre, le Tribunal a indiqué à maintes reprises qu’il incombe aux soumissionnaires d’être « vigilants et qu’ils réagissent dès qu’ils découvrent ou auraient vraisemblablement dû découvrir un vice de procédure [5]  ». Il revient au soumissionnaire d’être à l’affût de tout problème potentiel dans le cadre d’un appel d’offres et de déposer une plainte en temps opportun.

[20]  Compte tenu de la chronologie des faits exposés précédemment, c’est entre le 3 et le 13 février 2020, soit plus d’un mois avant que la plainte soit dûment déposée auprès du Tribunal, le 19 mars 2020, que SoftSim aurait dû découvrir ses deux premiers motifs de plainte et, dans le cas du premier motif, savoir que l’institution fédérale n’accorderait pas de réparation.

[21]  En ce qui a trait au premier motif de plainte, c’est entre le 29 janvier et le 31 janvier 2020 que SoftSim s’est d’abord plainte que l’appel d’offres des IRSC avait été rédigé de manière à favoriser le titulaire. Les IRSC ont donné suite à cette plainte en publiant la modification n^o 004, le 3 février 2020. Bien qu’elle ait par la suite formulé à nouveau ce motif de plainte auprès des IRSC, SoftSim aurait dû comprendre que ses préoccupations ne feraient pas l’objet d’autres mesures au plus tard le jour où l’appel d’offres a pris fin, c’est-à-dire le 13 février 2020. SoftSim n’aurait pas dû attendre l’adjudication du marché au titulaire, laquelle selon elle « prouvait que ses doutes étaient fondés » [traduction], pour soumettre ce motif de plainte au Tribunal [6] .

[22]  SoftSim aurait dû découvrir son second motif de plainte à la suite de la publication de la modification n^o 004, le 3 février 2020. Dans la plainte qu’elle a déposée auprès du Tribunal, SoftSim affirme que les IRSC n’ont pas respecté les dispositions de l’Accord sur les marchés publics de l’Organisation mondiale du commerce ^[7] en ne fournissant pas de tableau révisé des critères obligatoires et en fournissant de l’information contradictoire dans la modification n^o 004. En particulier, SoftSim soutient que le retrait de l’exigence liée à OpenID au critère obligatoire O2 à la question et réponse 6, puis son ajout au critère obligatoire O3 à la question et réponse 7 portaient à confusion, d’autant plus que la question 7 avait pour but de savoir si certaines technologies pouvaient être retirées de l’appel d’offres. Or, SoftSim n’a pas soulevé de questions quant à l’interprétation des changements apportés au critère O3 dans la modification n^o 004 avant d’avoir été avisée qu’elle n’obtiendrait pas de contrat, le 9 mars 2020.

[23]  Ainsi, SoftSim n’a pas déposé ces deux motifs de plainte dans les 10 jours ouvrables suivant la date où elle a découvert ou aurait dû découvrir ses motifs de plainte, ou dans les 10 jours ouvrables suivant le refus de réparation de l’institution fédérale.

Indication raisonnable d’une violation

[24]  Deuxièmement, aux termes de l’alinéa 7(1)c) du Règlement, le Tribunal peut enquêter sur une plainte si celle-ci démontre, dans une mesure raisonnable, que la procédure du marché public n’a pas été suivie conformément aux accords commerciaux applicables. En l’espèce, le Tribunal conclut qu’aucun des motifs de plainte de SoftSim ne révèle, dans une mesure raisonnable, que les IRSC ont violé les dispositions des accords commerciaux applicables [8] .

Premier motif : l’appel d’offres a été rédigé de manière à favoriser le titulaire

[25]  Même en omettant le retard susmentionné, le premier motif de plainte de SoftSim ne révèle pas, dans une mesure raisonnable, la violation d’un accord commercial. SoftSim n’a fourni aucun élément de preuve étayant l’allégation selon laquelle l’appel d’offres a été rédigé de manière à favoriser le titulaire. À l’annexe 2 de la DP, intitulée « Énoncé des travaux », il est mentionné que les exigences techniques de la DP reposent sur l’environnement logiciel actuel des IRSC [9]  :

8. Environnement technique

ResearchNet est une application J2EE multiniveau déployée dans Oracle Application Server au moyen des cadres Struts, Tiles et Spring. XML est utilisé pour l’échange de données. Oracle 11g est utilisé pour le serveur de base de données. L’environnement de développement intégré My Eclipse est utilisé pour écrire le code source et Subversion est utilisé pour le contrôle de code source. JUnit est utilisé comme cadre d’application d’essai. Les formulaires PDF sont conçus au moyen des bibliothèques Nuance et iText.

La base de données sur les décisions de financement (Funding Decisions Database) est une application Web J2EE qui utilise la plateforme SOLR pour effectuer les recherches à facettes. Les index SOLR sont créés à partir des données relationnelles stockées dans un serveur de base de données Oracle 11g.

Les services Web sont utilisés pour prendre en charge une fonctionnalité étendue des systèmes, en combinaison avec le cadre d’autorisation OAuth2.

OpenID est utilisé pour mettre en œuvre une authentification unique entre les anciens systèmes des IRSC.

[Traduction]

[26]  SoftSim elle-même l’a reconnu en affirmant ce qui suit, le 30 janvier 2020 :

À chacun des critères, votre client a dressé une liste de technologies, dont le nombre va jusqu’à 15, et le candidat proposé doit posséder trois ans d’expérience dans chacune d’elle. Il s’agit d’une mission impossible, parce que le seul endroit sur la planète où on retrouve réunies les versions exactes de ces 15 technologies est l’environnement CCV/ResearchNet qui est actuellement en place aux IRSC.

[Traduction]

[27]  Le Tribunal a souvent affirmé que l’entité contractante a le droit de structurer un appel d’offres, de même que les critères d’évaluation technique, de façon à répondre à ses besoins opérationnels légitimes [10] . En l’espèce, il est compréhensible et raisonnable que les IRSC aient demandé de l’expérience dans les technologies énoncées dans la DP, et cela ne démontre pas que l’appel d’offres a été rédigé de manière à avantager le titulaire.

[28]  Qui plus est, on s’attendrait à ce que le titulaire ait de l’expérience dans ces technologies, puisqu’il a travaillé dans l’environnement logiciel des IRSC. Comme il a déjà été mentionné par le Tribunal, le fait d’être le titulaire ne constitue pas, en soi, un avantage injuste [11] .

[29]  En l’absence d’éléments de preuve démontrant le contraire, le Tribunal conclut que l’appel d’offres n’a pas été rédigé de manière à avantager le titulaire, mais plutôt afin de répondre à des besoins opérationnels légitimes.

Deuxième motif : l’appel d’offres n’a pas été modifié correctement

[30]  Encore une fois, même n’eût été le retard dont il a été question précédemment, le deuxième motif de plainte de Softsim ne révèle pas non plus, dans une mesure raisonnable, la violation d’un accord commercial. Le Tribunal conclut que les IRSC n’ont pas modifié de manière erronée l’appel d’offres.

[31]  Le Tribunal souligne que rien dans les accords commerciaux ne prescrit la forme que doivent prendre les modifications. Les accords commerciaux exigent seulement que les modifications soient communiquées aux soumissionnaires éventuels [12] . Ainsi, les IRSC n’étaient nullement tenus de publier un tableau révisé tenant compte des modifications apportées aux critères obligatoires O2 et O3 conformément aux questions et réponses 6 et 7 de la modification n^o 004.

[32]  En outre, le Tribunal conclut que la modification n^o 004 énonçait clairement qu’OpenID était ajouté à la liste des technologies exigées au critère obligatoire O3 [13] . Quoi qu’il en soit, comme il est mentionné précédemment, SoftSim n’a pas donné suite à la question dans les délais impartis et, ainsi, elle ne peut demander au Tribunal d’intervenir maintenant.

Troisième motif : il a été conclu à tort que la soumission de SoftSim ne remplissait pas le critère obligatoire O3

[33]  Eu égard au troisième motif de plainte de SoftSim, le Tribunal est d’avis que les IRSC ont conclu avec raison que la soumission de SoftSim ne remplissait pas le critère obligatoire O3. De fait, rien n’indique, dans une mesure raisonnable, qu’il y a eu violation des accords commerciaux.

[34]  SoftSim soutient qu’il n’était pas loisible aux IRSC de procéder à une nouvelle évaluation des critères obligatoires une fois qu’elle en était à évaluer les critères cotés. Selon SoftSim, le fait que les IRSC ont évalué les critères cotés pour SoftSim implique que cette dernière a initialement eu la note de passage aux critères obligatoires, car la section 4.1.1.2 consacrée aux critères techniques cotés prévoit que « [l]e soumissionnaire doit avoir rempli chacun des critères obligatoires susmentionnés pour qu’un pointage lui soit accordé selon les critères [cotés] » [traduction].

[35]  SoftSim a présenté des arguments similaires dans d’autres plaintes déposées auprès du Tribunal (notamment dans le dossier n^o PR-2019-057 du Tribunal). Cet argument n’est pas fondé. En tout temps, il incombe à une institution fédérale de corriger les erreurs dès qu’elle les constate [14] , et c’est ce que les IRSC ont fait lors de la nouvelle évaluation. Le fait que les IRSC sont passés par erreur à l’évaluation des critères cotés n’excuse en rien le non-respect des critères obligatoires de la part de SoftSim, peu importe que ce non-respect ait été découvert si tard.

[36]  De plus, le Tribunal a toujours soutenu qu’il incombe au soumissionnaire de s’assurer que sa proposition est conforme à tous les éléments essentiels de l’appel d’offres et que, par conséquent, il incombe au soumissionnaire de faire preuve de diligence raisonnable dans la préparation de sa proposition et de vérifier qu’elle est conforme à tous les éléments essentiels [15] .

[37]  En l’espèce, l’appel d’offres contenait des exigences claires : la soumission devait remplir toutes les exigences obligatoires pour être jugée recevable [16] . Par conséquent, il incombait à SoftSim de s’assurer qu’elle remplissait les critères obligatoires, tels qu’ils avaient été modifiés. Or, comme l’ont fait remarquer les IRSC, la soumission de SoftSim ne faisait aucunement mention d’une expérience de l’utilisation d’OpenID, de sorte qu’elle ne remplissait pas le critère obligatoire modifié O3.

Allégations non fondées

[38]  Le Tribunal souligne enfin que selon SoftSim, le titulaire n’a pas l’expérience demandée de l’utilisation d’OpenID. Le Tribunal a toujours soutenu qu’il faut plus que des allégations imprécises pour qu’une enquête soit ouverte [17] . En l’espèce, SoftSim n’a fourni aucun élément de preuve concernant cette allégation, se contentant d’affirmer que son candidat avait « déclaré que personne aux IRSC, y compris le titulaire [...] n’a une quelconque expérience d’OpenID » [traduction] et que « les IRSC ont fait appel à quelqu’un des États-Unis parce qu’ils n’ont pas réussi à trouver quiconque au Canada possédant cette expérience » [traduction]. Une telle allégation non étayée ne constitue pas un élément de preuve suffisant pour que le Tribunal ouvre une enquête.

[39]  En dernier lieu, le Tribunal prévient les parties plaignantes qu’elles ne devraient pas faire des allégations vagues et non fondées dans le but de mettre en doute l’intégrité d’entités contractantes ou de fonctionnaires en particulier. SoftSim n’a fait preuve d’aucune retenue à cet égard, au point où son comportement pourrait avoir atteint le stade de l’intimidation ou du harcèlement [18] . Le Tribunal tient pour acquis que toutes les parties sont de bonne foi. La partie plaignante ne devrait pas remettre en question les actions des fonctionnaires en prétendant la mauvaise foi, ou pire, à moins qu’elle ait en sa possession des éléments de preuve étayés de faits concrets. Aucun élément de preuve du genre n’a été déposé en l’espèce. Dans les affaires menant à une enquête approfondie, le Tribunal peut condamner aux dépens les parties qui font de telles allégations de façon arbitraire ou téméraire, à titre de mesure de dissuasion ou de sanction négative d’un tel comportement.

DÉCISION

[40]  Aux termes du paragraphe 30.13(1) de la Loi sur le TCCE, le Tribunal décide de ne pas enquêter sur la plainte.