Jugements de la Cour canadienne de l'impôt

MOTIFS DU JUGEMENT

Le juge en chef adjoint BOWMAN

A. Introduction

[1]         Il s'agit d'un appel d'une cotisation établie à l'égard de l'année d'imposition 1993 de Commcorp Financial Services Inc. (Commcorp), l'une des quelques sociétés fusionnées pour constituer l'appelante, appelée auparavant Newcourt Financial Ltd.

[2]         À l'origine, plusieurs questions en litige opposaient les parties, mais elles ont toutes été réglées sauf deux. Après règlement des questions restantes par la Cour, les avocats ont convenu de rédiger un projet de jugement dans lequel toutes les questions en litige seraient réglées.

[3]         Les questions restantes concernent la déduction pour amortissement (DPA) relative au logiciel acquis par Commcorp en 1993. Le ministre du Revenu national a considéré la série d'opérations et chaque opération en faisant partie, par lesquelles Commcorp a acquis le logiciel et l'a loué, en vertu d'un contrat de cession-bail à la personne qui l'avait développé et utilisé dans son entreprise, comme une opération d'évitement au sens de la règle générale anti-évitement (RGAE) et a décidé que, par suite des attributs fiscaux pour Commcorp, celle-ci n'avait pas le droit de réclamer la DPA à l'égard du logiciel.

[4]         À titre subsidiaire, Commcorp a acquis le logiciel auprès d'une personne avec laquelle elle avait un lien de dépendance et le coût, pour elle, devrait être réduit à la juste valeur marchande (JVM) qui, selon l'intimée, n'était pas supérieure à 13 100 000 $.

[5]         L'appelante reconnaît que Commcorp a acquis le logiciel auprès d'une personne avec laquelle elle avait un lien de dépendance, mais elle soutient que, lors de l'acquisition, le logiciel valait 33 091 255 $.

[6]         La Couronne a abandonné les arguments figurant aux sous­-alinéas 13a)(i), (ii) et (iii), soit que le logiciel n'avait pas été acquis par Commcorp, que s'il avait été acquis, il ne l'avait pas été dans le but de tirer un revenu ou que l'opération ou les documents étaient un stratagème.

[7]         Il reste donc à régler les questions de l'application de la RGAE, de la JVM du logiciel et du caractère raisonnable au titre de l'article 67.

B. Les opérations - Le 1^er avril 1993

[8]         Les opérations conclues en avril 1993 sont décrites dans un exposé conjoint partiel des faits (ECPF), auquel sont joints les documents pertinents, soit deux tableaux, les pièces A et B, qui présentent les rapports juridiques et les mouvements de fonds. Ces deux tableaux sont joints aux présents motifs.

[9]         La série d'opérations peut être résumée brièvement.

[10]       BHP New Zealand Steel Limited (BHP) est une société fabriquant de l'acier qui réside en Nouvelle-Zélande. Elle était propriétaire d'application logicielles qu'elle utilisait pour la composante production de son installation intégrée de fabrication de l'acier à Glenbrook, en Nouvelle-Zélande, et pour stocker des données concernant la gestion financière de l'entreprise.

[11]       Commcorp a reçu de MACC and Partners Australian Ltd. une évaluation du logiciel, soit 50 000 000 $NZ. L'équivalent en dollars canadiens était de 33 091 255 $. Pour des raisons de commodité, j'utilise parfois la somme de 33 millions de dollars

[12]       BHP a vendu le logiciel à Macquarie Leasing (NZ) Limited (MLL), filiale de Macquarie Bank Limited (MBL), banque australienne, pour 33 091 255 $CAN, en contrepartie d'un billet à ordre.

[13]       MLL a vendu le logiciel à 1004583 Ontario Ltd. (1004583), société constituée en Ontario à cette fin par les avocats de Commcorp, pour 33 091 255 $, en contrepartie d'un billet à ordre.

[14]       1004583 a loué le logiciel à Eagle Financial and Leasing Services Limited (Eagle), société située aux îles Caïmans et filiale de Barclays Bank PLC (Barclays), banque du Royaume-Uni, et lui a accordé une licence.

[15]       Le bail, d'une durée de 11 ans, expirait le 5 avril 2004. Il prévoyait des options d'achat pouvant être levées le 5 avril 2002 et le 5 avril 2004, pour un montant égal à la valeur actuelle, calculée en 2003, du flux de revenu restant.

[16]       Commcorp a contracté, auprès de Barclays, un prêt de 27 770 896,80 $ garanti par une cession de montants de loyer précis à payer en vertu du bail conclu avec Eagle et par une partie des montants payables en cas de résiliation du bail qui correspondait au solde impayé du prêt à l'époque pertinente. Le seul recours prévu au titre du prêt était les paiements cédés.

[17]       Eagle et MLL ont conclu un sous-bail et un contrat de licence en vertu desquels Eagle sous-louait le logiciel à MLL, et lui octroyait une licence, aux mêmes conditions, ou à peu près, auxquelles elle avait loué le logiciel de 1004583 et obtenu une licence. L'une des différences était que MLL était tenue, à la clôture, de payer d'avance à Eagle le loyer total prévu par le sous-bail et le prix de la première option.

[18]       MLL et BHP ont conclu un sous-sous-bail et un contrat de licence en vertu desquels MLL sous-sous-louait le logiciel à BHP, et lui octroyait une licence, aux mêmes conditions, ou à peu près, que le bail et le sous-bail, sauf que MLL était tenue, à la demande de BHP, d'accepter un paiement préalable de 31 933 061 $ en contrepartie de l'obligation de BHP prévue par le bail.

[19]       1004583 a conclu un contrat avec Commcorp afin de lui vendre le logiciel, le 5 avril 1994, pour 33 091 255 $.

[20]       1004583, Commcorp, Eagle, MLL et BHP, et Whitaker Nominees Limited, société néo-zélandaise (Whitaker), ont conclu un contrat de dépôt entre les mains d'un tiers en vertu duquel BHP devait remettre à Whitaker copie du code source, du code objet et de la documentation sur le logiciel concernant le logiciel en cause, copie du logiciel et l'évaluation originale. La remise de tous ces documents à Whitaker, à titre de tiers convenu, a été reconnue comme la remise du logiciel en vertu des trois contrats de vente et de cession du logiciel (liant BHP à MLL, MLL à 1004583 et 1004583 à Commcorp).

[21]       Commcorp, Barclays et Eagle ont conclu l'entente de soutien Eagle en vertu de laquelle Eagle convenait de verser à Barclays 3 996 708 $. Barclays a également convenu chaque fois qu'un [Traduction] « paiement précis » devenait payable en vertu du bail, de le verser ou de le faire verser par Eagle, à même les produits de l'obligation à l'achat de laquelle elle avait consenti grâce aux 3 996 709 $. Les [Traduction] « paiements précis » étaient les loyers prévus et d'autres montants (notamment les sommes versées en cas de résiliation) payables au titre du bail, sauf dans la mesure où ils n'avaient pas été cédés en garantie en vertu du prêt.

[22]       Barclays a écrit à Commcorp, acceptant de s'assurer du respect, par Eagle, des obligations que lui imposaient les contrats auxquels elle était partie.

