Comment reconnaître travaux de routine et pratique courante ?

Lorsqu’on réclame un crédit d’impôt à la RS&DE, il faut démontrer que nous avons fait plus que la pratique courante. Cette démonstration n’est pas évidente. Nous avons déjà illustré une façon d’identifier et de mesurer l’écart à la technologie. Nous discuterons encore de la méthode pour faire cette démonstration dans un prochain blogue.

Lorsqu’on prépare un dossier de RS&DE nous décrivons le projet et ses activités. Nous croyons fermement y voir un processus systématique qui satisfait les cinq questions. Tout en reste là jusqu’au jour où le conseiller en rechercher et technologie (CRT) de l’Agence du Revenu du Canada (ARC) jette un regard sur votre réclamation.

Et alors, IL EST SOUVENT TROP TARD.

Vous aimez les histoires d’horreur ? Laissez-moi vous raconter des situations que tous les praticiens moindrement expérimentés en RS&DE ont rencontré plusieurs fois dans leur carrière :

1-   Une histoire d’horreur

Un client obtient tous ses crédits pour toutes ses réclamations pendant plusieurs années incluant une vérification sans coupure ni commentaire du CRT.

Un nouveau CRT est assigné au dossier cette année et toute la réclamation est rejetée. Pourquoi?   Le nouveau CRT répond « c’est du développement de routine, vous n’avez pas dépassé la pratique courante. »  Comment a-t-il pu en arriver là? Plusieurs raisonnements peuvent mener à cette conclusion. Le CRT poursuit alors avec l’une des affirmations suivantes :

Experience

« Vous faites ce genre de développement depuis dix ou vingt ans. Alors vous connaissez ces technologies. Il n’y a plus d’incertitudes ».

Est-ce à dire que si la compagnie ne faisait ces développements que depuis, disons un ou deux ans, alors on reconnaîtrait l’existence d’incertitudes parce que cette jeune société n’aurait pas bâti une pareille base d’expertise et de connaissances ? J’ai déjà entendu un CRT répondre « oui » à cette question !…

Google

« On trouve cette technologie par une simple recherche dans Google, c’est donc de la pratique courante dans le domaine technologique. »

De nos jours plusieurs technologies changent très rapidement et il existe de nombreux forums et sites d’aide et de partage pour discuter des problèmes et de leurs solutions. Si l’on applique cet argument au pied de la lettre alors il n’y a presque plus de recherche expérimentale possible car les développeurs s’investissent rarement dans des recherches obscures et très risquées sans chercher/trouver des appuis existants.

Dépannage

« Les activités décrites ne dépassent pas le niveau du dépannage technologique et sont, par conséquence, des activités de routine ».

L’objectif du dépannage est de résoudre des problèmes techniques, d’optimiser des procédés ou d’ajuster les performances d’équipements. Il ne s’agit pas de faire avancer la connaissance.

Domaine sans progrès

« Tout a été établi dans le domaine (du génie mécanique par exemple), les lois, les principes et les normes sont établis. Tout ce qu’il est possible, aujourd’hui, c’est de combiner des connaissances déjà définies pour obtenir des résultats prévisibles. Tous les travaux dans ce domaine sont donc de la pratique courante » !!!

C’est alors qu’on entend une mâchoire tomber au sol…

… Et que débute une longue et pénible bataille pour faire renverser cette stupide décision.

2-   Comment répondre à cette affirmation ?

Disons-le tout de suite. Ce ne sera pas facile de convaincre un CRT (et son gestionnaire) de changer d’opinion. Explorons ensemble quelques pistes de solution :

• La première étape consiste souvent à convaincre le CRT de cesser d’utiliser un terme aussi ambigu que « routine » ou « courante ». Peut-il préciser d’où provient la base de connaissance pertinente et ce qu’elle contient plus en détails ?
• S’il utilise l’argument fondé sur l’expérience des développeurs ou de la compagnie, c’est alors un cas classique de confusion entre rencontrer quelqu’un de compétent et ne pas voir (comprendre) l’incertitude vue dans l’œil de l’expert. Avec l’expérience l’expert développe une meilleure habileté à saisir les éléments essentiels d’un problème. La présence d’une incertitude n’est donc pas nécessairement accompagnée d’un manque de confiance pour la résoudre comme on peut le voir chez les développeurs moins expérimentés. L’incertitude naît à un plus haut niveau dans l’esprit de l’expert.
• Certains CRT acceptent l’idée que de changer l’approche de conception d’une expérience (ou de créer un concept alternatif) indique un défi qui n’est pas évident. En particulier, les détails d’un essai ne sont peut-être pas suffisants en soi, mais c’est le cumul de plusieurs essais qui peut converger et faire germer l’idée d’une solution nouvelle et possible.

