---

---

TABLE DES MATIÈRES

• DÉCISION DU TRIBUNAL
• EXPOSÉ DES MOTIFS
• • PLAINTE
  • CONTEXTE
  • QUESTIONS PRÉLIMINAIRES
  • • Motifs de l’ordonnance du Tribunal du 6 janvier 2010
  • ANALYSE DU TRIBUNAL
  • • Position de M&S
    • Position de TPSGC
    • Position de Sierra
    • Analyse du Tribunal
    • Frais
  • DÉCISION DU TRIBUNAL

---

EU ÉGARD À une plainte déposée par Microsoft Canada Co., Microsoft Corporation, Microsoft Licensing, GP et Softchoice Corporation 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 À 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
MICROSOFT CANADA CO., MICROSOFT CORPORATION, MICROSOFT LICENSING, GP ET SOFTCHOICE CORPORATION	Partie plaignante
ET
LE MINISTÈRE DES TRAVAUX PUBLICS ET DES SERVICES GOUVERNEMENTAUX	Institution fédérale

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 de l’article 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 le remboursement des frais raisonnables qu’il a engagés pour répondre à la plainte, ces frais devant être payés par Microsoft Canada Co., Microsoft Corporation, Microsoft Licensing, GP et Softchoice Corporation. En conformité avec la Ligne directrice sur la fixation des frais dans une procédure de plainte portant sur un marché public, le Tribunal canadien du commerce extérieur assigne un degré 3 de niveau de complexité à cette plainte et une indication provisoire du montant d’indemnisation de 3 000 $. Si l’une ou l’autre des parties n’est pas d’accord avec cette indication provisoire du degré de complexité ou cette indication provisoire du montant de l’indemnisation, elle peut déposer des observations auprès du Tribunal canadien du commerce extérieur, en conformité avec la Ligne directrice sur la fixation des frais dans une procédure de plainte portant sur un marché public. Le Tribunal canadien du commerce extérieur se réserve la compétence de fixer le montant définitif de l’indemnisation.

Dominique Laporte
Dominique Laporte
Secrétaire

Membre du Tribunal :	André F. Scott, membre présidant
Directeur :	Randolph W. Heggart
Gestionnaire de l’enquête :	Michael W. Morden
Conseiller juridique pour le Tribunal :	Eric Wildhaber
Parties plaignantes :	Microsoft Canada Co., Microsoft Corporation, Microsoft Licensing, GP et Softchoice Corporation
Conseillers juridiques pour les parties plaignantes :	Paul Conlin Gregory Somers G. Ian Clarke Heather Cameron Benjamin P. Bedard
Partie intervenante :	Sierra Systems Group Inc.
Conseillers juridiques pour la partie intervenante :	Martin G. Masse Geoffrey C. Kubrick Corinne Brûlé
Institution fédérale :	Ministère des Travaux publics et des Services gouvernementaux
Conseillers juridiques pour l’institution fédérale :	David M. Attwater Susan D. Clarke Ian McLeod David Covert

Veuillez adresser toutes les communications au :

PLAINTE

1. Le 29 octobre 2009, Microsoft Canada Co., Microsoft Corporation, Microsoft Licensing, GP et Softchoice Corporation (M&S) déposaient 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 ¹ . La plainte porte sur un présumé nouveau marché public passé par le ministère des Travaux publics et des Services gouvernementaux (TPSGC) au nom du ministère de la Santé (Santé Canada), pour lequel il est allégué que TPSGC a utilisé un contrat existant passé en 2005 avec Sierra Systems Group Inc. (Sierra) portant sur une solution logicielle de portail unifié (SLPU).

2. M&S allègue que le contrat SLPU prévoyait l’achat d’une série de produits d’Oracle Corporation (Oracle), y compris certaines licences concernant Oracle Collaboration Suite (OCS). M&S soutient qu’Oracle a cessé d’offrir l’OCS en 2008 pour fournir à la place des licences Oracle Beehive. M&S allègue que TPSGC a tenté à tort de déployer une solution de courrier électronique au moyen d’applications visées par des licences Oracle Beehive, alors que les licences comportant cette fonctionnalité ne sont pas visées par le contrat SLPU. Par conséquent, M&S soutient que les produits actuellement fournis sont sensiblement différents de ceux qui sont décrits dans l’invitation portant sur la SLPU et que le marché qui en est résulté constitue une acquisition inappropriée d’un nouveau produit puisque aucune procédure concurrentielle des marchés publics n’a été suivie.

3. Afin de remédier à cette situation, M&S demande que TPSGC cesse le déploiement, à Santé Canada, de la solution présumée nouvelle de courrier électronique et qu’il applique une procédure des marchés publics concurrentielle en vue de la fourniture de logiciels de courrier électronique à Santé Canada et dans tout autre ministère où le déploiement de logiciels de courrier électronique en vertu du contrat SLPU est terminé, en cours ou projeté. De plus, M&S demande que le Tribunal recommande que M&S et TPSGC négocient un montant approprié d’indemnisation qui tient compte du marché éventuel perdu par M&S à ce jour, de la gravité des irrégularités dans la procédure des marché public et du préjudice causé à l’intégrité du mécanisme d’adjudication. Elle demande aussi ses frais sur la base procureur-client.

CONTEXTE

4. Le 7 octobre 2004, TPSGC diffusait la demande de proposition (DP) portant sur la SLPU par l’intermédiaire du MERX² . Seize modifications en réponse à 418 questions posées par des soumissionnaires potentiels ont été diffusées et la période de présentation des soumissions se terminait le 16 décembre 2004. TPSGC aurait reçu deux soumissions conformes soit une de Sierra et l’autre d’IBM (Canada) Ltd.

