Le code source n’est pas, à lui seul, une preuve de RS&DE. C’est une pièce du dossier, qui prend de la valeur lorsqu’elle démontre une investigation systématique pour lever une incertitude technologique. Le guide du formulaire T661 de l’Agence du revenu du Canada (ARC) mentionne d’ailleurs le code source parmi les documents à conserver, avec les journaux de développement et les pièces financières. Voici comment l’utiliser, le structurer et le relier à votre demande.
En bref
- ✅ Le code source, les journaux de développement et les pièces financières font partie des documents à conserver pour répondre à un examen de l’ARC.
- ✅ La programmation peut être admissible comme travail de soutien, à condition d’appuyer directement et proportionnellement des travaux de RS&DE.
- ❌ Du code livré ne prouve pas l’avancement technologique: il faut montrer les hypothèses, les essais et les résultats.
- ✅ Le taux de base du crédit d’impôt à l’investissement est de 15 %; certaines sociétés privées sous contrôle canadien peuvent obtenir 35 %.
- ✅ Documentez pendant les travaux, pas des mois plus tard au moment de produire le T661.
Table des matières
- Ce que « code source » veut dire dans une demande de RS&DE
- Le logiciel est-il admissible? Travail principal et travail de soutien
- Quel code source conserver, et sous quelle forme
- Exemple: ce qu’un dossier logiciel solide raconte
- Documenter pendant les travaux, pas après
- Du code au crédit: formulaires, taux et échéances
- Les erreurs les plus fréquentes avec le code source
- Notre point de vue
- Faire examiner votre dossier avec HLP
- Questions fréquentes
- Sources
Ce que « code source » veut dire dans une demande de RS&DE
Quand on cherche « code source RS&DE », on pose en général l’une de ces trois questions. Mon code peut-il être admissible? Quelle partie de mon code dois-je montrer à l’ARC? Comment prouver que mon équipe a fait de la recherche et pas seulement du développement courant?
La réponse commune: l’ARC n’évalue pas la qualité ou l’élégance de votre code. Elle évalue les travaux qui l’ont produit. Le programme vise les travaux qui cherchent un avancement scientifique ou technologique et qui comprennent une investigation systématique par expérimentation ou analyse. Le code est la trace concrète de cette démarche, un peu comme un cahier de laboratoire l’est en chimie.
Qui peut demander le crédit
Les sociétés, les particuliers, les fiducies et les sociétés de personnes qui effectuent des travaux de RS&DE au Canada peuvent demander une déduction sur le revenu et un crédit d’impôt à l’investissement. Une jeune pousse qui développe une plateforme, un fabricant qui écrit le micrologiciel d’un nouvel appareil et une biotech qui construit un modèle d’analyse de données peuvent donc tous se poser la question.
Le logiciel est-il admissible? Travail principal et travail de soutien
La programmation peut entrer dans une demande de deux façons. Elle peut constituer le cœur des travaux, lorsque vous cherchez à résoudre un problème technologique que l’état des connaissances ne permet pas de résoudre. Elle peut aussi servir de soutien à des travaux de RS&DE.
L’ARC précise que la programmation informatique peut être admissible comme travail de soutien si elle appuie directement et proportionnellement des travaux de RS&DE. Ses lignes directrices ajoutent que les travaux de soutien ne sont pas eux-mêmes de la RS&DE, mais peuvent en faire partie s’ils sont proportionnels aux besoins et appuient directement des travaux admissibles.
Concrètement, deux mots comptent: « directement » et « proportionnellement ». Si vous écrivez un banc d’essai pour tester une hypothèse d’architecture, le lien est direct. Si vous consacrez des semaines à une interface d’administration sans rapport avec l’incertitude, le lien ne tient pas.
Ce qui est exclu, même si cela demande beaucoup de code
Les lignes directrices de l’ARC écartent notamment les modifications de style, le contrôle normal de la qualité, l’étude de marché et la production commerciale. L’acquisition de connaissances existantes n’est pas admissible non plus.
En développement logiciel, cela donne par exemple:
- ❌ Intégrer une bibliothèque connue selon sa documentation officielle.
- ❌ Refaire l’interface visuelle d’une application existante.
- ❌ Corriger des bogues courants et exécuter des tests de routine.
- ✅ Tenter d’atteindre une performance ou une fiabilité que les approches connues ne permettent pas, après avoir formulé des hypothèses et en avoir éprouvé plusieurs.
- ✅ Concevoir un algorithme ou une architecture dont le comportement ne peut être prévu sans expérimentation.
Quel code source conserver, et sous quelle forme
Le guide du T661 indique qu’il faut conserver les parties du formulaire détaillant les travaux techniques, le code source, les journaux de développement et les pièces financières justificatives. Ces documents doivent établir la démarche systématique et le lien direct avec les travaux de RS&DE.
Un dépôt de code bien tenu répond déjà à une bonne partie de cette exigence. Voici ce que nous recommandons de rendre facile à retrouver:
- L’historique des versions: les validations (commits) datées, avec des messages qui décrivent l’essai tenté, pas seulement « correctif ».
- Les branches expérimentales: celles qui ont échoué comptent autant que celles qui ont réussi, parce qu’elles prouvent l’incertitude.
- Les prototypes et bancs d’essai: le code écrit pour mesurer, comparer ou valider une hypothèse.
- Les résultats de tests et de mesures: temps de réponse, taux d’erreur, consommation de ressources, avant et après chaque tentative.
- Les journaux de développement: notes techniques, comptes rendus de réunions d’équipe, tableaux de suivi des problèmes.
- Les liens avec les heures et les salaires: qui a travaillé sur quoi, et à quel moment.
Relier le code aux hypothèses
Un fichier de code seul dit peu à une personne qui n’a pas vécu le projet. Ce qui parle, c’est la chaîne complète: le problème technologique, l’hypothèse, l’essai, le résultat, la décision suivante. Le code source en est la dernière maille, pas la première.
Une bonne pratique simple: dans votre outil de suivi, associez chaque ticket expérimental à un identifiant de projet de RS&DE et à l’incertitude qu’il cherche à lever. Lorsque vient le temps de rédiger la description technique, vous n’avez plus à reconstituer une histoire de mémoire.
Exemple: ce qu’un dossier logiciel solide raconte
Imaginons une entreprise qui développe un moteur de traitement d’images pour l’inspection de pièces industrielles. L’exemple est illustratif et ne représente pas un client.
Incertitude technologique. Les méthodes de détection connues ne permettent pas d’atteindre le taux de détection visé sur des surfaces réfléchissantes, sans un temps de traitement incompatible avec la cadence de la ligne.
Hypothèses. L’équipe en formule trois: un prétraitement adaptatif, un modèle plus léger entraîné sur des données synthétiques, et une exécution partielle sur matériel dédié.
Essais. Chaque hypothèse fait l’objet d’une branche, d’un banc d’essai et d’un jeu de mesures. Deux échouent, l’une réussit partiellement.
Résultat et avancement. La combinaison de deux approches atteint la cible, et l’équipe consigne ce qu’elle a appris sur les limites de chacune.
Dans ce scénario, le code source de chaque branche, les mesures et les notes de l’équipe forment un dossier cohérent. Sans ces éléments, le même projet ressemblerait à une simple livraison de produit.
Documenter pendant les travaux, pas après
Le guide de l’ARC mentionne aussi l’Application d’auto-évaluation et d’apprentissage, qui peut aider à identifier et à rassembler les renseignements à l’appui d’un projet. C’est un bon point de départ pour structurer votre réflexion avant de rédiger.
La difficulté réelle est d’ordre organisationnel. Les développeurs veulent coder, les dirigeants veulent livrer, et la documentation de RS&DE passe en dernier. Une démarche claire de gestion de projet pour dirigeants aide à fixer les responsabilités, les jalons et les habitudes de consignation dès le début des travaux, ce qui rend la tenue du dossier de RS&DE beaucoup plus naturelle.
Quelques habitudes qui fonctionnent:
- Désigner une personne responsable de la documentation technique par projet.
- Prévoir quinze minutes à la fin de chaque sprint pour noter les hypothèses testées et les résultats.
- Ne jamais supprimer les branches expérimentales abandonnées sans en archiver l’historique.
- Conserver les versions des spécifications et les échanges techniques où l’équipe constate qu’une approche ne fonctionne pas.
Pour approfondir la tenue de dossiers dans un contexte de jeune entreprise, consultez notre article sur la RS&DE pour les startups. Pour la partie financière, notre texte sur les dépenses de R&D explique comment les salaires, les matériaux et les contrats se rattachent à vos projets.
Du code au crédit: formulaires, taux et échéances
Les formulaires
La demande devrait être accompagnée du T661 et de l’annexe T2SCH31 pour les sociétés, ou du T2038(IND) pour les particuliers, selon la politique de l’ARC sur les exigences de production. Le code source ne se joint pas d’office au dépôt: vous le conservez et le produisez si l’ARC le demande lors d’un examen.
L’échéance
La date limite est de 12 mois après l’échéance de production de la déclaration de revenus, soit généralement 18 mois après la fin de l’année d’imposition pour une société, d’après la même politique. Calculez-la à partir de la fin de votre exercice et confirmez-la sur la page officielle avant de vous y fier.
Le taux du crédit
Selon la politique de l’ARC sur le crédit d’impôt à l’investissement, le taux de base est de 15 %. Certaines sociétés privées sous contrôle canadien et certaines entités admissibles dont l’année d’imposition commence après le 15 décembre 2024 peuvent obtenir 35 %. Votre taux dépend de votre structure, ce qui vaut la peine d’être validé avant de faire des projections.
Les crédits provinciaux
Des crédits provinciaux et territoriaux peuvent s’ajouter, et leur effet sur les dépenses admissibles au fédéral varie selon le crédit. L’ARC indique que des crédits de R&D sont offerts notamment au Québec, en Ontario, en Colombie-Britannique et au Yukon. Si votre équipe de développement est au Québec ou en Ontario, le calcul global mérite une attention particulière.
L’approbation préalable
L’ARC offre une approbation préalable facultative. Elle peut couvrir au maximum trois projets, et chaque approbation est valide pour une durée maximale de trois ans, d’après la page officielle du programme. Pour une entreprise qui prévoit plusieurs années de développement logiciel, c’est une option à évaluer.
Les erreurs les plus fréquentes avec le code source
- Tout verser au dossier. Un dépôt entier de plusieurs centaines de milliers de lignes n’aide personne. Choisissez les extraits qui illustrent l’expérimentation.
- Ne montrer que le produit final. Le résultat livré ne démontre pas l’incertitude. Les tentatives, si.
- Confondre complexité et incertitude. Un système complexe peut être entièrement prévisible pour un spécialiste. L’incertitude, c’est l’impossibilité de prévoir le résultat avec les connaissances disponibles.
- Attribuer du temps à des tâches sans lien. Les heures de programmation qui n’appuient pas directement les travaux admissibles fragilisent le reste de la demande.
- Attendre l’avis de vérification. Reconstituer un historique technique sous pression est long et rarement complet.
Notre point de vue
Depuis que nous accompagnons des entreprises dans leurs demandes de RS&DE, nous voyons le même scénario: une équipe de développement qui a fait un vrai travail d’investigation, mais dont le dossier raconte une simple livraison de produit. Le code existe, les essais ont eu lieu, et pourtant rien ne les relie à une incertitude technologique clairement énoncée.
C’est pourquoi notre équipe réunit des fiscalistes et des experts techniques. Les premiers connaissent les critères de l’ARC; les seconds comprennent ce que vos développeurs ont réellement tenté. Ensemble, nous traduisons un historique de code en description technique rigoureuse, puis nous la défendons si l’ARC pose des questions.
Notre conviction est qu’un dossier bien construit dès le départ vaut mieux qu’un dossier défendu à la dernière minute. Et si une vérification ou un litige survient, nous demeurons à vos côtés, jusqu’à la Cour canadienne de l’impôt s’il le faut.
Alexandre
Faire examiner votre dossier avec HLP
Vous avez du code, des essais et des notes, mais vous ne savez pas si le tout forme une demande solide? Nous rédigeons les descriptions de projets de R&D, maximisons la réclamation, offrons un suivi et un soutien lors de la vérification, et préparons les dossiers d’opposition. Pour une première évaluation, notre logiciel d’analyse d’admissibilité est offert à 0 $.
Présentez-nous votre projet sur hlp.ca et nous vous dirons comment structurer votre dossier.
Questions fréquentes
L’ARC exige-t-elle mon code source au moment de la demande?
Non, le code source n’est pas joint d’office au dépôt du T661. Vous devez toutefois le conserver avec les journaux de développement et les pièces financières, car il peut vous être demandé lors d’un examen. Prévoyez qu’il soit récupérable, daté et rattaché à vos projets.
Écrire du code suffit-il pour que mon projet soit admissible?
Non. Les travaux doivent viser un avancement scientifique ou technologique et comprendre une investigation systématique. Le développement courant, comme le contrôle normal de la qualité ou les modifications de style, est exclu.
Le travail de programmation de soutien peut-il être réclamé?
Oui, à certaines conditions. La programmation peut être admissible comme travail de soutien si elle appuie directement et proportionnellement des travaux de RS&DE. Elle ne l’est pas lorsqu’elle n’a pas de lien avec l’incertitude technologique visée.
Quel est le taux du crédit pour un projet logiciel?
Le taux dépend de votre entreprise, pas du type de projet. Le taux de base du crédit à l’investissement est de 15 %, et certaines sociétés privées sous contrôle canadien peuvent obtenir 35 %. Des crédits provinciaux peuvent s’ajouter, notamment au Québec et en Ontario.
Sources
- Quels sont les travaux admissibles, ARC
- Lignes directrices sur l’admissibilité des travaux, ARC
- T4088, guide du formulaire T661, ARC
- En quoi consistent les encouragements fiscaux pour la RS&DE, ARC
- Politique sur les exigences de production pour la RS&DE, ARC
- SR&ED Investment Tax Credit Policy, ARC
- Crédits d’impôt provinciaux et territoriaux pour la R&D, ARC
- Importance de la gestion de projet pour dirigeants
No responses yet