[23]       MLL, Eagle, Commcorp et 1004583 ont conclu une entente de coordination en vertu de laquelle les obligations prévues par le bail étaient divisées en « clauses relatives au recours » , que MLL a accepté d'exécuter, et en « clauses restrictives relatives au recours » , que Eagle a accepté d'exécuter. Eagle a donné à MLL, au moyen d'une procuration, le droit d'exercer tous les droits d'Eagle prévus par le bail. Dans le cadre de cette entente, Commcorp a signé un engagement relatif à l'absence de trouble de jouissance dans lequel elle acceptait d'être liée par les modalités du sous-sous-bail même en cas de défaut par Eagle ou MLL en vertu du bail ou du sous-bail, dans la mesure où BHP n'était pas en défaut à l'égard du sous-sous-bail.

[24]       MBL a garanti les obligations de MLL en vertu de diverses ententes.

[25]       Les fonds ont circulé de la façon prévue par les diverses ententes, entre les divers comptes que détenaient les parties chez Barclays, et les opérations ont été closes le 5 avril 1993. Les paragraphes 11 et 12 de l'ECPF résument ce qui est survenu ce jour-là :

[Traduction]

11.        Le 5 avril 1993 (voir la pièce A ci-jointe) :

a)          BHP a cédé et transféré le logiciel à MLL, en vertu du contrat de vente et de cession du logiciel de BHP NZS, et MLL a signé un billet à ordre, en faveur de BHP, de 33 091 255 $ comme contrepartie du prix d'achat payable par MLL pour le logiciel;

b)          MLL a cédé et transféré le logiciel à 1004583, en vertu du contrat de vente et de cession du logiciel de MLL, et 1004583 a signé un billet à ordre, en faveur de MLL, de 33 091 255 $ comme contrepartie du prix d'achat du logiciel;

c)          100483 [sic] a loué le logiciel à Eagle, et lui a octroyé une licence, en vertu du bail;

d)          1004583 a cédé et transféré le logiciel à Commcorp, en vertu du contrat de vente et de cession du logiciel à Commcorp;

e)          Eagle a sous-loué le logiciel à MLL, et lui a accordé une sous-licence, en vertu du sous-bail et du contrat de licence.

Les documents contenus dans les onglets 26 à 50 ont également été signés relativement à ce qui précède.

12.        Le 5 avril 1993, les mouvements de fonds suivants sont survenus :

a)          Barclays a avancé 27 770 896,80 $ à Commcorp, en vertu du prêt;

b)          Barclays a transféré les montants mentionnés dans les directives, conformément aux directives :

(i)          33 091 255 $ de Commcorp à 1004583;

(ii)         1 100 000 $ de Commcorp à MLL;

(iii)        33 091 255 $ de 1004583 à MLL;

(iv)        33 091 255 $ de MLL à BHP;

c)          BHP a versé la somme de 31 933 061 $ à MLL, à titre de paiement préalable des loyers et de l'option d'achat prévus par le sous-sous-bail et le contrat de licence;

d)          MLL a versé la somme de 31 767 604 $ à Eagle, à titre de paiement préalable des loyers et de l'option d'achat prévus par le sous-bail et le contrat de licence;

e)          Eagle a versé à Barclays la somme de 3 996 708 $, conformément à l'entente de soutien avec Eagle;

f)           Barclays a payé l'obligation 3 996 709 $, conformément à l'entente de soutien avec Eagle, obligation qui est venue à échéance le 15 mars 2002, pour 8,13 millions de dollars;

g)          la somme de 27 770 897 $ (31 767 604 $ - 3 996 708 $) est restée en possession d'Eagle, devant servir aux paiements prévus par le bail afin de garantir et de rembourser le prêt.

La pièce B contient un schéma des paiements en espèces versés le 5 avril 1993. La somme de 1 100 000 $ susmentionnée a été versée par Commcorp à MLL à titre d'honoraires relativement à l'opération.

[26]       Il n'est pas nécessaire de résumer les autres démarches officielles prises relatives aux opérations, notamment les avis juridiques. De grands cabinets d'avocats internationaux ont réglé toutes ces questions, avec compétence. Les opérations et les documents sous-jacents représentent des obligations véritables, obligatoires et exécutoires. Ils sont effectivement ce qu'ils étaient censés être.

[27]       Il convient de citer quelques-uns des autres faits énoncés dans l'ECPF parce qu'ils ont été jugés importants par l'une ou l'autre des parties et mentionnés dans la plaidoirie :

[Traduction]

18.        Le prix d'achat du logiciel a été financé par Commcorp grâce aux 27 770 897 $ à emprunter à Barclays et aux 6 420 358 $ provenant de sources internes. Cette somme comprend 1 100 000 $ que Commcorp a versés à MLL à titre d'honoraires relativement à l'opération. Eagle a versé 3 996 000 $ à Barclays. Le solde du paiement préalable est resté en possession d'Eagle.

19.        Avant de conclure l'opération, Commcorp savait que BHP verserait une somme à MLL et que MLL verserait à Eagle une somme suffisante pour couvrir les obligations de Commcorp envers Barclays pendant la durée du prêt.

20.        Commcorp n'avait aucune indication que BHP ou Macquarie avait besoin de fonds. Dans le cadre de cette opération, BHP ou Macquarie n'obtenait pas de fonds de Commcorp.

21.        Le flux monétaire pour Commcorp pendant la durée de l'opération, que la première option d'achat soit levée ou non, est de 1 711 907 $ (comme l'indiquent les annexes I et II de l'onglet 72). Les paiements prévus par le bail et les paiements du principal et des intérêts à verser en vertu du prêt sont énoncés aux annexes de l'onglet 72. Cette annexe indique également les détails des déductions fiscales prévues relativement à la DPA et aux intérêts ainsi que les montants inclus dans le revenu aux fins fiscales.

22.        Dans le calcul de son revenu pour l'année d'imposition 1993 (terminée le 31 décembre 1993), Commcorp a inclus la somme de 34 191 255 $ dans son coût des biens amortissables de catégorie 12 de l'annexe II du Règlement de l'impôt sur le revenu et a déduit la somme de 17 313 740 $ à titre de déduction pour amortissement, en vertu de l'alinéa 20(1)a) de la Loi de l'impôt sur le revenu, dans le calcul de son revenu pour cette année, somme dont le ministre du Revenu national a refusé la déduction dans sa nouvelle cotisation établie à l'égard de l'appelante.

23.        En l'espèce, l'arrangement en cause a été décrit au conseil d'administration de Commcorp (onglet 73) comme un [Traduction] « bail visant un logiciel conclu pour des raisons fiscales qui fournira à Commcorp un abri fiscal de 15 millions de dollars en 1993 et de 15 autres millions de dollars en 1994 » .

24.        Avant de conclure l'opération, Commcorp croyait que Eagle sous-louerait le logiciel à MLL et lui accorderait une licence, et que MLL sous-sous-louerait le logiciel à BHP et lui accorderait une licence. Il était également entendu que BHP et Macquarie paieraient à l'avance leurs obligations prévues par le sous-sous-bail et le contrat de licence et le sous-bail et le contrat de licence respectivement.

25.        L'année suivante, l'appelante a conclu deux autres opérations conçues selon le même modèle, concernant des paiements préalables au locataire qui était une filiale de la banque prêteuse. Dans le procès-verbal de la réunion du conseil d'administration du 21 septembre 1994 (onglet 74), on en parle comme de [Traduction] « baux visant un logiciel avantageux du point de vue fiscal conclus par la société » .

