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 31^e jour de mars 2021.

« S. D’Arcy »

Traduction certifiée conforme

ce 15^e 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 (5^e 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, M^me Cathy Sporich, et deux témoins experts, M. Shrinavensen Keshav et M^me 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 n^o 1 de l’année d’imposition 2010 (« projet n^o 1 de 2010 »), « Méthodes conformes au protocole pour étendre la fonctionnalité Bluetooth ».

• - AT1/OT1

• - AT2/OT2

Projet n^o 2 de l’année d’imposition 2010 (« Projet n^o 2 de 2010 »), « Méthodes d’optimisation des services TCP sur les réseaux cellulaires ».

• - AT1/OT1

• - AT2/OT2

• - AT3/OT3

Projet n^o 3 de l’année d’imposition 2010 (« Projet n^o 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 n^o 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 n^o 3 de 2010 ne constituait pas de la RS&DE.

[55] La Cour n’est saisie que d’une partie du projet n^o 1 de 2010 et du projet n^o 2 de 2010. L’ARC a reconnu que la partie du projet n^o 1 de 2010 qu’elle a désignée comme étant AT2/OT2 et la partie du projet n^o 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 n^o 1 de 2010, et

AT1/OT1 et AT3/OT3 du projet n^o 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 n^o 1 de l’année d’imposition 2011 (« Projet n^o 1 de 2011 »), « Plateforme d’intégration multipoint pour les applications mobiles ».

• - AT1/OT1

• - AT2/OT2

• - AT3/OT3

Projet n^o 2 de l’année d’imposition 2011 (« Projet n^o 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 n^o 2 de 2011. L’ARC a accepté que l’ensemble du projet n^o 2 de 2011 constitue de la RS&DE.

[58] La Cour n’est saisie que de la partie du projet n^o 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 n^o 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 M^me 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 n^o 2 de 2010 et aux AT1/OT1 et AT3/OT3 du projet n^o 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] M^me 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 n^o 1 de 2010 et comme AT2/OT2 du projet n^o 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 n^o 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, M^me 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 M^me Ali et de M. Keshav

[96] J’ai reconnu M^me 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 M^me Ali et de M. Keshav étaient fondés sur des renseignements factuels très limités. Il a soutenu que M^me 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 M^me 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 M^me 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 n^o 1 de 2010, l’un des faits clés sur lequel M. Penn s’est appuyé était que l’appelante traitait une gamme d’appareils mobiles qui n’étaient pas fabriqués par l’appelante.

[104] Après avoir lu les rapports de M^me Ali et de M. Keshav et entendu leur déposition verbale, j’ai conclu que ni l’un ni l’autre n’avait la compréhension requise de l’entreprise de l’appelante. À mon avis, cela constitue une grave lacune dans leurs rapports. Ils ne disposaient pas de la base factuelle nécessaire qui leur aurait permis de donner à la Cour des opinions éclairées sur les projets en question.

[105] M. Keshav déclare dans son rapport qu’il a fondé son opinion concernant les quatre projets qu’il a examinés sur les documents suivants :

• - Le résumé de la demande de RS&DE de l’appelante déposée auprès de l’ARC (formulaire T661 de l’ARC).

• - Des documents intitulés [traduction] « Échéancier des activités sans fil d’Allegro » pour 2010 et pour 2011 (le document de 2010 fait deux pages et celui de 2011 fait deux pages et demie).

• - Un document intitulé [traduction] « Supplément de 2010 relatif à l’après-examen par l’ARC d’Allegro » et un document intitulé [traduction] « Supplément de 2011 relatif à l’après-examen par l’ARC d’Allegro ».

• - Une lettre de l’ARC adressée à l’appelante.

[106] Il ressort clairement de son témoignage que M. Keshav s’est principalement appuyé sur le formulaire T661 de l’appelante. Il ressort également clairement de son témoignage, notamment de ses réponses lors de son contre-interrogatoire, que M. Keshav avait une connaissance très limitée de l’entreprise de l’appelante. Il n’était pas au courant de la nature de l’entreprise de l’appelante, de ses clients, de la nature des divers appareils utilisés dans l’entreprise de l’appelante et du système de contrôle du code source et du logiciel que l’appelante utilisait pour documenter ses recherches.

[107] Par exemple, M. Keshav ne savait pas que l’appelante développait un logiciel qui serait compatible avec plusieurs ordinateurs portatifs. Il ne savait pas non plus quells étaient les problèmes subis par l’appelante en raison de la documentation limitée fournie par les fabricants.

[108] Je ne comprends pas comment M. Keshav a pu donner son opinion sans comprendre l’entreprise de l’appelante, les problèmes technologiques qui se sont posés lorsque l’appelante a essayé de développer des produits pour répondre aux besoins de ses clients, les systèmes que l’appelante a utilisés pour faire le suivi de ces problèmes technologiques et les mesures qu’elle a prises pour les résoudre.

[109] M. Keshav a parfois conclu dans son rapport que l’appelante n’a pas tenté de présenter et de valider officiellement une hypothèse. Le problème que j’ai avec cette conclusion est qu’il a admis qu’il ne connaissait pas les logiciels FogBugz et Jira X (le logiciel de suivi des bogues ou des défauts) que l’appelante a utilisés pour documenter le travail qu’il a effectué (y compris l’élaboration d’hypothèses) sur les soi-disant défauts qu’elle a rencontrés.

[110] Ce logiciel était un élément clé du système que l’appelante avait développé pour formuler et documenter ses hypothèses lorsqu’elle essayait de résoudre les problèmes techniques qu’elle subissait. Par exemple, la désignation par l’appelante d’un projet comme étant admissible à titre de RS&DE était fondée principalement sur la documentation de son travail contenue dans le logiciel Jira X (qui contenait la documentation relative aux hypothèses formulées par l’appelante). Or, M. Keshav n’était même pas au courant de l’existence de ce logiciel, celui-là même que l’appelante utilisait pour définir les projets qu’elle réalisait au cours d’une année donnée afin de déterminer si les travaux effectués sur ces projets constituaient des travaux de RS&DE.

[111] Ce manque d’information concernant l’entreprise de l’appelante est évident dans le rapport de M. Keshav, dans lequel il formule plusieurs postulats factuels. Tout au long de son rapport, lorsqu’il discute des faits sur lesquels il s’est appuyé et des hypothèses qu’il a formulées, il utilise des expressions telles que [traduction] « ce n’est pas clair », « cela semble indiquer » et [traduction] « peut-être ce que l’on voulait dire ». L’utilisation de ces expressions par M. Keshav, ainsi que son besoin de formuler de nombreux postulats factuels, prouve qu’il n’avait pas le fondement factuel requis pour fournir les renseignements demandés. Ceci a été renforcé lors de son contre-interrogatoire.

[112] J’ai des réserves similaires concernant le rapport de M^me Ali en ce qui concerne le seul projet qu’elle a examiné et dont la Cour est saisie, le AT1/OT1 du projet n^o 1 de 2010. Au même titre que M. Keshav, sa principale documentation de référence était un nombre limité de documents produits par l’ARC. Elle a utilisé trois documents que M. Keshav a également utilisés : les formulaires T661, les calendriers de l’entreprise et la lettre de l’ARC mentionnée dans le rapport de M. Keshav. Ses principaux documents de référence comprenaient également le rapport technique de M. Wong, un énoncé de politique de l’ARC et cinq courts documents de l’appelante.

[113] Comme M. Keshav, M^me Ali a également affirmé qu’elle ne connaissait pas l’entreprise de l’appelante.

[114] M. Rupel a témoigné que les obstacles techniques auxquels l’appelante s’est heurtée en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2010 ont été causés par le fait que l’appelante, lors du développement de ses produits, a dû traiter avec des piles Bluetooth de différents fabricants, des imprimantes de différentes entreprises et de multiples combinés. M^me Ali a témoigné qu’elle n’était pas au courant que l’appelante avait affaire à différentes piles et imprimantes et à de multiples combinés.

[115] M^me Ali a affirmé que des environnements différents (différents types d’imprimantes et différents types de combinés) auraient des limitations différentes. Elle a noté que pour que l’appelante trouve une solution qui fonctionne avec toutes les limitations, il faudrait faire des enquêtes et des travaux de développement. Cependant, elle ne savait pas que l’appelante était confrontée à ces différents environnements.

[116] M^me Ali a noté que l’expérimentation implique non seulement de tester et d’analyser, mais aussi d’explorer la relation entre les essais, d’expliquer les résultats par rapport à l’hypothèse soulevée, de tirer des conclusions, de proposer une nouvelle hypothèse ou d’effectuer des essais supplémentaires. L’une des réserves soulevées par M^me Ali dans son rapport est qu’il n’était pas clair pour elle si l’appelante avait effectué cette analyse.

[117] M. Rupel a témoigné que l’appelante a documenté cette analyse dans son système de contrôle du code source et son logiciel de suivi des bogues ou des défauts. M^me Ali a noté au cours de son contre-interrogatoire qu’elle n’avait pas été informée du système utilisé par l’appelante pour documenter les problèmes techniques que celle-ci a affrontés et de la manière dont elle a traité ces problèmes. Cela comprenait l’utilisation par l’appelante du logiciel de suivi des bogues et des défauts.

[118] Je trouve surprenant le fait qu’elle ne connaissait pas les logiciels Jira X et FogBugz puisqu’elle note dans son rapport d’expert que l’un des documents sur lesquels elle s’est appuyée est intitulé [traduction] « Échantillons de renseignements contemporains », que l’intimée a déposé comme pièce R-66. Dans ce document de deux pages, il est signalé que l’une des sources utilisées par l’appelante pour déterminer les tâches effectuées dans le cadre de chaque projet de RS&DE était l’information recueillie par l’analyse des dossiers Jira X et FogBugz.

[119] M^me Ali a déclaré qu’elle était préoccupée par les renseignements qui lui avaient été fournis, mais elle n’a pas demandé de renseignements supplémentaires. Elle n’a pas communiqué avec qui que ce soit. Elle a pris les renseignements fournis par son client, l’ARC, et a donné son opinion en fonction de ces renseignements.

[120] L’appelante tentait de développer un nouveau produit (sa plateforme) qui fonctionnerait de façon fluide avec une multitude d’appareils utilisant différents systèmes d’exploitation et tournant sur les systèmes d’exploitation de divers clients. Ni M^me Ali ni M. Keshav n’étaient au courant de cet environnement difficile. En raison de ce faible fondement factuel, surtout si on la compare au fondement factuel sur lequel repose l’opinion de M. Penn, je n’ai accordé aucun poids aux rapports d’expert de M^me Ali et de M. Keshav. Le seul rapport d’expert auquel j’ai accordé de l’importance est celui de M. Penn.

III. Résumé du droit

[121] Le paragraphe 248(1) donne la définition suivante de la RS&DE :

« activités de recherche scientifique et de développement expérimental » Investigation ou recherche systématique d’ordre scientifique ou technologique, effectuée par voie d’expérimentation ou d’analyse, c’est-à-dire :

a) la recherche pure, à savoir les travaux entrepris pour l’avancement de la science sans aucune application pratique en vue;

b) la recherche appliquée, à savoir les travaux entrepris pour l’avancement de la science avec application pratique en vue;

