Documenter maintenant votre RS&DE

Pour réclamer des crédits d’impôt pour un projet de RS&DE, l’Agence du Revenu du Canada (ARC) exige maintenant une documentation contemporaine des activités réclamées. On fait cela comment  documenter la RS&DE?

Documenter COMMENT ?

Il faut une nouvelle discipline d’entreprise, un nouveau système pour documenter régulièrement car personne ne se souviendra en détail de ce qui s’est passé il y a 12 ou 18 mois. Lorsque vous partez un nouveau projet de développement pensez tout de suite à le documenter. Comment allez-vous mesurer les travaux réalisés? Vous trouverez ensuite des façons d’intégrer ces mesures dans vos façons de faire. Par exemple :

• Marquez ces activités dans votre logiciel de gestion de projets ou de feuilles de temps
• Sauvegardez les informations dans un répertoire distinct pour la RS&DE
• Sauvegardez les courriels important en format PDF
• Créer une fiche rouge marquée R&D sur votre bureau où vous jetez vos notes manuscrites datées, les copies papier tirées des sites web, des blogs et autres sites visités pour comprendre et évaluer la technologie, les outils, les solutions alternatives, etc.
• Créez des certificats de naissance et produisez des documents de suivi de l’avancement de vos projets pouvant être réclamés en RS&DE
• Débutez un journal de bord pour consigner l’évolution de chaque projet
• Suivez les dépenses
• Utilisez des outils simples de communication et de documentation collaboratifs, tel un Wiki, ou des enregistrements vocaux pour bâtir votre « collage » virtuel, sur le réseau ou même sur le Web, et pour :
  • Centraliser les informations justificatives
  • Débuter la rédaction préliminaire de vos projets techniques.
  • Motiver certains de vos ressources plus portées par le format électronique, souvent plus efficace.

Documenter QUOI ?

Révisez les informations rassemblées deux ou trois fois au moins durant l’année, pour vous assurer que les informations sont complètes, datées et reliées aux principaux événements du projet.

Concepts

Documentez les discussions initiales sur les concepts et des documents initiaux expliquant les besoins – pourquoi vous ressentiez le besoin d’expérimenter les améliorations techniques au départ. Des photos, des vidéos, des prototypes ou des codes RATÉS peuvent valoir leur pesant d’or pour démontrer les changements et les améliorations notables au design expérimental. Si vous pouvez démontrer les besoins de haut niveau, vous allez typiquement trouver que la plupart des entreprises génèrent beaucoup de documentation détaillée – le truc c’est de retracer la preuve des « résultats inutiles d’échec détaillé » avant qu’ils ne soient jetés.

Enjeux

De même les enjeux de haut niveau sont souvent les plus difficiles à documenter – l’enjeu est souvent situé entre une tentative d’apprentissage ou une mise au point de type « essai et erreur ». Parlez à vos concepteurs et analystes, faites-leur décrire leur approche conceptuelle et les dates correspondantes où elles étaient toujours considérées.

Typiquement, lorsqu’il manque quelque chose envoyez un courriel en demandant une confirmation sommaire (ex. une liste à puces plutôt qu’un texte) des alternatives conceptuelles considérées dans les premières phases du développement. De même, vous pouvez enregistrer une entrevue où l’on vous décrira le détail des situations ou des concepts complexes. Les spécifications techniques quantifiés des cibles spécifiques qui étaient connues ou pas sont importantes pour définir et démontrer les problèmes technologiques.

L’apprentissage apparaît dans la complexité des détails racontés par les personnes qui ont fait le travail – les gestionnaires sont souvent trop loin des problèmes et ils sur-simplifient parfois les difficultés, par exemple pour faciliter la discussion. Ceci peut rendre la réclamation très difficile à défendre. Allez à la source, parlez à ceux qui font le travail détaillé trouvez quelles étaient leurs options et ce qu’ils recherchaient. Construisez-vous une vision globale et rapprochée à la fois. Les citations trop générales manquent de crédibilité. Obtenez des conclusions spécifiques, quantifiées ou qualifiée.

Réflexions

Documenter votre processus de réflexion (thought process) avant l’expérimentation.