26.        En l'espèce, lorsqu'elle a conclu l'arrangement en cause, Commcorp visait principalement à obtenir la déduction pour amortissement découlant de l'acquisition du logiciel, en ce que la déduction pour amortissement était déductible dans les deux premières années et que les loyers constituaient une créance pendant la durée du bail.

[28]       Je joins sous les cotes I et II les annexes de l'onglet 72 de l'ECPF, car elles illustrent le véritable contexte économique de l'opération. De toute évidence, le principal mobile économique, du point de vue de Commcorp, est le montant déductible aux fins de l'impôt, ce qui n'est pas contesté. On peut présumer que l'opération présentait des avantages fiscaux en Nouvelle-Zélande, pour BHP, mais je ne sais pas exactement lesquels. Ils ne sont pas importants pour l'espèce. Cependant, les annexes indiquent autre chose - soit la circularité essentielle de l'opération. On a introduit 33 millions de dollars au début, somme qui est revenue à son point de départ. La seule chose qui n'a pas bougé est le logiciel. Il est demeuré là où il était au départ - chez BHP. Personne - Commcorp, la banque, Eagle, BHP ou quiconque d'autre dans la chaîne - n'a couru le moindre risque. Cette somme de 33 millions de dollars était fondée sur une évaluation faite par MCC, entreprise sélectionnée par MBL, laquelle avait intérêt à voir l'opération se conclure en raison de la commission de 1 100 000 $ que MLL devait toucher. L'évaluation de 33 millions de dollars avait peu de rapport avec le coût réel du développement du logiciel, qui se situait plus dans les 11 millions de dollars.

[29]       Il s'avère que les chiffres importaient peu parce que l'argent est revenu à son point de départ. Je traiterai de ce détail plus à fond lorsque je discuterai la JVM du logiciel.

[30]       La troisième raison pour laquelle les annexes sont importantes est que celles-ci illustrent la difficulté de déterminer les attributs fiscaux de façon à supprimer l'avantage fiscal « de façon raisonnable dans les circonstances » . En l'espèce, le ministre a déterminé qu'il s'agit d'une opération d'évitement qui n'est pas visée par le paragraphe 245(4). L'attribut fiscal est la DPA visant le logiciel. Par conséquent, selon le raisonnement, la DPA devrait être supprimée, mais tous les autres attributs survenus pendant la durée de l'opération, de 1995 à 2004, ne sont pas touchés. Il faut le reconnaître, la RGAE est un instrument imprécis, mais même s'il n'est pas un scalpel, il n'est pas non plus une masse.

[31]       Les revenus et les déductions élevés prévus au cours des années 1995 à 2004 sont sans doute fondés sur un coût de 33 millions de dollars et la déduction fiscale qui en résulte. La RGAE semble avoir été adoptée afin de permettre au ministre de lutter contre les stratagèmes d'évitement fiscal trop audacieux dont les objectifs fiscaux éclipsent de loin les buts commerciaux. Elle ne devrait pas être utilisée pour pénaliser les contribuables qui se livrent à des stratagèmes d'évitement fiscal qui ne plaisent pas au ministre, en supprimant l'aspect avantageux du point de vue fiscal d'une opération d'évitement mais en ne touchant pas aux aspects préjudiciables.

[32]       J'examine en premier lieu la question de la JVM du logiciel. L'appelante a produit en preuve deux évaluations. La première a été préparée par M. Geoffrey H. Cooper (évaluation de MACC), avant la conclusion du bail, et la seconde, par M. Peter Hatges, de KPMG. La Couronne n'a pu examiner le logiciel avant le procès parce qu'il n'était pas disponible. Lorsqu'il l'est devenu, j'ai ajourné le procès pour permettre aux experts de la Couronne de l'examiner, mais l'état dans lequel il se trouvait après 10 ans, compte tenu de toutes les modifications qu'une utilisation continue pendant cette période comportait, a apparemment empêché toute détermination significative de la valeur qu'il avait en avril 1993. La Couronne s'est donc fondée sur des rapports préparés par M. Howard E. Johnson, de Campbell Valuation Partners Limited, dans lesquels celui-ci formule des observations sur les rapports de l'expert de l'appelante.

[33]       Avant d'analyser les rapports, précisons ce que nous tentons de faire ici. Commcorp a acheté le logiciel dans le cadre d'une opération entre parties ayant un lien de dépendance, et le prix visé à l'article 69 est donc réputé la JVM. Le but premier de l'achat était d'obtenir une déduction fiscale. Il ne faut donc pas s'attendre à ce qu'une partie comme Commcorp ou toute autre personne faisant partie de la chaîne, par exemple MLL, 1004583 ou Eagle, ou naturellement BHP, se préoccupe de conclure une opération en fonction du caractère commercial inhérent qu'elle présente, parce qu'il n'y avait aucun risque commercial pour personne. En l'espèce, il n'est pas question d'un terrain ou d'actions d'une société. Le bien à évaluer est un progiciel unique, ayant un but spécial, développé par BHP, à ses propres fins, en vue d'exploiter son aciérie en Nouvelle-Zélande. Sa valeur véritable pour BHP, dans la conduite de ses affaires, est inconnue. Elle pourrait varier selon un écart d'une importance indéterminée, d'après les critères utilisés. La définition classique de la JVM est trop bien connue pour être reprise ici, mais précisons qu'il faut supposer un vendeur et un acheteur hypothétiques, qui n'ont aucun lien de dépendance, qui sont connaissants et astucieux et qui aimeraient conclure une opération mais ne sont pas désespérés, et il faut déterminer quel type de marché ces négociateurs hypothétiques sont prêts à conclure. Comme le vicomte Simon l'a dit dans l'arrêt Gold Court Selection Trust Limited v. Humphrey (Inspector of Taxes), [1948] A.C. 459, p. 473 :

[Traduction] ... si le bien est difficile à évaluer mais s'il a néanmoins une valeur pécuniaire, il faut procéder à la meilleure évaluation possible. L'évaluation est un art, et non une science exacte. La certitude mathématique n'est pas nécessaire, ni certainement possible. Il revient aux commissaires de formuler leur estimation en attribuant une valeur pécuniaire au bien, et il s'agit là d'une conclusion de fait à tirer d'après la preuve dont ils sont saisis.

[34]       En l'espèce, il est difficile de déterminer la JVM du logiciel parce qu'il n'est pas établi que le logiciel, conçu et développé précisément en vue de l'exploitation d'une aciérie particulière en Nouvelle-Zélande, sera probablement acheté et vendu sur le marché libre. À mon avis, il est difficile de croire qu'une aciérie quelque part au monde paierait quelque chose comme 33 millions de dollars pour un logiciel conçu et développé pour l'aciérie de BHP, en Nouvelle-Zélande. Le caractère particulier du logiciel est illustré par la section 3.0 du rapport de MACC, dont voici le texte :

[Traduction]

3.0        L'environnement informatique de BHP NZS