c) le développement expérimental, à savoir les travaux entrepris dans l’intérêt du progrès technologique en vue de la création de nouveaux matériaux, dispositifs, produits ou procédés ou de l’amélioration, même légère, de ceux qui existent.

Pour l’application de la présente définition à un contribuable, sont compris parmi les activités de recherche scientifique et de développement expérimental :

d) les travaux entrepris par le contribuable ou pour son compte relativement aux travaux de génie, à la conception, à la recherche opérationnelle, à l’analyse mathématique, à la programmation informatique, à la collecte de données, aux essais et à la recherche psychologique, lorsque ces travaux sont proportionnels aux besoins des travaux visés aux alinéas a), b) ou c) qui sont entrepris au Canada par le contribuable ou pour son compte et servent à les appuyer directement.

Ne constituent pas des activités de recherche scientifique et de développement expérimental les travaux relatifs aux activités suivantes :

e) l’étude du marché et la promotion des ventes;

f) le contrôle de la qualité ou la mise à l’essai normale des matériaux, dispositifs, produits ou procédés;

g) la recherche dans les sciences sociales ou humaines;

h) la prospection, l’exploration et le forage fait en vue de la découverte de minéraux, de pétrole ou de gaz naturel et leur production;

i) la production commerciale d’un matériau, d’un dispositif ou d’un produit nouveau ou amélioré, et l’utilisation commerciale d’un procédé nouveau ou amélioré;

j) les modifications de style;

k) la collecte normale de données.

[122] La jurisprudence a eu recours à cinq critères pour déterminer si une activité particulière constitue une activité de RS&DE. Ces critères ont été résumés par la Cour d’appel fédérale dans l’arrêt CW Agencies Inc. c. Canada, 2001 CAF 393, 2002 D.T.C. 6740, par. 17, comme suit :

1. Existait-il un risque ou une incertitude technologique qui ne pouvait être éliminé par les procédures habituelles ou les études techniques courantes?

2. La personne qui prétend se livrer à de la RS & DE a-t-elle formulé des hypothèses visant expressément à réduire ou à éliminer cette incertitude technologique?

3. La procédure adoptée était-elle complètement conforme à la discipline de la méthode scientifique, notamment dans la formulation, la vérification et la modification des hypothèses?

4. Le processus a-t-il abouti à un progrès technologique?

5. Un compte rendu détaillé des hypothèses vérifiées et des résultats a-t-il été fait au fur et à mesure de l’avancement des travaux?

[123] Les critères ont été exposés pour la première fois dans une décision de notre Cour par le juge Bowman (tel était alors son titre), Northwest Hydraulic Consultants Limited c. La Reine, 98 D.T.C. 1839 (CCI) (la « décision Northwest Hydraulic »).

[124] En discutant de l’existence d’un risque ou d’une incertitude technologique, le juge Bowman a noté ce qui suit dans la décision Northwest Hydraulic, au paragraphe 16 :

a) Lorsqu’on parle de « risque ou [d’]incertitude technologique » dans ce contexte, on laisse implicitement entendre qu’il doit exister une incertitude quelconque qui ne peut pas être éliminée par les études techniques courantes ou par les procédures habituelles. Je ne parle pas du fait que dès qu’un problème est décelé, il peut exister un certain doute au sujet de la façon dont il sera réglé. Si la résolution du problème est raisonnablement prévisible à l’aide de la procédure habituelle ou des études techniques courantes, il n’y a pas d’incertitude technologique telle que cette expression est utilisée dans ce contexte.

b) Qu’entend-on par « études techniques courantes »? C’est cette question (ainsi que celle qui se rapporte au progrès technologique) qui semble avoir divisé les experts plus que toute autre. En résumé, cela se rapporte aux techniques, aux procédures et aux données qui sont généralement accessibles aux spécialistes compétents dans le domaine.

IV. Quels projets constituaient de la RS&DE?

[125] Je commencerai par rechercher, pour chaque projet, s’il y avait un risque ou une incertitude technologique qui ne pouvait être éliminé par des études techniques courantes ou par les procédures habituelles.

A. Partie AT1/OT1 du projet n^o 1 de 2010

[126] Le formulaire T661 produit auprès de l’ARC par l’appelante décrivait comme suit l’avancée technologique que l’appelante tentait de réaliser en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2010 : [traduction] « 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 sur une connexion d’imprimante Bluetooth (en surmontant les limitations particulières de la mise en œuvre de l’impression Bluetooth) ». [1]

[127] M. Rupel a décrit de manière assez détaillée les obstacles technologiques que l’appelante a dû surmonter, les travaux qu’elle a effectués et les résultats qu’elle a obtenus en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2010.

[128] Il a noté que les imprimantes en question étaient de petites imprimantes qui étaient utilisées par environ 20 % de ses clients et qui étaient accrochées à la ceinture des employés du client. Ces imprimantes imprimaient des documents, tels que des reçus, à partir de renseignements transférés par Bluetooth de l’appareil portatif à la petite imprimante. C’est Microsoft qui a développé le logiciel utilisé pour communiquer avec la petite imprimante (appelée « pile Bluetooth »). L’appelante n’était pas en mesure de [traduction] « regarder à l’intérieur » du logiciel pour voir comment il fonctionnait ou pour ajuster son fonctionnement.

[129] Le problème auquel l’appelante était confrontée était que les petites imprimantes disposaient d’un tampon de 64 ko qui stockait les renseignements envoyés par l’appareil portatif à l’imprimante jusqu’à ce que celle-ci soit en mesure d’utiliser ces renseignements pour imprimer le document. Le problème était que si trop de renseignements étaient envoyés, le tampon était dépassé et une partie ou la totalité des renseignements était perdue. Cela signifiait que son client ne pouvait pas obtenir une impression correcte du document.

[130] Le fait que les différents clients de l’appelante disposaient de piles Bluetooth de différentes sociétés et d’imprimantes et d’appareils portatifs de différents fabricants aggravait le problème. L’appelante devait développer un logiciel qui fonctionnerait sur tous ces systèmes.

[131] M. Rupel a signalé que les problèmes ont placé l’appelante dans une situation qui était au-delà des limites des études techniques courantes. Il a noté que dans le cadre d’études techniques courantes, on travaille avec des systèmes qui n’ont pas de dépassement de tampon, des systèmes qui fonctionnent. L’appelante devait travailler avec le système de quelqu’un d’autre qui comportait des bogues et ne fonctionnait pas correctement, un système qui était essentiellement une boîte noire.

[132] M. Rupel a déclaré que l’appelante avait expérimenté trois solutions différentes au problème, en envisageant un [traduction] « scénario avec pertes », en utilisant une méthode de compression transparente et un mécanisme d’étranglement. Il a noté que l’appelante cherchait des solutions créatives qui lui permettraient de contourner le problème tout en utilisant les interfaces standard.

[133] Le [traduction] « scénario avec pertes » consistait à envoyer moins de données afin d’éviter de dépasser le tampon de 64 ko. M. Rupel a expliqué que cela signifiait que le document imprimé n’était pas totalement fidèle, en ce sens que les renseignements transmis à l’imprimante étaient incomplets d’une certaine manière, ce qui peut être acceptable selon l’application. Le document imprimé peut ne pas être aussi beau que l’original, mais il peut être acceptable pour l’utilisateur.

