Point clé
Une demande de RS&DE ne se gagne pas à la réunion de préparation du printemps. Elle se gagne pendant l'année, avec des hypothèses datées, des PR abandonnées documentées, des décisions consignées et une répartition hebdomadaire du temps, et vous pouvez tester un projet actif avec une vérification en 10 questions dès cette semaine.
La plupart des demandes de RS&DE (recherche scientifique et développement expérimental) ne perdent pas leur valeur au moment de la production. Elles la perdent pendant l’année, quand personne n’écrit ce qui était incertain et que les essais ratés disparaissent. Cet article s’adresse aux CTO, aux responsables techniques et aux responsables des finances d’entreprises logicielles canadiennes qui veulent une demande bâtie sur des traces, pas sur des souvenirs. Il se termine par une vérification en 10 questions à faire sur un projet actif avant la fin de votre exercice.
Chaque printemps, la même réunion a lieu. Les finances ont l’échéance de la T2 (déclaration de revenus des sociétés) au calendrier. Le conseiller en RS&DE a envoyé un questionnaire. Le CTO et deux développeurs seniors s’assoient pour expliquer ce qui était incertain en mars de l’année d’avant, quelles approches l’équipe a essayées et pourquoi les deux premières n’ont pas marché.
Ils se souviennent de l’approche qui a été livrée. Ce qu’ils n’arrivent pas à reconstituer avec assurance, c’est justement ce qui intéresse le plus l’Agence du revenu du Canada (ARC) : l’hypothèse avant qu’on connaisse la réponse, les expériences qui ont échoué et les heures derrière chacune.
Cette réunion donne l’impression que c’est là que la demande se construit. Ce n’est pas le cas. La valeur s’est jouée des mois plus tôt, chaque fois qu’un essai raté a été écrasé dans une fusion propre, qu’une décision de conception est restée dans un fil Slack ou que personne n’a noté quels développeurs ont passé quelles semaines sur le problème difficile.
Ceci est de l’information générale, pas un conseil fiscal. Votre conseiller en RS&DE ou votre comptable valide ce qui est admissible et comment le réclamer.
Que dit vraiment l’ARC sur les dossiers de RS&DE?
L’ARC indique que tenir des dossiers « tout au long de toutes les phases de vos travaux de RS&DE » appuie la demande et peut réduire les erreurs, et qu’une documentation datée, signée et propre aux travaux réalisés est la meilleure. Sa page « Se préparer à faire une demande » place les feuilles de temps et les registres d’activités juste à côté des dossiers de projet.
Le signal récent le plus clair, c’est le processus d’approbation préalable que l’ARC a ouvert le 1er avril 2026 pour les entreprises admissibles dont le revenu brut annuel est inférieur à 25 M$. Le formulaire demande de décrire comment vous allez suivre les travaux de RS&DE et les dépenses associées, y compris vos pratiques de documentation, et comment vous allez tenir une documentation contemporaine tout au long du projet. Il demande aussi des preuves de diligence raisonnable montrant que les connaissances et les approches existantes ne suffisaient pas.
La documentation contemporaine n’est pas une condition juridique stricte pour chaque demande. Les tribunaux ont accepté des preuves crédibles produites plus tard. Mais une preuve reconstituée pèse moins lourd qu’un document daté fait sur le moment, et elle coûte beaucoup plus cher à produire.
L’enjeu a aussi grimpé cette année. Le projet de loi C-15, qui a reçu la sanction royale le 26 mars 2026, a fait passer le plafond de dépenses du crédit remboursable bonifié de 35 % de 3 M$ à 6 M$. Il a aussi rétabli l’admissibilité des dépenses en capital pour les biens acquis à compter du 16 décembre 2024. Plus de dépenses sont admissibles au taux bonifié, donc plus de dépenses dépendent de la preuve.
Où la preuve de RS&DE s’échappe-t-elle pendant un sprint normal?
Aux fusions, aux lancements de projet, dans les fils Slack et dans les feuilles de temps. Aucune de ces fuites ne vient de la négligence. Elles viennent de bonnes pratiques d’ingénierie conçues pour livrer du logiciel, pas pour prouver de la recherche.
| Fuite | Quand elle se produit | Ce que la demande perd |
|---|---|---|
| Approches ratées écrasées ou supprimées | À la fusion, quand on fait le ménage des branches | La preuve d’une investigation systématique. Les impasses sont la preuve. |
| Incertitude jamais écrite | Au lancement, quand tout le monde « sait » où est le risque | L’hypothèse, formulée avant qu’on connaisse la réponse |
| Décisions prises dans Slack ou en appel | En milieu de projet, pendant le débogage | Le raisonnement qui relie une expérience à la suivante |
| Recherche cachée dans des billets de fonctionnalité | À la planification, quand les essais sont fondus dans des récits | La capacité de séparer les heures admissibles du travail courant |
| Temps non suivi par rapport au problème | Chaque semaine | Une répartition de la main-d’œuvre défendable, qui fait l’essentiel de la valeur en dollars |
| Départ ou rotation des développeurs | N’importe quand | La seule personne capable d’expliquer le travail |
La plupart de ces fuites arrivent au moment où la preuve coûte le moins cher à garder. Une demande de fusion (PR, pour pull request) fermée avec une raison d’une ligne ne coûte rien au moment de la fusion. Reconstituer pourquoi elle a été fermée coûte un après-midi à un développeur neuf mois plus tard, et la réponse est moins crédible.
À quoi ressemble une preuve contemporaine dans une pile logicielle?
Surtout à des artefacts que votre équipe produit déjà, datés et reliés au projet. Le cadre de l’ARC demande s’il y avait une incertitude technologique, si une équipe qualifiée a mené une investigation systématique et si les travaux visaient un avancement technologique. Chacun de ces critères correspond à quelque chose dans vos outils.
| Ce que l’examinateur doit voir | Où ça se trouve déjà | Ce qu’il faut ajouter pour que ça tienne |
|---|---|---|
| Ce qui était incertain, avant de connaître la réponse | Billet d’exploration, RFC (demande de commentaires), document de conception | Une hypothèse écrite et la raison pour laquelle les approches connues ne suffisaient pas, datée au lancement |
| Expériences et itérations | Branches, PR, commits | Garder les PR ratées fermées avec une raison. Ne pas supprimer la branche. |
| Résultats mesurés | Exécutions d’intégration continue (CI), scripts de banc d’essai, tableaux de bord | Committer les résultats des bancs d’essai ou les joindre au billet |
| Décisions et raisonnement | Slack, réunions | Un registre de décision d’architecture (ADR) ou un court résumé recollé dans le billet |
| Qui a fait le travail, et pendant combien de temps | Auteurs Git, personnes assignées aux billets, feuilles de temps | Une répartition hebdomadaire des heures au projet, par personne |
| Ce qu’on a appris | Notes de rétro, la PR finale | Une note de clôture dans le billet : ce qui a marché et ce qu’on sait maintenant |
Le récit technique que vous finirez par produire s’écrit à partir de ce tableau. Notre guide du formulaire T661 couvre la partie récit.
Quelles habitudes de saisie marchent sans ralentir l’équipe?
Celles qui se greffent à ce que l’équipe fait déjà. Demander aux développeurs d’écrire plus, c’est perdu d’avance. Leur demander d’ajouter une ligne à un billet qu’ils ferment déjà, ça passe.
Étiqueter la recherche au lancement. Ajoutez un court gabarit aux billets d’exploration et aux RFC : ce qu’on ne sait pas, pourquoi les approches évidentes ne marcheront pas, comment on va le tester. Trois phrases écrites le premier jour valent plus que trois pages écrites au printemps suivant.
Fermer les PR ratées avec une raison. Une PR fermée intitulée « Approche B : cache en écriture immédiate, abandonnée, lectures incohérentes sous écritures concurrentes » est un document daté d’investigation systématique. Ça a pris dix secondes.
Ramener les décisions dans le dossier. Quand un fil Slack ou un appel règle une question technique, quelqu’un colle un résumé de deux lignes dans le billet ou rédige un court ADR.
Garder les chiffres. Si un banc d’essai a tranché une question, committez le résultat ou joignez-le. « Le p95 est passé de 410 ms à 160 ms sur le jeu d’essai », avec une date, vaut mieux que « la performance s’est nettement améliorée ».
Répartir le temps chaque semaine, pas chaque année. La main-d’œuvre est habituellement la plus grosse part de la demande d’une entreprise logicielle, et c’est la part la plus souvent estimée après coup. Une répartition hebdomadaire par personne et par projet, même en pourcentages approximatifs, est beaucoup plus facile à défendre. Certaines équipes la tirent des billets assignés.
Faire le point chaque mois avec les finances. Une vérification mensuelle de 20 minutes entre le responsable technique et la personne responsable de la demande attrape les lacunes pendant que les gens qui ont fait le travail s’en souviennent encore. Votre conseiller peut y assister et voir du vrai matériel des mois d’avance.
Notre article sur la vérification en RS&DE explique pourquoi ce sont les lacunes de documentation, et non les travaux inadmissibles, qui causent la plupart des rajustements. Ces habitudes comblent ces lacunes avant qu’un examinateur les trouve.
Comment faire une vérification des lacunes de preuve sur un projet?
Choisissez un projet actif qui comporte une vraie incertitude technique et répondez à dix questions en utilisant seulement ce qui existe dans vos outils aujourd’hui. N’auditez pas tout votre programme de R-D. Si vous devez expliquer quelque chose de mémoire, la réponse est non.
| # | Question | Vert | Jaune | Rouge |
|---|---|---|---|---|
| 1 | L’incertitude technologique est-elle écrite, avec une date antérieure au début des travaux? | Billet ou document daté | Écrite plus tard | Pas écrite |
| 2 | Le dossier explique-t-il pourquoi les approches connues ne suffisaient pas? | Précis, avec références | Générique | Absent |
| 3 | Pouvez-vous montrer au moins deux approches essayées, dont une qui a échoué? | PR ou branches liées | Seule la gagnante reste | Rien de traçable |
| 4 | Les résultats sont-ils mesurés et conservés, pas seulement décrits? | Résultats committés ou données jointes | Chiffres dans Slack | Adjectifs seulement |
| 5 | Les décisions techniques clés sont-elles consignées là où vit le projet? | ADR ou résumés dans les billets | Éparpillées dans le clavardage | Dans la tête des gens |
| 6 | Pouvez-vous dire qui a travaillé dessus et environ combien d’heures chacun, par mois? | Répartition hebdomadaire | Personnes assignées seulement | Estimation de fin d’année |
| 7 | Le travail admissible est-il séparable du travail courant dans l’outil de suivi? | Billets ou étiquettes distincts | Mélangé, mais séparable avec effort | Complètement fondu |
| 8 | Si le développeur principal partait demain, quelqu’un d’autre pourrait-il expliquer le projet à partir du dossier? | Oui | En partie | Non |
| 9 | Les contributions des sous-traitants sont-elles identifiées et leurs contrats au dossier? | Oui | En partie | Inconnu |
| 10 | Votre conseiller pourrait-il examiner ce projet sans interroger personne? | Oui | Avec un court appel | Non |
Les équipes qui font l’exercice pour la première fois sont habituellement au vert sur les artefacts de code, parce que Git garde tout. Elles sont au rouge sur le raisonnement et sur le temps.
Sur un seul projet, les correctifs sont évidents et petits. Vous ajoutez une hypothèse à un billet, vous rouvrez trois PR fermées et vous commencez une répartition hebdomadaire pour quatre personnes.
À quoi ressemble la vérification sur un vrai projet?
Habituellement à un mélange : un bon historique de code, un raisonnement faible et aucun suivi du temps. L’entreprise et les chiffres ci-dessous sont fictifs et ne décrivent pas un client.
Une entreprise SaaS de 35 personnes dont l’exercice se termine le 31 décembre fait la vérification à la mi-octobre sur son projet le plus technique : la résolution de conflits en temps réel pour les modifications hors ligne de son application mobile. Huit développeurs y ont touché depuis février.
Les résultats :
- Vert aux questions 3, 4 et 7. L’équipe a essayé les transformations opérationnelles, puis les CRDT (types de données répliqués sans conflit), puis une approche hybride. Les trois existent sous forme de branches. Les bancs d’essai sont committés. Le travail a sa propre épopée.
- Jaune aux questions 5 et 8. La décision d’abandonner les transformations opérationnelles a été prise lors d’un appel de deux heures en mai. Le raisonnement ne survit que dans les notes personnelles d’un développeur.
- Rouge aux questions 1, 2 et 6. Personne n’a écrit l’incertitude au lancement. La description de l’épopée dit « bâtir la synchro hors ligne ». Les heures n’ont jamais été réparties, et les finances prévoyaient les estimer à partir des salaires en mars.
Voici ce qu’ils font des 11 semaines qui restent dans l’année :
- Le responsable technique rédige une note datée dans l’épopée : ce qui était inconnu en février, pourquoi les approches publiées ne convenaient pas à leur modèle de données et ce qu’ils prévoyaient tester. La note indique qu’elle a été écrite en octobre. C’est honnête, et bien mieux qu’en avril.
- Le développeur qui a les notes de mai les transforme en ADR et le relie aux branches fermées.
- Dès le lundi suivant, l’équipe répartit son temps chaque semaine. Pour février à octobre, les finances et le responsable technique reconstituent la répartition à partir de l’historique des billets et de l’activité Git, maintenant, pendant que les huit développeurs sont encore là pour la confirmer.
- Le conseiller obtient un accès en lecture à l’épopée en novembre au lieu d’un questionnaire en mars.
L’ingénierie reste exactement la même. Ce qui change, c’est la part qu’on peut en montrer.
Pourquoi octobre compte-t-il si votre exercice se termine le 31 décembre?
Parce que la fenêtre de production est longue, mais pas celle de la preuve. Pour une société dont l’exercice se termine le 31 décembre, la T2 est due six mois plus tard, le 30 juin, et la date limite de déclaration de la RS&DE tombe 12 mois après. À la mi-octobre, environ dix mois du travail de l’année sont déjà derrière vous.
La majeure partie est encore récupérable. Les développeurs font encore partie de l’équipe, les fils Slack sont consultables et les PR fermées existent. Quand la préparation de la demande commencera au printemps, ce ne sera plus vrai pour une partie de tout ça.
Les autres fins d’exercice déplacent les dates, pas la logique. Les entreprises dont l’exercice se termine le 31 mars viennent de passer la mi-année et peuvent corriger l’année en cours presque entièrement en route. Celles dont l’exercice se termine le 30 septembre viennent de fermer le leur et devraient saisir la preuve de l’an dernier pendant que la mémoire est fraîche.
Quelle place pour votre conseiller en RS&DE?
La même qu’avant. Ce qui change, c’est où vont ses heures. Un conseiller qui travaille à partir de billets datés, de PR liées et de répartitions hebdomadaires passe son temps à exercer son jugement : quels projets sont admissibles, comment présenter l’incertitude, comment la demande tiendra en examen. Un conseiller qui travaille à partir d’entrevues passe son temps à reconstituer.
C’est le modèle sur lequel Chrono R&D est bâti. La plateforme se connecte à vos dépôts Git et à votre outil de suivi des billets, saisit le travail admissible au fur et à mesure et le structure selon les critères de l’ARC, pour que chaque demande remonte à des artefacts sources datés. Vous pouvez travailler avec nos consultants partenaires certifiés ou garder votre conseiller actuel. Dans les deux cas, il examine des preuves au lieu de courir après. Pour savoir comment les examinateurs distinguent une preuve saisie d’un texte généré, lisez le test saisie contre génération.
Questions fréquentes
L’ARC exige-t-elle une documentation contemporaine pour une demande de RS&DE?
Pas comme condition juridique stricte. Les tribunaux ont accepté des preuves crédibles produites plus tard. Mais l’ARC dit que les documents datés et précis sont les meilleurs, et une preuve reconstituée pèse moins lourd et coûte beaucoup plus cher à produire.
Qu’est-ce qui compte comme preuve contemporaine pour un projet logiciel?
Des billets d’exploration ou des RFC datés qui énoncent l’hypothèse, des PR ratées fermées avec une raison, des résultats de bancs d’essai committés, des ADR ou des résumés de décision dans les billets, et une répartition hebdomadaire du temps par personne. La plupart de ces éléments existent déjà dans Git et dans votre outil de suivi.
Est-il trop tard pour corriger la documentation de l’exercice en cours?
Habituellement, non. Si les développeurs sont encore dans l’équipe et que les fils et les branches existent encore, vous pouvez rédiger des notes datées maintenant, transformer les décisions éparpillées en ADR et reconstituer la répartition du temps à partir de l’historique des billets et de Git. Indiquez clairement ce qui a été écrit après coup.
Pourriez-vous montrer à un examinateur ce qui s’est passé sur un projet?
Choisissez un projet de R-D actif. Pourriez-vous montrer à un examinateur, avec vos outils seulement, ce qui était incertain, ce que l’équipe a essayé et qui a fait le travail?
Si vous voulez un deuxième regard, on fera la vérification des lacunes de preuve sur ce projet avec votre responsable technique et votre responsable des finances, ensemble. Vous repartirez avec la liste des lacunes précises et de ce qu’il faut corriger avant la fin de votre exercice, que vous utilisiez Chrono R&D ou non. Réservez une vérification des lacunes de preuve, ou commencez avec Chrono R&D et connectez un dépôt vous-même.
Chrono R&D fournit un logiciel de documentation et travaille avec les conseillers en RS&DE. Rien dans cet article n’est un conseil fiscal. L’admissibilité et les montants sont déterminés par l’ARC, et votre conseiller ou votre comptable valide le traitement pour votre entreprise.
Sources : ARC, Se préparer à faire une demande | ARC, Approbation préalable : remplir votre demande | ARC, Processus d’approbation préalable (conseil fiscal, 2026) | Ministère des Finances, Adoption de la loi mettant en œuvre le budget 2025 | KPMG, Canada’s SR&ED program enters a new era