5. Le 27 mai 2005, conformément aux dispositions de la DP relative à l’évaluation des soumissions et à l’adjudication du contrat, TPSGC accordait à Sierra le contrat portant sur la fourniture d’« [...] une solution logicielle de portail unifié comprenant notamment un logiciel sous licence, une garantie, l’entretien, le soutien, la formation, la documentation et les services professionnels connexes de même que l’ensemble des droits de licence prévus aux présentes » [traduction]. Le contrat précisait de plus ce qui suit : « Le Canada souhaite que la solution logicielle de portail unifié permette aux Canadiens et à d’autres utilisateurs d’avoir accès aux sites Web [du gouvernement du Canada] par l’intermédiaire de services de portail à interface externe (y compris les services fondés sur Internet) et offrira l’accès aux utilisateurs du gouvernement [...] au moyen de services de portail à interface interne [...]. »³ [traduction]. La durée initiale du contrat était de trois ans et comportait quatre options irrévocables de un an. À ce jour, deux options ont été levées..

6. Le contrat original prévoyait que Sierra fournirait l’OCS. Cependant, en septembre 2008, à cause de l’abandon d’OCS par Oracle, Sierra a commencé à fournir Oracle Beehive à la place. Selon les éléments de preuve figurant dans la plainte, le 30 mars 2009⁴ , TPSGC s’est prévalu de son droit d’acheter des licences supplémentaires, incluant l’entretien et le soutien, pour l’utilisation du SPLU par Santé Canada, conformément au contrat original.

7. Le 12 juin 2009, Microsoft Canada Co., Microsoft Corporation et Microsoft Licensing, GP (Microsoft) déposaient une première plainte devant le Tribunal⁵ , invoquant le même motif que dans la présente plainte et un deuxième motif concernant l’interprétation du contrat SLPU.

8. Le 26 juin 2009, Microsoft déposait une deuxième plainte auprès du Tribunal⁶ , alléguant les mêmes motifs que dans la première plainte.

9. Le 29 juin 2009, le Tribunal rendait sa décision de ne pas enquêter relative à la première plainte. Le Tribunal jugeait la plainte prématurée et fondée essentiellement sur des hypothèses et ajoutait que les renseignements accompagnant la plainte ne contenaient pas d’indications selon lesquelles la plainte concernait la procédure de passation de marchés publics suivie relativement à un « contrat spécifique »⁷ . Le Tribunal déclarait ce qui suit :

18. [...] Le Tribunal est d’avis qu’en ce moment, la plainte de Microsoft relève de la pure spéculation en ce qui concerne les futures actions de TPSGC par rapport au contrat SLPU. Par conséquent, en l’absence de tout élément de preuve concernant l’existence de tout nouveau contrat spécifique, le Tribunal n’a pas compétence pour enquêter sur la plainte. Comme l’affirme la Cour d’appel fédérale dans Novell Canada Ltd. c. Canada (Minister of Public Works and Government Services), « [...] le Tribunal ne peut s’autoriser du paragraphe 30.11(1) pour mener une enquête sur l’ensemble de la procédure des marchés publics suivie par le gouvernement ».

[Note omise]

10. Le 10 juillet 2009, le Tribunal rendait sa décision relativement à la deuxième plainte. Le Tribunal estimait que la plainte concernait le même prétendu marché visé par la première plainte et, qu’elle contenait la même preuve documentaire si ce n’est l’ajout d’une lettre de Microsoft à TPSGC. Par conséquent, le Tribunal était d’avis que la doctrine de la chose jugée s’appliquait, ce qui l’empêchait d’examiner la deuxième plainte.

11. Le 28 juillet et le 7 août 2009, Microsoft Canada Co. déposait des avis de demande auprès de la Cour d’appel fédérale (CAF) relativement aux décisions du Tribunal mentionnées précédemment.

12. Dans la procédure devant la CAF, , TPSGC produisait des documents le 8 septembre 2009 dont une série de courriels qui, selon M&S, indiquaient que TPSGC implantait la SLPU, y compris le courrier électronique, à Santé Canada.

13. Entre le 21 septembre et le 16 octobre 2009, M&S et TPSGC ont échangé de la correspondance au sujet du contenu de cette série de courriels et de l’allégation portée à l’attention du Tribunal dans la plainte actuelle. Le ou vers le 16 octobre 2009, M&S recevait une lettre, datée du 8 octobre 2009, dans laquelle TPSGC informait M&S que, l’affaire se retrouvant devant les tribunaux, TPSGC n’était pas en mesure d’en discuter.

14. Le 29 octobre 2009, M&S déposait la plainte actuelle devant le Tribunal. Selon le Tribunal, cette plainte a été déposée dans le délai de 10 jours ouvrables prévu par l’article 6 du Règlement sur les enquêtes du Tribunal canadien du commerce extérieur sur les marchés publics ⁸ .

15. Le 6 novembre 2009, le Tribunal informait les parties qu’il enquêtait sur la plainte, puisqu’elle 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.

16. Le 13 novembre 2009, M&S déposait une requête auprès du Tribunal lui demandant d’ordonner à TPSGC de produire certains documents relatifs à la procédure qui, selon M&S, étaient sous la garde du gouvernement du Canada. M&S demandait aussi que ces documents soient produits avant le dépôt du rapport de l’institution fédérale (RIF) afin de lui permettre raisonnablement d’aborder toute question soulevée dans le RIF. M&S demandait aussi, compte tenu des circonstances de l’espèce (c’est-à-dire qu’aucune invitation comme telle n’a été publiée et qu’elle n’a pas eu l’occasion de prendre connaissance des spécifications et des exigences techniques de l’invitation) et de la brève période dont elle disposait pour répondre au RIF, que les documents soient déposés auprès du Tribunal 14 jours avant la fin du délai de dépôt du RIF.

17. Le 17 novembre 2009, TPSGC déposait une requête auprès du Tribunal demandant que ce dernier ordonne à M&S de remettre à TPSGC les copies de deux pièces en exemplaire unique déposées avec la plainte. TPSGC soutenait que M&S, en déposant les pièces en exemplaire unique pour des raisons supposément liées aux droits d’auteur, mais non étayées, violaient la lettre et l’esprit de la ligne directrice du Tribunal intitulée Désignation, protection, utilisation et transmission des renseignements confidentiels. TPSGC soutenait que M&S semblait fonder ses allégations sur les éléments de preuve contenus dans les deux documents et que le défaut d’accorder à TPSGC, à ses conseillers juridiques et à ses experts l’accès complet à la preuve constituait une négation des principes de base de la justice naturelle. TPSGC soutenait aussi qu’il avait le droit de consulter les éléments de preuve sur lesquels s’appuyait M&S afin d’être en mesure de répondre adéquatement à cette dernière. TPSGC demandait aussi une prolongation de 14 jours du délai de dépôt du RIF. Le 23 novembre 2009, TPSGC retirait sa demande quant à la remise des copies des deux pièces en exemplaire unique.

