Jugements de la Cour canadienne de l'impôt

 

 

 

 

Référence : 2004CCI280

Date : 20040413

Dossier : 2000-3716(IT)G

ENTRE :

DAVID MORLEY

appelant,

et

SA MAJESTÉ LA REINE,

intimée.

 

[TRADUCTION FRANÇAISE OFFICIELLE]

 

 

MOTIFS DU JUGEMENT

 

Le juge Archambault

 

          [traduction] Pour reprendre une remarque que m’a adressée ce matin un ancien associé principal de Coopers Lybrand maintenant à la retraite, certains « éléments » du secteur privé se sont attiré ce qui leur arrive en se montrant à la fois cupides et stupides. Malheureusement, nous en avons aussi fait les frais[1].

 

[1]     Cette déclaration dont M. David Morley est lui-même l’auteur annonce la couleur des événements qui ont mené aux présents appels. Le 8 décembre 1993, M. Morley est devenu commanditaire de la société en commandite Agensys (Canada) (la « société en commandite »), société antérieurement connue sous le nom de Continental. Le 31 décembre 1993, la société en commandite lui a attribué une perte de 217 282 $ résultant essentiellement de la déduction pour amortissement (la « DPA ») demandée relativement à un logiciel (le « logiciel ») qu’elle avait acquis au prix déclaré de 12 150 000 $. Une partie de la perte de 217 282 $, soit 36 028 $, a été reportée à l’année d’imposition 1990 et déduite du revenu imposable de M. Morley en tant que perte autre qu’en capital.

 

[2]     Dans un avis de nouvelle cotisation daté du 21 novembre 1997, le ministre du Revenu national (le « ministre », « Revenu Canada » ou l’« ADRC ») a refusé à M. Morley la déduction de la part des pertes de la société en commandite qu’il demandait pour lui‑même pour l’exercice de 1993. Il a également refusé la déduction de la perte autre qu’en capital de 36 028 $ reportée à l’année d’imposition 1990. Enfin, il lui a imposé des pénalités s’élevant à 50 495,35 $ en vertu du paragraphe 163(2) de la Loi de l’impôt sur le revenu (la « Loi »), L.R.C. 1985, ch.1 (5^e suppl.).

 

[3]     Selon la réponse à l’avis d’appel modifié, les quatorze questions suivantes se poseraient dans le cadre des présents appels :

 

1.       La société en commandite était-elle une société de personnes valide?

 

2.       La société en commandite exploitait-elle une entreprise en vue de tirer un profit de l’exploitation du logiciel et avait‑elle une attente raisonnable de profit ou, au contraire, a‑t‑elle été constituée uniquement pour permettre aux investisseurs d’obtenir des remboursements d’impôt en demandant la DPA se rapportant au logiciel?

 

3.       M. Morley s’est-il joint à la société en commandite en vue d’en tirer un revenu? Avait-il une attente raisonnable de profit?

 

4.       Le logiciel a-t-il été acquis aux fins de gagner ou de produire un revenu ainsi que l’exige l’alinéa 1102(1)c) du Règlement de l’impôt sur le revenu (le « Règlement »)? Dans la négative, il ne s’agit pas d’un bien amortissable.

 

5.       Le logiciel était-il un bien visé à l’alinéa o) de la catégorie 12 de l’annexe II du Règlement? Ou s’agissait-il d’un « logiciel de systèmes » au sens de l’article 1104 du Règlement ou d’un bien visé à la catégorie 14 de l’annexe II du Règlement?

 

6.       En 1993, le logiciel était-il « prêt à être mis en service » au sens des paragraphes 13(26) et (27) de la Loi? Dans la négative, la société en commandite ne pouvait pas demander de DPA pour l’année en question.

 

7.       À quel moment le logiciel a-t-il été acquis? M. Morley prétend qu’il l’a été en décembre 1992; l’intimée, en 1993. Si l’acquisition a eu lieu en 1993, la « règle de la demi-année » prévue au paragraphe 1100(2) du Règlement s’applique à la DPA.

 

8.       Quel a été le coût du logiciel pour la société en commandite? Ce coût se limitait-il au paiement comptant de 960 000 $ ou correspondait-il au montant de 12 150 000 $ indiqué dans le billet à ordre (le « billet pour achat ») délivré lors de l’achat du logiciel? Selon l’intimée, ni la société en commandite ni le vendeur du logiciel, Agensys Corporation (« Agensys T&C ») – entité constituée sous le régime des lois des îles Turks et Caicos –, ne voulaient que le billet pour achat crée quelque obligation légale. L’intimée prétend en outre que Agensys T&C n’a jamais eu l’intention de réclamer la somme indiquée dans le billet pour achat.

 

9.       Y avait-il des liens de dépendance entre M. Morley, la société en commandite et Agensys T&C? Quelle était la juste valeur marchande (la « JVM ») du logiciel?

 

10.     La DPA demandée devait-elle être refusée suivant l’article 67 de la Loi, au motif que son montant n’était pas raisonnable eu égard aux circonstances?

 

11.     M. Morley était-il assujetti aux « règles sur la fraction à risques » prévues au paragraphe 96(2.1) de la Loi, de sorte que sa quote-part de la perte subie par la société en commandite serait réduite à 35 025 $, c’est‑à‑dire la somme qu’il a effectivement payée pour l’acquisition de parts dans la société en commandite?

 

12.     M. Morley avait-il le droit de déduire la perte autre qu’en capital de 36 028 $ dans le calcul de son revenu imposable de 1990?

 

13.     M. Morley a‑t‑il, sciemment ou dans des circonstances équivalant à faute lourde, fait un faux énoncé dans sa déclaration de revenus, de sorte qu’il convient d’appliquer la pénalité prévue au paragraphe 163(2) de la Loi?

 

14.     Le ministre a-t-il obtenu, dans le cadre de sa vérification, certains renseignements ou documents en violation des droits de M. Morley garantis par la Charte? Le cas échéant, quelle réparation peut être accordée?

 

[4]     À l’ouverture comme au fil de l’audience, les deux parties ont admis certains faits, ce qui a permis d’éliminer quelques‑unes des questions susmentionnées. Premièrement, l’intimée a reconnu que le logiciel en cause n’était ni un logiciel de systèmes ni un bien de la catégorie 14. Elle a aussi renoncé à affirmer que des pénalités devaient être imposées à M. Morley au titre du paragraphe 163(2) de la Loi. Quant à M. Morley, il a convenu, pour les besoins des présents appels, que la société en commandite avait acquis le logiciel en décembre 1993, bien qu’il y ait, selon lui, des éléments de preuve permettant de conclure que l’acquisition avait eu lieu en décembre 1992. Quoi qu’il en soit, en conséquence de cette admission, il y a lieu d’appliquer la règle de la demi-année à la société en commandite pour 1993.

 

I        Les faits[2]

 

[5]     L’instruction des présents appels a nécessité 14 longues journées[3] réparties sur une période de trois semaines. Les parties ont déposé des centaines de pièces correspondant à plusieurs milliers de pages[4]. Je n’ai pas l’intention de repasser tous les faits pertinents dans le cadre du présent résumé. Je traiterai des points factuels les plus importants dans mon analyse. Toutefois, il me semble opportun de donner dès maintenant une vue d’ensemble des faits en cause ici et de brosser le portrait des principaux acteurs de cette saga.

 

[6]     M. Morley est un homme de grande taille aux manières agréables. Après avoir obtenu un diplôme de premier cycle de l’Université de la Colombie‑Britannique en 1958[5], il a connu une brillante carrière au sein de la fonction publique du Canada. Ce fait est attesté dans une lettre que le premier ministre de l’époque, Pierre Elliott Trudeau, lui a personnellement adressée en mars 1978, à l’occasion de son départ temporaire de la fonction publique. Après avoir fait quelques affaires dans le secteur privé, notamment en acquérant une participation dans une entreprise de conception de logiciels (Omnitech Graphics Systems) dont il est par ailleurs devenu président, il a regagné la fonction publique fédérale. Il semble qu’il ait pris définitivement sa retraite de la fonction publique en 1993, au moment où il a décidé de démarrer son propre cabinet de conseil.

 

[7]     En septembre 1993, un courtier en valeurs mobilières, M. Mark Farmer, lui a fait connaître la société en commandite. À l’époque, il s’est vu remettre copie d’une notice d’offre confidentielle portant sur les parts de la société en commandite, de la convention d’acquisition du logiciel et de la convention d’entiercement des codes sources[6]. Usant d’un rare et remarquable degré de prudence, il a obtenu copie d’un rapport d’évaluation daté du 28 juin 1993, rédigé par M. Bob Pritchard (l’« évaluation Pritchard de 1993 » ou le « rapport Pritchard de 1993 »), de même qu’un document de 49 pages intitulé « The Future of Information Management » (« L’avenir de la gestion de l’information »). Ce document non daté renfermait une description du logiciel, de ses atouts et de sa position concurrentielle sur le marché ainsi que les témoignages[7] d’utilisateurs et celui d’un professeur qui, selon l’auteur du document, avait procédé à une [traduction] « évaluation indépendante du produit d’AGENSYS » (à savoir, le logiciel). M. Morley a aussi demandé à deux experts-conseils du domaine travaillant à Ottawa de lui dire ce qu’ils pensaient du logiciel. Il a même réussi à obtenir la participation de ces deux experts à une conférence téléphonique avec le créateur du logiciel, M. Howard Kale, qui vivait à Black Canyon City, en Arizona.

 

[8]     À partir des divers documents promotionnels se rapportant au logiciel, M. Howard Johnson, l’expert en évaluation du cabinet Campbell Valuation Partners Limited qui est venu témoigner à la demande de l’intimée, a produit la description suivante du logiciel et des avantages qu’il procure. Cette description se trouve aux pages 7 à 12 du rapport (l’« évaluation Johnson » ou le « rapport Johnson ») qu’il a présenté le 23 mai 2003 :

 

[traduction]

 

Description générale

 

Le logiciel est décrit comme un système et un langage de gestion de l’information utilisé pour concevoir, créer, améliorer et documenter des applications logicielles. Les développeurs s’en servent pour créer des applications de gestion de l’information, les administrateurs pour contrôler la sécurité et la gestion de l’environnement et, enfin, les utilisateurs pour manipuler et gérer plus facilement leur information.

 

Le logiciel permet de concevoir et de mettre en œuvre des applications professionnelles sans être expert en informatique. Il a servi à créer un environnement utilisateur et un jeu d’instructions logiques, semblable à ceux du tableur Lotus 1-2-3, où le développeur indique à l’ordinateur ce qu’il doit faire sans programmer la façon de le faire. Par conséquent, le logiciel permet au programmeur de se concentrer sur les processus logiques nécessaires pour réaliser l’application sans se soucier des nombreuses instructions de programmation détaillées dont l’ordinateur a besoin pour accomplir ses tâches. À la différence de Lotus 1-2-3, le logiciel répond aux besoins plus vastes de la gestion de l’information et des bases de données et du développement d’applications.

 

Le logiciel présente les fonctionnalités suivantes :

 

•                    Langage de programmation – Le logiciel fait appel à un langage de programmation de quatrième génération qui permet à l’utilisateur d’écrire des instructions (un programme) en langage humain plutôt que sous la forme d’un code informatique.

 

•                    Outils de développement d’application – Le logiciel comprend tous les outils nécessaires pour créer des applications et des programmes entièrement fonctionnels et en tester tous les aspects, de la conception à la documentation.

 

•                    Éditeur de programme – Doté d’un système d’invite de commandes complet, cet outil interactif permet de saisir et de modifier le code source, en plus de prévenir de nombreux types d’erreurs de programmation.

 

•                    Progiciel d’imagerie[8] - Cette trousse permet la saisie, le stockage, la récupération, l’affichage, la transmission et l’impression en mode électronique des répliques exactes de pages de document, ce qui constitue le fondement du bureau sans papier.

 

•                    Trousse d’aide à la programmation et de débogage – Cette trousse permet au programmeur de tester son programme, de l’exécuter tel qu’il est écrit et de déceler à l’avance les erreurs à corriger pour ainsi éviter des problèmes coûteux en temps et en argent.

 

•                    Compilateur et éditeur de liens – Ces outils traduisent les instructions du langage de haut niveau sous la forme condensée de symboles exécutables.

 

•                    Gestionnaire d’écran – Cet outil permet à l’utilisateur de modifier sans effort le format de l’écran affiché par un programme en particulier.

 

•                    Gestionnaire de base de données – Cet outil de traitement sans erreur des fichiers de base de données permet à l’utilisateur de saisir, d’organiser, de trier et d’extraire des données; le programmeur se sert de cet outil pour créer des bases de données et des fichiers, ainsi que pour disposer le contenu des enregistrements des bases de données.

 

•                    Langage d’interrogation – Ce langage permet à l’utilisateur final d’extraire l’information stockée dans une base de données sans utiliser de codes, de mots clés ou de programmes déjà écrits pour y parvenir. Le logiciel pose plutôt à l’utilisateur une série de questions simples au sujet de l’information qu’il recherche et fournit automatiquement les instructions à l’ordinateur pour que celui-ci trouve, organise et affiche à l’écran ou imprime sur papier l’information recherchée.

 

•                    Trousse d’utilitaires – Ces utilitaires facilitent la tenue à jour des fichiers. Ainsi, les utilitaires de soutien permettent aux gestionnaires et aux utilisateurs chevronnés d’explorer les aspects plus techniques d’un système qui leur seraient inaccessibles autrement.

 

•                    Outil de reprise après sinistre – Cet outil permet à l’utilisateur de rebâtir des fichiers endommagés.

 

•                    Trousse de documentation – Cette trousse regroupe les outils servant à produire automatiquement la documentation de toutes les applications à l’intention des utilisateurs, des gestionnaires et des développeurs.

 

•                    Système de sécurité – Ce système permet au gestionnaire de contrôler l’accès des utilisateurs aux programmes d’application et aux bases de données.

 

•                    Capacité de traduction multilingue – Le logiciel peut produire automatiquement la documentation dans 99 langues.

 

Avantages du logiciel

 

Contrairement aux autres produits disponibles à la date d’évaluation, le logiciel est censé offrir les avantages suivants :

 

•                    La principale force du logiciel réside dans sa capacité à exécuter des applications de gestion de l’information très complexes excédant les possibilités des autres outils automatisés. Le logiciel comprend automatiquement les commandes simples pour saisir, afficher, imprimer et traiter l’information, et son système de fichiers lui permet d’accéder efficacement à celle-ci.

 

•                    Simplicité – Les utilisateurs n’ont pas à bien connaître les ordinateurs ou à bien comprendre leur fonctionnement pour utiliser efficacement le logiciel. Ce dernier se charge d’indiquer à l’ordinateur ce qu’il doit faire et quand il doit exécuter une commande. Il n’est donc pas nécessaire d’être un expert en informatique pour utiliser le logiciel. 

 

•                    Phrases structurées – Une phrase structurée comprenant verbe, adverbe, complément d’objet et adjectifs permet d’ordonner au logiciel d’exécuter une commande. Le programmeur connaissant bien la syntaxe anglaise, le logiciel permet un apprentissage rapide et peut être maîtrisé en moins de trois mois. Cette caractéristique, combinée à la correction automatique des erreurs, permet de vérifier facilement que les applications créées avec le logiciel ne comportent aucun bogue et fonctionnent correctement. Le recours à des phrases structurées constitue la percée fondamentale et le changement de paradigme qu’offre le logiciel.

 

•                    Productivité, capacité d’adaptation et réduction des coûts – Le logiciel accélère le développement d’applications logicielles et réduit les coûts qui y sont associés en lui appliquant les principes de la réduction, de la réutilisation et du recyclage. Autrement dit, l’architecture du logiciel comporte des éléments réutilisables qui réduisent de 80 % les efforts consacrés à la programmation pour développer une application par rapport aux langages et aux outils employés jusqu’à présent. Les outils du logiciel réduisent également le temps et les coûts consacrés au développement d’applications puisqu’ils éliminent la plupart des erreurs de programmation lorsqu’elles sont introduites et relèvent les autres par des tests en continu. Sa capacité de réingénierie des anciens systèmes permet au logiciel de recycler les données et processus existants lors du passage à des architectures client/serveur. 

 

•                    Documentation automatique – Le logiciel est doté des outils nécessaires pour produire automatiquement les documents afférents à toutes les applications. Ces documents sont destinés aux utilisateurs, aux gestionnaires et aux développeurs. Il s’agit là d’un avantage important sur la plupart des autres produits.

 

•                    Qualité – Le logiciel est doté des outils et des méthodes nécessaires pour tester et valider la conception de processus opérationnels, d’interfaces utilisateur et d’applications logicielles. Il permet aux utilisateurs et aux analystes de développer des applications qui évoluent sans heurt au gré des exigences de chacun. Le logiciel améliore la qualité et la fiabilité des applications en assemblant celles-ci à partir de composants logiciels éprouvés et réutilisables.

 

•                    Portabilité – Les données et les spécifications logiques du logiciel sont distinctes les unes des autres et de l’environnement où elles sont exploitées. Cette caractéristique procure aux applications développées et exécutées au moyen du logiciel une indépendance envers la plateforme utilisée. Les outils du logiciel génèrent des applications compatibles avec de nombreux types d’ordinateurs, de réseaux, de systèmes d’exploitation et d’interfaces utilisateur. En outre, les services de communication et de messagerie assurés par le logiciel permettent aux applications exécutées sur diverses plateformes de s’échanger des données.

 

•                    Interopérabilité – Le logiciel fournit une infrastructure servant au développement de logiciels conformes aux normes des systèmes ouverts, en vigueur internationalement et au sein de l’industrie, qui facilitent la communication entre les applications.

 

•                    Évolutivité – Le logiciel permet de développer des applications évolutives puisqu’il sert à développer des applications à la fois portables et interopérables.

 

[Non souligné dans l’original et, sauf indication contraire, notes de bas de page omises.]

 

[9]     Pour comprendre cette description et éviter en partie la confusion qui prévalait à l’audience, il importe de faire la distinction entre deux composantes ou fonctionnalités clés du logiciel, soit le développement d’applications et l’utilisation de l’application. Tout d’abord, il convient de préciser que, en informatique, une application (une « application » ou « application opérationnelle ») est un logiciel qui sert en fin de compte à automatiser des opérations ou encore des activités humaines. À titre d’exemple, on peut penser aux produits bien connus de Microsoft que sont Word (traitement de texte) et Excel (chiffrier électronique). On entend par « développement d’applications » l’exploitation d’une trousse d’outils ou de production par le développeur (c.-à-d. le créateur de logiciels) en vue de « créer » une application. Autrement dit, il utilise un logiciel pour créer un autre logiciel. En revanche, l’« utilisation de l’application » est l’exploitation par l’utilisateur des fonctions de l’application créée par le développeur et ultimement destinée à l’utilisateur final. Bien souvent, les entreprises de logiciels qui créent des systèmes de gestion de l’information vendent leurs produits aux termes d'une licence de deux façons, dont l’une sous la forme d’une « version d’exécution », c’est-à-dire limitée à l’utilisation de l’application. C’est en quelque sorte la version « allégée » du système de gestion de l’information, puisqu’elle n’offre à l’utilisateur que des fonctions de base. Les fonctions avancées, comme celles qui permettent de créer des applications, sont hors de la portée de l’utilisateur.

 

[10]   Dans le cas présent, le logiciel offre les deux fonctionnalités, c’est-à-dire le développement d’applications (la « version de développement » ou « version AGP ») et l’utilisation de l’application (la « version d’exécution » ou « version AGS »). Étant donné que l’expression « système Agensys de développement d’applications » sert à décrire le logiciel, il est tout naturel que les descriptions technique et commerciale reproduites plus haut mettent l’accent sur ses fonctionnalités axées sur le développement. La société en commandite a d’abord et avant tout payé pour profiter de la fonctionnalité AGP du logiciel, c’est-à-dire ce qu’elle avait au départ l’intention de vendre aux consommateurs canadiens. Elle ne pouvait vendre que la version d’exécution (AGS) parce qu’il est nécessaire de créer d’abord une application avec la version AGP avant que cette application ne puisse servir avec la version AGS. À partir de ces explications, il apparaît évident que la composante la plus utile du logiciel est la version AGP, puisque celle‑ci permet de faire de l’argent en la vendant sous licence ou en l’exploitant dans le but de créer et de vendre des applications opérationnelles.

 

[11]   M. Larry Gamble est le promoteur de la société en commandite; il en a été le premier commanditaire en plus d’être l’unique actionnaire du commandité, à savoir 616927 Ontario Inc. (le « commandité »). En 1970, il amorce une carrière d’enseignant après avoir obtenu un baccalauréat en enseignement. Au bout de quatre ans, il décide de réorienter sa carrière pour travailler dans le domaine de l’immobilier et des valeurs mobilières. Il entre alors au service de la division de courtage en valeurs mobilières de A.E. LePage. En 1988, il quitte l’entreprise pour démarrer son propre cabinet de courtage immobilier et de courtage en valeurs mobilières, qu’il vend en 1990. Pour se faire aider dans la gestion de la société en commandite, M. Gamble a retenu les services d’un ancien collègue, M. Nicholas Barisheff. M. Barisheff a obtenu un diplôme en administration des affaires de l’Université Ryerson puis, en 1969, il a entamé sa carrière professionnelle. En 1974, après cinq années à travailler comme expert‑conseil, il a été engagé comme courtier en valeurs mobilières par A.E. LePage. Il a quitté l’entreprise en 1981. De 1981 à 1992, il a agi comme conseiller dans le cadre de diverses opérations immobilières et opérations sur titres.

 

[12]   C’est M. Barisheff qui, au printemps de 1992, allègue‑t-on, a présenté M. Gamble à M. Kale, qui avait besoin de 500 000 dollars américains pour financer un projet de commercialisation d’un logiciel. Il a dit à M. Gamble que M. Kale était le créateur d’un logiciel connu sous le nom de « Kammand » (« Kammand »). M. Gamble affirme que la société en commandite a acquis une version révisée de Kammand appelée « logiciel Agensys »[9]. Selon lui, ce sont les droits sur ce logiciel qui ont été achetés par la société en commandite le 20 décembre 1992. Ces droits se limitaient à l’utilisation et à la commercialisation du logiciel au Canada. Un exemplaire de la convention d’acquisition (la « convention d’acquisition de 1992 ») a été versé à l’onglet 40 ainsi qu’à l’onglet 55, sous‑onglet 6. Cette convention a été modifiée et mise à jour le 30 juin 1993. Suivant cette reformulation de la convention (la « convention d’acquisition de 1993 »), la société en commandite achetait d’Agensys T&C certains droits de propriété intellectuelle exclusifs relatifs au logiciel pour un prix déclaré de 12 150 000 $, payé au moyen du billet pour achat. La société en commandite était tenue de verser à Agensys T&C, pour cet achat, une contrepartie supplémentaire égale à 10 % de ses revenus annuels bruts, une fois que ses ventes cumulées au Canada auraient dépassé 120 millions de dollars.

 

[13]   Plus précisément, aux termes de la convention d’acquisition de 1993, la société en commandite a acquis les droits suivants :

 

—    le droit d’utiliser, d’exploiter, de modifier, de développer, de changer, et d’améliorer le logiciel et d’en assurer la maintenance;

 

—    le droit de commercialiser le logiciel et d’offrir les services connexes au Canada,

 

—    le droit de copier ou de reproduire le logiciel et les manuels afférents au Canada.

 

Les codes sources livrés[10] à la société en commandite pouvaient être exécutés sur les trois plateformes de système d’exploitation suivantes[11] :

 

—    MS-DOS, version 3.3 et [compilateur ‘C’, version 6.0, de Microsoft et compilateur ‘C’, version 6.0, de Borland];

 

—    Unix – SCO System V, version 3.2;

 

—    Système d’exploitation (SE) Sun.

 

Aux termes de la convention d’acquisition de 1993, Agensys T&C a accepté :

 

—    de fournir une formation (à un maximum de deux ingénieurs logiciels de la société en commandite) et les services de conseillers techniques (jusqu’à deux mois-personnes par année) aux représentants désignés de la société en commandite,

 

—    de prendre part à des activités promotionnelles (jusqu’à concurrence de six foires commerciales ou points de vente au détail sur une période de deux ans) moyennant des honoraires de 500 $ par jour (plus les frais de déplacement);

 

—    de fournir à la société en commandite toutes les améliorations de base[12] et les modifications de maintenance[13] qu’elle développe;

 

—    dans un délai raisonnable suivant [traduction] « une demande écrite formulée en ce sens par la société en commandite  », développer un logiciel de soutien[14] (le « logiciel de soutien ») et en céder le droit d’auteur pour le Canada à la société en commandite [traduction] « sans frais pour la société en commandite, mais en contrepartie de redevances raisonnables sur le plan commercial ou de droits comparables »;

 

—    livrer à la société en commandite, selon des conditions commerciales raisonnables, les « améliorations »[15] requises pour que le logiciel demeure concurrentiel sur le marché;

 

—    lancer aux États‑Unis, d’ici un an, une campagne de marketing et de promotion du logiciel et communiquer à la société en commandite des témoignages d’utilisateurs.

 

[14]   La société en commandite devait payer le prix d’achat (la partie constituée d’une somme forfaitaire) indiqué dans la convention d’acquisition de 1992 par délivrance du billet pour achat de 12 150 000 $. Le billet ne portait pas intérêt avant le 21 décembre 1993. À partir du 21 décembre 1993, des intérêts simples s’appliquaient, ceux‑ci étant calculés au taux préférentiel (de la Banque Royale du Canada), majoré de 0,5 %. Ces intérêts devaient continuer à courir jusqu’au 20 décembre 2002, date à laquelle les intérêts courus et impayés seraient capitalisés et ajoutés au capital impayé. Par la suite, les intérêts sur le capital impayé seraient calculés et acquittés trimestriellement à partir du 20 mars 2003. Le capital devait être remboursé de la manière suivante : un paiement en espèces de 960 000 $ (soit 7,9 % du prix d’achat) au plus tard le 20 décembre 1993, suivi de versements trimestriels à partir du 20 mars 1994. Toutefois, le montant des paiements effectués avant le 20 décembre 2002 devait être plafonné à 50 % de l’encaisse distribuable nette de la société en commandite. Quant aux versements trimestriels débutant le 20 mars 2003, ils devaient être faits indépendamment de l’état de l’encaisse distribuable et la société en commandite était tenue au remboursement complet du capital et des intérêts dus au plus tard le 20 décembre 2012.

 

[15]   Le 19 octobre 1993, M. Morley a souscrit 15 parts de la société en commandite, pour un prix total de 232 500 $ (15 500 $ par part), dont 35 025 $ étaient payables en espèces, et le solde de 197 475 $, au moyen d’un billet (un « billet de souscription »). Eu égard au calcul et au paiement des intérêts ainsi qu’au remboursement du capital, les modalités des billets de souscription délivrés par les commanditaires (les « commanditaires ») sont identiques à celles du billet pour achat délivré par la société en commandite, sauf pour une différence de taille : le taux d’intérêt préférentiel est majoré de 1 %, au lieu de 0,5 %[16].

 

[16]   Non seulement M. Gamble était‑il le promoteur de la société en commandite, l’unique actionnaire du commandité et le premier commanditaire : il en était également un important[17] commanditaire. Il avait acquis 63 parts, pour un coût total de 950 000 $ dont il n’avait versé que 143 113 $. Quant à M. Barisheff, il a déclaré que sa situation financière ne lui permettait pas de devenir commanditaire. À la clôture du placement privé de la société en commandite, le 8 décembre 1993, Agensys T&C a reçu 960 000 $[18] en espèces pour le paiement total du billet pour achat délivré pour le logiciel, plus les billets de souscription émis par les commanditaires, qui totalisaient 11 190 000 $. Par ailleurs, les parts des commanditaires ont été données en garantie.

 

[17]   M. Gamble a aussi fondé onze autres sociétés en commandite (les « 11 sociétés en commandite ») dans le but d’acquérir le droit de commercialiser le logiciel dans d’autres pays, comme l’Australie et la Nouvelle‑Zélande, le Royaume-Uni, la France et l’Italie. Entre 1993 et 1996, ces sociétés en commandite ont distribué leurs parts au Canada au moyen de notices d’offre confidentielles. M. Gamble vendait les parts de la société en commandite et des 11 sociétés en commandite (soit, collectivement, les « 12 sociétés en commandite »)[19] en tant qu’abri fiscal. Ainsi, l’avocat de la société en commandite a obtenu du ministre un numéro d’inscription d’abri fiscal conformément à l’article 237.1 de la Loi. Lors de son témoignage, M. Morley a reconnu les importants avantages fiscaux qu’il y avait à devenir commanditaire de la société en commandite[20]. Il a demandé la déduction d’une perte d’entreprise de 217 282 $, bien qu’en réalité, il n’ait déboursé que 35 025 $ en 1993, ce qui représente tout juste 15 % du coût total de ses parts dans la société en commandite. Pour les commanditaires qui pouvaient déduire en entier les pertes de la société en commandite au taux marginal d’imposition de 50 %, il s’agissait d’un remboursement immédiat de 310 %[21]. Pour M. Morley, le montant du remboursement aurait été légèrement inférieur, étant donné qu’il a dû reporter rétrospectivement à 1990 une partie de ses pertes. Évidemment, dans l’éventualité où les commanditaires seraient tenus de payer leurs billets de souscription ainsi que l’impôt exigible sur leur quote-part des revenus de la société en commandite, ce « profit fiscal » (la différence entre les économies d’impôt et l’argent déboursé) s’en trouverait diminué. Or, la société en commandite n’a jamais — c.‑à‑d. à partir de 1993 et jusqu’au moment de sa dissolution, le 28 février 1997 — réalisé de vente du logiciel ni tiré de revenus bruts de l’exploitation du logiciel. Par ailleurs, M. Morley (à l’instar, fort probablement, de tous les autres commanditaires) n’a jamais été tenu à quelque paiement que ce soit sur son billet de souscription, qu’il s’agisse du capital ou des intérêts courus, et on ne s’attend pas non plus à ce qu’il y soit jamais tenu[22].

 

[18]   Le 31 décembre 1993, la société en commandite a conclu une entente de commercialisation exclusive (l’« entente de commercialisation ») d’une durée de dix ans (reconductible pour deux périodes supplémentaires de cinq ans) avec Compucor Marketing Inc. (« Marketing »), dont le nom est ultérieurement devenu Agensys Marketing Inc. L’entente visait à assurer la promotion et la commercialisation du logiciel à d’éventuels utilisateurs finaux[23]. D’après les états financiers de 1994 de la société en commandite, les sociétés en commandite d’Agensys avaient conclu une entente analogue[24]. M. Gamble a déclaré que M. Barisheff et lui‑même détenaient chacun une participation de 50 % dans Marketing. Toutefois, cette affirmation contredit ce qui est indiqué dans les états financiers susmentionnés, à savoir que Marketing était indirectement détenue à part entière par M. Gamble[25].

 

[19]   En échange de ses services, Marketing avait le droit de garder, suivant l’article 8.1 de l’entente de commercialisation, 50 % du total des ventes brutes du logiciel (qu’elles aient ou non été réalisées par elle). Suivant l’article 6.1 de cette entente, Marketing était également autorisée à offrir aux utilisateurs finaux des services connexes de soutien du logiciel, notamment sous forme d’aide à l’installation, de formation technique et de dépannage par téléphone. Elle pouvait garder 90 % du montant des frais payés pour ces services. Enfin, suivant l’article 8.2, la société en commandite s’engageait à rembourser à Marketing les dépenses engagées par cette dernière dans l’exécution de ses fonctions [traduction] « selon ce que la société en commandite, à sa seule discrétion, juge indiqué ». En tout état de cause, la société en commandite consentait à avancer jusqu’à 500 000 $ à Marketing pour la mise en place d’installations et de services de formation et de soutien, ainsi qu’à verser un acompte sur les dépenses de commercialisation et de publicité remboursables[26].

 

[20]   Le rôle de M. Morley ne se résumait pas à celui d’un commanditaire passif. Il est également devenu membre du [traduction] « groupe de la direction »[27] chargé de la gestion des affaires de la société en commandite. À partir du début[28] de 1994, il a pris part aux activités de commercialisation du logiciel. Bien qu’il ait affirmé, lors de son témoignage, qu’il avait travaillé [traduction] « bénévolement » de mars à juillet 1994, il ressort de la correspondance déposée en preuve que M. Morley espérait toucher des commissions sur les ventes du logiciel ainsi qu’un pourcentage des honoraires perçus au titre de la fourniture d’applications logicielles personnalisées au gouvernement fédéral et à d’autres clients potentiels des 12 sociétés en commandite. Toutefois, en août 1994, M. Morley a conclu qu’il serait plus avantageux de réclamer au groupe de la direction des honoraires de gestion de 5 000 $ par mois (60 000 $ par année). Comme nous allons le constater plus loin, il s’est sans doute rapidement aperçu qu’il serait très difficile de réaliser des ventes et qu’il mettrait beaucoup plus de temps que prévu à toucher des revenus provenant de commissions. Étant donné qu’aucune vente n’a jamais été réalisée, sa décision s’est révélée judicieuse, d’autant plus que ses honoraires de gestion sont passés à 7 500 $ par mois lors de la deuxième année (90 000 $ par année). Le 20 avril 1997, l’arrangement a été modifié et ses honoraires ont été fixés à 75 $ l’heure[29].

 

