Nous utilisons du no-code : le projet reste-t-il éligible au CII ?

Le no-code permet aujourd'hui de lancer des produits numériques plus rapidement que jamais. Mais lorsqu'il s'agit de Crédit d'Impôt Innovation (CII), une question revient régulièrement : un projet développé sans code ou avec peu de développement spécifique reste-t-il éligible ?

La réponse n'est ni un oui automatique ni un non catégorique. Car en matière de CII, le véritable sujet n'est pas la technologie utilisée. Ce qui compte avant tout, c'est la capacité de l'entreprise à démontrer qu'elle a conçu un produit nouveau répondant aux critères définis par l'administration fiscale.

Alors, le no-code est-il compatible avec le CII ? Quels sont les critères à respecter et les pièges à éviter ? Décryptage.

Le recours au no-code exclut-il automatiquement le bénéfice du CII ?

Non. Aucun texte fiscal ni aucune disposition de la doctrine administrative ne prévoit qu'un projet développé en no-code ou en low-code soit exclu du Crédit d'Impôt Innovation (CII).

Cette précision est importante, car de nombreux dirigeants associent encore l'innovation à la complexité technique ou au volume de code produit. 

Le CII vise les dépenses engagées pour la conception de prototypes ou d'installations pilotes de produits nouveaux présentant des performances supérieures à celles des produits existants sur le marché concerné, comme le rappelle la doctrine fiscale relative au Crédit d'Impôt Innovation.

Le recours au no-code n'est donc pas le sujet. Ce qui compte, c'est la capacité de l'entreprise à démontrer qu'elle a conçu un produit nouveau présentant des performances supérieures à celles des produits déjà disponibles sur son marché.

Exemple - Entreprise A

Une société développe sur Bubble une plateforme permettant aux gestionnaires immobiliers d'automatiser l'attribution de logements selon des critères multiples habituellement traités manuellement. La valeur créée réside dans les fonctionnalités proposées et les performances obtenues, pas dans la technologie utilisée.

Exemple - Entreprise B

Une entreprise recrée un logiciel de gestion commerciale déjà largement disponible sur le marché en y ajoutant quelques personnalisations graphiques. Le projet est développé en code traditionnel, mais la nouveauté du produit reste difficile à démontrer. Le risque de rejet est alors élevé malgré l'utilisation d'un développement classique.

Que regarde réellement l'administration fiscale pour accorder le CII ?

La notion centrale est celle de produit nouveau.

Selon la doctrine fiscale, le produit doit présenter des performances supérieures à celles des produits déjà présents sur le marché. Cette définition précise que ces performances peuvent être techniques, fonctionnelles, ergonomiques ou environnementales.

Dans la pratique, l'administration analyse plusieurs éléments :

• la nouveauté du produit ;
• les performances apportées aux utilisateurs ;
• les travaux de conception réalisés ;
• les phases de développement et d'expérimentation ;
• les tests et validations effectués ;
• l'existence d'un prototype ou d'une installation pilote.

La doctrine précise également qu'un prototype n'est pas nécessairement un produit finalisé. L'administration admet notamment qu'une version intermédiaire destinée à être testée et améliorée puisse constituer un prototype éligible lorsqu'elle permet de valider les caractéristiques du futur produit, comme l'indique le BOFiP consacré au CII.

Concrètement, pour vous, cela change profondément la manière d'aborder le sujet.

La bonne question n'est donc pas : « Quel outil avons-nous utilisé pour développer le produit ? » mais  « Avons-nous créé un produit nouveau capable d'apporter une valeur mesurable par rapport aux solutions déjà disponibles ? »

Un logiciel développé en no-code peut-il constituer un produit nouveau ?

Du coup, vous l’avez compris : la réponse est oui. Dans certains cas, le no-code permet même d'accélérer les cycles d'innovation en facilitant le prototypage et les tests utilisateurs.

L'éligibilité dépend toutefois de la nouveauté du produit et non de la rapidité de développement.

Exemple - Entreprise A

Une PME conçoit une plateforme RH destinée aux réseaux de franchises. L'application permet de répartir automatiquement les besoins en personnel entre plusieurs établissements en tenant compte des compétences, de la localisation et des contraintes contractuelles. Cette fonctionnalité apporte une réponse inédite à un problème métier identifié. Le prototype est développé sur Bubble. Dans cette situation, le support technologique n'est pas le sujet principal ; c'est la nouveauté du produit qui sera analysée.

