Vérification RS&DE : pourquoi les réclamations IA perdent

La première lettre de l’ARC arrive dans une enveloppe beige. La formulation est calme. L’agence procède à une vérification de votre réclamation RS&DE et souhaite planifier une discussion initiale. Le conseiller en recherche et technologie assigné au dossier est nommé dans la lettre, ainsi que ses coordonnées. Rien dans la lettre n’est alarmant. Rien dans la lettre n’est rassurant non plus.

Ce qui suit est un processus défini, et ce processus n’a pas changé dans sa substance depuis des années. Ce qui a changé, c’est l’étalonnage. Les évaluateurs de l’ARC en 2026 lisent la documentation différemment des évaluateurs de 2022, et les outils de filtrage IA qui tournent maintenant sur les narratifs T661 entrants signalent des schémas qui seraient passés inaperçus il y a trois ans. Les entreprises qui perdent des ajustements sous le nouvel étalonnage ne sont pas, dans la plupart des cas, des entreprises dont la R&D sous-jacente était inadmissible. Ce sont des entreprises dont la documentation ne peut pas défendre la réclamation qu’elle fait. Les réclamations préparées par IA, particulièrement celles produites par des outils basés sur la génération, sont disproportionnellement dans cette catégorie.

Cet article décrit le processus de vérification étape par étape, montre les moments précis où les narratifs générés par IA s’effondrent et explique quoi faire si vous ne pouvez pas répondre aux questions qu’un évaluateur va poser. Le traitement architectural approfondi de la raison des échecs se trouve dans notre guide sur les réclamations RS&DE préparées par IA.

Qu’est-ce qui déclenche une vérification RS&DE de l’ARC?

L’ARC ne vérifie pas chaque réclamation. L’agence utilise une combinaison de sélection basée sur le risque et d’échantillonnage aléatoire. Le taux de vérification tourne autour de 12 % des réclamations dans une année donnée, mais le taux n’est pas uniforme selon les types de réclamations. Les réclamations de première fois et de grande valeur attirent plus d’attention; la croissance rapide d’une année sur l’autre dans la valeur des réclamations attire l’attention; les ratios élevés de salaires RS&DE par rapport à la masse salariale totale attirent l’attention; et les réclamations en IA/ML sont sous surveillance accrue depuis 2024.

Deux déclencheurs plus récents sont importants pour la documentation préparée par IA. Le premier est le filtrage IA de l’ARC, qui tourne maintenant sur les narratifs T661 entrants et signale les schémas associés à une documentation de mauvaise qualité ou fabriquée : prose IA générique, liens manquants vers des sources, affirmations sur l’incertitude technologique sans manques de connaissances articulés. Le second est le programme d’approbation préalable aux réclamations, entré en vigueur le 1er avril 2026, qui demande de la documentation contemporaine comme condition de soumission.

Nous avons couvert ce qui déclenche les vérifications dans notre article sur les audits RS&DE. Le résumé : les réclamations préparées par IA font face maintenant à deux couches de scrutin. Le filtrage IA et l’évaluateur humain s’étalonnent tous deux au même standard.

Étape 1 : Contact initial et demande de documents

La vérification commence par une lettre ou un appel téléphonique du conseiller en recherche et technologie (CRT) assigné à votre dossier. Le CRT est un évaluateur technique, pas un vérificateur fiscal. Son travail consiste à évaluer si le travail décrit dans votre T661 répond aux critères d’admissibilité. La première interaction est procédurale : le CRT se présente, explique la portée de la vérification et émet une demande de documents.

La demande de documents demande généralement les narratifs techniques que vous avez soumis, la documentation de projet maintenue pendant la période de réclamation, les relevés de temps appuyant vos allocations salariales, et tout contrat avec des tiers. L’expression qui compte dans la demande est « maintenue pendant la période de réclamation ». Le CRT demande des preuves qui précèdent la déclaration. Il ne demande pas les documents que vous avez produits après la réception de l’avis de vérification. Il demande le dossier contemporain.

C’est le premier moment précis où les réclamations préparées par IA commencent à perdre. Un outil d’IA basé sur la génération produit le narratif T661 au moment de la déclaration, parfois des mois après le travail sous-jacent. Le narratif est le seul artefact que l’entreprise possède. La « documentation de projet maintenue pendant la période de réclamation » est quelque chose que l’équipe technique doit trouver ou recréer après la réception de la demande. Une partie existe. Une partie n’a jamais été écrite. L’entreprise commence la vérification avec un manque de documentation qu’elle ne savait pas qu’elle avait.

Un outil d’IA basé sur la capture produit une position de départ différente. La documentation contemporaine est l’entrée du narratif, pas son résultat. Les commits, les pull requests, les tickets et les notes de conception sont déjà organisés et liés à des réclamations spécifiques. La demande de documents est quelque chose à laquelle l’entreprise peut répondre en jours, pas en semaines.

Étape 2 : La lecture du narratif

Le CRT lit les narratifs T661 dans le dossier. La lecture se produit avant et après que l’écran d’IA a effectué son premier passage, et le CRT est étalonné aux mêmes attentes que l’écran. Il cherche de la spécificité à chaque étape du test d’admissibilité en trois volets.