[134] Compresser les données signifie utiliser l’une des nombreuses méthodes disponibles. Il semble que l’une des méthodes que l’appelante a mises à l’essai était de créer une image JPEG. L’image JPEG contenait tout le texte qui devait être transféré, mais dans un format compressé.

[135] M. Rupel a noté que l’appelante a essayé de développer une méthode de compression transparente. Cela signifiait que l’appelante essayait de compresser et de décompresser les données sans que le logiciel intervenant sache ce qui se passait. L’appelante a dû développer un logiciel pour « creuser » à différents endroits de la pile Bluetooth afin d’essayer d’injecter la compression d’une manière qui éviterait le dépassement du tampon de 64 ko.

[136] Aucune de ces méthodes ne s’est avérée efficace. Cependant, l’appelante a pu surmonter le problème en développant un mécanisme d’étranglement. Un mécanisme d’étranglement est un moyen de contrôler la vitesse à laquelle les données sont poussées dans le système. M. Rupel a noté qu’en faisant des expériences, l’appelante a pu trouver une vitesse optimale qui permettait à l’imprimante Bluetooth de vider sa mémoire tampon assez rapidement pour ne jamais la dépasser.

[137] Une expérimentation s’est révélée nécessaire, car l’appelante était aux prises avec plusieurs obstacles. Si la vitesse était trop lente, l’imprimante s’endormait, si elle était trop rapide, le problème s’aggravait. En outre, l’appelante a dû faire face au fait que les imprimantes n’ont pas une vitesse d’impression constante. Elle a également dû développer un logiciel qui fonctionne pour différents types de documents, pour différents types d’imprimantes et différents types d’ordinateurs portatifs. Comme nous l’avons signalé précédemment, elle a dû faire tout cela sans avoir accès au logiciel qui faisait fonctionner les imprimantes et les ordinateurs de poche, les soi-disant boîtes noires. L’appelante a fait le suivi des travaux qu’elle a effectués dans son système de contrôle du code source et son logiciel Jira X détectant les défauts.

Opinion de M. Penn

[138] M. Penn a conclu que les travaux exécutés en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2010 portaient sur le développement expérimental et la recherche appliquée.

[139] M. Penn a noté que le problème avec lequel l’appelante était aux prises résultait en grande partie de l’absence de normes et des problèmes d’incompatibilité qui prévalaient en 2010 et 2011. Il a noté que l’appelante a dû mener une enquête systématique sur l’éventail des options disponibles auprès de différents fournisseurs de piles Bluetooth ainsi que sur différentes plateformes d’appareils mobiles afin de déterminer ce qu’il était possible de faire.

[140] Ses véritables conclusions étaient les suivantes :

[traduction]

L’application de l’étranglement et de la compression ne peut être réalisée qu’en fixant certains paramètres quantitatifs qui sont inhérents à ces techniques, tels que des durées et des taux de transfert ciblés ou des pourcentages de compression. Alors que le réglage ou l’optimisation des réglages de ces paramètres pour une paire fixe d’appareils pourrait être considéré comme une tâche courante dans d’autres circonstances, ce projet traitait de l’interopérabilité sur une gamme d’appareils mobiles qui n’étaient pas fabriqués par Allegro. Je ne connais aucune base de connaissances facile à évaluer, aujourd’hui ou en 2010, grâce à laquelle les ingénieurs d’Allegro auraient pu régler ces paramètres simplement en faisant preuve de diligence. Il s’agissait d’un détournement laborieux et expérimental des activités ordinaires de développement de logiciels qu’aucun ingénieur en logiciels raisonnable ne qualifierait de tâche courante.

[...] Premièrement, Allegro rassemblait une base de connaissances exclusive sur les comportements expérimentaux des appareils mobiles qui n’existaient pas sous une forme facile à évaluer et, deuxièmement, si elle avait choisi de rendre cette base de connaissances publique, sa valeur pour la communauté plus large des développeurs de logiciels mobiles se serait étendue même à ceux qui n’avaient jamais eu l’intention d’acheter des produits Allegro. Le travail lié à cette composante constituait de la recherche appliquée [2] .

[Non souligné dans l’original.]

[141] L’opinion de M. Penn est un exemple de l’importance de connaître l’environnement technologique auquel l’appelante devait faire face lorsqu’elle menait des expériences dans le but d’améliorer ses produits.

B. Partie AT1/OT1 du projet n^o 2 de 2010

[142] Tel qu’il a été discuté précédemment, l’ARC a divisé le projet n^o 2 de 2010 en trois composants. M. Rupel a expliqué à la Cour plusieurs termes et concepts généraux qui s’appliquent à l’ensemble du projet n^o 2 de 2010.

[143] L’objectif technologique du projet n^o 2 de 2010 était de :

[traduction]

[...] développer des méthodes et des techniques pour améliorer l’évolutivité et le débit des services TCP (protocole de contrôle de transmission) transmis par l’intermédiaire du protocole IP (protocole Internet) sur les réseaux cellulaires. Plus précisément, l’objectif était de développer des méthodes pour permettre une diffusion plus efficace de l’audio numérique, des mécanismes de gestion de la connexion pour convertir le protocole UDP en protocole TCP et réduire la surcharge liée aux délais d’attente TCP [3] .

[144] M. Rupel a expliqué à la Cour ce que signifiaient les termes UDP et TCP. Il a également expliqué ce que l’on entend par équilibreur de charge, commande de session et mise en cache.

[145] Il a noté que le protocole TCP est un protocole de communication Internet. Le protocole TCP est développé au-dessus du protocole Internet et constitue un moyen fiable pour permettre à la grande majorité des éléments sur Internet de communiquer.

[146] Le protocole UDP est un autre protocole qui est également développé au-dessus du protocole Internet, comme le protocole TCP. Le protocole UDP est un protocole très léger comparativement au protocole TCP, mais ce dernier accomplit des choses que le protocole UDP ne fait pas.

[147] M. Rupel a expliqué que lorsqu’une grande quantité de données est envoyée sur Internet, elle est divisée en morceaux (paquets) et chaque paquet est envoyé séparément par le protocole Internet.

[148] Il a noté que les avantages liés au protocole TCP incluent le fait qu’il garantit que le paquet d’information envoyé sur Internet arrive effectivement à sa destination. Si le paquet n’arrive pas à destination, le protocole TCP envoie un avis à l’expéditeur de l’information indiquant quel paquet n’est pas arrivé. Ce protocole possède également une fonction qui garantit que les paquets de données, une fois reçus, sont placés dans le bon ordre.

[149] Le protocole UDP ne possède pas ces caractéristiques, mais comme il n’a pas autant de « surcharge », il peut être plus rapide que le protocole TCP. L’appelante a créé un protocole UDP qui a permis à ses clients de réduire leur utilisation de données sur les réseaux cellulaires sans fil, ce qui a réduit considérablement leurs coûts. M. Rupel a souligné qu’à l’époque, le coût d’une bande passante sur les réseaux cellulaires était très élevé.

[150] Lorsque l’appelante a créé le protocole UDP, celui-ci a très bien fonctionné, mais à un moment donné, des problèmes se sont manifestés. Elle a conclu que les problèmes étaient causés par l’interaction entre son protocole UDP et les nouveaux pare-feu qui étaient installés par ses clients.

[151] Un autre problème concernait les équilibreurs de charge. Les clients qui disposaient d’un trafic important sur leurs réseaux et de plusieurs serveurs utilisaient ces équilibreurs de charge. L’objectif des équilibreurs de charge était d’équilibrer l’utilisation de chacun des serveurs.

[152] L’appelante a rencontré des problèmes avec l’interaction des équilibreurs de charge et de la commande de session. La commande de session consiste à gérer les sessions entre un serveur et un utilisateur particulier (appelé client). Au lieu que le client ait à envoyer tous les mêmes renseignements de façon répétée au serveur, ce dernier stocke certains de ces renseignements jusqu’à la fin de la session. C’est ce qu’on appelle la mise en cache. Un problème s’est produit lorsque des équilibreurs de charge ont fait en sorte que des parties de l’information transférée soient stockées sur différents serveurs.

[153] En raison de ces problèmes, l’appelante a dû renoncer à son protocole UDP. Elle a ensuite travaillé à l’élaboration d’un protocole TCP qui fonctionnerait mieux que son protocole UDP tout en réduisant l’utilisation de données par le client.

[154] M. Rupel a parlé de la partie du projet n^o 2 de 2010 désignée par l’ARC comme étant la partie AT1/OT1.

[155] Le formulaire de l’ARC produit par l’appelante décrit l’avancée technologique que l’appelante essayait de réaliser en ce qui concerne la partie AT1/OT1 du projet n^o 2 de 2010 comme suit : « la mise en œuvre d’un regroupement de tableaux d’octets réutilisables dans lequel l’audio numérique était compressé en vue d’une transmission, éliminant complètement la rupture du son causé par les sous-exécutions de la mémoire tampon (les sous-exécutions étaient à leur tour causées par le débit insuffisant des paquets) » [4] .

[156] En passant d’un protocole UDP à un protocole TCP, l’appelante s’est heurtée à un problème avec les fichiers audio. Ces fichiers n’étaient pas envoyés assez rapidement et seule une partie du fichier audio pouvait être lue lors du premier accès par le destinataire des fichiers audio.