[21]   Aucun des témoins entendus à l’audience n’a pu offrir une bonne description de la relation entre les 12 sociétés en commandite, du rôle d’Agensys T&C et d’Agensys U.S. et des caractéristiques du logiciel au fil des ans. On en trouve quelques indices dans une note non datée adressée par M. John Batton, président d’Agensys U.S., à M. Gamble (la « note de M. Batton du 8 février 1995 ») (voir l’onglet 60). La note remonte vraisemblablement au 8 février 1995, c’est-à-dire la date qui y a été imprimée par le télécopieur. Sont joints à cette note des documents non datés, tels que le « plan opérationnel » et le « plan d’expansion » d’Agensys T&C, deux documents reçus par Agensys U.S. en mai 1994[30].

 

[22]   Les deux premières pages du [traduction] « plan opérationnel » apportent certains éclaircissements :

 

Agensys Corporation

Plan opérationnel

 

Agensys Corporation[31] est détentrice, au pays et à l’étranger, des droits sur le système Agensys de développement d’applications. Elle a conclu des ententes avec les sociétés suivantes :

 

Marché interne (États‑Unis)

 

Agensys Inc.[32], une société texane, a le droit[33] de vendre et de distribuer le système Agensys de développement d’applications[34]. Elle a pour mandat de créer les marchés suivants pour le système Agensys de développement d’applications :

 

Marché des revendeurs de produits à valeur ajoutée (RPVA) — Agensys Inc. a pour mandat d’amener les RPVA à utiliser le système Agensys de développement d’applications comme technologie de base et de développer des applications pour la distribution dans les marchés de la vente au détail et de la vente aux entreprises.

 

Marché des applications — Agensys Inc. a pour mandat de créer, au moyen du système Agensys de développement d’applications, des applications pouvant être revendues dans les marchés de la vente au détail et de la vente aux entreprises.

 

Agensys Inc. a pour mandat de former des coentreprises qui créeront, au moyen du système Agensys de développement d’applications, des applications destinées à être revendues dans les marchés de la vente au détail et de la vente aux entreprises.

 

Agensys Inc. a pour mandat de créer une demande pour le système Agensys de développement d’applications dans le domaine de la gestion de l’information d’entreprise. Cette mission s’articulera autour de l’offre de solutions développées par des consultants en ayant recours au système Agensys de développement d’applications comme principal outil technologique.

 

Ces droits et fonctions ne sont pas exclusifs. Le paiement pour l’octroi de ces droits correspond à des redevances brutes, égales à un certain pourcentage, sur les licences d’utilisation du système Agensys de développement d’applications, redevances qui seront versées trimestriellement à Agensys Corporation. Les redevances peuvent être cédées à une société en commandite[35]. À la réception d’un avis en ce sens, Agensys Inc. redirigera les redevances vers la société cessionnaire[36].

 

Marchés internationaux

 

Des sociétés en commandite seront établies pour permettre l’achat du logiciel dans certains pays. Les pays en question et le pourcentage correspondant à chacun d’eux sont précisés dans la liste qui suit :

 

Pays	Prix[37]	%
Canada*	12 150 000 $	5,2 %
Austr./N.‑Z.*	7 300 000	3,26 %
France*	16 900 000	7,56 %
Italie	11 500 000	5,03 %
Royaume-Uni	18 000 000	7,87 %
Allemagne	22 000 000	9,62 %
Afrique du Sud	2 500 000	1,09 %
Mexique	4 000 000	1,75 %
Autriche	3 700 000	1,62 %
Suisse	3 700 000	1,62 %
Espagne/Portugal	8 000 000	3,5 %
Holl./Lux./Belg.	9 000 000	3,94 %
Norv./Suède/Dan.	9 900 000	4,33 %
Chine/H.K./Mal./Sing. Phil./Thaïl./Ind.	5 000 000	2,19 %
É.-U.	95 000 000	41,55 %
* Ces pays comportent des sociétés en commandite en activité au début de 1994.

 

La version du système Agensys de développement d’applications achetée par les sociétés en commandite est celle fonctionnant sur les plateformes MS‑DOS 1993 et SCO‑UNIX.

 

Le paiement des droits relatifs à un pays prend deux formes :

 

Un paiement au moment de l’achat effectif des droits par la société en commandite.

 

Le remboursement d’un prêt découlant d’un accord de redevances sur les ventes du système Agensys de développement d’applications.

 

[Non souligné dans l’original.]

 

[23]   Dans les notes internes de l’Internal Revenue Service (l’« IRS ») rédigées à l’automne 1995, Agensys U.S. est décrite comme étant une société établie à Dallas, au Texas, dont John Batton est [traduction] « propriétaire et exploitant »[38]. On peut y lire que [traduction] « M. Kale n’est pas lié à cette société ». Il ne faisait que lui offrir ses services. Par ailleurs, M. Kale avait informé l’IRS qu’il n’était pas [traduction] « un investisseur, un actionnaire ou un dirigeant/employé » d’Agensys U.S. ni d’Agensys T&C; il n’était pas non plus lié à Agensys T&C. M. Batton, de son côté, avait déclaré qu’il n’avait [traduction] « eu affaire à personne [d’Agensys T&C], à l’exception de l’avocat ». Il avait admis que [traduction] « M. Howard Kale assurait à l’occasion le relais technique entre  » Agensys T&C et Agensys U.S. Dans leurs témoignages, MM. Gamble, Barisheff et Morley ont déclaré ne détenir aucune espèce de participation dans Agensys T&C et ne pas y être liés. Ils n’en connaissaient pas le propriétaire, mais croyaient qu’elle appartenait à M. Kale ou à sa famille. Dans la version préliminaire du procès-verbal de la réunion de direction de la société en commandite qui a eu lieu le 28 février 1995 (réunion à laquelle M. Kale n’aurait pas assisté d’après la liste des personnes présentes), on trouve l’énoncé suivant : [traduction] « À l’issue d’un échange avec Larry Gamble, Howard Kale a fait savoir qu’il avait le contrôle exclusif d’Agensys Corp. aux îles Turks et Caicos » (onglet 177).

 

[24]   En janvier et en juillet 1997, l’ensemble des actifs des 12 sociétés en commandite a été transféré à Agensys International. M. Gamble affirme qu’il avait toujours eu l’intention de prendre cette mesure, et ce, afin de financer, dans un premier temps, l’acquisition du logiciel par l’intermédiaire de sociétés en commandite, pour ensuite transférer la propriété des biens de ces sociétés en commandite à une nouvelle société dont les actions seraient inscrites à une bourse des valeurs. Pour des raisons que nous verrons plus loin, Agensys International a cessé ses activités à la fin d’août 1998 sans avoir jamais – à l’instar de la société en commandite – réalisé de ventes du logiciel ni tiré des revenus bruts de l’exploitation du logiciel. Ensemble, les 12 sociétés en commandite ont amassé 69 millions de dollars; après soustraction du montant des billets de souscription, cela représentait 13 millions de dollars. De cette dernière somme, six millions de dollars ont été versés à Agensys T&C pour les droits qu’elle détenait sur le logiciel dans divers territoires et 4,6 millions de dollars ont servi aux activités des 12 sociétés en commandite et d’Agensys International entre 1993 et 1997[39].

 

[25]   Le 22 juillet 1994, le ministre a écrit à M. Gamble pour l’informer que la société en commandite et quatre des 11 sociétés en commandite feraient l’objet d’une vérification, dont la Section de l’évitement fiscal s’est ultérieurement chargée. Le 31 juillet 1996, la Section a communiqué ses conclusions à la société en commandite : de l’avis du ministre, le logiciel n’avait aucune valeur et la société en commandite n’exploitait pas d’entreprise. En conséquence, le ministre entendait établir de nouvelles cotisations à l’égard des commanditaires pour leur refuser la déduction de leur quote-part respective des pertes de la société en commandite. La plupart des associés ont fait l’objet de nouvelles cotisations en novembre 1996[40]. M. Morley faisait figure d’exception : sa nouvelle cotisation a été établie le 21 novembre 1997.

 

[26]   Le 19 septembre 1996, la Division des enquêtes spéciales (les « ES ») de Revenu Canada [responsable des enquêtes criminelles] a été avisée par la Section de l’évitement fiscal du fait que M. Gamble était impliqué, avec d’autres individus (dont M. Morley), dans une fraude d’envergure et que des déductions illicites étaient demandées de manière frauduleuse. Le 8 août 1997, M. Gamble a reçu du directeur adjoint, Division de la validation et de l’exécution, une lettre l’informant que le dossier de la société en commandite avait été confié aux ES. On pouvait notamment y lire ce qui suit : [traduction] « Afin d’assurer la protection de vos droits, il m’a été demandé de renvoyer votre dossier au chef des Enquêtes spéciales ». Le 7 octobre 1997, un enquêteur des ES a présenté une dénonciation en vue d’obtenir un mandat de perquisition (Formule 1, article 487 du Code criminel) (la « dénonciation des ES ») à un juge de la Cour de l’Ontario. Agensys International a tenté sans succès d’obtenir l’annulation du mandat de perquisition pour tromperie délibérée[41], mais au final, aucune des personnes impliquées dans les affaires de la société en commandite n’a eu à faire face à des accusations de fraude fiscale au titre de l’article 239 de la Loi.

 

II       Analyse

 

(A)     Le fardeau de la preuve

 

[27]   Avant de traiter des questions explicitement soulevées par les présents appels, il convient de préciser que c’est à M. Morley qu’il incombe de démolir les présomptions de fait formulées par le ministre lors de l’établissement des cotisations. Dans ses conclusions écrites finales, dont je reproduis ici un extrait, l’avocat de M. Morley a décrit de la manière suivante les règles relatives au fardeau de la preuve :

 

[traduction]

 

L’arrêt Hickman revêt lui aussi une grande importance en raison de ce qui y est dit au sujet du fardeau de la preuve. À la page 5376, la juge L’Heureux-Dubé déclare ce qui suit :

 

Il est bien établi en droit que, dans le domaine de la fiscalité, la norme de preuve est la prépondérance des probabilités : Dobieco Ltd. c. Minister of National Revenue, [1966] R.C.S. 95, et que, à l’intérieur de cette norme, différents degrés de preuve peuvent être exigés, selon le sujet en cause, pour que soit acquittée la charge de la preuve : Continental Insurance Co. c. Dalton Cartage Co., [1982] 1 R.C.S. 164; Pallan c. M.R.N., 90 D.T.C. (C.C.I.), à la p. 1106. En établissant des cotisations, le ministre se fonde sur des présomptions : (Bayridge Estates Ltd. c. M.N.R., 59 D.T.C. 1098 (C. de l’É.), à la p. 1101), et la charge initiale de « démolir » les présomptions formulées par le ministre dans sa cotisation est imposée au contribuable (Johnston c. Minister of National Revenue, [1948] R.C.S. 486; Kennedy c. M.R.N., 73 D.T.C. 5359 (C.A.F.), à la p. 5361). Le fardeau initial consiste seulement à « démolir » les présomptions exactes qu’a utilisées le ministre, mais rien de plus : First Fund Genesis Corp. c. La Reine, 90 D.T.C. 6337 (C.F. 1re inst.), à la p. 6340.

 

L’appelant s’acquitte de cette charge initiale de « démolir » l’exactitude des présomptions du ministre lorsqu’il présente au moins une preuve prima facie : Kamin c. M.R.N., 93 D.T.C. 62 (C.C.I.); Goodwin c. M.R.N., 82 D.T.C. 1679 (C.R.I.). [...]  Il est établi en droit qu’une preuve non contestée ni contredite « démolit » les présomptions du ministre : voir par exemple MacIsaac c. M.R.N., 74 D.T.C. 6380 (C.A.F.), à la p. 6381; Zink c. M.R.N., 87 D.T.C. 652 (C.C.I.). […]

 

Lorsque l’appelant a « démoli » les présomptions du ministre, le « fardeau de la preuve […] passe […] au ministre, qui doit réfuter la preuve prima facie » faite par l’appelant et prouver les présomptions: Magilb Development Corp. c. La Reine, 87 D.T.C 5012 (C.F. 1^re inst.) à la p. 5018. [...]

 

Lorsque le fardeau est passé au ministre et que celui-ci ne produit absolument aucune preuve, le contribuable est fondé à obtenir gain de cause : voir par exemple MacIsaac, précité, où la Cour d’appel fédérale a infirmé le jugement de la Division de première instance (à la p. 6381) pour le motif que le « témoignage n’a été ni contesté ni contredit, et aucune objection ne lui a été opposée ». Voir aussi Waxstein c. M.R.N., 80 D.T.C. 1348 (C.R.I.); Roselawn Investments Ltd. c. M.R.N., 80 D.T.C. 1271 (C.R.I.).

 

 

Nous soutenons qu’en se prononçant sur la question du fardeau de la preuve, la juge L’Heureux-Dubé a clairement établi les principes suivants :

 

1.         Lorsqu’il établit de nouvelles cotisations, le ministre se fonde sur des présomptions et c’est au contribuable qu’est imposée la charge initiale de démolir ces présomptions.

 

2.         L’appelant s’acquitte du fardeau de démolir les présomptions de fait du ministre en présentant au moins une preuve prima facie.

 

3.         Une preuve non contestée et non contredite démolit les présomptions du ministre.

 

4.         Si l’appelant présente une preuve prima facie et démolit les présomptions du ministre, la charge passe à l’intimée, qui doit réfuter la preuve prima facie.

 

5.         Lorsque le fardeau passe au ministre et que celui-ci ne produit aucune preuve, l’appelant est fondé à obtenir gain de cause.

 

Autrement dit, l’appelant n’est pas tenu de produire une preuve d’un caractère absolu comme c’est le cas pour le ministère public en matière criminelle. Au contraire, l’appelant peut démolir les présomptions qui ont servi de fondement à la nouvelle cotisation en présentant simplement une preuve prima facie. Une fois cela fait, la charge passe au ministre et, si ce dernier ne produit aucune preuve, l’appelant est fondé à obtenir gain de cause.

 

À la page 5377, la juge L’Heureux-Dubé poursuit :

 

Comme le juge Rip de la Cour canadienne de l’impôt l’a noté dans Gelber c. M.R.N., 91 D.T.C. 1030, à la p. 1033, « [le ministre] n’est pas l’arbitre de ce qui est fondé ou non en matière de droit fiscal ». Le juge Brulé, de la Cour canadienne de l’impôt dans Kamin, précité, a observé à la p. 64 :

 

[…] le ministre devrait pouvoir réfuter cette preuve [prima facie] et présenter des arguments à l’appui de ses présomptions.

 

Le ministre n’a pas carte blanche pour établir les présomptions qui lui conviennent. À l’interrogatoire principal, on s’attend qu’il puisse produire des preuves plus concrètes que de simples présomptions pour réfuter les arguments de l’appelant.[42]

 

[28]   Je souscris généralement à cette description. Toutefois, je ferais deux commentaires. Premièrement, la preuve prima facie que doit présenter le contribuable doit être crédible. Deuxièmement, lorsque le ministre produit des éléments de preuve, le juge doit procéder à une appréciation globale de la force probante de la preuve dont il est saisi de part et d’autre et tirer une conclusion, selon la prépondérance des probabilités, quant à la question de savoir si le contribuable a réussi à faire prévaloir son point de vue. À l’audience, l’avocat de M. Morley a souscrit à ces deux commentaires.

 

 

(B)     La société en commandite a-t-elle été formée en vue de tirer un profit de l’exploitation du logiciel? Exploitait-elle une entreprise en 1993?

 

[29]   Des quatorze questions en litige énoncées auparavant, il n’en reste que onze. Les quatre premières peuvent être examinées ensemble, car elles procèdent toutes d’une même question fondamentale, soit celle de savoir si la société en commandite exploitait une entreprise dans une attente raisonnable de profit au cours de l’année d’imposition 1993. Étant donné que la principale raison d’être de la société en commandite était l’acquisition du logiciel, la question revient à déterminer si la société en commandite a été formée en vue de tirer un profit de l’exploitation du logiciel ou si elle visait uniquement à permettre à ses commanditaires d’obtenir des remboursements d’impôt en demandant la DPA relative au logiciel. Selon moi, la réponse à ces questions réglera ces quatre questions.

 

[30]   À l’alinéa 21h) de sa réponse à l’avis d’appel modifié, l’intimée déclare qu’en établissant sa cotisation, le ministre s’est fondé sur la présomption suivante relativement à cette question précise :

 

[traduction]

 

21h)     la prétendue société en commandite a été formée par Larry Gamble dans l’unique but de permettre à des investisseurs d’obtenir des remboursements d’impôt au moyen d’une déduction pour amortissement.

 

[31]   Dans son argumentation écrite, l’avocat de l’intimée adopte un point de vue légèrement différent. Se concentrant principalement sur l’année d’imposition 1993, il affirme qu’aucune entreprise n’a été exploitée au cours de cette année. Voici sa thèse :

 

[traduction]

 

A.        PAS DE SOCIÉTÉ DE PERSONNES EN 1993

 

3.         Une société de personnes consiste en deux ou plusieurs personnes qui exploitent une entreprise en commun en vue de réaliser un bénéfice. Il ne fait plus aucun doute que, pour prouver l’existence d’une société de personnes, il est nécessaire d’établir que trois éléments essentiels sont réunis : a) une entreprise; b) exploitée en commun; c) en vue de réaliser un bénéfice.

 

Backman c. Canada, [2001] 1 RCS 367 [onglet 20]

 

4.         L’intimée soutient qu’il n’y avait pas de société de personnes en 1993 du fait que les associés n’avaient pas l’intention de tirer un bénéfice des ventes du logiciel. Cette conclusion est étayée par les faits suivants : (i) aucun examen approfondi du logiciel n’a été fait avant son acquisition, (ii) jusqu’en 1994, au moins, Agensys Canada n’employait pas de personnel technique, (iii) le logiciel, de toute évidence, n’a pas été « livré » ni examiné avant décembre 1993; (iv) jusqu’en 1994, au moins, Agensys Canada a concentré tous ses efforts sur la promotion et les ventes, non pas d’applications logicielles, mais de parts de sociétés en commandite. 

 

5.         En fait, l’intimée soutient, d’une part, que s’il existait une « entreprise » en 1993, celle-ci était présentée aux commanditaires comme un instrument permettant d’économiser de l’impôt, en n’accordant que peu d’importance, voire aucune, à la possibilité pour Agensys Canada de tirer profit de l’utilisation du logiciel acquis; d’autre part, il était impensable de s’attendre à ce que Agensys Canada puisse tirer profit de l’utilisation du logiciel avant que ce dernier ne puisse être examiné, en décembre 1993. L’intimée ajoute que l’appelant n’a pas réussi à démontrer qu’il avait une attente raisonnable de profit, un constat corroboré par le fait qu’aucun revenu n’a jamais été généré, pas plus qu’il n’y a eu d’efforts pour permettre au logiciel de demeurer à la fine pointe du progrès et ainsi en faciliter la vente.

 

6.         La Cour suprême du Canada a indiqué que « pour statuer sur l’existence d’une société de personnes, les tribunaux doivent se demander si la preuve documentaire objective et les circonstances de l’affaire, notamment les actes concrets des parties, sont compatibles avec l’existence d’une intention subjective d’exploiter une entreprise en commun dans le but de réaliser un bénéfice ».

 

Backman, précité, paragraphe 25

 

7.         Ainsi, la Cour doit considérer l’ensemble des circonstances et éviter l’application mécanique d’une liste de contrôle ou d’un critère comportant des paramètres définis de façon plus précise. La Cour doit se montrer pragmatique dans l’examen des trois éléments essentiels d’une société de personnes. Pour déterminer si une telle société a été établie, il faut analyser et soupeser les facteurs pertinents eu égard à toutes les circonstances.

 

Backman, précité, paragraphe 26

 

8.         Il ne suffit pas que les documents de la société de personnes et les autres documents indiquent l’intention de créer une société de personnes. Les conditions fondamentales d’existence d’une société de personnes doivent également être respectées.

 

Backman, précité, paragraphe 27

 

9.         En résumé, l’intimée soutient que, en 1993, Agensys Canada n’avait pas l’intention de tirer un bénéfice et qu’aucune entreprise n’a été exploitée. Les activités qui ont eu lieu se rapportaient à la vente des parts de la société en commandite. Avant 1994, cette dernière n’avait pas les moyens financiers d’entreprendre un effort de commercialisation. Il s’ensuit qu’il n’y avait pas de société de personnes, du moins n’y en avait-il pas en 1993.

 

[32]   Quant à M. Morley, sa thèse est la suivante : [traduction] « [I]l ne fait guère de doute que les activités exercées par le contribuable étaient de nature commerciale et que la règle de l’attente raisonnable de profit ne saurait s’appliquer » (page 21 des arguments écrits de son avocat). Pour étayer ce qu’il avance, son avocat se fonde sur les principes énoncés par la Cour suprême du Canada dans l’arrêt Stewart c. La Reine, 2002 CarswellNat 1070, 2002 CSC 46, 2002 CarswellNat 1071, 212 D.L.R. (4th) 577, 2002 DTC 6969, au paragraphe 53 :

 

Nous soulignons que ce critère de l’existence d’une source « en vue de réaliser un profit » ne doit faire l’objet d’une analyse que dans les situations où l’activité en cause comporte un aspect personnel ou récréatif. En toute déférence, nous estimons que les tribunaux ont commis une erreur, dans le passé, en appliquant le critère de l’ERP à des activités comme l’exercice du droit et la restauration qui ne comportent aucun aspect personnel de cette nature […] Lorsqu’une activité est clairement de nature commerciale, il n’est pas nécessaire d’analyser les décisions commerciales du contribuable. De telles démarches comportent nécessairement la recherche d’un profit. Il existe donc par définition une source de revenu et il n’est pas nécessaire de pousser l’examen plus loin.

[Passage souligné par l’avocat.]

 

 

[33]   L’avocat de M. Morley ajoute (à la page 26 de son argumentation écrite) qu’il [traduction] « est évident que la position de la Cour suprême du Canada, au jour d’aujourd’hui, consiste à dire que, même si un contribuable est clairement motivé par des considérations d’ordre fiscal, ces dernières n’invalident pas les opérations effectuées à des fins fiscales, à moins que ces opérations ne soient factices ». Pour appuyer ce qui précède, il cite La Reine c. Walls, 2002 CarswellNat 1072, 2002 CSC 47, 212 D.L.R. (4th) 606, 2002 DTC 6960, au paragraphe 22 :

 

Même si les intimés en l’espèce étaient clairement motivés par des considérations fiscales lorsqu’ils ont acquis leur participation dans la société, cela n’enlève rien à la nature commerciale de l’exploitation du parc d’entreposage ni à sa qualification de source de revenu pour l’application de l’art. 9 de la Loi. Il est bien établi qu’une motivation d’ordre fiscal n’enlève rien à la validité d’opérations effectuées à des fins fiscales : Backman c. Canada, [2001 DTC 5149] [2001] 1 R.C.S. 367, 2001 CSC 10, par. 22; Shell Canada Ltd. c. Canada [99 DTC 5669] [1999] 3 R.C.S. 622; Canada c. Antosko [94 DTC 6314], [1994] 2 R.C.S. 312; Stubart Investments Ltd. c. La Reine [84 DTC 6305], [1984] 1 R.C.S. 536, p. 540. Nous réitérons aussi la mise en garde faite dans l’arrêt Stewart, précité, par. 65, selon laquelle, compte tenu de l’existence de dispositions anti‑évitement particulières dans la Loi, les tribunaux ne devraient pas s’empresser de renforcer les dispositions de la Loi lorsque des inquiétudes sont exprimées concernant l’évitement de l’impôt : voir également Enterprises Ludco Ltée c. Canada [2001 DTC 5505], [2001] 2 R.C.S. 1082, 2001 CSC 62, par. 39; Neuman c. M.R.N. [98 DTC 6297], [1998] 1 R.C.S. 770, par. 63.

 

[Passage souligné par l’avocat.]

 

[34]   À mon avis, bien qu’il soit troublant de constater que la société en commandite n’a jamais réalisé de ventes, la preuve produite par les deux parties à l’audience appuie, selon la prépondérance des probabilités, la position de M. Morley, à savoir qu’une société de personnes valable existait au 30 juin 1993 et qu’elle a exploité une entreprise en 1993. D’abord, un contrat de société a été conclu et signé le 30 juin 1993 par deux personnes : M. Gamble, en tant que premier commanditaire, et 616 927 Ontario Inc., à titre de commandité. Leur intention, comme en témoigne l’article 2.2 du contrat, était d’exploiter une entreprise [traduction] « de reproduction, de commercialisation et de distribution du [logiciel] et d’autres logiciels au Canada et de fournir des services d’appoint, de soutien au développement, de gestion et d’autres services connexes en vue de tirer un profit de cette entreprise ». Évidemment, une simple stipulation ne suffit pas, en soi, à prouver l’existence d’une société de personnes. La conduite des associés doit cadrer avec cet énoncé.

 

[35]   Il est vrai qu’en 1993, M. Gamble et la société en commandite se sont surtout efforcés de réunir les capitaux nécessaires à cette dernière par voie de placement privé. M. Gamble a déclaré qu’à cette fin, il avait retenu les services de M^e Allan Beach, du cabinet Fasken, Campbell, Godfrey, au début de 1993[43]. Le cabinet a préparé une notice d’offre confidentielle (dont la version définitive porte la date du 20 juillet 1993). L’offre portait sur l’achat de 850 parts de la société en commandite et la souscription minimum par investisseur était fixée à 155 000 $. M^e Beach et M. Gamble travaillaient également à la rédaction de la convention d’acquisition de 1993, qui a été conclue le 30 juin 1993[44]. Le 8 décembre 1993, date de clôture des souscriptions, le montage financier de la société en commandite était terminé : 34 investisseurs avaient souscrit des parts de la société en commandite, pour un montant total de 13 175 000 $.

 

[36]   À la même époque, la société en commandite travaillait également à l’élaboration de son plan de commercialisation et quelques démonstrations ont été effectuées. Aux dires de M. Gamble, un certain M. Bergerson avait été chargé, à un moment donné en 1992, de préparer une évaluation du logiciel et du marché canadien. Au même titre que bon nombre de documents[45] censément rédigés en 1992 et en 1993, le document intitulé « KAMMAND: Canadian Market Research » (« Kammand : une étude du marché canadien ») et présenté comme étant le rapport de M. Bergerson (pièce A‑3) ne porte aucune date ni aucune mention de son auteur[46]. La copie d’un programme concernant une démonstration du logiciel que M. Kale lui‑même devait effectuer à Toronto en septembre 1993 a également été déposée en preuve (onglet 52); les participants dont il est fait état comprenaient des gens appartenant ou ayant appartenu à l’équipe IBM. Il est possible[47] que M. Kale ait fourni ces services conformément à une entente intervenue entre lui et M. Gamble, entente à laquelle M. Kale fait allusion dans une lettre qu’il a adressée à M. Gamble le 17 janvier 1993. Par ailleurs, comme nous l’avons vu précédemment, la société en commandite a conclu l’entente de commercialisation avec Marketing le 31 décembre 1993.

 

[37]   En 1994, la société en commandite a loué, avenue Woodbine, à Toronto, des bureaux d’une superficie de 1 500 pi² de même qu’une salle réservée aux démonstrations. En 1995, elle a déménagé dans des bureaux plus spacieux (3 000 ou 4 000 pi²) situés Consumers Road, à Toronto.

 

[38]   Essentiellement, trois particuliers — M. Barisheff, M. Gamble et M. Morley — ont pris part à la gestion de Marketing et de la société en commandite en 1994. Il semble que c'est à M. Barisheff qu’incombait la responsabilité de l’ensemble de l’exploitation. Dans sa déposition, il a déclaré avoir consacré la totalité de son temps, de septembre 1992 à septembre 1998, à la société en commandite et à Agensys International. Il intervenait dans les orientations stratégiques de la société en commandite et il s’occupait de la commercialisation et des problèmes techniques ainsi que des questions relevant du domaine des valeurs mobilières. Il tenait aussi des réunions avec les comptables et les avocats et se chargeait de l’embauche du personnel. Il touchait à titre de rémunération 50 % des honoraires du commandité; ces honoraires étaient de 80 000 $ en 1993, de 60 000 $ en 1994, de 150 000 $ en 1995 et de 180 000 $ en 1996[48]. Quant à M. Gamble, il consacrait apparemment 75 % de son temps à la société en commandite; toutefois, la description de ses fonctions est vague : il s’est présenté comme un « facilitateur ». Je suppose qu’il passait une bonne partie de son temps à faire la promotion de la vente des parts des 12 sociétés en commandite.

 

[39]   En 1994, M. Morley consacrait de trois à quatre jours de son temps à la société en commandite ou à Marketing. En plus d’essayer d’obtenir un accès aux ministères et organismes fédéraux, il s’employait à établir des [traduction] « usines de fabrication de logiciels » au Canada et à tisser des réseaux à l’étranger pour le compte des 11 sociétés en commandite. Le ministère des Affaires étrangères figure au nombre de ceux qui lui ont fourni le nom de partenaires commerciaux potentiels à l’étranger. L’une des informations qu’il a reçues concernait une société italienne : elle aurait apparemment constitué une piste sérieuse, mais n’a donné, au bout du compte, aucun résultat.

 

[40]   Il semblerait que l’une des toutes premières activités entreprises par la société en commandite en 1994 ait été d’inscrire son équipe de direction à une séance de formation offerte en Arizona par l’Université Western International. MM. Gamble, Barisheff, Morley, Kale et Batton y ont assisté.

 

[41]   Selon M. Barisheff, le plan de départ (l’« approche axée sur le produit »), qui était de vendre le logiciel comme tel à d’éventuels utilisateurs finaux, a été abandonné après cette formation[49]. La société en commandite a alors fait sienne la stratégie de marketing (l’« approche axée sur la consultation ») adoptée par Agensys U.S., laquelle consistait à développer pour des organismes gouvernementaux et des entreprises les applications personnalisées dont elles avaient besoin pour la gestion de leur information. Ces organisations ont été regroupées par secteur (appelés [traduction] « marchés verticaux »), c’est-à-dire le gouvernement fédéral, l’aviation et les services financiers. M. Morley aurait reçu le mandat de trouver des débouchés dans le secteur public, M. Farmer, le secteur des valeurs mobilières, et un certain M. Bert Smalley, pilote aérien, celui de l’aviation.

 

[42]   On trouve quelques notes de service internes et de la correspondance qui indiquent que M. Morley a commencé à prendre part aux activités de commercialisation de la société en commandite en janvier 1994[50]. La toute première note, datée du 17 janvier 199[4] et adressée à MM. Gamble et Barisheff, revêt un intérêt particulier, car, d’une part, elle montre que M. Morley était de ceux qui croyaient que la société en commandite exploitait une véritable entreprise et, d’autre part, qu’il a pu détecter très tôt certaines des faiblesses du plan d’affaires[51]. Voici un passage tiré de cette note :

 

[traduction]

 

Avant de consacrer plus de temps à l’élaboration d’une stratégie pour vendre Agensys au secteur public, je souhaite avoir une meilleure idée de la façon dont vous comptez segmenter le marché canadien. J’aimerais aussi obtenir plus de précisions quant à la nature du rôle que vous me voyez intégrer au sein d’Agensys Canada (AC), le cas échéant.

 

Je suis heureux d’avoir été invité à prendre part à la discussion la semaine dernière. J’en retiens deux choses : l’ampleur du travail qui reste à accomplir pour que le lancement sur le marché canadien soit couronné de succès, de même qu’un sentiment d’inquiétude à l’idée de s’en remettre trop longuement à l’aide à la programmation d’applications fournie depuis les États-Unis. Les gouvernements canadiens s’intéresseront particulièrement à cet aspect. À titre de commanditaire, je me permets d’avancer qu’au moment où des liquidités seront disponibles, l’ouverture d’une usine de production de logiciels au Canada pourrait devenir un élément rentable pour AC. Ma troisième préoccupation concerne le très faible financement dont dispose AC.

 

[. . .]

 