Exemple - Entreprise B

Une société développe un CRM sur une plateforme no-code afin de centraliser les données commerciales et d'automatiser certaines tâches. Malgré plusieurs mois de travail, les fonctionnalités proposées existent déjà largement sur le marché. La démonstration d'un produit nouveau sera beaucoup plus difficile.

Concrètement, un projet innovant peut être développé sans écrire une seule ligne de code, tandis qu'un projet développé par une équipe de développeurs expérimentés peut ne pas répondre aux critères du CII.

Pourquoi le no-code suscite-t-il parfois des interrogations lors d'un contrôle ?

Parce que le no-code est souvent perçu comme un moyen de développer plus vite et avec moins de ressources, certains en déduisent qu'un projet réalisé sur une plateforme no-code est nécessairement moins innovant. 

Pourtant, cette idée ne repose sur aucun critère fiscal. La doctrine du CII ne distingue pas les projets selon la technologie utilisée.

Lors d'un contrôle, le sujet n'est généralement pas le nombre de lignes de code produites, mais la capacité de l'entreprise à démontrer les travaux réalisés, les choix de conception effectués et les résultats obtenus. D'où l'importance d'une documentation solide.

Exemple - Entreprise A

L'entreprise conserve les cahiers des charges, les comptes rendus d'ateliers, les maquettes, les rapports de tests et les résultats obtenus lors des phases pilotes. Plusieurs années plus tard, elle est capable de démontrer précisément comment le prototype a évolué.

Exemple - Entreprise B

Le produit a été développé rapidement grâce au no-code mais aucun historique des décisions, des tests ou des améliorations n'a été conservé. Lors d'un contrôle, l'entreprise peine à démontrer la réalité de la démarche d'innovation.

Le véritable risque n'est donc pas le no-code lui-même. Le risque réside souvent dans l'absence de preuves permettant de justifier les travaux réalisés.

Comment démontrer l'innovation d'un projet no-code ?

La démonstration doit reposer sur des éléments concrets.

L'administration doit comprendre :

• quel problème a été identifié ;
• pourquoi les solutions existantes étaient insuffisantes ;
• quelles performances nouvelles étaient recherchées ;
• comment le prototype a été conçu ;
• quels tests ont été réalisés ;
• quels résultats ont été obtenus.

On ne le répète jamais assez pour n’importe quel projet, mais c’est d’autant plus vrai dans un environnement no-code. Vous devez conserver les documents suivants a minima : 

• les cahiers des charges ;
• les maquettes fonctionnelles ;
• les parcours utilisateurs ;
• les comptes rendus d'ateliers ;
• les résultats des tests ;
• les rapports de validation ;
• les versions successives du prototype.

Exemple - Entreprise A

Une startup développe un outil permettant aux techniciens de maintenance industrielle de diagnostiquer certaines anomalies à partir d'une combinaison de données opérationnelles et de photographies terrain. Plusieurs versions du prototype sont testées auprès d'utilisateurs pilotes avant d'être validées. Chaque évolution est documentée et justifiée.

Exemple - Entreprise B

Une entreprise remplace plusieurs fichiers Excel par une application no-code centralisée. Le gain de productivité est réel, mais il ne démontre pas nécessairement l'existence d'un produit nouveau par rapport aux solutions déjà disponibles sur le marché.

La différence entre les deux situations ne tient pas au no-code. Elle tient à la capacité à démontrer une innovation au sens fiscal du terme.

Les dépenses liées au no-code sont-elles éligibles au CII ?

Elles peuvent l'être lorsque les dépenses concernent directement les opérations de conception du prototype ou de l'installation pilote.

La doctrine fiscale relative aux dépenses éligibles du CII détaille notamment les règles applicables aux dépenses de personnel directement affectées aux opérations d'innovation ainsi qu'à certaines dépenses externalisées.

Selon les situations, cela peut concerner :

• des chefs de projet innovation ;
• des product managers ;
• des UX designers ;
• des concepteurs fonctionnels ;
• des profils techniques impliqués dans le prototype.

Exemple - Entreprise A

Le product manager, le designer UX et le responsable innovation participent directement à la conception du prototype. Une partie de leur temps peut potentiellement être retenue dans l'assiette du CII.

Exemple - Entreprise B

L'équipe marketing intervient uniquement après la mise sur le marché du produit. Ces dépenses relèvent de l'exploitation commerciale et non des travaux d'innovation.

