Comment prouver la RS&DE ? (2/2)

La documentation contemporaine des projets de RS&DE est le nouveau credo des CRT. Il faut des preuves documentaires que notre recherche a eu lieu sinon il n’y a pas de RS&DE admissible. Les témoignages verbaux ne suffisent plus Mais comment fait-on cela ?

Le jour où vous serez vérifié en RS&DE, vous devrez répondre à chacune des cinq questions définies ces dernières années par l’ARC pour déterminer l’admissibilité à la RS&DE. Dans un article récent nous avons proposé de regrouper vos preuves en fonction de ces cinq questions.

Nous présentons aujourd’hui les preuves des trois dernières questions.

« Il faut des preuves que notre recherche a eu lieu sinon il n’y a pas de RS&DE admissible »

Partagez ce Tweet SVP

3-     Preuve d’une investigation systématique

Une investigation systématique est une approche structurée qui implique de passer de l’identification des incertitudes scientifiques ou technologiques, à l’émission d’hypothèses, aux mises à l’essai par expérimentation ou analyse et à la formulation de conclusions logiques.

Dans un contexte d’affaire, ceci implique que :

• Les objectifs de la RS&DE sont clairement établis et écrits assez tôt dans le projet,
• Les méthodes et expérimentations tentées pour résoudre les incertitudes sont précisées,
• Les travaux sont être supervisés par du personnel avec une compétence technique appropriée.

Exemples

Pour démontrer un processus systématique, il est nécessaire de :

• Montrer l’expérimentation systématique et appuyer l’ampleur des coûts :
  • Combien d’expérimentations et d’alternatives ont été étudiées pour tenter de résoudre chaque incertitude,
  • Démontrer la méthode de travail :
    • Analyses (lesquelles, pourquoi, combien d’alternatives analysées ou simulées (théoriques), etc.),
    • Processus d’essais (quel environnement d’essai, quelle évolution d’un essai à l’autre, combien de courses d’essais du processus, quelles conclusions, etc.),
    • Conservez les preuves et résultats des essais non concluants,
    • Prototypes (combien de prototypes (physiques ou simulés), pourquoi chacun et quelle est la cause de leur rejet),
    • Prenez des photos des prototypes physiques avant de les détruire.
  • Résultats des analyses de performance (dans le temps et suite à l’évolution du processus),
  • Conclusions : comparer les résultats aux attentes et expliquer les variations,
  • Pour lesquelles des incertitudes croyez-vous pouvoir tirer une conclusion (donc identifier un avancement technologique) ?
• Lister en ordre chronologique les événements clé, activités, test et résultats pertinents à la résolution des incertitudes,
• Conserver les résultats obtenus et les conclusions qui en ont été tirées à l’époque,
• Produisez et conservez des compte-rendu de réunions de suivi technique incluant la date et les participants,
• Documenter toute nouvelle direction prise suite aux tests (itérations),
• Conserver des versions de plans de projet, de budgets, de plan d’utilisation des ressources, de plans de tests, et des explications qui les accompagnent,
• Noter les activités de support. L’utilisation de technologies bien étables et reconnues comme « de routine » est non éligible sauf si l’activité est réalisée en support à un projet de développement expérimental. Ça peut alors devenir éligible. Ne négligez donc pas les essais qui vous sembleraient inéligibles au départ,
• Conserver tout autre document technique pertinent.

4-     Preuves de l’avancement

L’avancement est défini ainsi par l’ARC la politique sur l’admissibilité des travaux : « la production de renseignements ou la découverte de connaissances qui font progresser notre compréhension des relations scientifiques ou de la technologie. (…) L’avancement technologique fait passer la base de connaissances scientifiques ou technologiques d’une société à un niveau supérieur par l’augmentation de la compréhension de la technologie. »

Exemples

Nous avons déjà illustré la documentation de la pratique courante et de l’écart technologique. Il faut :

