Travail open source et RS&DE : quand est-ce admissible?

Les entreprises logicielles qui construisent sur l’open source tendent à supposer qu’aucun de ce travail n’est admissible au RS&DE. Le raisonnement paraît logique : si le code est public, il n’y a pas d’incertitude technologique. La réponse est déjà disponible.

Ce raisonnement est faux plus souvent qu’on ne le croit. Le logiciel open source est un point de départ, pas une solution complète. Quand votre équipe d’ingénierie fork un projet pour un problème que les mainteneurs n’ont jamais anticipé, ou intègre plusieurs composants OSS et découvre des effets d’interaction nécessitant une investigation systématique, le travail peut satisfaire chaque partie des critères d’admissibilité de l’ARC. La question n’est pas de savoir si le code de base est public. C’est de savoir si le problème résolu par votre équipe avait une réponse dans les connaissances publiques existantes.

La plupart des conseillers RS&DE ignorent complètement cet aspect. Les entreprises dirigées par des développeurs laissent du travail admissible hors de leurs demandes parce que le code de base provenait d’un projet open source.

Comment le test des « connaissances publiques » de l’ARC s’applique-t-il?

Le cadre d’admissibilité de l’ARC repose sur l’incertitude technologique : un praticien qualifié aurait-il pu déterminer la solution en utilisant les connaissances scientifiques ou technologiques généralement disponibles?

Pour le travail open source, cela devient une question précise : la solution est-elle documentée dans le code existant du projet, sa documentation, ses issues ou ses ressources communautaires?

Si votre équipe a suivi la documentation du projet, utilisé ses APIs comme prévu et l’a configuré selon les guides publiés, c’est de l’application routinière de connaissances existantes. Pas d’incertitude, pas de demande.

Mais la documentation open source a ses limites. La plupart des projets documentent leurs cas d’usage prévus. Ils documentent rarement ce qui se passe quand on pousse le logiciel dans un domaine imprévu, qu’on le combine avec d’autres outils dans des configurations non testées, ou qu’on a besoin de performances sous des contraintes que les auteurs originaux n’ont pas considérées. Quand votre équipe franchit cette limite, elle entre dans le territoire de l’incertitude technologique réelle.

Le test est objectif. Peu importe que votre équipe ait trouvé la réponse et l’ait contribuée à la communauté. Ce qui compte, c’est que la réponse n’était pas prévisible au départ.

Quels sont les cinq scénarios où le travail open source est admissible?

Le même test en trois parties s’applique au travail open source comme à toute autre demande RS&DE : incertitude technologique, investigation systématique et avancement technologique. Voici comment ça se concrétise.

1. Construire une extension nouvelle sans solution existante

Votre équipe a besoin d’une fonctionnalité qui n’existe pas dans l’écosystème. Vous avez cherché dans le registre de plugins, le suivi des issues et les forums communautaires. Rien ne convient.

Construire un plugin standard en suivant l’API d’extension du projet est routinier. Mais quand le framework d’extension lui-même ne peut pas supporter ce dont vous avez besoin, et que votre équipe doit investiguer si l’architecture sous-jacente peut être adaptée d’une manière non prévue par le projet, l’incertitude entre en jeu.

Exemple : Une équipe travaillant sur Apache Kafka avait besoin de garanties de traitement exactly-once dans une topologie multi-régions avec une latence sous les 100 ms. La sémantique exactly-once existante de Kafka ne couvrait pas leur scénario de réplication inter-régions. L’équipe a passé 10 semaines à investiguer si le protocole de groupes de consommateurs pouvait être étendu pour supporter leurs exigences de cohérence sans violer les garanties d’ordonnancement dont dépendaient les autres consommateurs. Quatre approches testées. Deux ont introduit des violations d’ordonnancement subtiles visibles uniquement lors de conditions spécifiques de rééquilibrage de partitions.

Cette investigation est admissible. La réponse n’était pas dans la documentation. Le problème a nécessité une expérimentation systématique. Les connaissances résultantes ont fait avancer la compréhension du comportement du protocole Kafka sous des contraintes non prévues par la conception originale.

2. Forker et modifier un OSS pour un problème imprévu

Forker un projet open source et l’adapter pour un problème que le code original n’était pas conçu pour résoudre est l’un des scénarios admissibles les plus courants. C’est aussi l’un des plus négligés.