18. Le 27 novembre 2009, le Tribunal rendait une ordonnance rejetant la requête de M&S. Selon le Tribunal, la demande était prématurée puisque TPSGC n’avait pas encore déposé le RIF. L’ordonnance du Tribunal fixait aussi au 11 décembre 2009 la nouvelle date de dépôt du RIF.

19. Le 11 décembre 2009, TPSGC remettait le RIF. Le 16 décembre 2009, M&S déposait une requête demandant au Tribunal d’ordonner à TPSGC de fournir un certain nombre de documents relatifs au déploiement d’Oracle Beehive à Santé Canada de même que d’autres documents concernant le contrat SLPU et le déploiement prévu par TPSGC d’Oracle Beehive. M&S soutenait que ces documents auraient dû être produits par TPSGC dans le RIF, conformément à l’alinéa 103(2)b) des Règles du Tribunal canadien du commerce extérieur ⁹ , parce qu’ils étaient en la possession de TPSGC et qu’ils étaient pertinents à la question soulevée dans la plainte.

20. Le 23 décembre 2009, TPSGC et Sierra soumettaient des réponses à la requête de M&S. TPSGC soutenait que les documents demandés n’étaient pas pertinents et d’aucune utilité quant au règlement de la question en litige. Il affirmait que les renseignements et les éléments de preuve contenus dans le RIF présentaient une réponse complète à la question en litige et fournissaient un ensemble complet d’éléments de preuve permettant au Tribunal de rendre sa décision. Sierra appuyait les observations de TPSGC et ajoutait que M&S n’avait pas réussi à établir la pertinence des documents demandés quant à la question en litige. Le 30 décembre 2009, M&S déposait une réplique aux commentaires soumis par TPSGC et Sierra.

21. Le 6 janvier 2010, le Tribunal ordonnait à TPSGC de produire certains des documents demandés par M&S.

22. Le 11 janvier 2010, TPSGC déposait neuf documents auprès du Tribunal.

23. Les 18 et 19 janvier 2010, respectivement, M&S et Sierra déposaient leurs commentaires sur le RIF. Le 22 janvier 2010, TPSGC remettait une réponse aux commentaires de M&S sur le RIF, soutenant qu’ils contenaient des assertions et des allégations factuelles inexactes. Le 29 janvier 2010, M&S soumettait sa réplique à la réponse de TPSGC.

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

QUESTIONS PRÉLIMINAIRES

Motifs de l’ordonnance du Tribunal du 6 janvier 2010

25. Dans sa requête du 16 décembre 2009, M&S demandait une ordonnance exigeant de TPSGC qu’il produise certains documents. Voici le texte de la requête :

a) Documents de planification standards de TPSGS relatifs au projet DEC (environnement d’informatique répartie) de Santé Canada, y compris les éléments suivants :

(i) Document justifiant le projet ou exposant les besoins fonctionnels;

(ii) arrêté de projet;

(iii) plan de projet;

(iv) document exposant les exigences relatives aux systèmes;

(v) protocole d’entente ou lettre d’intérêt liant TPSGC et Santé Canada.

(vi) entente de niveau de service entre TPSGC et Santé Canada;

(vii) matériel relatif à la formation de haut niveau;

(viii) normes de conception détaillées;

(ix) protocole de test, procédures et rapports.

b) portions pertinentes du [contrat SLPU] et modifications ou commandes subséquentes depuis le 30 mars 2009;

c) toute présentation ou analyse établie par TPSGC relative à [...] Oracle Beehive;

d) toute analyse de TPSGC relative à la fonctionnalité ou aux capacités d’Oracle Beehive;

e) toute analyse comparant [OCS] et Oracle Beehive;

f) état de tous les montants payés à [Sierra] aux termes du contrat SLPU;

g) état de tous les montants payés à [Sierra] ou à ses filiales relativement à la fourniture de services professionnels touchant le déploiement du système DCE à Santé Canada.

[Traduction]

26. Après avoir examiné les arguments et observations des parties sur la pertinence de ces documents à l’égard de la procédure d’enquête du Tribunal, ce dernier ordonnait à TPSGC de déposer les documents suivants :

les parties du contrat [SPLU] (n^o EP265-04H009/001/ET) conclu entre [TPSGC] et [Sierra], ainsi que toute modification ou commande subséquente relative au contrat qui se rapporte aux droits et aux privilèges de [Santé Canada] à l’égard de la solution logicielle fournie par [Sierra], notamment l’[OCS] et les développements futurs qui pourraient y être apportés ;

toute présentation ou analyse préparée par [TPSGC] relative aux fonctionnalités en matière de courrier électronique d’[OCS] et d’Oracle Beehive.

27. Le Tribunal est d’avis que la question à trancher en l’espèce se limite à établir si le déploiement d’Oracle Beehive à Santé Canada s’effectuait conformément au contrat SLPU. Le Tribunal tient compte de certaines portions du contrat SLPU, de même que des modifications ou des commandes subséquentes relatives à ce dernier, eu égard aux droits de Santé Canada relatifs au déploiement de la SLPU.

28. Dans ce contexte, la fonctionnalité du courrier électronique et les services collaboratifs sont pertinents eu égard au libellé de la plainte. Par conséquent, le Tribunal a ordonné la divulgation des présentations ou analyses établies par TPSGC qui avaient trait à ladite fonctionnalité parce qu’il estimait qu’elles pourraient possiblement aider le Tribunal à rendre sa décision finale. Le Tribunal reconnaissait que le RIF abordait la question de la fonctionnalité du courrier électronique, mais constatait que la question de la capacité d’OCS et d’Oracle Beehive, à cet égard, demeurait étroitement liée à l’établissement des droits et obligations de TPSGC compte tenu du libellé de la plainte.

