RS&DE pour les entreprises logicielles : guide complet du DT

Le développement logiciel représente 40,8 % de tous les crédits RS&DE approuvés par l’ARC. C’est la catégorie la plus importante du programme. Si votre équipe d’ingénierie fait face à des incertitudes technologiques, vous êtes presque certainement admissible à des crédits plus importants que vous ne le pensez.

La plupart des entreprises logicielles laissent une part substantielle de leurs crédits sur la table. Non pas parce que leur travail n’est pas admissible, mais parce que la documentation est fastidieuse, les règles d’admissibilité semblent opaques, et associer le travail d’ingénierie au cadre de l’ARC demande un effort que personne ne veut interrompre son sprint pour faire.

Ce guide s’adresse aux directeurs techniques et aux responsables d’ingénierie qui veulent comprendre le programme en profondeur : ce qui se qualifie, ce que valent les crédits, ce que l’ARC exige en matière de documentation, comment fonctionne le formulaire T661, et les erreurs qui réduisent le plus souvent les demandes.

Qu’est-ce que la RS&DE?

RS&DE signifie Recherche Scientifique et Développement Expérimental. C’est le plus grand programme d’incitatifs fiscaux fédéraux pour la R&D au Canada, administré par l’Agence du revenu du Canada. Le programme offre des crédits d’impôt à l’investissement (CII) pour les dépenses admissibles engagées lors de l’avancement des connaissances scientifiques ou technologiques.

Le programme existe depuis 1986. En 2024-2025, l’ARC a traité 22 758 demandes et approuvé 4,5 milliards de dollars en crédits. Ce n’est pas une subvention ou une remise. C’est un crédit d’impôt appliqué contre l’impôt fédéral sur le revenu des sociétés, avec un volet remboursable pour certaines sociétés qui signifie un remboursement en argent même les années où l’entreprise est déficitaire.

Pour les entreprises logicielles, la RS&DE couvre les travaux où votre équipe d’ingénierie tentait de résoudre un problème qui ne pouvait pas l’être en appliquant des techniques existantes. Le résultat était incertain, l’approche exigeait une investigation, et votre équipe a appris quelque chose de nouveau sur ce qui était techniquement possible.

Trois types d’activités sont admissibles :

• La recherche fondamentale — travaux expérimentaux ou théoriques pour faire avancer les connaissances sans application commerciale spécifique
• La recherche appliquée — travaux pour faire avancer les connaissances dans un but pratique précis
• Le développement expérimental — travaux pour réaliser un avancement technologique pour un matériau, un dispositif, un produit ou un procédé nouveau ou amélioré

La grande majorité des demandes d’entreprises logicielles relèvent du développement expérimental.

Votre R&D logicielle est-elle admissible?

L’ARC applique un test en trois parties à chaque projet d’une demande RS&DE. Les trois parties doivent être satisfaites.

Qu’est-ce que l’incertitude technologique?

Définition de l’ARC : “Le fait de ne pas savoir si un résultat ou un objectif donné peut être atteint, ou comment l’atteindre, sur la base des connaissances ou de l’expérience scientifiques ou technologiques généralement disponibles.”

C’est le critère le plus important et le plus mal compris. L’incertitude technologique n’est pas la même chose que la difficulté technique. Construire quelque chose de complexe en utilisant des techniques établies, c’est difficile, pas incertain. L’incertitude existe quand un ingénieur compétent, en appliquant toutes les méthodes connues, ne peut pas déterminer à l’avance comment atteindre l’objectif ou si c’est même possible.

En pratique pour les équipes logicielles :