J’aimerais revenir sur la question des relations personnelles. La semaine dernière, j’ai échangé avec un ami qui occupe le poste de premier vice-président des opérations sur devises à la Banque de Montréal. […]  Il a demandé à ce qu’on lui présente AC lorsque l’entreprise sera en activité. . . .

 

Je vous prierais de me téléphoner lorsque vous en aurez la possibilité. Je souhaite être associé à la recherche de débouchés pour AC et à couvrir mes frais personnels de démarrage. Pour cette raison, je vous saurais gré d’être le plus précis possible quant à la façon dont vous envisagez nos relations futures.

 

[Non souligné dans l’original.]

 

 

[43]   En réalité, il a été déposé en preuve un nombre considérable de lettres et de notes internes montrant que M. Morley s’employait activement à intéresser des représentants gouvernementaux, des cadres d’entreprise et des étrangers, aux services de consultation offerts par la société en commandite[52]. L’une des stratégies de développement de l’entreprise de la société en commandite consistait, semble‑t‑il, à ouvrir des [TRADUCTION] « usines de production de logiciels au Canada », usines qui auraient développé les applications opérationnelles demandées par ses clients. M. Morley a déployé beaucoup d’efforts pour tenter de persuader certains gouvernements provinciaux du Canada à consentir des incitatifs fiscaux pour l’établissement de telles usines. Toutefois, ces démarches ne semblent pas avoir porté fruit.

 

[44]   L’idée que la société en commandite ait pu tenter, particulièrement en 1994 et en 1995, de vendre ses services de développeur d’applications opérationnelles sans bien connaître son propre logiciel, sans posséder de personnel compétent pour développer ces applications[53] et sans disposer de toutes les fonctionnalités du logiciel est plutôt déconcertante (pour ne pas dire pathétique). On en trouve un bon exemple à l’onglet 102, dans une lettre adressée par M. Morley à un certain M. Barron, du ministère du Développement économique le 14 juin 19[9]4, à laquelle M. Morley avait annexé un document intitulé « Agensys: a paradigm shift in application development » ([traduction] « Agensys : un changement radical dans le domaine du développement d’applications »), qui décrivait en ces termes l’indépendance du logiciel vis-à-vis des plateformes :

 

[traduction]

 

Les modules d’application développés avec AGENSYS sont dégagés de toutes contraintes liées au matériel et au système d’exploitation et fonctionnent indépendamment de la structure des données, du réseau et de l’environnement.

 

[Non souligné dans l’original.]

 

Dans son rapport d’évaluation du logiciel, daté du 6 septembre 1994, Object Systems Inc. déclare que le logiciel [traduction] « ne permet[tait] pas l’interopérabilité entre plateformes ni ne pren[ait] en charge l’accès à une gamme acceptable de fichiers et de bases de données » (onglet 128, p. 6 du résumé). Les assertions de M. Morley sont donc largement trompeuses![54]

 

[45]   En fait, pendant la majeure partie des années 1994 et 1995, la société en commandite était bien loin de réaliser des ventes[55]. Elle devait embaucher des consultants simplement pour déterminer ce que le logiciel pouvait et ne pouvait pas faire, préparer de nombreux documents d’évaluation avant commercialisation et des démonstrations à l’intention d’éventuels acheteurs et de Revenu Canada et corriger les anomalies du logiciel (bogues)[56]. Ainsi, en mars 1994, les services d’Object Systems Inc. ont été retenus pour l’évaluation et la préparation de matériel promotionnel relatif au logiciel.

 

[46]   Pour illustrer davantage les points qui précèdent, je reproduis ici plusieurs passages tirés de notes, de lettres et de rapports. D’abord, dans une note adressée à Larry Gamble et à Nick Barisheff le 8 août 1994, M. Morley écrit ce qui suit (onglet 117) :

 

[traduction]

 

Paul Blair[57] a fait une observation intéressante au sujet de Howard [Kale]. Il a dit que Howard ne fait pas toujours la différence entre ce que AGENSYS serait capable de faire et ce que le logiciel est en mesure d’accomplir concrètement. Les notes manuscrites de Howard, qui se veulent une réponse à la note de service du 2 juin de Larry, sont un exemple de ses attentes irréalistes quant au logiciel qui sera développé d’ici « la fin de 1994 ». (p. 2)

 

[…]

 

L’information que Terry [Stanhope, de la société Object Systems Inc.] aura recueillie pendant son séjour aux États-Unis confirmera sans doute que les capacités d’AGENSYS ne sont pas à la hauteur de ce qui est déclaré dans la publicité. Il faudra vraisemblablement déboguer un des logiciels existants. À titre d’exemple, Paul a signalé que la version d’AGENSYS destinée à l’environnement Unix, dont Howard affirmait qu’elle était prête, a présenté un bogue dès qu’il a saisi la première commande[58]. (p. 4)

 

[. . .]

 

Comme vous le savez, j’ai commencé à faire des démarches auprès du gouvernement fédéral, car il nous fallait nous faire notre propre idée de la façon dont notre produit serait accueilli. J’ai mis fin à mes démarches un mois plus tard parce que nous n’avions aucun moyen de vérifier si ce que nous affirmions au sujet de ses possibilités tenait de la réalité ou de la fiction. (p. 6)

 

[. . .]

 

Si nous devions obtenir notre première commande d’application au cours des six prochaines semaines, nous ne serions pas prêts à fournir les services professionnels de soutien avant, pendant et après le développement du produit. Il y a beaucoup plus à faire que de demander la programmation de l’application aux États-Unis. (p. 8)

[Non souligné dans l’original.]

 

[47]   Voici l’appréciation formulée par Object Systems Inc. à la page 24 de son [traduction] « Évaluation de produit – logiciel professionnel AGENSYS », datée du 6 septembre 1994 (onglet 128) :

 

[traduction]

 

Nous sommes arrivés à la conclusion que, si on proposait à d’éventuels acheteurs de faire l’essai préalable d’AGENSYS pendant un ou deux jours, ils décideraient de ne pas en faire l’acquisition. La documentation ne peut rivaliser avec la norme établie par Apple et Microsoft.

 

[48]   En 1995, MM. Paul Mighton et Gary McCann[59], deux personnes possédant une certaine expérience du domaine du logiciel, ont été engagés comme consultants. Toutefois, ils consacraient la totalité de leur temps aux activités de la société en commandite. Toujours en 1995, M. Karnis a été engagé comme consultant pour aider la société en commandite à préparer une démonstration. La note du 23 mars 1995 ci‑dessous (onglet 189), adressée par M. Morley à D. Strutt et J.‑P. Bradford, permet de constater que, neuf mois plus tard, les choses n’avaient pas beaucoup avancé :

 

[traduction]

 

J’ai dit à Larry [Gamble] et à Nick [Barisheff], en juillet 1994, que je n’avais aucunement l’intention de reprendre les démarches auprès du secteur fédéral avant de disposer d’un produit dont les qualités annoncées peuvent être démontrées, d’une équipe d’experts confirmés pour commercialiser et développer la technologie et de l’infrastructure de soutien d’une application. Ils sont tous deux conscients que, dans un segment de marché aussi isolé que la fonction publique fédérale, on n’a qu’une seule chance. Terry était censé nous apporter une expertise technique. Nous avons perdu cinq mois parce qu’il n’a pas livré la marchandise.

 

Je ne m’engagerai pas, en notre nom, à tenter une nouvelle percée sur le marché d’Ottawa avant d’avoir vu les démos mis au point par Gary McCann et la documentation préparée par Paul pour la commercialisation, la présentation démo et les ventes. Cela dit, je suis enfin convaincu que nous sommes désormais sur le point de régler les problèmes mentionnés ci‑dessus. Il est temps de commencer à élaborer une stratégie pour le marché vertical du secteur public (SMVSP). Je souhaiterais avoir votre avis au sujet des idées exposées ci-dessous[60].

 

Ce qui suit dépend de notre capacité de mettre en œuvre dès maintenant une application client-serveur. Paul [Mighton] et Gary [McCann] affirment qu’il est possible de se doter d’une capacité d’interfaçage avec l’ordinateur central d’ici au 31 juillet. Nous arrêterons probablement notre choix sur AS 400, puisqu’il occupe une part importante du marché nord-américain et 70 % du marché italien. Paul et Gary se trouvent actuellement à Dallas afin de nous aider à déterminer exactement où en est le logiciel et ce qui reste à faire […]

 

[Non souligné dans l’original.]

 

 

[49]   Dans son rapport du 7 mai 1995 (le « rapport de mai 1995 ») (onglet 207), Gary McCann (v.‑p., Technologie et Développement commercial) dresse un portrait de la situation :

 

[traduction]

 

Agensys – Clarification de ce que nous avons

 

La grande question que se posent les gens depuis un certain temps est celle‑ci : de quoi disposons-nous sur le plan des versions, éditions, etc.? Au cours de la dernière année, quelques personnes ont produit un important volume de documents pour tenter de définir les plans de développement et les nouvelles éditions à venir.

 

Je me suis rendu à Phoenix dans le but de régler définitivement cette question. Il ne devrait pas y avoir davantage de confusion à ce sujet puisqu’il s’agit ici d’une version en mode texte ou caractère d’Agensys exploitée sous DOS et SCO/Unix. C’est tout! On peut oublier toute la documentation sur les versions de 1994 qui promettaient le développement d’une interface utilisateur graphique et d’autres produits livrables compatibles avec Windows, Windows NT, OS/2, Motif, Open Look, etc. Rien n’indique que ce projet ait été mené à terme même s’il faisait partie d’un plan de développement qui n’était pas du tout mauvais. Le séjour à Dallas a fait naître quelques soupçons à ce sujet et le voyage à Phoenix a permis de dissiper tout doute qui subsistait quant à ce que nous avons en notre possession.

 

Nous ne devrions pas nous préoccuper du fait que nous n’ayons pas en main toute la panoplie de fonctionnalités. Cet aspect ne devrait pas nous inquiéter à court terme. Je tiens à répéter que nous disposons d’un produit stable et commercialement viable, à partir duquel nous pouvons effectivement réaliser des solutions logicielles pour nos clients et commencer à nous faire connaître et à acquérir une bonne renommée dans l’industrie. À plus long terme, nous devrons être à l’écoute, car le marché exige, et continuera d’exiger des produits que les utilisateurs trouvent conviviaux et divertissants. Aussi malheureux que cela puisse paraître, et indépendamment du fait que la gestion de l’information y soit pour peu, c’est la réalité et nous ne pouvons la modifier. Nous devons nous ouvrir aux évolutions technologiques et aux avancées de l’informatique d’utilisateur final et suivre les nouvelles tendances, ou en subir les conséquences et devenir une simple statistique dans le très compétitif secteur du logiciel. Je veux parler ici de l’utilisateur et non du développeur. Puisque nous aurons la responsabilité du développement, nous conserverons la maîtrise et profiterons de l’ensemble des fonctions ou services de soutien, lesquels constitueront des retombées directes du processus de développement, p. ex. soutien au client, contrats de maintenance, instruction et formation, pour n’en citer que quelques‑unes.

 

Par conséquent, nous devrions prévoir l’amorce d’un plan de développement d’un produit au troisième trimestre de 1995. Ce plan devrait inclure le développement des interfaces avec les bases de données et les réseaux, ainsi que des interfaces de plateformes comme le système à mémoire virtuelle (MVS) de DEC, ainsi que les systèmes MVS et AIX d’IBM. La plupart des anciens systèmes ont été développés et continuent de fonctionner sur des plateformes MVS; il faudrait commencer à travailler sur ce type de développement. Nous devrions également nous concentrer sur le développement d’une interface utilisateur graphique (IUG) pour rendre intuitive l’utilisation du produit par l’ensemble des utilisateurs finaux. Nous devrions continuer d’améliorer le module Translation Manager et mettre en place un environnement de multitraitement au moyen de divers modules d’Agensys. Il ne s’agit pas d’une tâche complexe si elle est planifiée. À l’avenir, toutes les activités de développement évolueront, en partie grâce à un plan ordonné, de manière à nous positionner pour l’avenir et elles nous seront partiellement dictées par nos clients. Ce développement devrait être financé par les recettes futures et il devrait être envisagé, dans le plan, de consacrer un minimum de 20 % des recettes aux activités de développement.

 

[Non souligné dans l’original.]

 

 

[50]   La nécessité de doter le logiciel d’une interface utilisateur graphique et de capacités d’interface pour les bases de données et les communications est également relevée par M. Morley dans une note datée du 20 janvier 1996 dans laquelle il résume les commentaires reçus à la suite de six démonstrations effectuées par CGI. La société en commandite avait retenu les services de cette firme d’experts-conseils en informatique bien connue pour organiser et effectuer des démonstrations du logiciel à d’éventuels clients, notamment certains associés responsables des TI pour les cabinets Coopers & Lybrand, Ernst & Young et Deloitte Touche, ainsi qu’à Revenu Canada. Il semble que les démonstrations aient été données avant et après la présentation offerte à Revenu Canada. Voici le constat accablant posé par ces clients potentiels (voir l’onglet 296) :

 

[traduction]

 

Les clients de notre consultant ont été unanimes : aucun d’entre eux n’envisagerait d’utiliser AGENSYS avant que nous puissions offrir une interface Windows. Nous devons également démontrer que le logiciel possède des capacités d’interface pour les bases de données et les communications. Il nous faudrait également, par l’intermédiaire d’un groupe indépendant tel CGI, documenter la fiabilité et la résistance du noyau d’AGENSYS. Il devra être exempt de bogues, et nous devrons le soumettre à des essais rigoureux et à des procédures de réception pour démontrer que tel est le cas.

 

[Non souligné dans l’original.]

 

[51]   La présentation du logiciel à Revenu Canada avait été demandée bien avant — presque un an auparavant. Revenu Canada voulait voir le logiciel et ses codes sources afin de vérifier s’il existait bel et bien, si ses performances étaient celles annoncées et s’il avait quelque valeur. Les conseillers engagés par Revenu Canada pour assister à la démonstration du 16 janvier 1996 ont jugé que le [traduction] « produit, en l’état actuel, ils n’en recommanderaient l’achat à personne » (onglet 293). L’un d’eux [traduction] « avait noté une série de lacunes fonctionnelles — une liste de douze améliorations qui devaient être apportées au produit » (onglet 299).

 

[52]   Mentionnons également l’évaluation faite par M. Phil Irving[61], chef des produits techniques, qui tient des propos tout à fait différents de ce qu’on peut lire dans « The Future of Information Management » (« L’avenir de la gestion de l’information ») au sujet de la simplicité d’utilisation du logiciel. Voici ce qu’il écrit dans son rapport provisoire du 20 février 1996, soit quelques jours après sa rencontre avec M. Kale (onglet 306) :

 

[traduction]

 

4.3       La conception et l’élaboration d’un projet

 

1.         La conception d’un projet est un processus complexe qui requiert à la fois une bonne compréhension des besoins opérationnels et de solides connaissances en conception et en développement de bases de données. Par conséquent, il n’est pas recommandé de confier l’élaboration d’une solution à des concepteurs inexpérimentés. Soulignons que la version AGS ne devrait pas être vendue comme un outil de développement d’applications qui est à la portée du premier venu.

 

[…]

 

3.         Les travaux de développement de la version AGS, qui risquent de se révéler très longs, pourraient très bien être pris en charge par une équipe composée de programmeurs du client et d’Agensys, équipe qui travaillerait en collaboration avec les techniciens de bases de données et sous leur direction.

 

[Non souligné dans l’original.]

 

[53]   On trouve enfin l’appréciation globale de M. David Gillman dans son plan d’affaires du 13 août 1996 (onglet 336) :

 

[traduction]

 

Le choix de commercialiser le produit de Howard Kale en tant qu’outil de développement se heurte à une forte résistance pour plusieurs raisons. Premièrement, on a souvent fait allusion aux contraintes techniques relatives à l’IUG, aux multiples plateformes, à une méthode viable, à l’historique des révisions. Deuxièmement, la concurrence est énorme et bien ancrée. Troisièmement, aucune orientation claire n’a été définie concernant le créneau que le produit était censé occuper. On a misé sur de supposés avantages concurrentiels qui n’en étaient pas.

 

Malgré les limites techniques et autres, je crois que nous pouvons trouver un débouché pour le produit en tant qu’environnement de développement orienté objet, et nous devrions nous concentrer entièrement sur ce marché […]

 

[…]

 

Approche

 

Il nous faudra au moins un an pour créer et commercialiser une gamme de produits qui nous permettra de nous attaquer à ce marché. Nous devrions privilégier une approche consistant à obtenir du succès dans la sphère des services et des applications au moyen de l’outil et de la méthode, à constituer une banque de nos réussites et des repères indépendants, avant de démarcher toutes les entreprises, sauf les plus petites, en leur présentant l’outil comme un produit en soi. Pour le moment, il est encore trop tôt pour consacrer du temps et de l’argent à vendre un produit non éprouvé. Et j’insiste sur le « pour le moment ». Lorsque tous les problèmes techniques seront réglés et que les caractéristiques de nos produits seront bien comprises des acteurs du marché, nous devrions être en mesure d’en récolter les fruits.

 

[Non souligné dans l’original.]

 

 

[54]   Comme le montrent les extraits qui précèdent, M. Morley essayait, de toute évidence, de vendre à des acheteurs potentiels un produit logiciel qu’on prétendait doté de fonctionnalités très attrayantes qui, dans une large mesure, n’étaient pas en service à l’époque où des efforts de commercialisation étaient faits, de 1994 à 1996. Non seulement le logiciel n’était pas en mesure de remplir toutes les promesses, mais ni la société en commandite ni Marketing ne possédaient, en 1994 et en 1995, les ressources humaines nécessaires pour mettre au point les améliorations et développer des applications opérationnelles. Il leur fallait se fier à Agensys T&C, laquelle devait, conformément à la convention d’acquisition de 1993, livrer certaines des améliorations requises, décrites comme étant le logiciel de soutien, [traduction] « dans un délai raisonnable suivant une demande écrite formulée en ce sens » et à livrer toute autre amélioration selon des conditions commerciales raisonnables. Puisque, apparemment, Agensys T&C n’avait pas d’employés, il lui fallait pouvoir compter sur Agensys U.S. Or, la société en commandite et Agensys U.S. n’étaient liées par aucun contrat!

 

[55]   À la lumière de tout ce qui précède, il n’est pas étonnant que les vérificateurs de l’ADRC aient pensé que les documents promotionnels de la société en commandite avaient été préparés, et les démonstrations effectuées, dans l’unique but de répondre aux exigences fiscales de Revenu Canada[62].

 

[56]   Au cours de l’année 1996, la société en commandite a de nouveau modifié son plan d’affaires, délaissant l’approche axée sur la consultation au profit de la création d’applications génériques (l’« approche misant sur une production générique ») et donnant ainsi suite à une suggestion d’adopter l’approche d’une entreprise allemande bien connue dans le monde du logiciel : SAP. Elle a produit une première application générique, « AGS Mortgage », une solution de gestion des comptes hypothécaires canadiens, qu’elle a lancée vers la fin de 1996. Un nouveau directeur général, M. Frank Snape, était en poste depuis septembre 1996, MM. Mighton et McCann ayant décidé de quitter la société. M. Snape avait acquis une certaine expérience en gestion auprès de diverses sociétés, y compris des entreprises de technologie de pointe. Il a occupé ce poste au sein de la société en commandite jusqu’au transfert de l’actif en 1997, puis il a exercé les mêmes fonctions avec Agensys International jusqu’à ce que la société cesse ses activités, à la fin d’août 1998. Il a engagé plusieurs programmeurs afin de concevoir et de réaliser les applications opérationnelles génériques. Dans le cas du produit AGS Mortgage, il a fallu environ six mois pour établir les spécifications et six autres mois pour la programmation. Il semble que l’application ait été prête au début de 1998. Par conséquent, la majorité du travail effectué par M. Snape l’a été au profit d’Agensys International. Outre AGS Mortgage, Agensys International a travaillé au développement d’autres applications, notamment « AGS Canadian Property Management », un outil de gestion immobilière.

 

[57]   À n’en pas douter, les 12 sociétés en commandite ont été mises sur pied afin d’optimiser les avantages fiscaux offerts aux investisseurs et elles ont servi à amasser des fonds pour acquérir les droits sur le logiciel dans divers pays. L’objectif final était de transférer les droits sur le logiciel à Agensys International et d’inscrire cette dernière à une bourse comme celle du NASDAQ. À mon avis, le fait qu’il y ait eu peu de planification commerciale en 1993, sauf en ce qui concerne l’achat du logiciel et l’obtention de capitaux pour la société en commandite et au moins l’une des 11 sociétés en commandite (celle créée pour l’acquisition des droits sur le logiciel en Australie et en Nouvelle‑Zélande), ne conduit pas forcément à la conclusion que la société en commandite n’exploitait pas d’entreprise en 1993 ou qu’aucune société de personnes valable ne pouvait être formée. Dans les débuts de son existence, il est normal qu’une société de personnes consacre ses énergies à l’obtention des fonds nécessaires au financement de ses activités commerciales. Dans son argumentation écrite, l’avocat de l’intimée ne prétend pas que la société en commandite n’a pas exploité d’entreprise de 1994 à 1996. Il concentre essentiellement son attention sur l’année d’imposition 1993. Or, selon moi, si les activités entreprises par la société en commandite à partir de 1994 entrent dans le cadre de l’exploitation d’une entreprise, c’est donc que cette entreprise existait en 1993, à l’époque où on s’affairait à trouver du financement et à planifier les premières étapes de la commercialisation du logiciel.

 

[58]   En dépit des nombreuses lacunes qui semblent caractériser les moyens adoptés par la société en commandite pour l’exploitation de son entreprise, la Cour suprême du Canada a statué que les tribunaux devaient s’abstenir de poser un jugement sur le sens des affaires d’un contribuable. Puisque je suis tenu de suivre les décisions rendues par la Cour suprême, je conclus que la société en commandite a été dûment constituée en juin 1993, qu’elle exploitait une entreprise en vue de réaliser un bénéfice et que le logiciel a été acquis en vue de générer un revenu. Je suis d’avis que M. Morley a véritablement essayé d’exploiter le logiciel en vue de réaliser un bénéfice. Il est vrai qu’il a été capable de fausses déclarations dans le cadre de ses efforts de commercialisation[63], mais il m’est impossible de conclure que l’abondante correspondance qu’il a produite et les nombreuses réunions auxquelles il a assisté dans le but de promouvoir le logiciel et les services de la société en commandite s’inscrivaient dans une opération de camouflage destinée à donner la fausse impression qu’une entreprise était exploitée. Je ne pense pas qu’il aurait fait autant de démarches auprès de gouvernements et de relations d’affaires en l’absence de véritables objectifs commerciaux. Une note rédigée le 23 avril 1994 (onglet 74, page 2) illustre ce point :

 

[traduction]

 

Il y a un autre aspect dont je me soucie : nos réputations personnelles. […] J’arrive à tenir mes engagements en matière de ventes parce que les gens savent qui je suis et m’accordent leur confiance. Aucun de nous ne souhaite risquer sa réputation en raison de problèmes de planification et de gestion au sud de la frontière […]

 

 

Au fil des mois et des années, la société en commandite a engagé du personnel plus compétent pour travailler dans les bureaux loués réservés à ses activités. Les efforts se sont progressivement intensifiés.

 

[59]   Les raisons de l’échec de cette entreprise sont nombreuses. De toute évidence, la planification et la mise en oeuvre laissaient grandement à désirer. Peut-être faut-il attribuer ces lacunes à la trop grande importance accordée aux avantages dérivés des abris fiscaux. Les exemples abondent où des encouragements fiscaux ont donné des résultats contraires à ceux voulus par le législateur. Précisons en outre que ce phénomène est plus marqué lorsque les encouragements ne sont pas utilisés de la façon prévue, comme c’est le cas en l’espèce. Je suis convaincu que Agensys U.S. a connu plus de prospérité en développant des applications opérationnelles aux États‑Unis avec l’aide du logiciel, pour lequel elle n’avait qu’à verser des redevances[64].

 

[60]   Quoi qu’il en soit, les activités commerciales de la société en commandite constituaient une entreprise pour M. Morley et, suivant l’article 96 de la Loi, il a le droit de déduire de ses revenus sa part des pertes subies par l’entreprise, calculées au niveau de la société en commandite. Le montant de ces pertes dépendra des réponses aux autres questions en litige.

 

(C)     Quel a été le coût du logiciel acquis par la société en commandite?[65]

 

[61]   On trouve, au paragraphe 21 de la réponse à l’avis d’appel modifié, la liste de certains faits relatifs au coût du logiciel sur lesquels le ministre s’est fondé pour établir la cotisation de M. Morley :

 

[traduction]

 

t)          ni Agensys Corporation ni la présumée société en commandite ne voulaient que le billet pour achat crée quelque obligation légale;

 

u)         le billet pour achat n’a pas imposé à la [société en commandite] l’obligation absolue de payer quelque somme à son porteur;

 

[…]

 

dd)      ni la présumée société en commandite ni l’appelant ne voulaient que le billet de souscription crée quelque obligation légale;

 

ee)       jamais la présumée société en commandite ou Agensys Corporation n’a eu l’intention de réclamer la somme indiquée dans le billet de souscription;

 

ff)        le billet de souscription n’a pas imposé à l’appelant l’obligation absolue de payer quelque somme au bénéficiaire qui y est désigné.

 

[62]   L’avocat de M. Morley a fait valoir que la preuve présentée à l’audience établissait, prima facie, que le coût du logiciel s’élevait à 12 150 000 $. Essentiellement, il fonde son argument sur les clauses de la convention d’acquisition du logiciel et du billet pour achat ainsi que sur le document constatant le paiement de ce billet par la cession des billets de souscription des 34 commanditaires et le versement des 960 000 $ en espèces. Il se fonde en outre sur les témoignages de M. Gamble et de M. Barisheff, lesquels ont affirmé que la convention d’acquisition du logiciel constituait l’ensemble de l’entente intervenue et ont nié l’existence d’une clause secrète[66].

 

[63]   Après examen de l’ensemble de la preuve qui m’a été présentée, j’ai conclu, selon la prépondérance des probabilités, que Agensys T&C et la société en commandite n’ont jamais voulu que le billet pour achat crée quelque obligation légale et que la première n’a jamais eu l’intention de réclamer les sommes indiquées dans le billet pour achat et les billets de souscription qui lui ont été cédés. On peut qualifier de factices le billet pour achat ainsi que les billets de souscription qui l’ont remplacé. Ils ne sont pas le reflet [traduction] « des véritables droits et obligations juridiques (s’il en est) que les parties [avaient] l’intention de créer »[67]. Je pense que le prix payé pour le logiciel se limite aux 960 000 $ réellement transférés à Agensys T&C en décembre 1993. Cette conclusion repose sur les motifs qui suivent :

 

(1)     Les billets de souscription n’ont jamais été payés. On n’a jamais demandé à M. Morley ni aux autres commanditaires de verser quelque montant au titre du remboursement du capital ou du paiement des intérêts afférents à ces billets.

 

(2)     Agensys T&C, en sa qualité de vendeur, n’a pas corroboré le fait que le prix d’achat du logiciel était réellement de 12 150 000 $. Ni M. Kale, ni aucun représentant d’Agensys T&C n’ont témoigné à l’audience.

 

(3)     M. Gamble n’a pas donné un témoignage digne de foi sur la question du prix payé pour le logiciel.

 

(4)     La JVM du logiciel ne dépasse pas 960 000 $.

 

(5)     Selon la dénonciation des ES, un des commanditaires (l’« associé A ») a indiqué qu’il n’avait jamais été question de payer les billets de souscription.

 

(6)     Les billets de souscription correspondaient tout au plus à l’obligation éventuelle de verser des redevances au moment où des profits seraient enregistrés, le cas échéant.

 

 

(1)     Les billets de souscription n’ont jamais été payés

 

[64]   La preuve initiale la plus convaincante de l’intention des parties de limiter le prix du logiciel à 960 000 $ réside dans le fait que seul ce montant a été payé à Agensys T&C. Plus de dix années après l’acquisition présumée du logiciel en décembre 1992, les billets de souscription n’avaient toujours pas fait l’objet du moindre paiement de la part des commanditaires. Or, des paiements partiels venaient à échéance en mars, en juin et en septembre 2003, indépendamment de toute répartition de bénéfices nets par la société en commandite (ou du versement de dividendes par Agensys International). À cet égard, M. Morley a déclaré qu’au 15 septembre 2003, ces paiements n’avaient pas été exigés, car le seul recours dont Agensys T&C disposait contre lui et les autres anciens commanditaires par suite du règlement d’un différend en 1996 se limitait aux actions d’Agensys International, actions qui n’avaient plus aucune valeur du fait de la perquisition et de la saisie qui avaient eu lieu le 8 octobre 1997 et de la cessation des activités d’Agensys International en août 1998. Les actions avaient été transférées aux associés de la société en commandite au moment de sa dissolution, le 28 février 1997, qui avait fait suite au transfert en franchise d’impôt des actifs de la société en commandite en faveur d’Agensys International, le 1^er janvier 1997.

 

 

(2)     Absence de corroboration de la part d’Agensys T&C ou de M. Kale

 

[65]   Aucun représentant d’Agensys T&C n’est venu témoigner à l’audience, pas même M. Kale ou les mandataires de la société avec lesquels traitait la société en commandite à l’époque de l’acquisition du logiciel et à celle du différend susmentionné. Pour expliquer l’absence de M. Kale, l’avocat de M. Morley invoque le témoignage de M. Barisheff et avance [traduction] « que les relations avec Howard Kale étaient devenues conflictuelles ». En fait, voici ce qu’a été la réponse exacte de M. Barisheff lorsque je lui ai demandé, à la fin de son témoignage, ce qu’il était advenu de M. Kale : [traduction] « Je n’en ai pas la moindre idée. […] Lui et moi n’étions pas en bons termes depuis la poursuite. » Or, de mémoire,  aucune déclaration du genre n’a été faite s’agissant de M. Morley ou encore de M. Gamble, le promoteur de la société en commandite, l’unique propriétaire effectif du commandité et aussi, d’après les états financiers de la société en commandite, l’unique propriétaire effectif de Marketing. Aux dires de M. Gamble, M. Barisheff était un simple intermédiaire. Il aurait été fort utile d’entendre les explications de M. Kale quant à la façon dont les conditions de la convention d’acquisition de 1993 ont été négociées en 1992 et en 1993 et de connaître sa version de la teneur du différend de 1996 et la raison pour laquelle il a consenti à un règlement étonnamment avantageux pour les 12 sociétés en commandite et leurs associés, règlement qui prévoyait la conversion de billets autorisant un recours général en billets à recours limité aux actions d’une société fermée. Même si M. Kale avait refusé de témoigner, il existait des moyens pour l’y contraindre[68]. J’ai tiré une conclusion défavorable de l’absence de M. Kale et j’en déduis que son témoignage aurait nui à la thèse avancée par M. Morley. À cet égard, j’adopte l’approche préconisée par le juge Sarchuk dans la décision Enns v. Minister of National Revenue, 1987 CarswellNat 397, paragraphe 9, [1987] 1 C.T.C. 2256, 87 DTC 208, et par bon nombre d’autres juges de la Cour dans d’autres affaires :

 

Dans l’ouvrage de Sopinka et Lederman, The Law of Evidence in Civil Cases, les auteurs font remarquer ce qui suit au sujet des conséquences de l’omission de faire comparaître un témoin, je cite :

 

[traduction] Dans l’affaire Blatch c. Archer, (1774) 1 Cowp. 63, p. 65, Lord Mansfield a déclaré :

 

Il existe certainement un principe voulant que les faits soient appréciés à la lumière de la preuve que l’une des parties était en mesure de produire et que l’autre partie était en mesure de réfuter.

 

L’application de ce principe a conduit à établir une règle bien connue selon laquelle l’omission d’une partie ou d’un témoin de produire une preuve que la partie ou le témoin était en mesure de produire et qui aurait peut-être permis d’élucider les faits, fonde la Cour à déduire que la preuve de la partie ou du témoin en question aurait été défavorable à la partie à laquelle l’omission a été attribuée.

 

Dans le cas d’un demandeur auquel il incombe d’établir un point, l’effet de cette déduction peut être que la preuve produite sera insuffisante pour s’acquitter du fardeau de la preuve. (Levesque et al. c. Comeau et al., [1970] R.C.S. 1010; (1971), 16 D.L.R. (3d) 425.)

 

[Soulignement ajouté par le juge Sarchuk.]

 

 

(3)     Absence d’éléments de preuve crédibles

 

La description imprécise et confuse du déroulement des négociations relatives au prix d’acquisition

 