Ceci est critique car si le problème ne peut pas être défini avant l’expérimentation, alors le coût pourrait être refusé. Votre besoin d’expérimenter peut-être dû à un manque de temps ou de ressources. L’approche expérimentale est peut-être la meilleure méthode pour la situation quoique pas la seule. Cependant, assurez-vous de tirer de bonnes conclusions après l’expérimentation. Par exemple, si vous ne recommenceriez pas ce design de l’expérimentation, c’est peut-être un apprentissage très significatif. Mettre l’emphase sur l’évolution du design de l’expérimentation peut être exceptionnellement puissant.

Objectifs

Liens avec vos objectifs.

De même, si vous ne pouvez montrer de changement dans l’approche ou dans la direction, il se peut que vous ne soyez qu’en train de faire une mise au point d’une technique connue. Alors assurez-vous de conserver les liens à l’objectif initial dans la documentation. La « mise au point » est peut-être une étape nécessaire plutôt que le véritable « apprentissage » à venir dans le futur. Ainsi, présenter l’évolution de la conception de l’expérimentation est souvent une perspective critique et essentielle pour certaines situations en démarrage.

Et vous comment documentez-vous vos projets de RS&DE ? Avez-vous des trucs à partager ? Comment vous assurez-vous que les bonnes informations sont conservées tout au long de l’année ?

Comment documentez-vous pendant le déroulement de vos projets de RS&DE ? Avez-vous des trucs ? des façons de faire ou des idées à partager à ce sujet ? Comment l’ARC a-t-elle réagi à vos mécanismes de documentation ?

R&D Action vous remercie de votre visite sur notre blogue sur les crédits d’impôt.

R&D Action c’est le choix de l’expérience et de l’expertise en crédits d’impôt.

Plusieurs autres catégories de solutions pratiques et applicables sont disponibles à droite de cette page, dans l’index.

Essayez-les.  Elles sont pour vous.

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 ?

Non au logiciel de documentation de la RS&DE

En plus de 25 ans dans le métier je n’ai jamais vu un logiciel de support à la documentation RS&DE qui portait bien ce nom. Plusieurs compétiteurs ont proposé ou offrent encore un logiciel pour documenter les activités et surtout les coûts de la RS&DE. C’est, bien sûr, un concept attirant car cela pourrait répondre aux exigences des conseillers en recherche et technologie (CRT) de l’ARC. Mais cela ne fonctionne pas. Cela ne fonctionnera jamais et voici pourquoi.

« Acheter un logiciel pour documenter la RS&DE ne résout aucun problème« 

Partagez ce Tweet SVP

Vendre du rêve – ou de la fausse sécurité

Bien sûr, les concepteurs du logiciel ont travaillé très fort pour le développer. Ils y ont mis beaucoup de bonnes idées. Ils méritent nos encouragements. Ah oui ? Je n’ai JAMAIS vu un tel logiciel encore pleinement en fonction après plus d’une seule année chez un client. Jamais. Et à ceux qui me répondent que leur implantation est plus ancienne que cela je réponds, ah oui ? Quelles fonctions sont encore utilisées? Le cumul des coûts ? Quel est le moteur de motivation active de cette implantation ? Le logiciel lui-même ou l’effort que le consultant injecte à chaque mois ou trimestre ? Ce logiciel est-il implanté dans TOUTES vos équipes de développeurs ? Et vous avez réduit l’effort de rédaction de fin d’année de combien ? 10% ?

Garbage in – garbage out

Les vendeurs de logiciels de documentation RS&ED ont tous à peu près les mêmes arguments :

• C’est automatique
• Ça réduit les efforts de rédaction en fin d’année
• Ça oblige à une discipline
• Ce sera plus acceptable aux yeux des CRT

Ce sont de bons arguments de vente, mais la réalité est toute autre :

• Garbage in – garbage out (poubelles à l’entrée – cochonneries à la sortie): après quelques semaines d’utilisation sans la présence du consultant qui a vendu le logiciel, nous constatons :
  • une tendance à limiter les efforts de documentation.
  • de plus en plus de copier-coller d’une semaine à l’autre.
  • peu ou pas de mise à jour de la structure du projet expérimental.
  • multiplication de mots dangereux (essais et erreur, débogage, documentation client, etc.) ou de phrases fourre-tout sans signification pour documenter la recherche.
