JUGEMENT
CONFORMÉMENT aux motifs du jugement ci-joints, l’appel relatif aux années d’imposition 2007 et 2008 est rejeté au motif que l’appelante n’a pas effectué de recherche scientifique ni de développement expérimental au-delà de ce qui avait déjà été établi par le ministre du Revenu national.
Signé à Edmonton (Alberta), ce 8e jour de juin 2015.
Traduction certifiée conforme
ce 14e jour d’août 2015.
M.-C. Gervais
ENTRE :
HIGHWEB & PAGE GROUP INC.,
appelante,
et
SA MAJESTÉ LA REINE,
intimée.
[traduction française officielle]
MOTIFS DU JUGEMENT
I. Introduction et questions à trancher
[1] L’appelante, Highweb & Page Group Inc. (« HPGI »), a interjeté appel à l’encontre du refus par le ministre du Revenu national (le « ministre ») de déduire certaines dépenses de recherche scientifique et de développement expérimental (« RS et DE »). Une déduction de 25 200 $ a été refusée pour l’année d’imposition 2007 (phase 1) et une déduction de 37 975 $ a été refusée pour l’année d’imposition 2008 (phase 2). Le ministre a accordé des crédits d’impôt à l’investissement (« CII ») en matière de RS et DE de 2 704 $ pour l’année d’imposition 2008 (« STA2 - phase 2 »).
[2] HPGI invoque comme argument qu’elle a procédé à des investigations d’ordre technologique ou à des expérimentations en vue de résoudre les incertitudes technologiques qu’elle avait cernées. Plus précisément, HPGI affirme avoir réalisé l’investigation systématique requise ayant donné lieu à six progrès technologiques pendant la phase 1 et à un total de quatre progrès technologiques pendant la phase 2, soit trois de plus que le seul autorisé par le ministre (STA2 ‑ phase 2). Il n’y a pas de désaccord en ce qui a trait aux montants, aux dates ni à d’autres critères.
[3] Par conséquent, la question à trancher par la Cour est la suivante : les travaux réalisés par l’appelante au-delà de STA2 ‑ phase 2 constituent‑ils des activités de RS et DE?
II. Droit
[4] Pour avoir droit au CII en matière de RS et DE, un contribuable doit faire des dépenses pour des activités de recherche scientifique et de développement expérimental exercées au Canada directement par le contribuable, relativement à son entreprise, conformément au sous-alinéa 37(1)a)(i) de la Loi de l’impôt sur le revenu, LRC 1985, ch. 1 (5e suppl.) (la « Loi »).
[5] La définition d’activités de recherche scientifique et de développement expérimental figurant au paragraphe 248(1) de la Loi se rapporte à la demande de déduction de l’appelante. Elle est ainsi rédigée (non soulignée dans l’original) :
[…]
« activités de recherche scientifique et de développement expérimental » Investigation ou recherche systématique d’ordre scientifique ou technologique, effectuée par voie d’expérimentation ou d’analyse, c’est-à-dire :
a) la recherche pure, à savoir les travaux entrepris pour l’avancement de la science sans aucune application pratique en vue;
b) la recherche appliquée, à savoir les travaux entrepris pour l’avancement de la science avec application pratique en vue;
c) le développement expérimental, à savoir les travaux entrepris dans l’intérêt du progrès technologique en vue de la création de nouveaux matériaux, dispositifs, produits ou procédés ou de l’amélioration, même légère, de ceux qui existent.
Pour l’application de la présente définition à un contribuable, sont compris parmi les activités de recherche scientifique et de développement expérimental :
d) les travaux entrepris par le contribuable ou pour son compte relativement aux travaux de génie, à la conception, à la recherche opérationnelle, à l’analyse mathématique, à la programmation informatique, à la collecte de données, aux essais et à la recherche psychologique, lorsque ces travaux sont proportionnels aux besoins des travaux visés aux alinéas a), b) ou c) qui sont entrepris au Canada par le contribuable ou pour son compte et servent à les appuyer directement.
Ne constituent pas des activités de recherche scientifique et de développement expérimental les travaux relatifs aux activités suivantes :
e) l’étude du marché et la promotion des ventes;
f) le contrôle de la qualité ou la mise à l’essai normale des matériaux, dispositifs, produits ou procédés;
g) la recherche dans les sciences sociales ou humaines;
h) la prospection, l’exploration et le forage fait en vue de la découverte de minéraux, de pétrole ou de gaz naturel et leur production;
i) la production commerciale d’un matériau, d’un dispositif ou d’un produit nouveau ou amélioré, et l’utilisation commerciale d’un procédé nouveau ou amélioré;
j) les modifications de style;
k) la collecte normale de données.
[…]
[6] Cette définition est large et un peu détournée aux alinéas a), b), c) et d). En outre, elle est assujettie à des exceptions aux alinéas e) à k). Il n’est donc pas surprenant qu’une jurisprudence exposant une approche méthodologique ait à juste titre été établie.
[7] Dans la décision Northwest Hydraulic Consultants Limited v. Her Majesty The Queen, [1998] 3 CTC 2520 (« Northwest Hydraulic »), le juge Bowman met en évidence cinq critères, résumés ci-dessous par la Cour, permettant de savoir si les « expérimentations » constituent des dépenses de RS et DE :
1. Existe-t-il un risque ou une incertitude technologique?
2. Des hypothèses visant cette incertitude technologique ont-elles été formulées?
3. La procédure utilisée fait-elle appel à une méthode scientifique présentant les caractéristiques habituelles : l’observation scientifique systématique, la mesure et l’expérimentation ainsi que la modification itérative des hypothèses?
4. Y a-t-il eu un progrès technologique ou, plus simplement, des connaissances ont-elles été acquises?
5. Les étapes susmentionnées ont-elles toutes été consignées simultanément dans des dossiers détaillés?
III. Projet en général
[8] Pour toute déduction au titre de la RS et DE, les faits liés aux expérimentations réalisées sont essentiels dans le cadre d’une analyse de la Cour.
[9] L’entreprise HPGI s’occupe de la commercialisation et de la conception de logiciels numériques et de systèmes d’accessibilité en ligne. Ces produits et services aident les petites et moyennes entreprises à gérer des serveurs internes ainsi que des applications, du contenu et des procédés administratifs Web grâce à l’utilisation de la suite logicielle de HPGI « iFactum ». Le programme iFactum était en vente avant que les travaux de RS et DE soient réalisés.
[10] Le président et principal actionnaire de HPGI, M. Sarmiento, et un de ses assistants ont entrepris les travaux. M. Sarmiento a témoigné à l’audience. Il est titulaire d’une baccalauréat ès sciences en génie électrique et possède de nombreuses années d’expérience au sein de son entreprise en matière de conception et de commercialisation de logiciels liés à la gestion et à l’intégration de renseignements commerciaux. Il semble suffisamment qualifié pour mener à bien les travaux entrepris.
[11] Généralement, et comme l’a décrit l’appelante dans sa demande initiale de déduction en matière de RS et DE, la phase 1 (RS et DE 2007) et la phase 2 (RS et DE 2008) concernaient l’amélioration du produit de l’appelante par [traduction] l’« universalisation » de la compatibilité du système de gestion du contenu Web iFactum avec d’autres programmes commerciaux pour les systèmes d’exploitation (phase 1) et plateformes commerciales de serveurs Web (phase 2). En résumé, il s’agissait de mettre à jour et de modifier le programme de service iFactum pour inclure les nouveaux serveurs et logiciels Web de tiers ou leurs versions à jour.
[12] Dans son argumentation, le représentant de l’appelante a fait connaître l’hypothèse ou proposition prédominante réelle à la Cour pour chacune des phases :
Phase 1 : Le langage de conception du logiciel « J# » pourrait assurer l’interopérabilité, la communication et la fonctionnalité entre diverses plateformes logicielles de produits grâce à la modification du code d’iFactum au moyen de différents systèmes d’exploitation.
Phase 2 : iFactum pourrait assurer la compatibilité entre de multiples plateformes Web ou le contenu des services Web grâce à la modification du code d’iFactum.
[13] Par déduction, il existe une différence ciblée entre les progrès technologiques proposés pour la phase 1 et ceux proposés pour la phase 2 : les premières améliorations (phase 1) visent les systèmes d’exploitation mêmes des systèmes informatiques d’un utilisateur et les secondes (phase 2) visent la compatibilité entre des plateformes Web ou en ligne. Ce système est souvent décrit comme étant le système « intranet » d’une entreprise (phase 1), comparativement à « Internet », qui est offert au public (phase 2). Bien que les cibles soient différentes, les progrès sont théoriquement obtenus en modifiant ou en remodelant le code d’iFactum sous-jacent. Le code est simplement le langage de la séquence binaire intégrée dans le programme ou le langage d’exploitation d’iFactum, qui fournit les commandes, les directives et les schémas pour le programme.
IV. Précisions sur les travaux entrepris
[14] Bien qu’il soit logique d’examiner l’incertitude technologique et les procédures expérimentales dans leur ensemble, compte tenu des deux hypothèses prédominantes, il est plus pratique et sensé de procéder à une analyse plus élémentaire. Puisque chaque investigation ou expérimentation technologique alléguée proposée doit être axée sur l’incertitude technologique, les exercices 2007 et 2008 doivent être analysés de façon segmentée. Cette façon de faire correspond autant à l’analyse réalisée par le ministre pour rejeter la majeure partie des CII en matière de RS et DE demandés qu’à la façon dont HPGI a présenté son appel lors de l’audience. Elle correspond aussi à la jurisprudence : Les Abeilles Service de Conditionnement Inc. c. Sa Majesté la Reine, 2014 CCI 313, au paragraphe 138. En outre, une telle analyse permet de dégager les éléments clés du langage par ailleurs isolé et unique lié à la conception de logiciels. Il convient de noter que deux cahiers de preuves documentaires (intitulés [traduction] le « livre des preuves » et le « livre des documents ») ont été produits en preuve par HPGI. Seuls les documents dont il est question dans les présents motifs ont été décrits et mentionnés dans les témoignages oraux pendant l’audience et constituent donc le dossier documentaire présenté à la Cour. Ces documents particuliers ont été présentés aux parties dès le début et précisés à la fin des témoignages et avant les observations.
[15] Par conséquent, le tableau ci-joint à l’annexe 1 résume les expérimentations des phases 1 et 2 ainsi que les étapes des activités, telles qu’elles ont été décrites et analysées à l’origine par l’Agence du revenu du Canada (l’« ARC »). Les résumés proviennent du témoignage des deux témoins : pour le compte de l’appelante, M. Sarmiento, président de HPGI, et, pour le compte de l’intimée, M. Pelissero, conseiller en recherche et en technologie à l’ARC.
[16] Il incombe à l’appelante de démontrer, selon la prépondérance des probabilités, que les travaux réalisés dans le cadre des expérimentations étaient des activités de RS et DE : Zeuter Development Corporation c. Sa Majesté la Reine, 2006 CCI 597 (« Zeuter Development »), au paragraphe 26. À cette fin, la preuve documentaire de HPGI comprenait des feuilles de temps pour M. Sarmiento et les autres employés de HPGI de même qu’environ 37 entrées relatives aux billets de soutien technique selon la date pour la phase 1 et 17 entrées selon la date pour la phase 2. Ces billets de soutien technique étaient des « papillons adhésifs » informatisés indiquant les obstacles et les prochaines étapes dans une nomenclature informatique très générale. D’un autre côté, M. Pelissero de l’ARC a présenté un important rapport d’analyse technique en matière de RS et DE de 16 pages (le « rapport d’analyse technique »). L’analyse de la preuve concernant la conformité à la méthode et à la consignation scientifiques sera déterminée au moyen d’une évaluation particulière de l’incertitude technologique alléguée, des expérimentations proposées ainsi que des progrès déclarés, découlant, encore une fois presque entièrement, du rapport d’analyse technique de l’ARC susmentionné.
V. Analyse et décision
[17] L’appel est rejeté pour les raisons suivantes.
(1) Absence d’incertitude et de progrès technologiques
[18] Pour qu’il y ait une incertitude technologique, il doit y avoir des connaissances manquantes. Cette situation a été décrite par le représentant de l’appelante comme étant [traduction] « la pièce manquante d’un casse-tête ». Il ne peut s’agir d’une connaissance existante, mais simplement inconnue du demandeur de CII, ou d’une lacune pouvant être comblée en utilisant un autre produit au moyen des techniques habituellement utilisées par, dans ce cas, des développeurs de logiciels qualifiés et expérimentés. La simple combinaison de ces gens compétents et de connaissances ou autres produits facilement accessibles ne constitue pas un progrès scientifique ou du développement expérimental. Il s’agit de la recherche et du développement d’un produit. Le fait que des programmes déjà offerts, comme J# et JavaScript, soient à la base de ces réalisations donne à penser que l’incertitude ne découlait pas d’un inconnu technologique au sens de connaissance manquante, mais plutôt d’essais sélectifs et d’erreurs procédurales de séquencement : le fait de savoir quels produits offerts utilisés dans l’ordre approprié en apportant les modifications de routine, standards ou courantes permettraient de procéder à la meilleure amélioration possible du logiciel iFactum existant, mais dépassé.
[19] Ce point est aussi démontré par le CII en matière de RS et DE accordé par le ministre dans le cadre du STA2 - phase 2. Beaucoup plus de renseignements sur les données consignées ont été générés et étaient attribuables à cette incertitude, à cette expérimentation et ces progrès technologiques. De plus, il y a eu résolution des incertitudes technologiques ciblées relativement à l’encodage différentiel des plateformes .NET et Java. Des essais et des modifications individuels, dûment consignés, ont modifié les fonctions dans les protocoles par étapes. Les réalisations pendant le STA2 ‑ phase 2 ont généré des apprentissages quant à l’incertitude liée au rapprochement relatif au mappage des types de données de QueryBeans. Elle était incompatible. Une technique a été conçue pour découvrir un rapprochement des types de données partagés entre les plateformes .NET et JavaScript. Les connaissances n’ont pas été obtenues grâce à la confirmation du postulat ou de l’hypothèse, mais en prenant connaissance d’une issue dans le contexte de l’incertitude prouvée par un résultat négatif. Aucune autre expérimentation technologique ou avancée technologique détaillée découlant d’un progrès technologique de la phase 1 ou de la phase 2 n’a ainsi été définie, examinée, analysée ou résolue. Le représentant de HPGI a laissé entendre que la circulaire d’information 86‑4R3 est d’un certain secours lorsque, à première vue, il n’y avait aucune incertitude technologique. Il a fait valoir qu’il y avait bien une [traduction] « incertitude systémique ». Il était nécessaire de [traduction] « travailler sur la combinaison de technologies, d’appareils et/ou de processus » puisque les [traduction] « combinaisons non négligeables de technologies et de principes établis (bien connus) guidant l’intégration comportent un élément important » d’incertitude systémique. Dans les faits, ce n’est pas évident d’après les éléments de preuve. L’appelante n’a pas présenté suffisamment de documents ou de dossiers concurrents pour démontrer que le problème de compatibilité entre le système et Internet (au-delà du STA2 ‑ phase 2) a été suffisamment analysé pour établir la nécessité de procéder à des expérimentations technologiques ou à des investigations afin de combler la lacune technologique liée à iFactum.
(2) Aucune hypothèse claire ou investigation technologique révélée dans le témoignage n’appuie la demande de déduction en matière de RS et DE
[20] Après une journée et demie de témoignage et un interrogatoire précis de la Cour, HPGI, par l’entremise de son représentant, a réuni les deux hypothèses susmentionnées : une axée sur le système d’exploitation et l’autre sur les interfaces Web et Internet. Le témoignage de M. Sarmiento n’indiquait pas clairement que les hypothèses étaient documentées au moment où les travaux ont été réalisés. La présence de ces hypothèses, dès le début, est essentielle pour fournir à la Cour une preuve concrète que les expérimentations et les investigations technologiques existaient au départ pour surmonter l’incertitude. La seule exception à cette situation concernait le STA2 ‑ phase 2 du rapport d’analyse technique. Pendant le STA2 ‑ phase 2, l’usage fréquent par HPGI des mots [traduction] « incompatibilité », [traduction] « impossible à résoudre avec les produits existants » et [traduction] « recherches requises » était une caractéristique de l’incertitude technologique existante qui a intuitivement mené à l’élaboration d’une hypothèse et à la tenu d’investigations technologiques détaillées. Le ministre a accordé cette demande de déduction, mais a rejeté les autres. Pour la Cour, ces faits sont conformes à la jurisprudence, qui affirme logiquement que, pour qu’une incertitude soit surmontée, un « compte rendu détaillé […] doi[t] être fait […] au fur et à mesure de l’avancement des travaux » (Northwest Hydraulic au paragraphe 16). Cela ne concordait pas avec les faits de l’espèce de HPGI; la mince preuve documentaire consignée, préparée et rassemblée simultanément par l’appelante n’était pas suffisante pour montrer l’investigation et les expérimentations technologiques requises afin de confirmer ou d’infirmer les hypothèses, sauf pour le STA2 ‑ phase 2.
[21] Il n’y avait pas de preuve indiquant que les travaux réalisés étaient, tout bien considéré, plus qu’une activité de base de HPGI liée à la conception de logiciels et à la modification d’un de ses produits existants. Le programme, iFactum, avait besoin d’une mise à jour habituelle, une tâche très répandue au sein de l’industrie. Les éléments de preuve ne montraient pas que les travaux réalisés dépassaient l’application des pratiques et des procédures normales, même s’il s’agissait de produits récemment conçus ou mis à jour par un tiers. Peu d’éléments de preuve donnaient à penser que les travaux ne servaient pas uniquement à améliorer le produit iFactum à l’aide de produits existants, mais récemment mis sur le marché, grâce à des travaux de programmation informatique effectués par une personne compétente et adéquatement formée : C.W. Agencies Inc. v. Canada, 2002 DTC 6740, au paragraphe 18. Tout compte fait, d’après la preuve présentée, l’amélioration d’iFactum découle de mesures consistant à utiliser des produits existants et à corriger des lacunes du code ainsi que des incompatibilités entre iFactum et d’autres plateformes en utilisant des techniques de conception de logiciels habituelles. Ces produits et ces compétences ont été utilisés relativement à iFactum pour améliorer sa commerciabilité.
(3) Consignation pertinente insuffisante
[22] Par ailleurs, la preuve portant sur la question de savoir si les procédures scientifiques ont été respectées ne suffit tout simplement pas dans le cas des investigations, des expérimentations et des progrès technologiques pour lesquels la demande de déduction a été refusée. Ce fait a été démontré par la nécessité pour M. Sarmiento pendant l’audience de décrire l’incertitude technologique, les progrès technologiques ainsi que les travaux réalisés en ne faisant pas référence à quelque dossier technique pertinent, reconnaissable ou structuré établi par HPGI, mais en faisant plutôt référence de façon étendue et presque exclusive dans sa preuve principale au rapport d’analyse technique de l’ARC. Le rapport d’analyse technique était utile, car il mettait en valeur les commentaires de M. Sarmiento dans le cadre des entrevues pendant la phase de vérification et d’examen de l’ARC qui s’est notamment déroulée après les travaux. Il ne s’agit pas d’un substitut convenable à la tenue de dossiers contemporains. Rien qui s’apparente à de tels dossiers ou documents créés par HPGI au moment de la réalisation des travaux de RS et DE n’a été présenté devant la Cour. Bien que la preuve du résultat soit importante, pour les progrès technologiques, il est essentiel que le respect rigoureux de la méthode scientifique et technologique soit démontré de façon détaillée et simultanée pendant la réalisation des expérimentations. Puisqu’une réponse négative à l’hypothèse est un résultat plus fréquent et souvent tout aussi utile pour l’amélioration des connaissances technologiques, une consignation étape par étape, une analyse et une évaluation des données sont des exigences obligatoires, non un addenda facultatif. C’est une feuille de route. Si quelqu’un perd la marche à suivre et les données concernant les échecs, la reconstitution à l’aide de ces dossiers précis favorise un processus déductif permettant de choisir une orientation, une vitesse ou une méthode différente pour créer, situer, adapter et organiser [traduction] « la pièce manquante du casse-tête ». Le « seul moyen fiable de prouver que la recherche scientifique a été effectuée de façon systématique consiste à produire des preuves documentaires » : Zeuter Development, au paragraphe 28. Dans les faits, ce processus de consignation essentiel était absent en l’espèce.
VI. Résumé et dépens
[23] En résumé, il est possible qu’il y ait eu d’autres incertitudes technologiques et progrès technologiques dans le cadre d’autres volets de la phase 2 et de certains travaux de la phase 1. Toutefois, la nature précise des incertitudes technologiques, des hypothèses ou des expérimentations quant à la façon de surmonter ces obstacles et les connaissances acquises grâce aux travaux de recherche ne peuvent être déterminées à l’aide de la preuve de HPGI relativement aux travaux réalisés. Dans les faits, il y a eu une négligence et un non-respect manifestes des exigences en matière de procédure bien connues liés à la méthode scientifique ainsi que de la nécessité fondamentale de tenir des dossiers détaillés et actuels afin de documenter les incertitudes technologiques, les hypothèses, les expérimentations, les résultats et les réalisations.
[24] Comme l’appelante a choisi que l’appel soit régi par la procédure informelle pour les deux exercices, il n’y aura aucune ordonnance relative aux dépens.
Signé à Edmonton (Alberta), ce 8e jour de juin 2015.
« R.S. Bocock »
Juge Bocock
Traduction certifiée conforme
ce 14e jour d’août 2015.
M.-C. Gervais
Résumé du rapport d’analyse technique, du témoignage de l’appelante et des dossiers sur les progrès technologiques
[non souligné dans l’original]
|
Phase de la recherche |
Progrès technologique allégué |
Témoignage de l’appelante quant à la méthodologie utilisée/dossiers |
Position de l’intimée au sujet du progrès technologique |
|
STA1 Phase 1 |
Le projet a fait progresser la technologie sous-jacente en matière de conception de logiciel pour une application Web en rendant iFactum pleinement interexploitable avec une gamme complète de logiciels commerciaux et de plateformes matérielles. Cette percée en ce qui a trait à la souplesse du système a entraîné une évolutivité illimitée. Ces progrès technologiques généraux découlent d’un ensemble de progrès technologiques secondaires clés. |
Le fondement de l’expérimentation était de permettre à iFactum de fonctionner sur de multiples plateformes logicielles en utilisant un seul code uniforme. Les langages différaient entre Microsoft (C++) et d’autres (IBM, Oracle). L’objectif était d’utiliser le même code pour tous. Il a été décidé d’utiliser J# après l’expérimentation. Cette première étape permettait de déterminer le système d’exploitation. |
• Un examen de la documentation ponctuelle (« DP ») (journaux de bord hebdomadaires, billets de soutien technique) a permis de déterminer des techniques de programmation de l’industrie ainsi que des scénarios de détermination et de résolution de problèmes qu’un professionnel des technologies de l’information (TI) formé mettrait en œuvre dans des circonstances semblables. • La DP n’a pas fourni de preuve à l’appui d’une investigation ou d’une recherche systématique par voie d’expérimentation ou d’analyse fournissant de nouvelles connaissances scientifiques ou techniques ou favorisant un progrès technologique. |
|
STA2 Phase 2 |
Plus précisément, HPGI a fait progresser la technologie sous-jacente de la programmation d’applications Web en développant la méthodologie – compilation d’un programme Java sans classes Java propres à Windows ou Linux – pour remédier à l’incompatibilité de Java avec le serveur d’application Linux sans compromettre la compatibilité de Java avec Windows. |
Ils ont entrepris d’écrire 150 fonctions opérationnelles d’iFactum, converties manuellement dans J# (pour .NET et Java). |
• Cette tâche consistait à utiliser la technologie Java comme prévu. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Il existe de nombreux documents concernant le portage et la migration vers les langages C#, J#, C++ et Java accessibles au public, et il ne manque pas d’exemples de codes (il est possible d’en trouver dans : 1. des tutoriels de livres, 2. Internet et 3. MSDN). Il existe aussi des livres traitant du portage de C#/C++/J# vers/à partir de Java ou vice versa. • Un examen de la DP (journaux de bord hebdomadaires, billets de soutien technique) a permis de déterminer des techniques de programmation de l’industrie ainsi que des scénarios de détermination et de résolution de problèmes qu’un professionnel des technologies de l’information (TI) formé mettrait en œuvre dans des circonstances semblables. • La DP n’a pas fourni de preuve à l’appui d’une investigation ou d’une recherche systématique par voie d’expérimentation ou d’analyse fournissant de nouvelles connaissances scientifiques ou techniques ou favorisant un progrès technologique. |
|
STA3 Phase 1 |
L’équipe a aussi fait des progrès quant à la technologie sous-jacente en matière de logiciel d’application Web en rendant iFactum pleinement interexploitable avec le système d’exploitation (SE) Linux et la structure de son système de classement, incompatible avec son équivalent sur Windows. HPGI est parvenue à cette interopérabilité en programmant iFactum pour déterminer automatiquement le SE auquel le programme se connecte et en activant ensuite le système de classement interne correspondant. |
Après avoir déterminé le système d’exploitation hôte, le dossier est extrait au moyen du code uniforme d’iFactum nouvellement conçu créé en J#. |
• Il s’agit de techniques appropriées qu’un professionnel des TI utiliserait dans des circonstances semblables. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Il existe beaucoup de techniques bien connues pour déterminer le SE qu’utilise une application, par exemple, en cherchant un fichier .dll,.so (pour AIX, Sun Solaris), .a (pour Solaris) ou *SRVPGM en particulier dans un répertoire précis du système d’exploitation utilisé afin d’établir s’il existe ou non. • Fait référence à l’utilisation d’un code différent et personnalisé, non à un code uniforme ou universel. |
|
STA4 Phase 1 |
L’innovation, grâce à un processus automatique permettant de déterminer par voie électronique la plateforme utilisée ainsi que la base de données correspondante pour ensuite harmoniser le langage de définition de données (DDL) et le langage de manipulation de données (DML) de la base de données d’iFactum, a permis de faire progresser la technologie liée à la manipulation de bases de données et la programmation de logiciels pour les applications Web. Ce changement a aussi rendu iFactum universellement compatible avec les systèmes commerciaux de bases de données pour toutes sortes de plateformes ainsi que pour toutes les versions de celles-ci. |
Mettre à jour iFactum aux fins de compatibilité avec les différentes bases de données hôtes : serveur SQL, Oracle et DBZ et leurs codes DDL et DML uniques. |
• Il s’agit de techniques appropriées qu’un professionnel des TI utiliserait dans des circonstances semblables. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Ce STA est mieux compris en tant qu’exposé des faits opérationnels et de ce qui devait être réalisé (mise à jour d’iFactum pour qu’il soit compatible avec différentes bases de données (serveur SQL, Oracle et DB2) ainsi que leurs codes DDL et DML). |
|
STA5 Phase 1 |
Le fait de rendre iFactum interexploitable avec les PME (petites et moyennes entreprises) susmentionnées ainsi que les plateformes haut de gamme a fait progresser la technologie sous-jacente en matière de reprogrammation de logiciels et de reconfiguration pour les applications Web. |
Mettre à jour iFactum pour assurer la compatibilité et l’interopérabilité avec les plateformes d’IBM. |
• Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Ce STA est mieux compris en tant qu’exposé des faits opérationnels et de ce qui devait être réalisé (pouvoir utiliser iFactum avec des plateformes d’IBM précises). Aucune science ou technologie n’a été déterminée. • Un examen de la DP (journaux de bord hebdomadaires, billets de soutien technique) a permis de déterminer des techniques de programmation de l’industrie ainsi que des scénarios de détermination et de résolution de problèmes qu’un professionnel des technologies de l’information (TI) formé mettrait en œuvre dans des circonstances semblables. • La DP n’a pas fourni de preuve à l’appui d’une investigation ou d’une recherche systématique par voie d’expérimentation ou d’analyse fournissant de nouvelles connaissances scientifiques ou techniques ou favorisant un progrès technologique. |
|
STA6 Phase 1 |
HPGI a réalisé des progrès technologiques secondaires afférents aux systèmes de gestion du contenu Web en équipant iFactum de capacités d’extraction de données externes et en améliorant l’interaction avec l’utilisateur. Plus précisément, l’équipe a tiré profit du nouveau programme pour la création d’une base de données automatique comprenant des dépôts de données où les visiteurs du site Web peuvent inscrire de l’information sur une interface conviviale automatiquement transmise à la base de données d’iFactum. |
Mettre à jour iFactum pour permettre les rapports personnalisés d’autres bases de données hôtes : Oracle, DBZ, et serveur SQL. |
• Le cadre du code était le suivant : 1. lire le fichier de configuration d’iFactum pour établir si la base de données est locale ou éloignée et son type (Oracle, DB2 ou serveur SQL); 2. demander à l’utilisateur d’entrer son code d’utilisateur et son mot de passe (ce qui permettrait d’obtenir des autorisations pour des données particulières). Lire les métadonnées (afin de déterminer la disposition des fichiers) dans le but de récupérer des données; 3. les données (tables et champs) seraient présentées à l’utilisateur. Ce dernier choisirait ensuite les données appropriées (glisser-déplacer) pour la génération de rapport. • Il s’agit des techniques appropriées (création de code dans les limites du logiciel) qu’un professionnel des TI formé utiliserait dans les circonstances. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. |
|
STA1 Phase 2 |
Universaliser l’interopérabilité d’iFactum avec des applications commerciales et supposer de résoudre le problème en reprogrammant systématiquement iFactum pour se conformer aux services Web (SW) dans une AOS […] encodage de quelque 150 fonctions logicielles conformes aux services afin d’automatiser les processus d’affaires communiquant à l’aide d’applications commerciales axées sur Windows et Linux. |
Ce STA correspond à peu près à la phase 1 du STA2, mais pour les services Web plutôt que les services gérés par le système central : rendre 150 fonctions opérationnelles d’iFactum conformes aux services Web. |
• Il s’agit de techniques appropriées (restructuration/modification du code pour respecter les spécifications) qu’un professionnel des TI formé utiliserait dans les circonstances. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Ce STA est mieux compris à titre d’exposé des faits opérationnels et de ce qui devait être réalisé (rendre 150 fonctions opérationnelles d’iFactum conformes aux services Web). Aucune science ou technologie n’a été déterminée. Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques. |
|
STA2 Phase 2 |
Accordée par le ministre |
Accordée par le ministre |
Accordée par le ministre |
|
Pendant le processus, de nombreuses incertitudes technologiques à la base du codage différentiel des plateformes .NET et Java ont été résolues en testant individuellement et en modifiant les fonctions mentionnées précédemment dans le cadre de protocoles expérimentaux par étapes. Grâce à l’innovation expérimentale systématique, l’équipe a aussi remédié à des incertitudes complexes pour rectifier des problèmes de mappage des types de données. |
Il y avait une incompatibilité ne pouvant pas être résolue simplement à l’aide de produits existants et accessibles, entre le mappage des types de données de QueryBeans, .NET et Java, qui nécessitait des travaux de recherche afin d’élaborer un code permettant le partage de ces données entre les plateformes .NET et Java. |
Les travaux ont commencé le 18 février 2008 et ont pris fin le 6 avril 2008. D’après la DP et les discussions avec la demanderesse, les personnes suivantes ont réalisé des travaux liés à cette TA : • VS : 246 heures; rôle : supervision, expérimentation, programmation • « Personne B » : 153 heures; rôle : testeur/programmeur Problèmes de conformité et d’admissibilité : • Ces deux personnes, dont les heures travaillées connexes sont indiquées, ont réalisé des travaux de RS‑DE admissibles. Documentation justificative examinée : • Examen de l’historique des demandes de soutien technique et des carnets de bord (indiquant le nom des personnes et les heures réclamées). Les deux comprenaient des détails sur les travaux réalisés. |
|
|
STA3 Phase 2 |
HPGI a ensuite programmé, à titre expérimental, chaque fonction d’iFactum aux fins d’interopérabilité avec des plateformes haut de gamme auxquelles il est possible d’accéder à distance à partir du Centre d’innovation d’IBM. |
Rendre iFactum exploitable sur les plateformes Web d’IBM en modifiant ou en reconfigurant le code d’iFactum au moyen du type de données QueryBeans. |
• Il s’agit de techniques appropriées qu’un professionnel des TI utiliserait dans des circonstances semblables. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. • Ce STA est mieux compris à titre d’exposé des faits opérationnels et de ce qui devait être réalisé (rendre 150 fonctions opérationnelles d’iFactum exploitables sur les plateformes d’IBM). Aucune science ou technologie n’a été déterminée. Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques. • Un examen de la DP (journaux de bord hebdomadaires, billets de soutien technique) a permis de déterminer des techniques de programmation de l’industrie ainsi que des scénarios de détermination et de résolution de problèmes qu’un professionnel des TI formé mettrait en œuvre dans des circonstances semblables. • La DP n’a pas fourni de preuve à l’appui d’une investigation ou d’une recherche systématique par voie d’expérimentation ou d’analyse fournissant de nouvelles connaissances scientifiques ou techniques ou favorisant un progrès technologique. |
|
STA4 Phase 2 |
L’équipe de projet a ensuite modifié davantage le logiciel pour parfaire l’interopérabilité d’iFactum avec les produits SOA Foundation d’IBM. |
Obtenir la certification IBM d’iFactum indiquant sa conformité aux principes de la SOA en modifiant le code d’iFactum pour respecter les normes de la SOA afin de communiquer avec les applications de tierces parties, ce qui a été possible en utilisant des outils logiciels du serveur pour les entreprises et les activités commerciales d’IBM. |
• Il s’agit de techniques appropriées qu’un professionnel des TI utiliserait dans des circonstances semblables. • Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques dans le domaine des TI ou de l’informatique. La technologie (p. ex. J#, SOA (architecture)) est utilisée comme prévu. • Ce STA est mieux compris à titre d’exposé des faits opérationnels et de ce qui devait être réalisé (rendre iFactum conforme à la SOA (IBM)). Aucune science ou technologie n’a été déterminée. Il n’y a pas eu de nouvelles connaissances scientifiques ou technologiques. |
|
RÉFÉRENCE : |
|
|
No DU DOSSIER DE LA COUR : |
|
|
INTITULÉ : |
|
|
LIEU DE L’AUDIENCE : |
|
|
DATES DE L’AUDIENCE : |
|
|
MOTIFS DU JUGEMENT : |
|
|
DATE DU JUGEMENT : |
COMPARUTIONS :
|
M. Todd Louie et M. Ryan Wagman |
|
|
Avocat de l’intimée : |
Me Aaron Tallon |
AVOCATS INSCRITS AU DOSSIER :
|
Nom : |
|
|
Cabinet : |
|
|
Pour l’intimée : |
William F. Pentney Sous-procureur général du Canada Ottawa, Canada |