• Définir la base de connaissances initiale,
• Préciser l’écart recherché par rapport à la technologie existante,
• Conserver les avis négatifs sur la faisabilité de notre approche technologique par des experts externes ou des fournisseurs de technologie,
• Documenter le « rejet d’une hypothèse car cela constitue un avancement puisque nous éliminons une solution possible »,
• Référer à une revue scientifique ou de l’industrie définissant l’état des capacités de la technologie à certains moments,
• Enregistrer les résultats (même négatifs),
• Noter les connaissances que l’on serait fier de présenter à nos confrères. Quel serait leur opinion au sujet du progrès atteint/recherché des connaissances ?
• Documenter périodiquement votre vision sur des sujets tels que :
  • La nouvelle connaissance ou technologie est-elle généralisable ? Où ?
  • Cette connaissance peut-elle être appliquée ailleurs que dans cette situation spécifique ?
  • Pour quelle raison technologique l’avancement n’a pas été recherché ou obtenu auparavant ?
  • Qu’est-ce que vous feriez différemment si le projet débutait aujourd’hui ?
  • Comparer vos résultats/technologies à des produits antérieurs ou concurrents

5-     Registre des hypothèses et des résultats

« Un registre des hypothèses, des essais et des résultats devrait être conservé au cours des travaux.  (…) les travaux [doivent être] consignés de façon à indiquer clairement la raison d’être de leurs principaux éléments et préciser comment ils s’inscrivent dans l’ensemble du projet. (…) Une investigation ou recherche systématique ne peut généralement pas être conduite sans consigner les travaux au fur et à mesure qu’ils progressent. Elle ne vise pas à suggérer un format particulier de documentation pour supporter la RS&DE. »

L’Annexe 2 du T4088 – Guide pour le formulaire T661 contient certains exemples de preuves suggérées par l’ARC. Mais il ne donne pas d’exemple de registre des hypothèses. Voici quelques suggestions pratiques :

Exemples

Pour chaque projet de RS&DE, une documentation doit être produite pendant que sont réalisées les activités afin d’assurer la consistance et l’intégrité du contenu. Le tableau suivant devrait être révisé et mis à jour deux à quatre fois par année :

• Identifier le projet (nom, numéros dans les systèmes de gestion et de feuilles de temps, etc.),
• Identifier le responsable,
• Produire un tableau du contenu technologique précisant, pour chaque incertitude et pour chaque hypothèse :
  • Mois de début/fin des activités,
  • Incertitude technologique et pratique courante associée,
  • Hypothèses formulées pour résoudre les incertitudes,
  • Résultats obtenus pour chaque hypothèse,
  • Avancements technologiques visés et obtenus, connaissance générée par ces travaux,
  • Ressources et efforts (heures) utilisés, incluant les consultants.

Conclusion

Ceci complète nos exemples de documentation pour supporter vos réclamations de crédits à la RS&DE. Les nouveaux CRT exigent maintenant une telle documentation contemporaine des projets de RS&DE. C’est devenu une condition d’acceptation. Il faut donc s’organiser pour produire, enrichir et conserver ces traces de vos projets pendant l’année afin de réduire les risques d’une décision malheureuse par ces CRT.

Et vous comment documentez-vous vos projets de RS&DE ? Avez-vous des trucs ou des embûches à partager ? Lesquelles de vos pratiques de documentation ont convaincu le CRT ?

Nous sommes honorés de constater le temps consacré à la lecture de notre page. L’index de notre blog (à droite de cette page) contient plusieurs autres solutions qui vous sont aussi destinées.

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

Comment prouver la RS&DE ? (1/2)

La documentation contemporaine des projets de RS&DE est le plus récent mot d’ordre des CRT. Il faut prouver par des preuves documentaires que notre recherche a eu lieu sinon il n’y a pas de RS&DE admissible. Les témoignages verbaux ne suffisent plus. Mais comment fait-on cela ?

Dans des articles récents nous avons présenté quelques façons de documenter vos projets de RS&DE. Nous avons présenté un processus peu coûteux, nous avons illustré comment s’organiser pour documenter et comment documenter l’écart à la pratique courante.

« Pour réduire les risques de vos réclamations vous devez obtenir les meilleures preuves de votre R&D. Il faut donc s’organiser pour produire, enrichir et conserver des traces solides pendant l’année »

