Point clé
Les travaux d'IA et d'automatisation dans une entreprise peuvent être admissibles à la RS&DE, mais seulement la partie réellement incertaine, et seulement si vous consignez hypothèses, bases de référence, résultats et heures pendant les travaux. Tout reconstituer au moment de la réclamation, c'est laisser de l'argent sur la table.
Un directeur financier approuve un budget pour automatiser la saisie des commandes. Douze mois plus tard, le système est en production, l’équipe en est fière et le dossier de fin d’année part chez le comptable. À un moment donné, le comptable demande si une partie des travaux relevait de la R&D. Personne n’en est certain. Les ingénieurs qui ont mené les expériences difficiles sont passés au projet suivant, les notebooks sont à moitié effacés, et la seule trace de l’échec des deux premières approches est un fil Slack datant de mars.
Cette entreprise a peut-être réalisé des travaux admissibles à la RS&DE (recherche scientifique et développement expérimental). Elle va maintenant passer des semaines à essayer de le prouver, et la demande qu’elle déposera sera plus faible que ce que les travaux méritaient.
Le scénario est courant dans les entreprises canadiennes de taille moyenne qui investissent en IA et en automatisation. Elles traitent l’économie de la R&D comme une question fiscale qui arrive après le projet. Sa place est dans le plan de projet. Cet article s’adresse aux directeurs financiers et aux responsables des opérations qui pilotent des programmes d’IA et veulent savoir quelles parties peuvent être admissibles et comment conserver la preuve.
Pourquoi les programmes d’IA en entreprise produisent-ils des travaux admissibles à la RS&DE?
Parce que transformer un processus opérationnel désordonné en système d’IA fiable en production se heurte souvent à des problèmes que personne n’a encore résolus. Quand la réponse ne se trouve ni dans la documentation, ni dans la recherche publiée, ni dans le guide d’un fournisseur, l’équipe commence à expérimenter. C’est précisément ce type d’expérimentation que la RS&DE vise à soutenir.
La plupart des discussions sur la RS&DE au Canada ciblent les éditeurs de logiciels qui conçoivent des produits. Ce cadrage oublie un groupe important : les manufacturiers, distributeurs, assureurs, firmes d’ingénierie et entreprises de logistique qui intègrent l’IA à leurs propres opérations. Ces entreprises se voient rarement comme des acteurs de la R&D.
Pourtant, les obstacles sont bien réels. Les données sont incohérentes d’une façon qu’aucun fournisseur n’avait prévue. Les systèmes patrimoniaux n’ont jamais été conçus pour communiquer entre eux. La logique de décision vit dans la tête de trois employés seniors et dans un chiffrier de 40 onglets.
Que demande réellement le critère de la RS&DE?
L’Agence du revenu du Canada (ARC) évalue le développement expérimental selon trois critères, et les trois doivent être présents. Le guide des activités admissibles à la RS&DE les explique en détail. En bref :
Incertitude technologique. Un praticien compétent n’aurait pas pu savoir comment résoudre le problème avec les connaissances généralement accessibles. « On n’était pas sûrs que ça marcherait » ne suffit pas. « Les approches standard ont échoué, et rien de publié n’expliquait pourquoi », oui.
Investigation systématique. L’équipe a travaillé le problème au moyen d’hypothèses, d’expériences et de résultats consignés. Essayer des choses jusqu’à ce que quelque chose fonctionne ne compte pas.
Avancement technologique. L’investigation a produit de nouvelles connaissances, même si la réponse est qu’une approche ne fonctionne pas. Les expériences ratées peuvent être admissibles.
Appliquer ces critères à des travaux d’IA dans une entreprise demande du jugement. La ligne ne dépend pas de la difficulté ou du coût des travaux. Elle dépend de la possibilité de connaître la solution avant de commencer.
Où les travaux d’IA et d’automatisation peuvent-ils être admissibles?
Quelques cas de figure reviennent souvent quand des équipes construisent des systèmes d’IA en production sur de vraies données opérationnelles. Voyez-les comme des exemples. L’admissibilité d’un projet précis dépend des faits et de la qualité de leur documentation.
Comportement d’un modèle sur des données opérationnelles désordonnées
Prenons un distributeur qui utilise un modèle de langage pour extraire les lignes de bons de commande. Des milliers de clients envoient leurs bons sous forme de PDF numérisés, de courriels, de chiffriers et parfois de télécopies. Une approche d’extraction standard fonctionne sur les documents propres et s’effondre sur le reste : cellules fusionnées, quantités écrites à la main, unités qui changent en cours de document, numéros de pièce qui correspondent à trois codes différents selon le client.
Si l’équipe établit une base de référence avec l’approche standard, consigne qu’elle échoue par rapport à un seuil de précision défini, formule des hypothèses sur les causes et teste des solutions de rechange de façon structurée, cette investigation a la forme de la RS&DE. L’ARC voudra savoir si le mode d’échec et sa résolution étaient déjà décrits quelque part. Pour une combinaison précise de types de documents et de règles métier, ce n’est souvent pas le cas.
Problèmes d’intégration sans solution connue
Les entreprises fonctionnent avec des systèmes qui n’ont jamais été conçus pour l’IA. Un ERP de 2009 sans API. Un outil de planification qui exporte des CSV à heure fixe. Un processus de soumission qui repose sur une base de données Access maison.
Brancher un modèle sur ces systèmes relève habituellement de l’ingénierie courante. Pas toujours. Imaginez une couche de recherche qui fait remonter des enregistrements contradictoires provenant de deux systèmes de référence, et un modèle qui gère cette contradiction de façon imprévisible. Aucun des composants ne documente ce comportement à lui seul, et l’investigation de cette interaction peut être admissible. Une décision de la Cour canadienne de l’impôt de 2024 (DAZZM Inc. c. Sa Majesté le Roi) a confirmé que l’intégration de composants connus peut créer une véritable incertitude technologique à l’échelle du système. Le guide sur les demandes en IA et en apprentissage automatique approfondit cet angle.
Fiabilité sous de vraies contraintes opérationnelles
Un modèle exact 90 % du temps, c’est une démo. Un modèle qui doit avoir raison sur chaque soumission d’assurance, ou signaler quand il n’est pas sûr de lui, c’est un système de production. Passer de l’un à l’autre exige parfois d’étudier le calibrage, les seuils de confiance ou la logique de repli là où les techniques connues n’ont pas tenu sur votre distribution de données. Ces travaux peuvent être admissibles quand ils suivent une démarche systématique.
Outils conçus pour mener l’investigation
Si l’équipe construit un banc d’évaluation sur mesure ou une simulation d’un flux de production parce qu’aucun outil existant ne permettait de tester ce dont elle avait besoin, cet outillage peut être admissible à titre de soutien à l’investigation. On l’oublie facilement parce qu’il n’est jamais livré à personne.
Qu’est-ce qui n’est généralement pas admissible?
Utiliser l’IA, ce n’est pas la faire avancer, et les examinateurs de l’ARC font clairement la distinction. Déployer des outils, les configurer et retravailler des prompts, c’est appliquer une technologie connue. Ce côté de la ligne compte tout autant, parce que l’ARC examine de près les demandes liées à l’IA. L’article sur les changements à la RS&DE en 2026 explique pourquoi cet examen s’est resserré.
Les travaux généralement exclus de la RS&DE :
- Le déploiement d’outils prêts à l’emploi. Déployer un copilote d’un fournisseur, configurer les fonctions d’IA intégrées d’un CRM ou activer le traitement de documents dans une plateforme existante.
- La configuration et l’intégration courantes. Faire correspondre des champs, établir des connexions API qui fonctionnent comme documenté, construire des pipelines de données standard.
- L’itération de prompts en soi. Reformuler des prompts et tester des variantes pour améliorer les résultats, c’est appliquer un outil connu.
- Un ajustement fin standard qui fonctionne. Utiliser des méthodes documentées sur vos données et obtenir des résultats acceptables.
- La saisie, l’étiquetage et le nettoyage de données. Nécessaires, souvent coûteux, et pas du développement expérimental, sauf si la méthode de curation elle-même exigeait de résoudre une inconnue.
- La formation, la gestion du changement et l’adoption. Essentielles au résultat, mais hors programme.
- Le déploiement, la surveillance et la maintenance d’un système une fois qu’il fonctionne.
Un gros programme d’IA contient les deux types de travaux, souvent dans le même sprint. La partie admissible peut se limiter à quelques semaines d’investigation dans un chantier de plusieurs mois. Réclamez tout le programme comme de la R&D et vous vous retrouverez dans un examen impossible à gagner. N’en réclamez rien et vous laissez de l’argent bien réel sur la table.