[157] L’appelante a commencé à expérimenter différentes façons de compresser les fichiers audio. Au début, les méthodes qu’elle a mises à l’essai n’ont pas été couronnées de succès.

[158] Elle a alors commencé à expérimenter ce que l’on appelle des attributs non sécurisés. M. Rupel a expliqué que le langage logiciel utilisé par l’appelante avait un environnement géré. Fondamentalement, elle s’assurait que les différents codes sources utilisés fonctionnaient correctement. Cependant, le code utilisé à cette fin ralentissait le processus.

[159] L’appelante a essayé de développer des attributs dits non sécurisés en ajoutant un code qui n’allait pas être géré. M. Rupel a décrit de la façon suivante l’effet des attributs non sécurisés :

[traduction]

[...] Vous n’avez plus de filet de sécurité en dessous de vous, vous marchez sur la corde raide en espérant que vous n’aurez pas de bogues à ce moment-là parce que si vous en avez, cela ne va pas les attraper, cela ne va pas vous empêcher de vous faire mal. [5]

[160] Il a toutefois noté qu’il en résultait une diminution des frais généraux, ce qui signifiait que l’appelante pouvait espérer faire passer les données assez rapidement pour résoudre le problème.

[161] L’utilisation d’attributs non sécurisés n’a pas marché. La solution définitive consistait à retourner dans le monde dit géré et à utiliser une solution hybride dans laquelle l’appelante [TRADUCTION] « faisait des choses qui [étaient] un peu dangereuses, mais qui ne sont pas moins sûres » [6] .

[162] M. Rupel a donné une description technique détaillée de la solution. Cette solution consistait à réutiliser certains des objets qui avaient été transférés. Il a décrit le processus en termes simples comme suit :

[traduction]

[...] C’est un peu comme si vous aviez un seau que vous – vous preniez un seau et le remplissiez d’eau et vous l’envoyiez là où vous en aviez besoin et vous vidiez tout le seau et preniez un autre seau et le remplissiez d’eau et – maintenant au lieu de cela, nous prenons – nous jetons juste l’eau et rapportons le seau et le remplissons à nouveau. Donc, nous réutilisons le même seau [7] .

Cela a permis d’économiser suffisamment de frais généraux pour que l’appelante puisse résoudre le problème des fichiers audio. La solution a fonctionné pour n’importe quel fichier audio envoyé et sur les quelque 500 appareils différents qu’elle a rencontrés.

[163] M. Rupel a déclaré ce qui suit au sujet des travaux effectués concernant les attributs non sécuritaires et la solution consistant à réutiliser certains objets :

[traduction]

Il me faut encore découvrir si cela marche. C’est juste une idée, une hypothèse. Rien ne garantit que ça va marcher. Il faut expérimenter et trouver et il y a beaucoup de détails dans le code. Lorsque nous sommes assis ici et que nous en parlons, cela semble simple, mais lorsque vous creusez réellement dans le code, il y a toutes sortes de complexités que vous rencontrez et avec lesquelles vous devez vous battre pour être en mesure d’atteindre l’objectif en premier lieu. Donc, pouvons-nous vraiment faire cette chose hybride, est-ce possible, et une fois que nous y arriverons, est-ce que ce sera adéquat [8] ?

Opinion de M. Penn

[164] M. Penn a noté qu’en 2010 et 2011, le protocole UDP était assorti de restrictions quant au nombre d’appareils simultanés pouvant être connectés à un réseau mobile. Il a compris que l’appelante expérimentait le protocole TCP parce qu’il permettait de connecter un plus grand nombre de dispositifs. Cependant, l’appelante était aux prises avec le problème de lenteur des vitesses de transmission. Il a conclu que le travail de l’appelante sur ce projet constituait un développement expérimental étant donné la nature expérimentale de l’approche que l’appelante devait adopter avec les différents appareils pour déterminer ce que l’écologie alors disponible pouvait prendre en charge.

[165] Dans son rapport d’expert, il a déclaré ce qui suit :

[traduction]

[...] La programmation en ce qui concerne le son est une expertise très pointue qui fait défaut à la plupart des ingénieurs en logiciels. Ce constat, combiné à la demande croissante de téléphones intelligents au cours des sept dernières années, a résulté en une banalisation du matériel de traitement audio et des API (interfaces de programmation d’applications) de traitement audio au sein du secteur des appareils mobiles, qui s’est grandement consolidé entre-temps. En 2010, cependant, il y avait encore une variation considérable entre les appareils mobiles portatifs dans la gamme des formats audio pris en charge, des codecs audio, des taux de transfert audio disponibles et des fonctionnalités prises en charge relativement au son dans les API offertes par les fournisseurs. Bien que la solution finale d’Allegro à cet OT diffère sensiblement de sa solution à l’OT1 du projet n^o 1 de l’exercice 2010, les composants OT1 de ces deux projets partagent la propriété que l’enquête qu’ils ont entreprise était nécessairement systématique [...] et vaste (bien que, avec une probabilité raisonnable, incomplète à la fin de l’exercice 2010), ayant pris en compte les particularités des nombreux appareils mobiles en circulation à cette époque. Dans le présent composant, ces paramètres audio constituaient des incertitudes technologiques sous-jacentes dans une écologie d’appareils étrangers à l’égard desquels les développeurs de la plateforme d’Allegro auraient dû adapter leur produit. [...] Allegro a développé une base de connaissances dans la partie AT1/OT1 du projet n^o 2 de l’exercice 2010, caractérisant ainsi la distribution des paramètres pertinents pour la transmission audio numérique en 2010, qui aurait été utile aux membres de la communauté plus large des développeurs de logiciels mobiles qui n’ont jamais eu l’intention d’acheter les produits d’Allegro. Il s’agissait là aussi de recherche appliquée et non d’une application habituelle de techniques standard. [...] [9]

C. Partie AT3/OT3 du projet n^o 2 de 2010

[166] Le formulaire de l’ARC produit par l’appelante décrivait de la façon suivante l’avancée technologique qu’elle tentait de réaliser en ce qui concerne la partie AT3/OT3 du projet n^o 2 de 2010 : [traduction] « Développement d’un enveloppeur d’événement synchrone capable d’arrêter un processus rapidement, éliminant ainsi une attente moyenne de cinq à huit minutes pour un délai d’attente TCP à partir d’un appareil mobile » [10] .

[167] M. Rupel a expliqué ce qu’était un événement synchrone en faisant la distinction entre un événement synchrone et un événement asynchrone. Un événement synchrone se produit lorsque, au cours d’une communication, le système envoie une demande d’information et attend ensuite la réponse. Un événement asynchrone se produit lorsque le système envoie une demande d’information et fait ensuite autre chose pendant qu’une autre partie du système attend la réponse.

[168] M. Rupel a noté qu’avec un événement synchrone, c’est l’ensemble du système qui attend la réponse, alors qu’avec un événement asynchrone, le système n’attend pas la réponse. La méthode synchrone est utilisée lorsque le système ne peut pas progresser dans la logique du programme avant d’avoir reçu une réponse.

[169] Le problème avec lequel l’appelante était aux prises était que Microsoft avait intégré un délai d’attente de cinq à huit minutes dans son logiciel qui contrôlait les caractéristiques de bas niveau des appareils portatifs. L’appelante n’avait aucun contrôle sur ce délai. Des problèmes se manifestaient dans la communication TCP lorsqu’une demande d’information était envoyée et qu’aucune information ne revenait. Le logiciel Microsoft prenait alors au moins de cinq à huit minutes pour se réinitialiser. C’était un problème pour l’appelante, qui essayait de fabriquer des appareils qui fonctionnaient en temps réel, c’est-à-dire qui étaient toujours connectés au réseau.

[170] M. Rupel a décrit le problème comme étant un problème de logiciel qui s’est produit parce que Microsoft a développé le logiciel en utilisant les protocoles applicables à un réseau câblé et que les appareils étaient maintenant utilisés sur un réseau sans fil. Il a noté que les concepteurs du logiciel n’ont jamais envisagé une situation où l’appareil serait connecté, mais ne pourrait pas envoyer de données, mais il s’agit là d’une situation courante pour un appareil sur un réseau sans fil. Un exemple de ce type de situation est lorsqu’un appareil se trouve dans un stationnement où la réception est mauvaise.

[171] Bien qu’il s’agisse d’une caractéristique liée de la conception du logiciel de Microsoft, l’appelante a dû régler le problème sans avoir accès au code utilisé par Microsoft, tout en étant confronté à un système très complexe.

[172] M. Rupel a décrit trois méthodes que l’appelante a mises à l’essai pour tenter de résoudre le problème.

[173] La première méthode consistait à utiliser un pare-feu et à effectuer une inspection approfondie des paquets pour mettre fin aux longues connexions en attente d’une réponse. L’appelante essayait de faire face à la situation où le logiciel lui disait qu’il était connecté, mais il y avait en fait un problème et l’appareil ne communiquait pas.

[174] Il a expliqué que l’inspection approfondie des paquets signifiait que l’appelante [traduction] « jetait un petit coup d’œil » sur des endroits où elle n’aurait normalement pas dû aller, à savoir les tampons du réseau où l’information entrait par le réseau TCP.