Pour l’incertitude technologique, le CRT veut voir ce qui n’était pas connaissable à partir des méthodes existantes au début du travail. « Nous avons examiné des approches d’optimisation de performance » n’articule pas un manque de connaissances. « Nous avons examiné si un schéma de partitionnement hiérarchique personnalisé pouvait maintenir une latence de requête p95 inférieure à 150 ms sous des lectures simultanées dépassant 12 000 RPS, où les approches existantes étaient inadéquates pour notre schéma d’accès » articule un manque de connaissances.

Pour l’investigation systématique, le CRT veut voir ce qui a été essayé, observé, modifié et conclu. « L’équipe a mené une expérimentation itérative » ne décrit pas une investigation. « L’équipe a évalué quatre approches sur six semaines. Trois ont échoué de manières spécifiques : la promotion des clés chaudes a dégradé les performances de la longue traîne, le cache à deux niveaux a produit des incohérences sous des écritures simultanées, le partitionnement personnalisé seul ne pouvait pas gérer la contention des clés chaudes. La quatrième a atteint 142 ms p95 à 13 400 RPS lors des tests de charge le 2026-02-14 » décrit une investigation.

Pour l’avancement technologique, le CRT veut voir le manque de connaissances comblé et l’état de l’art que le travail a dépassé. « Nous avons réalisé un avancement technologique dans le domaine du traitement distribué des données » ne nomme pas un avancement. « L’architecture hybride n’est pas décrite dans la littérature existante pour ce schéma d’accès spécifique, et les résultats des tests documentent un gain de performance mesurable par rapport aux bases de référence publiées » nomme un avancement.

Les outils d’IA basés sur la génération utilisent par défaut le premier type de formulation dans chaque cas. Le schéma est structurel. Le modèle remplit des détails plausibles à partir des données d’entraînement, et le pari le plus sûr pour le modèle est une formulation générique qui fonctionne pour beaucoup de sociétés possibles. Le CRT le lit et recourt aux heuristiques d’échec de crédibilité.

Étape 3 : La question « d’où cela provient-il? »

C’est le moment où la plupart des réclamations basées sur la génération échouent. Le CRT choisit une affirmation spécifique dans le narratif et demande à l’équipe technique de produire les artefacts source derrière elle.

Pour une réclamation basée sur la génération, la réponse est une version de « nous avons généré le narratif à partir de la description du projet et de notre connaissance du travail. » L’équipe technique peut généralement trouver une certaine preuve derrière la réclamation, mais la preuve doit être extraite de la base de code après que la question a été posée. Le narratif n’a pas été construit à partir des artefacts; les artefacts doivent être rétroactivement ajustés au narratif. Parfois, l’ajustement fonctionne. Parfois, l’artefact n’existe pas parce que le narratif décrivait un travail qui ne s’est pas produit tout à fait comme la prose l’implique. Parfois, l’artefact existe mais ne correspond pas à la spécificité du narratif. Le CRT remarque chaque écart.

Pour une réclamation basée sur la capture, la réponse est un seul clic. Le narratif porte des métadonnées de provenance pour chaque affirmation. La question « d’où cela provient-il? » atterrit sur un hash de commit, un numéro de pull request ou un identifiant de ticket avec une date. Le CRT ouvre l’artefact, le lit et confirme que le narratif résume ce qui est dans le dossier sous-jacent. La conversation avance.

La décision de la Cour canadienne de l’impôt dans DAZZM Inc. c. Le Roi, 2024 CCI 129 portait exactement sur ce problème : la documentation soumise lors de l’étape de révision avait été substantiellement reconstituée après coup, et la cour a traité la reconstitution comme un échec de crédibilité. L’affaire ne concerne pas l’IA. Elle concerne la documentation contemporaine comme standard procédural.

Étape 4 : L’entretien technique

Dans de nombreuses vérifications, l’ARC demande un entretien avec les membres de l’équipe technique qui ont effectué le travail RS&DE. Pas le comptable. Pas le consultant qui a préparé la déclaration. Les ingénieurs. Le CRT veut parler aux personnes qui ont livré le travail, leur demander ce qu’elles essayaient d’accomplir, ce qu’elles ne savaient pas faire au début, quelles approches elles ont essayées, et ce qu’elles ont appris.

Les ingénieurs qui peuvent parler couramment de ces questions sont convaincants. Les ingénieurs qui ne se souviennent pas du travail parce qu’il a été déclaré par un consultant externe qui l’a reconstitué à partir de tickets Jira ne le sont pas. Les outils d’IA basés sur la génération introduisent un troisième mode d’échec : des ingénieurs qui reconnaissent le projet mais ne reconnaissent pas le narratif que l’outil d’IA a produit. Le narratif décrivait le travail en termes que l’équipe technique n’aurait pas utilisés. Les détails techniques dans le narratif ne sont pas les détails que les ingénieurs se souviennent avoir traités.