[66]   Il convient, à ce stade‑ci, d’examiner en profondeur les faits pertinents entourant la négociation du prix du logiciel en 1992 et en 1993 et le prétendu différend qui a surgi au milieu de 1996. M. Gamble a déclaré qu’au moment où la décision d’acquérir le logiciel a été prise, au milieu de l’été 1992, il a choisi de désigner M. Barisheff comme mandataire pour se distancier de M. Kale, qui représentait apparemment Agensys T&C dans le cadre des négociations. M. Gamble a dit avoir limité les contacts avec M. Kale pendant que ce dernier négociait avec M. Barisheff. On se serait donc attendu à ce que M. Barisheff puisse faire la lumière sur ces négociations lors de son témoignage. Fait étonnant, il n’a pu en donner qu’une vague description. Par exemple, il n’a pas pu dire quel était le prix de départ demandé par M. Kale[69]. Il se souvenait seulement d’une vague déclaration de M. Kale selon laquelle l’entreprise qui serait propriétaire du logiciel pourrait valoir une centaine de millions de dollars. M. Barisheff avait même oublié le montant de l’offre de départ qu’il avait lui‑même présentée au nom de M. Gamble : il avait un vague souvenir qu’elle était de 10 millions de dollars. Il n’a pas non plus pu donner bien des précisions quant à la façon dont on avait arrêté la fraction du prix à verser au comptant. Il a simplement déclaré que M. Kale demandait initialement quelque deux millions de dollars en espèces[70]. M. Gamble a offert une version différente des faits, mais, en définitive, l’acquéreur du logiciel ne savait pas grand‑chose du déroulement des négociations. Il a répondu de la manière suivante à mes questions (à la page 938 de la transcription de son témoignage) :

 

[traduction]

 

Q.  Si vous aviez offert de payer comptant en totalité, quel montant aurait été versé?

R.  Il voulait obtenir 12 millions.

Q.  12 millions.

R.  Ou 14 millions, peu importe. Il voulait de l’argent comptant. C’était sa première exigence. Et nous avons répondu que nous n’avions pas ces 12 millions.

Q.  12 ou 14?

R.  Eh bien, les chiffres ne sont peut-être pas tout à fait ceux-là. Je dis simplement que…

Q.  Parce qu’encore une fois, ce n’était pas vous?

R.  Je ne m’occupais pas de cela, je ne peux donc encore une fois que faire des conjectures.

 

[67]   Le seul échange que M. Gamble a reconnu avoir eu avec M. Kale durant les négociations est survenu à l’occasion d’un coup de fil que ce dernier lui a donné pour se plaindre de la lenteur du processus. Il lui a répondu qu’il ne tenait qu’à lui de présenter une offre plus acceptable. Selon M. Barisheff, à un moment donné, M. Kale aurait demandé 12 150 000 $, un prix que M. Gamble aurait accepté au début de l’automne 1992.

 

[68]   M. Gamble a déclaré qu’afin de déterminer si le prix était juste, il a consulté son neveu, qui travaillait à CGI et s’y connaissait un peu. Toutefois, le neveu ne s’est pas présenté pour attester ce fait. M. Gamble a également indiqué qu’il avait parlé à M. Batton afin d’obtenir de l’information sur des logiciels comparables sur le marché américain. Il convient de rappeler que M. Batton n’a jamais accepté de verser immédiatement une somme importante lorsqu’il a acquis le droit non exclusif de commercialiser le logiciel aux États‑Unis par l’intermédiaire d’Agensys U.S. : la seule contrepartie qu’il a fournie était sous la forme d’un arrangement du même type qu’un accord de redevances.

 

  La date d’acquisition

 

[69]   Aux dires de M. Gamble, le logiciel aurait été acquis le 20 décembre 1992 conformément à la convention d’acquisition de 1992. Cette convention ne renferme aucun énoncé quant à la date de sa signature; on peut seulement y lire la mention [traduction] « en date du 20 décembre 1992 ». M. Gamble soutient que le document a été rédigé par les avocats d’Agensys T&C et qu’il l’a signé le 20 ou le 21 décembre 1992 au cabinet de son avocat spécialisé en immobilier, M^e Kutner, après examen du document par ce dernier et avant les vacances de Noël. M^e Kutner n’a pas témoigné afin de corroborer les dires de M. Gamble, et son absence n’a pas été expliquée. Lorsqu’on a demandé à M. Barisheff de confirmer que M. Gamble avait signé la convention d’acquisition de 1992 au cabinet de M^e Kutner, il a répondu : [traduction] « [J]’ai l’impression que cette convention et d’autres documents concernant la société en commandite ont été signés à ce moment ». Ce n’est pas ce qu’on peut appeler une corroboration très solide[71].

 

[70]   Lors de son témoignage, M^e Beach a déclaré qu’il avait rencontré M. Gamble au début de décembre 1992 et qu’on lui a alors demandé de [traduction] « commencer à réfléchir aux opérations commerciales et aux documents qui seront nécessaires à cet égard »[72]. Il a également affirmé avoir été consulté au sujet de la convention d’acquisition de 1992 [traduction] « à l’époque où sa rédaction était en cours »[73]. Cette description ne cadre pas avec la version des faits de M. Gamble. Celui‑ci a affirmé que M^e Beach a été engagé au début de 1993 et il a fait référence à M^e Kutner uniquement en tant qu’avocat ayant examiné la convention d’acquisition de 1992. Même s’il a déclaré que la société en commandite avait conclu en 1992 la convention d’acquisition de 1992[74], M^e Beach a admis ne pas avoir rédigé ce document et, en contre‑interrogatoire, il a ajouté qu’il n’avait pas pris part aux négociations relatives à la convention, qu’il n’était pas présent au moment de sa signature et qu’il ne savait pas quand cette dernière avait eu lieu. Il est curieux qu’un avocat dont les services ont été spécialement retenus pour ses connaissances en matière de valeurs mobilières et de logiciels[75] n’ait pas rédigé un tel document et n’ait pas été consulté en 1992 — puisque, selon la version des faits de M. Gamble, il ne l’a pas été. Il est fort possible que M^e Beach ait été consulté au sujet de la convention, mais seulement en 1993. La convention d’acquisition de 1993, qu’il a rédigée, renvoie à la convention précédente. Pour les motifs exposés ci‑dessous, je pense que M^e Beach se méprend – c’est le moins qu’on puisse dire – lorsqu’il affirme que cette entente est intervenue en décembre 1992 et qu’il a été consulté à son sujet en 1992.

 

[71]   La déclaration de M. Gamble selon laquelle il aurait signé la convention d’acquisition de 1992 au bureau de son avocat le 20 ou le 21 décembre 1992 avant les vacances de Noël n’est pas crédible. Les motifs qui m’amènent à tirer cette conclusion sont nombreux. Premièrement, dans un affidavit daté du 14 février 1995 (onglet 161), M. Kale déclare que la société en commandite a acquis les droits canadiens sur le logiciel le 15 décembre 1993[76] — et non le 20 décembre 1992, comme le prétend M. Gamble. Deuxièmement, dans une lettre portant la date du 13 janvier 1995, M. Morley a informé le chef des évaluations fiscales, à Toronto, que la société en commandite avait obtenu l’évaluation pour orienter ses négociations concernant le prix d’achat[77]. L’évaluation Pritchard de 1993 porte la date du 28 juin 1993 — et non pas 1992 —, ce qui est conforme à l’affidavit de M. Kale comme à la déclaration de M. Morley. 

 

[72]   Au paragraphe 5 de la convention d’acquisition de 1992, il est stipulé que les codes sources seront livrés dans les trois jours suivant la signature de cette entente. Une convention d’entiercement intervenue entre Agensys T&C, la société en commandite et Temple Trust et portant la mention [traduction] « en date du 20 décembre 1992 » (as of the 20^th day of December, 1992, dans le texte anglais) (onglet 43) semble confirmer cet énoncé. Toutefois, selon M. Gamble, les codes sources ont été livrés un an plus tard, soit le 20 décembre 1993, au moment où la convention d’entiercement a réellement été signée[78]. Il est donc impossible de tenir pour acquis que ce qui est écrit dans la convention d’acquisition de 1992 est le reflet exact de la réalité. En fait, il appert plus logique de conclure que la convention d’acquisition de 1992 a été signée aux îles Turks et Caicos le 20 décembre 1993, en même temps que la convention d’entiercement des codes sources.

 

[73]   Troisièmement, lorsqu’un contrat est signé à une date donnée, il n’est pas d’usage chez les avocats (et cela a été confirmé par M^e Beach) de stipuler que le document est [traduction] « en date du » (« as of » that date) et d’indiquer la date en question. Cette formule est généralement réservée aux cas où le document constate une entente verbale intervenue à une date antérieure. Si la signature et la passation du contrat ont lieu le même jour, on emploiera normalement une formule du genre : [traduction] « signé le ».

 

[74]   Quatrièmement, comme l’a souligné l’avocat de l’intimée, la société désignée sous le nom d’Agensys T&C (c.‑à‑d. Agensys Corporation) avait un  autre nom le 20 décembre 1992. Les documents de la société obtenus du gouvernement des îles Turks et Caicos révèlent que Agensys T&C a été constituée le 30 mars 1992 sous le nom d’« Overseas Oil Consultants S.A. » et que ce nom n’a été modifié par celui d’« Agensys Corporation » que le 20 mai 1993!

 

[75]   Cinquièmement, je ne crois pas que M. Gamble a acquis la société en commandite à l’été de 1992 comme il l’a affirmé. Il a déclaré que la société en commandite était inactive[79] (la « société en commandite inactive »), qu’elle avait été formée en 1983 et qu’elle avait été acquise auprès de son avocat, M^e Kutner, au milieu de 1992. Les registres du commandité et les documents déposés par la société en commandite inactive auprès du gouvernement de l’Ontario n’étayent pas cette version des faits. Premièrement, l’avis de changement concernant la société en commandite inactive a été établi le 5 février 1993 seulement, et non en 1992. Dans la convention de rachat suivant laquelle M. Gamble a transféré sa part initiale dans la société en commandite, datée du 9 décembre 1993 et signée par M. Gamble lui‑même, il est écrit que celui‑ci a acquis cette part initiale le 5 février 1993[80]. Deuxièmement, même dans l’avis de changement, M. Gamble n’est pas désigné comme étant le nouveau commanditaire. L’avis reste muet sur ce point. Troisièmement, l’avis mentionne que les activités de la société en commandite inactive sont dans le domaine [traduction] « immobilier » et non dans celui de la commercialisation et du développement de logiciels. Quatrièmement, la nouvelle adresse indiquée dans l’avis n’est pas celle de M. Gamble ou de l’une de ses entreprises ayant un lien avec la société en commandite inactive. L’entreprise de M. Gamble est sise au 301 Prudential Drive, bureau 107, Scarborough (Ontario[81]), alors que l’adresse indiquée dans l’avis est le 100 Prudential Drive, bureau 112, Scarborough (Ontario). Cinquièmement, c’est le nom de la personne mentionnée dans les documents de 1983 qui figure dans l’avis du 5 février 1993, et non celui de M. Gamble, ce à quoi il serait raisonnable de s’attendre s’il avait acquis la société en commandite à cette date. Finalement, il est intéressant de constater que, dans sa lettre du 17 janvier 1993 (onglet 45), par laquelle il accepte de fournir des services de consultation à la société en commandite, M. Kale fait référence à la [traduction] « société en commandite d’Agensys » plutôt qu’à la [traduction] « société en commandite de Continental Limited », soit le nom donné à la société en commandite dans les conventions d’acquisition de 1992 et de 1993. Pourquoi M. Kale, qui avait négocié la vente du logiciel à peine quelques jours auparavant, aurait-il employé le mauvais nom, un nom qui de surcroît ne devait être adopté qu’après 1994[82]?

 

[76]   Je crois, selon la prépondérance des probabilités, que la convention d’acquisition de 1992 est un document antidaté qui a été rédigé et signé seulement après le 17 janvier 1993, soit la date à laquelle M. Kale a écrit sa lettre de représentation. Je soupçonne que c’est seulement après cette date que M. Gamble a pris conscience des répercussions de la règle de la demi‑année et qu’il a tenté de rectifier le tir avec la convention d’acquisition de 1992. Je n’ai donc pas été étonné lorsque l’avocat de M. Morley a indiqué, en cours d’audience, que son client était disposé à reconnaître que le logiciel avait été acquis seulement en décembre 1993. Néanmoins, cela ne change rien au fait que la crédibilité de M. Gamble était déjà entachée.

 

 

• La première rencontre avec M. Kale

 

[77]   Le témoignage de M. Gamble a été contredit sur plusieurs autres points. L’un d’eux concerne la description qu’il a donnée de sa toute première rencontre avec M. Kale. Aux dires de M. Gamble, cette rencontre aurait eu lieu à Toronto à la fin de l’hiver ou au début du printemps de 1992 et, outre M. Kale, M. Barisheff, l’avocat de M. Kale et deux experts en logiciel y auraient assisté. M. Gamble a indiqué qu’il y avait deux buts à la rencontre : d’une part, discuter de la possibilité que M. Gamble consente à M. Kale un prêt d’argent garanti par une hypothèque sur le ranch que celui‑ci possédait en Arizona; d’autre part, présenter un logiciel à des investisseurs canadiens. Plusieurs fois au cours de son témoignage, M. Gamble a insisté (probablement pour se distancier de M. Kale) sur le fait qu’il a assisté au début de la rencontre seulement et qu’il y est resté tout au plus 40 minutes pour discuter du prêt, ajoutant qu’il était parti avant que ne soit abordée la question du logiciel. Cette version des faits a été contredite par M. Barisheff, qui a déclaré que d’entrée de jeu, la question du prêt avait été écartée et que le but de la première rencontre à Toronto était donc uniquement de discuter du logiciel. Cette rencontre a duré deux ou trois heures et M. Gamble et lui y ont assisté d’un bout à l’autre[83].

 

 

• La gravité du différend

 

[78]   L’une des raisons alléguées pour expliquer qu’aucun paiement n’a jamais été effectué au titre des billets de souscription est que ces derniers ont été modifiés par suite du règlement d’un différend qui serait survenu en 1996. Le porteur de ces billets ne pouvait faire valoir ses droits que sur les actions d’Agensys International, et ces actions n’ont plus aucune valeur du fait que la société a fermé ses portes.

 

[79]   Le 23 septembre 1996, les 12 sociétés en commandite ont déposé à la Cour de justice de l’Ontario (Division générale) un avis d’action qui a été transmis aux avocats d’Agensys T&C et de Temple Trust. Une demande de délivrance d’un acte de procédure a été déposée le 25 septembre 1996 à la Cour suprême des îles Turks et Caicos contre ces mêmes défenderesses. Une déclaration a été préparée; toutefois, elle n’a apparemment pas été déposée à la Cour de l’Ontario. Dans la déclaration, les demanderesses réclamaient des dommages‑intérêts de 155 000 000 $ pour de présumés manquements aux conventions d’acquisition. Ces dommages‑intérêts étaient ventilés ainsi : 50 millions de dollars pour violation de la garantie relative au logiciel et manquement à l’engagement de fournir certains services en ce qui concerne, entre autres, [traduction] « le soutien, la formation, la maintenance, le développement, l’amélioration et la promotion du [logiciel] », 50 millions de dollars [traduction] « pour manquement à certaines ententes accessoires », 50 millions de dollars pour [traduction] « déclaration inexacte frauduleuse, ou déclaration inexacte faite par négligence », et 5 millions de dollars en dommages‑intérêts punitifs. Ni l’avis d’action ni la déclaration ne renferment de renseignements supplémentaires quant à ces présumés manquements. Hormis ce qui précède, on demandait la restitution de certains fonds détenus en fiducie au bénéfice de quelques‑unes des 11 sociétés en commandite.

 

[80]   Selon MM. Barisheff et Gamble et M^e Beach, la poursuite a été intentée principalement parce que Agensys T&C ne respectait pas l’obligation qu’elle avait aux termes de la convention d’acquisition de 1993 de fournir le logiciel de soutien sans exiger de frais préalables. Agensys T&C a tenté de se faire payer, ce que la société en commandite a refusé[84]. MM. Barisheff et Gamble ont aussi fait allusion au manque de soutien sur le plan technique et sur le plan de la commercialisation. M. Gamble a fait précisément référence à la campagne de marketing qui n’a jamais été lancée aux États‑Unis.

 

[81]   Bien que la cause d’action fasse consensus dans son ensemble, les témoignages divergent quant aux époques où ces manquements ont eu lieu. D’une part, selon M. Morley, il y a eu manquement concernant la livraison du logiciel de soutien plus d’un an et demi avant que la poursuite soit intentée. Selon M^e Beach, le différend concernant le logiciel de soutien a pris naissance au moins un an avant le mois de septembre 1996 (voir la page 320 de la transcription du témoignage de M^e Beach). Lors de son témoignage, M. Barisheff a confirmé que la quasi-totalité des améliorations (c.‑à‑d. le logiciel de soutien) mentionnées à l’annexe A de la convention d’acquisition de 1993 n’a jamais été livrée par Agensys T&C. D’autre part, selon M. Gamble, la livraison du logiciel de soutien a suivi son cours sans difficulté jusqu’à la moitié de 1996! Voici ce qu’il a déclaré dans son témoignage (pages 524‑526 de la transcription) :

 

[traduction]

 

            Q. Vous ai-je entendu dire que ces difficultés ont pris naissance au printemps de 1996? Est-ce bien ce que vous avez dit?

 

            R. Au printemps, c’est devenu tout à fait évident au printemps de 1996 parce que AGENSYS Corporation m’a informé qu’elle ne produirait aucun des logiciels de soutien que nous demandions sans avoir reçu de l’argent au préalable.

 

            Q. Y avait-il déjà eu des difficultés avec AGENSYS Corporation à propos d’améliorations de quelque nature que ce soit ou tout autre genre de difficulté, avant le printemps 1996?

 

            R.  Il n’y a rien eu d’important que je puisse citer. Les choses mettaient évidemment plus de temps à se faire que moi‑même, en tant que (sic), et la société en commandite, ne l’aurions souhaité. Mais elles se faisaient, nous obtenions du soutien, les choses allaient de l’avant. Et vraiment, je n’aurais jamais pensé que nous nous dirigions vers l’éventualité d’une poursuite, jusqu’à ce que j’apprenne que, en effet, AGENSYS Corporation n’allait pas respecter la convention et fournir sans frais le logiciel de soutien dont nous avions besoin, pour ensuite percevoir sa contrepartie sous forme de redevances comme nous en avions convenu.

 

            Q.  Vous avez appris que c’était là sa décision?

 

            R.  Je l’ai appris de, directement, de Howard Kale.

 

            LE JUGE ARCHAMBAULT : Et vous faites référence à quelle époque, maintenant?

 

            LE TÉMOIN : C’était, je dirais, autour du mois de mai ou juin 1996.

 

 

[Non souligné dans l’original.]

 

 

[82]   Ici encore, la version des faits donnée par M. Gamble est contredite par d’autres témoins, et de plus, elle ne cadre pas avec la preuve documentaire. Afin de bien comprendre quel était l’objet du prétendu différend, il est essentiel d’exposer la chronologie des faits à partir de la convention d’acquisition de 1993. Étant donné que les indications fournies par les différents témoins au sujet de ce différend sont d’ordre général et demeurent plutôt floues, il faut nécessairement s’en remettre à la preuve produite sous forme de documents, et ce, sans pouvoir compter, dans la plupart des cas, sur l’aide de leurs auteurs. D’après ce que je saisis, voici ce qui est arrivé. Lors de la vente, le logiciel décrit n’offrait que quelques‑unes des fonctionnalités de base[85]; plusieurs des fonctionnalités dont on avait abondamment parlé lui faisaient défaut, telles que la capacité de fonctionner sur de nombreuses plateformes (portabilité), la possibilité d’accéder à diverses bases de données et l’IUG. Agensys T&C a dû s’engager à améliorer le logiciel. Elle l’a fait en insérant dans la convention d’acquisition de 1993 une clause d’engagement (clause 4.4) à livrer le logiciel de soutien, sans exiger aucuns frais au préalable. Seule une redevance devait lui être versée, et son montant restait à négocier. Pour une raison qui m’échappe, on a exigé une demande écrite en ce qui concerne le logiciel de soutien et, selon M. Barisheff, celle-ci n’a jamais été présentée. (M. Gamble ne savait pas si une telle demande avait été présentée.)

 

[83]   Agensys T&C n’avait pas d’employés pour développer le logiciel. Elle a donc dû faire appel à un consultant, M. Kale[86]. Dans sa correspondance, Agensys T&C était toujours représentée par un avocat des îles Turks et Caicos. Le 7 avril 1994, après la vente du logiciel à la société en commandite, Agensys T&C a conclu une entente (l’« entente de développement de 1994 ») (onglet 68) avec Agensys U.S. afin que celle‑ci prenne le relais de M. Kale pour le développement des prochaines améliorations du logiciel. Le premier projet entrepris dans le cadre de cette entente est décrit dans un [traduction] « énoncé des travaux » daté du 14 avril 1994 (onglet 68). Les améliorations (les « améliorations de 1994 ») qui devaient être développées correspondaient dans une large mesure au logiciel de soutien : elles comprenaient cinq nouvelles plateformes d’exploitation[87], l’IUG pour cinq environnements différents et cinq protocoles de liaison. Suivant ce qui était prévu dans l’énoncé des travaux, le coût total de ces améliorations devait être supporté par [traduction] « les organisations qui acquièrent les droits exclusifs dans un pays ». Agensys U.S. devait facturer les travaux en cours à Agensys T&C. La moitié du prix devait être reçu [traduction] « des pays dont la capitalisation était assurée au moment de la livraison du code objet bêta » (onglet 68) (c.‑à‑d. de celles des 12 sociétés en commandite qui, à cette date, avaient amassé les fonds dont elles avaient besoin) et le solde, de ces mêmes pays, une fois que le projet serait livré et accepté. La quote‑part de la société en commandite correspondait à 5,2 % du prix[88].

 

[84]   Le 1^er décembre 1994, Agensys T&C (par l’intermédiaire de son avocat) a informé M. Gamble que les versions bêta des améliorations de 1994 avaient été reçues, ajoutant que [traduction] « conformément à l’entente, la moitié de la somme convenue pour le développement est due et exigible immédiatement » (onglet 145). La société en commandite a effectué le premier versement de 22 620 dollars américains. Cette somme représentait la moitié de la quote‑part que la société en commandite devait payer sur le coût total de 870 000 dollars américains, ventilé dans la facture jointe à la demande de paiement. La liste des plateformes énumérées dans cette facture est la même que celle figurant dans l’énoncé des travaux, à l’exception de la substitution de Windows NT 3.5 par NT Win 16 et NT Win 32 et de l’ajout de la plateforme SCO d’Unix, laquelle était censée avoir été livrée avec le logiciel décrit, en 1993. Une somme de 60 000 dollars américains était facturée pour chacune des sept plateformes. Un relevé de compte non daté de la Toronto‑Dominion révèle que 22 620 $ ont été transférés à l’avocat d’Agensys T&C aux îles Turks et Caicos. La note de M. Batton du 8 février 1995 confirme que la première moitié a été payée par la société en commandite (et deux des 11 sociétés en commandite) (onglet 60).

 

[85]   Dans une note qu’il lui a adressée le 19 février 1995 et qui traite de la vérification de l’établissement de la valeur du logiciel effectuée par Revenu Canada, M. Morley rappelle à Larry Gamble que le logiciel de soutien devait être fourni sans frais (à l’exception d’une redevance ou de droits comparables) et qu’il sera nécessaire de procéder à la modification de la convention d’acquisition de 1993 dont M. Gamble a [traduction] « discuté avec Howard » afin de traiter de [traduction] « la récente facture de John Batton » (onglet 167). Dans le cas contraire, [traduction] « les investisseurs pourraient également douter de l’engagement antérieur que vous avez pris de verser [à Agensys T&C] 60 000 dollars américains ». M. Morley recommande que [traduction] « les modalités de base du développement et du paiement du logiciel de soutien [soient] confirmées avec Howard et [que] John Batton en soit informé ».

 

[86]   Lors d’une réunion de la direction tenue deux jours plus tard, le 21 février 1995 (onglet 177), Paul Mighton a suggéré que la société en commandite [traduction] « prenne en charge le développement du produit » et a proposé de nommer M. McCann au poste de vice‑président, technologie[89]. M. Gamble s’est dit d’avis que le [traduction] « contrat de McCann » et [traduction] « tous les coûts de développement devraient être financés depuis Turks et Caicos ». Il a aussi insisté sur le fait que [traduction] « Howard Kale [devait] respecter son engagement initial ». À la réunion de direction du 8 mars 1995 (onglet 182), il a été décidé que Paul Mighton établirait un plan de développement et que, en raison du [traduction] « refus [de M. Kale] d’accepter l’idée que les fonds nécessaires au développement proviennent de Turks et Caicos », le contrat de M. McCann [traduction] « [serait] financé par [Marketing] ».

 

[87]   Puisque MM. Mighton et McCann devaient se rendre sous peu à Dallas pour rencontrer M. Batton, il était prévu que le plan de développement soit élaboré dans les quelques jours suivants (onglet 186). C’est à l’occasion de cette visite à Dallas que M. Mighton a informé M. Batton que la société en commandite ne prendrait pas livraison des améliorations de 1994 et que Marketing [traduction] « allait se charger du projet de développement »[90]. La société en commandite n’a donc pas effectué le deuxième versement prévu dans l’énoncé des travaux. Ce fait est confirmé dans une lettre[91] de M. Batton à l’avocat d’Agensys T&C portant la date du 22 mars 1995 (avec copie conforme adressée à Paul Mighton).

 

[88]   On peut présumer qu’il a été question du voyage de M. Mighton à la réunion de direction du 28 mars 1995, dont le procès-verbal est toutefois devenu introuvable, même s’il a été approuvé à la réunion de direction du 11 avril 1995 (onglet 191). Lors de cette dernière réunion, M. McCann a déclaré qu’il comptait rendre visite à M. Kale, à Phoenix, le 19 avril 1995, [traduction] « afin de passer en revue tous les aspects relatifs à Agensys. Howard [Kale] a fait savoir que six interfaces sont terminées, mais nous ne les avons pas à notre bureau ». Le rapport rédigé en mai 1995 par M. McCann consécutivement à la visite effectuée à Phoenix est reproduit en partie au paragraphe 49 ci‑dessus[92]. Dans une note de M. Mighton adressée à M. Gamble le 23 mai 1995 – la première note depuis la présentation du rapport de mai 1995 de M. McCann –, on peut lire ce qui suit concernant l’état des relations avec M. Kale et Agensys U.S. : [traduction] « Il a fallu six semaines pour en arriver à une entente sur les modalités de la collaboration entre le bureau de Dallas, Howard et nous. Parmi les étapes importantes qui assureront notre réussite, mentionnons […] » (onglet 214).

 

[89]   Les procès-verbaux des réunions qui ont eu lieu en juin et un plan de développement daté du 31 juillet 1995 révèlent la présence d’une certaine collaboration avec M. Kale concernant la mise en place de certaines améliorations, notamment pour la plateforme Sun Solaris, ainsi que la [traduction] « présentation démo en réseau ». À l’assemblée générale annuelle des sociétés en commandite d’Agensys convoquée le 5 juillet 1995, il a été question du projet de fusion de la société en commandite et de la société en commandite australienne par création d’une société par actions (onglet 245). En septembre 1995, M. Mighton a préparé, à l’intention de Marketing, un plan d’affaires pour 1995‑1996 comprenant une proposition de plan de développement du logiciel qui, à en juger par son aspect, son style et son contenu, semblait plutôt destinée à promouvoir la création de nouvelles sociétés en commandite d’Agensys.

 

[90]   Le 26 janvier 1996, M. Morley a fait circuler parmi les membres du groupe de la direction les [traduction] « Objectifs de planification de 1996 » concernant, entre autres, des questions générales telles que la fusion des sociétés en commandite d’Agensys par la création d’une société par actions avant la fin d’avril 1996 (onglet 297). Le document traitait également du travail de développement du logiciel, qui serait en majeure partie confié à CGI et dans une mesure moindre, à Ron Mercier, un employé de l’équipe technique, M. Kale en étant exclu. Les tâches attribuées à CGI comprenaient la [traduction] « conception d’une architecture client‑serveur » et l’achèvement d’un [traduction] « coprocesseur Unix‑DOS  » et des [traduction] « améliorations du produit de la phase I ». Le 16 janvier 1996, lors d’une démonstration à l’intention de Revenu Canada, M. Phil Irving, de CGI, a déclaré, aux dires du vérificateur de l’évitement fiscal, que CGI [traduction] « s’occupera[it] de la maintenance » et que [traduction] « CGI participer[ait] au développement ultérieur » du logiciel. Toutefois, dans une lettre datée du 3 novembre 1997, CGI a écrit : [traduction] « [N]ous n’avons jamais été engagés pour développer les nouvelles révisions ou versions du produit » (onglet 418). Leur [traduction] « engagement consistait en de nombreuses activités, par exemple : étudier la position d’Agensys sur le marché […] développer des applications de démonstration […] et établir l’ordre de priorité des futures améliorations du produit d’Agensys ».

 

[91]   Du 12 au 15 février 1996, M. Irving se trouvait en Arizona pour rencontrer M. Kale. Dans son rapport, il déclare : [traduction] « Le présent document résume les discussions et les réalisations accomplies au cours de la période initiale de transfert des travaux […] »[93] [non souligné dans l’original] (onglet 306). Il décrit dix [traduction] « produits livrables »[94] qui ont été obtenus et déclare que [traduction] « dix pages de notes ont été écrites à la main et dix heures de conversation ont été enregistrées ».

 

[92]   Le seul autre rapport antérieur à l’action en justice intentée le 23 septembre 1996 est le rapport Gillman du 13 août 1996, qui renferme encore une autre analyse du plan d’affaires et des propositions (onglet 336). Par exemple, M. Gillman écrit au sujet du logiciel qu’il [traduction] « n’est pas complètement développé sur le plan technologique [et] a besoin d’une IUG, d’un concepteur, d’une multiplateforme, d’Internet ». Il suggère notamment de [traduction] « travailler en étroite collaboration » avec Paul Blair, de Phoenix. M. Gillman considère comme un obstacle le fait de [traduction] « s’en remettre à Howard Kale » pour ce qui est des questions de développement, mais il affirme qu’[traduction] « il n’y a pas de solution facile ». Il considère aussi comme un obstacle le fait de devoir s’en remettre à M. Kale pour les questions de soutien et il propose la solution suivante :

 

[traduction] Reconnaissons le génie d’Howard. Il est un concepteur, pas une personne qui s’intéresse aux processus continus et au soutien. Il faut créer et maintenir une structure de soutien pour notre propre développement et pour nos clients.

 

Un ou deux des nouveaux diplômés formés au sein d’Agensys recevront une formation approfondie additionnelle et seront chargés de soutenir le développement. Le coût de ces personnes sera assumé par Howard.

 

[Non souligné dans l’original.]

 

[93]   Ainsi, contrairement aux prétentions de M. Gamble, Agensys et M. Kale n’ont pas arrêté de fournir le logiciel de soutien au milieu de l’année 1996. Selon M. Barisheff, à l’exception du manuel d’utilisation et du guide de référence (qui ont été livrés en 1992), de même que des systèmes d’exploitation Sun Solaris et SCO Unix livrés en 1993‑1994 (à mon avis, plus probablement en 1994 et en 1995), le logiciel de soutien n’a jamais été livré. S’il y a eu manquement consistant en la non‑livraison de la plus grande partie du logiciel de soutien, il s’est concrétisé en mars 1995 lorsque l’on a demandé à la société en commandite de payer le deuxième versement pour les améliorations de 1994 et qu’elle a refusé de le faire. Ce n’était donc pas au milieu de 1996. S’il y a eu un manquement en mars 1995 (comme M. Morley l’a affirmé dans son témoignage), l’action aurait dû être intentée à ce moment‑là, un an et demi avant que l’avis de poursuite ne soit déposé en septembre 1996.

 

[94]   Je continue à employer les expressions [traduction] « prétendu différend » et [traduction] « s’il y a eu manquement » parce que je ne suis pas convaincu qu’un manquement est survenu. Si cela avait été le cas, il en aurait été question dans les notices d’offre des sociétés en commandite d’Agensys. Ces sociétés en commandite ont recueilli une somme d’argent considérable après mars 1995 et elles avaient conclu avec Agensys T&C des conventions d’acquisition semblables à la convention d’acquisition de 1993. Par exemple, dans la notice d’offre confidentielle concernant la société en commandite Agensys (FR) 1995 (la « société en commandite française »)[95], qui est datée du 11 septembre 1995, et celle concernant la société en commandite Agensys (UK) 1995 (la « société en commandite du Royaume‑Uni »)[96], qui est datée du 1^er février 1996, il n’est pas fait état d’un manquement commis par Agensys T&C qui aurait causé des dommages de 155 millions de dollars. Par exemple, M. Gamble a attesté, le 1^er février 1996, qu’il n’avait pas [traduction] « omis de déclarer un fait important qui [devait] être mentionné » dans la notice d’offre confidentielle de la société en commandite du Royaume‑Uni (pièce A‑4, page 34). Si des manquements graves causant des dommages de 155 millions de dollars étaient survenus, ils auraient constitué un fait important qui aurait eu une incidence sur la valeur des parts offertes par ces sociétés en commandite.

 