[175] Puisque les pare-feu surveillaient le trafic du système et savaient exactement ce qui passait par le réseau, le pare-feu pouvait être utilisé pour trouver de l’information sur ce qui passait par le réseau.

[176] Les essais réalisés dans le cadre de l’inspection approfondie des paquets et des pare-feu n’ont pas permis de trouver une solution à son problème.

[177] La deuxième méthode qu’elle a mise à l’essai consistait à expérimenter un processus de rebouclage qui consistait à envoyer un paquet à travers les couches du réseau avec des instructions indiquant que l’endroit où il devait aller était le point d’origine.

[178] Elle espérait éviter le problème du délai d’attente de cinq à huit minutes en interrompant la session réseau, ce qui, en théorie, aurait pour effet de tout réinitialiser immédiatement. Le problème qu’elle a subi est qu’elle n’a pu supprimer qu’un côté de la session (par exemple, le côté périphérique), mais n’a pas pu supprimer l’autre côté (le côté serveur). Le système se trouvait donc dans ce que M. Rupel appelle un état incohérent, ce qui posait un problème.

[179] Le problème a été résolu en développant un mécanisme à deux volets pour éliminer le problème. M. Rupel a décrit le processus de la façon suivante :

[traduction]

[...] en créant un autre processus, nous avons créé une situation parallèle dans laquelle nous pouvions démarrer une nouvelle session pour – la session originale, où tout se passe encore, où toutes les choses importantes se passent encore, mais nous créons cet autre processus qui crée alors une nouvelle session avec le serveur, et nous devons alors essentiellement suivre ce qui se passe là-bas, mais nous pouvons utiliser ce canal pour communiquer jusqu’à ce que le délai de cinq à huit minutes expire.

Nous avons donc une sorte de canal de communication temporaire que nous mettons en place pendant la période où l’intervalle de cinq à huit minutes nous bloque [11] .

[180] M. Rupel a noté que l’appelante a enregistré tout son travail dans le système de contrôle du code source. L’appelante a développé un logiciel pour chacune des méthodes qu’elle a mises à l’essai afin de tester chacune des méthodes proposées.

Opinion de M. Penn

[181] M. Penn ne pense pas que la partie AT3/OT3 du projet n^o 2 de 2010 constituait en soi de la recherche ou du développement expérimental. Cependant, il croit que la partie AT3/OT3 a soutenu les autres parties du projet n^o 2 de 2010, qui, selon lui, constituaient du développement expérimental ou de la recherche. En substance, la partie du projet n^o 2 de 2010 que l’ARC a désignée comme étant la partie AT3/OT3 a soutenu les autres parties du projet n^o 2 de 2010 de telle sorte qu’elle a contribué aux objectifs généraux d’un projet de développement expérimental. Il s’est demandé s’il était logique pour l’ARC (ou pour quiconque) de diviser le projet n^o 2 de 2010 de l’appelante en trois composants.

[182] Il a déclaré ce qui suit dans son rapport d’expert :

[traduction]

[...] La description de ce projet [projet n^o 2 de 2010] propose une avancée technologique primordiale : un protocole d’application TCP qui surpasse le protocole UDP en débit et en évolutivité. La possibilité d’y parvenir ou non était une incertitude technologique. Pour réaliser cette avancée, certaines caractéristiques du protocole TCP en matière de conception sont incompatibles avec son utilisation dans ce protocole d’application. L’une d’entre elles, l’OT3, est le long délai d’attente qui est généralement intégré dans les piles TCP. Le défaut de la terminologie du sous-projet, la partie « AT3/OT3 », est qu’elle implique une portée de travail si limitée qu’elle empêche la désignation d’une AT ou d’un OT pour ce seul composant. Ce composant partage les avancées technologiques et les incertitudes du projet auquel elle contribue [...]

[...] Compte tenu des documents et des entretiens dont je dispose, je ne suis pas en mesure d’établir raisonnablement qu’une enquête systématique a été menée dans le cadre des travaux liés à ce composant. En revanche, je suis raisonnablement certain que le projet n^o 2 dans son ensemble a consisté en des travaux de recherche et de développement expérimental, parallèlement à certains travaux courants inévitables qui ont eu lieu à l’appui du programme de recherche global du projet. Je pense également qu’il est raisonnablement probable que les travaux décrits dans la partie AT3/OT3 et le contenu technique associé étaient en eux-mêmes suffisamment nouveaux pour servir de base à une extension normalisée du protocole TCP pour les communications à faible latence sur des réseaux non fiables. Ce qui n’est pas clair pour moi, c’est si la réalisation du potentiel de recherche quant à la partie AT3/OT3 a effectivement eu lieu [12] .

D. Partie AT/OT1 du projet n^o 1 de 2011

[183] L’appelante a décrit comme suit les avancées technologiques qu’elle tentait de réaliser pour l’ensemble du projet n^o 3 :

[traduction]

L’objectif technologique de ce projet était de développer une plateforme d’intégration pour les appareils mobiles qui donnent lieu à des points d’extrémité multiples dynamiques. Plus précisément, l’objectif était de développer des méthodes pour permettre aux paquets de données mobiles d’être acheminés intelligemment vers différentes applications sans qu’il soit nécessaire de mettre en place des points d’extrémité ou des agents de messagerie particuliers pour chaque point d’intégration [13] .

[184] En ce qui concerne la partie AT/OT1 du projet n^o 3, l’appelante espérait réaliser une avancée technologique en développant un mécanisme de délai de connexion pour les opérations distribuées amorcées par un dispositif mobile.

[185] L’obstacle technologique auquel l’appelante se heurtait découlait des délais d’attente des opérations mobiles. L’appelante a noté que le but principal de son système était de fournir des données à des dispositifs clients tels que des dispositifs mobiles. Cela exigeait que les données soient envoyées sur des réseaux cellulaires à forte latence. En raison de la latence des réseaux cellulaires, il n’est pas facile de déterminer si une connexion a expiré.

[186] M. Rupel a fait remarquer que les gens confondent la bande passante et la latence. La latence est un autre aspect de la vitesse ou de la synchronisation. Il note que l’information peut traverser un système à grande vitesse (bande passante élevée) tout en étant retardée quant à son arrivée à destination (latence élevée).

[187] Il a expliqué que les réseaux cellulaires présentent une latence élevée par rapport aux réseaux par fil. Dans un réseau cellulaire, [TRADUCTION] « il y a beaucoup plus de manipulations à faire pour décoder ce que contiennent les ondes radio et les couches de technologie à traverser pour arriver à destination. [...] ce délai initial est pire sur un réseau sans fil, en particulier sur un réseau cellulaire » [14] .

[188] Le délai d’attente était le même que dans le projet n^o 2 de 2010, mais le délai d’attente dans le projet n^o 1 de 2011 a causé un problème d’un autre ordre. M. Rupel a expliqué que le système de l’appelante regroupait des messages de logique commerciale et les envoyait dans le système. Comme nous l’avons vu précédemment, les messages sont divisés en morceaux et envoyés par petits paquets, qui sont reconstruits de l’autre côté. Le processus est doté de ce qu’on appelle un mécanisme de mise en file d’attente. Le logiciel de l’appelante gère ce qui se trouve dans la file d’attente pour faire passer l’information par la boîte noire sous-jacente, puis la reconstruire de l’autre côté. Les délais d’attente posaient des problèmes de fidélité au processus de mise en file d’attente de l’appelante.

[189] Par exemple, le délai d’attente peut entraîner la réinitialisation du système. Une fois qu’il se réinitialise, tous les renseignements se trouvant dans la file d’attente sont envoyés au système à un rythme si rapide qu’ils submergent l’appareil.

[190] Par conséquent, l’appelante a dû effectuer des essais sur les délais d’application afin de déterminer le moment optimal. M. Rupel a fait remarquer qu’il y a beaucoup de compromis à faire en ce qui concerne le délai, car si celui-ci est trop court, une série de problèmes se manifeste, et s’il est trop long, une autre série de problèmes survient. Il essayait de trouver le « point idéal », ce qui était compliqué vu qu’il travaillait avec des boîtes noires et qu’il n’avait aucun moyen de savoir si les problèmes individuels survenant à un extrême ou à l’autre allaient devenir inacceptables d’un point de vue commercial.

Opinion de M. Penn

[191] M. Penn a expliqué que, pour que l’appelante puisse empêcher les connexions de tomber en panne, elle devait tenir compte des capacités limitées des unités centrales et des capacités de mise en réseau de chacun des appareils concernés. Il est d’avis qu’il s’agissait d’un problème expérimental qui n’aurait pas pu être résolu par une norme en 2011. Il considérait la recherche effectuée par l’appelante comme relevant du développement expérimental puisque l’appelante a dû expérimenter avec de multiples dispositifs dans de multiples conditions de réseau afin de déterminer si les connexions pouvaient prendre en charge diverses solutions afin de maintenir la reconnexion. Il a émis l’opinion suivante dans son rapport écrit :

[traduction]