Comme le rappelle le BOFiP, ce n'est pas l'intitulé du poste qui est déterminant mais la participation effective aux travaux d'innovation éligibles.

L'élément déterminant reste toujours le lien direct entre le collaborateur et les travaux d'innovation réalisés. À l'inverse, les dépenses liées à l'exploitation courante, au déploiement commercial ou à la maintenance du produit ne relèvent généralement pas du périmètre du CII.

Quels sont les principaux risques pour un projet no-code déclaré au CII ?

• Le premier risque consiste à confondre innovation et transformation digitale.

Digitaliser un processus ou automatiser une tâche ne suffit pas nécessairement à caractériser un produit nouveau.

• Le deuxième risque consiste à surestimer l'originalité du projet.

Une fonctionnalité nouvelle pour l'entreprise n'est pas forcément nouvelle pour le marché.

Or la doctrine administrative du CII apprécie la nouveauté du produit au regard des solutions déjà disponibles sur le marché concerné et non au regard des seules pratiques internes de l'entreprise.

• Le troisième risque concerne la documentation.

Les projets no-code sont souvent développés rapidement et de manière très itérative. Sans documentation, il devient difficile de démontrer plusieurs années plus tard la réalité des travaux engagés.

Enfin, certaines entreprises assimilent à tort la personnalisation d'un outil existant à une démarche d'innovation.

Or l'administration fiscale s'intéresse principalement à la création d'un produit nouveau et non à l'adaptation d'une solution déjà disponible.

Points clés à retenir

• Le no-code est compatible avec le CII. Aucun texte fiscal n'exclut un projet au motif qu'il est développé en no-code ou en low-code.
• Le critère central reste la nouveauté du produit. L'administration vérifie avant tout la valeur apportée par la solution par rapport aux offres déjà présentes sur le marché.
• L'innovation s'apprécie au niveau du marché. Une fonctionnalité nouvelle pour votre entreprise n'est pas nécessairement innovante au sens fiscal.
• Le no-code ne remplace pas l'innovation. Un projet développé sur Bubble ou FlutterFlow peut être éligible, mais uniquement s'il répond aux critères du CII.
• La documentation est essentielle. Cahiers des charges, maquettes, tests et rapports de validation constituent souvent les meilleures preuves en cas de contrôle.
• Les projets no-code doivent être documentés avec rigueur. Les choix de conception, les itérations et les résultats obtenus doivent pouvoir être justifiés.
• La transformation digitale ne suffit pas toujours. Automatiser un processus ou remplacer un outil existant ne permet pas automatiquement de bénéficier du CII.
• Certaines dépenses peuvent être retenues. Les dépenses de personnel et certaines prestations externes sont éligibles lorsqu'elles participent directement aux travaux d'innovation.
• Une analyse préalable permet de sécuriser la déclaration. Avant de solliciter le CII, il est recommandé de vérifier la solidité des critères d'éligibilité et des éléments de preuve disponibles.
• Retrouvez notre ebook CII pour aller plus loin !

FAQ

Un projet développé sur Bubble ou FlutterFlow peut-il être éligible au CII ?

Oui. L'éligibilité dépend de la nouveauté du produit et des travaux de conception réalisés, pas de l'outil utilisé pour le développer.

Le fait de ne pas écrire de code est-il un motif de rejet ?

Non. Aucun texte fiscal ni aucune doctrine administrative ne prévoit une telle exclusion.

Une application métier interne développée en no-code est-elle éligible ?

Pas automatiquement. Il faut démontrer l'existence d'un produit nouveau présentant des performances supérieures par rapport aux solutions déjà disponibles sur le marché.

Les dépenses de personnel liées au projet peuvent-elles être retenues ?

Oui, sous certaines conditions. Les collaborateurs concernés doivent être directement affectés aux opérations de conception du prototype ou de l'installation pilote.

Le no-code augmente-t-il le risque de contrôle fiscal ?

Non. En revanche, une documentation insuffisante peut fragiliser la capacité de l'entreprise à démontrer la réalité de sa démarche d'innovation, quel que soit le mode de développement utilisé.

Le no-code n'est ni un passeport vers le CII, ni un motif d'exclusion. Comme pour tout projet d'innovation, l'essentiel reste la capacité à démontrer la nouveauté de la solution développée et la réalité des travaux réalisés. La technologie utilisée n'est qu'un moyen ; c'est le projet qui est évalué.