[95]   À mon avis, aucun manquement grave de ce genre n’est survenu parce que je crois qu’aucun engagement sérieux de fournir le logiciel de soutien n’a été pris. Comme le logiciel ne possédait pas, au moment de son achat, une grande partie des fonctionnalités qui le rendaient si particulier et si intéressant, on se serait attendu à ce que l’acheteur exige que le vendeur fournisse une version complète du logiciel de soutien selon un calendrier de livraison convenu entre eux. En l’espèce, les parties ont seulement stipulé que le logiciel de soutien devait être fourni sur [traduction] « demande écrite » de la société en commandite, et une demande écrite de ce genre n’a jamais été faite!

 

[96]   Le fait que la [traduction] « campagne nationale de publicité et de promotion aux États‑Unis » (qui était prévue au paragraphe 4.5 de la convention d’acquisition de 1993) devait être achevée au plus tard le 30 juin 1994 indique également que les engagements n’étaient pas sérieux. Dans son témoignage, M. Barisheff a reconnu que la campagne n’avait pas encore eu lieu en février 1996. Ainsi, personne ne semble s’être préoccupé de la question de savoir si ces engagements [traduction] « sur papier » étaient exécutés ou non. C’est ce qui ressort également des notices d’offre confidentielles concernant les parts de la société en commandite française et de la société en commandite du Royaume‑Uni : ces notices d’offre renferment un engagement [traduction] « sur papier » similaire et M. Gamble n’y mentionne pas que cet engagement n’a jamais été rempli dans le passé par Agensys T&C (page 11 des pièces A‑4 et A‑6)!

 

[97]   En tout état de cause, à quoi vous servirait une campagne nationale menée aux États‑Unis si votre entreprise est exploitée en France, au Royaume‑Uni ou au Canada? Pourquoi Agensys T&C aurait‑elle pris un tel engagement alors qu’elle devait recevoir uniquement des paiements de redevance de la part d’Agensys U.S. et non une somme initiale importante comme les 6 millions de dollars payés par les 12 sociétés en commandite? Quoi qu’il en soit, Agensys T&C ne pouvait pas forcer Agensys U.S. à lancer une telle [traduction] « campagne nationale » parce qu’il n’y avait aucun engagement à cet égard dans leur entente du 2 février 1994[97]. L’engagement relatif à la campagne nationale américaine ne semble pas correspondre à une réalité commerciale.

 

[98]   En ce qui concerne les obligations en matière de promotion, de formation et de consultation technique, seule cette dernière n’était pas limitée dans le temps. Elle exigeait [traduction] « deux mois‑personnes par année ». L’obligation concernant les activités promotionnelles devait s’appliquer pendant deux ans et celle en matière de formation semble avoir été limitée à la période initiale (voir le paragraphe 13 ci‑dessus).

 

[99]   L’absence de réaction à la prétendue non‑exécution des engagements indique également qu’il n’y a eu aucun manquement à la convention d’acquisition de 1993. La chronologie des faits décrite plus haut ne fait état d’aucune demande présentée par écrit à Agensys T&C ou à M. Kale de juin 1993 à août 1996[98] afin que soit livré le logiciel de soutien[99] et qu’il soit remédié à l’absence de soutien technique ou de soutien en matière de mise en marché ou au défaut de mener la campagne de marketing promise aux États‑Unis. Rien dans la preuve n’indique que le défaut de remédier aux manquements à la convention d’acquisition de 1993 mènerait à des poursuites judiciaires. La preuve n’indique pas non plus qu’il y a eu quelque menace d’action en justice lorsque M. Kale a refusé, le 8 mars 1995, de financer le contrat de M. McCann en vertu duquel celui‑ci devait fournir des services en matière de développement au groupe de la direction. La seule réaction de M. Gamble a été de payer M. McCann par l’entremise de Marketing. La preuve n’établit pas non plus qu’il y a eu quelque menace de recours en justice pour obtenir la livraison des améliorations de 1994 lorsque, le 22 mars 1995, la société en commandite a refusé de payer le deuxième versement relativement à ces améliorations, sachant très bien qu’Agensys T&C avait refusé de financer le développement qui devait être effectué par la société en commandite. À son retour de Dallas, M. Mighton a préparé un plan de développement à l’intention du groupe de la direction. Même si la société en commandite avait payé en décembre 1994 le premier versement concernant les améliorations de 1994, lesquelles n’avaient pas été livrées, la preuve ne démontre pas qu’il y a eu quelque menace d’action en justice visant à obtenir un remboursement de ce versement qui aurait été payé par erreur. (Ou a‑t‑il été effectivement payé par erreur?)

 

[100] Au contraire, dans sa note du 23 mai 1995, M. Mighton fait état [traduction] d’« une entente sur les modalités de la collaboration entre le bureau de Dallas, Howard et nous ». M. Gamble et les autres membres du groupe de la direction ont continué de parler à M. Kale, de le rencontrer et de travailler avec lui au moins jusqu’en février 1996, lorsqu’il semble y avoir eu un [traduction] « transfert » amical des outils de programmation, des dossiers, des manuels et des connaissances techniques de M. Kale. Ce transfert semble indiquer que M. Kale « fermait boutique » et prenait sa retraite de la programmation informatique, à tout le moins en ce qui concerne Agensys. Le 13 août 1996, M. Gillman a suggéré que M. Kale assume le coût d’un nouveau diplômé qui serait chargé du soutien. Le fait suivant qui est mentionné dans la chronologie est l’action en justice de 155 millions de dollars. Est‑ce possible que le refus de M. Kale — encore un autre — cette fois de prendre à sa charge le coût du [traduction] « nouveau diplômé » ait amené M. Gamble à intenter une action en justice au nom des 12 sociétés en commandite? Ce manquement valait‑il les 155 millions de dollars que la société en commandité réclamait? Valait‑il que l’on s’entende, en ce qui concerne Agensys T&C, pour convertir 11 190 000 $ de billets de souscription à recours général en billets à recours limité[100]?

 

[101] L’absence d’action en 1994 et 1995 est difficile à expliquer. Les sociétés en commandite d’Agensys ont versé à Agensys T&C des centaines de milliers de dollars chaque année de 1993 à 1996 — 6 millions de dollars au total. Des millions de dollars de billets de souscription auraient été payables à Agensys T&C. On se serait donc attendu à ce que M. Gamble soit dans une position de négociation favorable pour forcer Agensys T&C à respecter ses obligations à la lettre. Les paiements auraient pu être retenus sur les sommes versées relativement aux autres sociétés en commandite d’Agensys. On aurait pu aussi menacer de ne pas payer les sommes dues au titre des billets de souscription. Quoi qu’il en soit, il aurait été dans l’intérêt d’Agensys T&C de fournir à la société en commandite le logiciel de soutien, la formation et le soutien qui avaient été convenus parce que, pendant les dix premières années, les paiements faits au titre des billets de souscription dépendaient de l’encaisse nette pouvant être versée aux associés. Par contre, la situation serait compréhensible s’il n’existait aucune véritable obligation légale de payer ces billets.

 

[102] Par ailleurs, les circonstances relatives aux procédures judiciaires font naître beaucoup de soupçons. Dans les dix jours suivant le dépôt de l’avis d’action, les avocats de la société en commandite informaient leur homologue aux îles Turks et Caicos que MM. Gamble et Barisheff avaient [traduction] « mis au point avec Howard Kale la structure d’un projet de règlement » (onglet 347). Lorsqu’on lui a demandé si cela était exact, M. Gamble a affirmé que ce n’était pas lui, mais les avocats de la société en commandite qui avaient élaboré cette structure. Invité à donner sa version, M. Barisheff a dit que c’était les avocats ou M. Gamble. Ainsi, personne n’a négocié la structure du règlement! Personne ne voulait prendre le crédit pour avoir réalisé rapidement ce tour de force étonnant!

 

[103] Le règlement du prétendu différend a été signé le 31 octobre 1996, soit 38 jours après le dépôt de l’avis d’action. Il prévoyait qu’une nouvelle société serait constituée (Agensys International) et qu’elle acquerrait pour 1 $ tous les droits mondiaux que possédait toujours Agensys T&C[101]. Agensys T&C utiliserait une partie des fonds, qui totalisaient 907 270 $[102], qui avaient été avancés en fiducie par certaines des 11 sociétés en commandite et qui ne lui avaient pas encore été versés, pour souscrire 90 727 actions ordinaires d’Agensys International. Ces actions représentaient seulement 0,09 % de toutes les actions ordinaires[103]. De plus, Agensys T&C transférerait pour la somme de 1 $ tous les droits mondiaux sur le logiciel et sur Kammand (qui avait été acquis de M. Kale le même jour) qui n’étaient pas alors détenus par les 12 sociétés en commandite. Il y a lieu de rappeler que le plan opérationnel d’Agensys T&C qui était joint à la note de M. Batton du 8 février 1995 indiquait une valeur d’environ 95 millions de dollars au titre uniquement des droits américains relatifs au logiciel. Le prix total envisagé dépassait 228 millions de dollars. Le transfert des droits mondiaux résiduels d’Agensys T&C sur le logiciel et sur Kammand pour la somme de 1 $ n’a donc aucun sens. Tout cela est tout simplement irréel et ne correspond à aucune réalité commerciale!

 

[104] Tout ce qui précède est suffisamment ahurissant en soi, mais pas autant que le fait qu’Agensys T&C a accepté de modifier les billets de souscription des associés et de les transformer en billets à recours limité, ce recours étant limité à la valeur des actions d’Agensys International. En outre, non seulement Agensys T&C a‑t‑elle renoncé à son droit de recevoir des commanditaires les intérêts accumulés sur les billets de souscription, elle a aussi renoncé à tout intérêt futur. Lorsqu’on lui a demandé d’expliquer comment ce résultat extraordinaire avait été obtenu, M. Gamble a indiqué qu’il avait été proposé par ses avocats de Fasken. La version des faits de M. Gamble n’a pas été corroborée par M^e Beach, lequel avait témoigné avant lui et n’avait pas été interrogé à ce sujet. Aucune explication raisonnable n’a été donnée au cours des audiences quant à la question de savoir pourquoi une partie qui était apparemment libre de tout lien de dépendance comme Agensys T&C accepterait de renoncer à son plein recours contre chacun des commanditaires en échange d’un recours limité visant les actions d’une société privée nouvellement constituée. La seule explication que M. Gamble a donnée à l’audience était qu’une telle opération était permise en vertu d’une nouvelle disposition dans la législation fiscale. Même si M. Gamble disait vrai, cela n’explique pas pourquoi une partie libre de tout lien de dépendance accepterait d’accorder des conditions aussi favorables aux commanditaires. M. Barisheff a estimé le coût total du développement du logiciel de soutien à 2 millions de dollars. Ainsi, même s’il y avait un engagement valide de livrer le logiciel de soutien, Agensys T&C a renoncé à son recours général de 11,2 millions de dollars et à tous les intérêts sur cette somme à cause d’un manquement de 2 millions de dollars! À quoi s’ajoute le fait qu’Agensys T&C a accepté de renoncer (pour la somme symbolique de 1 $) à son droit de propriété sur le logiciel et sur Kammand ainsi qu’à ses autres droits territoriaux, qui incluaient les États‑Unis[104].

 

[105] Enfin, il y a lieu de mentionner que toute cette affaire s’est déroulée en secret, à l’insu de M. Snape, qui venait tout juste d’être embauché à titre de directeur général, et de M. Morley, qui faisait partie du groupe de la direction depuis 1994 et qui critiquait depuis très longtemps M. Kale et M. Batton d’Agensys U.S.

 

[106] À mes yeux, toute cette saga n’a aucun sens. Je tire deux conclusions de la preuve concernant le différend et le règlement. Premièrement, je ne crois pas que M. Gamble, en qualité d’associé contrôlant relativement aux affaires de la société en commandite et d’associé qui avait investi une somme considérable à titre de commanditaire, et Agensys T&C aient jamais voulu que cette dernière soit tenue de livrer le logiciel de soutien à la société en commandite et de lancer une campagne nationale de marketing. De plus, aucun manquement grave justifiant la réclamation de 155 millions de dollars, l’action en justice et le règlement subséquent n’a été établi. Je crois plutôt que la poursuite est une façade destinée à soutenir une conversion des billets de souscription à recours général en billets à recours limité et la renonciation aux intérêts.

 

 

(4)     La JVM du logiciel

 

[107] Le fait que la JVM des droits de commercialisation canadiens du logiciel ne dépassait pas 960 000 $ est une autre raison pour laquelle je ne crois pas que le billet pour achat a créé une véritable obligation juridique et qu’Agensys T&C avait l’intention de percevoir des sommes au titre de ses billets de souscription.

 

[108] Cela m’amène aux deux rapports d’évaluation qui ont été déposés à l’audience à titre de preuves d’expert concernant la JVM du logiciel. Le premier rapport (l’« évaluation Pritchard de 2003 » ou le « rapport Pritchard de 2003 ») a été rédigé par M. Bob Pritchard, celui‑là même qui avait préparé l’évaluation Pritchard de 1993 dont il était question dans la notice d’offre de juillet 1993. Dans son rapport de 1993, M. Pritchard estimait la JVM à 14 875 000 $ au 31 mai 1993. Selon l’évaluation Pritchard de 2003, cette valeur était de 14 300 000 $ au mois de novembre 1993, une baisse attribuable aux nouvelles conditions du marché. Les avocats de l’intimée se sont opposés au dépôt de ce rapport au motif que M. Pritchard ne devait pas être considéré comme un témoin expert, principalement parce qu’il n’était ni un expert en évaluation d’entreprise agrée, ni un analyste financier agréé, ni un comptable agréé. J’ai décidé d’admettre l’évaluation Pritchard de 2003 et j’ai laissé M. Pritchard témoigner après que l’avocat de M. Morley eut avancé que je ne devrais pas me prononcer sur l’admissibilité de cette évaluation avant d’avoir entendu le témoignage de M. Pritchard. Les avocats de l’intimée étaient aussi de cet avis. Le témoignage de M. Pritchard était utile notamment parce que l’expert de l’intimée, M. Johnson, s’était appuyé sur certaines de ses projections. M. Pritchard décrivait aussi ce qu’il avait vu et fait en 1993.

 

[109] En ce qui concerne la qualité d’expert de M. Pritchard, je conclus qu’il ne devrait pas être reconnu à ce titre, principalement parce qu’il ne détient pas de titres de compétence dans le domaine en cause. De plus, je suis loin d’être convaincu que son évaluation était complète[105]. Même si j’avais reconnu M. Pritchard à titre d’expert, je n’aurais pas adopté son opinion quant à la valeur du logiciel. Je crois que la valeur déterminée par M. Johnson est beaucoup plus proche de la JVM du logiciel en 1993. Comme nous le verrons plus loin, j’ai certaines réserves concernant même certaines de ses hypothèses, notamment les prévisions de trésorerie très favorables de M. Pritchard sur lesquelles M. Johnson s’est appuyé. Selon les estimations de M. Johnson, la JVM se situait entre 900 000 $ et 2,1 millions de dollars au 20 décembre 1992. Comme il l’écrit dans son rapport, si on lui avait demandé une estimation ponctuelle, il aurait choisi la valeur médiane de cette fourchette, soit 1,5 million de dollars. Pour établir la JVM du logiciel, M. Johnson, à l’instar de M. Pritchard, a utilisé la méthode de l’actualisation des flux de trésorerie. Ses explications et ses conclusions sont exposées dans l’extrait suivant :

 

[traduction] La méthode de l’actualisation des flux de trésorerie exige que des prévisions des flux de trésorerie discrétionnaires annuels (définis ci‑dessous) qui devraient être générés par le logiciel au cours d’une certaine période (la « période de prévision », laquelle s’étendait en l’espèce de 1992 à 2002 inclusivement) soient faites et que ces flux de trésorerie discrétionnaires projetés soient actualisés selon un taux de rendement tenant compte des risques. La valeur des flux de trésorerie discrétionnaires au-delà de la période de prévision (c.‑à‑d. après 2002) est ensuite estimée. Il s’agit de la « valeur finale ». Pour déterminer la valeur finale, il faut multiplier les flux de trésorerie discrétionnaires annuels moyens prévus qui seront générés après la période de prévision par un « multiplicateur ». La valeur finale est ensuite actualisée à la date de l’évaluation. La somme de la valeur actualisée des flux de trésorerie discrétionnaires de la période de prévision et de la valeur finale actualisée représente la juste valeur marchande du logiciel.

 

Compte tenu des problèmes causés par les bogues possibles du logiciel et des lacunes possibles des projections de M. Pritchard, nous avons déterminé la juste valeur marchande du logiciel en utilisant un processus en deux étapes :

 

•                    d’abord, nous avons déterminé la valeur non rajustée[106] du logiciel en supposant :

 

✔    que le logiciel ne comportait aucun bogue à la date de l’évaluation,

 

✔    que les projections de M. Pritchard étaient raisonnables[107].

 

Nous avons considéré que la « valeur non rajustée » du logiciel équivalait à la somme de la valeur actualisée des flux de trésorerie discrétionnaires de la période de prévision et de la valeur finale actualisée, selon les projections de M. Pritchard[108] et les taux de rendement qui nous semblaient appropriés compte tenu de la nature du logiciel et du marché sur lequel il serait vendu;

 

•                    nous avons ensuite apporté des rajustements (le rajustement relatif aux frais de développement) à la valeur non rajustée afin de tenir compte :

 

✔    des frais de développement initiaux requis pour corriger les bogues du logiciel à la date de l’évaluation, qui sont décrits dans le rapport de Brock Solutions[109],

 

✔    des lacunes contenues dans les projections de M. Pritchard concernant les frais de développement continus qui seraient requis pour que le logiciel demeure concurrentiel à long terme[110]. 

 

Le montant des rajustements relatifs aux frais de développement est égal[111] à la somme de la valeur actualisée des frais de développement initiaux et des frais de développement continus de la période de prévision et de la valeur actualisée des frais de développement continus dans le cadre de la valeur finale, selon des taux de rendement qui sont conformes à ceux adoptés pour le calcul de la valeur non rajustée.

 

En résumé, la juste valeur marchande du logiciel à la date de l’évaluation représente la valeur non rajustée moins les rajustements relatifs aux frais de développement, de la manière suivante :

 

	Valeur minimale	Valeur maximale
Valeur non rajustée du logiciel	1 600 000 $	2 638 000 $
Moins : rajustement des frais de développement	(708 000)	(514 000)
Juste valeur marchande du logiciel (montant arrondi)	900 000 $	2 100 000 $

 

 

[110] Pour déterminer ses projections concernant les flux de trésorerie et étant donné que le logiciel était nouveau, M. Pritchard a établi des hypothèses concernant la taille du marché canadien pour des produits analogues. Bien qu’il ait indiqué que ses projections relatives à ce marché sur une période de dix ans étaient semblables aux chiffres réels auxquels M. Johnson était arrivé et que celui-ci estimait raisonnables, l’un des éléments clés qui a été pris en compte pour déterminer les flux de trésorerie futurs attribuables au logiciel était une estimation du taux de pénétration du marché canadien par la société en commandite. M. Pritchard s’est fondé sur différents taux hypothétiques de pénétration pour divers segments du marché canadien. Ces taux variaient de 0,1 % pendant l’année 1993 de la période de dix ans examinée à 5 % pendant l’année 1999 de cette période; il a reconnu que ces taux étaient fondés sur [traduction] « ce qu’il supposait être raisonnable ». Il faut mentionner que ses projections étaient basées également sur le plan d’affaires axé sur le produit, qui avait été abandonné au début de 1994 et remplacé par une approche axée sur la consultation[112].

 

[111] Après avoir déterminé le montant du revenu brut qui serait tiré du logiciel pendant la période de dix ans, M. Pritchard a déterminé les flux nets de trésorerie en estimant les dépenses qui seraient engagées par le propriétaire du logiciel pendant cette période. Il s’est appuyé sur son expérience dans le domaine des affaires pour, selon lui, établir des chiffres [traduction] « d’après un processus ascendant ». Ces chiffres représentaient non pas un pourcentage du revenu, mais ce qui constituait, à son avis, une estimation juste des dépenses. Il n’y a cependant aucuns frais de développement dans ses projections[113].

 

[112] Une fois les flux nets de trésorerie[114] estimés pour la période de dix ans, M. Pritchard a déterminé ce qui constituerait un taux d’actualisation approprié pour calculer la valeur nette actualisée de ces flux de trésorerie futurs. Le taux d’actualisation de 20 % dont il s’est servi correspondait à un peu plus du double du taux moyen d’intérêt qui était alors payé sur les prêts hypothécaires de cinq ans garantis par le gouvernement.

 

[113] M. Pritchard a ensuite calculé la valeur résiduelle ou finale du logiciel à la fin de la période de dix ans. Pour établir cette valeur, il a décidé de se servir des flux nets de trésorerie générés au cours de la dixième année et il a déterminé que ce montant pouvait être maintenu au cours de toutes les années subséquentes. Il a ensuite appliqué un multiplicateur de 20 à ces flux nets de trésorerie. Ce multiplicateur était inférieur au ratio cours‑bénéfice moyen de l’indice Standard & Poor’s 500, lequel était un petit peu plus élevé que 23 en 1993. La valeur des flux de trésorerie futurs à compter de la onzième année représentait un montant substantiel : 11 186 465 $, soit environ 75,2 % de la valeur du logiciel qui avait été établie à 14 875 196 $!

 

[114] Comme je l’ai indiqué précédemment, M. Johnson a refait les calculs de M. Pritchard concernant les flux de trésorerie. Il y a apporté essentiellement trois rajustements majeurs[115]. Premièrement, il a rajusté les flux de trésorerie en y ajoutant les frais de développement. Étant donné que M. Travers avait relevé des bogues dans le logiciel à la date de l’évaluation, M. Johnson a estimé que des frais de développement initiaux de 100 000 $ à 250 000 $ seraient requis pour corriger ces bogues. Ces montants représentent seulement une fraction des frais de développement totaux requis à cette fin. Cette fraction équivaut à 5,2 % du total et constitue la part de la société en commandite [traduction] « découlant de sa capacité d’être membre d’un consortium réunissant différentes parties[116] qui seraient collectivement disposées à financer la plus grande partie des frais de développement initiaux. Si ce n’était pas le cas, les frais de développement initiaux pourraient dépasser la valeur non rajustée, ce qui ferait en sorte que la juste valeur marchande du logiciel serait nulle. » (Page 46 du rapport Johnson.)

 

[115] Outre les frais de développement initiaux, des frais de développement continus devaient être engagés [traduction] « afin de soutenir la compétitivité à long terme du logiciel ». À cet égard, M. Johnson a supposé qu’Agensys T&C apporterait les améliorations nécessaires, comme le prévoyait la convention d’acquisition de 1993, et que le coût prendrait la forme de redevances représentant de 3 % à 5 % des ventes. Cette évaluation de M. Johnson semble très raisonnable, en particulier lorsqu’on considère la suggestion de M. McCann (voir le paragraphe 49 ci‑dessus) de [traduction] « consacrer un minimum de 20 % des recettes aux activités de développement ».

 

[116] La deuxième modification importante apportée par M. Johnson consistait à utiliser un taux d’actualisation de 35 % à 40 % (au lieu du taux de 20 % adopté par M. Pritchard) pour déterminer la valeur actualisée nette des flux de trésorerie, et des multiplicateurs de 9 et de 11 (au lieu du multiplicateur de 20 adopté par M. Pritchard) pour déterminer la valeur finale. En ce qui concerne le taux d’actualisation, M. Johnson est parvenu à sa conclusion en s’appuyant sur son expérience et après avoir discuté de la question avec des dirigeants de sociétés de capital de risque qui financent des fabricants de logiciels en démarrage. Ces sociétés utiliseraient un modèle de flux nets de trésorerie similaire pour évaluer une entreprise dans laquelle elles envisagent d’investir, même si celle‑ci pourrait être le fabricant d’un seul logiciel. Elles utiliseraient un taux d’actualisation variant entre 30 % et 50 % ou parfois 60 %. Après avoir discuté avec des dirigeants de sociétés de capital de risque, M. Johnson pensait qu’un taux d’actualisation de 35 % à 40 % serait raisonnable. Il faut noter cependant que, lorsque j’ai interrogé M. Johnson et que j’ai porté à son attention le fait que ces taux d’actualisation étaient utilisés pour évaluer une entreprise en exploitation qui avait, parmi son personnel, des personnes qualifiées pour développer le logiciel et s’en servir, il a reconnu que les sociétés de capital de risque ne seraient normalement pas intéressées par un simple achat de logiciel. Elles achèteraient toujours une entreprise en exploitation.

 

[117] En ce qui concerne le multiplicateur de 20 basé sur les ratios cours‑bénéfice du marché des actions adoptés par M. Pritchard, M. Johnson a écrit qu’il était irréaliste :

 

[traduction] L’utilisation de ratios cours‑bénéfice de sociétés ouvertes établies et diversifiées est fondamentalement incompatible avec l’évaluation d’un produit unique ayant un marché restreint, comme le logiciel. En outre, […] [ce ratio] excède considérablement le multiplicateur de 5 qui a été appliqué à la valeur résiduelle pour déterminer la juste valeur marchande d’AGENSYS dans d’autres pays développés à peu près à la même époque que la date de l’évaluation[117].

 

[Non souligné dans l’original.]

 

 

[118] Le troisième rajustement important effectué par M. Johnson avait trait à la manière d’appliquer le taux d’actualisation. M. Pritchard avait adopté un multiplicateur après impôts de 20 et l’avait appliqué aux flux nets de trésorerie avant impôts. M. Johnson a appliqué ses taux d’actualisation et les multiplicateurs aux flux nets de trésorerie après impôts. Selon lui, c’est ce qu’il fallait faire pour assurer la cohésion interne des calculs. Je suis aussi de cet avis[118]. À cet égard, il a supposé qu’un acheteur serait en mesure de réaliser des économies d’impôt en demandant une DPA[119]. Comme il avait supposé que la société en commandite avait acquis le logiciel en 1992 et étant donné aussi la règle de la demi‑année, l’économie d’impôts s’est étendue sur une période de deux ans et, en conséquence, les flux de trésorerie étaient positifs en 1992 et en 1993.

 

[119] À mon avis, une approche plus prudente devrait être adoptée. L’actif en cause ici est un logiciel qui n’avait pas encore fait ses preuves. Il est vrai qu’il s’agissait d’une nouvelle version d’un logiciel existant, Kammand, qui avait été commercialisé de manière limitée aux États‑Unis. Le logiciel était cependant différent de Kammand parce qu’il employait un langage différent visant à assurer sa portabilité et son interopérabilité avec diverses plateformes et bases de données, des caractéristiques que Kammand ne possédait pas. Il ressemblait donc davantage à un nouveau logiciel. Il s’agissait aussi d’un logiciel qui avait des limites importantes et auquel des améliorations majeures devaient être apportées afin d’en faire le produit intéressant décrit dans la publicité. Le logiciel était essentiellement un produit en évolution dont le développement avait à peine commencé.

 

[120] Même si l’on supposait que le logiciel n’était pas aussi différent de Kammand, la société en commandite achetait seulement un logiciel et non une entreprise en exploitation. Comme je l’ai mentionné précédemment, des sociétés de capital de risque n’auraient pas investi dans le logiciel si du personnel compétent n’avait pas pu en poursuivre le développement. En l’espèce, non seulement la société en commandite n’avait pas, au sein de son personnel, des personnes possédant les connaissances nécessaires pour créer le logiciel, mais elle n’avait pas non plus les programmeurs capables de créer les applications opérationnelles qu’elle voulait commercialiser à l’intention des utilisateurs finaux. Chaque fois qu’il fallait présenter le logiciel, la société en commandite devait demander à M. Kale ou à un autre consultant américain ou canadien de le faire fonctionner. À mon avis, acheter seulement un logiciel, sans l’équipe qui l’a conçu, a eu pour effet d’accroître considérablement le risque qu’assumeraient normalement des sociétés de capital de risque. En conséquence, je crois qu’un taux d’actualisation plus élevé devrait être adopté. Un taux minimal se situant entre 40 % et 45 % serait requis dans les circonstances de l’espèce.

 

[121] Les prévisions de trésorerie ne sont pas basées sur une entreprise existante pour laquelle il est possible de prévoir un bénéfice probable ou de faire des prévisions de trésorerie. En l’espèce, même s’il est possible de prévoir avec une certaine exactitude l’évolution de l’ensemble de l’industrie au cours d’une période de dix ans, la détermination du taux de pénétration du marché d’un nouveau produit commercialisé par un nouveau joueur (qui ne dispose pas d’un personnel compétent) est davantage un acte de foi aveugle qu’un exercice sérieux de spéculation[120]. Le taux de pénétration dépend de tellement de facteurs, notamment de la compétence de l’équipe de marketing, des caractéristiques du produit lui‑même, des ressources financières de l’entreprise qui le commercialise et de la présence de concurrents sérieux.

 

[122] En outre, M. Pritchard s’est appuyé, pour faire ses projections, sur l’hypothèse que le logiciel intéresserait les grandes et les moyennes entreprises qui l’utiliseraient principalement pour l’une des trois applications décrites à la page 19 du rapport Johnson :

 

[traduction]

•                    applications client-serveur – À la date de l’évaluation, de nombreuses organisations décidaient de passer rapidement aux applications client-serveur et aux applications distribuées. Cette transition s’avérait nécessaire en raison du remplacement des terminaux par des postes de travail intelligents. Ces nouvelles applications client-serveur permettaient aux postes de travail et aux serveurs de fonctionner ensemble dans un réseau local ou étendu. Le logiciel était annoncé comme la solution idéale pour exploiter ces applications en raison de sa compatibilité avec toutes les plateformes technologiques, compatibilité qui lui permet d’acheminer des données de l’une à l’autre;

 

•                    rationalisation des « anciennes applications » – le logiciel a été conçu pour répondre aux besoins de projets portant sur la migration d’applications par terminal sur ordinateur central destiné à un environnement client-serveur distribué;

•                    réingénierie des « anciennes applications » – à la date de l’évaluation, l’on s’attendait à ce que les prochaines versions du logiciel soient conçues spécialement pour prendre en charge la réingénierie des anciens systèmes qui utilisent des processus et des données distribués sur des ordinateurs centraux, des serveurs et des ordinateurs personnels. Le logiciel était annoncé comme solution de services de logiciels intermédiaires et de messagerie uniques qui prendrait en charge la réingénierie progressive des applications exploitées sur ordinateur central.

 

 

[123] En fait, comme M. Johnson l’a écrit à la page 21 de son rapport, M. Travers [traduction] « a conclu que le logiciel ne possédait pas, à la date de l’évaluation, bon nombre des caractéristiques nécessaires pour qu’il soit concurrentiel relativement aux applications et à la clientèle visées ». M. Johnson a ajouté que [traduction] « le logiciel :

 

•        convenait mieux à des applications destinées à un seul utilisateur ou à un petit groupe de travail;

 

•        ne possédait pas les caractéristiques qui étaient essentielles pour les grandes et les moyennes entreprises qui voulaient remplacer leurs anciens systèmes ou leurs systèmes d’ordinateur central[121].

 

[124] Il est consternant de découvrir que, selon les projections de M. Pritchard, 80 % des ventes projetées en 1994 et 1995 allaient provenir des comptes relatifs à des ordinateurs centraux (administration publique et autres) et des comptes de valeur moyenne (administration publique et autres). Inutile de dire que cela ajoute peu de crédibilité au travail de M. Pritchard.

 

[125] De plus, j’estime qu’il est difficile d’attribuer une grande valeur résiduelle à un logiciel qui a été acheté par une équipe qui ne possédait pas les compétences nécessaires pour le fabriquer et le développer et qui dépendait d’une société non résidente établie aux îles Turks et Caicos sans aucun employé pour assurer son développement. Il faut aussi tenir compte du fait que le logiciel devait affronter la concurrence d’entreprises bien établies qui commercialisaient des logiciels bien connus. Le marché canadien des logiciels de programmation comme celui en cause en l’espèce était saturé à l’époque[122]. À mon avis, il aurait été très difficile pour une nouvelle entreprise lançant un nouveau logiciel de s’établir dans ce marché et de concurrencer les autres entreprises jouissant d’un appui financier important. La probabilité qu’il y ait une valeur résiduelle après dix ans était très mince. L’histoire des logiciels est truffée d’exemples de bons logiciels qui ne sont restés sur le marché que pendant quelques années. De plus, il est important d’accorder un certain poids à l’information que M. Johnson a obtenue auprès de M. Batton, le président d’Agensys U.S., qui connaissait très bien le logiciel[123] et qui estimait sa durée de vie à sept ou huit ans[124] et le risque d’échec à 80 % ou 85 %.

 