BHP NZS est le plus gros producteur d'acier de la Nouvelle-Zélande, employant quelque 1 900 personnes. La société exploite une aciérie intégrée composée d'une installation de production de fonte, d'une aciérie, d'une usine de traitement, de machines de coulée continue, d'un laminoir à bandes à chaud, d'un laminoir à froid, d'une installation de fabrication de tubes et de tuyaux ainsi que de lignes d'enduction de bandes en continu. La société fabrique l'acier selon une méthode différente de celle de la plupart de ses concurrents, en ce qu'elle utilise, comme matière première, du sable ferrugineux plutôt que du minerai de fer. Elle exporte la majorité de sa production (environ 66 p. 100) et doit donc être concurrentielle sur le marché international. Elle y arrive en jouant le rôle de fournisseur spécialisé et en se différenciant des gros producteurs par sa souplesse quant à la quantité d'un produit qu'elle peut fabriquer, et en assurant un service à la clientèle efficace. La capacité de modifier ses calendriers et de produire de petites quantités sur commande de façon économique sont critiques à sa capacité concurrentielle.

BHP NZS est relativement progressive dans sa mise en oeuvre de systèmes informatisés de gestion des processus et de systèmes opérationnels. La société a dressé un plan opérationnel des services informatiques qui énonce la façon dont CSD appuiera les activités de la société, depuis la conversion de la matière première jusqu'à l'expédition du produit fini. Le plan détermine les six niveaux d'informatisation suivants :

            Niveau 5          -            Système d'entreprise

            Niveau 4          -            Support opérationnel

            Niveau 3          -            Gestion des processus

            Niveau 2          -            Contrôle des processus       

            Niveau 1          -            Contrôle en temps réel

            Niveau 0          -            Capteurs et activateurs

Le plan précise et décrit l'importance de l'intégration entre chaque niveau. Toute l'organisation semblait bien connaître ce plan et y adhérer. En fait, CSD était considéré comme un élément critique de la réalisation globale des plans stratégiques et annuels de l'organisation.

Les systèmes d'information opérationnels et informatiques ont eu la faveur dans le passé, mais à l'heure actuelle, l'accent est mis sur la productique, qui est l'intégration horizontale et verticale des systèmes, ce qui donne à chaque niveau de gestion accès à des données clés permettant ainsi la prise de décisions, l'atteinte de l'optimisation et la réalisation constante d'améliorations.

On prévoit que la mise en oeuvre complète de tous les systèmes de productique entraînera d'autres réductions de coûts, par exemple par une réduction de l'inventaire et une diminution des coûts des processus, en raison d'une coordination accrue entre chaque usine.

La méthode de développement des applications est axée sur une participation intense des utilisateurs à toutes les activités de développement - en fait, pour les projets de développement des systèmes, l'équipe est intégrée au point où il est difficile de faire la distinction entre utilisateurs et employés de CSD. Environ 55 employés de CSD participent officiellement au projet, mais au moins 150 employés de la société participent au développement des applications et à titre de soutien.

La société a adopté un « système ouvert » et appliqué la méthode utilisée pour les processus au développement des applications à l'aide de divers langages (LINC, ORACLE, FORTRAN) exploités sous de multiples plates-formes matérielles (UNISYS, IBM, DEC, SUN). Un réseau à l'échelle du site à fibre optique relie tous les processeurs et facilite l'intégration des données.

[35]       Je n'ai pas reproduit la section 4.0 ([Traduction] Évaluation fonctionnelle et technique du logiciel), qui est très longue, sauf pour un bref extrait.

[Traduction]

Par suite de notre examen, nous avons formulé les conclusions générales suivantes relatives à l'applicabilité et à la maintenabilité du logiciel :

·         Trois langages de programmation ont été utilisés pour le développement des applications, mais chaque langage est efficace du point de vue opérationnel et bien supporté. Le choix du langage de programmation était fondé sur la plate-forme logicielle, la nature du traitement et les orientations technologiques probables futures.

·         On a mis beaucoup l'accent sur la participation des utilisateurs et l'acceptation par les utilisateurs de leur responsabilité, dans la plupart des étapes du développement du logiciel. Il s'agissait d'une coopération étroite entre CSD et les utilisateurs.

·         On a déployé des efforts considérables afin de faire correspondre les exigences des application et les besoins opérationnels. Il s'agissait d'un facteur important de la livraison d'applications efficaces, utiles et fonctionnelles.

·         Le code du logiciel semble être écrit et structuré de façon efficace afin que les tâches de développement et de maintenance des applications permettent des efficiences.

·         L'application d'un système « ouvert » a facilité l'intégration des applications en permettant la transmission des données entre les applications, peu importe la plate-forme technique.

·         De nombreuses fonctions utilisateur ont été intégrées au logiciel afin d'appuyer les activités opérationnelles.

·         Le logiciel a été développé à l'aide de techniques de programmation modulaire qui facilitent la modification et l'amélioration du système.

·         Le logiciel est bien documenté sur le plan technique et du point de vue de l'utilisateur.

·         Bien qu'elles ne soient pas documentées de façon officielle, les normes et méthodes de l'industrie en vigueur lors du développement semblent avoir été utilisées lors du processus de développement.

·         Le logiciel semble bien maintenu grâce à une nouvelle fonctionnalité qui résulte de l'interaction entre les utilisateurs et des demandes d'améliorations et de modifications.

·         Le logiciel a été développé selon un plan stratégique officiel qui identifie les applications discrètes et l'importance de la relation intégrale (verticale et horizontale) avec d'autres applications.

[36]       Ces extraits ainsi que d'autres figurant dans le rapport illustrent l'excellence du logiciel dans son application à l'entreprise de BHP. J'accepte cette conclusion, mais elle démontre que, quelle que soit la valeur du logiciel pour BHP dans l'exploitation de son entreprise, celui-ci ne pouvait être facilement adapté à l'entreprise de quelqu'un d'autre. Sa valeur même pour BHP est inversement proportionnelle à sa valeur pour une autre aciérie et affecte donc le prix que le logiciel pourrait aller chercher sur le marché libre. En d'autres termes, toute société désirant installer un système informatique pour exploiter son aciérie trouverait qu'il coûte moins cher et qu'il est plus facile de développer son propre système plutôt que de verser 33 millions de dollars ou tout autre montant pour le système de BHP, puis d'essayer de l'adapter. Plus le système est adapté précisément à l'entreprise de BHP et plus sa valeur commerciale est grande pour BHP, moins il est utile ou précieux pour un autre utilisateur.

[37]       Aux prises avec la difficulté de trouver un marché libre pour le logiciel, le rapport de MACC a retenu une méthode d'évaluation qui tient compte du coût de remplacement et des efforts déployés dans le passé. Voici un extrait du rapport :

[Traduction] Aux fins des présentes, selon nos conclusions, la valeur du logiciel représente en tout temps le prix exprimé en argent pouvant être obtenu pour le logiciel, sur un marché libre de toutes restrictions, entre des parties averties et prudentes, n'ayant aucun lien de dépendance et agissant de leur plein gré.

Cette phrase, dont la formulation peut varier légèrement, figure dans pratiquement tous les rapports d'évaluation. C'est la définition traditionnelle de la JVM utilisée par les évaluateurs. Je ne m'y oppose pas comme définition, mais le rapport de MACC ne cherche pas à déterminer cet élément. Aucun marché libre de toutes restrictions pour un logiciel de ce genre n'a été identifié. C'est pourquoi il faut recourir au coût de remplacement comme seule méthode d'évaluation.

