Des projets qui dépassaient auparavant les seuils d'évaluation sont systématiquement reclassés comme innovation technologique. Que recherche un évaluateur aujourd'hui, comment détecter si votre projet est en zone de risque et quand accepter qu'il ne s'agit pas de R&D.
Jusqu'à la première moitié de 2025, présenter un projet intégrant l'intelligence artificielle, le machine learning ou le traitement du langage naturel était pratiquement synonyme d'avoir un argument solide pour accéder aux aides publiques à la R&D, que ce soit dans le cadre d'appels d'offres nationaux, régionaux ou européens. Les dossiers décrivant des modèles prédictifs, des systèmes de scoring basés sur l'apprentissage automatique, des moteurs de recommandation personnalisée ou des plateformes d'analyse multimodale recevaient régulièrement des évaluations positives. Le taux de qualification favorable pour ce type de projets était raisonnable, et l'argument "nous appliquons une IA avancée" fonctionnait comme un ancrage technique suffisant.
À partir du second semestre 2025, et avec une pleine consolidation au cours du premier trimestre 2026, ce schéma a profondément changé. Des projets substantiellement similaires à ceux qui, un an auparavant, auraient été qualifiés de R&D sont systématiquement reclassés comme innovation technologique. Cette transformation n'est pas une question administrative ni un durcissement conjoncturel des critères. C'est un changement de paradigme dans la manière dont les organismes d'évaluation définissent ce qui constitue la recherche et le développement dans le contexte technologique actuel.
Ce qui était qualifié de R&D jusqu'à mi-2025
Pour comprendre ce changement, il convient de caractériser d'abord le type de projet qui était bien accueilli lors de la phase précédente. Les dossiers qui aboutissaient alors partageaient plusieurs caractéristiques.
- Ils décrivaient le développement de modèles prédictifs basés sur des techniques de machine learning supervisé et non supervisé, les présentant comme une innovation technologique en soi. La simple mention de réseaux neuronaux récurrents, de modèles LSTM, d'architectures Transformer ou de traitement du langage naturel fonctionnait comme un argument de nouveauté, sans qu'il soit nécessaire de démontrer que la combinaison spécifique proposée dépassait un état de l'art concret.
- Ils construisaient l'état de l'art sur des comparaisons avec des concurrents commerciaux, et non sur la littérature scientifique. Un dossier pouvait consacrer cinq pages à expliquer pourquoi le produit résultant serait supérieur à celui d'entreprises spécifiques du marché, et cela était accepté comme une justification suffisante du positionnement technique.
- Ils intégraient des plans de travail orientés produit : recherche préalable, conception d'architecture, développement de modèles, intégration, validation par pilote et déploiement. La structure était plus proche d'un processus de développement logiciel que d'un projet de recherche expérimentale, mais cela était rarement pénalisé.
- Ils justifiaient des budgets importants incluant des licences de logiciels commerciaux, des services cloud, des outils SaaS tiers et, dans certains cas, des coûts d'utilisation d'API d'IA. Ces coûts étaient considérés comme une infrastructure légitime de R&D et étaient intégrés aux bases de calcul des aides sans plus de questionnement.
- Et, surtout, ils présentaient comme innovation technologique centrale l'intégration de capacités d'IA disponibles sur le marché, en supposant que leur incorporation dans un domaine sectoriel spécifique (finance, santé, éducation, commerce de détail, logistique) constituait en soi un acte de R&D défendable.
Ce type de projet recevait habituellement des évaluations positives, avec des appréciations techniques suffisantes pour dépasser les seuils applicables à chaque instrument, surtout lorsque le volet commercial ou d'impact était bien construit.
Pourquoi cela a changé : la maturité des LLM en tant que phénomène disruptif
La cause sous-jacente de ce changement n'est pas réglementaire mais technologique. L'émergence et la consolidation des grands modèles de langage commerciaux (GPT-4, Claude, Gemini, DeepSeek, Qwen et leurs équivalents open source) ont massivement repoussé les limites de ce qui relève de la recherche.
Des capacités qui, jusqu'en 2024, relevaient de la recherche de pointe (compréhension sémantique multilingue, extraction d'entités dans des textes spécialisés, classification contextuelle, analyse de sentiments, génération de résumés cohérents, compréhension d'images et de vidéos, transcription audio, traduction spécialisée, raisonnement sur des données structurées) sont aujourd'hui des produits de base accessibles via API pour quelques centimes par requête. Le raisonnement implicite appliqué par l'évaluateur est direct : si la capacité technique que l'on propose de construire est disponible commercialement, il n'y a pas d'incertitude technique à justifier. Il n'y a pas de nouveauté à démontrer. Et donc, il n'y a pas de R&D au sens strict. Il y a de l'intégration avancée, de l'innovation technologique, du développement commercial sophistiqué. Mais pas de recherche.
Ce changement n'est pas exclusif à un seul organisme ni propre au cadre espagnol. Il reflète une transformation générale de la manière dont les agences publiques d'innovation, les programmes régionaux, les cadres européens et l'interprétation administrative du Manuel de Frascati recalibrent ce qu'ils considèrent comme finançable en tant que R&D dans les projets d'IA appliquée.
La nouvelle logique d'évaluation : ce que voit un évaluateur aujourd'hui
L'évaluateur dispose aujourd'hui de capacités d'analyse technique qu'il n'avait pas il y a deux ans. Il peut vérifier en quelques minutes si une technique décrite dans un rapport est réellement nouvelle ou une application standard. Il peut s'assurer que la combinaison d'algorithmes proposée figure dans la littérature récente. Il peut demander une analyse de l'état de l'art sur n'importe quel sous-domaine technique. Ce qui nécessitait auparavant une expertise spécifique rare est désormais trivialement vérifiable.
Le résultat est que l'apparence de sophistication technique ne fonctionne plus comme argument. Énumérer des technologies impressionnantes ne génère plus de crédibilité. Cela génère, paradoxalement, de la suspicion. Lorsqu'un rapport mentionne le deep learning, les réseaux neuronaux, les Transformers, le PNL avancé, les architectures cloud évolutives et les moteurs de décision automatisés, l'évaluateur se demande où se trouve le développement propre. Si tout cela est disponible commercialement, qu'est-ce qui est exactement recherché ?
Il y a trois éléments que l'évaluateur recherche activement pour confirmer si un projet relève réellement de la R&D ou de l'intégration avancée.
- Premièrement, il examine le budget. Si des postes de dépenses apparaissent pour des services d'OpenAI, Anthropic, Gemini, des API d'IA en général, des coûts de jetons, des coûts d'inférence, des licences de plateformes commerciales qui résolvent déjà le problème (moteurs de scoring, outils de vérification d'identité, plateformes d'IA pré-construites), le projet se révèle être de l'intégration. L'arithmétique est brutale : si le cœur intelligent du produit s'exécute sur une infrastructure externe et est payé à la consommation, aucune capacité technique propre n'est en cours de construction.
- Deuxièmement, consultez la description technique. Si le document mentionne explicitement des fournisseurs d'IA commerciaux comme technologie à intégrer, s'il décrit des architectures multi-fournisseurs pour orchestrer plusieurs LLM commerciaux, s'il présente l'utilisation combinée de services externes comme une innovation, le projet se situe automatiquement en dehors du cadre de la R&D.
- Troisièmement, examinez la formulation des objectifs. Si les objectifs sont du type "développer un système qui...", "implémenter une plateforme pour...", "intégrer des capacités de...", le projet est un projet produit. Les objectifs valables en tant que R&D se présentent sous forme d'hypothèses : "valider si la combinaison X dépasse le benchmark Y publié dans la littérature, atteignant une valeur Z dans la métrique W sous les conditions C".
Comment détecter si un projet est à risque
Avant d'investir des efforts dans la rédaction d'un dossier de R&D, que ce soit pour un appel à projets compétitif, une aide directe, un programme européen ou tout autre instrument d'incitation publique, il est judicieux d'appliquer un filtre interne de quatre questions. Si la réponse honnête à trois d'entre elles ou plus est affirmative, le projet ne pourra pas aboutir en tant que R&D dans le contexte actuel et il convient de repenser la stratégie.
Le cœur technique du projet s'exécute-t-il en appelant des API d'IA commerciales ? Si le système fonctionne en envoyant des données à OpenAI, Anthropic, Google ou tout autre fournisseur similaire et en recevant le résultat traité, la valeur technique n'est pas construite en interne. Elle est louée. Il s'agit par définition d'innovation appliquée, et non de recherche.
Les "technologies innovantes" listées sont-elles des techniques accessibles avec une documentation publique ? Si un développeur compétent peut implémenter ce qui est décrit en lisant des tutoriels et de la documentation officielle, il n'y a pas de frontière technique à franchir. Random forest, gradient boosting, BERT pré-entraîné, Kubernetes, Apache Kafka, réseaux neuronaux convolutionnels standards : tout cela relève de l'ingénierie, et non de la recherche, en 2026.
Le budget inclut-il des postes significatifs de logiciels commerciaux qui résolvent d'eux-mêmes le problème technique posé ? Lorsque des licences de plateformes qui font déjà ce que le dossier présente comme un défi apparaissent, le projet se contredit. Si le dossier propose de rechercher en matière de scoring de crédit et budgétise simultanément des licences de bureaux de scoring commercial, l'évaluateur détecte l'incohérence immédiatement.
La différence entre le résultat du projet et ce qu'un concurrent pourrait faire en achetant les mêmes services est-elle opérationnelle, et non technique ? Si la réponse est oui, que la différence réside dans le go-to-market, l'expérience utilisateur, l'intégration avec les flux d'affaires ou l'acquisition de clients, le projet est légitime mais appartient à la catégorie de l'innovation appliquée. La différenciation concurrentielle basée sur le produit et le marché n'est pas la même chose que la différenciation technique basée sur la recherche.
Comment réorienter un projet pour qu'il soit une R&D viable
Réorienter un projet d'une "intégration d'IA commerciale" vers une "recherche avec un cœur technique propre" n'est pas toujours possible. Parfois, le projet est simplement de l'innovation appliquée et il convient de le présenter comme tel, en supposant que les conditions financières seront moins avantageuses mais réalistes. Mais lorsqu'il existe un véritable cœur technique caché sous des couches de description de produit, il existe des moyens concrets de le faire émerger.
- Identifier la contrainte de domaine qui invalide la solution commerciale. De nombreux projets qui semblent être une intégration de LLM commerciaux ont, en réalité, une raison technique pour laquelle cette intégration ne fonctionne pas ou n'est pas légalement viable. La réglementation sanitaire qui empêche l'envoi de données cliniques à des serveurs tiers. L'exigence de latence en temps réel que les API ne supportent pas. Le domaine spécialisé où les modèles généraux échouent systématiquement par manque d'entraînement sur ce vocabulaire ou ces structures. Lorsque cette restriction existe, la bonne approche est de développer des capacités techniques propres précisément parce que les solutions commerciales ne conviennent pas, et cela constitue bien de la R&D.
- Centrer le projet sur le jeu de données propriétaire, et non sur les techniques. Si l'entreprise dispose de données uniques (en raison d'années d'opération, d'intégrations physiques, d'un accès privilégié, du type de client, de capteurs propres), le projet doit articuler comme hypothèse centrale si ces données contiennent un signal prédictif suffisant et comment l'extraire par une méthodologie spécifique. Les techniques peuvent être standard, mais la nouveauté réside dans la combinaison jeu de données-méthodologie-résultat, qu'aucun concurrent ne peut reproduire en achetant des API.
- Construire l'état de l'art sur la littérature scientifique, et non sur les concurrents. Les rapports de R&D viables citent des articles de l'IEEE, de l'ACM, des revues spécialisées, des prépublications récentes sur arXiv. Ils ne sont pas basés sur des analyses de marché d'entreprises concurrentes. Cette discipline, apparemment formelle, transmet à l'évaluateur que l'équipe a positionné sa proposition par rapport à la frontière technique réelle, et non par rapport au paysage commercial.
- Éliminer les postes budgétaires qui révèlent une intégration. Les API d'IA commerciales, les licences de plateformes SaaS qui résolvent le problème, les coûts de tokens et d'inférence : tout cela doit être exclu du budget lié à la R&D. S'ils sont indispensables au produit final, ce sont des coûts opérationnels postérieurs au projet, et non des coûts de recherche. Les maintenir dans le budget, c'est donner à l'évaluateur la preuve que le projet est une intégration.
- Expliciter le risque technique réel. Un projet de R&D viable contient des risques crédibles qui peuvent entraîner l'échec technique du développement. "Il est possible que les variables proposées n'apportent pas de capacité prédictive incrémentale significative une fois contrôlées par les variables traditionnelles." "Il n'est pas certain que l'architecture proposée puisse maintenir des latences inférieures au seuil requis dans des conditions de charge réelle." "La généralisation du modèle entre les sous-populations pourrait ne pas être valide et nécessiter un réentraînement spécifique." Ces risques transmettent qu'il existe une incertitude réelle que la recherche vise à réduire.
- Envisager la coopération avec des centres de recherche. Une collaboration formelle avec une université, un organisme public de recherche ou un centre technologique ajoute de la crédibilité au projet en tant que R&D authentique, surtout lorsqu'elle apporte une capacité méthodologique que l'entreprise seule ne possède pas. Ce type de coopération est favorablement noté dans pratiquement tous les instruments publics.
Quand accepter que le projet est de l'innovation, et non de la R&D
Il y a un point qu'il convient d'admettre honnêtement : la plupart des projets d'entreprise intégrant l'IA en 2026 ne sont pas de la R&D, et cela n'enlève rien à leur valeur ni à leur légitimité. Les instruments conçus pour l'innovation technologique et l'innovation appliquée existent précisément pour les projets qui intègrent des technologies matures dans des processus de production ou des produits commerciaux avec un risque technique modéré, comme par exemple la ligne LIC du CDTI.
Insister pour présenter comme de la R&D ce que le système a déjà classé comme innovation appliquée entraîne un gaspillage de ressources dans la rédaction de dossiers qui n'aboutiront pas, un retard dans l'obtention de financements, car chaque cycle de rejet et de nouvelle soumission ajoute des mois ; et une détérioration de la crédibilité auprès des organismes évaluateurs lorsque les reclassifications à la baisse s'accumulent.
La tendance à venir
Le durcissement des critères de R&D pour les projets d'IA n'est ni conjoncturel ni réversible. Les modèles commerciaux continueront de s'améliorer, ce qui signifie que la frontière de "ce qui est considéré comme de la recherche" continuera de se déplacer vers le haut. Des capacités qui sont encore à la pointe aujourd'hui (fine-tuning spécialisé, agents autonomes dans des domaines complexes, raisonnement sur des données multimodales) deviendront des produits de base d'ici dix-huit à vingt-quatre mois.
La stratégie durable pour les entreprises qui dépendent de financements publics pour leurs projets d'IA consiste à construire des actifs techniques non réplicables par la consommation d'API. Cela signifie fondamentalement des données uniques, une connaissance approfondie du domaine qui se traduit par une méthodologie spécifique, des intégrations physiques avec du matériel ou des capteurs, une présence dans des secteurs réglementés avec des restrictions qui empêchent l'utilisation de modèles commerciaux, ou la capacité de faire de la science computationnelle qui va au-delà de l'ingénierie de prompt. Le reste, aussi sophistiqué que puisse paraître le résultat final, sera de plus en plus qualifié d'innovation technologique et de moins en moins de R&D.
Si vous avez des doutes quant à savoir si votre projet relève de la R&D ou de l'innovation technologique, ou si vous souhaitez évaluer comment réorienter votre dossier avant de le soumettre à un appel à projets, nous pouvons l'examiner avec vous. Chez Intelectium, nous gérons ce type de projets depuis 21 ans et nous savons de première main comment les organismes évaluent aujourd'hui. Écrivez-nous à dealflow@intelectium.com
