DAZZM Inc. c. Le Roi

DAZZM Inc. c. Le Roi
Base de données – Cour (s)
Jugements de la Cour canadienne de l'impôt
Date
2024-10-08
Référence neutre
2024 CCI 129
Numéro de dossier
2021-3161(IT)G
Juges et Officiers taxateurs
Jean Marc Gagnon
Sujets
Loi de l'impôt sur le revenu
Contenu de la décision
Dossier : 2021-3161(IT)G
ENTRE :
DAZZM INC.,
appelante,
et
SA MAJESTÉ LE ROI,
intimé.
Appel entendu les 27 et 28 mars 2024 à Montréal (Québec)
Devant : L'honorable juge Jean Marc Gagnon
Comparutions :
Avocat de l’appelante :
Me Extra Junior Laguerre
Avocats de l'intimé :
Me Anne-Élizabeth Morin
Me Julien Dubé-Senécal
JUGEMENT
Conformément aux motifs du jugement ci-joints, l’appel est accueilli, le tout avec dépens, et la nouvelle cotisation en date du 22 janvier 2020 visant l’année d’imposition de l’appelante se terminant le 30 juin 2018 est renvoyée à la 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 de développement expérimental additionnelles totales de 270 167$, et a droit au crédit d’impôt à l’investissement correspondant.
Signé à Montréal, Québec, ce 8e jour d’octobre 2024.
« J.M. Gagnon »
Juge Gagnon
Référence : 2024 CCI 129
Date : 20241008
Dossier : 2021-3161(IT)G
ENTRE :
DAZZM INC.,
appelante,
et
SA MAJESTÉ LE ROI,
intimé.
MOTIFS DU JUGEMENT
Le juge Gagnon
I. Mise en contexte
[1] L’appelante a déposé un avis d’appel le 14 décembre 2021 visant son année d’imposition se terminant le 30 juin 2018. L’appelante en appel d’une nouvelle cotisation par avis daté du 22 janvier 2020 et établie en vertu de la Loi de l’impôt sur le revenu [1]. Par cette nouvelle cotisation, la ministre du Revenu national (Ministre) a refusé à l’appelante une déduction réclamée à titre de recherche scientifique et de développement expérimental (RS&DE), de même que le crédit d’impôt à l’investissement (CII) correspondant.
[2] L’appelante développe et vend des progiciels de gestion fonctionnant sur le nuage en mode Software AS A Service (SaaS) destinés à ses clients du secteur public et privé.
[3] Dans le cadre de la production de sa déclaration de revenus 2018, l’appelante a réclamé des dépenses de RS&DE à titre de dépenses et de CII en lien avec deux projets (Projet 1/Projet 2). L’Agence du revenu du Canada (ARC) a accepté, tels que produits et sans examen visant à déterminer si les travaux entrepris dans le cadre de ce projet constituent des activités de RS&DE telles que définies au paragraphe 248(1) LIR, les dépenses de RS&DE liées au Projet 2. L’ARC a cependant refusé des dépenses de RS&DE liées au Projet 1 : Solution infonuagique totalement flexible bâtie sur métadata.
[4] Pour le Projet 1, l’appelante a initialement réclamé dans sa déclaration de revenus produite pour l’année d’imposition 2018 un montant total de 715 044$ à titre de dépenses de RS&DE. Suite à une première analyse de l’ARC, l’appelante a déposé une documentation amendée en soutien du Projet 1 et le montant total des dépenses de RS&DE a été réduit à 278 927$ aux fins du calcul des dépenses admissibles et du CII correspondant. Le Projet 1 concernait dorénavant quatre sous-projets. Seul le sous-projet 1 est en litige. La nouvelle cotisation en appel a reconnu aux fins du Projet 1 le montant de 8 760$ de dépenses RS&DE, refusant ainsi un montant de 270 167$.
[5] À l’ouverture de l’audition, l’intimé a concédé à l’appelante la reconnaissance de dépenses admissibles additionnelles de RS&DE pour les sous-projets 2, 3 et 4 du Projet 1 pour un montant de 61 314$. En conséquence, sans égard à la décision de la Cour, l’appel sera accueilli si ce n’est que pour reconnaître la concession de l’intimé aux fins de l’alinéa 37(1)a) et de l’article 127 LIR.
[6] Considérant la concession de l’intimé, le désaccord entre les parties concernant l’admissibilité des dépenses de RS&DE de l’appelante ne vise au final que les dépenses de salaires encourues par l’appelante au cours de son année d’imposition 2018 au montant de 208 853$ en lien avec le sous-projet 1 du Projet 1 nommé React Performance (Dépenses).
[7] Deux témoins ont été appelés par l’appelante. Seul le conseiller en recherche et technologie pour la vérification de la réclamation RS&DE de l’appelante a été appelé à témoigner par l’intimé.
II. Question en litige
[8] La question en litige est de déterminer si les activités réalisées dans le cadre du sous-projet 1 du Projet 1 (Projet Visé) constituaient des activités de RS&DE au sens de la définition prévue au paragraphe 248(1) LIR.
[9] Si la Cour conclut favorablement que les Dépenses constituaient des dépenses encourues dans le cadre d’activités de RS&DE définies au paragraphe 248(1) LIR, l’appel doit être accueilli. À l’exception du point soulevé au
paragraphe 5, aucune partie n’a soulevé de questionnement eu égard au montant des Dépenses. Dans l’éventualité où l’appel est accueilli, les Dépenses seront déductibles en vertu de l’alinéa 37(1)a) LIR et admissibles aux fins du calcul du CII en vertu du paragraphe 127(5) LIR. Au contraire, si la Cour conclut défavorablement que les Dépenses constituaient des dépenses encourues dans le cadre d’activités de RS&DE définies au paragraphe 248(1), l’appel ne sera accueilli qu’aux fins d’accorder la concession de l’intimé décrite plus haut.
[10] Conformément à un contrôle établi dans la décision Northwest Hydraulic [2], cinq critères doivent être présents pour qu’un projet se qualifie comme activité de RS&DE au sens du paragraphe 248(1) LIR :
existait-il un risque ou une incertitude technologiques qui ne pouvait être éliminé par les procédures habituelles ou les études techniques courantes?;
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?;
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?;
le processus a-t-il abouti à un progrès technologique?;
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?
III. Position des parties
[11] L’appelante est d’avis que les Dépenses sont encourues dans le cadre d’activités de RS&DE telles que définies au paragraphe 248(1) LIR. L’appelante est également d’avis que, considérant la position de l’intimé telle que libellée dans la réponse à l’avis d’appel, seuls les deux premiers volets énumérés au paragraphe 10 (l’incertitude technologique et la formulation d’hypothèses), sont en litige.
[12] L’appelante ajoute au soutien de sa position :
i. le vérificateur n’a jamais demandé les documents qu’il jugeait pertinents pour s’assurer que les travaux étaient admissibles;
ii. la combinaison des quatre outils/logiciels (Fonctionnalités) utilisés dans le cadre de la réalisation du Projet Visé représente une incertitude technologique et même une incertitude systématique. La problématique n’est pas avec l’utilisation d’une seule des composantes ou deux composantes des Fonctionnalités, mais bien l’utilisation des quatre Fonctionnalités réunies. La résultante n’est pas adéquate et celle attendue par les clients de l’appelante;
iii. une équipe expérimentée de l’appelante, consultant multitudes ressources tout au long du processus de recherche, n’a pas été en mesure de résorber la problématique, qui représente une incertitude technologique;
iv. au soutien de la problématique, le groupe Facebook, éditeur de React (une des quatre Fonctionnalités), remplace subséquemment les HOC, qui se sont avérés un sérieux enjeu dans le cadre du Projet visé, par les Hooks. Ce changement supporte que les outils/logiciels disponibles d’alors ne soient pas en mesure de répondre à toute éventualité notamment pour le Projet Visé;
v. l’appelante tente une multitude d’hypothèses. Chaque hypothèse fait l’objet d’une vérification systématique pour comprendre le résultat;
vi. il faut considérer chaque projet globalement de l’année et non chaque essai individuellement. D’une façon globale, le Projet visé permet à l’appelante de contribuer à l’avancement d’une incertitude technologique.
[13] Selon l’intimé il incombe à l’appelante de prouver ses affirmations, notamment afin de réfuter les hypothèses présentées en réponse par la Ministre. Il ajoute :
l’appelante ne démontre pas que les incertitudes technologiques surmontées ne peuvent pas être dissipées à l'aide des études techniques courantes. Les preuves démontrant le temps effectué sur les travaux sont reconstituées et ne sont pas contemporaines. Cependant, l’intimé accepte que cet aspect n’est pas fatal à la qualification d’un projet au titre de la RS&DE;
les solutions utilisées ne sont pas liées à une incertitude technologique, ils constituent seulement du débogage;
le Projet Visé représente essentiellement une démarche d’optimisation effectuée avec des méthodes et des connaissances disponibles. L’appelante ne démontre pas ses recherches et ses démarches;
Redux, React, Styled Component et Recompose (qui forment les quatre Fonctionalités) sont utilisées par des millions de personnes. L’appelante nous a indiqué que chacun de Redux, Styled Component, et Recompose est fabriqué pour aller avec React. Les solutions qu’elles apportent sont des solutions pour répondre à des bogues.
IV. Témoignages
1. Pierre Lamoureux
[14] Monsieur Pierre Lamoureux a témoigné pour l’appelante. Il est le fondateur de l’appelante. La Cour a retenu une impression favorable du témoignage de Monsieur Lamoureux. Il a représenté le témoin central de l’appelante. Il est apparu devant la Cour préparé et a exprimé les détails pour permettre de comprendre les enjeux liés au Projet Visé. Il a présenté une position rassurante et raisonnable de ce qu’a représenté le Projet Visé pour l’appelante.
[15] Monsieur Lamoureux est diplômé de l’École d’ingénierie polytechnique de Montréal. Il a complété un baccalauréat en génie informatique. Il a plus de 30 années d’expérience en développement et logiciels. Monsieur Lamoureux a été impliqué dans l’ensemble des projets de recherche et développement chez l’appelante. Il explique que cette implication d’un officier de son rang se justifie plus particulièrement pour une entreprise de petite ou moyenne taille qui ne peut se permettre de consacrer des ressources de main d’œuvre importantes de l’entreprise sans un suivi engagé et constant de ses dirigeants.
[16] Il confirme que l’appelante a été fondée en 2010. L’entreprise développe et commercialise une solution de IT Service Management. L’appelante avait une vingtaine d’employés en 2018. L’appelante a plus de 200 clients. Les activités de recherche et développement ont toujours occupé un poste important chez l’appelante.
[17] Le Projet Visé concerne le développement d’une nouvelle version d’un logiciel offert aux clients de l’appelante, destinée au service informatique des entreprises et permettant de mieux s’adapter aux besoins changeants de gérer leurs activités. La particularité du projet est l’intégration d’outils évolutifs permettant de supporter des plateformes. Les plateformes permettent d’accueillir le programme à distance et donc des accès multiples.
[18] Le témoin explique que le logiciel lui-même constitue en fait le système en arrière-plan qui (i) assure le suivi des requêtes, et (ii) gère l’inventaire et les contrats, informations, etc. des données-clients. La version précédente du logiciel nommé Octopus était le principal produit offert par l’appelante à ses clients. Le logiciel de base Octopus était un logiciel commun non-personnalisé. Cependant, l’architecture du logiciel permettait l’ajout de plug-in pour répondre au besoin spécifique des clients. Le logiciel contenait des champs (par exemple le prénom ou nom de famille) que l’utilisateur pouvait interchanger.
[19] La version offerte était la version 4 et l’appelante développait la version 5 disponible sur le Web en plus d’être disponible sur Windows tout comme la version 4. Cependant, en cours du développement de la version 5, l’appelante a rencontré des problèmes de performance majeurs. Ces problèmes sont le principal responsable des Dépenses encourues dans le cadre du développement de la version 5.
[20] Monsieur Lamoureux explique que la problématique rencontrée par l’appelante dans le cadre du développement de cette nouvelle version du logiciel est centrée sur l’utilisation de quatre outils (les Fonctionnalités) utilisés en conjonction, et qui sont décrits comme suit :
React : React est une librairie utilisée pour générer l’interface utilisateur. Il s’agit d’une librairie open source disponible à tous et développée par le groupe Facebook. React aide à générer le HTML. Cependant, d’autres librairies sont également nécessaires pour bâtir une application Web;
Redux : Redux est un outil généralement utilisé afin de s’assurer que seule la mise à jour d’un renseignement à l’écran par l’usager soit effectuée sans par ailleurs requérir une mise à jour de tout l’écran et ainsi réduire la vitesse de la performance de sauvegarde réalisée;
Styled Component : Styled Component est une librairie dédiée au style des caractères à l’écran de l’usager. Cette librairie est associée au formatage;
HOC : HOC (acronyme pour high-order components/calculators), est une méthodologie en lien avec la programmation permettant de réunir des composantes chacune ayant une fonction spécifique en chaîne. La programmation qui en résulte est réduite et moins lourde à mettre en place.
[21] Il confirme que le modèle code source ouvert (open source) est commun dans le monde du logiciel. Il y a beaucoup d’entreprises qui développent des librairies et qui permettent à la communauté (informaticien, programmeur, usager, etc.) de les utiliser. Il ajoute qu’en échange, souvent, la communauté partagera des commentaires, suivis, avis, (feedback), etc. sur les problèmes ou les difficultés rencontrés lors de l’utilisation et présentera des solutions, le cas échéant.
[22] Monsieur Lamoureux précise que lorsque le code source est accessible, l’usager est en mesure de modifier le code source de la librairie dans le but d’améliorer son application. Il en résulte une librairie évoluée.
[23] Il ajoute que dans le cadre de la réalisation d’une application Web comme la version 5, il peut avoir par exemple jusqu’à 20 ou 25 librairies différentes peuvent être utilisées, puisqu’aucune librairie ne permet de tout accomplir.
[24] Lors de la programmation de la version 5, il a été convenu que l’équipe de programmation allait effectuer une utilisation conjointe des quatre Fonctionnalités. Cependant, les essais quant au résultat obtenu ne se sont pas avérés concluants. La conjonction des Fonctionnalités entraînait une problématique importante quant à la performance de la version sous essai. La vitesse d’exécution était nettement trop lente. La conjonction n’est pas apparue impossible mais l’assemblage ne permettait pas d’atteindre une efficacité acceptable, ce qui menaçait le projet.
[25] Le témoin a souligné que des premiers essais afin de résoudre la problématique par des changements créant de petites optimisations de la performance a produit un gain négligeable de moins de 10 pour cent. Par la suite, le travail d’analyse a permis de réaliser que le problème de performance présentait une problématique encore plus importante nécessitant la vérification d’hypothèses additionnelles.
[26] Monsieur Lamoureux témoigne que l’appelante a regardé si la problématique pouvait être liée au millier de components utilisés simultanément afin d’alimenter le programme. Il a confirmé que l’appelante a fait des recherches, regardé tout ce qui était disponible, et ils ont lu tous les problèmes qui existaient associés aux différentes librairies utilisées. Aucune source consultée n’a révélé la problématique rencontrée de façon satisfaisante.
[27] L’appelante a souvent consulté un site Web nommé Github. Monsieur Lamoureux a expliqué que ce site contient une librairie de code, mais aussi permet aux gens dans la communauté de code et de programmation de se consulter pour savoir si d’autres rencontrent les mêmes problèmes ou pour essayer de comprendre la piste qui peut solutionner un problème. Il existait aussi d’autres articles et d’autres groupes ailleurs, par exemple sur Google et Reddit.
[28] L’appelante a contacté React qui n’a pas été en mesure de solutionner la problématique rencontrée. Les échanges contenus dans Github n’ont pas non plus mentionné la problématique. L’équipe de Réact a proposé à l’appelante de leur soumettre un projet reproduisant la problématique. L’intérêt du groupe Facebook à la situation de l’appelante existait véritablement.
[29] React avait un outil diagnostic pour aider à localiser où se trouvent les problèmes. Cependant, cet outil n’a pas fonctionné quand il a été utilisé pour le programme de l’appelante puisque le programme avait trop de nœuds. Le témoin ajoute qu’il était connu qu’avoir trop de nœuds causera l’outil diagnostic à ne pas fonctionner. Suite à cette réalisation, l’appelante a développé son propre outil diagnostic pour éviter le travail essai-erreur et solutionner le problème plus efficacement. L’appelante a développé trois outils diagnostiques.
[30] L’appelante s’est également résignée à devoir apprendre le fonctionnement interne des librairies (il réfère à Redux, Styled Component, Recompose) afin d’être en mesure de modifier le code source interne de ces librairies de façon à être capable d’injecter des noms permettant de solutionner le problème de performance. Le témoin a confirmé que cette approche a permis à l’équipe de programmation alors dédiée à la résolution du problème de performance de remplacer des composantes sources de ces programmes afin de vérifier si ces tentatives permettront de résorber ou atténuer la problématique.
[31] En analysant les codes des Fonctionnalités, l’appelante a constaté que des optimisations des librairies étaient possibles. La performance est passée de 1 300 millisecondes à 775 millisecondes. Mais cela ne suffit pas.
[32] Le témoin ajoute que les analyses ont permis de conclure qu’il n’y avait pas de problème avec React en soi avec 50 000 HOCs. Ce qui était le problème, c’est la combinaison de React avec Redux, avec Styled Component, et avec Recompose. Les HOCs créés par d’autres joueurs causaient également des problèmes de performance. Par contre, il n’y a jamais eu de certitude que le nombre de HOCs était l’unique responsable de la problématique. L’incertitude aurait pu être liée à un seul maillon plus faible qui rend le reste de l’équation automatiquement moins performant.
[33] La piste de solution ensuite considérée par l’appelante a été de réduire le nombre de nœuds associé à la programmation. Le témoin a relaté que l’appelante allait réécrire le code dans le but de réduire le nombre d’HOCs dans le programme. Bien que l’appelante pouvait réduire le nombre d’HOCs, elle ne pouvait pas les éliminer entièrement. Un certain nombre s’est avéré incontournable. Cette action a permis d’améliorer la performance de 775 à 692 millisecondes. Bien que la performance s’améliorait, elle était encore loin d’être acceptable. Monsieur Lamoureux a précisé qu’une performance acceptable est moins de 300 millisecondes, et que l’appelante cherchait à atteindre un rendement davantage performant.
[34] Monsieur Lamoureux a confirmé que l’appelante à utiliser ses meilleures ressources pour ce projet, parce que c’était complexe. Il a également expliqué que son équipe était bien organisée pour être efficace et éviter le dédoublement du travail requis. Cette approche est conforme à la gestion des entreprises de moyennes tailles à laquelle monsieur Lamoureux faisait allusion au début de son témoignage.
[35] Le témoignage a également permis d’apprendre comment l’appelante a été en mesure de comprendre les fondements de la librairie Redux. Par exemple, Redux recommandait aux usagers de programmation de se connecter plus haut dans le graphe. Cependant, le témoin a relaté que les recherches ont permis à l’appelante de comprendre qu’il pouvait avoir des avantages à se connecter plus bas et ce faisant a constaté des résultats positifs en effectuant cette stratégie non standard. Il note qu’il n’existait jusqu’alors aucune indication claire à cet effet dans la communauté.
[36] En répondant aux commentaires dans le rapport de vérification, monsieur Lamoureux a accepté les faits énoncés que Redux était un programme utilisé pour réduire les re-rendre. Cependant, incluant pour le Projet Visé, Redux n’était pas suffisant et il existait des problématiques qui n’étaient pas connues dans le domaine public. Le même constat existait avec React Dev Tools. Il était connu que cet outil était utilisé pour améliorer la performance. Il était aussi connu que React Dev Tools cesse de fonctionner sur des sites comportant de nombreux components. Le témoin a confirmé que ces outils n’ont pas suffi et le domaine public n’adressait pas de solution.
[37] Monsieur Lamoureux a également réitéré le processus de recherche engagé chez l’appelante. En première étape, la documentation des librairies retenues est assimilée. Pour la deuxième étape, les programmeurs recherchent les articles et les blogues disponibles et pertinents afin d’identifier ceux et celles s’ayant donné la peine d’expliquer une problématique qui a amené une solution à une problématique rencontrée. Il souligne également que les premières tentatives de solutionner la problématique est toujours de suivre les recommandations dans le domaine public, bien qu’ici ces pistes n’ont pas été concluantes et se sont estompées.
[38] Le témoin rappelle que les recherches effectuées ont permis de confirmer que la communauté en général était d’avis que React se devait d’offrir une approche plus performante que les HOCs. Ces positions ont certes reçu une attention puisque subséquemment le groupe Facebook a apporté une amélioration importante à leur librairie React qui est l’utilisation de hooks.
[39] Le témoin précise qu’à la fin du Projet Visé l’ensemble des librairies publiques disponibles retiraient le code des HOCs. L’appelante aurait voulu remplacer les HOCs, mais l’empreinte était trop importante dans l’architecture du programme. Au moment où les hooks sont apparus, l’appelante qui n’avait pas atteint la performance souhaitée a pris la décision de cesser le développement de la version 5. La version 5 n’a pas atteint la mise en marché. Le témoin ajoute que l’appelante a déployé beaucoup d’énergie et de ressources afin d’obtenir une performance adéquate, mais la raison d’affaire en a décidé autrement.
[40] Le témoignage détaillé de monsieur Lamoureux a permis d’établir le lien entre les itérations décrites aux documents préparés à l’attention de l’ARC et le travail, les interrogations rencontrées, les hypothèses retenues et les résultats obtenus afin de résorber l’incertitude liée à la performance.
[41] En contre-interrogatoire, monsieur Lamoureux a accepté que la seule incertitude technologique du Projet Visé fût liée à la performance de l’application par son usager.
[42] Il a également précisé que les deux principales librairies étaient React et Redux. React était une librairie plus établie utilisée plus fréquemment avec Recompose pour réduire le codage et Styled Component pour appliquer les styles. Redux était davantage un choix de l’appelante.
[43] Lorsque la Cour lui a demandé si l’ARC avait nié le problème de performance, monsieur Lamoureux a confirmé que lorsqu’il a relu la documentation rien ne lui a permis de comprendre que l’ARC remettait en question le problème présenté ou encore les hypothèses mises en place, les tests ou les mesures obtenues. La réponse de l’ARC était plutôt à l’effet que vous avez un problème de performance et la réponse est dans le domaine public d’où l’absence d’incertitude technologique. Le témoin rapporte que cette position lui est apparu inexplicable.
[44] En contre-interrogatoire on a demandé au témoin si l’appelante était la seule à utiliser les quatre Fonctionnalités. Le témoin a répondu ne pas être en mesure de répondre pour les autres usagers. Il l’ignore.
[45] Le contre-interrogatoire a principalement porté sur la documentation interne de l’appelante et à savoir si cette documentation avait été soumise à l’ARC. La réponse obtenue à cet égard n’était pas très claire. Toutefois, le témoin a référé à des documents apportés lors de rencontre avec l’ARC et a réitéré que tous les travaux de l’appelante étaient répertoriés et que c’était « super important ». Le témoin a indiqué que les documents soumis et descriptifs du travail accompli ne sont que des sommaires. Les documents sont principalement conservés à l’interne chez l’appelante. Il a expliqué être en mesure de confirmer qu’énormément de sources ont été consultées.
[46] Ensuite, le témoin a été questionné sur les trois outils de diagnostics développés par l’appelante. La principale question était de savoir si la création de ces outils constituait une incertitude technologique. Il lui a été demandé s’il était fréquent d’utiliser et/ou de développer de tels outils. Le témoin a été clair concernant l’utilisation et elle est fréquente chez les programmeurs. Quant au développement de ces outils, le témoin est d’avis que cela est beaucoup plus rare et que les programmeurs font davantage appel à des outils déjà existants. Il a ajouté qu’il est très rare de le faire soit même car c’est une spécialité peu commune et difficile. On fait appel à ce développement par soi-même lorsqu’aucune autre option n’est possible. Le niveau de difficulté est plus élevé en développement. La Cour comprend que le développement des outils s’est avéré nécessaire dans le cas présent en raison de l’absence d’autre moyen permettant de résorber la progression de l’incertitude technologique liée au manque de performance de la conjonction des Fonctionnalités avec le programme et les HOCs présents.
[47] Le contre-interrogatoire mené n’a pas véritablement attaqué le témoignage en principal de monsieur Lamoureux. À l’exception de ce qui a déjà été noté plus haut, le contre-interrogatoire par exemple n’a pas soulevé d’enjeu sur les hypothèses validées par l’appelante ou encore la réalité et le fondement ou la légitimité de l’absence de performance de la version 5 du programme en développement.
2. Chakib Hamdi [48] Monsieur Chakib Hamdi est le deuxième témoin appelé par l’appelante. Monsieur Hamdi est un conseiller externe offrant ses services pour accompagner les contribuables aux prises avec des demandes de crédit de RS&DE. Il offre également ses services comme sous-traitant de sociétés comme Emergex œuvrant dans les demandes de crédit de RS&DE.
[49] Monsieur Hamdi a reçu son diplôme d’ingénieur en informatique en 1998. Il a travaillé neuf ans dans l’industrie des TI comme directeur informatique. Il a ensuite travaillé comme consultant pour la qualification RS&DE pendant huit ans. Depuis 2016, il a créé sa propre boutique centrée sur la RS&DE.
[50] En ce qui concerne le projet en litige, monsieur Hamdi a offert ses services à l’appelante comme sous-traitant pour Emergex.
[51] Monsieur Hamdi a dit que l’appelante cherchait de l’aide puisqu’elle avait été vérifiée.
[52] Monsieur Hamdi a expliqué que lorsqu’il est consulté, il vérifie si le client a tous les outils. Ensuite il regarde si le client a correctement évalué les outils et si l’équipe en place a les compétences requises. Monsieur Hamdi revoit aussi l’environnement technologique pour comparer si les capacités d’une entreprise sont conformes au niveau de l’environnement technologique selon ses propres recherches et l’examen du domaine public qui existe à l’externe. Si les capacités sont conformes et il existe quand même une difficulté qui ne peut pas être solutionnée avec les capacités possibles dans l’environnement technologique, le projet semble être un bon candidat pour trouver une incertitude technologique.
[53] Dans le cas actuel le témoin a confirmé l’existence des incertitudes et des activités entreprises par l’appelante pour constituer un développement systématique par hypothèse, test et résultat. La documentation au soutien des activités doit également exister. Il a également validé avec l’appelante si un avancement de l’application elle-même existait et si un avancement des connaissances en avait résulté. À l’aide de ces vérifications, il a assisté l’appelante dans ses revendications auprès de l’ARC et plus particulièrement le Projet Visé qui a été présenté.
[54] Monsieur Hamdi n’a pas été très clair ou explicite sur les désaccords avec l’ARC concernant la qualification du Projet Visé et des Dépenses. Il a soulevé deux commentaires que le conseiller en recherche et technologie de l’ARC dans le dossier avait formulé pour refuser l’incertitude technologique. Monsieur Hamdi a fait état de son désaccord avec cette position qui selon lui affichait une vision beaucoup trop limitée de l’ensemble du Projet Visé et de l’étendue de la problématique rencontrée.
[55] Le témoin n’a pas fait l’objet d’un contre-interrogatoire, l’intimé se limitant essentiellement à établir que les services de monsieur Hamdi étaient rémunérés par l’appelante.
3. Didier Guillevic
[56] Monsieur Didier Guillevic est le seul témoin appelé par l’intimé. Il est le conseiller en recherche et technologie ayant agi dans le cadre de la vérification de la réclamation RS&DE de l’appelante pour l’année en appel et plus particulièrement la réclamation concernant le Projet Visé.
[57] Monsieur Guillevic a étudié le génie électrique à l’École supérieure d’ingénieurs en électrotechnique, Paris, France, et poursuivi des études de génie électrique et des télécommunications à l’Université technologique de Karlsruhe, Allemagne. Il a ensuite poursuivi des études de maîtrise en algorithmes d’apprentissage statistique au département d’ingénierie des systèmes électroniques à Colchester, Angleterre (University of Essex). Il a complété un doctorat en algorithmes d’apprentissage statistique à l’Université Concordia à Montréal, Canada.
[58] Sur le marché du travail, monsieur Guillevic a joint le Centre de recherche de Xerox, New York, ensuite été membre du personnel de recherche aux laboratoires centraux de la Nippon Electronic Corporative à Kawasaki, Japon. Il est ensuite revenu à Montréal pour agir à titre d’expert en machine learning pour la reconnaissance de la parole à Locus Dialogue et a poursuivi avec la société Idilia en machine learning liée à la recherche sur le traitement du langage naturel.
[59] En 2017, monsieur Guillevic a joint l’ARC à titre de conseiller en recherche et technologie pour l’examen de demandes de RS&DE. En 2021, il est passé à une autre position pour développer des solutions logicielles pour l’ARC.
[60] Monsieur Guillevic a d’abord expliqué la façon dont il procède en tant que conseiller en recherche et technologie. La demande de vérification est assignée à un vérificateur financier responsable du dossier. Il intervient ensuite à titre de conseiller technique auprès du vérificateur financier afin de l’assister à déterminer l’éligibilité des travaux réclamés par le contribuable à titre de RS&DE admissible.
[61] Monsieur Guillevic a agi pendant environ trois années comme conseiller technique pour des dossiers informatiques à l’ARC, sans plus de spécialisation spécifique. Il a été impliqué dans des projets de sites Web, mais également de systèmes de télémédecine.
[62] Au départ d’un dossier, il témoigne qu’il regarde ce qui a été soumis par le demandeur. Règle générale, c’est deux à trois pages par projet. Il s’agit du formulaire T661 transmis par le demandeur. Il regarde s’il y aurait un potentiel de qualification au titre de RS&DE.
[63] Il précise ensuite qu’il complète son travail en consultant la documentation du demandeur incluant lors des rencontres avec le contribuable. Il peut occasionnellement finaliser par des recherches sur le Web pour chercher un petit peu plus d’information. Avec toute cette information, il rédige son rapport.
[64] À ce sujet, il mentionne :
Il y a une méthodologie -- donc, en premier, on est assigné une demande. Donc, on est en équipe avec une financière. Et pis là, on regarde ce qui a été soumis par le demandeur. Donc, général, c’est deux-trois pages par projet. Pis là, en fonction de ça, ben, on regarde si, à priori, il y aurait un potentiel de RS&DE ou pas.
Et puis on va demander plus d’information sur le projet. On peut décider de ne pas mettre en examen tous les projets. Pis on va demander de l’information sur certains projets qu’on met en examen. On fait ça en collaboration avec la gestionnaire ou le gestionnaire. Donc, c’est décision à deux de décider quel projet va être mis en examen. Et pis là, donc, il y a la documentation qui arrive, normalement, avant la rencontre. On l’étudie, on fait une rencontre, on pose des questions au demandeur, et puis après, on écrit un rapport.
[65] Et au sujet de la rédaction du rapport il ajoute :
Donc, le rapport, il est basé sur -- donc, en premier, la T661, donc les deux-trois pages qu’on reçoit quand la demande est soumise. Ensuite, la documentation du demandeur. Ensuite, la transcription de tout ce qui a été dit pendant la rencontre. Aussi, on peut faire des recherches sur le Web pour voir un petit peu plus, ben, aller chercher un petit peu plus d’information. Et, avec toute cette information, ben, on écrit un rapport.
[66] Il complète au sujet de la qualification des travaux en mentionnant :
Détermination? Ben là, on essaie -- il faut suivre le -- les critères de la politique, qui est une interprétation de la Loi. Et pis ça nous dit que, ben, il y a cinq étapes pour essayer de voir si oui ou non il y aurait une incertitude ou un blocage technologique. Est-ce que, ensuite, une série d’hypothèses a été faite. Et -- donc, on appelle ça une démarche scientifique. Est-ce que ça a mené à un avancement technologique, des nouvelles connaissances que la communauté n’avait pas? Et puis aussi on doit vérifier aussi normalement s’il y a de la documentation pour, ben, pour -- on se -- to back up cette demande.
[67] En réponse à la question de la procureure de l’intimé au sujet de ce qui est demandé à l’appelante au départ en termes de représentations, monsieur Guillevic confirme demander un complément d’information dès le départ. Il réfère notamment au point 4 du formulaire prescrit T661 :
(…) Le point 4, ça c’est vraiment important, parce que pour qu’un projet de RS&DE commence, il faut vraiment avoir démontré que on a essayé de résoudre le problème avec l’expertise qu’on a, avec la boite à outils qu’on a, et puis qu’on a même fait un petit peu de recherche sur le Web pour voir s’il y avait pas d’autres personnes qui avaient rencontré la même problématique qui aurait pu la résoudre ou donner des chemins pour la résoudre. Donc, il faut un petit peu démontrer que ça, ça été investigué. Qu’on a vraiment un petit peu cherché de le résoudre avec nos connaissances, nos outils, et les connaissances publiques.
[68] Il confirme que pour la seconde soumission RS&DE révisée de l’appelante, les représentations obtenues étaient beaucoup plus ciblées. L’ensemble des réclamations RS&DE ont été présentées en quatre sous-projets apparemment pour les mêmes travaux que lors de la première soumission. Chaque sous-projet était documenté contrairement à la première soumission déposée, dont trois de ces sous-projets, il a trouvé des correspondances avec la présentation initiale, et un quatrième qui était nouveau.
[69] Au sujet de la deuxième soumission transmise, il lui a été demandé pour le Projet Visé :
ME MORIN: Et donc, en termes de représentations, qu’est-ce qui est présenté ici, on comprend que la détermination, vous avez conclu que c’était pas de la RS&DE. Pour l’activité 1, pourquoi avez-vous conclu que c’était pas de la RS&DE? Ou qu’il y avait pas d’incertitude technologique, en fait?
M. GUILLEVIC: En fait, donc, c’est optimiser la performance. Je pourrais peut-être commencer à expliquer comment -- quand on développe un produit logiciel, ça se fait toujours en deux étapes. La première étape, c’est on fait -- on crée une solution le plus rapidement possible qui fonctionne. Et la deuxième étape, c’est l’optimisation de la performance. Donc, ça, c’est la chaine de production d’un logiciel. C’est tout le temps ça.
[70] Selon le témoin, l’appelante a créé une solution le plus rapidement possible qui fonctionne. Le projet en litige concerne l’optimisation, l’étape deux, expliquée plus haut.
[71] Une fois de plus il a été demandé au témoin :
ME MORIN: Et donc, pour revenir à la question, pour le fait qu’il y ait pas d’incertitude, pourquoi -- comment êtes-vous arrivé à la conclusion qu’il y avait pas d’incertitude pour les activités du sous-projet 1?
M. GUILLEVIC: Le sous-projet 1, c’est l’optimisation de la performance, donc, étape 2. Donc, il faut regarder -- donc, en premier, c’est identifier les goulots d’étranglement de performance. Donc, où dans le code on passe tout notre temps. Et puis ensuite, il faut, donc, on adresse un endroit où il y a beaucoup de temps qui est passé. Et pis là, on regarde comment cette performance, elle a été améliorée. Parce qu’on fait ça tout le temps.
Donc, on a une boite à outils. On a des techniques. Il y a des techniques qui sont spécifiques à certains outils, mais on a les connaissances ou, dans la communauté, il y beaucoup de connaissances. Donc, on regarde comment cette -- donc, cette -- ce passage du code a été optimisé. Si ça été optimisé avec des choses qu’on connait ou vraiment des choses nouvelles. Donc, c’est là qu’on a regardé.
Pis pour l’activité 1, par exemple, ben -- donc là, disons qu’on a un formulaire, donc un site Web, un formulaire avec plusieurs champs. Donc ---
[72] La Cour a demandé au témoin s’il était possible que les ressources précises disponibles dans le domaine public ne soient pas directement pertinentes ou utiles aux problématiques de performance rencontrées. Pour monsieur Guillevic, si on se fie au projet et aux outils utilisés, donc, aux librairies qui sont utilisées, c’est vraiment - c’est se connecter ou pas se connecter. Il ajoute que ce que la Cour a décrit n’est pas le cas présent.
[73] Pendant l’optimisation, l’appelante a décidé de connecter chaque élément de l’interface directement au magasin Redux. Les résultats c’est que la performance s’est améliorée, mais ceci était connu. Selon lui, ça ressemblait vraiment à des tests de débutant, de personne qui n’avait pas d’expérience avec React. C’est une expérience de base et il n’y a aucune incertitude dans ce résultat.
[74] Monsieur Guillevic a expliqué dont la façon que les HOCs fonctionnent dans le code. Ils sont une fonction produisant un résultat spécifique. Étant des fonctions, un coût existe à leur utilisation. Donc, si on n’est pas très rigoureux et qu’on appelle ces fonctions des centaines de milliers de fois, bien sûr il va y avoir un coût. Donc, dans l’étape 2, optimisation d’un produit logiciel, il va falloir appeler moins de fonctions. Selon monsieur Guillevic, il n’y a aucune incertitude technologique dans l’utilisation des HOCs.
[75] Monsieur Guillevic a témoigné que puisqu’il n’avait pas d’incertitude technologique liée à l’optimisation de programme, que le développement de nouveaux outils pour faire la diagnostiquassions ne sera pas une incertitude technologique.
[76] Les programmes utilisés et les HOCs sont complémentaires, faits pour fonctionner ensemble, et utilisés par des dizaines de millions de personnes chaque jour. C’est des outils à code source ouvert. Tout le monde peut aller lire le code et donc, il y a beaucoup de discussions les concernant.
[77] Il ajoute que les activités pour le projet en litige sont c’est des activités d’apprentissage où il n’y a rien de nouveau pour la communauté. Un HOC, c’est une fonction. Tout étudiant de première année en informatique sait qu’appeler une fonction, ça a un coût. Donc, c’est sûr que si on va appeler