[38]       Dans la décision Aikman v. R., [2000] 2 C.T.C. 2211, confirmée par [2002] C.T.C. 147 (C.A.F.), j'ai exprimé de sérieuses réserves sur l'utilisation du coût de remplacement afin de déterminer la JVM et j'ai examiné un certain nombre de décisions dans lesquelles les tribunaux devaient déterminer la JVM de biens pour lesquels il n'existait aucun marché libre. Dans cette décision, il s'agissait d'un prototype désassemblé d'un véhicule plus léger que l'air appelé cyclogrue. Toutefois, j'avais été saisi de la preuve d'un achat récent entre parties n'ayant aucun lien de dépendance. Je ne considère pas la série d'achats pour 33 millions de dollars comme une preuve de la JVM.

[39]       En l'espèce, les experts des deux parties ont utilisé le coût de remplacement comme méthode acceptable pour déterminer la JVM et, ainsi que l'a dit le vicomte Simon dans Gold Coast, il faut faire de son mieux. En outre, le coût de remplacement d'un bien développé pour être utilisé dans l'exploitation d'une entreprise peut constituer une preuve de la JVM en l'absence d'un marché libre, alors que le coût de remplacement d'un artefact n'ayant aucune fonction commerciale n'est de toute évidence par un critère fiable.

[40]       Puisque tous les experts conviennent que le coût de remplacement est un critère acceptable et que je n'ai rien d'autre sous la main, j'examinerai la preuve de la valeur en fonction de cet élément.

[41]       Voici un extrait du rapport de MACC :

[Traduction] Nous nous sommes fait une opinion sur la valeur du logiciel à l'aide des méthodes d'évaluation suivantes :

·         coût de remplacement - la valeur calculée comme le coût actuel engagé pour remplacer le logiciel, compte tenu de la conception, du développement ainsi que de la formation des utilisateurs et de la documentation;

·         effort déployés dans le passé - les efforts déployés par BHP NZS pour concevoir, développer et mettre en oeuvre le logiciel.

Pour déterminer la valeur du logiciel, nous avons retenu une méthode à deux volets :

·         estimation de la valeur du logiciel en fonction de méthodes quantitatives liées au coût de remplacement;

·         ajout d'un facteur au coût de remplacement fondé sur la connaissance intellectuelle perçue, les compétences spéciales nécessaires pour concevoir et développer le logiciel, son importance pour les activités opérationnelles du groupe et sa contribution aux gains.

[42]       Dans son témoignage, M. Cooper a affirmé que les mots [Traduction] « et mettre en oeuvre » devaient être supprimés. Je suis d'accord. Le coût de mise en oeuvre ne fait pas partie du coût de remplacement. Cependant, le reste du témoignage de M. Cooper n'appuie pas l'affirmation selon laquelle il n'a pas inclus le coût de mise en oeuvre.

[43]       Pour déterminer le coût de remplacement du logiciel, M. Cooper a utilisé plusieurs méthodes :

(i)          Lignes de code Il faut compter le nombre de lignes du code opérationnel (ou instructions du programme) et appliquer un nombre moyen de lignes exécutes par jour pour arriver à un total de jours-personnes pour cette application.

(ii)         Temps de développement Il faut compter le temps total nécessaire pour exécuter toutes les activités et les tâches liées au développement du logiciel. M. Cooper se reporte à un ouvrage de Capers Jones, Applied Software Measurement, où l'auteur fait observer que les systèmes de suivi des entreprises omettent accidentellement de 30 à 70 p. 100 des efforts consacrés au développement des produits logiciels. Il a donc fait des rajustements à la hausse pour en tenir compte.

(iii)        Analyse des points fonctionnels Les points fonctionnels sont les sommes pondérées de cinq ou six facteurs comme les algorithmes, les entrées, les sorties, etc., dont on détermine le nombre qui peut être exécuté par mois-personne.

(iv)        Rétroconversion Il s'agit simplement d'une méthode de vérification de l'analyse des points fonctionnels en remontant vers le code source.

(v)         Formules d'estimation Application de formules au nombre de lignes de code produites.

Je n'examine pas plus avant cette méthode parce que M. Cooper ne la considérait pas comme fiable et qu'il l'a rejetée. Je peux voir pourquoi. Elle a donné un coût de remplacement de 58,7 millions de dollars NZ, soit 10 millions de plus que la méthode donnant le chiffre suivant le plus élevé.

[44]       Voici le résultat de l'analyse de M. Cooper grâce à diverses méthodes :

                                    Lignes de code                     -            47 000 000 $NZ

                                    Temps de développement -            41 100 000 $NZ

                                    Rétroconversion                     -            52 000 000 $NZ

[45]       Après avoir énoncé ces chiffres, M. Cooper a fait certains commentaires sur les écarts. Voici l'une de ses observations :

[Traduction] Les méthodes utilisées pour les applications présentent des écarts de valeur, ce qui démontre la volatilité des facteurs utilisés dans les calculs.

Il conclut que le coût de remplacement actuel du logiciel est de 47 millions de dollars NZ. Il y ajoute un montant de 3 millions de dollars NZ en raison de l'avantage concurrentiel que donne l'utilisation du logiciel.

[46]       En toute franchise, il n'est pas nécessaire d'avoir l'aide d'un expert pour voir la fausseté de ce raisonnement. Si l'on détermine le coût de remplacement, on le fait selon la meilleure méthode possible. On n'ajoute pas au coût de remplacement déterminé un pourcentage arbitraire fondé sur un facteur non pertinent qui concerne l'excellence du produit.

[47]       Avant de passer au rapport de réfutation préparé par le témoin expert de l'intimée, j'aimerais traiter d'un élément de preuve qui saute aux yeux. Le 16 mars 1993, un avocat représentant BHP a envoyé une lettre au Commissioner of Inland Revenue de la Nouvelle-Zélande, énonçant les coûts de développement de chaque application. Voici les chiffres figurant dans cette lettre, ainsi que ceux donnés dans le rapport de MACC (ils étaient reproduits dans le rapport de M. Johnson) :

[48]       Le rapport de MACC renvoie à l'ouvrage de Capers Jones, Applied Software Measurement, selon lequel les systèmes de suivi de la majorité des sociétés n'enregistrent pas entre 30 et 70 p. 100 des efforts réels consacrés aux logiciels. Ces pourcentages ne s'appuient sur rien et peuvent être des estimations arbitraires, mais acceptons-les et nous verrons où elles nous mènent.

[49]       Si nous ajoutons le pourcentage le plus faible et le pourcentage le plus élevé des efforts omis aux chiffres donnés aux autorités fiscales néo-zélandaises, soit 11 190 000 $NZ, nous obtenons 14 587 000 $NZ et 19 023 000 $NZ respectivement, soit 9 627 204 $CAN et 12 589 421 $CAN.

[50]       Je ne considère pas ce calcul comme une évaluation indépendante, mais il indique à quel point le rapport de MACC est exagéré. En outre, il correspond aux chiffres du rapport de M. Johnson.

[51]       Les critiques formulées par M. Johnson à l'égard du rapport de MACC sont précises et détaillées. Ses conclusions sont résumées dans une lettre envoyée à l'avocat de l'intimée.

[Traduction] En résumé, selon notre examen et notre analyse, à notre avis, l'évaluation faite par MACC dans son rapport, soit 50 millions de $NZ (environ 33 millions de $CAN), concernant la juste valeur marchande du logiciel, à la date de l'évaluation, est probablement surestimée de beaucoup. Comme l'explique plus en détail l'annexe A de la présente lettre, voici les raisons sur lesquelles nous nous fondons :