• Trop c’est comme pas assez. Je me souviens encore d’un client qui s’est présenté à une rencontre de vérification avec au moins 60 cm de papier imprimé à partir de son logiciel. C’était plein de répétitions, de phrases sans signification… et le CRT a refusé d’y jeter un coup d’œil ! Inutile !

Ce qui est essentiel c’est le suivi serré pour obtenir l’information de qualité, pas le prix du logiciel.

• Suivi, Suivi, Suivi. Malgré toute la bonne volonté de la direction, du consultant et même des principaux utilisateurs, la nature humaine reprend vite le dessus s’il n’y a pas un suivi très serré du consultant. Le suivi doit couvrir non seulement l’existence de nouvelle documentation, mais aussi, et surtout, la pertinence des traces conservées. Sans suivi serré, la validité régresse après quelques semaines, trois ou quatre mois tout au plus. Et on ne s’en rendra compte qu’en fin d’année en tentant de rédiger la description.
• Certains croient acheter la solution à leur problème. Un logiciel, aussi extraordinaire soit-il, n’est JAMAIS la solution. Ce n’est qu’un outil. La solution c’est qu’on effectue un suivi serré des données entrées à chaque semaine. Sinon vous accumulez des déchets et vous gaspillez le précieux temps de vos développeurs.
• Flexibilité face à l’inconnu. Le cœur du problème avec les logiciels de documentation c’est que ces outils demandent de pré-définir les objectifs, les avancements (AT) et les incertitudes (IT) technologiques. Comment pré-définir les AT et IT si c’est un véritable projet de développement expérimental? Nous ne pouvons savoir à l’avance où nous rencontrerons des problèmes, combien et quelles hypothèses seront testées et démontrées, quelles nouvelles avenues nous allons explorer. La flexibilité du logiciel est donc un problème important. Il est facile de créer un gabarit initial qui structure un avancement, auquel se rattachent 1 à n incertitudes et pour chaque incertitude il y a 1 à m hypothèses, etc. Mais un projet expérimental ne progresse pas toujours de façon linéaire dans une arborescence. La structure de ces logiciels est souvent trop lourde ou complexe pour ajouter simplement de nouvelles avenues explorées. Un expert du logiciel doit créer de nouvelles branches dans le processus expérimental sinon les usagers ne le feront pas, ils vont inscrire n’importe quoi n’importe où et l’information collectée deviendra vite inutilisable.

Acheter un logiciel pour documenter la RS&DE ne résout aucun problème

Une solution simple qui fonctionne

Au lieu d’acheter de la technologie inutile, achetez donc un bon cahier de laboratoire, un cahier de projet, appelez-le comme vous voulez. Un simple cahier permet toutes les insertions, les références et les notes que l’on veut et ça ne coûte pas 10$. En le jumelant avec un répertoire « R&D », vous pouvez y ajoutez copie des plans de projet et des rapports de suivi – avec vos notations manuelles…

Vous voulez quand même de la technologie ? Word et Excel ne vous suffisent pas ? Implantez un Wiki. Cette catégorie d’outil de partage d’information peut évoluer facilement.

Chez certains clients, nous avons acheté des agendas format lettre en spécifiant qu’ils doivent rester sur les bureaux, qu’ils peuvent être utilisés pour leurs besoins personnels mais surtout pour noter à chaque jour (avec les dates) sur quoi ils travaillent et combien d’heures ils y ont consacré. Souvent une phrase suffit à rappeler tout le contexte. Et la ventilation R&D/Non R&D sera facile à reproduire dans la feuille de temps. On peut y ajouter les noms et liens aux documents de support ou aux résultats de tests qui ont été produits. À la fin de l’année vous ramassez ces agendas. Vous les ressortez avec les documents Word ou Excel pour rédiger les descriptions ou lors de la préparation d’une vérification.

Évidemment, le suivi serré reste essentiel pour obtenir de l’information de qualité, mais au moins vous n’aurez pas à justifier les $ 5,000 pour l’utilisation d’un lourd logiciel inutile.

Comprenons-nous bien. Je suis impliqué dans la technologie depuis 40 ans. Je crois à la technologie. Mais je n’ai encore jamais vu une technologie qui auto documente les activités de RS&DE. Une technologie assez flexible pour s’adapter à plusieurs contextes.

Conclusion : Éloge du simple cahier de projet