29. Quant à la demande relative aux autres documents énumérés, le Tribunal estimait ces derniers non pertinents puisque toute violation des obligations de TPSGC pourrait être établie uniquement par l’interprétation des obligations de Sierra et de TPSGC en vertu du contrat SLPU et non à partir de tout autre document interne de planification. De plus, en ce qui a trait aux demandes de M&S portant sur des documents fournissant un « état de tous les montants payés à [Sierra] aux termes du contrat SLPU » et un « état de tous les montants payés à [Sierra] ou à ses filiales relativement à la fourniture de services professionnels touchant le déploiement du système DCE à Santé Canada », le Tribunal est d’avis que M&S n’a pas démontré que ces documents aideraient le Tribunal à rendre sa décision.

ANALYSE DU TRIBUNAL

30. Aux termes du paragraphe 30.14(1) de la Loi sur le TCCE, le Tribunal doit, dans son enquête, limiter son étude à l’objet de la plainte. À la conclusion de l’enquête, le Tribunal doit établir la validité de la plainte en fonction du respect des procédures et autres exigences établies par règlements pour le contrat spécifique. L’article 11 du Règlement prévoit de plus que le Tribunal doit déterminer si le marché public a été passé conformément aux accords commerciaux pertinents qui, en l’espèce, sont l’Accord de libre-échange nord-américain ¹⁰ , l’Accord sur le commerce intérieur ¹¹ et l’Accord sur les marchés publics ¹² . Même si le Tribunal a aussi le pouvoir d’effectuer des enquêtes aux termes de deux autres accords commerciaux, soit l’Accord de libre-échange entre le gouvernement du Canada et la République du Chili ¹³ et l’Accord de libre-échange entre le Canada et la République du Pérou ¹⁴ , en l’espèce, le contrat en cause a été adjugé avant l’entrée en vigueur de l’ALÉCC et de l’ALÉCP.

31. La question que le Tribunal doit trancher peut être formulée comme il suit : est-ce que le déploiement d’Oracle Beehive à Santé Canada constitue, de la part de TPSGC, un manquement à ses obligations aux termes de l’ACI, de l’ALÉNA et de l’AMP ou s’agit-il de l’exercice légitime de droits prévus au contrat SLPU et à ses modifications ultérieures?

32. Le Tribunal aborde cette question à la lumière des obligations du gouvernement aux termes des dispositions suivantes des accords commerciaux pertinents : article 501 et paragraphes 506(2), 506 (5) et 506 (6) de l’ACI; articles 1008, 1009 et 1010 de l’ALÉNA; et articles VII et IX de l’AMP.

Position de M&S

33. M&S soutient qu’un portail est tout à fait différent d’un système de courrier électronique et que la DP et le contrat SLPU concernaient la fourniture d’une solution logicielle de portail et non d’un système de courrier électronique. M&S soutient qu’un système de courrier électronique est composé de deux éléments distincts, soit l’« amont » (ou le logiciel serveur) et l’« aval » (ou le logiciel client). Elle soutient que l’amont constitue le cœur du système, qui accepte, transfère, livre et emmagasine les messages pour le compte d’utilisateurs individuels. L’aval est constitué de l’infrastructure centrale d’un système de courrier électronique. M&S affirme que, d’autre part, l’aval est constitué du logiciel installé dans les ordinateurs des utilisateurs il permet à ces derniers d’avoir accès au système d’amont, dans lequel les messages courriel sont emmagasinés et transférés, pour être lus. Elle estime que l’acquisition d’un nouveau système d’amont sans concurrence constitue le point central de la présente plainte. Elle soutient que la DP portant sur la SLPU prévoyait clairement que la solution logicielle de portail Web entrerait en interaction avec le système d’amont existant, sans le remplacer, et que, par conséquent, la DP portant sur la SLPU se limitait à des services de soutien excluant le logiciel serveur de courrier électronique.

34. Selon M&S, TPSGC déploie un nouveau système de courrier électronique pour Santé Canada au moyen d’Oracle Beehive, qui ne faisait pas partie du contrat SLPU de 2005. M&S soutient que selon divers documents au dossier¹⁵ , Oracle Beehive devrait être considéré comme un nouveau serveur de courrier électronique et que tous les comptes d’utilisateur rattachés au serveur devaient être transférés des plateformes existantes à Oracle Beehive.

35. M&S soutient que la DP portant sur la SLPU ne contenait pas d’exigence particulière concernant le logiciel de serveur pour courrier électronique. Selon M&S, un produit relatif à un « portail » est complètement différent d’un produit relatif au « courrier électronique » la DP ainsi que le contrat SLPU concernaient une solution logicielle pour portail Web qui devait s’intégrer aux systèmes de courrier électronique existants et fonctionner en interaction avec ces derniers. Elle soutient que TPSGC a décrit à tort l’objet de la DP portant sur la SLPU comme des services de portail et collaboratifs, ce qui constituait une tentative de justifier après coup l’acquisition sans appel à la concurrence d’Oracle Beehive. Selon M&S, la DP portant sur la SLPU concernait un produit logiciel pour portail qui fournissait certains services collaboratifs bien définis à l’intérieur de ce portail. M&S soutient que TPSGC essaie de s’appuyer sur une interprétation large de l’expression « portail et services collaboratifs » qui n’interprète pas le sens des termes de la DP dans leur contexte. Elle soutient que, si la SLPU devait englober un système de courrier électronique, des expressions comme « doit comprendre » ou « doit incorporer » auraient été utilisées. Elle souligne que ce type d’expression était utilisé en relation avec d’autres exigences obligatoires dans la DP :

O-12 Exigences relatives à l’architecture des systèmes

La [SLPU] doit assurer l’interface, l’intégration et les interactions avec les autres logiciels et composants et solutions logiciels, p. ex., mécanismes externes d’authentification et d’autorisation, dépôts de métadonnées, bases de données relationnelles et à fichiers non hiérarchiques, solutions de gestion de contenus, systèmes de gestion de dossiers et documents d’information, moteurs de recherche, recueillement, messagerie, messagerie instantanée et gestion d’agendas ainsi que systèmes de gestion de l’information.

La [SLPU] doit offrir, habiliter et soutenir une interface de programmation d’applications (API) complète et des boîtes à outils logiciels ou l’équivalent, qui permettront aux développeurs d’avoir accès de manière programmable aux fonctionnalités de la [SLPU], notamment aux éléments suivants :