[126] Il y a aussi le passage suivant qui figure dans un livre blanc technique préparé par la société Object Systems Inc.[125] :

 

[traduction]

Taux d’échec des projets de logiciel

 

Le National Research Council des États‑Unis a récemment signalé que jusqu’à 95 % de tous les projets de logiciel ne sont pas terminés de manière satisfaisante à temps pour que les utilisateurs auxquels ils étaient destinés puissent s’en servir. Indignée, l’industrie du logiciel a répondu que le taux d’échec réel correspondait à seulement 70 % de tous les projets lancés. Peu importe d’où viennent les chiffres, le taux d’échec des projets de logiciel est totalement inacceptable et ne serait toléré dans aucune autre discipline professionnelle.

 

[127] À mon avis, des taux d’actualisation plus élevés — 40 % et 45 % par exemple — doivent être utilisés pour tenir compte du risque plus important qui est lié à l’acquisition d’un produit assorti seulement de droits territoriaux limités qu’à l’acquisition d’une entreprise, même une entreprise fabriquant un seul logiciel. En outre, étant donné le risque élevé que le produit ne reste pas longtemps sur le marché, il serait préférable d’utiliser des multiplicateurs plus faibles — de 7 et 9, par exemple — pour évaluer les flux de trésorerie postérieurs à la période de prévision.

 

[128] J’estime qu’une autre modification doit être apportée au calcul de la JVM effectué par M. Johnson. Elle concerne le rajustement visant à tenir compte des frais de développement initiaux des solutions aux bogues détectés par M. Travers. Pour les motifs qui suivent, je crois qu’aucun rajustement ne devrait être effectué. Premièrement, je ne suis pas à l’aise avec l’estimation du coût de ces solutions. L’information disponible est insuffisante pour qu’on puisse tirer une conclusion à cet égard. Le fait que la valeur inférieure fait l’objet d’un rajustement complet alors que la valeur supérieure fait l’objet seulement d’un rajustement partiel me pose également problème. Enfin, je crois qu’un vendeur a l’obligation de livrer un logiciel qui est en état de marche et, en conséquence, d’en corriger tous les bogues qu’il comporte à l’origine. Quoi qu’il en soit, j’ai adopté un taux d’actualisation plus élevé, ce qui compense en partie l’élimination du rajustement initial relatif aux frais de développement; M. Johnson aurait fait de même s’il n’avait pas tenu compte de ce facteur[126].

 

[129] Enfin, l’évaluation de M. Johnson a été faite en date du 20 décembre 1992. Comme je suis parvenu à la conclusion que le logiciel n’a pas été acquis avant le 30 juin 1993, lorsque la nouvelle version de la convention d’acquisition a été signée, les calculs de M. Johnson doivent être modifiés en conséquence; en particulier, l’économie d’impôt liée au coût du logiciel doit être reportée d’un an.

 

[130] Comme l’indiquent de manière plus détaillée les tableaux joints aux présents motifs, la JVM résultant des rajustements décrits ci‑dessus qui sont apportés aux calculs de M. Johnson serait la suivante :

 

	Valeur minimale	Valeur maximale
Valeur non rajustée du logiciel	798 500 $	1 356 000 $
Moins : rajustements relatifs aux frais de développement	(250 900)	(220 900)
Juste valeur marchande du logiciel (montant arrondi)	548 000 $	1 135 000 $

 

[131] La valeur médiane de cette fourchette de JVM serait 841 500 $. Ainsi, à mon avis, il ne fait aucun doute que la JVM du logiciel acquis auprès d’Agensys T&C ne pouvait pas être supérieure à 960 000 $, la somme versée en argent comptant par la société en commandite. Ce montant se situe dans ma fourchette et dans celle de M. Johnson. Pour les raisons que j’ai déjà mentionnées, le logiciel valait peut‑être beaucoup moins que 960 000 $. Par conséquent, il est très peu probable, étant donné qu’il ne valait pas plus que 960 000 $, que les parties se soient entendues sur un montant supérieur à cette somme. Il s’agit d’un autre élément qui justifie ma conclusion selon laquelle les parties n’avaient pas l’intention de créer une obligation contraignante d’acquitter le solde dû relativement à l’achat du logiciel, à savoir 11 190 000 $, un montant presque égal à la valeur finale calculée par M. Pritchard.

 

(5)     La corroboration de l’associé A

 

[132] En plus du fait qu’on n’a jamais demandé aux commanditaires de verser les sommes d’argent, y compris les intérêts, qui étaient exigibles au titre des billets de souscription, du fait qu’aucun représentant d’Agensys T&C n’a témoigné afin de démolir les hypothèses de fait du ministre — en particulier l’allégation selon laquelle Agensys T&C n’avait jamais eu l’intention de percevoir des sommes au titre des billets de souscription — et du fait que la JVM du logiciel n’excédait pas 960 000 $, je dispose d’une confirmation de l’associé A, dont il est question dans la dénonciation des ES (onglet 412), que les commanditaires n’allaient pas avoir à payer leurs billets de souscription. L’associé A détenait des parts de plusieurs des 12 sociétés en commandite, dont Agensys (Canada)[127]. Après avoir reçu son avis de cotisation du ministre, il a parlé à un fonctionnaire de la section de l’évitement fiscal à qui il a confirmé qu’il [traduction] « ne [se] sentai[t] pas à l’aise en ce qui concerne cette [société en commandite] et pensai[t] qu’il pouvait s’agir d’une escroquerie ». L’associé A a aussi indiqué qu’on lui avait dit de vive voix que le montant dû au titre des billets de souscription [traduction] « qui était exigible dans dix ans ne serait jamais recouvré et que cette dette serait remise ». Même si de nouvelles dispositions législatives font en sorte que des intérêts devraient être payés sur des notices d’offre subséquentes de sociétés en commandite, ils seraient [traduction] « remboursés […] “en cachette” ».

 

[133] Il est vrai que l’associé A a affirmé dans un affidavit subséquent que [traduction] « je n’ai jamais fourni d’information provenant d’une source indépendante […] afin d’étayer l’affirmation selon laquelle je savais[128] que les sociétés en commandite d’Agensys étaient une “escroquerie” » (pièce A‑27). Il n’est cependant jamais revenu sur ses déclarations précises concernant le non‑recouvrement au titre des billets de souscription et le remboursement en cachette des intérêts.

 

[134] Il est regrettable que ni le vérificateur de l’évitement fiscal ni l’associé A n’aient témoigné devant la Cour. Lorsqu’on lui a demandé au cours de sa plaidoirie pourquoi l’associé A n’avait pas témoigné, l’avocat de l’intimée a répondu qu’il l’ignorait. Il a ajouté : [traduction] « Quoique je pense que vous pourriez vous appuyer sur elle [l’affirmation attribuée à l’associé A dans la dénonciation des ES selon laquelle le montant exigible au titre des billets de souscription ne serait jamais recouvré et ferait l’objet d’une remise], je crois qu’il faut se demander quelle valeur probante il convient de lui accorder, Monsieur le juge. » L’avocat de M. Morley a dit, dans sa plaidoirie, qu’[traduction] « il y avait des centaines, voire des milliers, de pages de documents dans le recueil conjoint des documents et ils ont été déposés et font partie de la preuve présentée à la Cour ». La dénonciation des ES se trouve dans ce « recueil conjoint » des documents, à l’onglet 412, l’un des derniers onglets du cahier n^o 12. L’affidavit subséquent a été déposé au cours des plaidoiries, avec le consentement de l’avocat de l’intimée, après que j’eus évoqué la découverte troublante de la déclaration mentionnée ci‑dessus.

 

[135] Il m’est impossible d’accorder une grande valeur probante à l’affirmation contenue dans la dénonciation des ES ou à celle contenue dans l’affidavit parce que l’associé A et le vérificateur de l’évitement fiscal qu’il a rencontré n’ont pas témoigné devant moi et que ces affirmations sont préjudiciables. Toutefois, compte tenu de mon analyse de la preuve circonstancielle et du manque de crédibilité de M. Gamble, ainsi que de la conclusion que j’en tire, j’estime que l’affirmation de l’associé A qui figure dans la dénonciation des ES est un autre élément qui appuie et justifie ma conclusion relative au coût réel du logiciel.

 

(6)     Tout au plus une obligation éventuelle

 

[136] En conséquence, je ne crois pas qu’Agensys T&C ait déjà eu l’intention de recouvrer une somme supérieure à 960 000 $ relativement à la vente des droits canadiens sur le logiciel à la société en commandite. Le billet pour achat et les billets de souscription qui l’ont remplacé ne constituaient pas une entente contraignante. Ils constitueraient peut‑être tout au plus un engagement éventuel concernant un paiement sous forme de redevances ou, comme il est mentionné dans le plan opérationnel d’Agensys T&C (au paragraphe 22 ci‑dessus), [traduction] « [l]e remboursement d’un prêt découlant d’un accord de redevances » sur les ventes du logiciel. Cette obligation éventuelle ne saurait être incluse dans le coût du logiciel[129].

 

 

(D)    Le paragraphe 69(1) et le lien de dépendance

 

[137] Je crois que la conclusion à laquelle je suis arrivé relativement au coût d’acquisition réel du logiciel n’exige pas que je me penche sur l’application du paragraphe 69(1) de la Loi. Dans le cas contraire cependant, j’aurais certainement conclu qu’il existait un lien de dépendance entre la société en commandite et Agensys T&C et que la JVM ne pouvait pas excéder 960 000 $.

 

[138] Pour parvenir à cette conclusion, je me serais appuyé sur les circonstances décrites précédemment et, en outre, sur le fait que les modalités du billet pour achat et des billets de souscription sont très loin d’être de nature commerciale. Lorsque j’ai interrogé M. Barisheff à ce sujet, il a reconnu qu’il n’avait jamais vu de modalités de ce genre dans les nombreuses opérations sur valeurs mobilières ou en matière d’immobilier auxquelles il avait participé. Dans ses observations écrites, l’avocat de l’intimée passe en revue la jurisprudence relative à la notion d’absence de lien de dépendance dans des situations semblables à celle en cause en l’espèce. Je reproduis les paragraphes 10 à 16 de ses notes :

 

[traduction]

B.        ABSENCE DE LIEN DE DÉPENDANCE ET ARTICLE 69

 

10.       La question de savoir si Agensys Canada et la société Agensys avaient ou non un lien dépendance est une question de fait, conformément à l’alinéa 251(1)c) de la Loi de l’impôt sur le revenu (alinéa 251b) en 1993). Dans la décision Brown c. Canada, [2001] A.C.I. n^o 763 [onglet 1], le juge Rip a défini plusieurs facteurs, dont un grand nombre — si ce n’est la totalité — sont présents dans l’appel Morley, ce qui indique l’existence d’un lien de dépendance :

 

▪  billet à ordre gonflé dont la période de validité dépasse la durée de vie utile du logiciel;

▪  écart entre le prix d’achat et la JVM estimée;

▪  autres facteurs, comme la décision arbitraire concernant les plateformes de jeu qui allaient être incluses dans l’achat et la vente et la désorganisation apparente du processus de sélection des noms des jeux.

 

11.       Le juge Rip a fait observer ce qui suit au sujet des billets à ordre au paragraphe 79 de la décision Brown :

 

Le billet [pour achat] n’était pas le genre d’instrument d’emprunt qu’auraient utilisé des parties sans lien de dépendance. Ce billet devait arriver à échéance le 31 décembre 2003, soit dix ans après l’opération et bien après le moment où l’on pouvait raisonnablement supposer que les jeux informatiques généreraient des bénéfices. M. Main prévoyait que le marché des consoles 16 bits se maintiendrait pendant cinq ans; quant à M. Grossman, il s’attendait à ce que ce marché dure jusqu’en 1996. Le billet n’était pas cessible, et la garantie connexe consistait en parts de la société de personnes. Aucun élément de preuve ne permet raisonnablement de conclure qu’un vendeur sans lien de dépendance [pourrait] être d’accord pour reporter le versement du solde du prix d’achat des logiciels, soit une somme de quelque 5 millions de dollars américains, avec ce billet pour toute garantie.

 

L’intimée fait valoir que ce passage s’applique directement au présent appel.

 

12.       Enfin, le juge Rip a examiné les autres facteurs suivants au paragraphe 79 [il s’agit en fait du paragraphe 80] pour conclure à l’existence d’un lien de dépendance : 

 

Certaines opérations menées après 1993 donnent également à penser qu’ASC […] et […] la société de personnes avaient entre [elles] un lien de dépendance. Pensons notamment à l’échange, par la société de personnes, d’un logiciel inconnu et que l’on pouvait présumer voué à l’échec, contre le jeu Super Copa, qui avait déjà été commercialisé sous d’autres noms, ainsi qu’à l’inclusion, en apparence arbitraire, de jeux destinés à la console Pico, sans l’approbation des associés, qui n’ont même pas été informés de la chose au préalable. De même, les jeux et leurs noms n’ont été déterminés qu’après 1993.

 

Il convient de noter à cet égard l’apparente indifférence démontrée par Agensys Canada à l’égard de la question de savoir si elle achetait « Kammand » ou « Agensys » et, le cas échéant, les différences entre les deux logiciels.

 

13.       La décision Petro-Canada v. The Queen (2002), 2003 DTC 94 [onglet 4], est pertinente également. L’appelante dans cette affaire avait acheté des données sismiques à un prix qui aurait été gonflé dans le but d’obtenir un traitement avantageux de la DPA [en fait, des FEC]. Le prix d’achat était de 46 751 752 $, alors que la JVM avait été établie à 8 884 497 $. En ce qui concerne la question de l’« absence de lien de dépendance », la Cour a fait référence aux faits suivants : (i) l’appelante ne pouvait donner aucun détail concernant les endroits où les données avaient été utilisées et les dates auxquelles elles l’avaient été (par. 71); (ii) l’acheteuse avait manifestement acheté les données sans tenir compte de l’emplacement auquel elles se rapportaient (par. 72); (iii) l’appelante n’avait en fait utilisé qu’environ 6 % des données qu’elle avait achetées (par. 73); (iv) « [a]ucune preuve n’indiquait que [l’acheteuse] avai[t] fait un sérieux effort pour négocier, avec les vendeurs, les prix devant être payés pour les données sismiques » (par. 83); (v) c’est le vendeur qui avait décidé du choix des données devant être vendues (par. 84); (vi) le vendeur et l’acheteuse avaient tous deux intérêt à ce que le prix payé pour les données sismiques soit aussi élevé « qu’[ils] pouvaient […] le justifier » (par. 85); (vii) les fonds devant servir à l’exploitation ou à l’utilisation des données devaient découler du traitement avantageux des FEC (par. 85).

 

14.       Le juge Bowie a conclu au paragraphe 82 : « Me fondant sur la preuve, je n’ai aucun doute que [les] opérations ne reflétaient pas des relations commerciales ordinaires entre des vendeurs et des acheteurs agissant dans leur propre intérêt et qu’il ne s’agissait donc pas d’opérations entre parties sans lien de dépendance. » [Non souligné dans l’original.]

 

15.       Enfin, au paragraphe 19 de la décision Gestion c. Canada, [2000] A.C.I. n^o 872 [onglet 5], la Cour a fait observer qu’« [u]ne transaction non réalisée à la juste valeur marchande peut indiquer une transaction entre parties ayant un lien de dépendance »[130]. L’intimée fait valoir que, vu l’écart marqué entre son évaluation et le prix d’achat du logiciel qui est énoncé, on peut se demander si celui‑ci a été acheté à sa JVM.

 

16.       Pour conclure à l’absence d’un lien de dépendance, la Cour s’est appuyée sur l’absence de « circonstances spéciales »[131] indiquant l’existence d’un lien de dépendance. La Cour a souligné qu’une preuve de « collusion, de […] magouille ou [de] manigances » révélerait l’existence d’un lien de dépendance.

 

[139] De plus, il est intéressant de rappeler les commentaires suivants faits par l’avocat de M. Morley dans ses observations écrites :

 

[traduction] L’appelant soutient que, dans le cadre de l’interprétation des alinéas 69(1)a) et 251(1)b), il faudrait, pour savoir si le coût réel devrait être remplacé par la juste valeur marchande, déterminer d’abord si l’acheteur et le vendeur avaient un lien de dépendance, après quoi, si l’on concluait que c’était le cas, que ce soit parce qu’ils étaient liés ou parce qu’ils ne traitaient pas l’un avec l’autre sans lien de dépendance dans les faits, le paragraphe 69(1) pourrait s’appliquer.

 

L’intimée semble toutefois privilégier le processus inverse : nous devrions déterminer si le bien acquis avait une juste valeur marchande égale au coût payé par l’acheteur et, si ce n’était pas le cas, nous pouvons nécessairement conclure que les parties avaient un lien de dépendance. L’intimée semble s’y prendre à rebours et laisser entendre que, si l’absence de juste valeur marchande peut être démontrée, il faut essentiellement en conclure que les parties avaient un lien de dépendance.

 

L’appelant soutient que ce renversement de l’objet manifeste de la loi doit être évité ou, à tout le moins, être adopté avec beaucoup de circonspection. L’article 69 ne devrait pas être appliqué, à moins que des facteurs externes à cette disposition permettent de conclure que les parties avaient un lien de dépendance.

 

Bien que la juste valeur marchande du bien en question aux fins du paragraphe 69(1) puisse être un facteur qui doit être pris en compte, il ne devrait pas en soi mener à la conclusion que les parties avaient un lien de dépendance et, ainsi, permettre à l’intimée de se fonder sur le paragraphe 69(1). Selon moi, c’est ce que l’intimée a essayé de faire, comme le montre la plaidoirie de son avocat. Au cours de cette plaidoirie, la seule raison invoquée pour appliquer le paragraphe 69(1) était le fait que le prix d’achat payé par la société en commandite pour le logiciel Agensys excédait la juste valeur marchande de celui‑ci.

 

[140] Je suis d’accord avec l’avocat de M. Morley lorsqu’il écrit dans ses observations que l’existence d’un écart entre la JVM et le prix payé ne devrait pas en soi être déterminant quant à l’existence d’un lien de dépendance. Il serait dangereux d’appliquer le paragraphe 69(1) dans de telles circonstances. Cependant, je conviens également qu’un tel écart est un facteur qui doit être pris en compte; il devrait être pris en considération avec les autres indications du fait que le prix n’a pas été déterminé dans des conditions dans lesquelles deux intérêts opposés étaient en cause. Il faut reconnaître qu’il est difficile de déterminer si une partie exerçait une influence indue sur l’autre lorsque le prix a été négocié, en particulier quand il ne semble pas y avoir de liens de sang ou un rapport financier ou économique entre les deux parties. Cependant, l’existence d’un écart important entre le prix convenu et la JVM du bien en cause devrait certainement constituer un facteur très pertinent qui doit être pris en compte lorsqu’il faut déterminer si le prix a été fixé dans des circonstances appropriées.

 

(E)     L’article 67 et le caractère raisonnable des dépenses

 

[141] Comme l’intimée a eu gain de cause au regard de la question du coût réel du logiciel et aurait eu gain de cause également en ce qui concerne le paragraphe 69(1) s’il avait été nécessaire d’appliquer cette disposition, je ne me prononcerai pas sur l’application de l’article 67 parce que j’ai certains doutes quant à son applicabilité dans les circonstances de l’espèce et qu’aucune décision traitant de cette question n’a été portée à mon attention[132]. À mon avis, il ne fait aucun doute qu’une déduction n’est pas un débours ou une dépense et, en conséquence, il est possible que l’article 67 ne doive pas être appliqué, à tout le moins s’il est interprété de manière restrictive. On pourrait toutefois fort bien faire valoir que l’article 67 est applicable relativement au coût d’acquisition du logiciel lui‑même[133]. Compte tenu des conclusions auxquelles je suis parvenu précédemment et du fait que cette question n’a pas été suffisamment débattue devant moi, j’ai décidé de ne pas la trancher dans le cadre des présents appels.

 

(F)     La fraction à risques

 

[142] Je ne crois pas qu’il soit nécessaire de recourir à l’application du paragraphe 96(2.1) de la Loi puisque j’ai conclu que le coût du logiciel n’excédait pas 960 000 $. Dans ces circonstances, la part des pertes de la société en commandite qui revient à M. Morley n’excède probablement pas sa contribution monétaire à la société en commandite et sa responsabilité à l’égard de celle‑ci.

 

(G)    Le logiciel était-il prêt à être mis en service en 1993?

 

[143] Le ministre s’est appuyé notamment sur les hypothèses suivantes qui sont énoncées au paragraphe 21 de la réponse à l’avis d’appel modifié pour conclure que le logiciel n’était pas prêt à être mis en service en 1993 et pour établir la cotisation de M. Morley :

 

[traduction]

(mm)    la présumée société en commandite n’a pas développé un produit commercialisable et elle ne dispose pas des ressources financières nécessaires pour développer et commercialiser un quelconque produit;

 

(nn)      depuis l’acquisition du droit d’auteur canadien sur le logiciel Agensys, la présumée société en commandite n’a jamais exercé ce droit dans le but de gagner un revenu;

 

(oo)      depuis l’acquisition du droit d’auteur canadien par la présumée société en commandite, le logiciel Agensys n’a pas été prêt à être mis en service ou à être utilisé ou vendu à des fins commerciales.

 

 

[144] Les paragraphes 13(26) et (27) de la Loi sont pertinents pour trancher cette question :

 

13(26)  Restriction de la déduction portant sur un bien prêt à être mis en service.

 

Pour l’application de la définition de « fraction non amortie du coût en capital » au paragraphe (21) dans le cadre de l’alinéa 20(1)a) et des dispositions réglementaires prises pour l’application de cet alinéa, pour le calcul du revenu qu’un contribuable tire d’une entreprise ou d’un bien pour une année d’imposition, aucun montant n’est inclus dans le calcul de la fraction non amortie du coût en capital, pour le contribuable, d’un bien amortissable d’une catégorie prescrite au titre du coût en capital, pour lui, d’un bien de cette catégorie (sauf un bien qui est une production portant visa, au sens des dispositions réglementaires prises pour l’application de l’alinéa 20(1)a)) avant le moment où le bien est considéré comme devenu prêt à être mis en service par le contribuable.

 

13(27)  Bien prêt à être mis en service.

 

Pour l’application du paragraphe (26) et sous réserve du paragraphe (29), le bien qu’un contribuable acquiert, à l’exception de tout ou partie d’un bâtiment, est considéré comme devenu prêt à être mis en service par lui au premier en date des moments suivants :

 

a)         le moment où le contribuable l’utilise pour la première fois pour gagner un revenu;

 

[…]

 

d)         le moment où le bien, à la fois :

 

(i)         est livré au contribuable, ou à une personne ou une société de personnes qui l’utilisera au profit du contribuable, ou, si le bien ne se prête pas à la livraison, est mis à la disposition de l’un d’entre eux,

(ii)        peut. seul ou d’avec d’autres biens en possession, à ce moment, du contribuable ou de la personne ou société de personnes visée au sous‑alinéa (i), être utilisé par le contribuable ou cette personne ou société de personnes, ou pour son compte, pour produire un produit ou fournir un service qui est vendable commercialement, y compris un produit ou un service utilisé ou consommé, ou à être utilisé ou consommé, par le contribuable ou cette personne ou société de personnes, ou pour son compte, dans le cadre de cette production ou de cette fourniture.

 

[Non souligné dans l’original.]

 

[145] Il ressort de la preuve que la société en commandite avait certains codes objets pour le logiciel à la fin de 1992. M. Gamble a dit ce qui suit dans son témoignage :

 

[traduction] En fait, le code objet nous avait été fourni dès octobre 1992 afin que nous le soumettions à des tests. Et nous avons reçu le code objet à jour dans sa version définitive en décembre 1992. Nous l’avions donc, ainsi que tous les manuels d’utilisation, tout ce dont nous avions besoin pour produire des applications. (Transcription du témoignage de M. Gamble, p. 501 et 502)

 

[Non souligné dans l’original.]

 

[146] Cette version des faits est‑elle corroborée par le reste de la preuve? Quel était le statut de ces codes? Le logiciel existait‑il uniquement en version bêta? S’agissait‑il seulement d’une version de démonstration comportant de nombreux bogues ou d’un logiciel pleinement opérationnel pouvant être utilisé pour produire un produit ou fournir un service qui était vendable commercialement?

 

[147] À mon avis, la meilleure preuve produite par l’avocat de M. Morley dans le but d’établir que le logiciel était prêt à être mis en service en 1993 est le rapport d’expert de M. Karnis concernant le logiciel tel qu’il existait en novembre 1993. M. Karnis a compilé cette version du logiciel (la « version de 1993 du logiciel ») à partir de codes sources qui avaient apparemment été déposés entre les mains d’un tiers, Temple Trust, aux îles Turks et Caicos, en 1993. L’identification technique de cette version compilée est : AGENSYS‑PRO‑DOS, Rel. 3, Ver. 12.69TCX4‑GDEMO, 11‑1‑93.

 

[148] Plus particulièrement, on a demandé à M. Karnis de déterminer si la version de 1993 du logiciel pouvait créer une application complexe d’envergure, la faire fonctionner et l’améliorer. Pour répondre à cette question, M. Karnis a essayé de faire tourner, à l’aide de la version de 1993 du logiciel, la version exécutable d’AGS Mortgage qui a été créée entre 1996 et 1998 par Agensys International au moyen de la version de développement du logiciel qui existait à l’époque (la « version de 1997 du logiciel »), afin de déterminer si cette application aurait pu être créée avec la version de 1993 du logiciel[134]. M. Karnis a alors détecté plusieurs bogues, dont l’un a occasionné une perte [traduction] « d’éléments mineurs servant à embellir l’écran ». Le bogue le plus grave touchait une instruction particulière (KMD‑PR0G) et a été relevé 102 fois dans 70 314 lignes de code d’AGS Mortgage[135]. Cette instruction avait pour but de suspendre le programme en cours pour exécuter un sous‑programme. Lorsque le sous‑programme était terminé, le programme en cours pouvait continuer. Selon M. Karnis, c’est à cause de ce bogue que la version de 1993 du logiciel [traduction] « avait cessé de fonctionner après environ 28 exécutions de cette instruction ». Il a décrit la solution dans les termes suivants à la page 3 de son rapport (pièce A‑15) :

 

[traduction] Nous avons élaboré une solution pour remplacer l’instruction KMD-PROG par une instruction SUB-PROG similaire (mais pas identique) d’Agensys. Nous avons réussi à corriger une occurrence de KMD‑PROG avec SUB‑PROG. Si nous avions pu disposer de plus de temps et de ressources, nous aurions corrigé toutes les occurrences de KMD‑PROG avec SUB‑PROG en restructurant l’application [AGS Mortgage]. Ce correctif unique a entraîné l’ajout de 5 lignes de code à [AGS Mortgage].

 

Manquant de temps et de ressources, nous avons essayé de cerner la cause réelle du bogue KMD‑PROG et d’y trouver une solution. Nous avons pu établir qu’une simple erreur de programmation [dans la version de 1993 du logiciel] était à l’origine de ce bogue (soit une perte de mémoire). Nous avons malheureusement manqué de temps pour mettre au point un correctif.

 

[Non souligné dans l’original.]

 

[149] M. Karnis a ajouté que ce bogue avait été corrigé [traduction] « à un moment donné entre 1993 et 1996 » et que l’application AGS Mortgage utilisée sur la version de 1997 du logiciel [traduction] « avait fait l’objet de tests poussés et d’une utilisation prolongée » et que le même bogue n’avait pas été détecté. Il a ensuite conclu ce qui suit à la page 6 de son rapport :

 

[traduction] La maintenance continue fait partie de tout grand projet logiciel et je crois que la présence d’un seul bogue dans tout le logiciel Agensys n’enlève absolument rien aux qualités techniques générales de ce logiciel à titre d’outil de développement d’applications.

 

Opinion

 

À mon avis, il est possible d’utiliser [la version de 1993 du logiciel] pour créer, maintenir, améliorer et exécuter [AGS Mortgage] sans qu’il soit nécessaire d’augmenter considérablement le nombre de codes programmes.

 

[Souligné par M. Karnis.]

 

[150] L’intimée a demandé à M. Bruce Travers, de Brock Solutions, de l’aider à évaluer la version de 1993 du logiciel. L’évaluation de M. Travers comportait deux volets :

 

[traduction]

•         Évaluer les affirmations faites dans les documents techniques et les documents de marketing d’AGENSYS.

•         Positionner AGENSYS par rapport aux produits concurrents à la date de l’évaluation.

 

Pour évaluer AGENSYS :

 

•         nous avons créé une application sommaire de la paye afin de tester les fonctions d’AGENSYS et d’explorer ses capacités et ses limites;

•         nous avons examiné les exemples d’application fournis avec le logiciel;

•         nous avons comparé les fonctionnalités d’AGENSYS à celles des produits concurrents mentionnés dans le document intitulé [traduction] « Notes sur les produits en concurrence avec KAMMAND ». (Page 1 de son rapport (pièce R‑5))

 

[Non souligné dans l’original.]

 

[151] M. Travers est parvenu notamment aux conclusions suivantes :

 

[traduction] Le développement de notre application de la paye nous a permis de mesurer les capacités et les limites d’AGENSYS. Nous sommes donc parvenus aux conclusions ci-après.

•         AGENSYS permet de développer des applications opérationnelles.

[…]

•         AGENSYS est un langage de programmation comptant plus de 100 commandes et 80 sous-commandes. Nous avons testé environ la moitié d’entre elles, et elles ont toutes fonctionné conformément à leur description dans les manuels techniques.

[…]

•         Le concepteur d’applications AGENSYS est essentiellement un prolongement des utilitaires de documentation. AGENSYS ne peut pas modéliser des données, ce que doivent faire avant tout la plupart des outils de conception d’applications. Nous avons relevé plusieurs bogues informatiques dans le concepteur d’applications[136]. Cet utilitaire n’était accompagné d’aucun manuel d’utilisation.

[…]

•         La version d’AGENSYS que nous avons testée présentait deux importantes lacunes techniques susceptibles d’en limiter l’utilité dans les grandes et moyennes organisations :

 

▪    Elle n’offre aucune interface avec les bases de données les plus répandues (c.-à-d. Oracle, IMS, Sybase, DB2, etc.). – Ces bases de données servent à stocker la quasi-totalité de l’information numérique des grandes et moyennes entreprises. Sans une telle interface, il faut copier les données se trouvant dans les bases de données externes et les introduire dans AGENSYS au moyen de l’utilitaire de transfert de fichiers. On est donc en présence de données en double, ce qui complique l’identification du bon fichier lorsque deux fichiers qui devraient être identiques ne le sont pas. Le dédoublement des données devrait être évité.

▪    Elle ne permet pas de créer des journaux de transactions. – Cette fonctionnalité est essentielle aux applications commerciales d’envergure. La journalisation est un processus qui consigne dans un journal, ou fichier, les transactions ayant entraîné une modification de l’information contenue dans une base de données. Le journal est toujours conservé sur un autre disque dur que les fichiers de la base de données. Si le système connaît une défaillance causée par le mauvais fonctionnement d’un disque dur, il est possible de reconstruire la base de données. Il suffit de recharger la dernière sauvegarde de sécurité puis de traiter de nouveau les entrées du journal créées après cette sauvegarde. Sans un tel journal, les utilisateurs doivent entrer eux-mêmes les transactions de nouveau. 

 

Par conséquent, AGENSYS n’est pas adapté aux besoins des grandes et moyennes entreprises qui veulent remplacer leurs anciens systèmes ou leur ordinateur central.

 

AGENSYS convient mieux au développement d’applications destinées à un seul utilisateur ou à un petit groupe de travail dont les transactions sont peu nombreuses.

 

[Non souligné dans l’original.]

 

[152] Il importe de mentionner que la Cour n’est pas liée par les preuves d’expert. Il appartient à la Cour de décider si les conditions prévues par les paragraphes 13(26) et (27) de la Loi ont été remplies, en tenant compte des preuves d’expert et de tous les autres éléments de preuve produits par les parties au cours de l’audience. Il faut mentionner également que la question de savoir si le logiciel était complet ou pouvait être utilisé pour produire un « produit vendable commercialement » ou fournir un « service vendable commercialement » n’a pas été posée expressément aux experts. Examinons l’ensemble de la preuve afin de trancher cette question.

 