[...] le développement d’un mécanisme qui attend une période de temps précisée avant de réinitialiser une connexion réseau est une pratique courante, et l’expérimentation requise pour fixer le temps d’attente ne comporte souvent qu’un faible degré d’expérimentation. [...] cependant, savoir combien de temps il faut attendre lorsqu’on développe un produit dans une écologie de dispositifs étrangers et sur de multiples réseaux cellulaires n’est pas courant. [...] Allegro développait justement cette base de connaissances [connaissances liées aux temps d’attente nécessaires] qui aurait été utile aux membres de la communauté plus large des développeurs de logiciels mobiles, y compris ceux qui n’avaient jamais eu l’intention d’acheter les produits d’Allegro. Il s’agissait là du résultat d’une recherche appliquée [15] .

[192] M. Penn a également examiné la partie AT3/OT3 du projet n^o 1 de 2011. Il a conclu que le travail effectué par l’appelante n’était pas du développement expérimental. L’avocat de l’appelante a informé la Cour que telle était la raison pour laquelle sa cliente a concédé ce point au début du procès.

E. Conclusion de la Cour

[193] En ce qui concerne les projets AT1/OT1 du projet n^o 1 de 2010, AT1/OT1 du projet n^o 2 de 2010 et AT1/OT1 du projet n^o 1 de 2011, j’abonde dans le sens de l’appelante et de M. Penn : le travail effectué par l’appelant constituait du développement expérimental.

[194] Le produit principal de l’appelante était sa plateforme (logiciel), qu’elle a développée pour tenir compte de l’environnement difficile dans lequel elle exerçait ses activités. L’appelante tentait de développer un nouveau produit (sa plateforme) qui fonctionnerait de façon transparente avec une multitude d’appareils utilisant différents logiciels d’exploitation et tournant sur les divers systèmes d’exploitation de ses clients. Il s’agissait d’un produit qui n’avait jamais existé auparavant.

[195] Le succès de l’appelante dépendait de sa capacité à satisfaire les besoins de ses clients dans un environnement caractérisé par la présence de nombreux appareils sans fil avec de nombreux systèmes logiciels sous-jacents auxquels l’appelante ne pouvait pas accéder, les fameuses boîtes noires. L’appelante devait également concevoir une plateforme qui interagirait avec les nombreux serveurs de ses clients. Son produit devait fonctionner indépendamment du fabricant de l’appareil portatif utilisé par le client ou du logiciel d’exploitation utilisé par l’appareil portatif.

[196] Cet environnement était encore compliqué par l’état de la technologie sans fil et des logiciels sous-jacents au moment où l’appelante effectuait l’expérimentation. M. Rupel et M. Penn ont tous deux noté que bon nombre des problèmes auxquels l’appelante s’était heurtée n’existeraient pas aujourd’hui en raison des progrès technologiques réalisés au cours des dix dernières années. Cependant, ils existaient à l’époque où l’appelante a réalisé les projets.

[197] Travaillant dans cet environnement, l’appelante avait besoin d’un produit qui fonctionnait mieux que les produits offerts par ses concurrents. Cela exigeait de l’appelante qu’elle travaille constamment à améliorer son produit. Elle l’a fait en développant constamment des logiciels pour améliorer le fonctionnement des divers appareils portatifs que ses clients utilisaient sur la plateforme de l’appelante.

[198] Comme l’ont expliqué M. Rupel et M. Penn, lors du développement de ce logiciel, l’appelante a dû surmonter de nombreux défis technologiques qui l’ont obligée à expérimenter pour trouver des solutions.

[199] 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. Elle devait expérimenter, [traduction] « formuler des hypothèses sur les choses qu’elle pouvait mettre à l’essai ou faire et voir ce qui fonctionnait par expérimentation » [16] .

[200] M. Penn a conclu que ces expériences, dans la mesure où elles étaient liées aux trois projets, constituaient une recherche scientifique et résultaient en une avancée technologique. M. Penn était éminemment qualifié pour tirer ces conclusions en raison de sa formation, de son expérience et de sa connaissance de l’entreprise de l’appelante. Ses conclusions sont conformes aux éléments de preuve dont je dispose.

[201] Compte tenu des éléments de preuve qui m’ont été présentés, en particulier la description par M. Rupel de la recherche effectuée par l’appelante et l’opinion d’expert de M. Penn, j’ai conclu que le travail entrepris par l’appelante en ce qui concerne les projets AT1/OT1 du projet n^o 1 de 2010, AT1/OT1 du projet n^o 2 de 2010 et AT1/OT1 du projet n^o 1 de 2011 était lié au développement ou à l’amélioration de son produit et impliquait de tenter de résoudre un risque ou une incertitude technologique qui ne pouvait être résolu par les études techniques courantes ou la procédure standard.

[202] Les trois projets ont exigé de l’appelante qu’elle effectue des essais et des expériences, dans un environnement difficile, pour trouver de nouvelles solutions qui permettraient à tous les composants logiciels de s’exécuter de la manière dont l’appelante l’exigeait afin de développer et d’améliorer un produit qui répondrait aux besoins de ses clients. Ces solutions ne pouvaient pas être trouvées par des études techniques courantes. Il s’agissait d’un travail que l’appelante a entrepris dans le but de réaliser des avancées technologiques qui lui permettraient de créer un nouveau ou un meilleur produit. Ce produit était une plateforme qui fonctionnerait avec de multiples appareils dans l’environnement décrit par M. Rupel.

[203] En ce qui concerne le projet AT3/OT3 du projet n^o 2 de 2010, tel qu’il a été discuté précédemment, M. Penn a conclu que si l’on considère le travail lié à ce que l’ARC a décrit comme un projet AT3/OT3 en soi, le travail ne constitue pas du développement expérimental ou de la recherche. Cependant, il a recherché s’il était logique de diviser le projet n^o 2 de 2010 en trois parties. M. Penn croyait que la partie AT3/OT3 soutenait les autres parties du projet n^o 2 de 2010, qui, selon lui, constituaient du développement expérimental ou de la recherche. J’ai conclu que la partie AT1/OT1 du projet n^o 2 de 2010 relevait du développement expérimental et le ministre a accepté que la partie AT2/OT2 du projet n^o 2 de 2010 constituât une activité de RS&DE.

[204] Je retiens la conclusion de M. Penn selon laquelle la partie du projet n^o 2 de 2010 que l’ARC a désignée comme étant la partie AT3/OT3 a soutenu les autres parties du projet n^o 2 de 2010 de telle sorte qu’elle a contribué aux objectifs généraux d’un projet de développement expérimental. Autrement dit, je conclus que le travail de l’appelante sur cette partie du projet n^o 2 de 2010 fût expérimental.

[205] Ma conclusion concernant les quatre projets est conforme au fait que l’ARC a conclu que les quatre projets étaient identiques ou semblables à des projets pour lesquels l’appelante a reçu des subventions du Conseil national de recherches du Canada (le « CNRC ») dans le cadre de son Programme d’aide à la recherche industrielle (le « PARI »). Les subventions que l’appelante a reçues visaient à effectuer des recherches qui mèneraient à de meilleurs produits.

[206] L’appelante avait de nombreux systèmes en place pour enregistrer les diverses hypothèses qu’elle formulait lors de ses recherches. Plus précisément, elle enregistrait ses recherches dans son système de contrôle du code source et son logiciel de suivi des défauts Jira X. Pour un projet expérimental particulier, y compris les projets en cause, ces systèmes enregistraient l’hypothèse émise par l’appelante au début du projet, la mise à l’essai de l’hypothèse et tout changement apporté à l’hypothèse au fur et à mesure de l’avancement des travaux. Il s’agissait d’un système que l’appelante a développé avec l’aide de M. Wong, son conseiller technique de l’ARC.

[207] Ce n’est qu’après avoir examiné le système de contrôle du code source et le système de suivi du logiciel Jira X pour déterminer le travail effectué que l’appelante a pris la décision de déclarer le projet dans sa déclaration de revenus à titre de RS&DE.

[208] Compte tenu des éléments de preuve qui viennent d’être discutés, j’ai conclu que lorsque l’appelante a mené les projets en question, elle a formulé des hypothèses visant précisément à réduire l’incertitude technologique cernée, a suivi les procédures appropriées à l’égard des essais, y compris la formulation, la mise à l’essai et la modification des hypothèses, et a tenu un registre détaillé des hypothèses mises à l’essai et des résultats obtenus au fur et à mesure de l’avancement des travaux.

[209] Pour ces motifs, les travaux effectués par l’appelante sur les projets désignés par l’ARC comme étant les parties AT1/OT1 du projet n^o 1 de 2010, AT1/OT1 du projet n^o 2 de 2010, AT3/OT3 du projet n^o 1 de 2010 et AT1/OT1 du projet n^o 1 de 2011 constituent de la RS&DE aux fins de la Loi de l’impôt sur le revenu.

V. Montant des dépenses de RS&DE engagées et des CII correspondants

[210] Comme j’ai conclu que les travaux de l’appelante à l’égard des quatre projets discutés ci-dessus constituent des activités de RS&DE, je dois maintenant déterminer le montant total des dépenses de RS&DE engagées par l’appelante au cours de la période pertinente et le montant des CII correspondants qu’elle peut déclarer.