Les outils basés sur la capture évitent ce mode d’échec parce que le narratif est résumé à partir des propres commits, pull requests et tickets des ingénieurs. La prose n’est pas leur écriture, mais la substance est leur travail. Ils le reconnaissent. L’entretien devient une conversation sur des décisions qu’ils ont réellement prises, avec les artefacts sous-jacents sur la table.

Étape 5 : Le résultat

La vérification aboutit à l’un de trois résultats : réclamation approuvée telle que produite, réclamation ajustée (partiellement refusée), ou réclamation entièrement refusée. Les ajustements sont le résultat le plus courant pour les entreprises logicielles. L’ARC refuse généralement des lignes de projet spécifiques ou réduit les allocations salariales plutôt que de rejeter l’ensemble de la réclamation.

La documentation IA basée sur la génération tend à produire des ajustements plus souvent, non pas parce que le travail sous-jacent était inadmissible, mais parce que la documentation ne peut pas défendre la réclamation qu’elle fait lorsqu’on l’interroge. Les lignes de projet qui se lisent de manière générique sont réduites ou supprimées. Les allocations salariales attachées aux lignes de projet qui ne survivent pas à la vérification technique sont ajustées en conséquence. Un ajustement de 30 % sur une réclamation de 400 000 $ représente un rappel de 120 000 $ avant les honoraires professionnels et les intérêts.

La documentation basée sur la capture tend à produire des approbations plus souvent, encore une fois non pas parce que le travail sous-jacent est plus admissible, mais parce que la documentation répond aux questions que le processus de vérification pose. Le narratif est ancré dans des artefacts source. Les artefacts sont datés. L’entretien technique confirme la substance. Le CRT trouve ce à quoi il est étalonné : un dossier contemporain d’investigation systématique sur une incertitude technologique qui a produit un avancement technologique.

Vous conservez le droit de vous opposer à tout résultat. Le processus d’opposition est formel et implique la division des appels, pas l’équipe de vérification RS&DE. Si vous avez de la documentation appuyant votre position, l’opposition vaut la peine d’être poursuivie. Si la documentation est mince, l’opposition est généralement un combat plus difficile.

Que faire si vous ne pouvez pas répondre à ces questions?

Si vous avez lu les cinq sections précédentes et réalisé que votre préparation RS&DE actuelle ne peut pas répondre à la question « d’où cela provient-il? », l’action est directe. Ne produisez pas une réclamation 2026 avec une documentation produite principalement à partir d’une invite. Soit vous reconstruisez le narratif à partir de vos données source réelles, paragraphe par paragraphe, avec chaque affirmation liée à un artefact daté, soit vous passez votre préparation par une architecture basée sur la capture qui effectue le travail en continu plutôt qu’au moment de la déclaration.

La première question à poser à votre fournisseur d’outil est la même que celle du CRT : d’où provient chaque affirmation technique dans nos narratifs T661? La bonne réponse est un artefact source. La mauvaise réponse est une description de l’invite.

Si vous êtes au début de votre cycle 2026 et souhaitez voir à quoi ressemble l’alternative, notre démo dure vingt-cinq minutes. Nous connecterons Lucius à un dépôt de démonstration et tracerons un paragraphe généré jusqu’au commit d’origine. Si votre dépôt contient les artefacts contemporains, la capture est l’architecture qui transforme ces artefacts en une réclamation défendable.

FAQ

Quel pourcentage des réclamations RS&DE fait l’objet d’une vérification par l’ARC?

Environ 12 % des réclamations dans une année donnée passent par une vérification technique, mais le taux n’est pas uniforme. Les premiers déclarants, les réclamations de grande valeur, les réclamations en croissance rapide et les réclamations en IA/ML font face à des taux de vérification plus élevés. Le filtrage IA qui tourne maintenant sur les narratifs T661 entrants ajoute une couche de sélection supplémentaire pour les réclamations avec des schémas de documentation génériques.

Que se passe-t-il si l’ARC ajuste ma réclamation RS&DE?

L’ARC émet un avis de nouvelle cotisation ajustant le montant du crédit. Vous avez 90 jours pour vous opposer formellement. Si votre documentation est mince, l’opposition est un combat plus difficile. Si elle est solide, l’opposition a une chance réelle. Dans les deux cas, les honoraires professionnels pour le processus d’opposition s’ajoutent au coût de l’ajustement. Sur une réclamation de 400 000 $ avec un rejet de 30 %, le rappel seul est de 120 000 $ avant ces honoraires.

Puis-je corriger une réclamation RS&DE basée sur la génération après avoir reçu un avis de vérification?

Vous pouvez compléter la documentation, mais vous ne pouvez pas la rendre rétroactivement contemporaine. Le problème n’est pas la qualité de la prose; c’est que le narratif n’a pas été construit à partir d’artefacts datés. Certaines entreprises s’opposent avec succès en fournissant des preuves techniques supplémentaires. Beaucoup n’y arrivent pas. La prévention est beaucoup moins coûteuse que la remédiation.

---

Si vous ne pouvez pas répondre à ces questions sur votre propre réclamation, parlez à notre équipe. Nous aidons les entreprises logicielles à évaluer si leur documentation RS&DE est contemporaine, basée sur la capture et prête pour une vérification de l’ARC.