Allegro Wireless Canada Inc. c. La Reine

Allegro Wireless Canada Inc. c. La Reine
Base de données – Cour (s)
Jugements de la Cour canadienne de l'impôt
Date
2021-03-31
Référence neutre
2021 CCI 27
Numéro de dossier
2014-1690(IT)G, 2014-1691(IT)G
Juges et Officiers taxateurs
Steven K. D'Arcy
Sujets
Loi de l'impôt sur le revenu
Notes
Contenu de la décision
Dossiers : 2014-1690(IT)G
2014-1691(IT)G
ENTRE :
ALLEGRO WIRELESS CANADA INC.,
appelante,
et
SA MAJESTÉ LA REINE,
intimée.
[TRADUCTION FRANÇAISE OFFICIELLE]
Appels entendus sur une preuve commune les 6, 7 et 8 mai 2019 et les 21, 22 et 23 septembre 2020 à Toronto (Ontario) et observations écrites reçues les 8, 21 et 28 octobre 2020.
Devant : L’honorable juge Steven K. D’Arcy
Comparutions :
Avocat de l’appelante :
Me Jonathan N. Garbutt
M. Justin Pon (stagiaire en droit)
Avocats de l’intimée :
Me Alisa Apostle
Me Natasha Mukhtar
Me Aaron Tallon
JUGEMENT
Conformément aux motifs du jugement ci-joints :
Les appels interjetés à l’encontre des cotisations établies au titre de la Loi de l’impôt sur le revenu pour les années d’imposition 2010 et 2011 de l’appelante sont accueillis, le tout avec dépens, et les nouvelles cotisations sont renvoyées au ministre du Revenu national pour nouvel examen et nouvelle cotisation au motif que l’appelante a engagé des dépenses admissibles de recherche scientifique et développement expérimental de 449 878 $ et 508 351 $ pour les années d’imposition 2010 et 2011, respectivement, et a droit aux crédits d’impôt à l’investissement correspondants de 157 457 $ et 177 923 $ pour les années d’imposition 2010 et 2011, respectivement.
Signé à Ottawa, Canada, ce 31e jour de mars 2021.
« S. D’Arcy »
Le juge D’Arcy
Traduction certifiée conforme
ce 15e jour d'octobre 2021.
François Brunet, réviseur
Référence : 2021 CCI 27
Date : 20210331
Dossiers : 2014-1690(IT)G
2014-1691(IT)G
ENTRE :
ALLEGRO WIRELESS CANADA INC.,
appelante,
et
SA MAJESTÉ LA REINE,
intimée.
[TRADUCTION FRANÇAISE OFFICIELLE]
MOTIFS DU JUGEMENT
Le juge D’Arcy
[1] L’appelante a déposé un appel à l’égard de son année d’imposition se terminant le 30 septembre 2010 (l’« année d’imposition 2010 ») et un appel à l’égard de son année d’imposition se terminant le 30 septembre 2011 (l’« année d’imposition 2011 »). J’ai entendu les deux appels ensemble sur preuve commune.
[2] L’appelante a réalisé des projets dans le but de développer des logiciels qui répondraient aux divers besoins de ses clients. Dans le calcul de son impôt à payer pour l’année d’imposition 2010 et l’année d’imposition 2011, l’appelante a pris pour position que certains de ces projets constituaient de la recherche scientifique et du développement expérimental (« RS&DE ») aux termes des dispositions de la Loi de l’impôt sur le revenu, L.R.C. (1985), ch. 1 (5e suppl.)
[3] Plus précisément, lors du calcul de son impôt sur le revenu pour l’année d’imposition 2010, l’appelante a déclaré des dépenses de RS&DE de 798 342 $ et des crédits d’impôt à l’investissement (les « CII ») correspondants de 279 420 $ à l’égard de trois projets. Le ministre du Revenu national (le « ministre ») a refusé 697 723 $ de la somme déclarée à titre de RS&DE et 244 208 $ des CII correspondants à l’égard de deux projets.
[4] Dans le calcul de son revenu pour l’année d’imposition 2011, l’appelante a déclaré des dépenses de RS&DE de 615 906 $ et des CII correspondants de 215 567 $. Le ministre a refusé 463 401 $ de la somme déclarée à titre de RS&DE et 162 190 $ des CII correspondants.
[5] Au cours des six jours d’audience, l’appelante a cite trois témoins au sujet des faits, M. Wesley Rupel, M. Khalid Eidoo et M. Russell Roberts, et un témoin expert, M. Gerald Penn. L’intimée a cite un témoin au sujet des faits, Mme Cathy Sporich, et deux témoins experts, M. Shrinavensen Keshav et Mme Shirook Ali.
[6] J’ai conclu que les quatre témoins de fait étaient crédibles. Pour les raisons que je vais exposer, je ne me suis appuyé que sur le témoignage d’expert de M. Penn.
[7] Les parties ont déposé un court exposé conjoint des faits partiel (l’« ECFP »).
I. Résumé des faits
[8] M. Rupel a décrit l’entreprise de l’appelante et les divers projets de recherche. Au cours de la période pertinente, M. Rupel et son partenaire commercial contrôlaient l’appelante.
[9] M. Rupel est titulaire d’un diplôme de premier cycle en physique et en mathématiques. En 1981, il a commencé un programme combiné de maîtrise et de doctorat en physique à l’Université de Californie, à Santa Barbara. Il a terminé la partie maîtrise du programme, mais en 1985, alors que son professeur était en congé sabbatique, il a fait une pause dans le programme et s’est joint à Dynamical Systems Research (« Dynamical »), une jeune entreprise de logiciels située à Berkeley, en Californie.
[10] Un an plus tard, Microsoft a acquis Dynamical. Cette acquisition a permis à Microsoft d’accéder aux logiciels de Dynamical, qu’elle a utilisés pour créer le système d’exploitation Windows. M. Rupel était l’une des 10 personnes impliquées dans les étapes initiales de la création du système d’exploitation Windows.
[11] Le travail de M. Rupel chez Microsoft était axé sur l’augmentation de la vitesse du système d’exploitation Windows, ce qui était un problème important puisque la première version du système d’exploitation était extrêmement lente.
[12] M. Rupel a quitté Microsoft en 1992 et, selon ses propres termes, a essentiellement pris sa retraite. Il est revenu chez Microsoft en 1998. Il s’est joint à l’appelante en 2002 et est devenu président et chef de la technologie en 2004.
[13] M. Rupel et son partenaire commercial ont fondé l’appelante afin de créer des logiciels pour les industries qui, selon eux, étaient mal desservies à ce chapitre. L’entreprise s’est concentrée sur la fourniture d’une plateforme logicielle permettant à ses clients de communiquer à distance avec leurs travailleurs. Cette communication se fait au moyen d’appareils portatifs sans fil dotés d’écrans LCD que les travailleurs des clients de l’appelante utilisent pour accéder à distance au système informatique de leur employeur.
[14] Les clients de l’appelante comprennent des entreprises de logistique de transport comme Manitoulin Transport, des détaillants comme Loblaws et la Régie des alcools de l’Ontario et des entreprises qui fournissent des services sur le terrain à leurs clients, comme Canon Canada (« Canon ») et Shred-it.
[15] M. Rupel a donné des exemples de la façon dont les clients de l’appelante utilisaient les appareils portatifs sans fil. Par exemple, il a expliqué comment les quelque 400 techniciens de Canon utilisaient les appareils pour communiquer avec le siège social de Canon lorsqu’ils effectuaient des réparations dans les locaux des clients de Canon. Cela permettait à Canon de suivre les travaux de réparation effectués par les techniciens. Cela permettait également à Canon de communiquer directement avec chaque travailleur.
[16] Loblaws utilisait les appareils dans la zone de réception de ses différents magasins pour numériser les codes à barres, ce qui l’aidait à contrôler ses stocks. Loblaws utilisait également les appareils pour enregistrer les livraisons et les stocks chez divers détaillants tiers qui achetaient leurs marchandises auprès de Loblaws.
[17] Les appareils portatifs permettaient de transférer des renseignements entre les travailleurs sur le terrain des divers clients de l’appelante et les bases de données tenues par les clients. Au cours de la période pertinente, il s’agissait d’un nouveau produit qui n’avait jamais existé auparavant.
[18] Des tiers ont fourni les appareils portatifs sans fil et l’appelante a fourni le logiciel. L’information était transférée par l’intermédiaire de réseaux cellulaires, principalement le réseau exploité par Rogers Wireless.
[19] M. Rupel a décrit en détail les divers problèmes techniques auxquels l’appelante a dû faire face lors du développement du logiciel qui permettait aux appareils portatifs de communiquer avec les serveurs. Ces serveurs contenaient les bases de données de ses différents clients, ou étaient connectés aux serveurs qui contenaient de telles bases de données.
[20] Il a noté que tout développement de logiciel tenait compte des besoins précis des clients. L’appelante a passé beaucoup de temps à déterminer les besoins de chacun de ses clients. Cela impliquait de comprendre l’entreprise du client et les problèmes qu’il essayait de résoudre. Une fois ces éléments déterminés, l’appelante a élaboré un cahier des charges définissant ce que le logiciel devait faire afin de résoudre les problèmes du client. Le cahier des charges était révisé par le client et l’équipe de développement de logiciels de l’appelante.
[21] Le cahier des charges était ensuite envoyé à l’équipe de développement de logiciels de l’appelante pour qu’elle réalise le logiciel conformément au cahier des charges. L’équipe de développement de logiciels avait fréquemment subi des problèmes qui entraînaient une révision du cahier des charges ou des modifications du logiciel pour résoudre le problème.
[22] Une fois la première version du logiciel conçue, elle a été examinée par l’équipe d’analyse de la qualité de l’appelante et son équipe de développement commercial. L’équipe d’analyse de la qualité veillait à ce que le logiciel fasse ce qu’il était censé faire et l’équipe de développement commercial s’assurait qu’il faisait ce qu’il était censé faire d’un point de vue commercial.
[23] M. Rupel a noté que, lors du développement de produits logiciels, on rencontre toujours des problèmes techniques. Par exemple, l’appelante peut réaliser exactement ce qui est précisé, mais une fois que le logiciel est intégré à l’appareil, celui-ci est [traduction] « simplement trop lent ». Afin de satisfaire les besoins de ses clients, l’appelante a dû trouver des solutions à tous les problèmes qu’elle rencontrait. Durant la période pertinente, il s’agissait d’un exercice compliqué en raison de l’état de la technologie sans fil et des logiciels sous-jacents à ce moment précis. Il a fait remarquer qu’il serait beaucoup plus facile de répondre au cahier des charges aujourd’hui puisque la technologie sous-jacente est beaucoup plus avancée.
[24] Il a noté que l’un des principaux problèmes rencontrés par l’appelante était le fait que des logiciels tiers contrôlaient les caractéristiques de bas niveau des appareils portables.
[25] Par exemple, divers tiers fournissaient le logiciel qui faisait fonctionner la radio utilisée pour communiquer avec les diverses stations cellulaires. Différents tiers fournissaient le logiciel pour différents modèles d’appareils portatifs. Cela s’est traduit par un manque d’uniformité dans le fonctionnement d’un modèle par rapport à un autre.
[26] M. Rupel a noté que si l’appelante détectait un problème qui n’aurait pas dû se produire compte tenu du cahier des charges du logiciel sous-jacent, elle devait faire preuve de créativité. Les études techniques courantes ne pouvaient résoudre le problème. L’appelante devait [traduction] « formuler des hypothèses sur les choses [qu’elle] pouvait mettre à l’essai ou faire et voir ce qui fonctionn[ait] par expérimentation ».
[27] L’appelante a également dû tenir compte des différents serveurs utilisés par chacun de ses clients. Dans de nombreux cas, l’appelante installait son propre serveur dans les locaux de son client et ce serveur communiquait ensuite avec le serveur du client.
[28] Le produit principal de l’appelante était sa plateforme (logiciel), qu’elle a développée pour s’adapter aux différentes particularités des divers appareils portatifs utilisés par ses clients. La plateforme devait tenir compte des différents systèmes d’exploitation et des fréquentes mises à jour du logiciel contrôlant les caractéristiques de bas niveau des appareils. L’objectif de l’appelante était d’avoir un système unique sur lequel toutes les différentes applications utilisées dans le fonctionnement des appareils pourraient être conçues.
[29] Cela exigeait de l’appelante qu’elle développe et maintienne une quantité importante de logiciels. Elle ne cessait également de développer des logiciels pour améliorer le fonctionnement des divers appareils portatifs sur sa plateforme.
[30] M. Rupel a décrit le processus utilisé par l’appelante pour s’assurer que les appareils fonctionnent correctement pour ses clients. Il a expliqué pourquoi l’appelante était tenue d’effectuer des recherches dans le cadre de ses activités.
[31] Il a noté que l’appelante n’avait pas accès aux codes sources des divers logiciels sous-jacents qui faisaient fonctionner les appareils portatifs. Il a qualifié ce logiciel de boîte noire, quelque chose dont l’appelante ne pouvait pas voir les « entrailles ». Il a noté qu’au fur et à mesure que l’appelante développait ses divers produits, divers bogues et défauts se manifestaient.
[32] Les bogues sont survenus lorsque les outils et les logiciels sous-jacents fonctionnaient comme prévu et que l’appelante avait commis une erreur dans la conception du logiciel, erreur qu’elle devait corriger.
[33] Quant aux défauts, ils sont survenus lorsque, après avoir examiné le problème, l’appelante ne pouvait pas déterminer pourquoi l’événement en question se produisait. Cela n’avait aucun sens pour l’appelante. Selon M. Rupel, il y avait quelque chose de mystérieux qui se passait et qui appelait une enquête plus approfondie.
[34] M. Rupel a noté qu’il se peut qu’un défaut fasse l’objet ou non des travaux de RS&DE déclarés par l’appelante aux fins de l’impôt. L’appelante prenait la décision plus tard, après avoir terminé son enquête et, avec un peu de chance, elle trouvait une solution au défaut. Elle passait en revue les travaux qu’elle avait effectués et déterminait si elle avait mené suffisamment de travaux d’expérimentation ou si la question avait été relativement simple et résolue de façon directe. Dans ce dernier cas, les travaux n’étaient pas été inclus dans les travaux de RS&DE de l’appelante ayant fait l’objet de la déclaration.
[35] Il a ensuite discuté de la nature du développement de logiciels effectué par l’appelante afin d’assurer la fiabilité du service qu’elle fournissait.
[36] Il a noté qu’à la fin des années 1980, lorsqu’il travaillait chez Microsoft, si le code source de Microsoft ne fonctionnait pas correctement, c’était parce que Microsoft avait fait quelque chose d’incorrect lors du développement du logiciel. Les employés de Microsoft examinaient alors tous les codes sources entrant dans la composition de Microsoft Windows pour déterminer où l’erreur s’était produite. Microsoft a tout développé à partir de zéro.
[37] M. Rupel note qu’en 2010 et 2011, les choses ont évolué. Au lieu de concevoir tous les logiciels à partir de zéro, les entreprises, lorsqu’elles construisent un produit, utilisent des logiciels provenant de diverses sources. Il a qualifié les différents logiciels de composants logiciels.
[38] La plupart des fonctionnalités exécutées lors du développement d’un produit ne sont pas réalisées par les personnes qui semblent concevoir le logiciel, mais plutôt par l’utilisation de divers composants qui remplissent des fonctions différentes. Ce qui se passait, c’est qu’une entreprise développait ses produits en prenant ces composants et en concevant un logiciel qui les [traduction] « coll[ait] l’un avec l’autre ».
[39] Le développeur du produit devait donc s’assurer que les différents composants logiciels faisaient ce qu’ils étaient censés faire. Un défaut se produisait lorsqu’il y avait une sorte d’interaction entre les différents composants logiciels qui n’était pas prévue, c’est-à-dire lorsqu’un composant logiciel ne faisait pas ce que le développeur attendait de lui.
[40] Lorsque cela se produisait, l’appelante entrait en contact avec le service d’assistance technique de la société qui avait développé le composant logiciel en question pour voir s’il avait une solution. Si le service d’assistance technique n’avait pas de solution, l’appelante devait alors commencer à faire des expérimentations pour déterminer dans quelles circonstances le composant logiciel se comportait d’une certaine manière et dans quelles circonstances il ne se comportait pas de cette manière. Il arrivait parfois que l’appelante évite le problème en faisant quelque chose d’une manière différente. L’expérimentation était nécessaire dans le premier cas parce que l’appelante travaillait avec des boîtes noires (les composants logiciels de tiers) qui ne se comportaient pas de la manière dont l’appelante s’attendait à ce qu’elles se comportent.
[41] L’appelante a dû faire des expérimentations et réaliser des essais pour trouver ce qu’elle pouvait faire pour que tous les composants logiciels s’exécutent de la manière dont l’appelante l’exigeait afin que l’appareil portatif (ou un autre de ses appareils) fournisse le service requis par le client de l’appelante.
[42] M. Rupel a donné un exemple général de la nature des problèmes subis par l’appelante. Il a noté que le composant A, le composant B et le composant C peuvent tous fonctionner comme prévu, mais que lorsqu’on les assemble, une interaction complexe et inattendue se produit. Il a noté que la résolution de ce problème nécessite d’émettre une hypothèse, de réaliser des essais, d’obtenir un résultat, d’en tirer des leçons et de trouver une solution.
[43] M. Rupel a également expliqué comment l’appelante faisait le suivi des travaux qu’elle effectuait. Il a fait référence à la façon dont elle suivait et gérait les modifications apportées aux codes sources. Il a noté que le logiciel est ce qui fait fonctionner un ordinateur, et que par code source, on entend essentiellement la façon dont quelqu’un produit un logiciel.
[44] L’appelante maintenait un système de contrôle du code source qui faisait le suivi de chaque changement apporté au code source. Ce système permettait à toute personne apportant des modifications au code source d’être informée de toute modification antérieure qu’elle-même ou un autre employé avait apportée au code source. L’appelante maintenait également un système de contrôle des versions qui permettait également de faire le suivi des versions actuelles et précédentes d’un logiciel particulier.
[45] M. Rupel a expliqué qu’un espace dans le système de contrôle du code source a été prévu pour insérer des commentaires. Lorsqu’une personne apporte un changement au code source, elle explique dans les commentaires pourquoi elle a apporté ce changement.
[46] L’appelante utilisait également un logiciel de suivi des bogues ou des défauts : un premier logiciel appelé FogBugz et un second appelé Jira X. Ces deux logiciels permettaient à l’appelante de faire le suivi de tous les bogues ou défauts qui étaient signalés, du moment où le bogue ou le défaut avait été corrigé et de la date à laquelle une équipe d’assurance de la qualité avait examiné le correctif apporté.
[47] En ce qui concerne la détermination du moment où les travaux effectués relativement aux défauts constituaient des travaux de RS&DE, l’appelante, avec l’aide de son conseiller technique en RS&DE de l’Agence du revenu du Canada (l’« ARC »), M. Paul Wong, avait mis en place un système dans le logiciel de suivi des bogues ou des défauts (plus précisément Jira X). Ce système permettait à l’appelante de suivre les problèmes qu’elle déterminait comme étant des défauts, c’est-à-dire les choses qui ne fonctionnaient pas comme l’appelante s’attendait à ce qu’elles fonctionnent. Lorsque les développeurs de l’appelante tentaient de trouver une solution à un défaut, ils plaçaient dans le logiciel de suivi des bogues des renseignements relatifs aux travaux qu’ils effectuaient pour tenter de corriger le défaut détecté.
[48] L’appelante stockait également des renseignements relatifs à des projets précis dans le système de contrôle du code source. Le logiciel de suivi des bogues Jira X servait de référence pour les renseignements contenus dans le système de contrôle du code source. Le système de contrôle du code source contenait une référence semblable au logiciel de suivi des bogues et des défauts Jira X. Ce système et ce logiciel ont été mis en concordance.
[49] En fin de compte, l’appelante examinait le logiciel de suivi des bogues et le système de contrôle du code source pour déterminer quels défauts avaient été détectés, les essais effectués par les développeurs de l’appelante pour tenter de corriger ces défauts et la résolution finale du problème. Après avoir effectué cet examen, elle déterminait si les travaux constituaient des activités de RS&DE.
[50] Au cours des années pertinentes, l’appelante a présenté des demandes relatives à des travaux de RS&DE effectués dans le cadre de cinq projets distincts. Elle a défini des objectifs technologiques pour chacun des cinq projets. L’appelante a travaillé sur trois des projets au cours de son année d’imposition 2010 et sur deux des projets au cours de son année d’imposition 2011.
[51] Le ministre a accepté la demande de RS&DE de l’appelante à l’égard du deuxième projet réalisé en 2011. Par conséquent, l’appelante n’a déposé des appels qu’à l’égard des trois projets réalisés en 2010 et de l’autre projet réalisé en 2011.
[52] L’ECFP note que la demande de RS&DE de l’appelante pour son année d’imposition 2010 comprenait trois projets, consistant en des activités définies comme suit :
Projet no 1 de l’année d’imposition 2010 (« projet no 1 de 2010 »), « Méthodes conformes au protocole pour étendre la fonctionnalité Bluetooth ».
- AT1/OT1
- AT2/OT2
Projet no 2 de l’année d’imposition 2010 (« Projet no 2 de 2010 »), « Méthodes d’optimisation des services TCP sur les réseaux cellulaires ».
- AT1/OT1
- AT2/OT2
- AT3/OT3
Projet no 3 de l’année d’imposition 2010 (« Projet no 3 de 2010 »), « Méthodes et techniques pour améliorer le rendement de la messagerie ».
- AT1/OT1
- AT2/OT2
[53] Par AT/OT, on entend avancée technologique et obstacle technologique. M. Eidoo a témoigné que les déclarations réelles faites par l’appelante ne faisaient pas de distinction entre les différents AT ou OT. L’appelante a présenté des demandes concernant les trois projets de RS&DE. La ligne de démarcation entre les AT1/OT1, AT2/OT2 et AT3/OT3 a été tracée par l’ARC. En fait, l’ARC a converti les trois projets en sept projets.
[54] Le projet no 3 de 2010 n’est plus devant la Cour. L’ARC a reconnu que la partie du projet qu’elle a désignée comme étant AT1/OT1 était une demande de RS&DE valide. L’appelante a concédé, au cours de l’audience, que la partie restante de sa demande de RS&DE concernant le projet no 3 de 2010 ne constituait pas de la RS&DE.
[55] La Cour n’est saisie que d’une partie du projet no 1 de 2010 et du projet no 2 de 2010. L’ARC a reconnu que la partie du projet no 1 de 2010 qu’elle a désignée comme étant AT2/OT2 et la partie du projet no 2 de 2010 qu’elle a désignée comme étant AT2/OT2 aient constitué des activités de RS&DE. Par conséquent, les éléments suivants sont les seules parties de la demande de RS&DE de l’appelante pour l’année d’imposition 2010 dont est saisie la Cour :
AT1/OT1 du projet no 1 de 2010, et
AT1/OT1 et AT3/OT3 du projet no 2 de 2010.
[56] L’ECFP note que lors du calcul du revenu pour son année d’imposition 2011, l’appelante a déclaré des dépenses pour les deux demandes de RS&DE décrites de la façon suivante :
Projet no 1 de l’année d’imposition 2011 (« Projet no 1 de 2011 »), « Plateforme d’intégration multipoint pour les applications mobiles ».
- AT1/OT1
- AT2/OT2
- AT3/OT3
Projet no 2 de l’année d’imposition 2011 (« Projet no 2 de 2011 »), « Méthodes et techniques pour améliorer le rendement de la messagerie ».
- AT1/OT1
- AT2/OT2
[57] Tel qu’il a été signalé précédemment, la Cour n’est pas saisie du projet no 2 de 2011. L’ARC a accepté que l’ensemble du projet no 2 de 2011 constitue de la RS&DE.
[58] La Cour n’est saisie que de la partie du projet no 1 de 2011 désignée par l’ARC comme étant AT1/OT1. L’ARC a reconnu que la partie du projet qu’elle a désignée comme étant AT2/OT2 pouvait être qualifiée de RS&DE. L’appelante a concédé, au cours de l’audience, que la partie du projet no 1 de 2011 désignée comme étant AT3/OT3 ne constituait pas de la RS&DE.
[59] M. Rupel a décrit en détail chacun des quatre projets devant la Cour.
II. Témoins experts
[60] J’ai entendu trois témoins experts. L’appelante a cite M. Gerald Penn et l’intimée a cité M. Shrinavensen Keshav et Mme Shirook Ali.
[61] M. Penn a donné son opinion quant à savoir si les travaux effectués par l’appelante sur ses cinq projets étaient de la recherche ou du développement expérimental selon les normes applicables à un chercheur en informatique.
[62] M. Keshav a donné son opinion quant à savoir si les travaux de l’appelante relatifs aux AT1/OT1 et AT3/OT3 du projet no 2 de 2010 et aux AT1/OT1 et AT3/OT3 du projet no 1 de 2011, tels qu’ils sont décrits dans certains documents qui lui ont été fournis par l’ARC, étaient conformes aux lignes directrices établies par l’ARC pour les crédits de RS&DE.
[63] Mme Ali a donné son opinion sur le degré d’admissibilité des travaux effectués par l’appelante aux crédits de RS&DE quant aux deux objectifs techniques suivants :
La mise en œuvre d’un mécanisme d’étranglement pour empêcher les dépassements lors de l’envoi de plus de 64 ko au moyen d’une connexion d’imprimante Bluetooth.
La détermination d’une limite de concurrence avec MSMQ lorsqu’environ 200 dispositifs simultanés tentent d’effectuer une opération de messagerie.
[64] Ce sont les deux projets désignés par l’ARC comme AT1/OT1 du projet no 1 de 2010 et comme AT2/OT2 du projet no 3 de 2010.
A. Rapport d’expert de M. Penn
[65] Au moment où M. Penn a été présenté à la Cour, l’intimée a affirmé qu’elle avait de nombreux doutes concernant l’admissibilité de son rapport d’expert. La Cour a tenu un voir-dire pour déterminer l’admissibilité de l’opinion de M. Penn. M. Penn a témoigné pendant le voir-dire.
[66] À la fin du voir-dire, j’ai retenu le rapport de M. Penn et l’ai reconnu en tant que témoin expert pour donner à la Cour son opinion sur la question de savoir si les travaux de l’appelante au cours des années 2010 et 2011 sur les projets pertinents constituaient des travaux de recherche ou un développement expérimental selon les normes applicables à un chercheur en technologie de l’information. J’ai informé les parties que j’exposerais les raisons pour lesquelles j’ai retenu le rapport de M. Penn dans mes motifs de jugement écrits.
[67] Le critère d’admissibilité en preuve d’une opinion d’expert est un critère comporte deux étapes, tel qu’établi par la Cour suprême du Canada dans l’arrêt White Burgess Langille Inman c. Abbott and Haliburton Co., 2015 CSC 23 (« Inman »). L’arrêt Inman confirme et clarifie les principes de common law précédemment exposés par la Cour suprême du Canada dans l’arrêt R. c. Mohan, [1994] 2 R.C.S. 9 (« Mohan »).
[68] La première étape du critère exige que la partie qui présente l’expert proposé établisse que la preuve satisfait aux quatre exigences minimales suivantes (les « facteurs de la jurisprudence Mohan ») :
- la pertinence;
- la nécessité d’aider le juge des faits;
- l’absence de toute règle d’exclusion;
- la qualification suffisante de l’expert.
[69] La deuxième étape exige du juge qui préside qu’il effectue une analyse coûts-bénéfices pour déterminer si une preuve d’expert par ailleurs admissible doit être exclue parce que sa valeur probante est surpassée par son effet préjudiciable. Pour ce faire, le juge qui préside doit tenir compte de facteurs tels que le délai, le préjudice et le risque de confusion qui peuvent en résulter.
[70] Au début du voir-dire, l’avocate de l’intimée a affirmé qu’elle avait des réserves quant aux qualifications de M. Penn et sur son rapport d’expert. Elle a noté que ses réserves concernant le rapport se rapportaient à la pertinence et à la nécessité d’aider le juge des faits.
[71] Je n’ai aucune difficulté à reconnaître M. Penn comme expert dûment qualifié. Il avait les connaissances et l’expérience particulières requises concernant le sujet précis qu’on lui a présenté. Il a acquis ces connaissances particulières grâce à des années d’étude et d’expérience.
[72] M. Penn est titulaire d’un doctorat de l’école d’informatique de l’Université Carnegie Mellon à Pittsburgh, en Pennsylvanie.
[73] Depuis 2013, il est professeur titulaire au département d’informatique de l’Université de Toronto. Il était auparavant le président associé de la recherche et des relations industrielles du département d’informatique de l’Université de Toronto. Il enseigne à l’Université de Toronto depuis 2005.
[74] Dans le cadre de ses fonctions, il a souvent collaboré avec des partenaires du secteur privé pour déterminer s’ils avaient le droit de demander des crédits de RS&DE pour certains projets de recherche et de développement.
[75] Il possède une vaste expérience en informatique et a notamment collaboré avec la NASA lorsqu’il était chercheur invité au Centre de recherches Ames, en Californie. Ses fonctions à la NASA portaient sur l’interaction entre l’homme et l’ordinateur. Il s’agissait de recherches sur un système de dialogue pour les missions extravéhiculaires de la mission sur Mars.
[76] M. Penn compte 20 ans d’expérience dans la recherche sur les technologies de l’information. Il a indiqué qu’il avait travaillé sur des projets similaires à ceux que l’appelante a entrepris pendant la période pertinente. Il a donné de nombreux exemples de projets de recherche précis qui portaient sur Bluetooth et les réseaux sans fil dans des domaines similaires aux projets d’Allegro.
[77] L’intimée n’a pas remis en question l’indépendance de M. Penn. En fait, l’indépendance de M. Penn est attestée par le fait qu’il a convenu avec le ministre que les travaux effectués par l’appelante sur l’un des sous-projets (AT3/OT3 du projet no 1 de 2011) ne constituaient pas des travaux de recherche ou du développement expérimental.
[78] Le témoignage d’expert de M. Penn est nécessaire. Son opinion m’est indispensable en raison de la nature hautement technique des projets en cause. Son témoignage est également pertinent. Il se rapporte aux principales questions dont est saisie la Cour.
[79] L’intimée n’a pas soulevé de règle d’exclusion.
[80] Je conclus également que les bénéfices de son témoignage l’emportent sur les coûts potentiels. En fait, je ne vois pas de coûts importants.
[81] Le rapport de M. Penn définit les questions qu’il a été chargé de traiter, note les documents et les discussions sur lesquels il s’est appuyé, donne un résumé de son opinion et ensuite, pour chacun des projets, donne une analyse de la façon dont il est arrivé à ses conclusions. Voilà exactement ce qu’attend la Cour d’un rapport d’expert.
[82] La principale réserve de l’intimée concernant le rapport de M. Penn porte sur ses nombreuses références à une revue technique des projets de l’appelante rédigée par le conseiller en recherche scientifique et technologique de l’appelante, M. Paul Wong. Comme nous l’avons vu précédemment, M. Wong a aidé l’appelante à développer le système de son logiciel de suivi des bogues et des défauts pour documenter les défauts détectés par l’appelante.
[83] Le rapport de M. Wong est le rapport dans lequel l’ARC disjoint les cinq projets de l’appelante en douze projets distincts. Le rapport de M. Wong est l’un des 284 fichiers de documents codés électroniquement examinés par M. Penn.
[84] Lorsqu’il donne son opinion d’expert sur les projets de l’appelante, M. Penn renvoie aux conclusions de M. Wong quant à savoir si chacun des 12 projets définis par M. Wong constitue de la RS&DE et indique s’il est d’accord ou non avec M. Wong. M. Penn renvoie aux conclusions de M. Wong au cours de son opinion d’expert pour chaque projet.
[85] M. Penn donne son opinion d’expert aux pages 2 à 16 de son rapport. Aux pages 17 à 24 de son rapport, sous le titre Pièce C, M. Penn donne son avis sur certains documents que M. Wong a fournis à l’appelante en réponse à un engagement pris au cours de l’interrogatoire préalable de M. Wong. J’ai fait abstraction de cette partie du rapport de M. Penn. Elle ne fait pas partie de son opinion d’expert quant à savoir si les travaux effectués par l’appelante constituent des travaux de recherche ou de développement expérimental. Je crois comprendre que l’appelante a demandé l’accès aux commentaires sur ces pages dans l’espoir qu’ils pourraient être utilisés pour régler l’appel. Cependant, aucune discussion n’a eu lieu en vue d’une transaction.
[86] L’avocate de l’intimée a fait valoir que l’opinion écrite de M. Penn est [traduction] « tellement dépendante » de sa réfutation du rapport de M. Wong qu’il est impossible d’en extraire les opinions portant uniquement sur la question de savoir si les projets constituent des activités de RS&DE. De l’avis de l’intimée, il lui serait préjudiciable de le faire.
[87] Je rejette la thèse de l’intimée. Le rapport de M. Penn est très clair et concis. Je n’ai aucune difficulté à différencier ses commentaires concernant le rapport de M. Wong de ses propres conclusions concernant la question de savoir si les travaux de l’appelante sur des projets individuels constituaient des travaux de recherche ou de développement expérimental. En fait, je ne vois pas comment M. Penn aurait pu donner son avis sans invoquer le rapport de M. Wong. Il était tenu d’informer la Cour des renseignements auxquels il a renvoyé pour se forger une opinion. C’est l’ARC, et non l’appelante, qui a disjoint les cinq projets de l’appelante en douze projets. M. Penn aurait dû comprendre pourquoi l’ARC a subdivisé les cinq projets de l’appelante en douze projets avant de donner son opinion.
[88] Il est certain que le témoin expert de l’intimée, Mme Ali, a estimé qu’il était important d’examiner le rapport de M. Wong puisqu’il est mentionné dans son rapport comme l’une des principales références qu’elle a utilisées pour préparer son rapport d’expert (le rapport de M. Wong est déposé sous la pièce A-8).
[89] La deuxième réserve de l’intimée concerne les entretiens téléphoniques que M. Penn a eus avec M. Rupel et M. Wayne Hammerschlag, un employé de l’appelante. Dans son rapport, M. Penn a renvoyé à ces entretiens lorsqu’il a informé la Cour du fondement sur lequel il s’est forgé une opinion.
[90] Au cours du contre-interrogatoire, l’avocate de l’intimée a demandé à M. Penn s’il existait une transcription de ces entretiens. Comme on peut s’y attendre, il n’y en a pas. Cependant, M. Penn a déclaré qu’il disposait de notes résumant ces entretiens. À la demande de l’avocate de l’intimée et avant la fin du contre-interrogatoire de M. Penn par celle-ci pendant le voir-dire, M. Penn a produit ces notes. Ces notes (pièce A-38) ont une longueur de deux pages, sont sous forme télégraphique et fournissent un résumé des réponses de M. Rupel à huit questions posées par M. Penn et des réponses de M. Hammerschlag à huit questions posées également par M. Penn.
[91] Les notes sont inadmissibles aux fins de preuve de tout fait invoqué dans les notes, car il s’agit de ouï-dire. Cependant, elles sont admissibles comme preuve du fondement sur lequel M. Penn s’est forgé une opinion.
[92] M. Penn a témoigné qu’il avait posé les questions afin de clarifier certains problèmes qu’il avait recensés en examinant les 284 documents électroniques. Les questions concernaient l’entreprise et les procédures de l’appelante.
[93] L’avocate de l’intimée a soutenu que je ne devais pas recevoir le rapport d’expert de M. Penn, car la transcription des entretiens n’a pas été produite à l’intimée ou à la Cour. En conséquence, le fondement des opinions de M. Penn qui s’appuyaient sur les entretiens ne pouvait pas être vérifié.
[94] Même si l’opinion d’un expert est fondée en tout ou en partie sur des renseignements qui ne peuvent être vérifiés devant la Cour, cela ne la rend pas inadmissible. Il s’agit d’une question de poids. La mesure dans laquelle le fondement factuel de l’opinion est vérifié par des éléments de preuve admissibles aura une incidence sur le poids qui lui sera accordé.
[95] Les entretiens de M. Penn avec M. Rupel et M. Hammerschlag ont permis à M. Penn de clarifier certaines questions qu’il se posait sur l’entreprise et les procédures de l’appelante. M. Rupel a produit à la Cour de nombreux éléments de preuve sur l’entreprise et les procédures de l’appelante. Je conclus que toutes les références de M. Penn à l’entreprise de l’appelante dans son rapport d’expertise et au cours de son témoignage principal et son contre-interrogatoire sont conformes au témoignage de M. Rupel. En d’autres termes, le fondement factuel du témoignage de M. Penn a été prouvé par les éléments de preuve admissibles devant la Cour.
B. Rapports d’expert de Mme Ali et de M. Keshav
[96] J’ai reconnu Mme Ali et de M. Keshav comme étant des témoins experts dans les domaines dans lesquels ils ont produit leurs opinions.
[97] L’avocat de l’appelante s’est dit préoccupé de ce que les rapports d’expert de Mme Ali et de M. Keshav étaient fondés sur des renseignements factuels très limités. Il a soutenu que Mme Ali et M. Keshav n’avaient pas reçu les documents clés dont ils avaient besoin pour se forger une opinion éclairée.
[98] J’ai informé l’avocat de l’appelante que je ne pouvais pas examiner les questions relatives au fondement factuel des rapports de Mme Ali et de M. Keshav avant d’avoir examiné les rapports en détail et d’avoir une compréhension éclairée du fondement factuel de leurs opinions. De plus, je l’ai informé que ses doutes concernaient le poids que j’accorderais aux rapports, ce que je ne pouvais décider avant d e les avoir lus en détail et entendu Mme Ali et M. Keshav.
[99] Après avoir lu chacun des rapports d’expert et entendu les deux experts, j’abonde dans le sens de l’avocat de l’appelante : le fondement factuel de chacun des rapports repose sur des renseignements insuffisants. Plus précisément, aucun des deux experts cités par l’intimée n’avait une compréhension suffisante de l’entreprise, des produits ou des procédures de l’appelante pour leur permettre de donner des opinions qui aideraient la Cour.
[100] M. Rupel et M. Penn ont tous deux témoigné que l’environnement technologique difficile dans lequel l’appelante tentait d’exercer ses activités était à l’origine des divers problèmes technologiques qu’elle avait subis.
[101] Comme je l’ai noté précédemment, le produit de base de l’appelante était sa plateforme (logiciel), qu’il a développée et constamment améliorée pour s’adapter aux différentes particularités de divers appareils portatifs, serveurs et imprimantes. M. Rupel a témoigné que l’appelante essayait de développer des produits qui permettraient de résoudre les problèmes qui se posent lorsqu’on traite les interactions entre de nombreux systèmes complexes. À l’époque, ses clients utilisaient de nombreux appareils et imprimantes portatifs qui en étaient aux premiers stades de développement. Elle devait également concevoir des systèmes qui fonctionnaient avec les divers serveurs de ses clients et reconnaître les différents environnements dans lesquels chacun de ses clients exerçait ses activités. À mon avis, il était essentiel de comprendre les activités de l’appelante et les questions techniques qui se posaient dans son environnement de travail pour pouvoir donner une opinion éclairée sur la question de savoir si ses travaux constituaient des travaux de développement expérimental.
[102] Il ressort clairement du témoignage qui m’a été rendu que M. Penn a passé beaucoup de temps à comprendre l’environnement commercial de l’appelante et, plus important encore, l’incertitude technique qui s’est manifestée lorsque l’appelante a tenté de développer ses produits afin de poursuivre et de faire croître son entreprise.
[103] Il est clair que M. Penn a estimé que cela était essentiel pour lui permettre de donner une opinion éclairée. Par exemple, comme je l’expliquerai, lors de l’examen de la partie AT/OT1 du projet no 1 de 2010, l’un des fa