[211] Pour chacune des années en cause, l’appelante a choisi, aux termes de la division 37(8)a)(ii)(B) et du paragraphe 37(10), d’utiliser la méthode de remplacement pour calculer ses dépenses de RS&DE et les CII correspondants. Conformément au paragraphe 2900(4) du Règlement de l’impôt sur le revenu, l’appelante et l’intimée ont calculé le montant de remplacement comme étant 65 % [17] des traitements et salaires admissibles des employés de l’appelante qui ont exercé directement des activités de RS&DE au Canada. De toute évidence, l’appelante et l’intimée ne se sont pas entendues sur les activités de l’appelante qui constituaient des activités de RS&DE.

[212] Au début de l’audience en mai 2019, j’ai demandé à chaque partie de communiquer à la Cour le montant des dépenses de RS&DE engagées par l’appelante pour chacun des quatre projets en cause et le montant des crédits de taxe sur les intrants correspondants pour chaque projet.

[213] Malgré l’assurance donnée par les avocats des parties que les calculs seraient communiqués à la Cour, elles ne l’ont pas fait 2019. Lorsque l’audience a repris en septembre 2020, j’ai réitéré que la Cour exigeait ces renseignements. Les parties ne les ont jamais communiqués à la Cour.

[214] J’ai entendu M^me Sporich de l’ARC le deuxième jour des audiences de septembre. Elle a donné à la Cour une ventilation détaillée de la façon dont l’ARC a calculé le montant des dépenses de RS&DE autorisées et les CII correspondants. Elle n’a pas donné à la Cour de renseignements similaires pour les quatre projets en cause.

[215] Toutefois, après que j’eus souligné une fois de plus que la Cour exigeait de tels renseignements, elle s’est engagée à fournir à la Cour des renseignements quant à la façon dont l’ARC aurait calculé les dépenses de RS&DE si le ministre avait accepté la demande de l’appelante telle qu’elle a été déposée. Ces renseignements (pièces R-8 à R-13) ont été produits le dernier jour de l’audience.

[216] L’appelante ne s’est pas opposée à l’un ou l’autre des calculs de l’ARC, à l’exception, comme je l’expliquerai sous peu, du calcul par l’ARC de l’aide gouvernementale accordée dans le cadre du PARI.

[217] La pièce R-13 contient, pour l’année d’imposition 2010 et l’année d’imposition 2011, la somme que l’appelante a déclaré à titre de dépenses de RS&DE et les CII correspondants, ainsi que les sommes auxquelles le ministre a fait droit. Le calcul pour l’année d’imposition 2010 est le suivant :

[218] Le calcul pour l’année d’imposition 2011 est le suivant :

[219] L’appelante n’a pas fourni les détails de son calcul des montants déclarés dans ses déclarations de revenus. Le calcul par l’ARC des montants ayant fait l’objet de la cotisation par le ministre concernant le total des dépenses de RS&DE, le montant de remplacement visé par règlement et l’aide gouvernementale figure dans les pièces R-3 à R-7 et R-13. M^me Sporich a expliqué ces calculs à la Cour.

[220] Étant donné que l’appel a été accueilli en ce qui concerne les quatre projets en cause, la Cour doit déterminer de nouveaux montants pour les dépenses totales de RS&DE, le montant de remplacement visé par règlement et l’aide gouvernementale. Étant donné qu’aucune des parties n’a produit de calculs de ces montants pour les quatre projets en cause, la Cour a calculé ces montants à l’aide des éléments de preuve dont elle disposait. Chaque partie aurait dû effectuer ces calculs et les communiquer ensuite à la Cour.

Dépenses de RS&DE

[221] Je me pencherai tout d’abord sur le total des dépenses de RS&DE pour l’année d’imposition 2010.

[222] Dans sa déclaration de revenus, l’appelante a déclaré 587 005 $ de dépenses de RS&DE admissibles, soit 562 005 $ de traitements et salaires et 25 000 $ à titre de paiement à un entrepreneur [19] . Lorsqu’il a établi la cotisation à l’égard de l’appelante, le ministre a supposé que les travaux effectués par le sous-traitant ne constituaient pas des activités de RS&DE. L’appelante n’a pas fait soutenu que l’hypothèse du ministre était erronée et n’a pas produit à la Cour de preuve à l’appui d’un paiement de 25 000 $ versé à un entrepreneur.

[223] Le ministre a accordé à l’appelante des dépenses de RS&DE de 171 979 $, entièrement constituées de traitements et salaires. En utilisant les chiffres produits par l’intimée dans la pièce R-9, j’ai ajouté à la somme de 171 979 $ les dépenses au titre des traitements et salaires engagées par l’appelante en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2010, la partie AT1/OT1 du projet n^o 2 de 2010 et la partie AT3/OT3 du projet n^o 2 de 2010. Cela donne un total de dépenses de RS&DE admissibles de 425 911 $ pour l’année d’imposition 2010.

[224] J’ai effectué un calcul similaire pour l’année d’imposition 2011. En utilisant les chiffres fournis par l’intimée dans la pièce R-12, j’ai augmenté la somme de 120 635 $ au titre des traitements et salaires autorisés par le ministre en y ajoutant les dépenses au titre des traitements et salaires engagées par l’appelante en ce qui concerne la partie AT1/OT1 du projet n^o 1 de 2011. Cela donne un total de dépenses de RS&DE admissibles de 355 891 $ pour l’année d’imposition 2011.

Montant de remplacement visé par règlement

[225] Le montant de remplacement visé par règlement est de 65 % des dépenses de RS&DE. Pour l’année d’imposition 2010, ce montant est de 65 % de 425 911 $, soit 276 842 $. Pour l’année d’imposition 2011, le montant de remplacement visé par règlement est de 65 % de 355 891 $, soit 231 329 $.

Aide gouvernementale

[226] Lors du calcul des dépenses de RS&DE, tant l’appelante que le ministre ont tenu compte de deux formes d’aide gouvernementale reçue par l’appelante.

[227] Le CNRC, conformément à son PARI, a fourni la première aide gouvernementale (la « subvention du PARI »). Conformément à un accord de contribution entre le CNRC et l’appelante (pièce A-1), le CNRC a accepté de contribuer à hauteur de 500 000 $ pour les coûts salariaux engagés dans l’exécution de certains travaux décrits dans l’accord [20] . Aux termes de l’ECFP, l’appelante a reçu 470 378 $ de la subvention du PARI. Lorsqu’il a calculé les dépenses de RS&DE de l’appelante et les CII connexes, le ministre a tenu pour acquis que tous les projets pour lesquels l’appelante a déclaré des travaux de RS&DE étaient identiques ou semblables à certains des projets visés par la subvention du PARI.

[228] Lorsqu’elle a calculé ses dépenses de RS&DE et ses CII admissibles, l’appelante a déduit 65 261 $ pour l’année d’imposition 2010 et 6 829 $ pour l’année d’imposition 2011 concernant la subvention du PARI. Par conséquent, l’appelante a tenu pour acquis qu’elle avait reçu au moins une partie de la subvention du PARI concernant les projets de RS&DE dont est saisie la Cour. Je n’ai entendu aucune déclaration de la part de l’appelante quant à la façon dont elle a calculé les sommes de 65 261 $ et de 6 829 $. En fait, l’appelante n’a rien dit quant à la rémunération de ses employés qui était couverte par la subvention du PARI et quant aux travaux effectués par ces employés dans le cadre des projets de RS&DE.

[229] L’intimée, à l’aide des renseignements que l’appelante a fournis à l’ARC, a remis à la Cour une annexe (pièce R-7) indiquant les employés précis de l’appelante qui ont participé aux cinq projets de recherche, le nombre d’heures que chaque employé a consacrées à ces projets et les heures de chaque employé qui ont été remboursées dans le cadre de la subvention du PARI.

[230] Pour l’année d’imposition 2010, l’annexe indique que 23 employés ont travaillé un total de 15 899 heures sur les cinq produits de recherche [21] et que 11 337 des heures travaillées par chaque employé pour l’appelante ont été remboursées dans le cadre de la subvention du PARI.

[231] L’ARC a ensuite réduit les 11 337 heures remboursées des heures qui se rapportaient soit aux projets de l’appelante que l’ARC n’a pas acceptés à titre de RS&DE, soit à d’autres projets (voir les pièces R-7 et R-8). Elle a conclu que seulement 4 010 des heures des employés remboursées aux termes de la subvention du PARI se rapportaient aux projets qu’elle a acceptés comme étant des dépenses de RS&DE. Elle a ensuite appliqué le taux horaire de chaque employé à ces 4 010 heures pour arriver à un remboursement total de 131 054 $ au titre de la subvention du PARI pour les projets qu’elle a acceptés comme étant des dépenses de RS&DE.

[232] Pour l’année d’imposition 2010, l’ARC a déduit la subvention du PARI de 131 054 $ qui a été calculée aux termes de l’alinéa 37(1)d) lorsqu’elle a déterminé la déduction de l’appelante en application de l’article 37 pour les dépenses de recherche scientifique et de développement expérimental (voir la pièce R-3, p. 1). Toutefois, lorsqu’elle a déterminé les CII correspondants, l’ARC a déduit, aux termes du paragraphe 127(18), 171 979 $, ce qui représente la totalité des dépenses au titre des traitements et salaires que l’appelante a engagées pour mener les projets que le ministre a acceptés à titre de RS&DE (voir la pièce R-3, p. 2).