La clé est l’écart entre ce pour quoi le logiciel a été conçu et ce dont votre équipe a besoin. Si cet écart nécessite une investigation, si vos ingénieurs ne peuvent pas prédire si les modifications fonctionneront sur la base de la documentation existante, le fork devient un projet de développement expérimental.

Exemple : Une startup en vision par ordinateur a forké un moteur d’inférence optimisé pour les GPUs cloud et a tenté de le faire tourner sur des appareils en périphérie avec une mémoire contrainte. Le code original supposait une VRAM abondante et utilisait des patrons d’allocation causant des crashs de mémoire sur le matériel cible. L’équipe a passé 14 semaines à réécrire la couche de gestion mémoire, tester différentes approches de quantification et investiguer si la précision se dégradait sous les seuils acceptables à chaque niveau de compression. Trois des cinq stratégies de quantification ont produit une dégradation de précision visible uniquement sur des distributions d’entrée spécifiques.

Ce n’est pas le fork en soi qui est admissible. C’est l’investigation systématique nécessaire pour déterminer si et comment le logiciel pouvait être adapté à un environnement non testé.

3. Intégrer plusieurs composants OSS avec des interactions imprévisibles

Ce scénario correspond à un principe que l’ARC a reconnu en jurisprudence. Une décision de la Cour de l’impôt de 2024 a confirmé que combiner des composants connus peut créer une incertitude technologique quand leurs interactions produisent un comportement imprévisible nécessitant une investigation originale.

Les écosystèmes open source regorgent de ce type de situation. Chaque bibliothèque fonctionne comme documenté en isolation. Combinez-en trois ou quatre et des cas limites émergent que personne n’avait anticipés, parce que personne n’avait testé cette combinaison précise.

Exemple : Une entreprise fintech a intégré un courtier de messages, une base de données de séries temporelles et un framework de traitement de flux pour un pipeline de calcul de risque en temps réel. Chaque composant fonctionnait individuellement. Sous charge de production, le système a montré des incohérences de données qu’aucune documentation des projets individuels n’abordait. L’interaction entre les garanties de livraison du courtier, la mise en tampon des écritures de la base de données et le mécanisme de checkpointing du processeur de flux créait une fenêtre où les calculs de risque utilisaient des données périmées. L’équipe a passé 8 semaines à investiguer l’interaction, construire une instrumentation personnalisée pour observer les écarts de synchronisation, et développer un mécanisme de coordination absent des trois projets.

Les technologies individuelles étaient connues. L’interaction ne l’était pas. C’est l’incertitude que l’ARC recherche.

4. Contribuer des correctifs amont qui résolvent des problèmes technologiques

Quand votre équipe résout un véritable problème technologique et contribue la solution à la communauté, le travail admissible s’est produit avant la fusion du correctif. L’investigation, les approches échouées, les tests systématiques ont tous eu lieu pendant que la réponse était encore inconnue.

Le fait que la solution devienne publique ne disqualifie pas rétroactivement le travail. L’ARC évalue l’admissibilité au moment où le travail a été effectué, pas au moment du dépôt de la demande.

Exemple : Une équipe travaillant avec une base de données distribuée a découvert que son algorithme de consensus exhibait un comportement de split-brain sous un patron de partition réseau spécifique que la suite de tests existante ne couvrait pas. Six semaines d’investigation sur la cause racine, trois correctifs testés, et validation que chacun n’introduisait pas de régressions dans d’autres scénarios de défaillance. Le correctif final a été contribué en amont. Le PR a été accepté.

La contribution amont n’affecte pas l’admissibilité dans un sens ou l’autre. Elle ne disqualifie pas le travail (l’incertitude existait au départ), et elle ne le qualifie pas automatiquement (le test en trois parties s’applique toujours). Ce qui compte, c’est si l’investigation a satisfait les critères de l’ARC pendant la période où le travail a été effectué. Pour plus d’informations sur comment le RS&DE s’applique à différents scénarios logiciels, consultez notre guide d’exemples.

5. Construire des outils personnalisés pour soutenir d’autres travaux de R-D admissibles

Parfois le travail open source n’est pas le projet de R-D principal. Votre équipe construit des outils personnalisés autour de composants OSS pour soutenir d’autres recherches admissibles.