La bonne approche c’est la simplicité. La documentation sans artifice logiciel nous donne la flexibilité et la qualité. Tout est une question de volonté, d’organisation et de suivi, pas de code informatique. À partir de là, cela devient une question de prendre l’habitude de documenter souvent.

Mandatez votre consultant pour suivre votre équipe, pour encadrer votre documentation. À part vous, il est celui qui est vraiment très intéressé à maximiser vos crédits. Le résultat écrit de la main de vos experts sera 100 fois plus convainquant pour le CRT, et il y verra, en prime, des diagrammes (à la main), des résultats de tests Bref il verra la preuve que vous gérer votre projet de RS&DE comme un projet de recherche systématique.

Nous sommes honorés de votre visite sur notre blogue.

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

Servez-vous.

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 peut-on mieux répondre à vos besoins ?

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 ?

RS&DE – Comment documenter l’incertitude et l’écart à la technologie ?

La documentation des projets et des activités réclamées à titre de RS&DE prend de plus en plus d’importance dans le processus de réclamation de ces crédits. Nous examinons ici pourquoi il est difficile de documenter l’incertitude technologique, surtout dans le contexte de développement expérimental (DE). Nous proposons une méthode simple pour documenter la pratique courante et « l’écart à la technologie » qui fera mieux ressortir cette incertitude.

1-     Pourquoi il est difficile de documenter l’incertitude technologique

Ces dernières années, l’ARC a insisté sur l’importance de la documentation au point de presque en faire un nouveau critère d’éligibilité. Ces jours-ci beaucoup de demandes écrites d’information complémentaire par l’ARC incluent une demande d’exemples de la documentation du projet. On en est rendu au point où la question de la documentation est l’un des principaux obstacles à l’obtention de crédits à la RS & DE.

« L’ARC devrait préciser la documentation « standard » nécessaire et suffisante pour une demande de RS & DE »

Partagez ce Tweet SVP

1.1 Pas de directive claire

À première vue, cette exigence peut sembler difficile à mettre par écrit. Et pourtant cette question pourrait être résolue à l’avantage de tout le monde si l’ARC émettait tout simplement une sorte de « standard » qui montrerait aux vérificateurs et aux contribuables ce qui est nécessaire pour appuyer une demande de RS & DE.

Bien sûr, il y a l’annexe 2 du « Guide pour compléter le formulaire T661 – T4088 ». Mais ce ne sont que des exemples. L’ARC n’y précise pas ce qui est requis, nécessaire et suffisant.

1.2 L’effet de ne pas définir clairement les exigences

L’ARC n’a pas fourni de directives écrites plus précises sur ses exigences de documentation. Ceci fait en sorte que les CRT peuvent toujours indiquer un « manque de documentation » ou « dossier insuffisant pour détailler le travail réclamé » comme motif pour refuser une demande. Comme il n’y a pas de norme écrite ou de test clair pour définir ce qui est nécessaire, il est presque impossible pour un contribuable de contester une telle décision.

Justifier une évaluation négative de RS & DE par l’expression « documentation insuffisante » est très facile et rentable pour l’ARC. C’est certainement beaucoup plus efficace que d’exiger du CRT une explication rationnelle et documentée du pourquoi il juge qu’il n’y a pas d’incertitude technologique ou de progrès technologique.

2-     Le cas du développement expérimental (DE)

Documenter en entreprise est bien plus problématique encore, parce que la plupart des entreprises réclamant de la RS&DE réclament en fait du développement expérimental (DE). L’objectif initial de ces projets est normalement de créer un « produit ou un procédé nouveau ou amélioré » mais pas de créer de la connaissance. Ce problème est compliqué par le fait qu’il existe deux types de documents requis :

2.1 Des enregistrements comptables et de temps :

Cette exigence est assez facile à satisfaire et la plupart des entreprises peuvent mettre en place un procédé simple pour s’y conformer.

• Vous devez prouver qui travaille quand sur ce projet, vous le faites avec des :
  • feuilles de temps,
  • contrats et des factures de sous-traitants,
  • rapports fréquents, et
  • d’autres documents de l’époque.
• Vous vous assurez que les heures travaillées sont suivies par projet, par activité et par employé. Il faut aussi une explication claire de la fin du projet appuyé par des faits.
• Vous utilisez une chronologie formelle et / ou un diagramme de Gantt.

