Éligibilité RS&DE en développement logiciel : critères et exemples

Votre équipe technique passe des semaines à résoudre un problème qui n’a pas de solution évidente. Cette situation peut soulever une question d’éligibilité à la RS&DE en développement logiciel, même si personne dans l’équipe n’a encore pensé au crédit d’impôt.

Le programme de recherche scientifique et développement expérimental (RS&DE) est le principal incitatif fiscal fédéral en recherche et développement au Canada. Les projets logiciels peuvent s’y qualifier, mais uniquement lorsque les travaux satisfont aux exigences techniques du programme.

La difficulté consiste à distinguer la mise en œuvre courante d’une véritable tentative pour générer de nouvelles connaissances technologiques. Un projet long, coûteux ou complexe n’est pas automatiquement admissible.

Comprendre l’éligibilité RS&DE en développement logiciel

Selon les critères d’admissibilité actuels de l’Agence du revenu du Canada, les travaux doivent être réalisés au Canada et satisfaire à deux exigences.

1. Pourquoi les travaux sont-ils réalisés?

Les travaux doivent viser l’avancement des connaissances scientifiques ou la réalisation d’un avancement technologique. Un avancement correspond à la génération ou à la découverte de connaissances qui font progresser la compréhension de la science ou de la technologie.

En logiciel, de nouvelles connaissances sont nécessaires lorsqu’il est impossible de déterminer, à partir des connaissances technologiques disponibles dans l’entreprise et de celles raisonnablement accessibles au public, si un résultat peut être atteint ou comment l’atteindre. C’est l’incertitude technologique.

Une difficulté commerciale, un échéancier serré, un manque d’expérience de l’équipe ou la complexité générale du produit ne suffisent pas. La limite doit appartenir à la base de connaissances technologiques disponible, et non seulement aux ressources du demandeur.

2. Comment les travaux sont-ils menés?

Les travaux doivent constituer une investigation ou une recherche systématique effectuée par expérimentation ou analyse. L’ARC décrit une démarche qui comprend :

1. la définition d’un problème;
2. la formulation d’une hypothèse susceptible de le résoudre;
3. la planification et la réalisation d’expérimentations ou d’analyses;
4. l’élaboration de conclusions logiques à partir des résultats.

Suivre une méthode de développement structurée ou un cadre Agile n’est pas suffisant en soi. Il faut relier les essais à une hypothèse technologique et montrer les connaissances acquises, que l’objectif commercial ait été atteint ou non.

Exemples de projets logiciels potentiellement admissibles

Certains scénarios peuvent contenir des travaux de développement expérimental lorsqu’ils dépassent l’application de pratiques connues.

• Concevoir une architecture capable de soutenir un volume de données ou une charge qui dépasse les limites démontrées des solutions disponibles.
• Développer un algorithme de traitement, d’optimisation ou de sécurité lorsque les approches connues ne permettent pas d’atteindre les caractéristiques techniques visées.
• Adapter un modèle d’intelligence artificielle à des données limitées, bruitées ou non standard au moyen d’une série d’hypothèses et d’expérimentations.
• Intégrer des systèmes dont les interactions imprévisibles créent une incertitude au niveau du système et exigent de modifier les technologies sous-jacentes.
• Tenter de réduire une latence, une consommation de mémoire ou un taux d’erreur au-delà de ce que permettent les méthodes publiquement accessibles.

Dans chaque cas, l’admissibilité dépend des faits. L’équipe doit identifier la limite de la technologie disponible, formuler ses hypothèses, tester les approches et tirer des conclusions des résultats. L’étiquette « innovant » ne remplace pas cette démonstration.

Ce qui n’est généralement pas admissible

Toutes les activités de développement ne se qualifient pas, même lorsqu’elles demandent beaucoup de temps ou d’expertise.

Activité	Analyse habituelle
Développement expérimental d’un nouvel algorithme pour dépasser une limite technologique documentée	Potentiellement admissible
Configuration ou personnalisation d’un progiciel de gestion intégré standard	Généralement non admissible
Intégration de logiciels existants avec des méthodes connues et sans interaction imprévisible	Généralement non admissible
Expérimentation sur une architecture pour soutenir une charge que les solutions disponibles ne peuvent atteindre	Potentiellement admissible
Création d’un site Web avec un système de gestion de contenu existant	Généralement non admissible
Correction courante de bogues, contrôle de qualité ou essais de routine	Généralement non admissible
Formation de l’équipe ou embauche d’un spécialiste pour appliquer un savoir-faire existant	Non admissible en soi

Une solution inconnue de votre équipe peut néanmoins faire partie des connaissances accessibles au public ou être maîtrisée par un professionnel compétent. Dans ce cas, le travail relève normalement de l’ingénierie ou de la programmation courante.

À l’inverse, l’intégration de technologies connues peut parfois créer une incertitude au niveau du système lorsque leurs interactions sont imprévisibles et que les sous-systèmes doivent être modifiés pour atteindre les spécifications. Cette conclusion doit être étayée par les faits et les expérimentations.

Pourquoi l’analyse diffère de la RS&DE manufacturière

La RS&DE s’applique à tous les secteurs, mais l’incertitude technologique ne se manifeste pas de la même façon. En fabrication, elle peut concerner un matériau, une tolérance mécanique, un procédé physique ou le passage à une nouvelle échelle.

En développement logiciel, elle se trouve souvent dans une architecture, un algorithme, une interaction entre systèmes ou une contrainte mesurable de performance. Ces décisions deviennent difficiles à reconstituer si l’équipe ne consigne que les fonctionnalités livrées.