• Admissible : Votre équipe a investigué si un modèle d’apprentissage automatique pouvait produire une classification fiable au seuil de confiance requis avec les données d’entraînement disponibles. La réponse était inconnue au départ.
• Non admissible : Votre équipe a implémenté un moteur de recommandation en utilisant un algorithme de filtrage collaboratif établi. L’algorithme était connu; vous l’appliquiez.
• Admissible : Votre équipe a tenté d’atteindre une latence inférieure à 50 ms sur un pipeline de données en temps réel sous des charges d’écriture concurrentes dépassant les benchmarks publiés pour votre technologie de file de messages. Aucune solution connue n’existait.
• Non admissible : Votre équipe a ajouté un cache Redis pour améliorer le temps de réponse des requêtes. La technique était établie; le résultat était prévisible.

Une décision de la Cour canadienne de l’impôt de 2024 dans DAZZM Inc. c. Sa Majesté le Roi (2024 CCI 129) a élargi la définition de manière significative. Le juge Gagnon a confirmé que “l’incertitude systémique” — l’incertitude découlant des interactions entre des composants connus — peut satisfaire ce critère. Si votre équipe a intégré deux systèmes existants ou plus et a rencontré des effets d’interaction nécessitant une investigation originale, vous pourriez avoir des travaux admissibles même si aucun composant individuel n’était nouveau.

Que signifie investigation systématique?

Les travaux doivent utiliser une approche systématique : formuler des hypothèses, les tester, observer les résultats, tirer des conclusions, itérer. L’ARC utilise le cadre “Northwest Hydraulic” d’une décision de la Cour de l’impôt de 1998 pour évaluer si un projet satisfait cette norme.

Le test en cinq parties que l’ARC applique :

1. Y avait-il une incertitude scientifique ou technologique?
2. Des hypothèses ont-elles été formulées pour réduire cette incertitude?
3. L’approche était-elle conforme à une investigation systématique par l’expérimentation ou l’analyse?
4. L’objectif était-il un avancement scientifique ou technologique?
5. Des registres des hypothèses testées et des résultats obtenus ont-ils été tenus au fur et à mesure?

Pour les équipes logicielles, cela ressemble à : un document de conception technique (hypothèse), la mise en oeuvre et les tests (expérience), les résultats mesurés par rapport aux performances attendues (résultats), la documentation de ce qui a été appris (conclusion). Les processus de développement agile s’appliquent raisonnablement bien à cette structure.

Qu’est-ce qui constitue un avancement technologique?

Les travaux doivent générer de nouvelles connaissances ou capacités qui font avancer l’état de la technologie. L’avancement n’a pas à être à l’échelle de l’industrie. Il peut être local à votre organisation : quelque chose que votre équipe comprend maintenant sur l’espace du problème qui n’était pas connu au départ.

• Admissible : Votre équipe a déterminé qu’une architecture de réseau neuronal spécifique ne peut pas atteindre une latence d’inférence fiable sous les contraintes de votre environnement de déploiement, puis a développé une architecture modifiée qui le peut.
• Non admissible : Votre équipe a livré une fonctionnalité plus rapidement que prévu parce que l’ingénierie était simple.
• Admissible : Votre équipe a établi les conditions limites de performance sous lesquelles un algorithme de consensus distribué se dégrade, puis a développé un mécanisme de repli pour gérer ces conditions.
• Non admissible : Votre équipe a refactorisé du code hérité pour améliorer la maintenabilité. Une meilleure structure n’est pas un avancement technologique.

Qu’est-ce que l’ARC exclut explicitement des logiciels RS&DE?

Certaines catégories sont exclues, quelle que soit leur complexité technique :

• La correction de bogues courants en utilisant des méthodes de débogage établies
• La saisie, la conversion ou la migration de données entre systèmes
• Le contrôle de qualité et les tests courants
• La maintenance des logiciels existants
• L’application de cadres, bibliothèques ou API standard sans traiter leurs limitations techniques connues
• L’ajout de fonctionnalités d’interface utilisateur ou de fonctionnalités en utilisant des méthodes techniques existantes

Combien vaut votre crédit RS&DE?

La structure du crédit dépend du type de votre société, de la nature des dépenses et de votre province.