a. services d’application;

b. services de personnalisation;

c. développement d’applications;

d. sécurité du portail, p. ex., services d’authentification et d’autorisation, identification unique;

e. accès aux sources de données;

f. services de présentation;

g. recherches;

h. « portlets »;

i. interfaces avec des services d’applications externes utilisant des services Web (protocoles SOAP);

j. services collaboratifs.

[...]

O-16 Intégration du courrier électronique

la [SLPU] doit utiliser des systèmes de courrier électronique conformes au protocole de transfert de courrier simple (protocole SMTP) et interagir avec ce dernier. La [SLPU] doit habiliter et soutenir la fonctionnalité de courrier électronique, notamment par l’acheminement d’avis ou d’autres événements relatifs au déroulement des opérations.

[...]

O-47 Services collaboratifs

La [SLPU] doit fournir, habiliter et soutenir la fonctionnalité de façon à permettre les avis par courrier électronique selon des critères définis par l’utilisateur dans le contexte des activités d’un groupe de travail en collaboration, p. ex., avis au sujet de nouveaux contenus, activités et réponses.

[Traduction]

36. M&S souligne que, selon la modification n^o 006 à la DP, TPSGC a refusé d’élargir sa portée quant à la SLPU pour englober les systèmes de courrier électronique lorsqu’un fournisseur lui a demandé de le faire. M&S mentionne aussi un échange qui s’est déroulé en janvier 2009 entre TPSGC et Sierra dans lequel, selon M&S, TPSGC reconnaissait que la DP portant sur la SLPU n’englobait pas les systèmes de courrier électronique et que la SLPU n’avait pas pour objet de remplacer les fonctionnalités classiques ou existantes en matière de courrier électronique¹⁶ .

37. Selon M&S, Oracle Beehive est un produit différent de celui que Sierra proposait en réponse à la DP portant sur la SLPU. M&S soutient que ce nouveau produit n’existait pas au moment de la diffusion de la DP portant sur la SLPU et ne constituait pas une amélioration de l’OCS. Elle ajoute que les publications d’Oracle sur le produit confirment qu’« Oracle Beehive est un produit indépendant d’[OCS] » [traduction] et qu’« il n’existe pas de programme d’ordinateur qui pourrait mettre [OCS] au niveau d’Oracle Beehive. Puisque l’architecture des deux produits est différente, il faut installer Oracle Beehive et transférer les données dans Oracle Beehive »¹⁷ [traduction].

38. Selon M&S, la DP portant sur la SLPU concernait un portail offrant des services collaboratifs limités et Sierra n’est pas autorisée à étendre la portée du contrat. M&S souligne qu’au moment où le contrat SLPU a été accordé à Sierra, en 2005, sa valeur s’établissait à 820 845,15 $ mais que, selon les « Faits saillants du contrat » [traduction] publiés par TPSGC le 25 mai 2005, la valeur estimative du contrat SLPU s’établissait à 20 millions de dollars¹⁸ . Selon M&S, la différence de 19,2 millions de dollars entre la valeur adjugée et la valeur totale estimative s’explique par l’achat de licences et de services professionnels supplémentaires associés au contrat SLPU. Elle affirme que Sierra, pour obtenir le maximum du revenu aux termes du contrat SLPU, devait effectuer des ventes de gamme supérieure d’une valeur de 19,2 millions de dollars en licences et en services professionnels connexes et, pour ce faire, offrait des produits et services que TPSGC était intéressé à acheter au cours du contrat SLPU. M&S fait allusion à l’échange de janvier 2009 entre TPSGC et Sierra comme une illustration de la tentative de Sierra d’accroître la portée du contrat SLPU pour y inclure Oracle Beehive¹⁹ .

39. De plus, M&S s’appuie sur un rapport qu’elle a commandé²⁰ pour soutenir que les exigences cotées C-21 et C-22 de la DP portant sur la SLPU limitaient le type de système de courrier électronique aux services « synchrones », comme les conférences audio ou vidéo (c’est-à-dire lorsque tous travaillent ensemble en même temps) par opposition aux services « asynchrones », comme la correspondance, le courriel et la messagerie électronique (c’est-à-dire là ou des gens peuvent collaborer entre eux à des moments différents) :

C-21 Services collaboratifs

La composante des services collaboratifs de la [SLPU] doit fournir les fonctionnalités suivantes de séances de travail en collaboration réparties et ces dernières doivent être fournies par l’intermédiaire d’une fonction intégrée de séances de travail en collaboration à l’intérieur de la composante des services collaboratifs :

a. Messagerie et communications de groupe;

b. soutien à la gestion des réunions et à la gestion d’agendas, y compris gestion d’agendas partagés et établissement des horaires de groupe.

C-22 Services collaboratifs

La composante des services collaboratifs de la [SLPU] doit fournir les fonctionnalités suivantes de séances de travail en collaboration réparties et ces dernières doivent être fournies par l’intermédiaire d’une fonction intégrée de séances de travail en collaboration à l’intérieur de la composante des services collaboratifs :

a. Messagerie instantanée (« clavardage »);

b. messagerie d’entreprise (diffusion).

[Traduction]

Position de TPSGC

40. TPSGC soutient que la question revient essentiellement à établir si la DP portant sur la SLPU exigeait ou recherchait une fonctionnalité de courrier électronique. Il affirme qu’ en plus des exigences obligatoires O-12, O-16 et O-47, et des exigences C-21 et C-22 mentionnées ci-dessus, d’autres critères obligatoires concernaient aussi une fonctionnalité de courrier électronique :

O-15 Gestion d’annuaire

La [SLPU] doit utiliser au besoin des environnements d’annuaire extérieurs (à la [SLPU]) à l’appui des courriels, des messages de permission ou d’autres fonctions.

Il doit être possible d’exploiter la [SLPU] au moins dans le cadre des environnements d’annuaire suivants et de les utiliser :

a. Microsoft Active Directory;

b. annuaire conforme au protocole allégé d’accès annuaire (protocole LDAP).

[...]

O-20 Plateforme de services d’application pour portail