[153] Premièrement, le logiciel n’a jamais été vendu à qui que ce soit par la société en commandite. Non seulement cela, mais je ne dispose d’aucune preuve démontrant qu’une vente était sur le point d’être conclue ou aurait pu être conclue. Au contraire, M. Gamble a reconnu que la société en commandite n’avait jamais été sur le point de conclure une vente de 1993 à 1995. (Voir le par. 45 ci‑dessus.) La preuve ne démontre pas non plus que la société en commandite a dressé une liste de prix. La seule liste de prix qui a été produite est datée du 1^er avril 1997 et a été établie par Agensys International (onglet 380). Deuxièmement, la création ou le développement de la première application au moyen du logiciel a commencé en 1996 et s’est terminé seulement à la fin de 1997 ou au début de 1998, ce qui jette un doute sérieux sur le fait que le logiciel décrit était complet à la fin de 1993. Le fait qu’il n’était pas complet pourrait bien expliquer pourquoi aucune vente n’a été réalisée en 1993, en 1994 et en 1995. Il pourrait bien expliquer aussi en grande partie pourquoi aucune application opérationnelle n’a jamais été développée avec le logiciel pendant la même période. Ce n’est que dans la dernière partie de 1996 que les premières démarches en vue de la création d’AGS Mortgage ont été entreprises.

 

[154] L’analyse des notes internes, des procès‑verbaux des réunions de la direction, des rapports et de la correspondance des années 1994 à 1996 ne dissipe pas ces préoccupations. Bien au contraire. Le portrait ressortant de tous les extraits tirés de ces documents qui sont cités ci‑dessus (en particulier aux paragraphes 42 à 53) n’appuie pas la thèse de M. Morley. Je reproduis à nouveau les passages les plus pertinents de ces extraits, ainsi qu’un autre passage : [traduction] « [L]’ampleur du travail qui reste à accomplir pour que le lancement sur le marché canadien soit couronné de succès […] Il a demandé à ce qu’on lui présente AC lorsque l’entreprise sera en activité » (17 janvier 199[4]). [traduction] « L’information que Terry [Stanhope, de la société Object Systems Inc.] aura recueillie pendant son séjour aux États-Unis confirmera sans doute que les capacités d’AGENSYS ne sont pas à la hauteur de ce qui est déclaré dans la publicité. Il faudra vraisemblablement déboguer un des logiciels existants. À titre d’exemple, Paul a signalé que la version d’AGENSYS destinée à l’environnement Unix, dont Howard affirmait qu’elle était prête, a présenté un bogue dès qu’il a saisi la première commande. […] Il nous faut obtenir la confirmation que le logiciel auquel nous nous attendions du fait de ce qui a été dit par Howard ou écrit dans notre documentation est bien disponible […] [N]ous n’avions aucun moyen de vérifier si ce que nous affirmions au sujet de ses possibilités tenait de la réalité ou de la fiction » (8 août 1994). [traduction] « Nous sommes arrivés à la conclusion que, si on proposait à d’éventuels acheteurs de faire l’essai préalable d’AGENSYS pendant un ou deux jours, ils décideraient de ne pas en faire l’acquisition. La documentation ne peut rivaliser avec la norme établie par Apple et Microsoft » (6 septembre 1994). [traduction] « J’ai dit à Larry [Gamble] et à Nick [Barisheff], en juillet 1994, que je n’avais pas l’intention de reprendre les démarches auprès du secteur fédéral avant de disposer d’un produit dont les qualités annoncées peuvent être démontrées […] Je ne m’engagerai pas, en notre nom, à tenter une nouvelle percée sur le marché d’Ottawa avant d’avoir vu les démos mis au point par Gary McCann et la documentation préparée par Paul pour la commercialisation, la présentation démo et les ventes. […] Paul et Gary se trouvent actuellement à Dallas afin de nous aider à déterminer exactement où en est le logiciel et ce qui reste à faire » (23 mars 1995). [Non souligné dans l’original.] [traduction] « La rédaction du manuel d’utilisation est maintenant terminée et le manuel est à l’impression. J’ai appris qu’il y a des fonctions d’Agensys qui ne fonctionnent pas, mais Howard m’a dit qu’elles fonctionnent. Gary se penchera aussi sur le problème avec Howard. […] Gary déterminera si nous avons une version stabilisée d’Agensys après la visite avec Howard » (onglet 191, 11 avril 1995). [Non souligné dans l’original.] [traduction] « Lorsque tous les problèmes techniques seront réglés et que les caractéristiques de nos produits seront bien comprises des acteurs du marché, nous devrions être en mesure de tirer parti des avantages du produit » (13 août 1996).

 

[155] À mon avis, seule une version de démonstration d’un logiciel incomplet a été mise à la disposition de la société en commandite en 1993. La présence du terme « DEMO » dans la description technique de la version de 1993 du logiciel qui a été examinée par les experts aux fins des présents appels est une première indication du fait que le logiciel décrit était un produit inachevé à la fin de 1993. Lorsque des consultants ont été embauchés entre juin et août 1994 pour évaluer l’interface utilisateur du logiciel décrit et la documentation connexe, ils se sont servis de ces deux versions : la version 15.24 NTCX12DEMO et la version 15.59 PXN90DEMO. Ainsi, même plus d’un an après l’acquisition du logiciel, seules des [traduction] « versions démo » étaient disponibles, ce qui tendrait à confirmer que la version définitive du logiciel décrit n’était pas encore terminée.

 

[156] Deuxièmement, contrairement à l’impression que les conventions d’acquisition de 1992 et de 1993 devaient créer, les codes sources du logiciel n’ont pas été transmis en 1992 ou 1993, notamment, à mon avis, parce que le développement du logiciel décrit n’était pas terminé. Il faut se rappeler que, en vertu de la convention d’acquisition de 1992, les codes sources devaient être communiqués dans les trois jours suivant la signature de cette convention (onglet 55, sous‑onglet 6, par. 5). Ils ne l’ont pas été. Il est prévu au paragraphe 3.2 de la convention d’acquisition de 1993, qui est datée du 30 juin 1993, que le [traduction] « vendeur a transmis le code source électroniquement par modem à la société en commandite et celle‑ci en accuse réception par les présentes ». [Non souligné dans l’original.] Cette déclaration est fausse. À l’audience, M. Gamble a reconnu que la transmission n’avait eu lieu que vers le 20 décembre 1993, lorsqu’il s’est rendu aux îles Turks et Caicos.

 

[157] En fait, ce n’est même pas à lui que les codes sources ont été transmis ce jour‑là, mais à Temple Trust, qui devait les détenir à certaines conditions en vertu du contrat d’entiercement [traduction] « en date du 20 décembre 1992 » (onglet 43). Selon ce contrat, les codes sources ne pouvaient pas être divulgués sans le consentement mutuel des parties. Agensys T&C devait donc donner son consentement et, par conséquent, pouvait aussi refuser. Le contrat décrivait en outre certaines circonstances, comme [traduction] « la survenance et la continuation d’un manquement important par Agensys [T&C] », dans lesquelles l’une ou l’autre des parties pouvait obtenir les codes sources. Ce n’est pas ce que j’appellerais la transmission des codes sources à la société en commandite. Il s’agit davantage d’un compromis visant à protéger dans une certaine mesure à la fois Agensys T&C et la société en commandite.

 

[158] Troisièmement, le fait qu’aucun test d‘acceptation n’avait encore été effectué en date du 8 février 1995 [traduction] « afin de vérifier si le [logiciel] [était] en état de marche » de façon qu’il puisse être [traduction] « réputé acceptable » et que [traduction] « les sociétés en commandite […] soient complètes » indique également que le développement du logiciel décrit n’était pas terminé. Ces passages ne sont pas tirés de la convention d’acquisition de 1993, comme on aurait pu s’y attendre. Fait très étonnant, cette convention est muette à ce sujet. Les passages sont plutôt tirés d’une note de service non datée (la « note de service portant sur les tests d’acceptation de 1993 ») (onglet 60) qui décrit en détail les tests d’acceptation auxquels le logiciel et les améliorations de 1994 devaient être soumis. Vu son importance, je reproduis intégralement cette note de service :

 

[traduction]

 

À : Larry Gamble

 

De : John Batton

 

Objet : Soutien « SE »

 

Vous trouverez ci-joint un tableau qui illustre les événements qui devraient se produire au cours des prochaines semaines. Il fait également état des éléments dont nous avons discuté et pour lesquels nous avons convenu qu’ils doivent être réalisés avant que ne se produisent les événements susmentionnés. Nous croyons que toutes les mesures peuvent être prises à distance avant le soutien à la démonstration demandé. Voici comment interpréter le tableau :

 

Convenir des détails des tests d’acceptation de 1993 — Les produits livrables seront soumis aux tests d’acceptation suivants :

 

Plateformes : Les compilateurs C et C++ des plateformes (MS‑DOS et SCO/UNIX[137] en mode caractères) devront compiler sans erreur le code source du système de développement Agensys. Les exécutables compilés des plateformes (MS‑DOS et SCO/UNIX) devront exécuter correctement la série de tests du système de développement Agensys pour vérifier son bon fonctionnement. Cette série de tests comprend les systèmes de sécurité et de conception, qui sont des applications exécutées dans la version AGS, pour en tester tous les aspects. Elle regroupe aussi diverses applications pour exécuter les verbes du langage et vérifier qu’ils sont conformes aux spécifications.

 

Exécuter les tests d’acceptation de 1993 — Le système de développement Agensys doit exécuter correctement la série de tests pour être jugé recevable.

 

Maintenir les sociétés en commandite de 1993 — Au terme des tests d’acceptation de 1993, les sociétés en commandite de 1993[138] seront complètes.

Débloquer les fonds de 1994 — Les fonds recueillis pour acquérir des parts au cours de la saison de ventes 1994 seront remis à la société Agensys. Aucune autre mesure ne sera prise tant que les fonds n’auront pas été versés aux comptes de la société Agensys.

 

Permettre aux sociétés en commandite d’avoir accès aux produits livrables de 1994 — Les copies logicielles de la version bêta du logiciel, prêtée à titre de démonstrateur à Agensys Canada en décembre 1994, cesseront de fonctionner le 1^er avril 1994 dans les bureaux au Canada. Cette version est prête à être livrée à la société Agensys pour qu’elle procède aux tests d’acceptation, conformément à l’énoncé des travaux[139].

[Non souligné dans l’original.]

 

[159] Des tests d’acceptation sont habituellement effectués lorsqu’un prix élevé est payé pour un logiciel[140]. C’est ce qui a été fait lorsqu’Agensys T&C a livré les améliorations de 1994 le 1^er décembre 1994 (onglet 145). La moitié du prix était payable à la livraison des copies bêta et le solde [traduction] « au moment de l’achèvement et de l’acceptation du projet ». L’entente de développement de 1994 (onglet 68) en vertu de laquelle les améliorations de 1994 ont été livrées renferme la clause suivante :

 

[traduction]

Article 8

 

LIVRAISON ET ACCEPTATION

 

À la fin des travaux, le développeur remet tous les produits livrables précisés dans l’énoncé des travaux au coordonnateur technique du responsable du projet aux fins d’essai et d’acceptation. Le développeur consigne cette livraison dans un document de confirmation de la livraison qui établit la nature et l’état des produits livrables, le moyen utilisé pour en assurer la livraison et la date de leur livraison. Le coordonnateur technique du responsable du projet contresigne le document de confirmation de la livraison pour indiquer qu’il a bien reçu le contenu qui y est décrit. Par la suite, ce document est remis aux coordonnateurs du contrat des parties. À moins que l’énoncé des travaux ne prévoie une autre procédure d’essai et d’acceptation, le coordonnateur technique du responsable du projet commence les tests d’acceptation après avoir reçu les produits livrables. Une fois les tests terminés, le responsable du projet remet un avis d’acceptation ou de rejet des produits livrables au coordonnateur technique du développeur. Si les produits livrables sont refusés, le responsable du projet indique, avec suffisamment de détails, les motifs de sa décision au coordonnateur technique du développement. Le développeur déploie tous les efforts raisonnables pour corriger les lacunes et les défauts de conformité et pour présenter de nouveau les éléments rejetés dans les plus brefs délais. Si le responsable du projet décide de ne pas accepter les produits livrables, tout paiement régulier doit être retenu, et le développeur conserve ses droits de propriété.

[Non souligné dans l’original.]

 

[160] L’énoncé des travaux auquel renvoie l’entente ci‑dessus prévoyait les tests d’acceptation suivants :

 

[traduction]

7. Tests d’acceptation : Les produits livrables seront soumis aux tests d’acceptation suivants :

 

Plateformes : Les exécutables des plateformes doivent exécuter sans erreur la série de tests du système de développement Agensys pour vérifier que celui-ci peut exécuter la version AGS dans le nouvel environnement. Cette série de tests comprend les systèmes de sécurité et de conception, qui sont des applications exécutées dans la version AGS, pour en tester tous les aspects. Elle regroupe aussi diverses applications pour exécuter les verbes du langage et vérifier qu’ils sont conformes aux spécifications.

 

Capacité de communication : Les produits livrables doivent présenter une capacité de communication par Ethernet au moyen des protocoles indiqués à la section 6. La plateforme Sun servira aux tests, puisqu’elle peut être exploitée sous Solaris 2.3 et qu’elle comporte une gamme de produits capables d’exécuter toutes les fonctions d’un serveur, peu importe l’application. L’accès à distance aux fichiers au moyen de ces protocoles fera l’objet d’une démonstration par réseau Ethernet. […]

 

[Non souligné dans l’original.]

 

[161] Il est étonnant qu’une telle procédure ait été stipulée dans l’entente de développement de 1994 relativement à la livraison des améliorations de 1994, pour lesquelles la société en commandite devait payer une somme de 45 240 $US, mais non dans la convention d’acquisition de 1993 alors que le prix était de 12 150 000 $! Le procès‑verbal de la réunion de la direction du 21 février 1995 (onglet 177) indique que M. Gamble a exigé qu’[traduction] « Howard Kale respecte l’entente initiale qu’il a conclue avec nous et qui prévoit des procédures d’acceptation, des tests, etc. ». Ces procédures ne sont pas décrites dans la convention d’acquisition de 1993! Contrairement à ce que M. Gamble a affirmé dans son témoignage, la convention d’acquisition de 1993 ne constitue pas l’ensemble de l’entente intervenue entre les parties. Il y a au moins un autre engagement formel qui n’a pas été répertorié. La note de service portant sur les tests d’acceptation de 1993, qui est datée du 8 février 1995, est conforme à [traduction] « l’entente [verbale] initiale ».

 

[162] Je suis d’accord avec M. Morley, qui a écrit dans la note de service qu’il a adressée à M. Gamble le 19 février 1995 que l’on ne pouvait pas considérer que les codes sources [traduction] « étaient complets selon les modalités de la convention d’acquisition du logiciel » tant que celui‑ci n’avait pas [traduction] « fait l’objet de tests d’acceptation établis »[141]. Cette note de service traite de la [traduction] « vérification de l’établissement de la valeur effectuée par Revenu Canada » et de la demande de [traduction] « démonstration dans un délai de deux semaines » de Revenu Canada. Dans sa note de service, M. Morley écrit que la société en commandite [traduction] « doit être en mesure de répondre au type de questions suivantes » :

 

[traduction]

Question 1. L’article 1 de la convention d’acquisition du logiciel (CAL) définit les termes « code source » et « programme informatique ». « Pouvez-vous prouver qu’ils ont été livrés et compilés en « code objet », et qu’ils ont réussi les tests d’acceptation de la société en commandite? »

 

État actuel. Il faut attendre que la société AGENSYS ait livré le code source en entier. CGI doit confirmer, par le truchement de sa vérification, que le code source livré est complet selon les modalités de la convention d’acquisition du logiciel. Il faut également attendre que le logiciel ait été soumis à des tests d’acceptation établis.

 

Mesures requises.

 

1. Demander à Mark Dennison[142] de terminer dès que possible la vérification et les activités décrites dans sa proposition du 17 février.

 

2. Concevoir dès que possible les tests d’acceptation en collaboration avec la société AGENSYS.

 

QUESTION 2. Quels composants du « schéma des systèmes » contenu à l’annexe D ont été livrés à la société en commandite et peuvent être démontrés? Des documents à l’appui peuvent‑ils être produits?

 

[Non souligné dans l’original.]

 

[163] La Cour ne dispose pas du reste de la deuxième question parce que la page 2 de la note de service est manquante[143]. Toutefois, il y a à la page 3 ce qui constitue fort probablement la troisième [traduction] « mesure requise » proposée par M. Morley en réponse à sa troisième question dont on ne connaît pas la teneur :

 

[traduction]

3. Toutes les versions logicielles, y compris celles qui ont déjà été livrées, doivent être soumises aux tests d’acceptation ainsi qu’à un processus visant leur acceptation par les sociétés en commandite d’AGENSYS.

 

[Non souligné dans l’original.]

 

[164] Ainsi, nous pouvons conclure à juste titre que le logiciel décrit n’avait pas été adéquatement testé en 1993 et nous pouvons déduire de cette conclusion que c’est parce qu’il n’était pas terminé à la fin de 1993, l’année d’imposition en cause en l’espèce.

 

[165] Bien que la preuve directe et la preuve indirecte soient contradictoires, il ressort de la lecture des différents documents produits en preuve qu’une version complète du logiciel décrit n’a pas été livrée en 1993. Comme il est mentionné au paragraphe 13 ci‑dessus, les codes sources du logiciel décrit qui ont été transmis à la société en commandite devaient permettre l’exécution sur les trois plateformes suivantes : MS‑DOS, SCO Unix et  SE Sun. En fait, la lettre d’Agensys T&C datée du 1^er décembre 1994 (onglet 145) et la facture qui y est jointe semblent indiquer que ces deux dernières plateformes ont seulement été livrées par Agensys T&C en format bêta à la fin de 1994 dans le cadre de la livraison des améliorations de 1994; la livraison de la version définitive de ces améliorations le 31 janvier 1995 a été refusée par la société en commandite en mars 1995[144].

 

[166] L’indication la plus récente d’une demande présentée afin d’obtenir la plateforme SE Sun remonte au 2 juin 1994 (onglet 95). Or, ce n’est qu’un an plus tard, lorsque M. Karnis a essayé de l’installer en vue d’une démonstration de réseaux, qu’il est question pour la première fois de la réception de la plateforme. J’y reviendrai[145].

 

[167] Le 25 juillet 1994, M. Morley écrit, dans une note de service adressée à Larry Gamble et à Nick Barisheff, que, selon John Batton, la [traduction] « version 14 (sic) d’AGENSYS et la version Unix d’AGENSYS nous ont été envoyées en juin. Les avons‑nous reçues? » (Onglet 116.) Ces propos semblent indiquer que la version Unix a peut‑être été envoyée seulement en 1994. Peut‑être qu’une version bêta avait été envoyée précédemment ou que l’information contenue dans la note de service est erronée. Nous n’avons pas la réponse à cette note. De plus, M. Morley a dit en août 1994 que [traduction] « la version d’AGENSYS destinée à l’environnement Unix, dont Howard affirmait qu’elle était prête, a présenté un bogue dès […] la première commande ». Dans son rapport de mai 1995, M. McCann affirme que le logiciel n’est disponible que pour les plateformes DOS et SCO Unix! (Voir le par. 49 ci‑dessus.) Cela indique clairement que la troisième plateforme (SE Sun), sur laquelle le logiciel décrit devait être utilisé, n’était pas prête en mai 1995. Enfin, il est intéressant de noter que les experts qui ont témoigné à l’audience ont utilisé seulement la version DOS pour évaluer la version de 1993 du logiciel.

 

[168] L’absence de preuve crédible établissant que des démonstrations d’un logiciel complet ont eu lieu en 1993 indique également que le logiciel décrit était toujours en cours de développement en 1993. Même si, au début de 1994, M. Morley était occupé à essayer de vendre les services de la société en commandite en matière de développement d’applications opérationnelles sur mesure pour le gouvernement et les entreprises, les premières démonstrations en direct à l’intention de clients indépendants éventuels ont eu lieu, selon la preuve, les 16 et 17 mai 1994. À ces dates, une démonstration en direct et [traduction] « un atelier […] au cours duquel une petite application était développée » ont eu lieu dans les bureaux de la société en commandite (onglets 419 et 416). Cette démonstration semble avoir été limitée parce que, dans sa note de service du 5 décembre 1994, qui traite du plan de travail de 1994 et des priorités de 1995, M. Morley affirme que nous [traduction] « devons avoir terminé à la fin de 1994, une démonstration et un script de qualité » (onglet 147).

 

[169] La démonstration du logiciel sollicitée par Revenu Canada au début de 1995 a eu lieu près d’un an plus tard. Il est vrai qu’un grave litige opposait les parties quant à la question de savoir si un expert de Revenu Canada pouvait prendre un engagement de confidentialité particulier envers la société en commandite, mais, à mon avis, il ne s’agit pas de la seule raison du retard. La société en commandite avait embauché des consultants (CGI) pour préparer cette démonstration et ces derniers avaient besoin de temps à cette fin. Il ne suffisait apparemment pas de présenter à nouveau la démonstration en direct ayant eu lieu les 16 et 17 mai 1994. Vraisemblablement, cette démonstration n’a porté que sur la plateforme DOS. Pour montrer certaines des fonctions les plus importantes du logiciel, par exemple sa portabilité et son interopérabilité, la société en commandite a obtenu et installé, après beaucoup d’efforts de débogage, la plateforme SE Sun/Solaris avec l’aide de M. Karnis.

 

[170] Outre le témoignage de M. Gamble (cité ci‑dessus) selon lequel la société en commandite avait reçu les [traduction] « code[s] objet[s] à jour dans [leur] version définitive en décembre 1992 », d’autres éléments de preuve étayent la thèse de M. Morley. Premièrement, le plan de développement d’Agensys T&C (reçu par Agensys U.S. en mai 1994 et joint à la note de M. Batton du 8 février 1995) indique que, [traduction] « à la fin de 1993, le système de développement d’applications Agensys était pris en charge par les plateformes MS‑DOS et SCO/Unix ». Il s’agit de la [traduction] « version de base » qui a été vendue aux sociétés en commandite d’Agensys (onglet 60). M. Gamble a cependant dit aussi ce qui suit :

 

[traduction]

Q. Quand le module de soutien pour UNIX vous a‑t‑il été livré?

R. Je pense que c’est en 1994, 1995. Je ne sais pas exactement à quel moment[146].

 

[…]

 

Q. Il s’agissait de plateformes?

R. Oui.

Q. Savez‑vous lesquelles?

R. Oui. J’ai déjà dit qu’il s’agissait des plateformes UNIX et Sun Solaris.

Q. D’accord. C’était en 1994, n’est-ce pas?

R. Oui[147].

 

 

[171] Dans ses observations écrites, l’avocat de M. Morley s’appuie aussi, notamment, sur le rapport Pritchard d’août 2003, plus précisément la page 4, afin d’établir que la version de 1993 du logiciel pouvait produire des produits vendables commercialement en 1993. M. Pritchard affirme à la même page que [traduction] « [d]e février 1993 à la fin de 1994, j’ai assisté à des démonstrations du logiciel AGENSYS […] Pendant toute cette période, le [logiciel] était un outil de création d’applications complet et opérationnel […] Il était en état de marche et pouvait créer des applications opérationnelles complexes »[148]. À mon avis cependant, cette description faite par M. Pritchard n’est pas plausible. Elle contredit directement le témoignage de M. Karnis, qui a affirmé que son évaluation de la version de 1993 du logiciel avait révélé qu’il ne pouvait pas exécuter l’application complexe AGS Mortgage sur la plateforme DOS avec ce logiciel à cause d’un bogue, auquel, selon lui, une solution a été apportée à un moment donné entre 1993 et 1996. Comment alors M. Pritchard peut‑il affirmer que le logiciel était pleinement opérationnel durant toute la période allant [traduction] « de février 1993 à la fin de 1994 »? À mon avis, M. Pritchard n’est pas suffisamment méticuleux et rigoureux pour que son témoignage soit convaincant et digne de foi[149].

 

[172] M. Pritchard soutenait dans son témoignage qu’il avait vu le logiciel tourner sur la plateforme Unix en mai 1993. Cependant, il s’est peut‑être trompé parce que, quand on lui a demandé sur quelle plateforme Kammand avait fonctionné auparavant, il a répondu que c’était sur un mini‑ordinateur IBM équipé d’[traduction] « un quelconque programme d’assemblage de base » (transcription du témoignage de M. Pritchard, 26 septembre 2003, p. 65 et 66). En fait, le logiciel tournait sur un PC avec plateforme DOS. M. Pritchard a affirmé également que certaines des versions du logiciel provenaient de [traduction] « la région de Chicago » (transcription du témoignage de M. Pritchard, p. 68). Aucun autre témoin n’a dit une telle chose. Selon les témoignages des autres témoins et la preuve documentaire, les améliorations apportées au logiciel provenaient de Phoenix et de Dallas, ainsi que, dans le cas du témoignage de M. Gamble, des îles Turks et Caicos. 

 

[173] De plus, la société Object Systems Inc. affirme dans son [traduction] « évaluation de produit » concernant le logiciel, qui est datée du 6 septembre 1994, que les versions « SCO Unix » et « Solaris Unix » ont fait l’objet d’une évaluation qui visait à confirmer qu’elles étaient compatibles avec le logiciel. Toutefois, cette évaluation portait principalement sur la plateforme PC DOS, ce qui semble contredire la lettre du 1^er décembre 1994 (onglet 145) et le rapport de mai 1995 de M. McCann (par. 49 ci‑dessus).

 

[174] Un rapport daté du 31 juillet 1995 (le « rapport de juillet 1995 ») propose une façon de concilier certains de ces éléments de preuve contradictoires. Il faut cependant d’abord rappeler que M. Karnis a été embauché en juin 1995 pour aider M. McCann à préparer une démonstration visant à illustrer la portabilité du logiciel sur DOS et sur SE Sun/Solaris. M. Karnis a essayé de compiler le logiciel afin qu’il puisse être utilisé sur la plateforme Sun Solaris, mais il s’est buté à de nombreuses difficultés. Il a dû consacrer plusieurs semaines à corriger les bogues du programme. Le problème a été décrit dans les termes suivants dans le rapport de juillet 1995 (onglet 240) :

 

[traduction]

1) Howard Kale, Larry Karnis et moi-même avons travaillé ensemble pour faire en sorte que la version Solaris fonctionne sur la machine Sun. Nous avons finalement réussi. […] Nous avons constaté que le module de développement d’Agensys n’a jamais fonctionné pendant l’examen du code de Dale Grantham. Voilà pourquoi personne n’a jamais vu le module de développement mais seulement la version exécutable. Les fichiers que nous a fournis Howard par l’intermédiaire de Dale étaient incomplets, et nous avons dû consacrer près de trois semaines à résoudre le problème. Nous avons réussi à faire fonctionner la version exécutable, mais pas le module de développement.

 

[175] L’identité de l’auteur de ce rapport n’est pas connue, mais il s’agit probablement de M. McCann, qui avait demandé à M. Karnis de l’aider à installer la plateforme Sun/Solaris. La différence entre la version de développement (module de développement) et la version exécutable est déterminante et elle offre la possibilité de résoudre les diverses contradictions contenues dans la preuve et dans les témoignages. La version exécutable du logiciel décrit pour une ou plusieurs plateformes était peut‑être prête à être mise en service dès 1993, mais la version de développement, qui est très importante et qui est nécessaire pour développer des applications opérationnelles, était prête à être mise en service seulement à compter de la fin de 1994. Par exemple, les versions de développement pour les plateformes SCO Unix et SE Sun/Solaris ont été livrées en version bêta le 1^er décembre 1994, dans le cadre des améliorations de 1994, mais la version définitive qui a été livrée le 31 janvier 1995 a été refusée en mars 1995. Cela semble conforme au paragraphe 4 de l’énoncé des travaux (joint à l’entente de développement de 1994, onglet 68), qui est libellé comme suit :

 

[traduction]

4. Résumé de l’objet du présent énoncé des travaux : Le présent énoncé des travaux a pour objet de mettre en oeuvre le système de développement Agensys et d’y ajouter des fonctionnalités. Il s’agit d’ajouter les plateformes précisées dans la description des produits livrables, de faciliter les protocoles de communication également décrits et d’ajouter les fonctionnalités d’IUG à la version AGS (exécutable) du système de développement Agensys, précisées elles aussi dans la description des produits livrables.

[Non souligné dans l’original.]

 

[176] Cela peut aussi expliquer toutes les difficultés qui ont surgi en juin et en juillet 1995 lorsque M. McCann a essayé d’installer la version de développement sur la plateforme SE Sun/Solaris. Selon toute vraisemblance, seule la version DOS du logiciel (la version exécutable et peut‑être aussi la version de développement) était donc prête à être mise en service à la fin de 1993. Il ressort toutefois de la preuve d’expert de M. Karnis et de M. Travers que le logiciel ne pouvait pas créer ni faire fonctionner correctement AGS Mortgage à cause des bogues qu’il comportait[150].

 

[177] À mon avis, le fait que M. Travers, l’expert de l’intimée, a été en mesure de programmer une application très simple ne constitue pas une preuve concluante du fait que le logiciel décrit était pleinement opérationnel. Il faut se rappeler que M. Travers a seulement examiné la moitié des commandes et qu’il a détecté [traduction] « plusieurs bogues » lorsqu’il a utilisé le module de conception d’applications. M. Karnis a aussi détecté des bogues lorsqu’il a essayé de programmer une application plus complexe, comme AGS Mortgage. Il ne disposait pas de suffisamment de temps et de ressources pour corriger ces bogues. Par conséquent, nous ne savons pas avec certitude s’il aurait eu des problèmes à mettre en application sa solution et s’il y avait d’autres bogues qu’une mise à l’essai complète de la version de 1993 du logiciel aurait pu révéler. Selon M. Karnis, les bogues qu’il avait détectés [traduction] « [n’enlevaient] absolument rien aux qualités techniques générales [d’Agensys] à titre d’outil de développement d’applications » et il était possible d’utiliser la version de 1993 du logiciel [traduction] « pour créer, maintenir, améliorer et exécuter » une application complexe et d’envergure comme AGS Mortgage.

 

[178] Toutefois, la question qu’il faut trancher en l’espèce est de savoir si le logiciel a été « livré » en 1993 et s’il pouvait « être utilisé […] pour produire un produit ou fournir un service qui [était] vendable commercialement ». Il faut se rappeler que le plan d’affaires de la société en commandite était fondé au départ sur l’approche axée sur le produit. Je ne crois pas que le logiciel décrit aurait pu être vendu à des utilisateurs finaux avant d’avoir été pleinement testé à l’aide des [traduction] « tests d’acceptation » décrits dans la note de service portant sur les tests d’acceptation de 1993 et avant que le bogue concernant l’instruction KMD‑PROG ait été réglé. Même si l’approche axée sur la consultation avait été adoptée en 1993, je ne crois pas que le logiciel décrit, qui comportait des bogues, pouvait être utilisé pour développer une application de façon satisfaisante.

 

[179] Il importe de préciser que je ne pense pas que seuls les logiciels ne comportant aucun bogue peuvent satisfaire au critère prévu à l’alinéa 13(27)d) de la Loi. Je sais que des logiciels comportant des bogues sont trop souvent vendus. La présence de ces bogues ne peut être que l’un des facteurs qui doivent être pris en compte dans le cadre de l’application de l’alinéa 13(27)d) de la Loi.

 

[180] L’une des raisons de ne pas accorder beaucoup de poids à l’opinion de M. Karnis, dont les connaissances techniques m’ont cependant impressionné, est le fait que la société en commandite n’a pas effectué de tests d’acceptation avant février 1995. Je suis convaincu[151] que les fabricants de logiciels ne vendent pas de produits à leurs clients avant de les avoir soumis à des tests rigoureux. Il serait encore acceptable, après que des tests ont été effectués, que le logiciel comporte toujours des bogues. Il serait irresponsable et suicidaire pour ces fabricants d’agir autrement. En conséquence, si le logiciel n’a pas été testé par la société en commandite avant février 1995, c’est parce que son développement n’était pas terminé, à tout le moins à la fin de 1993, la seule année d’imposition, outre 1990, en cause dans les présents appels.

 

[181] L’opinion de M. Karnis peut être comparée au verre à moitié plein ou à moitié vide. Comme l’ensemble de la preuve mène à la conclusion que le logiciel décrit n’était pas complet en 1993, j’estime que l’opinion de M. Karnis confirme que la version de 1993 du logiciel n’était pas opérationnelle en novembre 1993, la date pertinente à laquelle les codes sources qu’il a examinés ont été créés. Compte tenu du manque de preuve démontrant que les bogues ont été réglés avant la fin de 1993, je ne peux conclure que le logiciel décrit était complet et opérationnel en 1993.

 