Partagez ce Tweet SVP

Nous présentons ici une autre façon de regrouper vos preuves des activités de RS&DE. Ces dernières années, l’ARC a défini cinq questions pour déterminer l’admissibilité à la RS&DE. Il faut maintenant être prêt, en vérification, à répondre à chacune de ces questions et à démontrer nos arguments. Alors nous proposons ici de regrouper vos preuves en fonction de ces cinq questions.

Nous présentons aujourd’hui les preuves à apporter pour des deux premières questions. Nous conclurons avec les preuves des trois dernières questions dans un prochain blogue

Avant de débuter

Quelques mises en garde s’imposent avant de débuter :

• Contrairement aux affirmations de l’ARC, la documentation de processus expérimentaux n’est pas « naturelle » dans une entreprise commerciale.
• Documenter vos projets de RS&DE est une nouvelle discipline à implanter sur une base hebdomadaire ou mensuelle dans votre entreprise.
• Nommer un responsable technique de la documentation pour chaque projet réclamé devient un incontournable.
• Le papier n’est pas la seule documentation acceptable. Un fichier Word, Excel, Visio, Txt, un courriel, une photo ou un Wiki fera l’affaire, l’important c’est qu’il soit daté,
• Soyez créatif. Nous présentons ici un aide-mémoire, une source d’inspiration à partir de laquelle vous bâtirez votre banque de preuves, ne vous limitez pas à cette liste.
• Il faut dater tous vos documents.
• Enfin, il y a de nombreux recoupements entre les preuves présentées ici par question puisqu’on parle toujours du même projet vu sous l’angle des incertitudes et des expérimentations, qui permettent d’atteindre des avancements, etc.

Alors allons-y pour des exemples de preuves documentaires pour les deux premières questions :

1-     Preuves d’incertitudes :

Une incertitude existe « si la probabilité d’atteindre un objectif ou un résultat ou la façon d’y parvenir ne peuvent être déterminées d’après l’expérience ou les connaissances généralement disponibles. ».

Nous avons déjà discuté de comment documenter la pratique courante et le dépassement de la base de connaissance. Voici d’autres exemples de documentation des incertitudes :

Exemples

Les incertitudes sont rarement décrites formellement par le personnel affecté aux projets. Il faut donc créer l’habitude d’y faire référence durant le déroulement du projet.

• Dès le début du projet, préparer une liste (dans le certificat de naissance du projet, dont nous parlerons bientôt), des :
  • Principaux risques que l’objectif technologique ne soit pas atteint à l’intérieur des contraintes technologiques,
  • Problèmes anticipés et des solutions standards pour chacune,
  • Constater les besoins initiaux de mise à l’essai de technologies, d’élaborer un ou des prototypes,
  • Limites techniques et des alternatives connues, afin de les comparer plus tard avec la réalité du projet.
• Produire et mettre à jour des listes datée des :
  • Tentatives (par d’autres ou par vous) de résoudre le problème soulevé,
  • Alternatives conceptuelles envisagées pour résoudre l’incertitude,
  • Essais ou analyses sérieuses afin d’évaluer les alternatives,
  • Contraintes, des particularités ou des problèmes propres à votre environnement (taille, architecture, ressources, adaptabilité, etc.) qui vous empêchent d’utiliser les solutions existantes,
  • Spécifications contraignantes (performance, coûts, stabilité, fonctionnalité, compatibilité…).
• Identifier et documenter des contraintes conflictuelles (ex. : performance vs fiabilité)
• Documenter le fait que l’environnement est imprévisible c’est donc illustrer les interactions, les réactions ou les comportements de plusieurs composantes que l’on n’a pu déterminer à l’avance dans un système donné. Ceci peut mener à démontrer une incertitude systémique,
• Préciser le statut du projet et de la technologie en début et en fin d’année
  • Quelles incertitudes furent résolues durant l’année
  • Quelles incertitudes restent à résoudre
• Documenter les raisons de l’abandon de prototypes.