Quels sont les taux de crédit RS&DE fédéraux?

Sociétés privées sous contrôle canadien (SPCC) :

• CII remboursable de 35 % sur les premières dépenses admissibles de 3 M$ par année
• CII non remboursable de 15 % sur les dépenses admissibles au-dessus de 3 M$

Toutes les autres sociétés (non-SPCC, sociétés publiques, contrôle étranger) :

• CII non remboursable de 15 % sur toutes les dépenses admissibles
• Aucun volet remboursable

“Remboursable” est la distinction clé. Une SPCC avec un crédit remboursable de 35 % sur 3 M$ de dépenses admissibles reçoit 1,05 M$, même si la société n’a pas d’impôt à payer cette année-là.

Pour la plupart des entreprises logicielles en démarrage, le statut SPCC et le mécanisme de crédit remboursable sont la raison pour laquelle la RS&DE vaut la peine d’être réclamée, même les années déficitaires.

La réduction du seuil SPCC : le seuil amélioré de 3 M$ commence à s’éliminer progressivement lorsque le revenu imposable de l’année précédente dépasse 500 000 $ et est entièrement éliminé à 800 000 $. Il s’élimine également lorsque le capital imposable de l’année précédente dépasse 10 M$ et est éliminé à 50 M$.

Quelles dépenses sont admissibles à la RS&DE?

Les crédits RS&DE s’appliquent à :

• Les salaires et traitements des employés directement engagés dans la RS&DE
• Les matériaux consommés ou transformés dans l’exécution de la RS&DE
• Les coûts des sous-traitants pour la RS&DE effectuée en votre nom (à 80 % du montant payé)
• Les dépenses en capital pour l’équipement utilisé dans la RS&DE (restrictions récentes)
• Les frais généraux via la méthode de remplacement (55 % de la main-d’oeuvre directe, sans suivi détaillé)

Les salaires sont la catégorie la plus importante pour la plupart des entreprises logicielles. Un développeur consacrant 60 % de son temps à des projets admissibles contribue 60 % de son salaire à la base de dépenses admissibles.

Exemple de calcul : 500 000 $ en salaires admissibles

Une SPCC avec 500 000 $ en salaires admissibles, utilisant la méthode de remplacement :

Composante	Calcul	Montant
Salaires admissibles	Donnée	500 000 $
Remplacement des frais généraux (55 %)	500 000 $ × 55 %	275 000 $
Total des dépenses admissibles		775 000 $
CII fédéral à 35 % (SPCC)	775 000 $ × 35 %	271 250 $
Crédit provincial (Ontario, 8 %)	775 000 $ × 8 %	62 000 $
Total estimé du crédit		333 250 $

Comment se comparent les taux provinciaux de RS&DE?

Les taux provinciaux varient considérablement. Le taux combiné de l’Ontario pour une SPCC typique est d’environ 43 % (35 % fédéral plus 8 % provincial). Le crédit d’impôt RS&DE de la Colombie-Britannique est de 10 % remboursable pour les SPCC, donnant un taux combiné de 45 %. Le crédit R&D du Québec est de 14 à 30 % selon la taille de l’entreprise, poussant les taux combinés à 49-65 %. L’Alberta n’a pas de crédit provincial RS&DE, donc les SPCC ne reçoivent que le taux fédéral de 35 %.

Pour une société dépensant 1 M$ en R&D admissible en Ontario, c’est environ 430 000 $ en crédits par an.

Province	Fédéral (SPCC)	Provincial (approx.)	Combiné (approx.)
Ontario	35 %	8-11,5 %	43-46,5 %
Colombie-Britannique	35 %	10 %	45 %
Québec	35 %	14-30 %	49-65 %
Alberta	35 %	0 %	35 %

Quelle documentation l’ARC exige-t-elle?

