CIR : comment démontrer la contribution d’un consultant aux travaux de R&D ?

« Notre expert MLOps a passé six mois sur ce projet. Il a résolu des problèmes que personne dans l’équipe ne savait traiter. L’administration veut quand même rejeter sa facture du CIR. Comment est-ce possible ? »   Cette réaction, nous l’entendons régulièrement de la part de DAF de startups IA ou deeptech. 

La réponse est presque toujours la même : l’administration ne remet pas en cause la compétence du consultant. Elle remet en cause la preuve de sa contribution aux travaux de R&D. 

Autrement dit, l’enjeu n’est pas de savoir si votre consultant est senior, rare ou brillant. C’est de démontrer qu’il a effectivement participé à lever une incertitude technique et que des traces documentaires l’attestent pour être éligible pour le Crédit Impôt Recherche (CIR). 

Un consultant externe peut-il entrer dans le périmètre du CIR ? 

Oui, à condition que sa mission soit orientée vers la levée d’un verrou technique ou scientifique, et non vers l’exécution d’un périmètre déjà défini. 

Ce qui compte, c’est la nature de leur intervention : ont-ils contribué à explorer des hypothèses, à concevoir des protocoles d’essai, à valider ou invalider des pistes techniques ? 

Le malentendu le plus fréquent consiste à croire que le niveau du prestataire suffit à justifier son inclusion. Un architecte senior, un expert IA ou un chercheur contractuel ne sont pas automatiquement éligibles.  

Le sujet est particulièrement critique dans les startups software, IA, cyber et deeptech, où une large part de la R&D est réalisée par des experts externes : architectes freelances, consultants data, chercheurs contractuels, équipes d’ESN (Entreprise de Services du Numérique) spécialisées, développeurs seniors en renfort. 

Quelle contribution directe au verrou technique ? 

Poser une question simple avant toute inclusion : le consultant intervient-il sur l’incertitude technique du projet, ou uniquement sur son implémentation ? 

Pour être défendable, son intervention doit pouvoir être reliée à des activités concrètes de recherche :  

• Exploration d’hypothèses concurrentes 

• Conception de protocoles d’essai 

• Réalisation de tests de faisabilité 

• Développement de prototypes expérimentaux 

• Benchmarks comparatifs entre architectures ou modèles 
• Validation et invalidation de pistes 

A contrario, une mission centrée sur l’intégration, la TMA, le déploiement ou le support d’un périmètre déjà stabilisé relève de l’ingénierie courante. Elle n’apporte pas de réponse à une incertitude : elle exploite une solution déjà connue. 

Exemple 

Entreprise A mandate un expert temps réel pour résoudre un problème de synchronisation distribuée non couvert par l’état de l’art. Il conçoit les protocoles de test, formalise trois hypothèses d’architecture concurrentes et en abandonne deux après benchmarks : profil défendable. 

Entreprise B mandate un consultant React pour intégrer une UI entièrement spécifiée, sans incertitude technique identifiée : périmètre non défendable au sens du CIR. 

Bon à savoir 

L’administration ne regarde pas le titre du prestataire. Elle cherche à comprendre si sa mission a effectivement contribué à lever une incertitude technique documentée dans le dossier R&D. 

Quels livrables pour prouver la démarche expérimentale ? 

Un consultant CIR-compatible laisse des traces très différentes de celles d’une mission de delivery classique. La question n’est pas la quantité de documents produits, mais leur capacité à répondre à trois questions :  

1. Qu’est-ce qui a été testé ?  

1. Pourquoi cela n’était pas évident au départ ?  

1. En quoi la mission a-t-elle fait progresser l’état des connaissances sur le verrou ? 

Les supports les plus solides sont : 

• Les notes d’hypothèses (pistes envisagées, approches retenues ou écartées) 

• Les benchmarks comparatifs entre architectures ou modèles 

• Les notebooks montrant les essais successifs et les variations de paramètres 