2-     Preuves des hypothèses

Une hypothèse est « destinée à résoudre l’incertitude scientifique ou technologique. Une hypothèse est une idée, conforme aux faits connus, qui sert de point de départ à une étude approfondie visant à prouver ou à réfuter cette idée. »

Il faut donc ici noter les idées, les options et alternatives que nous avons envisagées pour résoudre les différentes incertitudes. N’oubliez pas :

• De dater ces documents
• De préciser à quelle incertitude chaque hypothèse tente de répondre.
• D’identifier qui a effectué les travaux
• Les meilleurs endroits où consigner les hypothèses sont le certificat de naissance, les rapports périodiques et le journal de bord dont nous allons parler dans une autre page de ce blogue.

Exemples

Voici des exemples de documentation des hypothèses :

• Décrire l’approche initiale envisagée pour résoudre chacune des incertitudes
• Présenter les hypothèses alternatives envisagées (pas nécessairement testées, ni l’approche finale)
• Quels essais ou analyses sérieuses ont été entreprises pour évaluer les alternatives ?
• Rapport de test ou d’essai : Quels résultats et quelles conclusions en avons-nous tiré ?
• À quel moment (suite à quels résultats) l’hypothèse fut-elle rejetée ? ou démontrée ?
• Décrire ce qui a justifié le besoin initial d’élaborer un ou des prototypes ?
• Pourquoi a-t-on abandonné le prototype ?

Conclusion

En conclusion, la documentation contemporaine des projets de RS&DE est maintenant une condition d’acceptation selon les CRT. Il faut donc s’organiser pour produire, enrichir et conserver ces traces de vos projets pendant l’année afin de réduire les risques d’une décision malheureuse par les CRT.

Nous sommes honorés de constater votre temps consacré à la lecture de notre page. L’index de notre blog (à droite de cette page) contient plusieurs autres solutions qui vous sont aussi destinées. Vous avez aimé votre lecture ? Dites-le nous. 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 identifier et mesurer l’écart à la technologie

L’Agence de Revenu du Canada (ARC) est de plus en plus exigeante en matière de documentation des activités de RS&DE. Il ne suffit plus de définir l’incertitude technologique et l’écart à la pratique courante. L’ARC requiert maintenant de mesurer cet écart.

Il n’y a pas toujours d’outil ou de mesure toute prête à montrer au conseiller de l’ARC (CRT). Cela découle de la nature même des travaux de RS&DE. Nous tentons de repousser des limites, souvent peu définies ou explorées. Nous devons donc utiliser notre créativité pour créer nos instruments de mesure.

« Il n’y a pas de limite aux coupures de crédits que Revenu Canada peut appliquer à un projet de R&D mal défini, documenté et mesuré »

Partagez ce Tweet SVP

Ne vous concentrez pas uniquement sur l’incertitude du produit. Regardez plutôt ce qui limite vos objectifs technologiques, les méthodes et technologies requises pour résoudre ces incertitudes. Pensez comment mesurer l’écart entre ces incertitudes et la pratique courante.

Aucune méthode n’est universelle. Et ce n’est pas un article de trois pages qui va établir LA méthode. Nous sommes-là, bien sûr, pour vous aider. Mais il y a tout de même un minimum à respecter pour satisfaire les exigences de l’ARC. Voici, à titre d’exemple, quelques suggestions pour mieux identifier et mesurer l’écart à la technologie courante et la progression de vos travaux :

1- Définir adéquatement la technologie.

Commençons d’abord par les technologies en cause. Il est très facile de mal définir la technologie, ceci peut nous empêcher de définir notre véritable incertitude, ce que l’on cherche à y ajouter. Par exemple, si je définis ma technologie comme le système de gestion de base de données, ou le système de pompe hydraulique, le CRT peut facilement avancer que ce système existe depuis longtemps et qu’il n’y a pas de défi technologique à concevoir une nouvelle pompe.