·       une lettre envoyée au Commissioner of Inland Revenue Department de la Nouvelle-Zélande, datée du 16 mars 1993, dans laquelle BHP New Zealand Steel (BHP NZS) estime le coût de développement du logiciel à 11 190 000 $NZ (environ 7,4 millions de $CAN);

·       des éléments précis du rapport de MACC selon lesquels la valeur établie est surestimée. Voici ces éléments :

ü       l'inclusion du temps de mise en oeuvre et de formation dans le coût de remplacement, facteurs qui ne font pas partie du coût de remplacement du programme lui-même, d'après Commcorp Financial Services Inc. (Commcorp). Ces coûts peuvent représenter entre 20 et 35 p. 100 du temps total consacré au projet,

ü       le taux salarial quotidien de 700 $NZ retenu par MACC, qui peut être surestimé de 20 à 30 p. 100,

ü       le compte en double des frais généraux relativement au temps de gestion et d'administration, qui peuvent surestimer le rajustement pour la [Traduction] « participation du personnel n'appartenant pas au CSD » de 5 à 10 p. 100,

ü       le compte en double du temps de développement du logiciel relativement au [Traduction] « code à usage général » pour certaines applications, ce qui peut surestimer la valeur du logiciel d'environ 2 millions de $NZ (environ 1,3 million de $CAN),

ü       l'application d'une prime « facteur commercial » qui peut surestimer la juste valeur marchande du logiciel, pour Commcorp, de 3 millions de $NZ (environ 2 millions de $CAN).

Après les rajustements apportés en raison des erreurs et des incohérences apparentes du rapport de MACC fondés sur notre analyse, la juste valeur marchande du logiciel, à la date de l'évaluation, est réduite pour se situer entre environ 18,5 millions de $NZ et 27,3 millions de $NZ, soit environ 12 à 18 millions de $CAN.

Enfin, malgré les rajustements pouvant être appropriés comme l'indique ce qui précède, les chiffres établis dans le rapport de MACC, selon lesquels la valeur résiduelle du logiciel, neuf ans après la date d'évaluation, est de 35 p. 100 de la juste valeur marchande initiale (soit 17,5 millions de $NZ ou environ 11,6 millions de $CAN), sont probablement de beaucoup surestimés également.

[52]        Il appuie ces conclusions sur les annexes jointes à la lettre. Je ne les reproduis pas aux présentes, sauf pour le calcul ci-dessous. Selon moi, M. Johnson était un témoin impressionnant, et j'accepte ses conclusions. Voici son nouveau calcul de la JVM du logiciel, qu figure à l'annexe 2 :

[Traduction]

Annexe 2

Nouveau calcul de la juste valeur marchande du logiciel

[53]        Selon le rapport de MACC, la valeur résiduelle du logiciel, à la fin des neuf ans, est de 35 p. 100 de sa JVM en 1993. L'invraisemblance de cette affirmation est illustrée dans le rapport de M. Johnson par l'extrait suivant :

[Traduction]

Détermination de la valeur résiduelle

Selon le rapport de MACC, la valeur résiduelle du logiciel, à la fin des neuf ans, est de 35 p. 100 de sa « valeur estimative » (soit 17,5 millions de $NZ).

Pour déterminer la valeur résiduelle du logiciel, MACC présume (à la section 8.0) que le logiciel ne sera pas maintenu (ou modifié par Commcorp). À l'inverse, dans la section 10.0, MACC affirme qu'[Traduction] « une grande partie du logiciel est 'de technologie récente'; par conséquent, pour conserver son avantage concurrentiel et sa valeur, le logiciel doit être continuellement modifié et amélioré pour tenir compte des nouvelles exigences et des nouveaux besoins commerciaux » . Il semble donc peut réaliste de penser que le logiciel conservera une partie importante de sa valeur initiale (35 p. 100) neuf ans après la date d'évaluation, sans maintenance ou sans amélioration, alors que ces éléments sont considérés comme critiques par MACC.