• Les design docs détaillant les arbitrages techniques 

• Les rapports d’essais ou d’échec documentant les pistes non concluantes 

• Les POCs ou prototypes attestant d’une validation expérimentale. 

Les rapports d’échec, en particulier, sont parmi les preuves les plus précieuses en CIR. Ils démontrent l’existence réelle d’une incertitude, et le fait qu’elle n’a pas été résolue du premier coup. 

Notre conseil Myriad 

Une facture détaillée avec 18 jours « architecture » n’aide pas si aucune hypothèse technique n’est documentée. Le dossier doit raconter une démarche, pas seulement lister des journées. 

Comment prouver l’intégration du consultant dans l’équipe R&D ? 

L’un des meilleurs signaux de réalité est l’intégration opérationnelle du consultant dans les rituels de l’équipe R&D. Pour un DAF confronté à une revue CIR, les preuves les plus solides sont celles qui ancrent le consultant dans le processus d’expérimentation du client, pas seulement dans sa facturation. 

Les traces les plus probantes sont les tickets Jira de courtes tâches techniques (user stories de recherche, tâches d’investigation, plans de test), les pull requests portant sur des fonctionnalités expérimentales, les comptes rendus de workshops scientifiques ou d’arbitrages d’hypothèses, les participations aux sprint reviews expérimentales, et les décisions documentées d’abandon de pistes. 

Cette dernière catégorie est particulièrement importante : lorsque le consultant contribue à documenter pourquoi une piste a été écartée, il devient directement rattachable à la levée du verrou.  

Le bon réflexe consiste donc à reconstruire la mission du consultant comme un chapitre à part entière du récit R&D, avec ses hypothèses, ses essais, ses livrables et ses contributions directes. 

Quels sont les pièges en contrôle CIR ? 

Les dépenses liées aux consultants externes sont parmi les plus challengées lors des revues CIR, notamment dans les sociétés software et IA qui s’appuient sur des experts rares.  

Premier piège : confondre expertise technique et contribution R&D 

Un consultant très senior n’est pas automatiquement éligible. Le sujet n’est pas son niveau, mais la nature expérimentale de sa mission. Ce raisonnement est souvent faux ou, à minima, excessivement simplificateur. 

Deuxième piège : les missions mixtes traitées à 100 % 

Dans de nombreuses startups SaaS, B2B ou ESN, un même consultant consacre 30 % de son temps à l’exploration et 70 % à la delivery. Seule la quote-part réellement expérimentale est défendable. Le 100 % « par confort » est rarement robuste face à un vérificateur. 

Troisième piège : le contrat en décalage avec la réalité 

Le contrat mentionne « assistance technique », mais le dossier CIR présente le consultant comme un chercheur expérimental. Cette incohérence est immédiatement visible lors d’un contrôle. Le document contractuel doit mentionner les objectifs de faisabilité, les hypothèses à tester et les livrables de recherche. 

Quatrième piège : l’absence d’agrément CIR 

Si le consultant intervient en prestation de service au sens de la sous-traitance, le prestataire doit détenir un agrément CIR valide délivré par le Ministère de la Recherche. Sans agrément, la dépense est rejetée d’office, même si les travaux sont de qualité. En régie (assistance technique), l’agrément est nécessaire même si le consultant est assimilé à un collaborateur interne sous votre direction. 

Ne confondez pas « expertise technique » et « éligibilité fiscale ». L’agrément CIR est un prérequis administratif, pas une validation de la qualité scientifique des travaux. 

Comment documenter sans alourdir le planning de vos équipes techniques ? 

La bonne nouvelle, c’est que les meilleures preuves existent souvent déjà dans vos outils. Les sources à récupérer en priorité : tickets Jira de tâches techniques, pull requests, benchmarks de performance, notebooks, RFC d’architecture, comptes rendus de workshops et arbitrages entre hypothèses. 

