La définition officielle de la RS&DE par l’ARC fait 60 mots de langage réglementaire qui n’explique rien et confond tout le monde.
Voici ce que ça signifie réellement : la RS&DE, c’est le travail que votre entreprise fait pour résoudre des problèmes techniques dont la solution n’était pas évidente au départ.
C’est tout. Le reste, c’est du détail.
La définition de l’ARC (pour référence)
La recherche scientifique et le développement expérimental désigne une investigation ou recherche systématique effectuée dans un domaine de la science ou de la technologie au moyen d’expériences ou d’analyses, qui vise à réaliser un avancement scientifique ou technologique et qui est liée à la création de nouveaux matériaux, dispositifs, produits ou procédés, ou à l’amélioration de ceux qui existent.
Cette définition est précise et technique. En termes pratiques : Vous avez fait de la recherche. Vous avez utilisé des méthodes systématiques. Vous avez fait face à de l’incertitude quant à savoir si votre approche fonctionnerait. Et votre travail a produit quelque chose de mieux — un algorithme plus rapide, une architecture évolutive, une nouvelle fonctionnalité, une optimisation.
Le mot clé est avancement. Vous avez fait progresser l’état technique de votre travail.
Décortiquons la définition
Trois éléments doivent être vrais pour que le travail soit considéré comme de la RS&DE :
1. Incertitude technologique
Vous ne saviez pas au départ si votre approche allait fonctionner.
Vous ne construisez pas quelque chose à partir d’un tutoriel ou en copiant un patron connu. Vous faites face à un problème dont la solution nécessite une investigation. Peut-être que vous le résolvez pour la première fois. Peut-être que vous le résolvez d’une façon nouvelle pour votre entreprise. Peut-être que les solutions existantes ne correspondent pas tout à fait à vos contraintes.
Exemples :
- « Nous avons besoin d’un processeur de paiement qui gère la conversion de devises en temps réel. Les solutions existantes ont 500 ms de latence. Nous avons besoin de moins de 100 ms. »
- « Nos requêtes de base de données sont lentes. Les techniques d’optimisation standard ne résolvent pas le problème. Que faire? »
- « Nous construisons un moteur de recommandation. L’approche ML évidente atteint 60 % de précision. Peut-on faire mieux? »
Dans chaque cas : vous avez fait face à de l’incertitude. La solution n’était pas évidente. Vous avez dû investiguer.
Contre-exemples :
- Intégrer Stripe à votre application (des milliers d’entreprises l’ont fait; la solution est bien documentée)
- Déployer sur Kubernetes (patron bien connu, processus documenté)
- Construire une API REST standard (architecture établie, aucune incertitude)
2. Investigation systématique
Vous n’avez pas juste deviné en espérant que ça marche. Vous avez investigué systématiquement.
Cela signifie que vous avez :
- Examiné le problème en profondeur
- Exploré les solutions potentielles
- Testé votre approche
- Documenté ce que vous avez essayé et pourquoi
- Pris des décisions basées sur des preuves, pas sur l’intuition
Systématique ne veut pas dire parfait. Ça veut dire intentionnel. Ça veut dire que vous pouvez expliquer votre processus.
Exemples :
- « Nous avons évalué trois architectures de base de données différentes et sélectionné celle qui répondait à nos exigences de latence. »
- « Nous avons essayé l’approche A. Elle n’a pas fonctionné à cause de X. Nous avons essayé l’approche B. Elle a fonctionné grâce à Y. »
- « Nous avons mené des expériences pour déterminer quel algorithme nous donnerait la précision requise. »
3. Avancement technologique
Votre travail a produit un progrès. Vous avez amélioré quelque chose. Vous n’avez pas simplement implémenté une technologie existante; vous l’avez étendue, optimisée ou appliquée d’une manière nouvelle.
L’avancement doit être technologique, pas au niveau des affaires. Vous ne pouvez pas réclamer « nous avons construit une fonctionnalité que les clients voulaient » si la fonctionnalité elle-même est techniquement simple.
Vous pouvez réclamer « nous avons optimisé le backend pour gérer 10 fois plus d’utilisateurs simultanés au même coût » parce que c’est un avancement technologique.
Exemples :
- Un algorithme qui atteint une meilleure précision que les alternatives open source existantes
- Une architecture qui passe à une capacité nettement supérieure à l’approche standard
- Une optimisation qui réduit la consommation de ressources en deçà de ce que les solutions existantes requièrent
- Une nouvelle approche à un problème technique que les concurrents ont résolu différemment
La confusion courante : Nouveau au monde vs. Nouveau pour vous
Voici ce que la plupart des gens comprennent mal : la RS&DE n’exige pas que vous inventiez quelque chose de nouveau pour le monde entier.
Elle exige que vous ayez fait face à une incertitude technologique et que vous l’ayez résolue.
Exemple : Votre équipe invente une approche d’apprentissage automatique pour la recommandation qui atteint 75 % de précision. Ça n’a jamais été fait — c’est nouveau au monde. RS&DE claire.
Mais votre équipe résout aussi un problème d’évolutivité dans votre couche de base de données. Vous êtes les premiers dans votre entreprise à le résoudre de cette façon, mais d’autres entreprises ont résolu des problèmes similaires auparavant. C’est quand même de la RS&DE, parce que vous avez fait face à une véritable incertitude sur la façon de résoudre votre version du problème.
L’ARC se soucie de votre processus, pas de votre originalité.
Pourquoi c’est important pour votre entreprise
La raison pour laquelle l’ARC se soucie de ces trois critères est qu’elle tente d’identifier les vrais investissements en R&D.
Si chaque entreprise réclamait simplement « nous avons fait du développement », le programme serait inutile et coûteux. Les trois critères filtrent le travail routinier — la maintenance, les implémentations standard, les solutions évidentes — et identifient le travail qui représente un véritable investissement en innovation.
Votre équipe d’ingénierie passe probablement 60 % de son temps sur du développement routinier (fonctionnalités standard, maintenance, implémentations évidentes). Ça ne se qualifie pas.
Votre équipe d’ingénierie passe probablement 30 à 40 % de son temps sur du travail où elle a fait face à une réelle incertitude technique et a dû investiguer pour résoudre le problème. Ça se qualifie.
L’ARC veut identifier ces 30 à 40 % et offrir un crédit pour ça.
Ce qui ne se qualifie pas
- Les correctifs de bogues et la maintenance routinière
- Le développement de fonctionnalités standard à partir d’une spécification claire
- Les tests, l’assurance qualité et la documentation (activités de soutien, pas de la recherche)
- Les ventes, le marketing, les opérations ou le travail administratif
- La gestion routinière de l’infrastructure
- Les correctifs de sécurité sur les systèmes existants
Ce qui se qualifie
- Développer une nouvelle approche à un problème technique
- Optimiser quelque chose au-delà de ce que les solutions existantes atteignent
- Résoudre un défi de concurrence, d’évolutivité ou de performance avec de l’incertitude
- Développer un modèle d’apprentissage automatique où l’approche et la précision n’étaient pas garanties
- Concevoir l’architecture d’un système pour répondre à des contraintes sans solutions évidentes
- Expérimenter avec des technologies émergentes pour voir si elles résolvent un problème
- Tout travail d’ingénierie où vous avez fait face à une véritable incertitude technique et avez dû investiguer
L’angle de la documentation
Pourquoi tout ça est-il important? Parce que lorsque vous déposez une demande de RS&DE, vous faites une déclaration à l’ARC : « Ce travail remplit les trois critères. »
L’ARC peut vous contester. Elle demandera : « Quelle était l’incertitude technologique? Qu’avez-vous fait pour investiguer? Quel avancement avez-vous réalisé? »
Votre documentation doit répondre clairement à ces trois questions.
C’est pourquoi la plupart des entreprises sous-réclament (elles sont conservatrices quant à ce qui se qualifie) ou embauchent des consultants (pour défendre la demande auprès de l’ARC).
Mais si vous comprenez clairement les trois critères, vous pouvez documenter votre propre travail. Vous pouvez expliquer pourquoi il se qualifie. Et quand l’ARC l’examinera, elle verra que votre processus était rigoureux.
Un cadre pratique
Quand votre équipe termine un projet, posez-vous ces questions :
- Avons-nous fait face à une incertitude technologique? Aurions-nous pu simplement chercher la réponse et l’implémenter, ou avons-nous dû investiguer?
- Avons-nous investigué systématiquement? Pouvons-nous pointer vers des expériences que nous avons menées, des approches que nous avons essayées ou des décisions que nous avons prises basées sur des preuves?
- Avons-nous réalisé un avancement technologique? Le résultat est-il plus rapide, plus précis, plus évolutif ou plus robuste que les solutions existantes?
Si oui aux trois, c’est du travail de RS&DE. Documentez-le. Vous le réclamerez plus tard.