Soyons donc plus spécifique : quelle cible mesurée veut-on atteindre ou dépasser ? Par exemple dans la gestion de la base de données, nous nous intéressons aux moyens de rendre plus performantes de 25% les information peu ou pas structurées de type « blob ». Nous devons donc mesurer notre cible avant, pendant et après notre processus expérimental et sous plusieurs angles pertinents pour notre expérience (vitesse, nombre d’enregistrements à la seconde, taux de succès des transactions, quantité de données perdues, etc.).

Même chose pour la pompe, au lieu de considérer toute la pompe, concentrez-vous, par exemple, sur la composante à l’étude, celle qui limite les résultats attendus. Par exemple, cela peut être la filtration, ou le maintien de la pression.

« Soyez créatif quand vos mesurez l’inconnu lorsque vous réclamez des crédits d’impôt R&D »

Partagez ce Tweet SVP

2- Évaluer la connaissance existante au départ

Il faut ensuite nous relier au reste de la planète. Sommes-nous les seuls ou les premiers à constater ces limites ou à tenter de les dépasser ? Quelles sont les approches connues ou étudiées, de quelle façon résout-on couramment la ou les limites rencontrées ?

Exemple : Lister, analyser sommairement et compter le nombre de :

• Recherches sur ce sujet sur Google,
• Articles pertinents,
• Recherches de brevets sur le sujet,
• Méthodes alternatives formulées ailleurs,
• Technologies similaires à nos besoins et leurs limites,
• Composantes ou solutions avec potentiel à explorer,
• Analyses ou questionnement d’experts externes ou de fournisseurs de technologies,
• Études universitaires,
• Etc.

3- Préciser les limites pertinentes de la technologie ou de la connaissance.

Lorsqu’on a bien situé la technologie cible, il faut préciser pourquoi cette partie de la technologie nous intéresse. Ceci nous ramène alors à bien préciser les limites technologiques que nous voulons dépasser. Cette technologie a certaines propriétés, permet certaines transformations, etc., mais elle a aussi ses limites, qui peuvent être traduites en unités mesurables telles un nombre maximal de transactions par seconde, ou une pression par centimètre carré, etc.

En passant, lorsque c’est défini ainsi, cette incertitude peut nous amener à renommer le projet et ses défis en fonction des objectifs technologiques ou des méthodologies plutôt que des incertitudes du produit.

4- Quantification des objectifs Vs pratique courante

De plus, l’ARC exige que nos objectifs technologiques soient quantifiés et clairement cités assez tôt dans le projet. Partout où cela est possible, il faut donc mesurer nos technologies au départ et nos objectifs de performance. Comparons-les dans le temps à des standards de performance existants ou à des nouveaux que nous allons formuler. Gardons-en des traces.

Exemple : Objectifs de performance 1 : XXXXX

• Date
• Cible
• Unités de mesure
• Conditions dans lesquelles le test fut réalisé
• Performance mesurée
• Constat, variable incertaine 1,
• Constat, variable incertaine 2, etc.
• Résultats, commentaires et conclusions

5- Relier les étapes de la recherche à des incertitudes spécifiques et mesurer le progrès

Enfin, parallèlement à ces exemples nous définissons un processus de développement expérimental, ses activités essentielles, et ses étapes. Nous identifions clairement où l’on tente de résoudre les incertitudes et quelles hypothèses alternatives sont analysées. Nous définissons alors des critères pertinents et nous les mesurons. L’existence de telles mesures différencie clairement les travaux expérimentaux de RS&DE du travail routinier.

Conclusion

En conclusion, il n’y a pas de limite à votre créativité pour définir des méthodes originales de mesure de vos progrès technologiques. De même, il n’y a pas de limite aux coupures que l’ARC peut appliquer à un projet expérimental qui n’est pas assez bien défini, documenté et supporté par des mesures adéquates. C’est votre choix.

Et vous, qu’en pensez-vous ? Avez-vous des trucs ou des idées à partager à ce sujet ?

Vous avez aimé votre lecture ? Dites-le nous. Que devrait-on y ajouter ?

Vous n’avez pas aimé votre lecture ? Dites-le nous. Que devrait-on corriger ?

Quels sujets vous intéressent ?