L’ARC permet que le « travail de soutien » soit admissible quand il est directement lié et nécessaire à la poursuite de projets RS&DE admissibles. Les bancs d’essai personnalisés, les outils de surveillance spécialisés ou l’infrastructure de pipeline de données construits spécifiquement pour soutenir une investigation de R-D peuvent compter.

Exemple : Une équipe d’apprentissage automatique construisant un système de recommandation innovant devait évaluer la performance du modèle contre des données de comportement utilisateur à une échelle que leur infrastructure existante ne pouvait pas gérer. Ils ont construit un framework d’évaluation personnalisé sur Apache Spark, écrivant des opérateurs spécialisés absents de l’écosystème Spark pour simuler le comportement de session utilisateur avec des distributions temporelles réalistes. Le framework d’évaluation n’était pas le projet de R-D. L’algorithme de recommandation l’était. Mais le framework était nécessaire pour exécuter les expériences de l’investigation principale.

Documentez cet outillage comme travail de soutien pour le projet RS&DE parent, pas comme une demande autonome.

Quel travail open source n’est pas admissible?

Tout le travail open source n’implique pas d’incertitude technologique. Ces activités sont de l’application routinière de connaissances existantes, peu importe l’effort d’ingénierie :

Utilisation routinière de bibliothèques. Installer un package, appeler son API selon la documentation, le configurer selon le README. Chronophage ne veut pas dire incertain.

Configuration et déploiement standards. Configurer des clusters Kubernetes, des pipelines CI/CD, déployer des piles de surveillance. Tout cela suit des patrons documentés.

Corrections de bogues connus. Si le bogue est documenté dans le suivi des issues avec un correctif connu, l’appliquer n’est pas du RS&DE. Si le bogue est inconnu et nécessite une investigation originale pour le diagnostiquer, c’est différent.

Intégration suivant des patrons documentés. Connecter deux services en utilisant leurs guides d’intégration publiés, même si ça prend des semaines. L’effort n’est pas synonyme d’incertitude.

Optimisation de performance par techniques connues. Profiler et appliquer des patrons établis (mise en cache, pool de connexions, optimisation de requêtes) est une pratique standard. Pour un regard plus approfondi sur où se situe la ligne, consultez notre guide d’exemples RS&DE.

Comment documenter les projets RS&DE open source?

Les projets RS&DE open source ont un avantage documentaire que la plupart des équipes ne réalisent pas : la piste de preuves existe déjà.

L’historique Git est votre cahier de laboratoire. Les messages de commit, noms de branches et descriptions de PR documentent la progression de l’investigation. Une branche nommée experiment/custom-consensus-fix-v3 avec 47 commits sur 6 semaines raconte une histoire d’investigation systématique que les réviseurs de l’ARC peuvent suivre.

Les descriptions de PR capturent hypothèses et résultats. Quand les ingénieurs écrivent « Essayé l’approche X, mais ça a causé Y dans la condition Z. Ce PR implémente l’approche W à la place », ils documentent exactement la boucle hypothèse-test-résultat que l’ARC recherche.

Les discussions d’issues documentent l’incertitude. Les fils où les ingénieurs débattent des approches possibles, citent des articles de recherche ou expliquent pourquoi la solution évidente ne fonctionnera pas sont des preuves directes que la réponse n’était pas prévisible à partir des connaissances existantes.

Le défi est de rendre ces preuves accessibles à un réviseur de l’ARC qui ne lira pas votre historique Git. Votre narratif technique doit traduire l’historique de développement brut dans le langage de l’ARC : quelle était l’incertitude, quelles hypothèses avez-vous testées, qu’avez-vous appris, et comment le résultat fait-il avancer l’état de la technologie.

Étapes pratiques pour renforcer votre documentation :

• Écrivez des messages de commit qui expliquent le pourquoi, pas seulement le quoi. « Annulé l’approche A en raison d’une régression de latence 3x sous charge concurrente » bat « Changements annulés ».
• Utilisez les descriptions de PR comme mini-rapports d’expérience. Énoncez l’hypothèse, l’approche, le résultat et la prochaine étape.
• Étiquetez le travail admissible dans votre outil de gestion de projet. Un simple label comme rsde-candidat sur les tickets impliquant une investigation réelle facilite grandement la préparation de la demande.
• Préservez les branches sans issue. Les expériences échouées sont des preuves d’investigation systématique. Ne les supprimez pas.

