Une intégration ERP n’est pas admissible à la RS&DE parce qu’elle est complexe, coûteuse ou sur mesure. Elle l’est seulement si, dans son déroulement, vous avez dû résoudre une incertitude technologique par un travail systématique d’expérimentation. Configurer un progiciel connu, former les usagers ou migrer des données selon une méthode éprouvée relève de la mise en œuvre courante. Concevoir une couche d’intégration inédite, dont le comportement ne pouvait être prédit, peut en revanche répondre aux critères de l’Agence du revenu du Canada (ARC). Voici comment faire le tri, quoi documenter et comment déposer la demande.
En bref
- ✅ Le critère décisif est l’incertitude technologique, pas la présence d’un ERP: il faut un obstacle technique dont la solution n’était pas connue au départ.
- ❌ La configuration standard, la formation, la documentation utilisateur et la simple migration de données ne sont pas des travaux admissibles en soi.
- 📁 Les preuves (hypothèses, essais, échecs, personnes, dates, calcul des dépenses) se conservent pendant le projet, pas après coup.
- 🗓️ La demande se produit avec le formulaire T661 et l’annexe T2SCH31, au plus tard 18 mois après la fin de l’année d’imposition.
Table des matières
- Ce que l’ARC entend par travaux admissibles
- Quand une intégration ERP peut-elle être admissible?
- Les activités qui sont exclues ou à surveiller
- Quelles dépenses peut-on réclamer?
- Les preuves à conserver pendant le projet
- Préparer et déposer la demande
- Comment l’ARC examine un projet ERP
- Notre point de vue
- Faire évaluer votre projet avec HLP
- Questions fréquentes
- Sources
Ce que l’ARC entend par travaux admissibles
Le programme de RS&DE offre des incitatifs fiscaux pour des travaux réalisés au Canada qui visent un avancement scientifique ou technologique, par une recherche systématique. L’ARC évalue l’admissibilité selon la capacité du projet à surmonter une incertitude technologique.
Cette incertitude existe lorsqu’on ne sait pas, ou qu’il est incertain, qu’un résultat puisse être atteint, à cause d’une insuffisance de la base de connaissances scientifiques ou technologiques au début du projet. Selon les lignes directrices de l’ARC sur l’admissibilité, l’avancement correspond à la génération ou à la découverte de nouvelles connaissances, et l’admissibilité commence quand le résultat est incertain avec les connaissances disponibles.
Pour un projet ERP, cela change la question à poser. Ne demandez pas « avons-nous livré un ERP complexe? », mais « quel problème technique n’avions-nous aucun moyen connu de résoudre, et comment l’avons-nous résolu? ». Si ce concept vous est encore flou, notre article sur l’incertitude technologique le détaille avec des exemples.
Quand une intégration ERP peut-elle être admissible?
Un ERP du commerce est, par définition, une base de connaissances existante. Ses fonctions standard, ses connecteurs préconçus et les pratiques de déploiement documentées par l’éditeur ne constituent pas une incertitude. Le terrain de la RS&DE se situe ailleurs: là où les connaissances disponibles ne suffisent pas.
Voici des situations où une incertitude peut raisonnablement se poser, à évaluer au cas par cas:
- Synchronisation en temps réel de systèmes hétérogènes: relier un ERP à des automates industriels, à des capteurs ou à un système d’exécution de la fabrication, avec des contraintes de latence et d’intégrité que les interfaces existantes ne permettent pas de garantir.
- Automatisation d’un processus d’affaires complexe: par exemple un moteur de planification ou d’ordonnancement dont la logique doit être inventée, testée et itérée parce qu’aucune méthode connue ne donne le résultat visé.
- Développement personnalisé exigeant de l’expérimentation: algorithmes de tarification, de coûts de revient ou de traçabilité qui ne peuvent pas être paramétrés avec les outils de l’éditeur.
- Architecture d’intégration inédite: performance et fiabilité à très grand volume de transactions, avec des essais, des échecs et des changements d’approche documentés.
Dans chaque cas, ce qui compte n’est pas le produit livré, mais le cheminement: hypothèse, conception d’essais, résultats, ajustements, connaissances acquises.
Exemples comparés
| Situation | Probablement admissible? | Pourquoi |
|---|---|---|
| Installer et paramétrer les modules standard d’un ERP | ❌ Non | Méthode connue, aucun inconnu technique |
| Migrer des données historiques avec des outils d’import courants | ❌ Non | Travail de routine |
| Concevoir un moteur d’intégration entre l’ERP et des machines de production avec contraintes de temps réel inédites | ✅ Possible | Le résultat ne pouvait pas être prédit sans expérimentation |
| Élaborer un algorithme d’ordonnancement sans solution connue, validé par des prototypes successifs | ✅ Possible | Incertitude sur la faisabilité, essais itératifs |
| Rédiger les manuels d’utilisation et former le personnel | ❌ Non | Activité de soutien non admissible |
Ce tableau illustre une logique, pas une garantie. Deux projets d’apparence identique peuvent aboutir à des conclusions différentes selon ce qui était réellement connu au départ.
Les activités qui sont exclues ou à surveiller
Le guide T4088 de l’ARC distingue les activités techniques directement liées à la RS&DE de celles qui ne le sont pas. L’expérimentation, l’analyse et les travaux de soutien techniques peuvent être demandés; la préparation de manuels d’utilisation, elle, ne peut pas l’être.
Dans un projet ERP, soyez particulièrement attentif à ces éléments:
- ❌ la gestion de projet générale, les réunions de coordination avec l’éditeur et le suivi budgétaire;
- ❌ la formation des employés et la conduite du changement;
- ❌ la documentation utilisateur;
- ❌ la collecte des exigences d’affaires, lorsqu’elle ne sert pas à résoudre un problème technique;
- ❌ la mise en production d’une solution dont la méthode était déjà connue.
Un projet peut contenir à la fois des travaux admissibles et des travaux qui ne le sont pas. L’enjeu est alors d’isoler les premiers, avec précision, plutôt que de réclamer l’ensemble du projet. Une réclamation trop large attire l’attention et fragilise aussi la partie solide du dossier.
Si votre projet est surtout logiciel, notre article RS&DE logiciel explique comment l’ARC aborde ce type de travaux.
Quelles dépenses peut-on réclamer?
Selon le guide T4088, peuvent être réclamés les salaires des employés qui travaillent directement à la RS&DE, les matériaux consommés ou transformés et certains frais généraux supplémentaires directement liés aux travaux, selon la méthode traditionnelle ou la méthode de remplacement. Les salaires directement attribuables aux activités de RS&DE sont admis, à l’exclusion de la part patronale des avantages sociaux.
Pour un projet ERP, les dépenses typiques sont:
- Le temps des développeurs, architectes et analystes qui ont réellement participé aux essais et à la résolution du problème technique, au prorata du temps consacré aux travaux admissibles.
- Les matériaux et ressources consommés lors de l’expérimentation, lorsqu’ils respectent les règles de l’ARC.
- Les frais généraux rattachés directement aux travaux, selon la méthode retenue.
Un point d’attention: une facture globale d’intégrateur ne se réclame pas telle quelle. Le contrat avec un tiers obéit à des règles propres, et il faut pouvoir isoler la portion qui correspond à des travaux admissibles. Nous détaillons ces enjeux dans notre article sur les dépenses de R&D.
Quel est le taux du crédit?
Selon la politique de l’ARC sur les crédits d’impôt à l’investissement, les dépenses admissibles peuvent donner droit à un crédit généralement de 15 %, et dans certains cas de 35 % pour une société privée sous contrôle canadien (SPCC), sous réserve des conditions liées à l’entité et à l’année d’imposition. Les crédits provinciaux, notamment au Québec et en Ontario, s’ajoutent selon vos circonstances. Vérifiez votre taux avec un fiscaliste avant de bâtir un budget autour du crédit.
Les preuves à conserver pendant le projet
C’est ici que la plupart des dossiers ERP se jouent. Selon le guide du processus d’examen de la RS&DE, il faut conserver des preuves des travaux réalisés, des participants, du moment de leur réalisation et du calcul des dépenses, ainsi que des registres comptables organisés (grands livres, journaux, pièces justificatives). Ces preuves peuvent comprendre des documents produits pendant les travaux, des photos, des vidéos et d’autres artefacts.
Pour un projet informatique, cela se traduit concrètement par:
- 📝 des notes de conception qui énoncent le problème technique et les hypothèses de départ;
- 🧪 des journaux de tests, des résultats de benchmarks, des captures de configurations essayées puis abandonnées;
- 💻 l’historique du dépôt de code (commits, branches, revues) daté;
- 🎫 des tickets et comptes rendus de réunions techniques montrant les impasses et les changements de direction;
- ⏱️ des feuilles de temps qui distinguent les tâches de RS&DE des tâches courantes.
Selon les mêmes lignes directrices, il faut documenter ce qui était inconnu, les hypothèses testées, les essais et les connaissances acquises, et non seulement une liste de fonctionnalités livrées. Une démarche de cartographie des coûts et des flux techniques, comme la méthode d’audit des coûts IT, peut aider à retracer qui a travaillé sur quoi et à relier les dépenses aux systèmes concernés.
Un réflexe simple
À la fin de chaque sprint ou jalon, posez-vous trois questions et notez les réponses: qu’avons-nous essayé? Qu’est-ce qui a échoué et pourquoi? Qu’avons-nous appris que nous ne savions pas? Dix minutes par jalon valent mieux que des semaines de reconstitution lors d’une vérification.