Pourquoi reconstituer la preuve plus tard vous coûte-t-il cher?
Parce que les détails qui rendent une demande défendable s’effacent en quelques mois, et que les personnes qui les détiennent s’en vont. Les sociétés ont 18 mois après la fin de l’année d’imposition pour produire leur demande, alors rien ne semble pressé. C’est dans cet écart que la majeure partie de la valeur se perd.
La mémoire flanche vite. Les ingénieurs se souviennent qu’une approche a échoué. Ils se souviennent rarement des métriques, de la configuration ou de la raison du choix de l’hypothèse suivante. Ce sont exactement ces détails que l’examinateur demande.
Les gens partent. Dans les programmes d’IA en particulier, la personne qui a mené les expériences peut être un contractuel, un ingénieur d’un partenaire ou quelqu’un qui a quitté l’entreprise depuis. Ses notebooks partent avec elle.
La reconstitution coûte des heures facturables. Quelqu’un doit interroger l’équipe, fouiller l’historique des commits et des tickets, puis rebâtir un récit. Vos ingénieurs ou un conseiller sont payés pour ce temps, et le résultat est un document visiblement rédigé après coup.
Les récits reconstitués sont plus faibles. L’ARC indique de plus en plus clairement qu’elle veut des documents contemporains, c’est-à-dire créés pendant les travaux. Un récit monté un an plus tard avec des estimations d’heures approximatives est plus facile à contester et plus difficile à défendre lors d’une vérification de la RS&DE.
Certains travaux ne sont jamais réclamés. Les expériences ratées sont souvent la partie la plus admissible d’un projet et la moins susceptible d’être retenue. Si personne ne les a notées, elles disparaissent de la demande.