2.2 Des documents techniques

Ces documents doivent corroborer que les activités réclamées comme RS & DE ont été réellement réalisées et dans la période de la réclamation.

La documentation du développement d’un nouveau produit est normalement axée sur le progrès du projet et sur la satisfaction des exigences et spécifications des clients. Mais ce n’est pas le langage ni ce que recherche le CRT de l’ARC.

Il est donc essentiel de produire une documentation spécifique au projet de RS&DE. Elle sera concentrée sur trois exigences de base de l’ARC rarement documentées dans un projet de développement d’un produit :

• La pratique courante pour cette technologie dans cette industrie a été définie et mesurée par rapport à au moins une référence,
• Il faut démontrer que l’on va au-delà d’ingénierie de routine et de la pratique courante. Pour ce faire, il s’agit de définir et de démontrer l’écart entre
  • ce que l’on souhaite réaliser, et
  • ce qui ne peut PAS être fait en utilisant la technologie existante et les connaissances de la pratique courante,
• Il faut aussi caractériser le processus expérimental utilisé :
  • les solutions explorées,
  • les hypothèses générées,
  • l’expérimentation,
  • l’analyse,
  • les résultats et conclusions tirées, et
  • qui a travaillé sur ces activités

3- Documenter la pratique courante et « l’écart technologique »

L’ARC n’exige pas seulement de démontrer le travail effectué. Il faut de plus en plus prouver en premier lieu que ce travail représente un « progrès » par rapport à « l’état de l’art » (aussi appelé pratique courante) de la technologie. Si cette étape est ratée, le contribuable peut avoir une excellente preuve de ses recherches, mais il ne satisfait toujours pas la cinquième question pour identifier s’il y a de la RS&DE.

Une fois que cet « état de l’art » est défini, il est plus facile de décider quels documents représentent le « processus expérimental » ou des activités qui sont ou ne sont pas de la RS&DE et pourquoi. Cette étape dépasse les exigences absolues pour réclamer des crédits d’impôt RS&DE. Mais c’est une méthode efficace pour mieux défendre les réclamations. Et ça ouvre la voie à une protection supplémentaire de la propriété intellectuelle lors de la commercialisation.

Après avoir établi, défini et réuni les faits pertinents à « l’état de l’art », il faut préciser ce qui était possible avec cette technologie et le comparer à ce qui était nécessaire pour réaliser notre projet. Voilà la clé pour définir l’incertitude rencontrée dans un projet de RS & DE. Nous appelons cela « l’écart technologique ».

4- Conclusion

En conclusion, l’analyse de l’écart technologique et les documents retraçant les étapes essentielles du processus expérimental devraient normalement satisfaire le CRT de l’ARC. Notons de plus que la date à laquelle cet écart a été reconnu comme une barrière centrale est souvent utilisée pour établir le début du projet de RS & DE. Il faut donc écrire et dater les documents où nous définissons cet écart à la technologie.

Et vous, qu’en pensez-vous ? Comment définissez-vous l’incertitude technologique pendant le déroulement de vos projets de RS&DE ? Avez-vous des trucs ? des façons de faire ou des idées à partager à ce sujet ? Comment l’ARC a-t-elle réagi à vos mécanismes de documentation ?

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 ?

Comment documenter la RS&DE : une méthode simple et économique

Comment peut-on satisfaire les exigences accrues de documentation de l’ARC ? Qu’est-ce qui se fait en pratique dans l’industrie pour documenter les projets de RS&DE ?

Une réponse simple consiste à citer le guide T 4088 pour compléter le formulaire T661 :

« Il est important de conserver des preuves à l’appui de votre demande (par exemple : renseignements, registres, documentation) afin de justifier que les travaux de recherche scientifique et de développement expérimental (RS&DE) ont été effectués et que les dépenses déductibles ont été engagées. (…) En fait, la documentation contemporaine datée, signée et spécifique aux travaux effectués est la meilleure preuve que vous puissiez fournir à l’appui des travaux demandés. »

C’est bien beau en théorie, mais en pratique, comment produire et maintenir des preuves contemporaines et mieux satisfaire aux exigences de l’ARC ?

Mesurez-vous le niveau croissant de risque auquel vous soumettez votre réclamation si vous n’avez pas encore mis en place un système de documentation continue de vos activités de RS&DE ?

