Le T661 est le formulaire que l’ARC exige pour toute demande de crédit d’impôt RS&DE au Canada. Déposé avec votre déclaration d’impôt sur le revenu des sociétés, il identifie vos projets admissibles, décrit les travaux techniques effectués et calcule les dépenses admissibles aux crédits d’impôt à l’investissement.
En 2024-2025, les entreprises canadiennes ont déposé 22 758 demandes de RS&DE et reçu 4,5 milliards de dollars en CII approuvés. Le développement logiciel représentait 40,8 % de tous les crédits accordés — le domaine le plus important de loin. Si votre entreprise emploie cinq développeurs ou plus effectuant des travaux techniquement incertains, le T661 mérite presque certainement votre attention.
Ce guide couvre la structure du formulaire, ce que chaque section requiert réellement, comment rédiger des récits techniques qui satisfont les réviseurs de l’ARC, et les erreurs qui réduisent ou disqualifient le plus souvent les demandes.
Qu’est-ce que le formulaire T661
Le T661 est officiellement intitulé « Dépenses de recherche scientifique et de développement expérimental (RS&DE) ». Il doit être déposé avec chaque demande de crédit RS&DE accompagnée du formulaire T2SCH31 — Crédit d’impôt à l’investissement. Déposer l’un sans l’autre entraîne la perte de tout ou partie de l’avantage fiscal.
Le document de référence est le Guide T4088 du formulaire T661 de l’ARC, qui fournit des instructions ligne par ligne. Le T661 lui-même contient 10 parties numérotées.
Les 10 parties du formulaire T661
Partie 1 — Renseignements généraux
Nom du demandeur, numéro d’entreprise, année d’imposition et personne-ressource principale. Simple. C’est l’en-tête administratif.
Partie 2 — Renseignements sur le projet (la section critique)
La partie 2 est remplie une fois pour chaque projet admissible et comporte trois sous-sections distinctes.
Section A — Identification du projet
Titre et code interne du projet, dates de début et de fin, le code de classification du domaine scientifique de l’ARC (de l’annexe du T661), si le projet est la continuation de travaux des années précédentes, et la divulgation de tout projet collaboratif ou conjoint avec d’autres entités.
Section B — Récits techniques
Les trois champs narratifs où la plupart des demandes réussissent ou échouent. Chacun a une limite de mots stricte :
- Ligne 242 (max 350 mots) : L’incertitude technologique qui a rendu les travaux nécessaires.
- Ligne 244 (max 700 mots) : Les travaux effectués — hypothèses, expériences, tests, résultats et conclusions, en ordre chronologique.
- Ligne 246 (max 350 mots) : Les nouvelles connaissances techniques acquises ou l’avancement technologique réalisé.
Ces éléments sont traités en détail dans la section suivante.
Section C — Renseignements supplémentaires sur le projet
Qui a préparé les descriptions techniques et leurs qualifications. Noms et rôles de trois membres clés du personnel technique au maximum. Si des travaux ont été effectués à l’extérieur du Canada. Les sous-traitants impliqués. La documentation disponible pour appuyer la demande.
Note sur les demandes multi-projets : Si vous avez plus de 20 projets admissibles, l’ARC vous permet de déposer la partie 2 pour les 20 plus importants en valeur monétaire. Toutes les autres parties doivent être complètes pour tous les projets.
Partie 3 — Calcul des dépenses de RS&DE
Vous choisissez l’une de deux méthodes ici, et ce choix est contraignant pour l’année d’imposition :
- Méthode de remplacement : Les frais généraux sont représentés par une formule — 55 % de la base salariale. Aucun suivi détaillé des frais généraux requis. La plupart des entreprises logicielles utilisent cette méthode.
- Méthode traditionnelle : Tous les frais généraux sont spécifiquement identifiés et alloués avec une documentation de soutien détaillée. Plafond plus élevé mais travail considérablement plus important.
Parties 4-7 — Calculs financiers
Ces sections calculent votre bassin de dépenses de RS&DE qualifiées (partie 4), le montant de remplacement prescrit selon la méthode de remplacement (partie 5), les ventilations des coûts par projet (partie 6) et les détails supplémentaires (partie 7). Si vous utilisez un consultant ou un comptable, ces parties relèvent principalement de leur domaine.
Partie 8 — Liste de vérification de la demande
La vérification interne d’exhaustivité de l’ARC. Sauter des champs ou laisser des éléments non corroborés augmente la probabilité de sélection pour vérification. Remplissez-la soigneusement.
Partie 9 — Renseignements sur le préparateur de la demande
Identifie qui a préparé la demande — un employé interne ou un consultant externe. Cette section a été ajoutée en 2013. Son omission entraîne une pénalité de 1 000 $ mais ne désavoue pas la demande.
Partie 10 — Attestation
Attestation d’un dirigeant autorisé. La personne qui signe assume la responsabilité de l’exactitude de la demande.
Comment rédiger les récits techniques
Les lignes 242, 244 et 246 sont là où les demandes réussissent ou échouent. Les réviseurs de l’ARC passent le plus de temps ici. Les récits vagues ou mal orientés sont la raison la plus courante pour laquelle des demandes autrement admissibles sont refusées.
Ligne 242 — Incertitude technologique (350 mots)
La définition de l’ARC : « Qu’un résultat ou objectif donné puisse être atteint, ou comment l’atteindre, n’est pas connu ou déterminé sur la base des connaissances ou de l’expérience scientifiques ou technologiques généralement disponibles. »
Trois choses que cela signifie en pratique :
1. L’incertitude doit exister au début du projet, pas avec le recul. Vous décrivez pourquoi, au moment où les travaux ont commencé, la solution n’était pas évidente ou dérivable des connaissances publiques existantes.
2. Elle doit dépasser ce qu’un praticien qualifié pourrait résoudre en appliquant des méthodes connues. Les problèmes techniques résolus par l’application de techniques établies sont explicitement exclus. L’incertitude technologique existe quand même un expert qualifié ne pourrait pas déterminer la solution sans mener une investigation originale.
3. L’échec est une preuve acceptable. Apprendre qu’une approche ne fonctionnera pas constitue une avancée des connaissances. Vous n’avez pas besoin de réussir — vous devez avoir fait face à une véritable incertitude et l’avoir investiguée.
Ce que l’ARC ne veut pas voir à la ligne 242 : des objectifs commerciaux (« nous voulions améliorer la performance client »), des descriptions de fonctionnalités (« nous avions besoin que le système gère 10 000 utilisateurs simultanés »), ou des problèmes résolus par l’application de solutions connues (« nous avons implémenté la mise en cache pour réduire la charge de base de données »).
Ligne 244 — Travaux effectués (700 mots)
C’est le registre d’investigation systématique. L’ARC utilise un test à cinq questions tiré de la jurisprudence (connu sous le nom de cadre « Northwest Hydraulic ») :
- Y avait-il une incertitude scientifique ou technologique ?
- Des hypothèses ont-elles été formulées pour réduire cette incertitude ?
- L’approche était-elle compatible avec une investigation systématique par expérience ou analyse ?
- L’objectif était-il un avancement scientifique ou technologique ?
- Des registres des hypothèses testées et des résultats ont-ils été maintenus au fur et à mesure des travaux ?
Les cinq doivent recevoir une réponse affirmative de ce que vous écrivez à la ligne 244. Structurez-la comme un registre chronologique : l’hypothèse avec laquelle vous avez commencé, les expériences ou analyses que vous avez menées, les résultats que vous avez observés, et les conclusions que vous avez tirées. Chaque cycle hypothèse-test-résultat est une itération d’investigation systématique.
Les directives de l’ARC sont explicites : « Les essais et erreurs dépourvus de planification systématique ne constituent pas une investigation appropriée. » Vous devez montrer que votre approche était structurée, pas aléatoire.
Ligne 246 — Avancement réalisé (350 mots)
Quelles nouvelles connaissances votre équipe a-t-elle acquises ? L’avancement ne nécessite pas un produit commercial ou un résultat réussi. Il exige que la compréhension produite par votre investigation dépasse ce qui existait au début du projet.
Rédigez en termes de principes : ce que votre équipe comprend maintenant de l’espace problème, les limitations que vous avez découvertes, les contraintes que vous avez cartographiées. Évitez de reformuler le résultat commercial. « Nous avons livré la fonctionnalité au T3 » n’est pas un avancement technologique.
Admissibilité spécifique aux logiciels
Le développement logiciel est admissible dans trois scénarios, selon les directives de l’ARC :
- Le logiciel lui-même est le produit novateur — un nouvel algorithme, une nouvelle architecture de données, un modèle d’apprentissage automatique sans solution technique existante.
- Le logiciel combiné avec le matériel crée un produit amélioré — systèmes de contrôle embarqués, pipelines de traitement du signal, implémentations personnalisées de réseaux neuronaux.
- Le logiciel créé pour soutenir un projet RS&DE admissible qui ne fait pas partie du produit commercial final — cadres de test personnalisés, outils de simulation, code HDL.
Incertitude système — Le concept clé pour les entreprises logicielles
La plupart des logiciels commerciaux sont construits sur des outils, bibliothèques et frameworks connus. L’ARC a historiquement exigé la nouveauté dans les composants eux-mêmes, pas seulement dans la façon dont ils sont combinés. Une décision de la Cour fiscale de 2024 a changé cela.
Dans DAZZM Inc. c. Sa Majesté le Roi (2024 CCI 129), le juge Gagnon a précisé que la combinaison de composants connus peut elle-même créer une incertitude technologique — appelée « incertitude système » — lorsque les interactions entre ces composants sont imprévisibles. La décision a également confirmé que l’incertitude technologique doit être évaluée au niveau du projet, pas au niveau des tâches, et a accepté les métriques de performance et les estimations de temps en lieu et place des feuilles de temps quotidiennes.
Cela est important : si votre équipe d’ingénierie a intégré plusieurs systèmes connus et a rencontré des effets d’interaction nécessitant une investigation originale, vous pouvez avoir des travaux admissibles même si aucun composant individuel n’était novateur.
Ce qui n’est pas admissible
L’ARC est explicite sur le fait que les éléments suivants ne sont pas admissibles, quelle que soit la complexité technique :
- Les corrections de bogues de routine utilisant des méthodes de débogage établies
- L’application de protocoles de mise en cache, de transfert de fichiers ou de modèles de base de données standard sans traiter leurs limitations connues
- Le contrôle de la qualité et les tests de routine
- L’embauche d’experts pour appliquer ce qu’ils savent déjà
- La nouveauté dans les fonctionnalités d’une application mobile obtenue à l’aide de méthodes techniques existantes
La distinction que trace l’ARC : la technologie est l’application pratique des connaissances et principes scientifiques — pas simplement construire ce qui est techniquement possible avec des outils existants.
Délais de dépôt
Le délai de dépôt RS&DE est de 12 mois après la date d’échéance de la déclaration d’impôt sur le revenu pour l’année au cours de laquelle les dépenses admissibles ont été engagées. Pour les sociétés, cela produit une fenêtre de 18 mois à partir de la fin de l’exercice :
| Fin d’exercice | Déclaration d’impôt due | Délai RS&DE |
|---|---|---|
| 31 décembre 2024 | 30 juin 2025 | 30 juin 2026 |
| 31 mars 2025 | 30 septembre 2025 | 30 septembre 2026 |
| 30 juin 2025 | 31 décembre 2025 | 31 décembre 2026 |
Deux règles qui surprennent les entreprises :
Aucune prolongation. L’ARC déclare : « L’ARC ne peut légalement accorder de temps supplémentaire » après l’expiration du délai. Le manquer entraîne le rejet automatique de la totalité de la demande. Il n’existe aucun mécanisme d’appel.
Les deux formulaires doivent être déposés avant le délai. Le T661 et le T2SCH31 doivent tous deux être soumis. Déposer seulement l’un entraîne la perte de tout ou partie de l’avantage.
L’ARC recommande de déposer au moins 90 jours avant le délai. Cela laisse le temps de corriger les lacunes que l’ARC identifie pendant qu’il y a encore une fenêtre pour le faire.
Pour la saison de dépôt 2026, consultez Délai de dépôt RS&DE 2026 : dates clés et comment se préparer.
Erreurs courantes du T661 qui réduisent ou disqualifient les demandes
Selon G6 Consulting, 80 % des demandes RS&DE sont approuvées sans examen détaillé. Des 20 % qui sont vérifiées, environ 60 % sont refusées ou substantiellement réduites. La différence entre les deux groupes se situe presque toujours dans les récits et la documentation.
Les erreurs narratives les plus coûteuses :
-
Décrire ce que fait le logiciel, pas le problème à le construire. « Nous avons construit un pipeline de traitement en temps réel qui gère 50 000 événements par seconde » est une description de produit. « Nous avons investigué si les architectures de file de messages connues pouvaient maintenir une latence inférieure à 100 ms sous des charges d’écriture simultanées dépassant les benchmarks publiés, et avons constaté qu’aucune ne le pouvait sans modifications architecturales nécessitant une investigation originale » décrit un travail admissible.
-
Omettre la structure hypothèse-test. Les réviseurs de l’ARC cherchent des preuves que votre équipe a formulé une approche, l’a testée, observé les résultats et tiré des conclusions. Une liste de tâches effectuées ne satisfait pas l’exigence d’investigation systématique.
-
Langage commercial dans les champs techniques. Les formulations comme « améliorer l’expérience client », « soutenir notre croissance » et « pression concurrentielle » n’ont pas leur place dans la partie 2. Chaque phrase doit décrire un fait technique.
Les erreurs de documentation les plus coûteuses :
-
Pas de registres contemporains. L’ARC traite avec scepticisme la documentation créée après coup. Les registres créés pendant les travaux — journaux git, descriptions de PR, notes de sprint, résultats de tests, documents de conception — constituent les preuves les plus solides. Si votre documentation a été assemblée au moment du dépôt à partir de souvenirs, votre demande est plus faible et plus vulnérable lors d’une vérification.
-
Réclamer 100 % du temps d’un employé sans registres de soutien. Les allocations de temps supérieures à 80 % pour tout individu déclenchent l’examen des réviseurs. Vous avez besoin de données de suivi du temps, de registres de calendrier ou de documentation d’attribution de projets pour soutenir les allocations.
-
Documentation manquante des sous-traitants. Les coûts des sous-traitants nécessitent des contrats signés, des factures et une description des travaux admissibles effectués. Une demande de sous-traitant de 100 000 $ sans contrats sera réduite ou refusée.
-
Omission de la divulgation d’aide gouvernementale. Les crédits RS&DE provinciaux et les subventions fédérales doivent être divulgués à la ligne 429. L’omission déclenche des signaux automatiques.
Le problème de documentation
Le T661 est essentiellement un exercice de documentation. Les travaux admissibles effectués par vos ingénieurs au cours du dernier exercice — les investigations incertaines, les approches qui ont échoué, les solutions novatrices — sont déjà capturés dans vos artefacts de développement. Commits git, pull requests, tickets Jira, tâches Linear, registres de décisions architecturales : c’est la matière première d’une demande T661.
La difficulté est de traduire cette matière première dans le format et le langage spécifiques que l’ARC exige. La plupart des entreprises le font rétrospectivement, ce qui est coûteux (temps d’ingénierie perdu en reconstruction), risqué (la mémoire est peu fiable, et l’ARC traite la documentation rétroactive avec scepticisme), et incomplet (les travaux admissibles du début de l’année qui n’ont pas été signalés à ce moment-là sont simplement perdus).
Chrono Platform se connecte à vos outils de développement et produit une documentation T661 prête pour l’ARC à partir de votre historique réel de commits, pull requests et tickets de projet — automatiquement, au fur et à mesure des travaux. Le résultat est une documentation plus précise que la reconstruction rétrospective, sans aucun impact sur votre équipe d’ingénierie.
Pour une comparaison détaillée des logiciels et des consultants pour la documentation RS&DE, consultez Consultants RS&DE vs logiciels : une comparaison honnête.
Si votre équipe passe du temps d’ingénierie à reconstruire la documentation RS&DE en fin d’année, parlez-nous de l’automatiser à partir de vos artefacts de développement existants.
Sources : Page du formulaire T661 de l’ARC | Guide T4088 du formulaire T661 | Statistiques annuelles du programme RS&DE | Politique d’admissibilité des travaux | Politique sur les exigences de dépôt | G6 Consulting — Rejections T661 | SR&ED Education — Analyse DAZZM