Comment saisir la preuve RS&DE pendant les travaux?
En intégrant quelques habitudes à la gestion des travaux d’IA dès le premier jour. Pas besoin d’un processus plus lourd. La plupart de ces habitudes sont celles qui font réussir les projets d’IA de toute façon.

Décrivez le problème avant de le résoudre
Quand l’équipe tombe sur quelque chose qui semble réellement inconnu, notez-le. Que cherchiez-vous à accomplir? Quelle est la cible, en chiffres? Que suggèrent les connaissances existantes, et pourquoi ne s’appliquent-elles pas ici? Une courte note dans le ticket suffit. Elle deviendra la section sur l’incertitude technologique du récit final.
Établissez une base de référence avec l’approche standard
Avant d’essayer quoi que ce soit de nouveau, appliquez la méthode évidente et consignez le résultat. « L’extraction standard a atteint 71 % de précision par champ, pour une exigence de 98 % sur notre jeu de documents », c’est une preuve. « On savait que ça ne marcherait pas », non.
Gardez hypothèses et résultats ensemble
Chaque expérience a sa ligne : l’hypothèse, ce qui a changé, ce qui a été mesuré, ce qui s’est passé, la conclusion. Les outils de suivi d’expériences en génèrent la majeure partie automatiquement. Un historique de tickets rigoureux fait aussi l’affaire.
Séparez l’investigation de la mise en œuvre
Menez les travaux incertains dans un volet distinct, avec leurs propres tickets ou étiquettes. Quand l’investigation aboutit et que l’équipe passe à la version de production, ce passage doit être visible dans les dossiers. Les heures admissibles deviennent faciles à repérer, et vous évitez de réclamer en trop.
Saisissez le temps dans les bonnes catégories
Les relevés de temps déterminent la valeur en dollars de la demande. Si les gens inscrivent « projet IA, 40 heures », personne ne pourra séparer plus tard le travail admissible du reste. Deux ou trois codes de temps par projet règlent l’essentiel du problème.
Rédigez le récit au fur et à mesure
Un résumé mensuel ou trimestriel sommaire de chaque investigation, écrit pendant que c’est frais, vaut mieux qu’un document soigné rédigé au moment de la demande. Le guide sur les descriptions techniques montre ce que l’ARC attend dans chaque section.
Rien de tout ça ne ralentit les travaux. Une équipe qui note ses hypothèses et mesure ses résultats par rapport à une base de référence livre de meilleurs systèmes d’IA. La trace documentaire est un sous-produit d’un projet bien mené.
Combien un programme d’IA peut-il récupérer grâce à la RS&DE?
Pour les sociétés privées sous contrôle canadien (SPCC), le crédit d’impôt fédéral à l’investissement pour la RS&DE est de 35 % et remboursable sur les dépenses admissibles jusqu’à un plafond annuel. Des changements fédéraux récents font passer ce plafond de 3 millions $ à 6 millions $. Au-delà du plafond, et pour les sociétés qui ne sont pas des SPCC, le taux est de 15 % et non remboursable. Vérifiez avec votre conseiller comment le plafond actuel s’applique à votre année d’imposition, puisque les dates d’entrée en vigueur comptent.
Les dépenses admissibles comprennent les salaires des personnes qui font les travaux admissibles, avec une majoration pour frais généraux selon la méthode de remplacement. Si un partenaire canadien sans lien de dépendance réalise des travaux admissibles pour vous, vous pouvez généralement inclure 80 % de la partie admissible de ce que vous lui versez. Les travaux réalisés hors du Canada ne comptent pas. Le guide sur les sous-traitants et le développement externalisé explique les règles, y compris comment rédiger les contrats pour appuyer la demande.
Ce dernier point compte si vous travaillez avec un partenaire externe en IA. Qui dirige les travaux, où ils sont réalisés et comment le contrat est structuré influencent tous votre capacité à les réclamer. Réglez la question avant le début du mandat.
Qu’est-ce qui change pour les entreprises québécoises?
Le Québec ajoute ses propres crédits d’impôt remboursables pour la R&D à la demande fédérale, si bien que les entreprises québécoises qui font des travaux admissibles récupèrent souvent nettement plus que le seul crédit fédéral. Le Québec a aussi refondu le CDAE (son crédit d’impôt pour le développement des affaires électroniques) en une version axée sur l’intégration de l’IA dans les processus d’affaires, pour les années financières commençant après le 31 décembre 2025. Ce crédit a ses propres critères d’admissibilité, dont un seuil de temps par employé, et ses propres règles d’interaction avec les autres crédits réclamés sur les mêmes salaires.
Les taux et les règles des deux ont bougé dans les récents budgets du Québec. Voyez-y une raison d’en parler tôt avec votre conseiller, pas un chiffre à inscrire dans un budget.
Qui devrait produire la demande de RS&DE pour vos travaux d’IA?
C’est à vous de décider. Votre équipe des finances, votre comptable externe ou un conseiller spécialisé en RS&DE peuvent tous la produire, et ce choix ne devrait pas dépendre de qui construit vos systèmes d’IA.
Voici comment on s’y prend. Quand nous menons un mandat d’IA avec un client canadien, la saisie de la preuve fait partie de la façon de travailler. Hypothèses, bases de référence, résultats d’expériences et répartition du temps sont consignés au fil du projet. En fin d’année, ce dossier vous appartient, tout comme les systèmes et le code. Remettez-le au comptable ou au conseiller en qui vous avez déjà confiance. Si vous voulez un logiciel pour l’organiser en documentation prête pour l’ARC, Chrono R&D le fait, mais rien dans le mandat ne dépend de son utilisation.
Nous ne promettrons pas qu’un projet précis est admissible. Ça dépend des faits et de l’examen de l’ARC. Ce que nous ferons, c’est nous assurer que si des travaux admissibles ont lieu, il en existe un dossier propre et contemporain.
Que devrait ajouter un directeur financier au lancement d’un projet d’IA?
Trois questions. Le changement est mineur, et il rapporte au moment de la demande.
- Quelles parties de ces travaux risquent de comporter de véritables inconnues techniques?
- Qui consigne les hypothèses, les bases de référence, les résultats et le temps pour ces parties?
- Qui produit la demande, et cette personne sait-elle que ce projet existe?
Répondez-y dès le départ et vous serez en bien meilleure position que l’entreprise qui reconstitue une année de travail à partir de fils Slack.
Questions fréquentes
Est-ce que l’utilisation de ChatGPT ou d’un copilote dans mon entreprise est admissible à la RS&DE?
Non. Déployer ou configurer des outils d’IA prêts à l’emploi, c’est appliquer une technologie connue. La RS&DE couvre l’investigation de problèmes techniques que les connaissances existantes ne permettaient pas de résoudre, par exemple rendre un modèle fiable sur des données où les méthodes standard ont échoué.
Les expériences d’IA ratées peuvent-elles être admissibles à la RS&DE?
Oui. L’avancement technologique inclut le fait d’apprendre qu’une approche ne fonctionne pas, à condition que l’investigation ait été systématique. Les expériences ratées sont souvent la partie la plus admissible d’un projet, mais seulement si quelqu’un a consigné l’hypothèse, le montage et le résultat.
Combien de temps ai-je pour produire une demande de RS&DE pour des travaux d’IA?
Les sociétés ont 18 mois après la fin de l’année d’imposition. Le délai n’est pas le problème. La qualité de la preuve se dégrade bien avant, alors consignez tout pendant le projet.
Si vous planifiez des travaux d’IA dans vos opérations et voulez intégrer l’économie de la R&D dès la première semaine, prenez rendez-vous avec Chrono Innovation. Nous examinerons le problème que vous voulez résoudre, la façon dont nous structurerions un premier mandat en production autour de ce problème et la place de la saisie de la preuve. Pour choisir ce premier problème, lisez comment prouver la valeur de l’IA sur un seul problème.