Le fait de contribuer le code affecte-t-il votre demande RS&DE?

Une préoccupation empêche les leaders d’ingénierie de considérer le travail open source pour le RS&DE plus que toute autre : « On ne détient pas la PI. On a contribué le code à la communauté. Comment ça peut être admissible? »

L’ARC n’exige pas que vous déteniez la propriété intellectuelle résultant de votre investigation. Le programme évalue le travail effectué, pas la propriété du résultat. Si votre équipe a mené un développement expérimental admissible, le travail est admissible que vous gardiez le résultat propriétaire, le contribuiez en amont ou le publiez dans un article de blogue.

C’est logique. Le programme existe pour encourager les entreprises canadiennes à prendre des risques technologiques. Contribuer les résultats à la communauté ne réduit pas le risque que votre équipe a pris. Ça n’annule pas l’investigation, les approches échouées ou les ressources investies. Le RS&DE compense l’activité de R-D, pas la PI résultante.

Les entreprises qui contribuent fortement à l’open source devraient auditer leur travail d’ingénierie pour ce patron. Si votre équipe résout des problèmes que la communauté n’a pas résolus, documente son investigation et fait avancer l’état de la technologie, ce travail appartient à votre demande RS&DE.

Comment démarrer?

Si votre entreprise construit sur ou contribue à l’open source, commencez par une revue ciblée des 12 derniers mois. Cherchez les projets où votre équipe d’ingénierie :

• A passé plus de deux semaines à investiguer un problème non couvert par la documentation existante
• A forké ou significativement modifié un projet OSS pour un cas d’usage imprévu
• A intégré plusieurs composants open source et rencontré des effets d’interaction nécessitant une investigation originale
• A construit des outils personnalisés pour permettre des expériences ou recherches
• A contribué des correctifs résolvant des problèmes que la communauté n’avait pas abordés

Pour chaque projet candidat, appliquez le test en trois parties. Y avait-il une incertitude technologique réelle? L’équipe a-t-elle investigué systématiquement? Le travail a-t-il produit un avancement technologique?

La plupart des entreprises qui font cette revue trouvent du travail admissible qu’elles ignoraient. L’étiquette open source donne l’impression de connaissances publiques. Souvent, le travail que votre équipe a fait pour pousser ce logiciel au-delà de ses capacités documentées est exactement ce que l’ARC a conçu le programme pour récompenser.

FAQ

Peut-on réclamer du RS&DE sur du travail open source si on a contribué le code?

Oui. L’ARC évalue l’activité de R-D, pas la propriété de la PI. Si votre équipe a mené un développement expérimental admissible, le travail est admissible que vous le gardiez propriétaire ou le contribuiez en amont. L’incertitude existait quand vous avez commencé. La contribution publique ne change rien.

Le fait de forker un projet open source qualifie-t-il automatiquement pour le RS&DE?

Non. Un fork n’est admissible que si les modifications ont nécessité une investigation systématique réelle face à une incertitude technologique. Adapter simplement un projet en suivant ses patrons d’extension documentés est de l’ingénierie routinière. Le fork est admissible quand votre équipe ne peut pas prédire si les modifications fonctionneront sur la base des connaissances existantes et doit expérimenter pour le déterminer.

Comment prouver l’incertitude technologique quand le code de base est public?

Concentrez votre narratif technique sur l’écart entre ce que le projet documente et ce dont votre équipe avait besoin. Montrez que vous avez cherché dans les ressources existantes (documentation, issues, forums communautaires) et que la réponse n’y était pas. Documentez ensuite l’investigation systématique : hypothèses testées, approches échouées et ce que vous avez appris. L’historique Git, les discussions de PR et les branches d’expériences fournissent des preuves solides pour une vérification RS&DE.

Vous ne savez pas quels projets open source de votre organisation d’ingénierie sont admissibles? Parlez à notre équipe RS&DE. Nous aidons les entreprises logicielles à identifier le travail de R-D admissible, structurer la documentation qui survit à la révision de l’ARC et maximiser les demandes sans exagérer.