La documentation est là où la plupart des demandes RS&DE réussissent ou échouent. L’ARC exige des registres contemporains : de la documentation créée pendant les travaux de R&D, pas assemblée après coup pour appuyer une demande.

Que signifie documentation contemporaine pour l’ARC?

La politique de documentation de l’ARC, IC86-4R3, précise que les preuves à l’appui doivent démontrer :

• La nature de l’incertitude technologique
• L’approche systématique adoptée pour l’investiguer
• Les travaux effectués, les hypothèses testées et les résultats observés
• L’avancement ou les nouvelles connaissances obtenus
• Le temps que les employés ont consacré aux activités admissibles

“Contemporaine” signifie que les registres existaient au moment où les travaux ont été effectués. Les commits Git, les demandes de tirage, les tickets de sprint, les documents de conception technique, les registres de décision d’architecture, les résultats de tests et les notes de réunion sont tous admissibles. Un document assemblé au moment de la demande a moins de poids.

Quelle documentation résiste à une vérification?

Ce qui tient :

• L’historique des commits Git avec des messages substantiels référençant le problème technique résolu
• Les descriptions de demandes de tirage décrivant l’approche d’investigation et le résultat
• Les tickets du suivi des problèmes (Jira, Linear, GitHub Issues) avec le contexte technique sur l’incertitude et l’approche
• Les registres de décision d’architecture (ADR) documentant pourquoi une approche technique a été choisie et quelles alternatives ont été rejetées
• Les résultats de tests et benchmarks indiquant ce qui a été mesuré, dans quelles conditions et ce qui a été trouvé
• Les rétrospectives de sprint ou les revues de conception où les défis techniques ont été discutés
• Les documents de conception technique rédigés avant le début de la mise en oeuvre

Ce qui ne tient pas :

• Les documents RS&DE rédigés par les ingénieurs spécifiquement pour la demande
• Les descriptions verbales assemblées lors d’entretiens rétrospectifs
• Les registres financiers sans narratifs techniques à l’appui
• Les allocations de temps sans preuve dans les outils de gestion de projet

Que contiennent les trois champs narratifs du T661?

Chaque projet admissible exige trois narratifs techniques dans la partie 2 du formulaire T661 :

• Ligne 242 (350 mots max) : L’incertitude technologique. Ce qui était inconnu ou inconnaissable au départ, et pourquoi cela ne pouvait pas être résolu en appliquant les connaissances existantes.
• Ligne 244 (700 mots max) : Les travaux effectués. Hypothèses, expériences, tests, résultats et conclusions en ordre chronologique.
• Ligne 246 (350 mots max) : L’avancement obtenu. Quelles nouvelles connaissances techniques ont été produites par l’investigation.

Comment déposer : T661 et processus

Le T661 doit être déposé avec votre déclaration de revenus T2 et le calendrier T2SCH31 du crédit d’impôt à l’investissement. Déposer le T661 sans le T2SCH31 — ou vice versa — entraîne la perte d’une partie de l’avantage.

La date limite de dépôt de la RS&DE est 18 mois après la fin de l’exercice pour la plupart des sociétés. L’ARC ne peut pas prolonger ce délai par la loi. Une demande déposée un jour en retard est refusée en entier. Il n’y a aucun mécanisme d’appel pour une date limite manquée.

Pour un exercice se terminant le 31 décembre : la déclaration T2 est due le 30 juin, et la date limite de la RS&DE est le 30 juin de l’année suivante.

L’ARC recommande de soumettre au moins 90 jours avant la date limite. Cela laisse le temps de corriger les lacunes identifiées lors d’une revue pré-approbation.

Quelles erreurs réduisent le plus souvent une demande RS&DE?

L’écart entre une demande solide et une demande réduite se situe presque toujours dans les narratifs et la qualité de la documentation. L’ARC approuve environ 80 % des demandes sans examen détaillé. Parmi les 20 % qui font l’objet d’un examen approfondi, la majorité sont réduites ou refusées.