Notre conseil Myriad 

Instaurer une revue mensuelle légère entre la direction financière et le CTO :  

• Quels consultants travaillent sur un verrou ?  

• Quelles hypothèses ont avancé ce mois-ci ?  

• Quelles journées sont hors delivery ?  

• Quels échecs doivent être archivés ?  

Ce rituel, répété chaque mois, augmente énormément la robustesse du dossier à la clôture, sans créer de charge documentaire supplémentaire pour les équipes. 

Que vérifier avant d’intégrer la dépense dans votre CIR ? 

Avant toute inclusion, six questions doivent trouver une réponse claire du côté des équipes techniques : 

1. Quel verrou technique précis le consultant a-t-il contribué à lever ? 

1. Quelles hypothèses ont été testées ? 

1. Quels livrables techniques le démontrent ? 

1. Quelle quote-part relève réellement de la démarche expérimentale ? 

1. Le contrat ou SOW reflète-t-il la mission R&D telle qu’elle a été vécue ? 

1. Le consultant apparaît-il dans la chronologie R&D documentée du projet ? 

Si la direction financière ne peut pas répondre simplement à ces questions, la dépense mérite d’être retraitée avant déclaration. Le meilleur test reste simple : si vous retirez le consultant du récit technique, le verrou reste-t-il levé de la même façon ? Si la réponse est non, sa contribution est généralement beaucoup plus facile à défendre. 

Points clés à retenir 

• Le consultant doit contribuer directement à la levée d’un verrou. Son rôle doit porter sur l’exploration d’hypothèses, les essais, les benchmarks ou la validation d’une piste incertaine. Une mission d’implémentation ou de renfort delivery reste beaucoup plus fragile. 

• La facture seule ne suffit jamais. Même détaillée, elle ne démontre pas la réalité de la démarche expérimentale. Le dossier doit montrer ce qui a été testé, pourquoi cela n’était pas évident, et comment la mission a fait progresser la compréhension du verrou. 

• Les livrables doivent refléter une logique d’essais et d’apprentissage. Les meilleurs supports sont les design docs, benchmarks, notebooks, hypothèses invalidées et rapports d’échec. 

• Le contrat doit parler explicitement de faisabilité, d’hypothèses et d’expérimentation. Les termes « assistance technique », « renfort build » ou « maintenance » fragilisent la qualification. 

• La quote-part delivery doit être exclue avec rigueur. Dans les missions mixtes, le 100 % « par confort » est rarement défendable. 

• L’agrément CIR du prestataire est obligatoire en cas de forfait. Sans lui, la dépense est rejetée d’office, indépendamment de la qualité des travaux. 

Les entreprises qui sécurisent durablement leur périmètre consultants ont simplement pris l’habitude d’archiver ce qu’elles font déjà. Si vous souhaitez vérifier la solidité de votre dossier ou sécuriser votre prochain CIR, contactez nos experts pour un diagnostic gratuit et confidentiel. 

FAQ 

Un freelance IA peut-il être éligible au CIR ? 

Oui, s’il travaille réellement sur des hypothèses expérimentales, des modèles, des benchmarks ou la levée d’incertitudes techniques, et que cela est documenté. 

Une ESN en régie peut-elle entrer dans le CIR ? 

Oui, mais uniquement pour la quote-part réellement affectée à la R&D, avec des preuves solides d’intégration à la démarche expérimentale. 

Le consultant doit-il apparaître dans un outil de suivi projet ?

Ce n’est pas une obligation formelle, mais c’est souvent la preuve la plus utile de sa participation réelle aux travaux. 

Les réunions techniques suffisent-elles comme preuve ? 

Non. Elles renforcent le dossier mais doivent être complétées par des livrables, des benchmarks ou des essais documentés. 

L’agrément CIR est-il toujours obligatoire ? 

Oui, dans tous les cas de prestation, l’agrément CIR est obligatoire..