Une valeur résiduelle de 35 p. 100 après neuf ans sous-entend un taux composé moyen de « dépréciation physique » d'environ 11 p. 100 par année pendant cette période, ce qui, en l'absence d'une maintenance et d'améliorations appropriées, illustre encore plus l'invraisemblance de l'hypothèse de MACC concernant la valeur résiduelle. Par voie de comparaison, à la section 11.0, MACC soutient que la valeur résiduelle du logiciel, à la fin de sa durée de vie restante (de 12,75 à 12,8 ans après la date d'évaluation, selon MACC), sera d'environ 5 p. 100 de sa valeur à la date d'évaluation (en dollars constants). Par conséquent, MACC a supposé que la juste valeur marchande du logiciel diminuera selon un taux composé annuel moyen d'environ 11 p. 100, de 1993 à 2002, mais d'environ 40 p. 100, de 2002 à la fin de 2005.

[54]       Je suis d'accord. L'idée qu'un logiciel développé en 1993 afin d'exploiter une aciérie conserverait, après neuf ans, 35 p. 100 de sa valeur me semble bien au-delà de la réalité. Le fait que la Couronne n'a pu, en 2003, déterminer la JVM du logiciel en raison des gros changements qu'il a subis pendant dix ans illustre son inutilité en l'absence d'une mise à niveau constante. Il est notoire que tout logiciel devient désuet très rapidement, et la preuve produite en l'espèce le confirme.

[55]       Même en appliquant le pourcentage peu réaliste de 35 p. 100 à l'estimation de M. Johnson, soit entre 12 et 18 millions de $CAN, nous arrivons toujours à des chiffres allant de 4 200 000 $ à 6 300 000 $. Cela me semble très élevé. De façon réaliste, je ne crois possible de justifier un pourcentage supérieur à 15 p. 100 de la JVM en 1993, et ce chiffre est probablement généreux.

[56]       Le propre expert de la Couronne nous donne une JVM, en 1993, allant de 12 à 18 millions de $CAN. Je ne suis pas tenu d'accepter cette opinion ou toute autre opinion d'expert, et je crois que les coûts réels de développement du logiciel fournis aux autorités fiscales de la Nouvelle-Zélande sont une indication aussi fiable de la JVM de ce bien que toute autre, du moins comme point de départ. Je pense donc que le chiffre de 18 millions de dollars est trop élevé.

[57]       Quant aux efforts omis allant de 30 à 70 p. 100, suggéré par Capers Jones, 30 p. 100 peut être un chiffre réaliste, mais le facteur de 70 p. 100 appliqué au chiffre de BHP rend celui-ci plus ou moins équivalent à ce que Johnson propose, soit 12 millions de dollars. Je crois qu'il est juste de donner aux appelants le bénéfice du chiffre le plus élevé, ce qui donne une JVM de 13 100 000 $. J'arrive à ce chiffre en ajoutant 70 p. 100 à 7 405 823 $, l'équivalent en dollars canadiens de 11 190 000 $NZ, pour en arriver à 12 589 899 $CAN, arrondi à 13 100 000 $CAN, qui est le chiffre figurant dans la réponse à l'avis d'appel. Ce montant se situe dans l'écart proposé par M. Johnson. Il y a donc importante convergence d'opinions relativement à ces calculs - le chiffre figurant dans la réponse de la Couronne, l'écart proposé par le témoin de la Couronne et le chiffre établi grâce aux propres coûts enregistrés par BHP, plus l'ajout du pourcentage supérieur des efforts omis suggéré par Capers Jones.

[58]       Je peux traiter rapidement du rapport de KPMG. Le loyer payable en vertu du bail du logiciel par 1004583 à Eagle se fonde sur l'évaluation de 33 millions de dollars de MACC. KPMG n'évalue pas le logiciel, estimant plutôt le bail selon les loyers qui, eux-mêmes, se fondent sur une évaluation qui, à mon avis, est trop élevée d'environ 20 millions de dollars. Si on commence par une valeur de 33 millions de dollars, si l'on fonde les loyers sur ce chiffre tout en sachant que l'argent reviendra à son point de départ, il n'est pas étonnant d'arriver à une valeur, pour le bail, équivalente à 33 millions de dollars.

[59]       En commençant avec 100 millions de dollars et en fondant les loyers sur ce montant, KPMG aurait pu évaluer les flux monétaires actualisés à 100 millions de dollars et, par conséquent, la valeur du logiciel et du bail, à ce montant. M. Johnson a fait observer ce qui suit au sujet du rapport de KPMG :

[Traduction]

Toutes les sommes figurant dans cette lettre sont exprimés en dollars canadiens.

À notre avis, l'évaluation faite par KPMG dans son rapport, soit environ 34 millions de dollars, concernant la juste valeur marchande du logiciel, à la date de l'évaluation, n'est pas corroborée. Voici les principales raisons sur lesquelles nous nous fondons :

·         KPMG n'examine pas précisément la valeur du logiciel, mais plutôt celle de la convention de bail relative au logiciel. KPMG suppose que son calcul de la valeur actuelle des paiements de location du logiciel peut être considérée comme la juste valeur marchande de celui-ci. Selon la portée de son examen, il ressort à l'évidence que KPMG n'a pas exécuté une évaluation valable du logiciel lui-même, ce qui lui aurait permis d'estimer de façon raisonnable la juste valeur marchande de celui-ci, indépendamment du bail;

·         la méthode adoptée par KPMG représente un calcul circulaire. Les paiements de location ont été établis en fonction du prix d'achat du logiciel, soit environ 33 millions de dollars, lequel était à son tour lié au rapport préparé par MACC Partners Australia Limited (MACC), daté du 5 avril 1993 (rapport de MACC). Par conséquent, il n'est pas étonnant que le calcul de la valeur actuelle des paiements de location exécuté par KPMG corresponde plus ou moins au prix d'achat. Si ce n'était pas le cas, il représenterait, pour le locateur ou le locataire, une possibilité de profit par arbitrage. La méthode retenue par KPMG ne sert donc qu'à vérifier l'exactitude mathématique des paiements de location. Elle ne permet pas de déterminer si la juste valeur marchande du logiciel sur laquelle les paiements de location se fondent est raisonnable. Comme l'explique notre lettre du 11 avril 2003 contenant nos commentaires sur le rapport de MACC, à notre avis, l'estimation de la juste valeur marchande du logiciel, soit environ 33 millions de dollars, effectuée par MACC est probablement surestimée de beaucoup. Par conséquent, la tentative de KPMG d'attribuer la valeur actuelle des paiements de location à la juste valeur marchande du logiciel sert à renforcer les erreurs commises par MACC dans sa détermination de la juste valeur marchande du logiciel;

·         le taux d'escompte de 8,64 p. 100 retenu par KMPG représente un taux de rendement presque sans risque. Il peut être approprié pour l'évaluation du bail, mais étant donné la certitude des paiements de location, il ne représente pas un taux de rendement raisonnable permettant de déterminer la juste valeur marchande du logiciel lui-même. Les taux de rendement commerciaux nécessaires au développement et à la vente des programmes privés complexes sont de beaucoup supérieurs aux taux de rendement sans risque étant donné les risques inhérents de ces activités. Si KPMG avait adopté un taux de rendement commercial reflétant les risques du logiciel lui-même, son calcul de la juste valeur marchande du logiciel aurait été de beaucoup inférieur à 34 millions de dollars.

[60]       Je suis d'accord avec ces conclusions. À mon sens, il est artificiel de fonder une évaluation sur les flux monétaires actualisés prévus par un bail alors que les loyers eux-mêmes se fondent sur une évaluation excessive et que les montants de loyer importent peu parce qu'ils reviennent finalement, sous une forme ou une autre, à leur point de départ.

[61]       Pendant la plaidoirie, l'avocat de l'appelante a utilisé une analogie, soit deux immeubles identiques, l'un à côté de l'autre, dont un est complètement loué, selon des baux à long terme, à des locataires de premier ordre comme des ministères provinciaux ou fédéraux, et l'autre, selon des baux à court terme, à des hippies et à des beatniks. Il affirme que le premier immeuble commandera un prix beaucoup plus élevé que le deuxième. Nul doute qu'il a raison, mais l'analogie ne tient pas. Dans le cas des deux immeubles, les baux ont été négociés sur le marché libre. En l'espèce, le bail était un simple lien dans un circuit fermé.

[62]       Le rapport de KPMG confirme l'exactitude mathématique de l'arrangement, mais il ne prouve rien quant à la JVM.

[63]       Dans le reste des présents motifs, je considère que la JVM du logiciel, au 5 avril 1993, était de 13 100 000 $. Il en résulte, en vertu de l'article 69, que Commcorp, qui a acquis le logiciel auprès de 1004583 dans le cadre d'une opération entre parties ayant un lien de dépendance, a payé 13 100 000 $. Je ne me prononce pas sur la question des honoraires de 1 100 000 $ versés à MLL. Commcorp a inclus cette somme dans les 34 191 255 $ qu'elle a affirmés être le coût en capital de ce logiciel. Aucun argument distinct n'a été avancé sur ce sujet. Puisque les parties rédigeront le jugement formel, elles peuvent, quoi qu'il en soit, régler ce point ou, à défaut d'une entente, me demander de le régler.

[64]       Il reste la question du caractère raisonnable en vertu de l'article 67 et la RGAE prévue par l'article 245.

[65]       Dans certains cas, l'article 67 peut avoir le même effet dans le cadre d'une opération entre parties sans lien de dépendance, que l'article 69 dans le cadre d'une opération entre parties ayant un lien de dépendance. En général, il n'est pas raisonnable de verser un montant supérieur à la JVM pour un bien, ce qui s'avère dans le cas où le payeur a un lien de dépendance avec le vendeur ou non. L'article 69 prévoit un mécanisme automatique visant à réduire tout prix excessif à la JVM dans le cas où les parties ont un lien de dépendance. Dans le cas où les parties n'ont pas un lien de dépendance, l'article 67 ne s'applique pas automatiquement. En l'espèce, cependant, cela est supposé dans l'application de l'article 69. Autrement dit, l'article 67 peut, du moins en l'espèce, n'ajouter rien d'autre que ce que l'article 69 avait déjà fait.

[66]       Qu'en est-il de la RGAE? L'application de la RGAE exige la prise de certaines mesures. La RGAE est une arme de dernier recours à n'utiliser que lorsqu'une opération, ou une série d'opérations, perçue comme ayant pour objet l'évitement fiscal fonctionne, c'est-à-dire qu'elle atteint le résultat fiscal voulu. Si l'opération ne fonctionne pas en dehors du cadre de la RGAE, il n'y a pas lieu d'invoquer la RGAE. Si elle fonctionne, il faut ensuite déterminer s'il s'agit d'une opération d'évitement donnant lieu à un avantage fiscal qui devrait être supprimé. Avant de déterminer la méthode de suppression de l'avantage fiscal « de façon raisonnable dans les circonstances » , il faut décider si l'on peut considérer que l'opération entraîne, directement ou indirectement, un abus dans l'application des dispositions de la Loi lue dans son ensemble, compte non tenu de l'article 245. S'il est décidé que le paragraphe (4) n'exclut pas l'application du paragraphe (2), il faut déterminer les attributs en vertu du paragraphe (2). Dans l'application du paragraphe (2), le paragraphe (5) présente une liste longue, mais non exhaustive, des solutions possibles.

[67]       En vertu du paragraphe (7), les attributs fiscaux ne peuvent être déterminés que par avis de cotisation, de nouvelle cotisation ou de cotisation supplémentaire, ou par avis d'un montant déterminé.

[68]       Dans le cas d'un appel d'une cotisation dans le cadre de laquelle la RGAE est appliquée, la Cour a le droit de tenir compte de chacun des éléments susmentionnés. Si elle considère que la RGAE s'applique, elle a le droit de décider si la détermination des attributs fiscaux par le ministre est appropriée et, si elle conclut par la négative, elle peut substituer sa propre décision. L'article 245 ne donne au ministre aucun pouvoir discrétionnaire pour décider soit de l'application de la RGAE soit de la mesure réparatrice appropriée à prendre. Par conséquent, dans le cadre d'un appel d'une cotisation établie en vertu de l'article 245, les pouvoirs de la Cour sont au moins aussi importants que ceux du ministre.

[69]       En l'espèce, l'appelante admet qu'il s'agit d'une opération d'évitement au sens du paragraphe (3), mais elle affirme qu'il n'y a pas d'abus au sens du paragraphe (4), et que le paragraphe (2) s'applique donc.

[70]       Le ministre a refusé la demande de la DPA au complet. Cette mesure me semble déraisonnable et exagérée. L'article 245 n'est pas une disposition pénale. L'intimée ne soutient pas que les opérations étaient des stratagèmes, que le logiciel n'a pas été acquis ou qu'il n'a pas été acquis dans le but de tirer un revenu. À l'origine, ces arguments avaient été plaidés à titre de présomptions, mais ils n'ont pas été avancés au procès. S'ils avaient été invoqués et retenus, il aurait été inutile d'invoquer l'article 67 ou 69. S'ils avaient été retenus, il y aurait eu refus de la demande de DPA au complet. La RGAE n'aurait même pas été mentionnée. Je trouve plutôt étrange que le ministre ait « présumé » des faits qui détruisent complètement la demande de DPA, puis qu'ils « présument » l'application de la RGAE. En toute logique, la présomption relative à la RGAE et les autres présomptions invoquées ne concordent pas. Elles ne peuvent tenir ensemble. Une telle situation ne semble pas avoir troublé le ministre qui partage, comme je le suppose, l'opinion d'Emerson relativement à l'incohérence.

[71]       Dans un cas comme l'espèce, il faut d'abord se demander si d'autres dispositions de la Loi réussissent à éliminer ou à atténuer les conséquences des attributs fiscaux recherchés par le contribuable, notamment des règles particulières comme l'article 55, les règles relatives au risque, les règles relatives aux biens de location, l'article 67 ou l'article 69, pour n'en mentionner que quelques-unes. Si, après application des règles particulières, le ministre estime toujours que la RGAE devrait s'appliquer, celle-ci doit être envisagée après examen et, si c'est possible, application des articles particuliers. La RGAE n'englobe pas les autres dispositions de la Loi de l'impôt sur le revenu ni ne s'y substitue.

[72]       Si l'on considère, à partir de cette double présomption, que le logiciel a été acquis en vue de tirer un revenu (et l'acceptation de cette proposition est implicite dans l'abandon, par la Couronne, de la présomption opposée) et qu'il coûtait 13 100 000 $, comment la RGAE peut-elle s'appliquer? L'opération cesse même d'être une opération d'évitement, et l'article 69 élimine complètement l'abus qui résulte de la demande de la DPA à l'égard d'un coût en capital artificiellement élevé.

[73]       Si j'avais conclu à l'application de la RGAE, j'aurais déterminé que le moyen approprié de supprimer l'avantage fiscal était de fonder la DPA sur la JVM du logiciel et de ne pas la supprimer entièrement. La demande de la DPA à l'égard d'un bien, au taux favorable prévu pour ce bien, ne constitue pas un abus du paragraphe 20(1) de la Loi de l'impôt sur le revenu ou du Règlement. L'abus consiste à demander la DPA à l'égard d'un prix gonflé artificiellement. Cependant, il ne s'agit pas là d'un abus des dispositions de la Loi qui exige l'application de la RGAE. Il s'agit d'un abus facilement supprimé par l'article 69.

[74]       Que l'on applique la RGAE et que l'on fonde la demande de DPA sur la JVM du logiciel ou que l'on applique l'article 69 et que l'on fonde la demande de DPA sur la JVM, le résultat est exactement le même. Si le résultat peut être le même sans l'article 245 ou avec lui, de toute évidence il n'est pas nécessaire de recourir à la disposition de dernier ressort de l'article 245, qui ne s'applique donc pas. Il est inutile d'invoquer une disposition générale anti-évitement pour faire ce que peut effectuer simplement et de façon efficace une disposition particulière.

[75]       L'appel est accueilli, et la nouvelle cotisation est renvoyée au ministre du Revenu national pour qu'il l'examine de nouveau et en établisse une nouvelle en considérant que le logiciel a été acquis par Commcorp, auprès de 1004583, à sa juste valeur marchande, soit 13 100 000 $CAN.

[76]       Il est ordonné aux parties de rédiger un projet de jugement incorporant les conclusions énoncées dans les présents motifs, ainsi que toutes autres questions réglées du présent litige qu'elles ont réglées.

[77]       À défaut d'entente sur les faits, les parties devraient communiquer avec la Cour pour déterminer une date acceptable aux parties pour les déclarations connexes.

Signé à Ottawa, Canada, ce 5^e jour de septembre 2003.

« D.G.H. Bowman »

J.C.A.

Pièce B

Mouvements de fonds le 5 avril 1993

27 770 896 $

(Prêt)                                       3 996 709 $

(Entente de soutien avec Eagle)

33 091 255 $

(Prix d'achat)

1 100 000 $

(Honoraires)

33 091 255 $

(Prix d'achat)

(Paiement préalable)

33 091 255 $                                      31 993 061 $

(Prix d'achat)                                      (Paiement préalable))

Commcorp Financial Services Inc.            Analyse des flux monétaires                     Vérificateur Marina Battista

Fin d'exercice 31 oct. 1993                      Durée totale                                            98-10-30

                                                            Contrat de location                                 CASHFLOW.XLS

                                                            transfrontalier visant le logiciel                  Durée totale

                                                                                                                        Annexe I

            Si le bail n'est pas résilié avant la date prévue du 4 avril 2004

Commcorp Financial Services Inc.            Analyse des flux monétaires                                 Vérificateur Marina Battista

Fin d'exercice 31 oct. 1993                      lors de la première option d'achat              98-10-30

                                                            Contrat de location transfrontalier                         CASHFLOW.XLS

                                                            visant le logiciel                                                   Première option

                                                                                                                                    Annexe II

Si le bail se termine le 4 avril 2002