Documentation rétroactive

La raison la plus fréquente pour laquelle les demandes sont réduites lors d’une vérification. Si votre équipe d’ingénierie rédige les narratifs RS&DE de mémoire au moment du dépôt, la documentation est intrinsèquement plus faible que les registres qui existaient pendant les travaux. Les vérificateurs de l’ARC comparent les dates sur les artefacts du projet avec les dates des travaux réclamés. Les incohérences sont un signal d’alarme.

La solution : documentez au fur et à mesure. Cela ne signifie pas ajouter de la paperasse RS&DE au flux de travail de vos ingénieurs. Cela signifie s’assurer que vos artefacts de développement existants contiennent suffisamment de contexte technique pour appuyer une demande. La plupart de ce dont l’ARC a besoin existe déjà dans vos outils de développement.

Langage d’incertitude technologique manquant

La partie 2, ligne 242 doit décrire l’incertitude technologique. Les vérificateurs cherchent un langage précis : ce qui était inconnu au départ, pourquoi c’était inconnu, et pourquoi cela ne pouvait pas être résolu en appliquant les connaissances existantes. De nombreuses sociétés décrivent ce qu’elles ont construit plutôt que l’incertitude à laquelle elles ont fait face.

“Nous avons développé un pipeline de traitement du langage naturel pour la classification de l’intention des clients” est une description du produit. “Nous avons investigué si des modèles basés sur des transformateurs pré-entraînés sur des corpus de texte général pouvaient atteindre une précision de classification de l’intention de qualité production sur un vocabulaire spécialisé de services financiers sans ajustement fin spécifique au domaine, où les données d’ajustement fin étaient limitées par des contraintes de confidentialité” décrit une incertitude.

Sous-comptage des dépenses admissibles

Les sociétés sous-déclarent fréquemment les allocations salariales admissibles. Elles ne réclament que les ingénieurs qui “travaillaient sur la RS&DE” comme projet, alors qu’en réalité, les travaux admissibles étaient distribués dans toute l’équipe tout au long de l’année. Un développeur consacrant 30 % de son temps à des travaux admissibles contribue 30 % de son salaire à la base — mais seulement si cette allocation est suivie et documentée.

Réclamation de 100 % du salaire sans support

Allouer 100 % du salaire d’un ingénieur à la RS&DE sans registres de temps à l’appui attire l’attention de l’ARC. Les allocations de temps supérieures à 80 % pour un individu nécessitent des données de suivi du temps, des registres d’agenda ou de la documentation d’affectation de projet pour être justifiées.

Critère d’avancement technologique manquant

La ligne 246 doit décrire quelles nouvelles connaissances techniques ont été produites. De nombreuses sociétés décrivent le résultat commercial. L’ARC ne se soucie pas des résultats commerciaux. Le contenu requis est technique : ce que votre équipe comprend maintenant sur l’espace du problème, quelles contraintes ont été cartographiées, quelles approches ont été confirmées comme infaisables, quelle méthode nouvelle a été développée.

Consultant ou logiciel RS&DE : quelle approche choisir?

Trois façons de préparer une demande RS&DE : utiliser un consultant traditionnel, utiliser un logiciel RS&DE, ou la préparer entièrement en interne. La bonne réponse dépend de la complexité de votre demande, de la capacité de votre équipe et de la fréquence à laquelle vous déposez.

Les consultants RS&DE facturent généralement 15 à 30 % de la valeur totale de la demande. Sur une demande de 300 000 $, c’est 45 000 $ à 90 000 $.

Un consultant est judicieux lorsque :

• C’est votre première demande RS&DE
• Votre demande inclut des projets controversés ou complexes susceptibles d’attirer l’examen de l’ARC
• Vous avez une grande demande ponctuelle après une période de plusieurs années sans dépôt
• Vos équipes d’ingénierie et de finances n’ont pas la capacité de gérer le processus

