Point clé
Une bonne catégorisation du temps en R-D augmente les demandes RS&DE de 15 à 30 %, presque uniquement en capturant du travail déjà fait mais jamais documenté ou mal classé.
La plupart des équipes de R-D ne savent pas où sont passées les heures d’ingénierie du dernier trimestre. Elles savent ce qui a été livré. Elles ne savent pas quels projets ont mangé le budget, ni lesquelles de ces heures étaient admissibles à la RS&DE.
Cet écart coûte deux fois. Une première fois sur le crédit sous-déclaré. Une seconde sur les décisions d’affectation prises à l’aveugle. Cet article explique ce que la catégorisation du temps récupère vraiment, ce que la sous-déclaration vaut en dollars, et comment la déployer sans révolte dans l’équipe.
Qu’est-ce que la catégorisation du temps en R-D?
La catégorisation du temps trie les heures d’ingénierie selon le type de travail, pas seulement selon le projet facturé. La semaine d’un développeur se répartit souvent en quatre blocs : travail expérimental sur une approche non éprouvée, développement de fonctionnalités courantes, triage de bogues et incident en production.
Seul le premier bloc est admissible à la RS&DE. Le suivi du temps classique donne un seul chiffre pour la semaine. La catégorisation donne la répartition.
C’est toute la différence. L’ARC ne finance pas la semaine. Elle finance la partie de la semaine consacrée à lever une incertitude technologique.
Combien la catégorisation du temps ajoute-t-elle à une demande RS&DE?
Entre 15 et 30 %, selon notre expérience. Le gain vient de deux sources, et aucune ne consiste à réclamer plus agressivement.
La première, c’est le travail non documenté. Les ingénieurs passent de vraies heures sur des approches qui échouent. Ces heures sont admissibles. Elles sont rarement consignées, parce que personne ne documente une impasse avec le soin qu’il met à documenter une fonctionnalité livrée.
La seconde, c’est le mauvais classement. Du travail est associé au mauvais projet ou fondu dans une seule ligne « développement ». Les heures étaient suivies. Elles ne l’étaient simplement pas d’une façon qui survit à une révision de l’ARC.
Dans les deux cas, il s’agit de récupération, pas de gonflement. Vous réclamez du travail que vous avez déjà payé.
Combien coûte la sous-déclaration, en dollars?
Faites le calcul sur une demande de taille moyenne. Une société privée sous contrôle canadien (SPCC) obtient un crédit fédéral remboursable de 35 % sur les premiers 3 millions de dollars de dépenses admissibles, plus le crédit provincial par-dessus.
Disons que votre main-d’œuvre admissible documentée s’élève à 800 000 $. À 35 % au fédéral, cela représente 280 000 $ de retour. Supposons maintenant que 20 % de votre travail admissible n’a jamais été intégré à la demande. La véritable base admissible était de 1 million. Vous avez laissé 70 000 $ sur la table, au fédéral seulement, en une seule année d’imposition.
Ajoutez le crédit remboursable québécois de 30 % sur les premiers 3 millions et le chiffre double environ. Répétez sur trois ans et le coût de ne pas faire de suivi dépasse le prix de n’importe quel outil sur le marché.
Que coûte une documentation faible lors d’une révision?
Plus cher que la sous-déclaration, en général. Une demande assemblée de mémoire au moment du dépôt a un mode de défaillance précis : le réviseur demande d’où vient un chiffre, et personne ne peut répondre.
Le coût se répartit en trois parties. Les honoraires professionnels pour défendre la demande. L’ajustement lui-même si la défense échoue. Et les heures d’ingénierie que vos gens les plus expérimentés passent à reconstituer une chronologie vieille d’un an au lieu de construire.
Un ajustement de 30 % sur une demande de 400 000 $ représente 120 000 $, avant honoraires et intérêts. C’est le chiffre à garder en tête quand quelqu’un affirme que le suivi ne vaut pas la charge administrative.
Pourquoi les développeurs résistent-ils au suivi du temps?
Ils résistent parce que la saisie manuelle est fastidieuse et qu’ils savent que le résultat est une fiction. La reconstitution de fin de mois est inexacte à environ 20-40 %. Les ingénieurs sentent qu’ils produisent un chiffre qui n’est pas vrai, et ça les agace.
L’automatisation règle le problème. Les outils qui lisent le travail que l’équipe produit déjà, l’historique git, les demandes de tirage, les tickets Jira, et qui catégorisent à partir de là, éliminent l’étape de saisie. Personne ne remplit de feuille de temps. La preuve était déjà là.
C’est aussi ce qui rend la documentation défendable. Une heure catégorisée rattachée au commit 4a7f2c1 sur une branche datée est un artéfact. Une heure catégorisée saisie dans un formulaire en avril, au sujet de travail fait en juin de l’année précédente, est un souvenir.
Comment déployer la catégorisation?
Quatre étapes, et l’ordre compte.
Commencez par l’écart, pas par l’outil. Sortez la demande de l’an dernier. Comparez ce que vous avez déposé à ce que votre dépôt de code dit du travail réellement effectué. L’écart, c’est votre analyse de rentabilité, en dollars, propre à votre entreprise.
Choisissez pour l’intégration, pas pour les fonctionnalités. L’outil doit lire les systèmes que vos ingénieurs utilisent déjà. S’il exige une nouvelle habitude, l’adoption échoue et vous revenez à la reconstitution.
Faites un trimestre en parallèle. Gardez l’ancien processus à côté du nouveau pendant trois mois. Vous obtiendrez une vraie comparaison et un filet de sécurité si quelque chose casse en cours d’année.
Confiez la demande à une personne. L’outillage capture la preuve. Quelqu’un doit quand même être responsable du dépôt. Les demandes s’effondrent quand la finance et l’ingénierie présument chacune que l’autre s’en occupe.
Qu’est-ce qui change après la première année?
Le crédit augmente, c’est l’objectif. Deux autres choses se produisent, que les équipes de finance valorisent souvent davantage dès la deuxième année.
Les prévisions deviennent justes. Vous savez ce qu’un projet d’une forme donnée a réellement consommé, donc le budget de R-D de l’an prochain repose sur une mesure plutôt que sur la dernière estimation plus une marge.
Les goulots d’étranglement deviennent visibles. Quand les données montrent que 40 % du temps d’ingénierie senior part en réponse aux incidents, c’est une décision de dotation que vous pouvez défendre avec un chiffre. Avant, c’était une impression.
Foire aux questions
De combien les outils de catégorisation du temps peuvent-ils augmenter une demande RS&DE?
Typiquement de 15 à 30 %. Les gains viennent de la capture d’activités admissibles auparavant non documentées ou mal classées, pas d’une réclamation plus agressive. Vous récupérez du travail que vous avez déjà payé.
Quel est le retour sur investissement d’un outil de catégorisation du temps en R-D?
Sur une base de main-d’œuvre admissible de 800 000 $, une amélioration de capture de 20 % vaut environ 70 000 $ de crédit fédéral seulement, au taux SPCC de 35 %, et environ le double avec le crédit provincial québécois. Cela, avant de compter la réduction du risque de vérification et les heures d’ingénierie senior que vous cessez de consacrer à la reconstitution.
Comment amener les développeurs à utiliser le suivi du temps?
Automatisez-le. Le suivi manuel est inexact à 20-40 % et crée une charge administrative que les développeurs rejettent. Les outils qui lisent git, Jira et Slack et catégorisent automatiquement éliminent le problème d’adoption, parce qu’il n’y a plus rien à remplir.
Vous voulez savoir ce qui manque à votre demande actuelle? Parlez à notre équipe pour connecter Chrono R&D à votre dépôt et voir l’écart sur vos propres données.