La [SLPU] doit comprendre un moteur de serveur d’applications, tout en s’y intégrant, qui fournit les éléments suivants :

a. Indépendance de l’architecture matérielle sous-jacente;

b. conçu pour une grande disponibilité et une grande variabilité dimensionnelle;

c. environnement d’exécution centré objet qui permet aux applications d’utiliser les services fournis par le serveur d’applications;

d. soutien des moyens de connexion reliant entre eux les divers systèmes d’information de l’organisation, p. ex., SAP, PeopleSoft et applications fonctionnelles propres à un programme;

e. contexte transactionnel dans lequel les composantes logiques fonctionnelles peuvent s’exécuter;

f. cadre qui permet aux composantes logiques de présentation de donner suite aux demandes liées au protocole HTTP (transfert hypertexte);

g. mise en commun des connexions aux bases de données;

h. soutien intégré pour les technologies de services Web (WSDL, SOAP, UDDI);

i. soutien intégré pour les technologies XML, incluant notamment XML Parsing, XSL Transformations;

j. soutien intégré pour les technologies et protocoles de traitement réparti, p. ex., CORBA et IIOP;

k. soutien intégré pour les intergiciels centrés sur les messages (p. ex., série MQ); et

l. soutien intégré pour les annuaires correspondant aux normes de l’industrie, comme LDAP.

[Traduction]

41. TPSGC soutient que M&S établit une distinction artificielle entre communications asynchrones et synchrones en affirmant que le terme « système de courrier électronique » englobe uniquement les communications « asynchrones », alors que les messageries de groupe et les messageries instantanées fournies à titre de services collaboratifs aux termes des paragraphes C-21 et C-22 sont des messageries « synchrones ». Selon TPSGC, cette distinction n’est pas étayée et est contredite par la définition des « services collaboratifs » [traduction] donnée à l’annexe 2 du rapport Ferris « [l]a collaboration est le processus par lequel des entités travaillent ensemble » [traduction] — et la reconnaissance qui y est faite de la nature des services collaboratifs qui comprennent le courrier électronique et la messagerie textuelle instantanée (qui, selon TPSGC, est aussi une forme de courrier électronique). TPSGC soutient qu’un courriel, étant un message numérique, il peut être livré tant de façon synchrone qu’asynchrone. Dans le langage courant, le terme « courriel » peut désigner tant les messages synchrones qu’asynchrones, c’est-à-dire la messagerie instantanée ou de la messagerie au sens plus large. TPSGC soutient que la DP portant sur la SLPU recherchait une fonctionnalité à la fois pour la messagerie synchrone et asynchrone, soulignant précisément que l’exigence obligatoire O-12 concernait une architecture soutenant à la fois la « messagerie » et la « messagerie instantanée ».

42. TPSGC affirme aussi que le déploiement de la SLPU à Santé Canada n’a pas remplacé le courrier électronique classique. Elle souligne qu’en décembre 2008, Santé Canada a fait l’acquisition de licences Microsoft d’une valeur de 12 millions de dollars, y compris Microsoft Office, et des services connexes, pour le ministère lui-même et l’Agence de la santé publique du Canada. Selon TPSGC, les employés de Santé Canada ont le choix entre Microsoft Office, WordPerfect de Corel ou la suite Lotus Smart d’IBM.

43. TPSGC soutient que la plainte devrait être rejetée et qu’il devrait obtenir le remboursement des frais engagés pour répondre à la plainte.

Position de Sierra

44. Selon Sierra, le RIF répondait entièrement à toutes les questions soulevées dans la plainte et elle n’a rien à ajouter.

Analyse du Tribunal

45. Le Tribunal a examiné les positions des parties à l’égard des quelque 25 critères énoncés dans la DP portant sur la SLPU originale et leurs points de vue en relation avec le contrat existant. Selon le Tribunal, il est clair que la DP cherchait à obtenir des services collaboratifs, comme l’indiquent les nombreuses mentions à ce sujet dans les exigences obligatoires et cotées²¹ . Le Tribunal est incapable de trouver une disposition ou un passage de la DP qui, comme l’allègue M&S, exclurait spécifiquement toute forme de messagerie électronique asynchrone.

46. Mais encore, le Tribunal estime que le déploiement d’Oracle Beehive découle des obligations assumées par Sierra aux termes du paragraphe B.4.4 du contrat type annexé à la DP et constituant l’article 4.4 du contrat SLPU, dont voici le texte :

4.4 MAINTENANCE DU LOGICIEL SOUS LICENCE

a) Période de maintenance : l’entrepreneur doit assurer la maintenance du logiciel sous licence en effectuant les corrections de codes (définies ci-après) et en respectant le code de maintenance (défini ci-dessous) pour le Canada :

(i) au cours de la période contractuelle [initiale²² ];

(ii) pendant toute année où le Canada exerce son option de services de maintenance supplémentaires (la « période de maintenance »).

b) Code de maintenance : l’entrepreneur fournira l’ensemble des services suivants dans les dix (10) jours civils de la diffusion du logiciel et de l’accès à ce dernier, pendant toute la durée de la période contractuelle, en relation avec le logiciel sous licence, dans le cadre de la maintenance de ce dernier :

(i) l’ensemble des corrections de bogue et de programme et toutes les autres améliorations;

(ii) l’ensemble des mises à niveau, mises à jour, versions nouvelles, majeures et mineures et changements de nom;

(iii) l’ensemble des extensions et des autres modifications, y compris notamment aux pilotes, aux modifications provisoires et aux versions de service;

(iv) l’ensemble des programmes d’applications (API), des cartes enfichables, des applets et des adapteurs;

(v) l’ensemble des réécritures, y compris les autres langages de programmation, lorsque l’éditeur du logiciel a abandonné les versions originales; et

(vi) sur demande, l’ensemble des versions simplifiées, pourvu que si ces versions simplifiées sont antérieures à la version du logiciel sous licence proposée par l’entrepreneur en réponse à la demande de proposition qui a débouché sur le présent contrat, la version simplifiée doit être fournie sans garantie et l’entrepreneur n’est pas tenu d’offrir maintenance ou soutien à l’égard de la version simplifiée du logiciel sous licence;

