La plupart des entreprises logicielles savent que la RS&DE existe. Bien moins savent où se situent réellement les frontières du programme. Le résultat : les équipes excluent régulièrement du travail admissible de leurs demandes, ou pire, incluent du travail qui attire l’attention de l’ARC et affaiblit l’ensemble du dépôt.
Les critères de l’ARC ne sont pas arbitraires. Une fois que vous comprenez la logique sous-jacente, le pattern devient clair. Cet article traduit le cadre d’admissibilité de l’ARC en termes de développement logiciel : ce qui se qualifie, ce qui ne se qualifie pas, et les catégories de travail que les équipes logicielles sous-évaluent systématiquement.
Les trois catégories de travail admissible
L’ARC définit le travail admissible à la RS&DE selon trois types.
La recherche fondamentale fait avancer les connaissances scientifiques ou technologiques sans application pratique spécifique en vue. Pratiquement aucune entreprise logicielle commerciale ne fait ça.
La recherche appliquée fait aussi avancer les connaissances, mais avec une application pratique spécifique comme cible. Certaines entreprises de technologie profonde se qualifient ici : architectures ML nouvelles, nouvelles méthodes cryptographiques, compilateurs personnalisés. Le seuil est élevé.
Le développement expérimental est là où la grande majorité des demandes RS&DE logicielles se situent. L’ARC le définit comme du travail effectué pour réaliser un avancement technologique dans le but de créer de nouveaux, ou d’améliorer les, matériaux, dispositifs, produits ou procédés existants. Il inclut l’investigation systématique menée par voie d’expérience ou d’analyse.
Cette dernière phrase compte. Pas juste construire quelque chose de difficile. Pas juste faire du travail que vous n’avez jamais fait avant. Investiguer un problème technologique que vous ne savez pas comment résoudre, en utilisant une approche structurée, et produire des résultats documentés.
Le test d’admissibilité en trois parties
Pour qu’une activité se qualifie sous le développement expérimental, l’ARC applique trois critères simultanément. Les trois doivent être présents.
1. Incertitude technologique
Il doit y avoir un problème technologique où la solution n’est pas connue ou déterminable par un praticien qualifié à travers les connaissances scientifiques ou technologiques généralement disponibles.
Ce critère est celui qui fait trébucher le plus de demandes. « Nous n’étions pas sûrs que ça marcherait » n’est pas de l’incertitude technologique. « Un ingénieur qualifié appliquant les techniques connues ne pouvait pas prédire le résultat » l’est.
Le test est objectif, pas subjectif. Peu importe que votre équipe ne connaissait pas la réponse. Ce qui compte est si la réponse était connaissable à partir des connaissances publiques existantes.
L’incertitude peut aussi émerger au niveau du système. Une décision de la Cour de l’impôt de 2024 (DAZZM Inc. c. Sa Majesté le Roi, 2024 CCI 129) a confirmé que l’intégration de composants connus multiples peut elle-même créer de l’incertitude technologique quand leurs interactions produisent un comportement imprévisible.
2. Investigation systématique
Le travail doit suivre un processus structuré : formuler des hypothèses, les tester, observer les résultats, tirer des conclusions. L’ARC utilise spécifiquement la phrase « expérience ou analyse ».
« Nous avons essayé plein de trucs et finalement ça a marché » ne satisfait pas l’investigation systématique. « Nous avons formulé trois approches basées sur la recherche disponible, testé chacune contre un benchmark défini, éliminé deux à cause de contraintes de latence, et modifié la troisième pour adresser des cas limites non couverts dans la littérature existante » oui.
3. Avancement technologique
Le travail doit faire avancer la base générale de connaissances dans le domaine, pas juste votre produit spécifique.
En pratique, « avancement » ne requiert pas un article publié ou une invention commercialement nouvelle. Il requiert que votre investigation ait produit de nouvelles connaissances techniques.
Une expérience échouée se qualifie. Découvrir qu’une approche particulière ne fonctionne pas sous certaines conditions fait avancer les connaissances. L’ARC n’exige pas le succès. Seulement une investigation véritable.
Ce qui se qualifie en développement logiciel
La politique d’admissibilité de l’ARC identifie trois scénarios.
Scénario 1 : Le logiciel lui-même est l’objet novel. Nouveaux algorithmes où aucune solution connue n’existe. Nouvelles structures de données. Architectures de modèles ML adressant des limitations des approches existantes. Implémentations de compilateurs personnalisés.
Scénario 2 : Le logiciel combiné avec du matériel crée un produit technologiquement avancé. Systèmes de contrôle embarqués. Implémentations de réseaux de neurones personnalisées pour du matériel spécialisé.
Scénario 3 : Logiciel développé pour permettre d’autre travail RS&DE admissible. Cadres de test personnalisés, environnements de simulation créés spécifiquement pour un projet RS&DE. Souvent oublié : l’outillage que vous construisez pour faire la recherche peut se qualifier même s’il n’est jamais livré aux clients.
Activités qui se qualifient couramment
Développement d’algorithmes novateurs. Quand aucun algorithme connu ne résout votre problème dans des limites de performance acceptables, et que votre équipe mène une investigation originale pour en développer un.
Nouvelles architectures de données. Si votre équipe a conçu un modèle de données ou une architecture de stockage qui adresse une contrainte qu’aucune approche existante ne pouvait résoudre.
Développement de modèles ML à la frontière de la recherche. Entraîner un modèle avec des techniques établies sur vos données n’est généralement pas de la RS&DE. Développer une nouvelle méthode d’entraînement ou investiguer un comportement inattendu du modèle peut se qualifier.
Optimisation de performance au-delà des techniques documentées. Ajuster la performance avec des méthodes de profilage établies ne se qualifie pas. Investiguer pourquoi votre système ne rencontre pas les cibles après que toutes les techniques connues aient été appliquées peut se qualifier.
Ce qui ne se qualifie pas
Corrections de bugs routinières. Le débogage utilisant des méthodes diagnostiques établies ne se qualifie pas.
Développement standard de fonctionnalités avec des techniques connues. Construire des fonctionnalités avec des cadres et patterns architecturaux établis ne se qualifie pas, quelle que soit la complexité.
Travail UI et UX. L’ARC exclut explicitement le design, l’esthétique et le travail d’expérience utilisateur.
Collecte de données et recherche de marché. Le travail d’ingénierie qui collecte fondamentalement des données sur le comportement des utilisateurs ne se qualifie pas.
Appliquer des outils IA/ML avec des méthodes existantes. Brancher des données dans une architecture de modèle connue, ajuster un modèle de fondation sans adresser un problème technique novateur est de la pratique standard.
Assurance qualité et tests routiniers. Les processus AQ standard ne se qualifient pas.
Déploiement et maintenance post-développement. La configuration d’infrastructure, la configuration CI/CD, la surveillance en production et la maintenance routinière sont explicitement exclues.
Dépenses admissibles : ce que l’ARC vous permet de réclamer
Salaires RS&DE. Salaires et avantages payés aux employés directement engagés dans le travail RS&DE. Les allocations de temps doivent être supportées par des registres.
Matériaux RS&DE. Le coût des matériaux consommés ou transformés dans le processus RS&DE. Pour la plupart des entreprises logicielles, c’est minimal.
Contrats RS&DE. Si vous avez contracté des tiers pour effectuer du travail RS&DE admissible, 80 % de ces coûts sont des dépenses admissibles.
Frais généraux. La méthode de remplacement applique un multiplicateur de 55 % à votre base salariale RS&DE. La méthode traditionnelle permet de réclamer des frais généraux spécifiques. Le choix est fait sur le T661 et est contraignant pour l’année fiscale.
Les activités que la plupart des entreprises logicielles manquent
Le temps des développeurs sur les approches échouées. Les ingénieurs qui ont passé des semaines à investiguer un problème qui a ultimement requis d’abandonner la première approche ne signalent souvent pas ce travail. Mais l’investigation d’un cul-de-sac est souvent le travail le plus admissible du projet.
L’outillage interne construit pour permettre la recherche. Si votre équipe a construit un environnement de simulation ou un banc d’essai personnalisé parce qu’aucun outil disponible ne pouvait faire ce dont vous aviez besoin, ce travail d’outillage peut se qualifier.
Le travail d’intégration avec une véritable incertitude au niveau du système. Depuis la décision DAZZM, si l’intégration de composants connus par votre équipe a produit des effets d’interaction qui ont nécessité une investigation originale, ce travail peut se qualifier au niveau du système.
De l’admissibilité à la documentation
Savoir ce qui se qualifie est l’étape un. L’étape deux est de le capturer d’une façon qui survit à un examen de l’ARC. L’échec courant : les entreprises font du travail admissible toute l’année, puis passent des semaines au moment du dépôt à essayer de reconstruire des narratifs techniques de mémoire. La reconstruction est coûteuse, souvent incomplète, et produit de la documentation que l’ARC traite avec scepticisme.
L’alternative est la capture continue : signaler le travail admissible au fur et à mesure, construire les narratifs techniques progressivement, arriver au moment du dépôt avec de la documentation qui reflète ce qui s’est réellement passé.
Vous voulez voir combien de travail admissible votre équipe laisse sur la table ? Parlez à notre équipe pour automatiser votre documentation RS&DE.