Préparer et déposer la demande
La demande est produite au plus tard 18 mois après la fin de l’année d’imposition, avec le formulaire T661 et l’annexe T2SCH31, joints à la déclaration de revenus annuelle, comme l’indique le guide T4088. La politique sur les exigences de production confirme que ce sont les formulaires prescrits pour les sociétés.
L’ARC recommande aussi que la partie technique du T661 soit rédigée par des personnes qui connaissent bien le contenu scientifique et technique des travaux. Pour un projet ERP, c’est un défi: les équipes TI comprennent le projet, mais rarement le langage d’admissibilité de l’ARC. Le résultat est souvent une description centrée sur les fonctionnalités, ce qui est exactement ce qu’il faut éviter. Notre guide pratique du T661 montre comment structurer chaque section.
Il existe par ailleurs une approbation préalable facultative, possible pour un maximum de 3 projets, chaque approbation étant valide pour une durée maximale de 3 ans. Elle peut avoir de l’intérêt pour un projet ERP pluriannuel, mais sa pertinence dépend de votre situation.
Comment l’ARC examine un projet ERP
L’examen est généralement réalisé par deux intervenants, selon le guide du processus d’examen: un conseiller en recherche et technologie (CRT), qui détermine si les travaux sont admissibles, et un examinateur financier (EF), qui examine les dépenses demandées. Vous devez fournir les documents à l’appui et les renseignements demandés dans les délais fixés.
Un projet ERP attire souvent des questions du CRT du type: « Pourquoi une solution existante ne répondait-elle pas au besoin? Quelles alternatives avez-vous essayées? Qu’est-ce qui était réellement incertain? ». Préparez des réponses écrites avant de déposer, pas après la lettre de l’ARC.
Sur les délais, l’ARC publie ses cibles de traitement et précise que des retards hors de son contrôle peuvent découler d’une demande incomplète ou de l’absence de réponse aux demandes de renseignements. Une demande claire et des réponses rapides accélèrent donc le dossier. Si vous êtes au Québec, consultez aussi notre article sur la vérification RS&DE de Revenu Québec.
Notre point de vue
Nous voyons régulièrement des projets ERP présentés de deux façons opposées. Certaines entreprises écartent d’emblée leur projet parce qu’il « n’est qu’un ERP », alors qu’une partie de leur développement sur mesure répond aux critères. D’autres veulent tout réclamer, y compris la configuration et la formation, ce qui expose le dossier en vérification.
Notre approche consiste à découper le projet en travaux. Nous cherchons le ou les points précis où l’équipe s’est butée à un inconnu technique, nous vérifions que les preuves existent, puis nous rédigeons la description technique en parlant d’hypothèses, d’essais et de connaissances acquises, jamais de fonctionnalités. Notre équipe réunit des fiscalistes et des experts techniques, ce qui permet de comprendre l’architecture avant de la défendre, y compris en cas de contestation.
Si l’incertitude n’est pas là, nous vous le disons. Un projet qui n’est pas admissible ne mérite ni honoraires ni risque de réajustement.
— Alexandre
Faire évaluer votre projet avec HLP
Vous hésitez sur l’admissibilité d’un projet d’intégration ou de développement lié à votre ERP? Nous proposons un outil logiciel d’analyse d’admissibilité offert à 0 $, qui vous aide à situer votre projet par rapport aux critères avant tout engagement. Au besoin, nous prenons en charge la rédaction technique, la maximisation de la réclamation, le suivi lors d’une vérification et, si nécessaire, les recours jusqu’à la Cour canadienne de l’impôt. Pour mesurer l’investissement, consultez notre article sur le prix d’un consultant RS&DE.
Questions fréquentes
Un ERP acheté « clé en main » peut-il donner droit à la RS&DE?
Généralement non. L’achat et le déploiement d’un produit standard ne comportent pas d’incertitude technologique, puisque la méthode est connue. Seuls les travaux de développement qui dépassent ce cadre, et qui exigent de l’expérimentation, peuvent être évalués.
Peut-on réclamer les honoraires de l’intégrateur?
Pas automatiquement. Il faut isoler la partie du contrat qui correspond à des travaux admissibles et respecter les règles de l’ARC sur les contrats avec des tiers. Un fiscaliste doit valider le traitement avant la production du T661.
Faut-il avoir réussi pour être admissible?
Non. L’admissibilité repose sur la nature des travaux et l’incertitude de départ, pas sur le succès. Un essai infructueux, bien documenté, est même une preuve utile de la démarche expérimentale.
Quand faut-il produire la demande?
Au plus tard 18 mois après la fin de l’année d’imposition, avec le T661 et l’annexe T2SCH31. Mieux vaut documenter tout au long du projet que reconstituer les faits à la dernière minute.
Sources
- Quels sont les travaux admissibles, ARC
- Lignes directrices sur l’admissibilité des travaux, ARC
- Guide T4088, ARC
- Politique sur les crédits d’impôt à l’investissement, ARC
- Le processus d’examen de la RS&DE, ARC
- Politique sur les exigences de production, ARC
- Encouragements fiscaux pour la RS&DE, approbation préalable, ARC
- Délais de traitement de l’ARC

No responses yet