Notre guide de la RS&DE pour le secteur manufacturier illustre ce contraste avec des exemples propres aux procédés et aux équipements.

L’approbation préalable de l’ARC pour un projet planifié

Depuis le 1er avril 2026, certaines entreprises peuvent utiliser le processus facultatif d’approbation préalable de l’ARC. Il permet de demander une détermination technique avant de commencer les travaux ou d’engager les coûts du projet.

Le processus vise les sociétés privées sous contrôle canadien, les sociétés canadiennes et les sociétés de personnes canadiennes qui ont un revenu brut annuel inférieur à 25 millions de dollars et qui sont en règle avec l’ARC. Une demande peut couvrir jusqu’à trois projets, et l’ARC indique rendre sa décision dans les huit semaines suivant la demande complète.

Une approbation peut être valide jusqu’à trois ans. Elle ne dispense toutefois pas l’entreprise de conserver ses pièces justificatives, de déclarer correctement les dépenses et de respecter les conditions applicables à la demande annuelle.

RS&DE et CDAE-IA pour un même projet TI

Une entreprise québécoise peut parfois être touchée à la fois par la RS&DE et le CDAE-IA. Ces mesures n’évaluent toutefois pas les activités selon les mêmes critères.

La RS&DE porte sur les travaux entrepris pour réaliser un avancement scientifique ou technologique au moyen d’une investigation systématique. Le CDAE-IA repose plutôt sur l’admissibilité de l’entreprise, des activités et des employés aux règles québécoises applicables aux affaires électroniques intégrant significativement l’intelligence artificielle.

La présence d’un même employé ou d’un même projet dans les deux analyses exige une ventilation rigoureuse. Les aides gouvernementales doivent être déclarées et les mêmes dépenses ne doivent pas être traitées comme si aucune autre aide n’avait été reçue. Le comparatif entre la RS&DE et le CDAE-IA explique les différences et les interactions à examiner.

Pour faire analyser votre portefeuille de projets logiciels, discutez avec un spécialiste.

Documentation à conserver pour un projet logiciel

Les éléments probants produits pendant les travaux aident à démontrer le problème, les hypothèses, les essais et les connaissances acquises. La documentation peut comprendre :

• des notes techniques décrivant la limite initiale et les raisons pour lesquelles les approches connues étaient insuffisantes;
• les hypothèses et les critères mesurables utilisés pour évaluer chaque approche;
• les résultats d’essais, analyses comparatives, journaux, mesures de performance et prototypes;
• l’historique des tentatives, y compris les échecs et les raisons des changements de direction;
• les commits de code, demandes de fusion, tickets et décisions d’architecture datés;
• le temps consacré par chaque personne aux travaux d’investigation, séparé de la mise en œuvre courante.

Les commits et les tickets sont utiles, mais ils ne prouvent pas automatiquement l’admissibilité. Leur contenu doit permettre de comprendre l’incertitude technologique et la progression de l’investigation.

Un suivi léger pendant chaque sprint est généralement plus fiable qu’une reconstitution plusieurs mois plus tard au moment de préparer le formulaire T661. Notre guide de documentation RS&DE présente des pratiques pour structurer cette collecte.

Évaluer vos projets logiciels avant la demande

Un projet logiciel peut être admissible même s’il échoue, et un produit commercialement réussi peut ne contenir aucun travail de RS&DE. L’analyse porte sur la raison et la méthode des travaux, non sur la nouveauté commerciale du produit.

Commencez par isoler les périodes où l’équipe ne pouvait pas résoudre une limite avec les connaissances disponibles. Reliez ensuite chaque hypothèse aux essais, aux résultats et aux nouvelles connaissances obtenues. Les tâches de développement courant doivent rester séparées.

Pour faire évaluer vos projets et structurer votre documentation avant la prochaine demande, réservez une consultation avec Avinova ou consultez notre page consacrée au crédit d’impôt RS&DE.

FAQ

Un projet d’intelligence artificielle est-il automatiquement admissible à la RS&DE?

Non. L’utilisation de l’intelligence artificielle ne crée pas automatiquement une incertitude technologique. L’application d’un modèle ou d’une méthode existante avec des pratiques connues relève généralement du développement courant. Un projet peut contenir de la RS&DE si l’équipe tente, par expérimentation ou analyse, de générer de nouvelles connaissances pour surmonter une limite technologique que les connaissances disponibles ne permettent pas de résoudre.

Les échecs de développement peuvent-ils faire partie d’une demande RS&DE?

Oui. Le succès du produit ou de l’hypothèse n’est pas une condition d’admissibilité. Un essai infructueux peut produire une nouvelle connaissance en démontrant qu’une approche ne fonctionne pas dans les conditions étudiées. L’entreprise doit néanmoins montrer que les travaux visaient un avancement et qu’ils ont été menés par une investigation systématique.

Les commits Git et les tickets suffisent-ils comme documentation?

Ils constituent des éléments probants utiles lorsqu’ils sont produits au fil des travaux, mais ils ne suffisent pas toujours à eux seuls. Ils devraient être accompagnés d’information qui relie le problème technologique, les hypothèses, les essais, les résultats et les conclusions. Des titres de tâches génériques comme « corriger la performance » expliquent rarement pourquoi les travaux étaient nécessaires ou ce que l’équipe a appris.

Combien de temps faut-il pour documenter un projet logiciel en RS&DE?

L’effort dépend de la taille du projet, mais quelques notes structurées prises au moment des décisions réduisent fortement le travail de fin d’année. L’objectif n’est pas de produire un rapport quotidien volumineux. Il est de conserver une trace contemporaine suffisante pour reconstituer l’incertitude, les hypothèses, les expérimentations et les conclusions.