généralement offerts aux titulaires du logiciel sous licence par l’éditeur du logiciel au cours de la période de maintenance (le « code de maintenance »).

c) Licence permettant d’utiliser le code de maintenance : dans le présent contrat, le terme « logiciel sous licence » englobe tout code de maintenance livré au Canada en relation avec le logiciel sous licence; il est entendu que la licence du logiciel sous licence régit l’utilisation du code de maintenance.

d) Envois : tous les envois requis pour expédier le code de maintenance au Canada doivent être effectués sans frais de conditionnement ou d’expédition supplémentaires pour le Canada. Le Canada peut utiliser la livraison électronique, si cette option est offerte, et si le Canada, à son entière discrétion, estime que la livraison électronique convient.

e) Déploiement du code de maintenance : sauf disposition contraire dans les présentes, le Canada sera responsable du déploiement du code de maintenance.

f) Maintenance du logiciel sous licence : l’entrepreneur doit continuer à assurer la maintenance de la version du logiciel sous licence (c’est-à-dire la version originale ou « intégrée » originalement visée par la licence en vertu des présentes au moment de l’adjudication du contrat) à titre de produit commercial (c’est-à-dire que l’entrepreneur ou l’éditeur du logiciel doit continuer à développer de nouveaux codes en relation avec le logiciel sous licence pour maintenir sa fonctionnalité et gérer les erreurs logiques) pendant au moins un an après la date d’adjudication du contrat. Si, après cette période, l’entrepreneur ou l’éditeur du logiciel décide d’interrompre ou de ne plus assurer la maintenance de la version « intégrée » alors à jour du logiciel sous licence et de fournir à la place une mise à niveau des produits existants incorporés à la solution logicielle, l’entrepreneur doit fournir à ce sujet un avis écrit au Canada au moins douze (12) mois avant ladite interruption.

[Traduction]

47. Compte tenu du libellé de ces dispositions, le Tribunal estime que Sierra est tenue d’assurer la maintenance du logiciel sous licence pendant toute la duré du contrat et des années d’option. Le Tribunal rappelle qu’étant donné l’existence de cette disposition à la DP portant sur la SLPU, les soumissionnaires étaient au fait de cette exigence au moment du dépôt de leur soumission. Conformément aux extraits cités précédemment, la « maintenance » exige la fourniture des corrections de codes, définies à la fois dans le contrat type et le contrat SLPU comme :

(i) l’ensemble des corrections de bogue et de programme et toutes les autres améliorations;

(ii) l’ensemble des mises à niveau, mises à jour, versions nouvelles, majeures et mineures et changements de nom;

(iii) l’ensemble des extensions et des autres modifications, y compris notamment aux pilotes, aux modifications provisoires et aux versions de service;

(iv) l’ensemble des programmes d’applications (API), des cartes enfichables, des applets et des adapteurs;

(v) l’ensemble des réécritures, y compris les autres langages de programmation, lorsque l’éditeur du logiciel a abandonné les versions originales; et

(vi) sur demande, l’ensemble des versions simplifiées, pourvu que si ces versions simplifiées sont antérieures à la version du logiciel sous licence proposée par l’Entrepreneur en réponse à la demande de proposition qui a débouché sur le présent contrat, la version simplifiée doit être fournie sans garantie et l’Entrepreneur n’est pas tenu d’offrir maintenance ou soutien à l’égard de la version simplifiée du logiciel sous licence. [traduction]

[Traduction, nos italiques]

48. Par conséquent, conformément aux conditions du contrat, Sierra a entre autres fourni OCS. OCS procurait aux utilisateurs l’accès à des fonctions intégrées de courrier électronique, de messagerie électronique, de conférences sur le Web de même que d’autres fonctions liées à Outlook de Microsoft et à ses navigateurs.

49. En septembre 2008, Sierra commençait à livrer Oracle Beehive à titre de version mise à niveau d’OCS sans frais additionnels pour le gouvernement. Dans un courriel daté du 18 novembre 2008, TPSGC cherchait à faire confirmer qu’Oracle Beehive constituait une mise à niveau d’OCS qui comportait un changement de nom et qui, par conséquent, était visée par le contrat existant²³ .

50. Les modalités d’un contrat doivent être interprétées selon leur sens ordinaire dans le contexte où elles sont utilisées. Une lecture attentive des dispositions mentionnées précédemment, y compris le titre de la section, « Maintenance du logiciel sous licence » et, ce qui est plus important, « l’ensemble des mises à niveau, mises à jour, versions nouvelles, majeures et mineures et changements de nom » du logiciel sous licence, soutient la conclusion du Tribunal selon laquelle la DP portant sur la SLPU établit clairement le droit de TPSGC d’obtenir ces nouvelles versions intégrant des changements majeurs comme mineurs et que Sierra est tenue de les fournir. Compte tenu du remplacement d’OCS par Oracle Beehive en septembre 2008, conformément à l’une des exigences de la DP portant sur la SLPU, Sierra devait fournir au « Canada » ce logiciel portant un nouveau nom, résultat d’une mise à niveau majeure. La décision de Sierra de remplacer OCS par Oracle Beehive a été prise indépendamment du contrat SLPU.

51. Le Tribunal estime que le déploiement d’Oracle Beehive à Santé Canada constitue la levée pure et simple d’une option visée dans la DP portant sur la SLPU et prévue au contrat. Cette option a non seulement trait au type de produit (pour incorporer les mises à niveau) mais prévoit aussi que le déploiement peut s’étendre à d’autres lieux. Par conséquent, le Tribunal estime que TPSGC avait le droit incontestable d’acheter des licences supplémentaires aux termes du contrat portant sur la SLPU et que ces licences constituaient des mises à niveau visées par le contrat. En somme, le Tribunal conclut que la présente affaire concerne uniquement l’administration des contrats, qui est au-delà de la compétence du Tribunal, et qu’il n’est pas saisi d’un cas de marché public exécuté de façon incomplète. Dans ce contexte, le Tribunal n’est pas en présence d’une violation des dispositions d’accords commerciaux.

52. À la lumière de ce qui précède, le Tribunal détermine que la plainte de M&S n’est pas fondée.

Frais