[233] M^me Sporich a donné la raison suivante pour déduire, aux termes du paragraphe 127(18), la totalité des dépenses au titre des salaires et traitements engagées par l’appelante plutôt que seulement la partie des salaires et traitements qui a été remboursée au titre de la subvention du PARI : puisque la subvention du PARI visait des projets qui ont été déclarés à titre de RS&DE, le travail effectué sur les projets devait, en vertu du paragraphe 127(18), être retiré du calcul des dépenses admissibles au CII [22] .

[234] La pièce R-7 contient un calcul similaire pour l’année d’imposition 2011. Pour l’année d’imposition 2011, l’ARC a conclu que l’appelante a reçu une subvention du PARI de 18 491 $ concernant les projets qu’elle a acceptés comme projets de RS&DE.

[235] L’appelante conteste la thèse du ministre. Elle soutient que, quel que soit le montant déduit aux termes de l’alinéa 37(1)d) lors du calcul de la déduction de l’appelante pour ses dépenses de recherche et de développement expérimental, le même montant doit être déduit aux termes du paragraphe 127(18) lors du calcul du montant des CII correspondants de l’appelante.

[236] J’abonde dans le sens de l’appelante.

[237] Selon l’alinéa 37(1)d), le contribuable doit déduire le montant suivant lorsqu’il détermine sa déduction aux termes du paragraphe 37(1) pour les dépenses de recherche scientifique et de développement :

le total des sommes représentant chacune une aide gouvernementale ou une aide non gouvernementale, au sens du paragraphe 127(9), au titre d’une dépense visée aux alinéas a) ou b), dans leur version applicable relativement à la dépense, que le contribuable a reçue, est en droit de recevoir ou peut vraisemblablement s’attendre à recevoir à la date d’échéance de production qui lui est applicable pour l’année;

[Non souligné dans l’original.]

[238] Ce texte oblige le contribuable à déduire le montant d’une aide gouvernementale, quelle qu’elle soit, telle qu’elle est définie au paragraphe 127(9). Le contribuable est tenu de déduire l’aide gouvernementale si elle est reçue à l’égard de certaines dépenses effectuées pour la recherche scientifique et le développement expérimental qui sont prévues par les alinéas 37(1)a) et b).

[239] Selon le paragraphe 127(18), le contribuable doit, lorsqu’il calcule un CII aux termes du paragraphe 127(5) à l’égard de son compte de dépenses admissibles de RS&DE, déduire le montant suivant :

Dans le cas où un contribuable — personne ou société de personnes (appelée dans le présent paragraphe « contribuable ») — reçoit, est en droit de recevoir ou peut vraisemblablement s’attendre à recevoir, au plus tard à la date d’échéance de production qui lui est applicable pour son année d’imposition, un montant qui représente une aide gouvernementale, une aide non gouvernementale ou un paiement contractuel qu’il est raisonnable de considérer comme se rapportant à des activités de recherche scientifique et de développement expérimental, l’excédent de ce montant sur les montants appliqués pour les années d’imposition antérieures en vertu du présent paragraphe ou des paragraphes (19) ou (20) relativement à ce montant est appliqué en réduction des dépenses admissibles du contribuable engagées par ailleurs au cours de l’année qu’il est raisonnable de considérer comme se rapportant aux activités de recherche scientifique et de développement expérimental.

[Non souligné dans l’original.]

[240] Lorsque le contribuable calcule son CII, selon ce texte, il doit déduire le montant de l’aide gouvernementale reçue. Il est tenu de déduire l’aide gouvernementale si elle peut raisonnablement être considérée comme se rapportant à des activités de RS&DE.

[241] Aux termes de l’alinéa 37(1)d) et du paragraphe 127(18), l’appelante était tenue de déduire le montant de l’aide gouvernementale, telle qu’elle est définie au paragraphe 127(9), qu’elle a reçue à l’égard de ses projets de RS&DE. La subvention du PARI est une aide gouvernementale aux fins du paragraphe 127(9).

[242] L’ARC a conclu que le montant de la subvention du PARI qui se rapportait aux projets qu’elle a acceptés à titre de RS&DE était de 131 054 $. L’ARC aurait dû déduire ce montant en application de l’alinéa 37(1)d) et du paragraphe 127(18). Le paragraphe 127(18) ne permet pas la déduction d’un montant supérieur à l’aide gouvernementale reçue par l’appelante.

[243] M^me Sporich a communiqué à la Cour la pièce R-10, qui est préparée sur le même fondement que les pièces R-7 et R-8, mais qui suppose que le ministre a accepté les dépenses de RS&DE de l’appelante telles qu’elles ont été déclarées. Il s’agit du calcul par l’ARC du montant de la subvention du PARI que l’appelante a reçu à l’égard de tous ses projets.

[244] Conformément à la pièce R-7, la pièce R-10 montre que pour l’année d’imposition 2010, 23 employés ont travaillé 15 899 heures sur l’ensemble des projets que l’appelante a déclaré être des activités de RS&DE et que 11 337 de ces heures ont été remboursées dans le cadre de la subvention du PARI. La pièce R-10 montre que sur les 11 337 heures remboursées dans le cadre de la subvention du PARI, 8 029 ont été consacrées à des travaux effectués dans le cadre des projets que l’appelante a déclaré être des activités de RS&DE. M^me Sporich a ensuite appliqué le taux horaire de chaque employé aux 8 029 heures pour arriver à une subvention totale du PARI de 262 239 $ pour l’ensemble des projets de l’appelante qui, selon elle, constituaient des activités de RS&DE. À la page 2 de la pièce R-10, elle ventile les 262 239 $ par projet individuel. Les pages 3 et 4 de la pièce R-10 contiennent des calculs similaires pour l’année d’imposition 2011.

[245] À l’aide de la page 2 de la pièce R-10, j’ai modifié le numéro de subvention du PARI pour l’année d’imposition 2010 afin de n’inclure que les projets que la Cour a acceptés à titre de RS&DE. Plus précisément, la partie AT2/OT2 du projet n^o 3 de 2010 a été exclue puisque l’appelante a concédé au début de l’audience qu’elle ne constituait pas une activité de RS&DE. En ajoutant le nombre donné pour les projets que la Cour a jugé être des activités de RS&DE, on obtient une subvention du PARI de 202 889 $. Un calcul similaire pour l’année d’imposition 2011 donne une subvention du PARI de 22 386 $. Tels sont les montants qui doivent être déduits aux termes de l’alinéa 37(1)d) et du paragraphe 127(18).

[246] La deuxième aide gouvernementale prise en compte par les deux parties a été désignée sous le nom d’aide de la SOCI. Je n’ai été saisi d’aucun élément de preuve sur la nature de la subvention, si ce n’est le fait que les deux parties ont déduit un montant au titre de la subvention de la SOCI lorsqu’elles ont déterminé les dépenses de RS&DE et les CII de l’appelante. L’appelante et le ministre ont tous deux calculé que l’aide gouvernementale au titre de la subvention de la SOCI correspondait à 10 % de ce qui suit :

Dépenses de RS&DE admissibles

Plus : montant de remplacement visé par règlement

Moins : aide du PARI reçue à l’égard des activités de RS&DE [23] .

[247] L’application de ce calcul aux montants déterminés par la Cour donne lieu à une aide gouvernementale au titre de la subvention de la SOCI de 49 986 $ pour l’année d’imposition 2010 et de 56 483 $ pour l’année d’imposition 2011.

[248] Compte tenu de ce qui précède, l’appelante a engagé des dépenses de RS&DE admissibles de 449 878 $ et de 508 351 $ pour les années d’imposition 2010 et 2011 respectivement, et a droit à des CII correspondants de 157 457 $ et de 177 923 $ pour les années d’imposition 2010 et 2011 respectivement, calculés comme suit :

[249] Pour les motifs qui précèdent, les appels sont accueillis avec dépens et les nouvelles cotisations sont renvoyées au ministre pour nouvel examen et nouvelle cotisation au motif que l’appelante a engagé des dépenses admissibles de RS&DE de 449 878 $ et de 508 351 $ pour les années d’imposition 2010 et 2011 respectivement, et qu’elle a droit aux CII correspondants de 157 457 $ et de 177 923 $ pour les années d’imposition 2010 et 2011 respectivement.

Signé à Ottawa, Canada, ce 31^e jour de mars 2021.

« S. D’Arcy »

Traduction certifiée conforme

ce 15^e jour d'octobre 2021.

François Brunet, réviseur

RÉFÉRENCE :	2021 CCI 27
NOS DU DOSSIER DE LA COUR :	2014-1690(IT)G 2014-1691(IT)G
INTITULÉ :	ALLEGRO WIRELESS CANADA INC. c. SA MAJESTÉ LA REINE
LIEU DE L’AUDIENCE :	Toronto (Ontario)
DATE DE L’AUDIENCE :	Les 6, 7 et 8 mai 2019 et les 21, 22 et 23 septembre 2020
MOTIFS DU JUGEMENT :	L’honorable juge Steven K. D’Arcy
DATE DU JUGEMENT :	Le 31 mars 2021

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

AVOCATS INSCRITS AU DOSSIER :

Pour l’appelante :

Nom :	Me Jonathan N. Garbutt
Cabinet :	Garbutt Tax Law Toronto (Ontario)
Pour l’intimée :	Nathalie G. Drouin Sous-procureure générale du Canada Ottawa (Canada)