Date: 20000830
Dossier: 98-1324-IT-G
ENTRE :
C.W. AGENCIES INC.,
appelante,
et
SA MAJESTÉ LA REINE,
intimée.
Motifsdu jugement
Le juge Bonner, C.C.I.
[1] Le présent appel est interjeté contre des cotisations d'impôt sur le revenu pour les années d'imposition 1991 à 1995. Par les cotisations en cause, le ministre du Revenu national (le « ministre » ) a refusé des déductions que l'appelante avait demandées en se fondant sur le fait qu'elle avait effectué au cours de ces années-là des dépenses courantes et des dépenses en capital en matière de recherche scientifique et de développement expérimental ( « RS & DE » ).
[2] La question que soulève cet appel est de savoir si un contribuable qui a, au cours de la période allant de 1990 à 1995, créé un logiciel d'application pour l'utiliser dans son entreprise a exercé des activités de RS & DE au sens de l'article 2900 du Règlement de l'impôt sur le revenu (le « Règlement » ). Le logiciel en question était nécessaire pour répondre à des exigences très strictes imposées par la nature de l'entreprise de l'appelante et le milieu concurrentiel dans lequel cette entreprise était exploitée.
[3] Au cours de la création du logiciel, le contribuable a utilisé :
a) une plate-forme informatique basée sur une nouvelle technologie, soit une technologie orientée objets dont l'appelante disait qu'il s'agissait d'une technologie naissante qui était fondamentalement différente;
b) un outil de génie logiciel assisté par ordinateur (GLAO) pour écrire un code machine;
c) une méthode de prototypage rapide par laquelle des prototypes de composantes du logiciel sont créés, essayés et ensuite repris pour corriger des défauts et ajouter de nouvelles fonctions ou capacités.
La technologie orientée objets permet, à ce que j'ai compris, de rassembler des structures de données et des fonctions pour créer des objets pouvant donner lieu à une utilisation ultérieure. La méthode de prototypage rapide s'écartait de la méthode de conception linéaire qui était alors traditionnelle, dans laquelle l'ensemble du programme d'ordinateur est créé d'un coup.
[4] Le logiciel développé par l'appelante était parfois appelé « International Distributed Lottery System » (IDLS), soit un système international décentralisé de loterie. Aux fins des déductions de dépenses de RS & DE demandées par l'appelante, le travail a été réparti en tâches ou projets de développement décrits comme suit :
[TRADUCTION]
Tâche
1 Système informatisé d'entrée des données et d'exécution des commandes
2 Améliorations et modules supplémentaires pour le système d'entrée des données et d'exécution des commandes
3 Améliorations et modules logiciels supplémentaires pour l'entrée des données et le système informatique
4 Améliorations et modules logiciels supplémentaires pour le système informatisé d'exécution des commandes
5 Logiciel pour le système postal américain
6 Module logiciel d'analyse des ventes amélioré
7 Améliorations apportées au système de composition automatique de télémarketing
8 Conception et développement de modules logiciels de télémarketing international
9 Entrée des données et exécution des commandes européennes
10 Système d'ordonnancement de la production
Ces descriptions peuvent être inutiles, mais les fonctions exécutées par le système logiciel issu du travail accompli par l'appelante ont été décrites d'une manière détaillée au cours des témoignages présentés à l'audience.
[5] Il n'y a aucun différend quant aux chiffres. Les parties ont produit un exposé conjoint indiquant les montants des dépenses engagées dans l'exercice de l'activité. La cause a été défendue suivant le principe que ce sera tout ou rien. Soit l'ensemble de l'activité sera considéré comme une activité de RS & DE au sens de l'article 2900, soit aucune partie de l'activité ne sera ainsi considérée.
[6] Les deux premiers témoins de l'appelante ont donné un témoignage portant sur le contexte et les détails du travail accompli. David Harlos est, depuis 1995, le directeur financier de l'appelante. De 1985 à 1995, il était un comptable externe qui travaillait au dossier de l'appelante. Brian Page est un vice-président de l'appelante. Il sert de pont entre le soutien technique et la direction de l'entreprise. En 1987, il est devenu consultant pour l'appelante.
[7] L'appelante exploite une entreprise consistant à vendre à des clients du monde entier (sauf du Canada) des billets de loteries commanditées par le gouvernement. Les activités de commercialisation de l'appelante sont exercées par téléphone et par courrier. Les affaires se font dans un certain nombre de langues. L'appelante accepte les paiements dans un certain nombre de monnaies européennes et nord-américaines. Chaque année, l'appelante offre ou vend à ses clients jusqu'à 100 « produits » de loterie.
[8] Les profits de l'appelante sont générés par les frais de gestion qu'elle fait payer à ses clients. L'appelante reçoit des commandes de billets par courrier et par téléphone. Elle sollicite des commandes de clients établis par téléphone. Elle obtient des clients en faisant des envois postaux d'essai à des personnes dont les noms figurent sur des listes de distribution que l'appelante achète. Lorsqu'ils traitent avec un client établi, les téléphonistes de l'appelante utilisent un fichier informatisé qui donne des détails concernant les habitudes d'achat du client, ses préférences et le solde de son compte. Les commandes téléphoniques reçues sont confiées aux téléphonistes selon la préférence linguistique du client. Il s'agit d'une entreprise à forte intensité de main-d'oeuvre qui emploie environ 450 personnes, dont 300 téléphonistes.
[9] L'appelante a deux à trois millions de clients et reçoit jusqu'à 25 000 commandes par jour. Les commandes sont enregistrées dans le système informatique de l'appelante. On accepte les paiements dans la monnaie du choix du client (sauf en dollars canadiens). Les paiements en argent comptant, par chèque, par carte de crédit et par mandat sont acceptables. Sur confirmation de paiement, le client est informé des numéros de série des billets qui ont été achetés pour lui. Les transactions doivent être conclues dans de stricts délais, car il est possible que des billets ne soient achetés que peu de temps avant le tirage et, évidemment, des billets ne peuvent être achetés après le tirage. Après le tirage, les numéros gagnants sont inscrits dans l'ordinateur de l'appelante, et cette dernière effectue une recherche dans la base de données en vue de trouver les noms des clients qui ont gagné et de prendre des dispositions pour payer ces clients.
[10] L'entreprise qui vient d'être décrite a constamment évolué au fil des ans. L'entreprise a été lancée au début des années 1980. Il s'agissait alors d'une entreprise rudimentaire d'envergure limitée. Des billets de mise éclair d'une seule loterie étaient vendus. Les communications entre l'appelante et sa clientèle se faisaient par courrier. Aujourd'hui, une proportion de seulement 30 p. 100 de l'entreprise résulte de communications postales. Le reste résulte d'appels téléphoniques dont le traitement est assuré à un centre téléphonique situé à Vancouver. Durant la période du développement du logiciel IDLS, il y avait un deuxième centre téléphonique, à Amsterdam. Celui-ci a été ultérieurement fermé. Les activités d'Amsterdam ont été intégrées aux activités canadiennes, arrangement qui a exigé un partage de la base de données et du système de traitement de transactions. Cela a ajouté à la complexité de l'IDLS. La nature de l'entreprise et le milieu concurrentiel exigeaient que l'entreprise soit exploitée avec l'aide d'un système pleinement automatisé.
[11] Vers la fin des années 1980, les besoins de l'entreprise de l'appelante dépassaient la capacité de la technologie alors employée par l'appelante. À cause du caractère unique des exigences commerciales de l'appelante, il n'était pas possible d'acheter un logiciel de série pour répondre à ces exigences. L'appelante n'a eu d'autre choix que de développer son propre système interne. Les objectifs commerciaux relatifs au nouveau système imposaient les exigences suivantes en matière de système : flexibilité, extensibilité, réponse immédiate, exactitude et fiabilité.
[12] En 1990, l'appelante a acheté un ordinateur de capacité moyenne IBM 400. Elle a également acheté un outil intégré de GLAO fabriqué par la société Synon, comme environnement de développement. L'IBM 400 était un nouveau système à l'époque. Il a été choisi parce que le fabricant faisait preuve d'un engagement à l'égard du produit et que l'on s'attendait que le système ainsi que le fabricant soient là pendant longtemps. Le système d'exploitation de l'IBM 400 était basé sur la technologie « orientée objets » . L'appelante a choisi l'outil de GLAO de la société Synon qui utilisait la technologie orientée objets et offrait une méthode de prototypage rapide ainsi qu'un environnement de développement complet.
[13] L'outil de GLAO de Synon utilisé par l'appelante permet au réalisateur de logiciel d'introduire des spécifications dans l'ordinateur en langage ordinaire, et un code machine COBOL est produit. Ainsi, les programmeurs de l'appelante n'avaient pas à écrire des millions de lignes de code. Sans cela, a témoigné M. Page, il aurait fallu à l'appelante environ dix autres années de travail. M. Page a fait remarquer que, grâce à cet outil, on peut réutiliser des programmes, et les programmeurs peuvent travailler de concert.
[14] L'environnement de développement permettait à l'appelante de maintenir de la documentation en matière de développement. L'outil de GLAO de Synon assure une autodocumentation, c'est-à-dire qu'il tient un registre d'activités quotidiennes sous forme électronique. Il applique en outre une méthode qui a facilité le développement du logiciel. L'appelante avait eu des problèmes dès le départ. Il lui fallait concevoir des solutions internes, car, vu la nouveauté de l'IBM 400 et de l'outil de GLAO de Synon, il y avait peu d'experts externes vers qui l'appelante pouvait se tourner afin d'obtenir de l'aide. Pour la même raison, les fabricants eux-mêmes n'étaient pas d'une grande utilité pour l'appelante face aux problèmes qu'elle avait.
[15] M. Page a témoigné que l'utilisation de l'outil de GLAO pour construire un système était nouvelle à l'époque. Il a décrit des inconvénients de cet outil. Des programmeurs ne l'aimaient pas parce qu'il y a un niveau d'abstraction. De plus, il y avait des limites inhérentes à cet outil. Le programmeur devait y indiquer exactement ce qu'il voulait, sinon le résultat final ne correspondait pas au but visé. Les essais étaient importants non seulement pour vérifier le résultat, mais aussi pour savoir si ce qui avait été accompli faisait le meilleur usage de unité centrale et d'autres ressources et maintenait l'intégrité des données. Lorsqu'un problème se posait, on devait déterminer s'il résultait d'une erreur dans l'introduction de données ou d'une limite inhérente à cet outil.
[16] Il y avait dans l'AS/400 lui-même un test d'utilité de performance qui, une fois les paramètres définis, permettait de comparer deux configurations de prototype différentes et d'analyser les résultats. Les résultats d'essais étaient conservés dans la machine, puis archivés. L'appelante ne gardait pas tous les tests qui avaient été archivés, car l'outil de GLAO de Synon permettait aux techniciens de revenir en arrière et de recréer un test.
[17] Comme je l'ai déjà mentionné, l'appelante utilisait une méthode de prototypage rapide. Cette méthode était destinée à permettre à l'appelante de se servir de l'IDLS tout en le développant. Pour cette raison et pour des raisons inhérentes au système d'exploitation informatique et à l'outil de GLAO, l'appelante avait entrepris de développer l'IDLS étape par étape, en utilisant la méthode de prototypage rapide plutôt que la méthode plus courante de conception linéaire, dans laquelle toutes les fonctions de l'ensemble du système sont définies au départ et dans laquelle le système est pleinement développé et testé avant d'être utilisé.
[18] Le témoin Robert Thomas Arnold était la personne principalement responsable du rejet des déductions d'impôt sur le revenu demandées par l'appelante. Il avait agi comme consultant pour Revenu Canada au sujet des aspects techniques et scientifiques relatifs à la demande de déductions de l'appelante. Il a dit que son rôle avait été d'examiner des documents présentés par l'appelante et d'examiner les exigences de la Loi de l'impôt sur le revenu. M. Arnold s'était rendu dans les locaux de l'appelante et avait passé une journée à examiner des documents présentés par l'appelante. Il a témoigné qu'il cherchait de la documentation de l'époque indiquant ou définissant le problème que l'appelante cherchait à régler ainsi que le plan adopté pour le régler. M. Arnold disait ce qui suit dans ses conclusions relatives à l'examen technique de la phase I, qui figurent à la pièce A-9 :
[TRADUCTION]
Rien ne prouve que des approches de remplacement ont été élaborées et essayées, et aucun travail fondé sur l'analyse systématique de résultats d'essais n'est décrit dans le rapport technique. Le rapport technique supplémentaire (doc H) dit que l'on peut démontrer le contenu technique en faisant un résumé des modifications de programme à partir de bandes de sauvegarde archivées, mais un tel résumé n'est pas présenté dans le rapport technique. Les activités globales sont des activités de nature courante ne comportant aucune incertitude technique. Bien que certains travaux courants puissent être proportionnels aux besoins et directement à l'appui d'un développement expérimental, la seule utilisation de pratiques courantes indique qu'une étude basée sur l'expérimentation n'était pas nécessaire pour résoudre des incertitudes techniques.
M. Arnold a bel et bien admis que l'appelante avait accompli son travail de manière systématique. Il n'avait pas examiné la documentation électronique de l'outil de GLAO de Synon pour déterminer si elle renfermait des preuves d'un contenu technique comme l'appelante avait dit qu'il devrait le faire.
[19] J'ai eu l'impression que M. Arnold avait adopté une approche rigide et doctrinaire dans son enquête sur la demande de déductions de l'appelante. Il semble ne pas avoir été disposé à examiner des éléments de preuve qui ne lui étaient pas présentés sous la forme qu'il préférait. Malgré le fait qu'un registre détaillé de l'hypothèse, des essais et des résultats devait[1] être tenu et produit comme preuve d'une recherche scientifique, M. Arnold semble avoir insisté indûment sur la forme sous laquelle le registre doit être tenu. La charge de la preuve dont doit s'acquitter un contribuable qui fait appel d'une cotisation d'impôt sur le revenu est moins lourde lorsque, comme en l'espèce, la cotisation repose sur une enquête sur laquelle un problème d'attitude a influé.
[20] Chaque partie a présenté un témoin expert. Ces deux témoins étaient très qualifiés en technologie logicielle et en développement de logiciels. Ils avaient toutefois des points de vue contraires sur la question de savoir si l'activité de l'appelante constituait une activité de RS & DE.
[21] M. Jacob Slonim, qui détient un doctorat et qui est doyen de la faculté d'informatique de Dalhousie University, a été appelé par l'appelante. M. Slonim a dit qu'en 1998, quand on lui a d'abord envoyé les documents qui avaient été présentés à Revenu Canada, il était très sceptique au sujet de l'assertion de l'appelante selon laquelle des activités de RS & DE avaient eu lieu. Il n'a commencé à changer d'idée qu'en décembre 1998, lorsqu'il est allé au bureau de l'appelante à Vancouver pour deux jours, qu'il a rencontré un certain nombre de personnes concernées, qu'on lui a montré le logiciel et qu'on lui a montré comment fonctionnait le logiciel. Toutefois, il était alors encore incertain et avait demandé plus de documentation ainsi que des manuels relatifs au matériel. En février 1999, il s'était de nouveau rendu au bureau de l'appelante à Vancouver et s'était renseigné davantage. Il est clair que la conclusion de M. Slonim reposait sur un travail soigné visant à découvrir les incertitudes technologiques auxquelles faisait face l'appelante ainsi que les mesures prises pour les résoudre. J'utilise le mot « découvrir » , car peu de registres de l'époque concernant l'activité maintenant en cause ont été maintenus par l'appelante (si ce n'est le registre d'activité pouvant être recréé grâce à l'outil de GLAO de Synon).
[22] Dans son rapport, M. Slonim traitait des lacunes des registres de l'appelante. Il faisait remarquer ceci :
[TRADUCTION]
Ce qui m'a déçu, c'est l'absence d'outil de gestion de projet ainsi que l'absence d'une documentation plus détaillée. À ce que j'ai compris, l'outil de gestion de projet, qui m'aurait aidé à voir où étaient les difficultés, n'a pas été gardé à C.W. Agencies. J'ai vu un ou deux documents qui m'ont indiqué que l'on avait utilisé l'outil de gestion de projet. En outre, bien que j'aie un parti pris puisque j'ai travaillé pour IBM pendant dix ans et que j'en connais les procédures très bien, il serait très étonnant que l'on ait fait appel à un gestionnaire de projet d'IBM n'ayant pas établi un plan détaillé de gestion de projet. Il est possible que ce gestionnaire ait gardé le plan en partant de C.W. Agencies. Sans cet outil, l'analyse était assurément beaucoup plus difficile à faire. Toutefois, comme je l'ai mentionné, en raison des nombreuses incertitudes relatives à ce projet, je n'ai aucun doute qu'une recherche était effectuée par voie d'expérimentation.
Face à l'insuffisance de la documentation, M. Slonim a examiné des modifications dans la structure des données et, à partir de modifications périodiques dans le registre généré par l'outil de GLAO, il estimait pouvoir en déduire quels changements étaient faits.
[23] M. Slonim a décrit comme suit l'hypothèse de l'appelante :
[TRADUCTION]
[...] C.W. Agencies a formulé l'hypothèse selon laquelle l'avantage provenant de l'architecture orientée objets donnerait lieu à une augmentation de la productivité par personne grâce au caractère réutilisable de composantes et à une diminution du temps de développement du système comparativement à des méthodes de développement par procédures. En même temps, il y avait des inconvénients majeurs : nécessité de gérer le caractère incertain de la performance et extensibilité de la nouvelle méthode non prouvée. C'est l'échelle de ce système qui fait que l'on est fondé à dire qu'il s'agit de recherche expérimentale.
Je signale ici qu'il ne m'apparaît pas clairement que cette « hypothèse » soit une hypothèse pouvant être prouvée ou réfutée par voie de recherche scientifique. Il me semble qu'elle est simplement trop vague. Le mot « hypothèse » dans ce contexte est normalement considéré comme désignant une conjecture qui n'est pas incompatible avec des faits connus et qui sert de point de départ à des recherches plus poussées par lesquelles elle pourrait être prouvée ou réfutée objectivement. Même si cette hypothèse est une hypothèse pouvant être vérifiée par voie de recherche scientifique, il ne semble pas que l'appelante ait cherché à la vérifier. Tout ce que l'appelante a vraiment cherché à faire, c'est de développer un logiciel.
[24] M. Slonim a présenté un témoignage détaillé concernant les aspects du système IDLS qu'il considérait comme uniques en leur genre et concernant les incertitudes[2] qui en découlaient à son avis. Les délais étaient extrêmement importants, les langues devaient être correctes, et il fallait s'occuper de questions de devises et de questions de fuseaux horaires. Il fallait veiller à ce que les listes de distribution ne contiennent aucune répétition et il fallait que les données relatives aux clients soient facilement accessibles et puissent être mises à jour d'une manière pratique. M. Slonim considérait comme un élément d'incertitude le fait que l'appelante utilisait une architecture nouvelle sans connaître beaucoup les effets secondaires. L'incertitude était accrue en raison de la taille du système et des millions de lignes de code nécessaires. M. Slonim a dit qu'il y avait de nombreuses inconnues à cause de l'interaction de différentes technologies et que les problèmes n'étaient pas susceptibles d'être réglés facilement. Il a expliqué en détail les incertitudes relatives au système ainsi que les progrès technologiques. Il a énuméré de nombreux éléments différents en matière d'incertitude : extensibilité, performance, intégration logicielle, réutilisation de modules logiciels, complexité des transactions, langues multiples, restrictions en matière de configuration de système, exploitation décentralisée, travaux d'impression, impasses, vitesse de communication et fiabilité du traitement, analyse des ventes, performance en temps réel, développement orienté objets, problèmes de conversion, problèmes de fuseaux horaires, intégrité et recouvrement des données, centre téléphonique et génie logiciel.
[25] Certaines des incertitudes étaient, a dit M. Slonim, résolues grâce à des progrès technologiques, certaines étaient dissipées par la « force brute » , c'est-à-dire par des solutions que M. Slonim qualifiait de moches ou temporaires, et d'autres étaient laissées de côté jusqu'à ce qu'une solution davantage « basée sur la théorie » soit découverte. Je signale ici que, de la manière dont je vois les choses, la question de savoir si le logiciel créé par l'appelante se prêterait bien à une utilisation dans l'entreprise de l'appelante n'est pas en soi une question d'incertitude technologique. Certaines incertitudes technologiques peuvent s'être posées au cours du projet visant à créer l'IDLS, mais, comme je l'ai déjà mentionné, cette cause a été défendue suivant le principe que ce sera tout ou rien.
[26] M. Slonim a fait remarquer que la machine AS/400 elle-même comportait des restrictions en matière de configuration qui entravaient le travail de l'appelante. La base de données du système d'exploitation comportait des contraintes quant au nombre maximum de fichiers, ainsi que des restrictions quant à la capacité des fichiers.
[27] M. Slonim a témoigné que, en 1989-1990, la méthode de conception linéaire était la norme. La méthode de prototypage rapide suivie par l'appelante avait été inventée en 1984-1985, mais, même en 1991, elle n'était pas encore répandue ou populaire. L'utilisation de l'outil de GLAO n'était pas une pratique courante à l'époque. Il se peut qu'elle ait été la norme dans des milieux universitaires, mais seulement pour un nombre relativement faible de lignes de code. Je signale ici qu'un écart par rapport à une pratique courante ne représente pas nécessairement une activité de RS & DE.
[28] M. Slonim a recensé ce qu'il considérait comme quatre progrès technologiques importants. Le premier était le développement d'un très gros système orienté objets qui faisait appel à l'outil de GLAO de Synon et qui répondait aux exigences du domaine de l'appelante. M. Slonim a dit que la pratique courante à l'époque était basée sur des langages procéduraux et sur des modèles de développement de logiciels de conception linéaire. Le deuxième progrès recensé par M. Slonim était l'utilisation du processus guidé par les données, qu'il considérait comme étant relativement nouveau et comme exigeant l'emploi d'une méthode différente de la méthode courante orientée vers les processus. Le troisième progrès technologique était, disait-il, l'intégration de l'outil de GLAO de Synon, avec sa méthode de prototypage rapide, à une époque où la pratique courante était d'utiliser la méthode de conception linéaire. M. Slonim a fait remarquer que l'outil de GLAO avait obligé l'appelante à changer sa méthode de conception et sa pratique en matière de génie logiciel et il arguait que cela constituait un écart important par rapport à la pratique qui était courante à l'époque. Le quatrième progrès recensé par M. Slonim avait trait à l'amélioration du réservoir de connaissances que représentaient les employés et consultants de l'appelante qui travaillaient au projet. M. Slonim estimait que le système IDLS dans son ensemble était une nouvelle façon d'utiliser l'informatique dans une nouvelle application.
[29] M. Ken Takagaki a été appelé comme témoin expert pour l'intimée. Il détient un doctorat (University of British Columbia). Il est doyen de la faculté d'informatique et de technologie de l'information au British Columbia Institute of Technology. Entre 1985 et 1988, il a travaillé à sa thèse, qui concernait les systèmes d'information orientés objets. Au cours du processus de vérification, M. Arnold a demandé à M. Takagaki de participer à des réunions avec l'appelante parce que les communications entre M. Arnold et l'appelante avaient été rompues. M. Takagaki a témoigné que, dans les années 1980, on développait des outils logiciels pour faciliter l'utilisation d'ordinateurs. Le développement d'outils de GLAO remonte aux années 1970. La méthode de prototypage rapide était largement utilisée dans de nombreux ordinateurs pour des fins commerciales au début des années 1980. M. Takagaki considérait cette méthode comme courante.
[30] M. Takagaki reconnaissait la rapidité du changement technologique et avait donc entrepris de se rafraîchir la mémoire quant à savoir ce qui était disponible en 1990. Il avait consulté de vieux répertoires universitaires, pour savoir ce qui était enseigné, ainsi que de vieux manuels, et il avait examiné un programme d'études pour déterminer ce que les professeurs étaient tenus d'enseigner. Dans son rapport, M. Takagaki considérait l'IDLS comme un système d'information et décrivait le processus de développement de systèmes d'information ainsi que les techniques et outils utilisés dans le développement de systèmes d'information. Il disait :
[TRADUCTION]
L'informatique et la technologie de l'information jouent un rôle dans la création de systèmes d'information ou de systèmes d'information de gestion [...]
Généralement parlant, en 1990, l'automatisation de la plupart des procédures ou procédés commerciaux était considérée comme techniquement faisable, notamment dans le cas de procédures ou procédés communs à la majorité des entreprises, par exemple l'établissement de la paie, la gestion du fichier du personnel, l'inscription de commandes, le contrôle des stocks, l'analyse des ventes et l'établissement du calendrier de production, où les règles de l'entreprise sont définies. Une grande variété de technologies pouvaient aisément être achetées, y compris des systèmes de base de données, des technologies de réseautique (LAN et WAN), du matériel de traitement (des ordinateurs centraux et des ordinateurs de capacité moyenne, ainsi que des ordinateurs personnels de plus en plus puissants), des outils de développement de logiciels utilisant des langages classiques (COBOL, RPG) et des outils de développement et de prototypage rapides comme les outils de GLAO et les outils utilisant des langages de quatrième génération.
La construction de systèmes d'information, parfois appelée développement de systèmes d'information, peut être complexe et difficile et comporter des risques importants en matière de gestion de projet. Toutefois, en consultant des manuels, en suivant des cours universitaires ou en s'adressant à des vendeurs, à des consultants et à des spécialistes d'expérience en matière de systèmes d'information, on avait largement accès aux connaissances sur les méthodes ou procédés efficaces pour la construction de systèmes d'information.
Le développement de systèmes d'information est un processus logique et systématique par lequel de tels systèmes sont planifiés, conçus et construits. L'ensemble du processus est habituellement appelé le cycle chronologique de l'élaboration des systèmes (CCES), et un processus particulier est parfois appelé une méthode de développement de système.
En pratique, le CCES est un processus itératif dynamique qui inclut généralement parmi ses composantes les étapes suivantes :
1. Début du projet. La nécessité du projet est déterminée (elle résulte habituellement d'une exigence commerciale), et la décision de lancer le projet est prise. Des décisions sont également prises concernant l'ampleur du projet, le budget, la dotation en personnel, etc.
2. Analyse des exigences. Les spécifications et objectifs de conception du projet sont déterminés en détail.
3. Conception de systèmes. Les exigences techniques ainsi que des solutions en matière de conception sont élaborées. Des modèles sont élaborés pour les données, les processus, les configurations logiques et les configurations physiques du système. Des configurations de rechange sont déterminées et évaluées.
4. Mise en oeuvre. Le matériel et le logiciel sont achetés et/ou développés.
5. Essai. Le système est essayé, c'est-à-dire que les diverses composantes ainsi que le système dans son ensemble sont testés.
6. Conversion. Les données, procédures et autres composantes de système sont converties par rapport à l'ancien système (s'il y en a un). Du personnel est formé.
7. Livraison. Le système est intégré à la production quotidienne.
8. Mise à jour. On augmente la puissance du système pour suivre l'évolution de la technologie ou du milieu commercial.
[31] M. Takagaki a ensuite traité des difficultés qui se posent souvent quand on élabore un système d'information et il a également traité des techniques fréquemment employées pour surmonter ces difficultés. Il disait :
[TRADUCTION]
Les systèmes d'information peuvent être complexes, et les interactions entre les diverses composantes peuvent être difficiles à prévoir. Les exigences commerciales sont en constante évolution, de sorte que le développement de systèmes a souvent lieu dans un climat d'incertitude environnementale ou commerciale. Le cycle chronologique de l'élaboration des systèmes est donc habituellement itératif en ce sens que des modifications du milieu commercial ou les résultats d'une étape subséquente peuvent faire que des réalisateurs de systèmes reviennent à une étape précédente. Tout au long de ce cycle, il y a de nombreux points de contrôle et/ou examens de gestion dans le cadre desquels la faisabilité d'un projet est évaluée et des décisions sont prises quant à savoir s'il convient d'aller de l'avant et s'il convient de fabriquer ou d'acheter un système. Dans ce contexte, une autre incertitude technologique importante tient à l'évolution rapide de la technologie, notamment en ce qui concerne le matériel. Par conséquent, les techniques et outils pour le développement rapide d'applications (DRA) intéressent les réalisateurs de systèmes.
Parmi les divers outils et techniques populaires dans le cas de nombreuses méthodes de développement de systèmes, mentionnons les suivants :
• Prototypage. Construction d'un modèle réduit ou représentatif ou d'un modèle de travail du système, pour aider aux diverses phases du CCES, y compris l'analyse des exigences, la conception, la mise en oeuvre et les essais. Dans le contexte du développement de systèmes, le prototypage est une méthode qui est couramment employée pour élaborer progressivement un système et qui vise à accélérer le processus de développement de systèmes et à améliorer la qualité du résultat final.
• GLAO (génie logiciel assisté par ordinateur). Outil de développement intégré pouvant être utilisé pour documenter des exigences, aider à la conception de systèmes globaux et générer des logiciels (modèles de programmes et de données). Vise à accélérer le développement de systèmes et à améliorer la qualité du résultat final.
• Analyse coûts-avantages. Analyse permettant de mettre en balance le coût de développement et d'exploitation d'un système et les avantages de ce système, en vue de prendre une décision éclairée à cet égard.
• Analyse de faisabilité. Détermination de la faisabilité technique, opérationnelle, économique et autre.
• Évaluation des performances et essais. Évaluation de produits par rapport au prix, à la performance et à d'autres facteurs. Cela est particulièrement important, car les technologies changent constamment, et des interactions complexes peuvent avoir lieu lorsque des technologies sont combinées. Le test par unité détermine comment des composantes fonctionnent lorsqu'elles sont essayées isolément. Le test de système détermine comment les composantes fonctionnent lorsqu'elles sont intégrées au système global. Une combinaison particulière de composantes (matérielles et/ou logicielles) est parfois appelée « configuration » . Tout logiciel élaboré au cours d'un projet de développement de systèmes d'information fait l'objet d'essais courants rigoureux.
• Gestion de configuration et intégration de systèmes. Les systèmes d'information combinent fréquemment des logiciels, du matériel, des données et des processus de diverses sources de manière à former un système intégré. Au fil des ans, les vendeurs et les réalisateurs de systèmes ont adopté différentes positions (parfois inconciliables) en matière de compatibilité. Certains vendeurs préfèrent que leurs produits restent « fermés » à des personnes extérieures. D'autres cherchent à s'assurer que leurs produits soient « ouverts » , c'est-à-dire compatibles avec des produits d'autres vendeurs ou facilement raccordables à de tels produits. Quoi qu'il en soit, les interactions entre différentes composantes peuvent être difficiles à prévoir ou peuvent donner des résultats inattendus et ponctionner une part importante de l'effort de développement de systèmes.
Le concept de cycle chronologique de l'élaboration des systèmes ainsi que les techniques et les outils mentionnés précédemment pourraient être considérés comme faisant partie de la pratique qui était courante parmi les réalisateurs de systèmes d'information à l'époque des demandes de déductions en cause. Ces matières étaient largement décrites et analysées dans des manuels ainsi que dans des revues spécialisées et elles étaient enseignées dans le cadre de programmes d'études postsecondaires en informatique et en technologie de l'information. Des processus commerciaux courants comme l'inscription des commandes, l'établissement de la paie, le contrôle des stocks et l'ordonnancement de la production sont fréquemment utilisés comme exemples dans des manuels, ainsi que dans des cours collégiaux.
[32] M. Takagaki a ensuite traité de la question de savoir si le travail inhérent au développement de systèmes d'information comporte nécessairement de la recherche scientifique au sens de l'article 2900. Il faisait remarquer ceci :
[TRADUCTION]
Le développement de systèmes peut comporter une investigation ou recherche systématique, ainsi que de l'expérimentation et/ou de l'analyse. Par exemple, une investigation ou recherche systématique est importante pour déterminer si toutes les exigences relatives au nouveau système ont été recensées lors de l'analyse des exigences. De même, une recherche systématique est appropriée lorsqu'il s'agit d'effectuer une analyse coûts-avantages et de se procurer quelque chose en faisant un choix entre un certain nombre de vendeurs possibles. Une expérimentation et une analyse peuvent être nécessaires au cours d'essais courants de logiciels ou lorsque divers produits matériels d'évaluation de performance sont offerts par des vendeurs. Toutefois, cela doit être distingué d'une « investigation [...] systématique d'ordre scientifique ou technologique.
Il faisait une distinction entre les projets de développement de systèmes d'information qui entrent dans le cadre de l'article 2900 et ceux qui n'entrent pas dans ce cadre.
[TRADUCTION]
[...] Lorsqu'un projet de DSI utilise un nouveau principe ou concept et vise principalement à vérifier ce nouveau principe ou concept, il se peut qu'il soit conforme au paragraphe 2900(1). Ou encore, des éléments d'un projet de DSI peuvent utiliser des connaissances, techniques ou principes nouveaux qui sont conformes aux exigences du paragraphe 2900(1).
[33] Puis, M. Takagaki a traité des dix projets de l'appelante, considérés individuellement et collectivement. Il faisait remarquer :
[TRADUCTION]
Dans tous ses projets, C.W. Agencies Inc. semblait avoir fait des efforts pour suivre un processus consistant à recenser des exigences, à créer des prototypes avec son outil de GLAO, à faire des essais et à perfectionner le système par itération, soit un développement de système courant, en se servant de méthodes courantes enseignées dans des cours ou expliquées dans des manuels de l'époque.
[...]
Comme on s'y attendrait dans le cas du développement de systèmes d'information courants, tous les projets indiquent qu'il y a eu « investigation ou recherche systématique » par voie « d'expérimentation ou d'analyse » . Les investigations de l'appelante ont principalement pour objet : (i) de définir des exigences, (ii) d'évaluer des produits commerciaux, (iii) de tester des configurations de matériel ou (iv) d'effectuer des tests courants de logiciels. Cela contraste avec une investigation systématique en science informatique, qui porte principalement sur de nouveaux concepts, principes, technologies ou techniques. Je considère que les investigations en cause ont été faites par des utilisateurs compétents et prudents de technologies complexes commercialement disponibles plutôt que par des chercheurs essayant de découvrir de nouveaux concepts, principes ou connaissances[3]. Ainsi, les activités décrites aux points (ii), (iii) et (iv) pourraient être exclues, en tant qu' « activités se rattachant [au] [...] e) [...] contrôle de la qualité ou [...] [à] l'échantillonnage normal des matériaux, des dispositifs ou des produits » . L'activité décrite au point (i) consiste principalement à déterminer les exigences commerciales, les règles et les besoins du système et n'est pas admissible comme « investigation [...] d'ordre scientifique ou technologique » .
2900(1)a) et b) Avancement de la science. Les éléments de preuve relatifs à tous les projets indiquent que ceux-ci ont tous été entrepris pour des motifs commerciaux et non pour l'avancement de la science. C'est ce que montrent les diverses descriptions de projet. De même, il y a une raison importante de croire que, dans leur ensemble, les dix projets ont été entrepris pour des motifs commerciaux et non pour l'avancement de la science.
Dans le cas de chacun des dix projets, l'hypothèse générale avancée était que le projet concerné n'était pas réalisable d'une manière efficace par rapport au coût vu l'état de la technologie informatique de l'époque. Toutefois, l'efficacité par rapport au coût d'un projet de développement de système d'information est fonction de nombreuses variables économiques ainsi que de facteurs techniques ou scientifiques. Par exemple, une baisse des prix du matériel, des pratiques d'achat judicieuses, une gestion de projet efficace ou simplement une réduction des exigences relatives au système peuvent également donner lieu à une efficacité par rapport au coût. Ainsi, ces hypothèses n'indiquent pas en quoi le projet dans son ensemble représente des travaux « entrepris pour l'avancement de la science » , c'est-à-dire de la recherche pure ou appliquée concernant le projet dans son ensemble.
2900(1)c) Progrès technologique. Comme je l'ai mentionné précédemment, les éléments de preuve indiquent que les dix projets considérés dans leur ensemble ont été entrepris pour des fins commerciales et non pour des fins de développement expérimental. À plusieurs endroits, la documentation disponible énonce d'une manière claire et précise les objectifs commerciaux de projets individuels et, malgré les nombreux cas où l'on prétend qu'il s'agit de progrès technologiques, on ne fait pas état d'une manière claire et nette des nouveaux concepts, principes, technologies ou techniques représentant le progrès technologique.[4]
2900(1)c) Création de nouveaux produits ou procédés ou amélioration de produits ou procédés existants. Les types de systèmes développés dans les dix projets sont tous semblables à ceux que l'on trouve dans divers secteurs de l'économie. Aucune nouvelle catégorie de produits ou systèmes n'a été produite, mais, tout comme c'est le cas en général, ces systèmes d'information sont tous fortement adaptés aux besoins de C.W. Agencies Inc.
En un sens étroit, toute modification du système donne lieu à une combinaison ou configuration technologique unique en son genre. Comme chaque projet a ajouté d'une certaine manière au système global, cela pourrait, selon une interprétation « libérale » de cette partie du règlement, représenter au moins une configuration nouvelle ou améliorée et peut-être un système d'information « nouveau » ou « amélioré » pourvu qu'il soit satisfait à la condition préalable énoncée à l'alinéa 2900(1)c) en matière de « développement expérimental » [...], ce qui n'est pas le cas à mon avis.
M. Takagaki a conclu :
[TRADUCTION]
À mon avis, les dix projets dans leur ensemble sont des projets courants de développement de systèmes d'information et ne répondent pas aux exigences du paragraphe 2900(1) pour les raisons suivantes :
1. Bien qu'il y ait eu « investigation [...] systématique [...] par voie d'expérimentation ou d'analyse » au sens du préambule du paragraphe 2900(1), cela visait à déterminer des exigences commerciales, à évaluer des produits commerciaux, à tester diverses configurations de matériel ou à effectuer des essais courants de logiciels. Dans le premier cas, il ne s'agit pas d'une investigation en science informatique. Dans les autres cas, les activités sont exclues en vertu de l'alinéa e) du paragraphe 2900(1).
2. Aucun élément de preuve n'indique que le produit représente un travail « entrepris pour l'avancement de la science » , que ce soit comme recherche pure selon l'alinéa a) ou comme recherche appliquée selon l'alinéa b). La preuve indique nettement qu'il s'agissait plutôt de raisons et d'objectifs commerciaux.
3. Il n'y a aucune preuve d'un « développement expérimental » au sens de l'alinéa c). On a tout au long du projet utilisé des produits et services commercialement disponibles ainsi que des méthodes et pratiques courantes de développement de systèmes d'information. Je ne crois pas non plus qu'un nouveau produit ait été créé en un sens général. Il s'agit en outre de la troisième itération — quoique améliorée — du système.
[34] En guise de réfutation, M. Slonim disait qu'il contestait ce qu'il appelait le principe de départ de M. Takagaki voulant que les projets aient été entrepris pour des raisons commerciales et qu'il n'y ait aucune preuve d'activité de RS & DE, soit une approche que M. Slonim considérait comme « [...] contraire au but du programme relatif aux activités de RS & DE » . M. Slonim disait que M. Takagaki avait omis d'examiner les problèmes technologiques réglés par l'appelante et il faisait référence à une publication de 1994 comme indication que de nombreux aspects du système de C.W. Agencies n'étaient pas courants à l'époque. M. Slonim disait qu'il avait été étonné que M. Takagaki ait omis de recenser l'une quelconque des 21 incertitudes et il disait qu'il supposait que cela résultait du fait que M. Takagaki n'avait pas suffisamment eu l'occasion d'examiner la technologie utilisée par l'appelante.
[35] Pour la période en question, on trouve deux versions de la définition de RS & DE donnée au paragraphe 2900(1). La version applicable aux années d'imposition 1991 et 1992 de l'appelante diffère de la version applicable aux années 1993 à 1995. Le paragraphe 2900(1) prévoit une exigence en deux parties pour ce qui est du développement expérimental. La deuxième partie a été modifiée pour les années d'imposition se terminant après le 2 décembre 1992. La première partie exige qu'une activité de RS & DE soit une « investigation ou recherche systématique d'ordre scientifique ou technologique, effectuée par voie d'expérimentation ou d'analyse » . La deuxième partie pour les années d'imposition 1991 et 1992 de l'appelante exige l' « utilisation des résultats de la recherche pure ou appliquée » dans un des buts énoncés. La deuxième partie pour les années d'imposition 1993 à 1995 exige que les travaux aient été « entrepris dans l'intérêt du progrès technologique » en vue d'une des fins énoncées. La modification apportée à l'article 2900 ne visait qu'à fournir des éclaircissements; aucun changement fondamental n'était envisagé. Sous la forme applicable aux années d'imposition de l'appelante 1993, 1994 et 1995, le paragraphe 2900(1) prévoyait en partie ceci :
2900. (1) Pour l'application de la présente partie ainsi que des articles 37 et 37.1 de la Loi, « activités de recherche scientifique et de développement expérimental » s'entend d'une 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;
d) les travaux relatifs à l'ingénierie, à 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) et servent à les appuyer directement.
[...]
f) le contrôle de la qualité ou la mise à l'essai normale des matériaux, dispositifs, produits ou procédés;
[...]
k) la collecte normale de données.
Il n'est pas nécessaire de reproduire la version applicable aux années 1991 et 1992.
[36] L'approche générale exacte de l'interprétation de l'article 2900 est énoncée comme suit dans la décision que notre cour a rendue dans l'affaire Northwest Hydraulic Consultants Ltd. c. R.[5] :
Les stimulants fiscaux accordés à ceux qui se livrent à la RS & DE visent à encourager la recherche scientifique au Canada (Consoltex Inc. v. The Queen, 97 DTC 724). Cela étant, la législation concernant pareils stimulants « s'interprète de la manière la plus équitable et la plus large qui soit compatible avec la réalisation de son objet » (article 12 de la Loi d'interprétation).
[37] Dans l'affaire Northwest, la Cour a ensuite établi trois critères fondamentaux à utiliser pour déterminer s'il y a eu une activité de RS & DE dans un cas donné. Il s'agit de l'incertitude scientifique ou technologique, du contenu scientifique ou technologique et du progrès scientifique ou technologique. La Cour a expliqué ces trois éléments ou critères dans des termes qu'il convient bien de réitérer :
1. Existe-t-il un risque ou une incertitude technologique?
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.
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? La chose comporte un processus à cinq étapes :
a) l'observation de l'objet du problème;
b) la formulation d'un objectif clair;
c) la détermination et la formulation de l'incertitude technologique;
d) la formulation d'une hypothèse ou d'hypothèses destinées à réduire ou à éliminer l'incertitude;
e) la vérification méthodique et systématique des hypothèses.
Il est important de reconnaître que, bien qu'une incertitude technologique doive être définie au départ, la détermination de nouvelles incertitudes technologiques au fur et à mesure que les recherches avancent et l'emploi de la méthode scientifique, et notamment l'intuition et la créativité, et parfois l'ingéniosité en découvrant, en reconnaissant et en mettant fin à de nouvelles incertitudes, font partie intégrante de la RS & DE.
3. Les procédures adoptées sont-elles conformes aux principes établis et aux principes objectifs de la méthode scientifique, définis par l'observation scientifique systématique, la mesure et l'expérimentation ainsi que la formulation, la vérification et la modification d'hypothèses?
a) Il est important de reconnaître que même si la méthodologie susmentionnée décrit les aspects essentiels de la RS & DE, la créativité intuitive et même l'ingéniosité peuvent avoir un rôle crucial dans le processus aux fins de la définition de la RS & DE. Toutefois, ces éléments doivent exister dans le cadre de la méthode scientifique dans son ensemble.
b) Ce qui peut sembler habituel et évident après coup ne l'était peut-être pas au début des travaux. Ce n'est pas uniquement l'adhésion à des pratiques systématiques qui distingue l'activité courante des méthodes nécessaires selon la définition de la RS & DE figurant à l'article 2900 du Règlement, mais l'adoption de la méthode scientifique décrite ci-dessus dans son ensemble, en vue d'éliminer une incertitude technologique au moyen de la formulation et de la vérification d'hypothèses innovatrices non vérifiées.
4. Le processus a-t-il abouti à un progrès technologique, c'est-à-dire à un progrès en ce qui concerne la compréhension générale?
a) Je veux dire par là quelque chose que les personnes qui s'y connaissent dans le domaine savent ou qu'elles peuvent de toute façon savoir. Je ne parle pas d'un élément de connaissance que quelqu'un, quelque part, peut connaître. La collectivité scientifique est étendue, et elle publie des documents dans de nombreuses langues. Un progrès technologique au Canada ne cesse pas d'être tel simplement parce qu'il existe un possibilité théorique qu'un chercheur, disons, en Chine, a peut-être fait le même progrès, mais que ses travaux ne sont généralement pas connus.
b) Le rejet, après l'essai d'une hypothèse, constitue néanmoins un progrès en ce sens qu'il élimine une hypothèse jusque là non vérifiée. Une bonne partie de la recherche scientifique vise justement à cela. Le fait que l'objectif initial n'est pas atteint n'invalide ni l'hypothèse qui a été émise ni les méthodes qui ont été employées. Au contraire, il est possible que l'échec même renforce le degré d'incertitude technologique.
5. La Loi et son règlement d'application ne le prévoient pas expressément, mais il semble évident qu'un compte rendu détaillé des hypothèses, des essais et des résultats, doive être fait, et ce, au fur et à mesure de l'avancement des travaux.
[38] Le rôle de témoins experts dans des causes comme celle-ci a été examiné par la Cour d'appel fédérale dans l'affaire Christie Ltd. c. La Reine[6]. Au paragraphe 12, le juge Robertson, parlant pour la Cour, disait :
La question de savoir en quoi consistent les recherches scientifiques au regard de la Loi est une question de droit ou une question mixte de droit et de fait, à trancher par la Cour canadienne de l'impôt, et non par les experts cités comme témoins, contrairement à ce que, trop souvent, pensent les avocats des contribuables comme du ministre. Un expert peut aider le juge à jauger les preuves et témoignages de nature technique et peut chercher à le convaincre que les recherches poursuivies n'ont pas abouti ou ne pourraient aboutir à une avancée technologique. Mais, somme toute, son rôle se borne à mettre à la disposition du juge des verres correcteurs à travers lesquels celui-ci peut saisir les données techniques avant de les analyser et évaluer. Sans doute, l'expert cité par une partie cherchera à faire en sorte que ses spécifications focales soient adoptées par la Cour. Cependant, il est loisible au juge de première instance de préférer une ordonnance à une autre.
[39] Il est curieux que, dans la présente espèce, pratiquement tous les éléments de preuve relatifs aux détails de ce qui a en fait été accompli par l'appelante au cours de la conception et de l'écriture du logiciel aient été présentés non pas par une personne directement et personnellement liée au processus, mais plutôt par l'expert de l'appelante, M. Slonim. De la manière dont j'apprécie la preuve, M. Slonim a dû, à cause de l'absence d'un plan de gestion de projet détaillé, examiner les résultats du travail de l'appelante, puis la technologie et les outils utilisés par l'appelante, pour arriver à des conclusions concernant les problèmes qu'il estimait que l'appelante devait avoir eus et concernant les mesures prises pour régler ces problèmes. Je signale que l'omission d'appeler le gestionnaire de projet ou une personne semblable n'a jamais été expliquée par l'avocat de l'appelante. En déterminant ce qui devait en fait s'être produit, M. Slonim, se fondant sur une conjecture quant aux « nombreuses incertitudes de ce projet » , est arrivé à des conclusions que la preuve ne justifiait pas, à mon avis.
[40] Selon moi, M. Takagaki a adopté une position plus prudente et plus défendable lorsque, en réponse à des questions sur ce qui avait été enregistré dans les journaux électroniques générés par l'outil de GLAO, il a fait remarquer : a) que « théoriquement » il aurait pu être possible d'examiner les journaux et de trouver de la documentation permettant d'en inférer une espèce de progrès et b) qu'un grand nombre d'inférences serait nécessaire.
[41] On a demandé à M. Takagaki si le fait même qu'un système gros et complexe ait été développé permettait d'en inférer qu'il y a eu un progrès technologique. Il a répondu qu'il n'avait vu dans la documentation rien qui ait été inconnu dans le domaine technologique. Nul doute que l'IDLS issu du travail de l'appelante était gros et complexe, mais ce simple fait ne permet pas de conclure que le travail était plus que du développement courant de systèmes d'information.
[42] À mon avis, le témoignage de M. Takagaki doit être préféré à celui de M. Slonim. L'opinion de M. Takagaki ne reposait pas sur des conclusions spéculatives quant à savoir ce qui devait s'être produit. Je rejette l'argument selon lequel le travail de M. Takagaki était défectueux du point de vue de la méthode et de l'hypothèse. Cet argument était basé sur l'assertion selon laquelle M. Takagaki avait considéré le logiciel de l'appelante dans son ensemble comme n'étant pas admissible parce que l'appelante avait une motivation commerciale à l'égard de son activité. Certes, je suis bien d'accord qu'il est contraire au bon sens d'exclure de l'application du paragraphe 2900 toute activité entreprise dans un but commercial, mais je ne crois pas que les conclusions de M. Takagaki reposaient sur une telle prémisse erronée. Quand on considère le témoignage de M. Takagaki dans son contexte, il est clair que M. Takagaki a évalué l'activité de l'appelante en vue de déterminer si cette activité avait été entreprise dans l'intérêt du progrès technologique. Il n'a pas été distrait par le but commercial prédominant de l'appelante.
[43] On a également dit que M. Takagaki s'était trompé en arrivant à une décision qualitative basée sur le degré de progrès technique requis pour que le travail soit assimilé à une activité entrant dans le cadre de l'article 2900. Cette critique se rapportait à des observations de M. Takagaki concernant l'exigence du paragraphe 2900(1), à savoir que le résultat de la recherche doit être utilisé en vue de la création de nouveaux matériaux, dispositifs, produits ou procédés ou de l'amélioration de ceux qui existent. Cette critique n'est pas fondée. En disant que l'IDLS ne représentait pas une nouvelle catégorie de produits, M. Takagaki faisait simplement remarquer que l'IDLS n'était pas un nouveau produit en un sens général, quoique étant fortement personnalisé. Il faisait remarquer que les systèmes d'information en ligne et de saisie de données utilisant des ordinateurs de capacité moyenne comme l'AS/400 avec des terminaux de saisie de données et des programmes personnalisés dans un environnement logiciel de GLAO étaient courants. La critique mentionnée précédemment pourrait avoir été justifiée si l'appelante avait pu établir que l'IDLS était essentiellement, même dans une faible mesure, quelque chose de plus qu'une variation de produits déjà existants. Je ne peux conclure que l'appelante a réussi à établir cela. M. Slonim a dit que certaines « incertitudes » avaient été laissées de côté et que certaines avaient été dissipées à l'aide de « solutions moches ou temporaires » , ce qui ne représente pas nécessairement un progrès technologique.
[44] La dernière critique concernant l'opinion de M. Takagaki se rapportait à la question de la pratique courante. À cet égard, l'appelante faisait remarquer que ce qui constitue une pratique courante dans un domaine technologique ne peut être évalué que par des spécialistes de ce domaine. On a dit que le témoignage de M. Slonim devrait être préféré à celui de M. Takagaki parce que la question devait être déterminée dans le contexte des circonstances du contribuable. Je conviens avec mon collègue le juge Bowman qu'un « progrès technologique au Canada ne cesse pas d'être tel simplement parce qu'il existe une possibilité théorique qu'un chercheur, disons, en Chine, a peut-être fait le même progrès, [...] » [7], mais je ne peux conclure que M. Takagaki n'a pas tenu compte du contexte de l'appelante en arrivant à sa conclusion selon laquelle on avait « tout au long du projet utilisé des produits et services commercialement disponibles ainsi que des méthodes et pratiques courantes de développement de systèmes d'information » .
[45] Pour les motifs susmentionnés, l'appel sera rejeté avec dépens.
Signé à Ottawa, Canada, ce 30e jour d'août 2000.
« Michael J. Bonner »
J.C.C.I.
Traduction certifiée conforme ce 19e jour de mars 2001.
(TRADUCTION FRANÇAISE OFFICIELLE]
Mario Lagacé, réviseur
[TRADUCTION FRANÇAISE OFFICIELLE]
98-1324(IT)G
ENTRE :
C.W. AGENCIES INC.,
appelante,
et
SA MAJESTÉ LA REINE,
intimée.
Appel entendu le 7 février 2000 à Vancouver (Colombie-Britannique) par
l'honorable juge Michael J. Bonner
Comparutions
Avocat de l'appelante : Me Douglas H. Mathew
Avocat de l'intimée : Me Ernest Wheeler
JUGEMENT
L'appel interjeté à l'encontre des cotisations établies en vertu de la Loi de l'impôt sur le revenu pour les années d'imposition 1991, 1992, 1993, 1994 et 1995 est rejeté avec dépens.
Signé à Ottawa, Canada, ce 30e jour d'août 2000.
|
« Michael J. Bonner » |
J.C.C.I.
Traduction certifiée conforme
ce 19e jour de mars 2001.
Mario Lagacé, réviseur
[1] RIS Christie Ltd. c. La Reine, C.A.F., no A-710-96, 21 décembre 1998 (99 DTC 5087).
[2] M. Slonim semblait utiliser le mot « incertitude » pour décrire ce que j'appellerais un défi.
[3] J'ai souligné ce passage parce qu'à mon avis il décrit l'activité maintenant en cause d'une manière exacte, exhaustive et, surtout, brève.
[4] Le soulignement est de moi.
[5] C.C.I., no 97531 (IT) G, 1er mai 1998 (98 DTC 1839).
[6] Affaire précitée.
[7] Affaire Northwest Hydraulic,précitée, à la page 8 (DTC : à la page 1842).