Le logiciel RS&DE est la meilleure approche lorsque :

• Vous déposez des demandes RS&DE chaque année
• Vos travaux admissibles sont principalement du développement logiciel
• Votre équipe génère déjà une bonne documentation technique dans son flux de travail
• Vous voulez réduire la dépendance aux consultants tout en maintenant la qualité des demandes
• Vous vous souciez de la préparation aux vérifications

L’avantage principal du logiciel est la saisie continue. Plutôt que de reconstruire les travaux admissibles de l’année au moment du dépôt, la documentation est construite de manière incrémentale à partir des artefacts de développement réels.

Comment Chrono R&D s’intègre dans tout ça?

Si vous déposez des demandes RS&DE chaque année, le manque de documentation est le problème qui mérite d’être résolu.

Les travaux admissibles que vos ingénieurs ont effectués cette année sont déjà dans vos outils de développement. Ils sont dans l’historique des commits, les descriptions de PR, les tickets de sprint et les décisions d’architecture. La question est de savoir si c’est capturé dans un format que l’ARC peut évaluer, ou si votre équipe passera des semaines à le reconstruire au moment du dépôt.

Chrono R&D se connecte à vos dépôts git, suiveurs de problèmes et outils de gestion de projet. Il identifie les travaux admissibles au fur et à mesure, structure les narratifs techniques dans le format requis par l’ARC, et produit un dossier prêt à soumettre. Vos ingénieurs ne rédigent pas de rapports RS&DE. Votre dépôt ne dépend pas de la mémoire. Votre documentation est prête pour une vérification dès le premier jour.

Référence rapide RS&DE pour les entreprises logicielles

Élément	Détail
Nom du programme	Recherche Scientifique et Développement Expérimental (RS&DE)
Administré par	Agence du revenu du Canada (ARC)
Type de crédit	Crédit d’impôt à l’investissement (CII)
Taux fédéral SPCC	35 % remboursable sur les premières dépenses admissibles de 3 M$
Taux fédéral non-SPCC	15 % non remboursable
Formulaire de dépôt	T661 (déposé avec T2 et T2SCH31)
Date limite de dépôt	18 mois après la fin de l’exercice
Part logicielle des demandes RS&DE	40,8 % de tous les crédits accordés

FAQ

Notre entreprise logicielle se qualifie-t-elle pour la RS&DE si nous ne travaillons pas sur l’IA ou l’apprentissage automatique?

Oui. Le test de qualification porte sur l’incertitude technologique, pas sur le type de technologie. Tout projet logiciel où le résultat était genuinement inconnu au départ, a nécessité une investigation systématique et a produit de nouvelles connaissances techniques peut se qualifier. Cela inclut les travaux sur les systèmes distribués, la performance des bases de données, les pipelines de données en temps réel, l’architecture de sécurité et bien d’autres domaines.

Jusqu’où pouvons-nous déposer des demandes RS&DE rétroactivement?

La date limite est 18 mois après la fin de l’exercice. Vous ne pouvez pas déposer rétroactivement pour des années au-delà de cette fenêtre. Si vous n’avez jamais réclamé la RS&DE, vous pouvez déposer pour votre exercice en cours et potentiellement l’année précédente selon votre date de fin d’exercice.

Quelle est la plus grande erreur de documentation que font les entreprises logicielles?

Rédiger les narratifs RS&DE de mémoire au moment du dépôt plutôt que de capturer le contexte technique au fur et à mesure. Les registres qui tiennent lors d’une vérification sont ceux qui existaient pendant le projet : commits git, descriptions de PR, tickets de problèmes et documents de conception. Un narratif assemblé six mois après les faits a beaucoup moins de poids auprès des vérificateurs de l’ARC.

---

Prêt à voir ce que valent les travaux de votre équipe d’ingénierie en crédits RS&DE? Parlez-nous — nous ferons une évaluation rapide de vos projets admissibles sans frais.