Dépasser les limites

• La clé pour répondre à la question de la pratique courante est parfois de rappeler les avancements recherchés. L’incertitude peut être établie et démontrée si :
  • l’on peut identifier un élément inconnu que nous avons dû découvrir par expérimentation systématique,
  • l’on peut démontrer que la recherche vise à dépasser les limites actuelles de la technologie.

Ceci est vrai à moins, bien sûr, qu’il n’existe pas une séquence définie d’étapes qui amènent au résultat recherché à coup sûr.

• Les travaux de routine incluent des défis de développement qui peuvent parfois être résolus par une collaboration générale avec d’autres praticiens. Par exemple, si les développeurs rencontrent des problèmes et qu’ils peuvent les résoudre simplement en échangeant en ligne ou avec leurs collègues. Si cette simple interaction mène à la résolution du problème, c’est de la routine. C’est aussi de la routine si le développeur est capable de reproduire ce qu’il trouve sur l’Internet et de l’introduire directement dans sa solution.
• Cela ne devient expérimental que si le développeur sent qu’il y a un risque lié à la solution, et s’il a dû améliorer ou renforcer ce qu’il a trouvé par une nouvelle approche. C’est aussi expérimental si l’on conclut que le travail réalisé est tout à fait nouveau et n’est pas supporté par ce que l’on trouve en ligne.
• Dans tous les cas, l’existence d’une ou de plusieurs preuves documentées sera extrêmement utile dans le débat.

Recommandation

Évitez toute mention de dépannage (ou “trouble-shooting” ou “déboggage”). Le dépannage est une activité de routine ayant pour but de corriger des équipements, logiciels ou procédés. Il s’agit très souvent d’une détection de défauts sans tenter de résoudre les incertitudes dans la technologie sous-jacente. Ceci n’est donc pas de la RS&DE. Ceci dit, le dépannage peut faire ressortir le besoin de faire de la RS&DE. Il est aussi possible que des activités de dépannage soient requises dans le cadre d’activités éligibles d’un projet de RS&DE.

3 Conclusion :

Donc la « pratique courante » et les « travaux de routine » sont  deux concepts fourre-tout utilisés couramment par des CRT pour couper des projets ou des activités.

La réponse à ces mots creux c’est d’EXIGER du CRT de le prouver. Qu’il vous fournisse une définition détaillée et documentée de ce qui constitue de la pratique courante ou des activités de routine dans le domaine technologique du contribuable selon le CRT. Quelle est la source de cette affirmation?

Toute réponse à cet argument doit donc passer par la démonstration que les travaux réalisés le furent pour résoudre une incertitude et dans le but de faire progresser notre connaissance de la technologie.

Par contre, il faut admettre que ce genre d’argument est difficile à gagner si on discute avec celui qui est à la fois juge et partie. De plus, il est plus facile d’affirmer qu’il s’agit de pratique courante que de démontrer le contraire, surtout si ce débat a lieu un ou deux ans après les faits.

Concluons par cette analogie : Avec l’évolution technologique accélérée actuelle, plusieurs développeurs construisent de nouvelles saveurs de gâteaux, mais très peu d’entre eux se risquent à créer de nouveaux types de pâtisseries. Selon l’esprit de la loi les « saveurs » devraient se qualifier, mais certaines interprétations tendent à hausser la barre au niveau des « types ».

Merci

Nous sommes honorés de votre visite sur notre blogue. R&D Action vous en remercie.

À droite de cette page l’index contient plusieurs autres catégories de solutions pratiques et applicables qui vous sont aussi destinées.

Vous avez aimé votre lecture ? Dites-le nous. Partagez-la. Que devrait-on y ajouter ? Quels sujets vous intéressent ?

Vous n’avez pas aimé cette lecture ? Dites-le nous. Qu’avez-vous moins apprécié dans ce texte ? Comment peut-on mieux répondre à vos besoins ?