Le vibe coding est-il admissible à la RS&DE?

L'ARC ne regarde pas comment le code a été écrit. Elle regarde si le travail répond à deux exigences: viser une avancée scientifique ou technologique et reposer sur une investigation systématique, par l'expérimentation ou l'analyse. Le point de départ est l'incertitude technologique: il est inconnu ou incertain qu'un résultat puisse être atteint, à cause d'une insuffisance dans les connaissances disponibles.

Autre point souvent oublié: dans le guide T4088, la programmation informatique figure comme travail de soutien. Elle compte lorsqu'elle appuie directement un travail de développement expérimental admissible. Écrire du code n'est donc pas, en soi, de la RS&DE.

La plupart des projets faits au « feeling » sont du développement courant: un site, un tableau de bord, un outil interne, une intégration standard. Pour ces projets, la solution existe déjà. L'IA la reproduit plus vite, mais l'incertitude, elle, n'existait pas.

L'ARC exclut l'acquisition de connaissances ou de savoir-faire qui existent déjà. Elle rappelle aussi, dans sa politique de 2015 (archivée), que la nouveauté, les fonctionnalités ajoutées ou une meilleure fonctionnalité ne suffisent pas à établir une avancée technologique. Une application nouvelle sur le marché n'est donc pas admissible pour cette seule raison.

L'outil n'exclut pas le projet. Ce qui compte, c'est la nature du problème. Un projet pourrait mériter un examen si, par exemple:

• Vous cherchez à atteindre une performance, une précision ou une fiabilité qu'aucune approche connue n'atteint, et vous ne savez pas à l'avance si c'est possible.
• Vous devez faire fonctionner ensemble des systèmes dont la compatibilité technique est inconnue, sans solution documentée.
• Votre équipe formule des hypothèses, les teste par des expériences, mesure les résultats et en tire des conclusions, l'IA n'étant qu'un outil parmi d'autres dans ce processus.

À notre avis, l'incertitude doit porter sur votre problème technique, pas sur la capacité de l'outil à produire du code qui fonctionne. Ce sont des cas à examiner, jamais des garanties.

L'ARC indique que les documents créés pendant que le travail est réalisé sont les plus courants, et elle cite parmi les preuves, côté logiciel, les journaux de révision ou de validation du code (« commit logs »). Elle mentionne aussi les photos, les vidéos et les artefacts.

Une pratique utile, qui n'est pas une exigence de l'ARC: garder des notes datées sur le problème, les hypothèses, les essais échoués et les décisions, y compris ce que l'outil d'IA a produit et pourquoi vous l'avez gardé ou rejeté. C'est ce fil qui montre qu'une investigation a bien eu lieu.

À notre connaissance, l'ARC n'a publié aucune ligne directrice propre aux outils de codage par IA. En l'absence de position officielle, des interprétations différentes circulent. Ne tenez donc rien pour acquis, et en particulier:

• N'assumez pas que le code généré compte comme travail admissible.
• Ne présumez pas qu'un abonnement à un outil d'IA est une dépense admissible: nous n'avons pas trouvé de position de l'ARC à ce sujet. Faites valider ce point.

Si vous voulez une réponse de l'ARC avant d'engager des dépenses, elle offre depuis le 1er avril 2026 une approbation préalable facultative: une décision en huit semaines, avant d'engager les coûts de RS&DE.

Si votre équipe a eu à résoudre un vrai problème technique, avec ou sans IA, un examen vaut la peine, idéalement avant la fin de votre exercice, tant que les journaux de code et les notes existent. Chez Hubvention, nous vous aidons à voir si votre travail se qualifie et à structurer le dossier. Réserver mon diagnostic →