53. Le Tribunal accorde à TPSGC le remboursement des frais raisonnables qu’il a engagés pour répondre à la plainte. Le Tribunal a tenu compte de la Ligne directrice sur la fixation des frais dans une procédure portant sur un marché public (la Ligne directrice) et il est d’avis que la complexité de la plainte correspond au degré de complexité le plus élevé prévu à l’annexe A de la Ligne directrice (niveau 3). La Ligne directrice fonde l’évaluation du degré de complexité d’une affaire sur trois critères : la complexité du marché public, de la plainte et de la procédure. La complexité du marché public était moyenne en ce qu’elle concernait la fourniture d’articles standards. Celle de la plainte était élevée puisqu’elle concernait l’interprétation de critères techniques complexes. Enfin, la complexité de la procédure était également élevée étant donné les deux requêtes et une partie intervenante et que, même s’il n’a pas été nécessaire de tenir une audience publique, il fallait respecter le délai de 135 jours et que des observations ont été présentées au-delà de la portée normale de la procédure. Par conséquent, comme le prévoit la Ligne directrice, l’indication provisoire du montant de l’indemnisation donnée par le Tribunal s’établie à 3 000 $.

DÉCISION DU TRIBUNAL

54. Aux termes du paragraphe 30.14(2) de la Loi sur le TCCE, le Tribunal détermine que la plainte n’est pas fondée.

55. Aux termes de l’article 30.16 de la Loi sur le TCCE, le Tribunal accorde à TPSGC le remboursement des frais raisonnables qu’il a engagés pour répondre à la plainte, ces frais devant être payés par M&S. En conformité avec la Ligne directrice, le Tribunal assigne un degré 3 de niveau de complexité à cette plainte et une indication provisoire du montant d’indemnisation de 3 000 $. Si l’une ou l’autre des parties n’est pas d’accord avec cette indication provisoire du degré de complexité ou cette indication provisoire du montant de l’indemnisation, elle peut déposer des observations auprès du Tribunal, en conformité avec la Ligne directrice. Le Tribunal se réserve la compétence de fixer le montant définitif de l’indemnisation.

---

¹ . L.R.C. 1985 (4^e supp.), c. 47 [Loi sur le TCCE].

² . Service électronique d’appel d’offres du Canada.

³ . Contrat de SLPU à la p. 4.

⁴ . RIF, pièce confidentielle 18.

⁵ . Re Plainte déposée par Microsoft Canada Co, Microsoft Corporation et Microsoft Licensing, GP (29 juin 2009), PR-2009-016 (TCCE).

⁶ . Re Plainte déposée par Microsoft Canada Co, Microsoft Corporation et Microsoft Licensing, GP (10 juillet 2009), PR-2009-021 (TCCE).

⁷ . Le paragraphe 30.11(1) de la Loi sur le TCCE prévoit ce qui suit : « Tout fournisseur potentiel peut, sous réserve des règlements, déposer une plainte auprès du Tribunal concernant la procédure des marchés publics suivie relativement à un contrat spécifique et lui demander d’enquêter sur cette plainte. » Le paragraphe 3(1) du Règlement sur les enquêtes du Tribunal canadien du commerce extérieur sur les marchés publics définit comme suit le terme « contrat spécifique » : « [...] tout contrat relatif à un marché de fournitures ou services ou de toute combinaison de ceux-ci, accordé par une institution fédérale — ou qui pourrait l’être — et visé, individuellement ou au titre de son appartenance à une catégorie, à l’article 1001 de l’ALÉNA, à l’article 502 de l’Accord sur le commerce intérieur, à l’article premier de l’Accord sur les marchés publics ou à l’article Kbis-01 du chapitre Kbis de l’ALÉCC. »

⁸ . D.O.R.S./93-602 [Règlement].

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

¹⁰ . Accord de libre-échange nord-américain entre le gouvernement du Canada, le gouvernement des États-Unis d’Amérique et le gouvernement des États-Unis du Mexique, 17 décembre 1992, R.T.C. 1994, n^o 2 (entré en vigueur le 1^er janvier 1994) [ALÉNA].

¹¹ . 18 juillet 1994, Gaz. C. 1995.I.1323, en ligne : Secrétariat du commerce intérieur <http://www.ait-aci.ca/index_fr/ait.htm> [ACI].

¹² . 15 avril 1994, en ligne : Organisation mondiale du commerce <http://www.wto.org/french/docs_f/legal_f/final_f.htm> [AMP].

¹³ . Accord de libre-échange entre le gouvernement du Canada et le gouvernement de la République du Chili, R.T.C. 1997, n^o 50 (entré en vigueur le 5 juillet 1997) [ALÉCC]. Le chapitre Kbis, intitulé « Marchés publics », est entré en vigueur le 5 septembre 2008.

¹⁴ . Accord de libre-échange entre le Canada et la République du Pérou, en ligne : le ministère des Affaires étrangères et du Commerce international <http://www.international.gc.ca/trade-agreements-accords-commerciaux/agr-... (entré en vigueur le 1^er août 2009) [ALÉCP].

¹⁵ . RIF, pièce confidentielle 7, fournie conformément à l’ordonnance du Tribunal datée du 6 janvier 2010.

¹⁶ . RIF, pièce confidentielle 16.

¹⁷ . Observations sur le RIF, pièce jointe 2, « Transfert de la suite Oracle Collaborations dans Oracle Beehive, survol et foire aux questions » [traduction], à la p. 1.

¹⁸ . RIF, pièce 3, « Faits saillants du contrat », document diffusé par TPSGC le 25 mai 2005.

¹⁹ . RIF, pièce confidentielle 16.

²⁰ . Plainte, pièce jointe 1, Ferris Research Inc., « La demande de proposition portant sur la SLPU : analyse de sa portée » [traduction], document daté du 28 octobre 2009 [rapport Ferris].

²¹ . Ces mentions se retrouvent dans les exigences obligatoires O-12, O-15, O-16, O-20 et O-47 et dans les exigences cotées C-21 et C-22.

²² . Ce terme figure uniquement dans le contrat SLPU; pour le reste, le libellé du contrat type et du contrat réel est identique.

²³ . RIF, pièce confidentielle 20 à la p. 3.