[182] S’il restait des doutes après avoir tenu compte de l’ensemble des circonstances relatives à la création du logiciel décrit, ces doutes sont dissipés par l’évaluation dévastatrice qui a été effectuée par M. Paul Mighton dans son plan d’affaires de septembre 1995, à la page 8 (onglet 250). M. Mighton écrit, au sujet de l’historique du développement du logiciel : [traduction] « Le fait qu’AGENSYS ADE[152] n’était pas prêt à être commercialisé au moment de l’acquisition des droits mondiaux de commercialisation a causé une importante perte de temps. » [Non souligné dans l’original.]

 

[183] À mon avis, je dispose d’une preuve claire qui me permet de conclure qu’en 1993 le logiciel décrit n’était pas « utilis[é] [par le contribuable] pour gagner un revenu », comme l’exige l’alinéa 13(27)a) de la Loi. Aucune vente du logiciel n’avait jamais été réalisée et le logiciel n’était pas utilisé en 1993 pour créer des solutions commerciales à l’intention des clients éventuels. De plus, je ne suis pas convaincu que le logiciel décrit a été livré[153] (au sens du sous‑alinéa 13(27)d)(i) de la Loi) avant la fin de 1993 et qu’à l’époque il « [pouvait] être utilisé […] pour produire un produit ou fournir un service qui [était] vendable commercialement » au sens du sous‑alinéa 13(27)d)(ii) de la Loi. M. Morley avait le fardeau de démolir l’hypothèse de fait du ministre selon laquelle le logiciel n’était pas prêt à être mis en service. Il ne s’est pas acquitté de ce fardeau.

 

(H)    Y a-t-il eu atteinte aux droits garantis par la Charte à M. Morley?

 

[184] M. Morley allègue que ses droits garantis par la Charte ont été violés lorsque le ministre a commencé son enquête sur une possible évasion fiscale visée à l’article 239 de la Loi. Il invoque expressément les articles 7 et 8 de la Charte canadienne des droits et libertés :

 

7.         Chacun a droit à la vie, à la liberté et à la sécurité de sa personne; il ne peut être porté atteinte à ce droit qu’en conformité avec les principes de justice fondamentale.

 

8.         Chacun a droit à la protection contre les fouilles, les perquisitions ou les saisies abusives.

 

[185] M. Morley fait valoir que le ministre a commencé son enquête criminelle dès août 1995, lorsque le vérificateur de l’évitement fiscal a indiqué dans une ébauche de note de service adressée aux ES qu’il croyait qu’une escroquerie avait été commise par le promoteur de l’abri fiscal et que les déductions fiscales étaient frauduleuses. Sa demande d’envoyer la note de service a toutefois été refusée, probablement par son supérieur, de sorte que la note n’a jamais été transmise aux ES. Une autre note de service quasi identique rédigée le 7 février 1996 n’a pas non plus été transmise aux ES. Ce n’est que le 19 septembre 1996 qu’une note de ce genre a été envoyée et ce n’est pas avant le 30 septembre 1997 qu’un gestionnaire des ES a informé M. Gamble qu’une enquête criminelle préliminaire avait été entreprise et qu’il avait le droit de garder le silence.

 

[186] M. Morley n’a jamais été informé de ses droits parce qu’il était absent – il était en vacances – lorsque la perquisition et la saisie ont été effectuées chez lui le 8 octobre 1997. Ce n’est qu’à son retour qu’il a été mis au courant de l’enquête criminelle. M. Morley soutient que ses droits garantis par la Charte ont été violés non seulement parce qu’il n’a jamais été informé de ses droits, mais aussi parce que l’enquête criminelle avait commencé, à son avis, dès août 1995. Il a assisté à des rencontres, dont l’une le 29 avril 1996, au cours de laquelle lui et M. Gamble se sont fait poser des questions. À l’époque, le ministre ne les a jamais informés de leur droit de garder le silence. En outre, la preuve démontre que le vérificateur de l’évitement fiscal qui a transféré le dossier aux ES était en communication avec l’enquêteur et lui transmettait de l’information au soutien de son exposé de position. L’enquêteur s’est servi de ce document, qui était essentiellement constitué du rapport de son vérificateur concernant la société en commandite, pour déterminer s’il y avait un motif suffisant d’entreprendre une enquête criminelle et de la poursuivre. Ce processus s’est déroulé de septembre 1996 au 8 août 1997.

 

[187] Il est utile de passer en revue la jurisprudence traitant de preuve viciée et du redressement que la Cour de l’impôt devrait accorder dans une affaire de cotisation fiscale et de pénalités où des éléments de preuve viciés sont produits. L’une des premières affaires dans lesquelles la Cour de l’impôt s’est penchée sur la question du redressement qu’elle pouvait accorder en cas d’atteinte aux droits garantis par la Charte est O’Neill Motors Limited v. The Queen, 96 DTC 1486, une décision rendue le 9 novembre 1995 qui a ensuite été confirmée par la Cour d’appel fédérale (98 DTC 6424). Dans ses motifs, la Cour a déclaré que l’enquête avait été effectuée de manière irrégulière par les représentants du ministre; l’avocat du ministre a admis que, si la preuve ainsi obtenue était inadmissible au motif qu’elle était viciée, il ne serait pas en mesure de justifier la cotisation. En conséquence, le juge Bowman (plus tard juge en chef) a décidé d’annuler la cotisation. Il a toutefois souligné que l’annulation de la cotisation ne devait pas être considérée comme une mesure de redressement normale, mais être utilisée uniquement dans des cas extrêmes.

 

[188] Une approche plus souple a été privilégiée dans d’autres décisions. Par exemple, dans la décision Donovan v. The Queen, 98 DTC 2140, du 15 octobre 1998, ma collègue la juge Lamarre Proulx a conclu que la preuve démontrant que le vérificateur n’avait pas informé le contribuable de manière appropriée qu’il se présenterait chez lui avec un enquêteur des ES n’était pas suffisante pour influer sur la validité des cotisations établies à l’égard du contribuable par suite de cette visite, ces cotisations étant de nature civile et non des mesures criminelles découlant de la cotisation établie par le ministre. En appel, le contribuable alléguait que quatre actes répréhensibles principaux avaient été commis contre lui relativement à la perquisition et à la saisie qui avaient été effectuées. La Cour d’appel fédérale (2000 DTC 6339) a confirmé la décision de la Cour de l’impôt au regard de trois de ces actes répréhensibles. Ce n’est qu’en raison du quatrième que la cotisation a été annulée en partie. Cet arrêt de la Cour d’appel fédérale a été rendu avant l’arrêt R. c. Jarvis, [2002] ACS n^o 76 (Q.L.), 2002 CSC 73, de la Cour suprême du Canada dont il est question ci‑dessous.

 

[189] Afin de déterminer s’il y a eu atteinte aux droits garantis par la Charte à M. Morley, il est important d’examiner de quels pouvoirs jouit le ministre lorsqu’il mène simultanément une enquête (l’« enquête ») visant à déterminer la responsabilité pénale (criminelle) d’un contribuable et une vérification (la « vérification » ayant pour but d’établir une cotisation de l’impôt dû par ce contribuable, y compris une amende administrative. L’arrêt pertinent le plus récent rendu par la Cour suprême du Canada, à savoir Jarvis, est très instructif à cet égard. Aux paragraphes 85 et suivants, la Cour exprime son opinion sur la question de savoir comment délimiter la frontière entre une vérification et une enquête, affirmant en particulier ce qui suit aux paragraphes 88 à 94 et 97 :

 

88        À notre avis, lorsqu’un examen dans un cas particulier a pour objet prédominant d’établir la responsabilité pénale du contribuable, les fonctionnaires de l’ADRC doivent renoncer à leur faculté d’utiliser les pouvoirs d’inspection et de demande péremptoire que leur confèrent les par. 231.1(1) et 231.2(1). Essentiellement, les fonctionnaires [traduction] « franchissent le Rubicon » lorsque l’examen crée la relation contradictoire entre le contribuable et l’État. Il n’existe pas de méthode claire pour décider si tel est le cas. Pour déterminer si l’objet prédominant d’un examen consiste à établir la responsabilité pénale du contribuable, il faut plutôt examiner l’ensemble des facteurs qui ont une incidence sur la nature de cet examen.

 

89        D’abord, la simple existence de motifs raisonnables de croire qu’il peut y avoir eu perpétration d’une infraction est insuffisante en soi pour conclure que l’objet prédominant d’un examen consiste à établir la responsabilité pénale du contribuable. Même lorsqu’il existe des motifs raisonnables de soupçonner la perpétration d’une infraction, il ne sera pas toujours exact de dire que l’objet prédominant de l’examen est d’établir la responsabilité pénale du contribuable. À cet égard, les tribunaux doivent se garder d’imposer des entraves de nature procédurale aux fonctionnaires; il ne serait pas souhaitable de [traduction] « forcer la main des autorités réglementaires » en les privant de la possibilité de recourir à des peines administratives moindres chaque fois qu’il existe des motifs raisonnables de croire à l’existence d’une conduite plus coupable. Ce point a été exprimé clairement dans l’arrêt McKinlay Transport, précité, p. 648, où le juge Wilson affirme : « Le Ministre doit être capable d’exercer ces [larges] pouvoirs [de surveillance], qu’il ait ou non des motifs raisonnables de croire qu’un certain contribuable a violé la Loi ». Bien que l’existence de motifs raisonnables constitue en fait une condition nécessaire à la délivrance d’un mandat de perquisition pour mener une enquête criminelle (art.  231.3 de la LIR et 487 du Code criminel) et pourrait, dans certains cas, indiquer que les pouvoirs de vérification ont été utilisés à mauvais escient, cet élément ne suffit pas pour établir que l’ADRC mène une enquête de facto. Dans la plupart des cas, si l’on croit raisonnablement à la présence de tous les éléments d’une infraction, il est probable que le processus d’enquête sera enclenché.

 

90        On peut encore moins retenir comme critère le simple soupçon qu’une infraction a été commise. Au cours de sa vérification, le vérificateur peut soupçonner toutes sortes de conduites répréhensibles, mais on ne peut certainement pas affirmer qu’une enquête est enclenchée dès l’apparition d’un soupçon. Sur le fondement de quels éléments de preuve un enquêteur pourrait-il obtenir un mandat de perquisition si un vague soupçon était suffisant pour bloquer le processus de vérification qui permet d’établir les faits? L’intérêt qu’a l’État à poursuivre ceux qui éludent volontairement le paiement d’un impôt revêt une grande importance, et nous devons nous garder de neutraliser la capacité de l’État d’enquêter et de recueillir des éléments de preuve de la perpétration de ces infractions.

 

91        L’autre extrême ne semble pas mieux convenir. Ce serait une fiction de dire que la relation de nature contradictoire ne prend naissance qu’au moment du dépôt des accusations. En toute logique, cela ne se produira qu’une fois que les enquêteurs croiront avoir obtenu la preuve de l’existence d’une conduite répréhensible. Puisque les infractions visées à l’art.  239 comportent un élément de culpabilité morale, il faut présumer que l’État disposera habituellement d’une preuve que l’accusé avait la mens rea requise avant de déposer une dénonciation ou de présenter un acte d’accusation. La collecte active de ces éléments de preuve indique que la relation de nature contradictoire a pris naissance puisqu’il s’agit là d’un aspect non pertinent pour l’évaluation de l’obligation fiscale. Par ailleurs, bien qu’il existe des mécanismes de contrôle judiciaire de l’exercice non autorisé d’un pouvoir (Roncarelli c. Duplessis, 1959 CanLII 50 (SCC), [1959] R.C.S. 121; Babcock c. Canada (Procureur général), 2002 CSC 57 (CanLII), [2002] 3 R.C.S. 3, 2002 CSC 57, par. 25), nous sommes d’avis que permettre aux fonctionnaires de l’ADRC d’avoir recours à l’application des par. 231.1(1) et 231.2(1) jusqu’au dépôt des accusations pourrait favoriser la mauvaise foi chez les poursuivants. Il est tout à fait concevable qu’il puisse survenir des situations où le dépôt des accusations sera retardé afin de contraindre le contribuable à fournir des éléments de preuve contre lui-même pour les besoins d’une poursuite sous le régime de l’art. 239. Bien que l’intimée ait soutenu que les tribunaux pourraient remédier à de telles situations, nous estimons préférable de les éviter plutôt que d’y remédier. C’est pourquoi le critère applicable est celui exposé précédemment.

 

92        Le fait que le dossier a été ou non transmis à la section des enquêtes constitue un autre facteur à prendre en compte pour déterminer s’il existe une relation de nature contradictoire. Encore une fois, ce facteur n’est pas déterminant en soi. Même lorsqu’un vérificateur recommande que les enquêteurs examinent un dossier, il se peut qu’aucune enquête criminelle ne soit engagée, car il est toujours possible que le dossier soit retourné à la vérification. Cependant, si un vérificateur est d’avis qu’un dossier devrait être envoyé aux enquêteurs, le tribunal doit examiner très attentivement ce qui se passe ensuite. Si le dossier est retourné à la vérification, les enquêteurs ont-ils réellement décidé de ne pas examiner le dossier et l’ont-ils retourné aux vérificateurs pour que ceux-ci terminent la vérification? L’ont-ils plutôt retourné pour des raisons de commodité afin que le vérificateur puisse utiliser les par. 231.1(1) et 231.2(1) pour obtenir des éléments de preuve pour les besoins d’une poursuite (comme le tribunal l’a constaté dans l’affaire Norway Insulation, précitée)?

 

93        Rappelons que, pour déterminer à quel moment la relation entre l’État et le particulier est effectivement devenue une relation de nature contradictoire, il faut tenir compte du contexte, en examinant tous les facteurs pertinents. À notre avis, la liste suivante de facteurs sera utile pour déterminer si un examen a pour objet prédominant d’établir la responsabilité pénale du contribuable. À l’exception de la décision claire de procéder à une enquête criminelle, aucun facteur n’est nécessairement déterminant en soi. Les tribunaux doivent plutôt apprécier l’ensemble des circonstances et déterminer si l’examen ou la question en cause crée une relation de nature contradictoire entre l’État et le particulier.

 

94        À cet égard, le juge de première instance examinera tous les facteurs, y compris les suivants :

 

a)       Les autorités avaient-elles des motifs raisonnables de porter des accusations? Semble-t-il, au vu du dossier, que l’on aurait pu prendre la décision de procéder à une enquête criminelle?

b)      L’ensemble de la conduite des autorités donnait-il à croire que celles-ci procédaient à une enquête criminelle?

 

c)       Le vérificateur avait-il transféré son dossier et ses documents aux enquêteurs?

d)      La conduite du vérificateur donnait-elle à croire qu’il agissait en fait comme un mandataire des enquêteurs?

e)       Semble-t-il que les enquêteurs aient eu l’intention d’utiliser le vérificateur comme leur mandataire pour recueillir des éléments de preuve?

f)       La preuve recherchée est-elle pertinente quant à la responsabilité générale du contribuable ou, au contraire, uniquement quant à sa responsabilité pénale, comme dans le cas de la preuve de la mens rea?

g)       Existe-t-il d’autres circonstances ou facteurs susceptibles d’amener le juge de première instance à conclure que la vérification de la conformité à la loi était en réalité devenue une enquête criminelle?

Il faut aussi souligner que le présent pourvoi concerne l’ADRC. Il se pourrait toutefois que d’autres ministères ou organismes gouvernementaux fédéraux ou provinciaux aient des structures organisationnelles différentes. Il pourrait alors être nécessaire, pour cette raison, d’appliquer certains facteurs, dont les facteurs qui précèdent, en tenant compte de leur contexte particulier.

 

[…]

 

97        Le critère de l’objet prédominant n’empêche pas l’ADRC de mener parallèlement une enquête criminelle et une vérification administrative. Le fait que l’ADRC enquête sur la responsabilité pénale d’un contribuable n’écarte pas la possibilité que soit menée simultanément une enquête dont l’objet prédominant consiste à évaluer l’obligation fiscale du même contribuable. Toutefois, si une enquête sur la responsabilité pénale est engagée postérieurement, les enquêteurs peuvent utiliser les renseignements obtenus conformément aux pouvoirs de vérification avant le début de l’enquête criminelle, mais non les renseignements obtenus conformément à ces pouvoirs après le début de l’enquête sur la responsabilité pénale. Cela vaut tout autant lorsque les enquêtes touchant la responsabilité pénale et l’obligation fiscale visent la même période d’imposition. Tant que l’enquête parallèle a effectivement pour objet prédominant d’évaluer l’obligation fiscale du contribuable, les vérificateurs peuvent continuer d’avoir recours aux par. 231.1(1) et 231.2(1). […] En d’autres termes, les pouvoirs de contrainte conférés par les par. 231.1(1) et 231.2(1) ne peuvent être exercés pour obtenir des déclarations verbales ou la production de documents écrits dans le but de faire progresser une enquête criminelle.

 

[190] Ainsi, à la lumière de ce qui précède, il est évident qu’il était possible pour le ministre d’effectuer parallèlement une vérification dans le but d’établir une nouvelle cotisation et une enquête visant à déterminer s’il y avait des motifs de porter des accusations contre M. Morley (et d’autres personnes ayant des liens avec la société en commandite) en vertu de l’article 239.

 

[191] Il importe de rappeler certains faits pertinents et certaines étapes clés de la vérification. Celle‑ci a commencé en juillet ou en août 1994. En fait, une lettre datée du 22 juillet 1994 a été envoyée à M. Gamble par un vérificateur de la section de l’évitement fiscal. Après l’échange de nombreuses lettres et plusieurs rencontres, démonstrations et différends concernant la question de savoir si les codes sources allaient être fournis aux consultants embauchés par le ministre pour déterminer la nature du logiciel et sa valeur, la vérification a pris fin en juillet 1996. Le vérificateur de l’évitement fiscal était prêt à informer les commanditaires de l’intention du ministre d’établir de nouvelles cotisations à leur égard le 31 juillet 1996 (onglet 335), mais M^e Beach a réussi à bloquer ce processus jusqu’en octobre 1996 (onglets 328, 338, 339, 341, 352 et 354). La vérification visant M. Morley a officiellement pris fin en novembre 1997, après qu’il eut demandé plus de temps pour présenter des observations au ministre et qu’il eut signé une renonciation à cette fin. Il s’agissait cependant d’appliquer à son cas la même décision qu’aux autres. Les rencontres postérieures aux cotisations de novembre 1996 ont eu lieu principalement à la demande de M. Gamble. C’est le cas par exemple de la rencontre du 29 avril 1997, à laquelle M. Morley et le directeur de l’évitement fiscal étaient présents (onglets 389 et 390).

 

[192] Il faut se rappeler que le fait qu’un vérificateur de l’évitement fiscal a des motifs raisonnables de croire qu’une infraction a été commise n’est pas suffisant en soi pour transformer une vérification en une enquête (paragraphe 89 de l’arrêt Jarvis). Il faut déterminer si l’objet prédominant de l’enquête consiste à établir la responsabilité pénale du contribuable. En outre, le fait que le dossier a été transmis à la section des enquêtes n’est pas déterminant en soi au regard d’une enquête qui a commencé (voir le paragraphe 92 de l’arrêt Jarvis).

 

[193] Par ailleurs, il est indiqué au paragraphe 97 de l’arrêt Jarvis qu’il est possible de mener parallèlement une enquête criminelle et une vérification administrative. Aux fins de la vérification, le contribuable n’est pas tenu d’être informé de son droit de garder le silence. Aussi, il est difficile de conclure en l’espèce que le vérificateur de l’évitement fiscal a effectué son travail dans le cadre d’une enquête criminelle lorsque l’on tient compte de tous les faits. Je ne pense pas que le fait qu’il soupçonnait simplement qu’il pouvait y avoir des motifs raisonnables de croire qu’une infraction avait été commise est suffisant pour transformer ses activités en une enquête criminelle. Le fait que son supérieur n’a pas approuvé la transmission de son dossier aux ES peut aussi indiquer que ses motifs n’étaient même pas suffisants pour justifier une telle mesure. Quoi qu’il en soit, il n’appartenait pas au vérificateur de l’évitement fiscal de mener une enquête sur une infraction criminelle. C’était le rôle de l’enquêteur des ES. Rien n’indique que le vérificateur de l’évitement fiscal a agi à titre de mandataire de l’enquêteur des ES ou qu’il a transmis à ce dernier des renseignements obtenus après le début de l’enquête criminelle.

 

[194] Il est possible que le supérieur du vérificateur de l’évitement fiscal ait décidé de reporter la transmission du dossier aux ES pour des raisons qui n’étaient pas valables, mais la preuve dont je dispose ne le démontre pas et je n’ai aucune raison de croire que ce fut le cas. En outre, je ne dispose d’aucune preuve démontrant que l’information obtenue par le vérificateur de l’évitement fiscal l’a été principalement aux fins d’une enquête criminelle. Le fait que le processus de vérification était presque terminé en juillet 1996 et qu’il était terminé en novembre 1996 au regard de bon nombre des commanditaires étaye la thèse selon laquelle c’est à la demande du contribuable qu’il y a eu rencontre après que le dossier eut été transmis aux ES. M. Gamble espérait toujours pouvoir convaincre la section de la vérification qu’il n’y avait aucune raison de refuser les pertes.

 

[195] Je ne dispose d’aucune preuve non plus qui indiquerait que le vérificateur de l’évitement fiscal a transmis à l’enquêteur des ES des renseignements obtenus après qu’il eut rempli sa dénonciation. Il n’a pas été demandé au vérificateur, lors de son contre‑interrogatoire préalable, de décrire de façon détaillée le type d’information qu’il aurait transmis à l’agent des ES. Pour toutes ces raisons, je conclus qu’il n’a pas été démontré que les droits garantis par la Charte à M. Morley ont été violés.

 

[196] Lors de l’audition d’une requête préalable au procès, j’avais fait savoir aux parties que la question de la violation de la Charte devait être soulevée au moment du dépôt des pièces. Cette question n’a pas été soulevée à l’audience lorsque les pièces ont été déposées. M. Morley ayant consenti à la production de la plupart des éléments de preuve, il serait difficile d’imaginer comment il pourrait invoquer des motifs justifiant l’annulation de la cotisation. Comme il l’a indiqué dans ses observations écrites, l’avocat de M. Morley faisait valoir que les arguments fondés sur la Charte pourraient être plus pertinents au regard de la détermination des dépens. Cette question ayant été soulevée, j’ai indiqué que je ne rendrais pas d’ordonnance relative aux dépens avant d’avoir donné aux deux parties la possibilité de présenter des observations.

 

III      Conclusion

 

[197] Pour tous ces motifs, les appels interjetés par M. Morley sont accueillis et les cotisations établies pour les années d’imposition 1990 et 1993 sont renvoyées au ministre du Revenu national pour nouvel examen et nouvelles cotisations, compte tenu du fait que M. Morley a droit à sa part des pertes de la société en commandite, que ces pertes devraient être déterminées en tenant compte du fait que le logiciel a été acquis par la société en commandite en 1993 en vue de tirer un revenu de son exploitation, mais qu’il n’était pas prêt à être mis en service cette année‑là, et que les pénalités devraient être annulées.

 

Signé à Ottawa, Canada, ce 13^e jour d’avril 2004.

 

 

« Pierre Archambault »

Juge Archambault

 

 

Traduction certifiée conforme

ce 15^e jour de janvier 2014.

 

 

Mario Lagacé, jurilinguiste

 

 

	ANNEXE DU PARAGRAPHE 130 DES MOTIFS DU JUGEMENT
Logiciel AGENSYS au Canada
Détermination de la juste valeur marchande
au 30 juin 1993
						Annexe 1
			Valeur minimale			Valeur maximale
Valeur non rajustée
	Fourchette des valeurs minimales – annexe 2A		798 500
	Fourchette des valeurs maximales – annexe 2B					1 356 000
Moins : rajustement relatif aux frais de développement
	Fourchette des montants minimaux – annexe 5A		(250 900)
	Fourchette des montants maximaux – annexe 5B					(220 900)
Juste valeur marchande du logiciel			547  600			1 135 100
	Montant arrondi		548 000			1 135 000
Hypothèses
	Pour la valeur MINIMALE, le taux d’actualisation est de 45 % et le multiplicateur est 7.
	Pour la valeur MAXIMALE, le taux d’actualisation est de 40 % et le multiplicateur est 9.
	Le logiciel a été acquis et était prêt à être mis en service en 1993.
	Seuls les frais de développement continus sont pris en compte, pas les frais initiaux.
	Les frais de développement sont ajoutés à la FNACC et sont assujettis à la règle de la demi‑année.

 

 

Logiciel Agensys au Canada
Détermination de la valeur non rajustée
Fourchette des valeurs minimales
																									Annexe 2A
																									Valeur
				1992	1993	1994		1995			1996	1997			1998		1999					2000	2001	2002	finale
Flux de trésorerie discrétionnaires				0	(39 609)	62 242		(42 069)			144 651	476 630			864 584		1 302 679					1 636 598	1 715 194	1 833 413	1 904 751
	Annexe 3A
Multiplicateur – valeur finale																									7
Valeur finale						0		0			0	0			0		0					0	0	0	13 333 254
Valeur actualisée à 45 %				0	(27 315)	29 602		(13 798)			32 719	74 349			93 008		96 643					83 732	60 518	44 612	324 432
Valeur actualisée :
		Période de prévision		474 068
		Valeur finale		324 432
		Valeur non rajustée		798 500
				798 500	=(VAN(C$41,D$13:M$13))+VAN(C$41,E18:N18)

 

 

Logiciel Agensys au Canada
Détermination de la valeur non rajustée
Fourchette des valeurs maximales
													Annexe 2B
													Valeur
		1992	1993	1994	1995	1996	1997	1998	1999	2000	2001	2002	finale
Flux de trésorerie discrétionnaires		0	85 829	187 679	(42 069)	144 651	476 630	864 584	1 302 679	1 636 598	1 715 194	1 833 413	1 904 751
	Annexe 3B
Multiplicateur – valeur finale													9
Valeur finale				0	0	0	0	0	0	0	0	0	17 142 755
Valeur actualisée à 40 %		0	61 304	95 748	(15 330)	37 649	88 607	114 802	123 549	110 866	82 990	63 363	592 451
Valeur actualisée :
	Période de prévision	763 549
	Valeur finale	592 451
	Valeur non rajustée	1 356 000
		1 356 000	=(VAN(C$41,D$13:M$13))+VAN(C$41,E18:N18)

 

 

Logiciel Agensys au Canada
Projections des flux de trésorerie discrétionnaires
Fourchettes des montants minimaux
												Annexe 3A
	1992	1993	1994	1995	1996	1997	1998	1999	2000	2001	2002	Années subséquentes
Bénéfice d’exploitation selon les projections de M. Pritchard	0	(364 955)	(157 247)	17 160	516 834	1 265 070	1 920 381	2 848 313	3 062 101	3 224 692	3 463 183	3 463 183
Annexe 4
Impôts sur le revenu
Récupérable (à payer) sur le bénéfice d’exploitation	0	164 230	70 761	(7 722)	(232 575)	(569 282)	(864 172)	(1 281 741)	(1 377 945)	(1 451 111)	(1 558 432)	(1 558 432)
Économie d’impôt liée à la DPA pour le logiciel		179 663	179 663	0	0	0	0	0	0	0	0	0
	0	343 892	250 424	(7 722)	(232 575)	(569 282)	(864 172)	(1 281 741)	(1 377 945)	(1 451 111)	(1 558 432)	(1 558 432)
Flux de trésorerie après impôts	0	(21 063)	93 177	9 438	284 259	695 789	1 056 210	1 566 572	1 684 156	1 773 581	1 904 751	1 904 751
Moins : besoin en fonds de roulement	0	(18 546)	(30 935)	(51 507)	(139 608)	(219 159)	(191 626)	(263 893)	(47 557)	(58 387)	(71 337)
Flux de trésorerie discrétionnaires	0	(39 609)	62 242	(42 069)	144 651	476 630	864 584	1 302 679	1 636 598	1 715 194	1 833 413	1 904 751

 

 

Logiciel Agensys au Canada
Projections des flux de trésorerie discrétionnaires
Fourchettes des montants maximaux
												Annexe 3B
		1993	1994	1995	1996	1997	1998	1999	2000	2001	2002	Années subséquentes
Bénéfice d’exploitation selon les projections  de M. Pritchard		(364 955)	(157 247)	17 160	516 834	1 265 070	1 920 381	2 848 313	3 062 101	3 224 692	3 463 183	3 463 183
Annexe 4
Impôts sur le revenu
Récupérable (à payer) sur le  bénéfice d’exploitation		164 230	70 761	(7 722)	(232 575)	(569 282)	(864 172)	(1 281 741)	(1 377 945)	(1 451 111)	(1 558 432)	(1 558 432)
Économie d’impôt liée à la DPA  pour le logiciel		305 100	305 100	0	0	0	0	0	0	0	0	0
		469 330	375 861	(7 722)	(232 575)	(569 282)	(864 172)	(1 281 741)	(1 377 945)	(1 451 111)	(1 558 432)	(1 558 432)
Flux de trésorerie après impôts		104 375	218 614	9 438	284 259	695 789	1 056 210	1 566 572	1 684 156	1 773 581	1 904 751	1 904 751
Moins : besoin en fonds de roulement		(18 546)	(30 935)	(51 507)	(139 608)	(219 159)	(191 626)	(263 893)	(47 557)	(58 387)	(71 337)
Flux de trésorerie discrétionnaires		85 829	187 679	(42 069)	144 651	476 630	864 584	1 302 679	1 636 598	1 715 194	1 833 413	1 904 751

 

 

Logiciel Agensys au Canada
Rajustement relatif aux frais de développement
Fourchette des montants minimaux
													Annexe 5A
		1992	1993	1994	1995	1996	1997	1998	1999	2000	2001	2002	Années subséquentes
Frais de développement initiaux
	estimés à
Frais de développement continus				5 641	15 050	30 717	73 181	139 842	198 128	278 396	292 861	310 620	332 319
	5 % des ventes		11 282	30 101	61 434	146 362	279 684	396 256	556 791	585 722	621 241	664 637	664 637
			(5 641)	(15 050)	(30 717)	(73 181)	(139 842)	(198 128)	(278 396)	(292 861)	(310 620)	(332 319)	(332 319)
Moins : impôts sur le revenu		0	(2 538)	(9 311)	(20 595)	(46 754)	(95 860)	(152 087)	(214 436)	(257 065)	(271 567)	(289 323)	(299 087)
Frais de développement nets		0	3 103	11 380	25 172	57 144	117 163	185 884	262 088	314 191	331 915	353 616	365 551
	Multiplicateur – valeur finale												7
	Valeur finale rajustée												2 558 854
Rajustement de la DPA relatif
	aux frais de développement		56 453	56 453
Décaissements nets		0	59 555	67 833	25 172	57 144	117 163	185 884	262 088	314 191	331 915	353 616	2 558 854
45 %	Valeur actualisée	0	41 072	32 262	8 256	12 926	18 277	19 998	19 445	16 076	11 712	8 605	62 270
	Valeur actualisée nette	250 900

 

Logiciel Agensys au Canada
Rajustement relatif aux frais de développement
Fourchette des montants maximaux
													Annexe 5B
		1992	1993	1994	1995	1996	1997	1998	1999	2000	2001	2002	Années subséquentes
Frais de développement initiaux
	estimés à
Frais de développement continus				3 385	9 030	18 430	43 909	83 905	118 877	167 037	175 717	186 372	199 391
	3 % des ventes		6 769	18 060	36 860	87 817	167 810	237 754	334 075	351 433	372 744	398 782	398 782
			(3 385)	(9 030)	(18 430)	(43 909)	(83 905)	(118 877)	(167 037)	(175 717)	(186 372)	(199 391)	(199 391)
Moins : impôts sur le revenu		0	(1 523)	(5 587)	(12 357)	(28 053)	(57 516)	(91 252)	(128 661)	(154 239)	(162 940)	(173 594)	(179 452)
Frais de développement nets		0	1 862	6 828	15 103	34 286	70 298	111 530	157 253	188 515	199 149	212 170	219 330
	Multiplicateur – valeur finale												9
	Valeur finale rajustée												1 973 973
Rajustement de la DPA relatif
	aux frais de développement		49 703	49 703
Décaissements nets		0	51 564	56 531	15 103	34 286	70 298	111 530	157 253	188 515	199 149	212 170	1 973 973
40 %	Valeur actualisée	0	36 832	28 842	5 504	8 925	13 071	14 813	14 918	12 774	9 639	7 335	68 246
	Valeur actualisée nette	220 900