« – Un système de documentation continue des activités de RS&DE  – Appuyé sur vos ressources-clé des projets »

Partagez ce Tweet SVP

Historique

La position de l’ARC au sujet de la documentation a beaucoup évolué au cours de la dernière décennie. C’était une question secondaire à l’époque mais maintenant la mise en place d’un dossier de preuve contemporain est pratiquement devenu un critère supplémentaire. Depuis quelques années, c’est devenu la cinquième question permettant de déterminer s’il y a de la RS&DE. Le raisonnement derrière tout cela c’est que la production d’enregistrement est devenue une caractéristique déterminante de la RS&DE. Donc s’il y a une documentation insuffisante alors non seulement le travail n’est pas pris en charge, mais ça ne doit pas être de la RS&DE.

Dans le contexte des restrictions budgétaires des dernières années, la mentalité de récupération a prospéré à l’ARC. La documentation a été vue comme un moyen potentiellement rapide de mettre de côté les revendications lorsque la charge de travail a alourdi le programme. La preuve documentaire est pour l’ARC un excellent moyen d’obtenir des taux intéressants de récupération (ou de rejet) des crédits d’impôt. Tout ce qu’il faut c’est de passer d’une position « qui apparaît raisonnable » à celle de « prouvez-le! ».

Documentation contemporaine

Ainsi, l’exigence d’une documentation contemporaine implique que l’information reconstruite plus tard (ex. : les rapports produits en fin d’année) a moins de valeur aux yeux de l’ARC. L’ARC est à la recherche de la documentation qui a été « produite naturellement au cours d’un projet et qui devrait être suffisante pour appuyer une demande de RS & DE ».

Certains réclamant croient que cela signifie que toute paperasse relative au projet devrait satisfaire l’ARC. Ça ne fonctionne pas comme cela.

La véritable signification de cette exigence c’est que la génération des pièces justificatives est une caractéristique d’un projet de RS & DE. Répétons ici le raisonnement de l’ARC : Si les documents produits dans le cours normal d’un projet ne sont pas suffisants pour appuyer une demande, le projet est non seulement non pris en charge comme de la RS&DE, mais ce n’en est pas.

Donc, il faut démontrer à l’ARC que tout au long de l’année vous identifiez rapidement vos projets éligibles, et que vous les gérez comme des projets de RS&DE distincts de vos autres projets de développement.

Un système de documentation simple et à faible coût

Il est illusoire de s’imaginer que les petits et les moyens réclamant vont mettre en place des cahiers de laboratoire détaillés dédiés à la recherche, et qu’ils vont se doter des équipements et des spécialistes de la documentation scientifique qu’une telle approche semble exiger.

C’est pourquoi nous présentons ici une approche simple à mettre en place et efficace. L’essentiel de ce système repose sur deux piliers : C’est

• Un système de documentation continue
• Appuyé sur vos ressources-clé des projets.

Il s’agit donc de créer un système pour capturer les activités éligibles durant l’année, et pour :

• Être utilisé régulièrement par les employés parce qu’il n’est pas lourd et encombrant,
• Faciliter la préparation des formulaires de fin d’année (T661), et
• Satisfaire aux exigences de l’ARC.

Voici la solution :

1- Formez votre personnel de développement à reconnaître les activités éligibles en :

• Assistant aux séminaires publics de l’ARC.
• Formant tout le personnel de gestion de projets et des équipes de R&D.
• Rafraîchissant les mémoires et informant des nouveautés.

2- Mettez en place un système formel de marquage des projets dès que l’équipe de développement rencontre ses premiers problèmes majeurs.

• Les équipes de développement peuvent utiliser des filtres ou des marqueurs distinctifs pour identifier les activités de RS & DE et en archiver les résultats.

3- Motivez le personnel à enregistrer les activités potentiellement éligibles

• Rappelez-leur l’importance du programme pour l’entreprise – réduction des impôts, augmentation des liquidités, emplois maintenus, etc.
• Transférez une partie des résultats des réclamations de crédits d’impôt RS&DE au budget des projets R&D afin qu’ils s’équipent ou qu’ils initient de nouvelles recherches intéressantes
• Mettez en place un programme de bonus individuel incitatif pour souligner leur contribution au succès des réclamations.

4- Demandez aux équipes de développement des « certificats de naissance » au début d’un projet

• Le certificat de naissance est un aperçu condensé qui identifie, tôt dans le processus :
  • Les principales contraintes et défis technologiques ;
  • Les incertitudes technologiques potentielles ;
  • Les progrès technologiques potentiels recherchés ;
  • Les approches ou hypothèses potentielles – prouvées et non prouvées.
• Le certificat est utilisé comme point de départ pour le formulaire T661.
• Archivez les certificats de naissance ou incluez-les dans vos rapports de gestion normale.

5- Contrôlez le système et la conformité de son application

• Nommez un leader technique pour travailler avec le contrôleur
• Identifiez les projets offrant un bon potentiel de réclamation et rédigez pour chacun un plan des travaux à réaliser
• Organisez des rencontres régulières de suivi de projets et conservez-en copie des minutes et des actions en découlant
• Révisez régulièrement les dossiers de documentation

6- Produisez des rapports périodiques de progrès des travaux suite aux certificats de naissance :

• Prenez en note :
  • Les problèmes rencontrés,
  • Les hypothèses soulevées,
  • Le progrès des résultats,
  • La résolution des problèmes
  • Les événements majeurs.
• Recueillez et archivez ces rapports sur une base régulière (hebdomadaire, bi mensuel, etc.).
• Incluez diverses formes de rapports telles que :
  • Rapport de résultats de tests pour les activités de RS&DE
  • Revues de conception
  • Rapports concernant des événements majeurs,
  • Rapports réguliers sur des situations particulières,
  • Brouillons de formulaire T661, etc.

7- Conservez une copie complète de chaque prototype clé incluant ses données d’exécution, son environnement de production et de test.

8- Développez un système pour ségréguer les activités éligibles de celles de routine :

• Établissez un département distinct pour l’équipe de R&D
• Distinguez les enjeux de technologie de ceux de développement de nouveaux produits
• Mettez en place une codification des projets avec sous-codes pour identifier les activités de RS&DE
• Enregistrez les activités expérimentales et reliez-lez au plan du projet dans votre système de gestion de projet
• Assurez-vous de bien enregistrer le temps par employé par activité, surtout pour les activités éligibles.

9- Suivez les dépenses :

• Plans et rapports sur l’allocation réelle des ressources ;
• Feuilles de temps détaillées par activité de RS&DE ;
• Résumés périodiques des superviseurs.
• Maintenez à jour, pour chaque employés et sous-traitants :
  • Nom et coordonnées
  • Le nombre d’heures ou la proportion de leur temps utilisé sur les activités éligibles, par projet
  • Le lien avec le système de paie et le G/L
  • Les qualifications de chacun pour ce projet :
    • Leur rôle (technique)
    • Formation/expérience
    • Années d’expérience
    • Date d’arrivée / départ du projet
    • Commentaires, contribution spéciale, etc.
  • Identifiez et documentez les activités indirectes et de soutien nécessaires au progrès des activités de RS&DE :
    • Préparation des équipements et du matériel
    • Expérimentation et analyse des résultats
    • Enregistrement des mesures, calculs et graphiques
    • Identification d’activités éligibles de support
    • Coordination directe des activités de RS&DE
  • Documentez le coût des matériaux consommés et/ou transformés
    • Révisez la définition de matériaux consommés et de matériaux transformés (méthode traditionnelle)
    • Notez les matériaux vendus ou convertis pour un usage commercial
  • Conservez copie signée des contrats de sous-traitance et des contrats clients concernés par vos projets de RS&DE

10- Conservez toute autre information pouvant servir de back-up, le cas échéant

Conclusion

Ainsi donc, la mise en place d’un tel système génère plusieurs avantages importants :

• Un meilleur suivi de la R & D
• Un dépistage hâtif des réclamations
• Une meilleure compréhension de la R & D par tous
• Une réduction du risque d’échapper des projets éligibles
• Une meilleure probabilité de satisfaire aux exigences de l’ARC
• Une augmentation de la valeur des réclamations de RS & DE

Et vous, quelles sont vos expériences et vos trouvailles en matière de documentation des activités de RS&DE ? Avez-vous besoin d’aide pour la mise en place d’un tel système économique de documentation pour vos réclamations ?