CII : Notre V2 / V3 est-elle encore éligible au CII ?

Une V1 a déjà été lancée, le produit existe, mais la V2 ou la V3 transforme tellement l’usage qu’on se demande si le CII reste possible. Cette question, nous l’entendons régulièrement de la part de DAF de PMEs en phase de croissance. 

La réponse est nuancée : oui, une V2 ou V3 peut rester éligible au Crédit d’Impôt Innovation (CII), mais seulement si elle constitue une véritable nouvelle génération produit, pas une simple itération de roadmap. 

Le fait d’écrire « V2 » dans Jira ou sur votre site ne suffit ni à exclure ni à sécuriser le dispositif. Le vrai sujet est de savoir si vous êtes face à une mise à jour enrichie ou à une nouvelle génération produit qui transforme réellement l’usage. 

Qu'est-ce que le CII finance exactement ? 

Avant de trancher sur l'éligibilité d'une V2 ou V3, il est utile de rappeler ce que le CII finance (et ce qu'il ne finance pas). Le dispositif couvre les dépenses de conception de prototypes ou d'installations pilotes de produits nouveaux présentant des performances supérieures à celles des produits existants sur le marché. 

Le mot clé est « sur le marché ». Une innovation n'est pas ce que vous n'aviez jamais fait en interne, mais ce que le marché ne propose pas encore, ou pas de cette manière. C'est la frontière qui distingue une modernisation d'une vraie démarche CII. 

Un projet est généralement éligible lorsqu'il réunit les caractéristiques suivantes : 

• Des preuves de performance accumulables : tests, benchmarks, PoC, mesures comparatives permettant de documenter l'apport fonctionnel 

• Un prototype : l'innovation se construit par itérations successives - premières explorations, ajustements, stabilisation - et non par un déploiement unique 

• Un gain fonctionnel mesurable pour l'utilisateur final : quelque chose que l'utilisateur peut faire demain qu'il ne pouvait pas faire hier 

Ce qui généralement n’est pas éligible 

Plusieurs catégories de travaux sont souvent présentées comme innovantes, mais ne répondent pas aux critères du CII : 

• La refonte UI/UX purement esthétique, sans nouvelle performance fonctionnelle 

• L'automatisation de flux internes sans création de valeur nouvelle pour le marché 

• La réarchitecture technique (microservices, migration cloud, refonte de stack) si l'expérience utilisateur reste identique 

• Le rattrapage de fonctionnalités déjà standard chez les concurrents 

• La recombinaison de technologies existantes sans création de capacité nouvelle 

Bon à savoir 

Le meilleur filtre reste simple : qu'est-ce que l'utilisateur peut faire demain qu'il ne pouvait pas faire hier ? Si la réponse est « rien de fondamentalement différent », on est probablement face à une modernisation, pas à une innovation au sens du CII.  

Pour aller plus loin sur ce sujet, consultez notre article Comment déterminer si mon innovation est vraiment innovante pour le CII ?. 

La V2 doit-elle être plus qu’une simple amélioration ? 

La réponse est oui. Le CII n’a jamais été pensé pour financer les mises à jour d’un produit existant. Une V2 ou V3 devient éligible lorsqu’elle crée une rupture mesurable sur au moins l’un des axes suivants : 

• Les fonctionnalités : le produit intègre de nouveaux usages absents en V1, qui modifient réellement la proposition de valeur 

• L’ergonomie : les parcours évoluent de façon significative pour transformer l’expérience utilisateur, pas simplement moderniser le design 

• La performance technique : gain objectivable sur la vitesse, la robustesse ou la qualité de traitement 

• Le workflow utilisateur : la logique d’utilisation change en profondeur, avec de nouvelles séquences métier ou une orchestration plus intelligente 

• La catégorie de produit : la V2 fait évoluer le produit vers un nouveau positionnement ou un nouvel usage, modifiant sa place sur le marché 

Le point déterminant n’est pas la quantité de fonctionnalités ajoutées, mais la capacité à démontrer que la nouvelle version introduit une transformation perceptible, mesurable et différenciante pour l’utilisateur final. 

Exemple 

Entreprise A transforme une V1 de dashboard cybersécurité en V2 pilotée par IA, avec réduction de 80 % des faux positifs et nouveau cockpit analyste : dossier solide. 

Entreprise B ajoute 15 filtres et une meilleure navigation à sa V1 : intérêt business réel, mais éligibilité CII souvent faible. 

Quels sont les critères qui rendent une V2 / V3 défendable ? 

Toutes les V2 ne se valent pas fiscalement. Pour un DAF, le bon raisonnement consiste à vérifier si la nouvelle version change au moins l’un de ces axes : la proposition de valeur, le workflow utilisateur ou la profondeur technico-fonctionnelle visible. Plus le changement touche ces dimensions, plus le dossier CII gagne en substance. 

1) Une rupture fonctionnelle visible 

La nouvelle version doit apporter des capacités réellement supérieures à la version précédente : 

• Moteur prédictif absent en V1 

• Orchestration temps réel 

• Nouveau builder no-code 

• Couche collaborative synchrone 

2) Une nouvelle ergonomie qui change le workflow 

Une refonte UX purement esthétique est rarement suffisante. En revanche, une nouvelle logique d’interaction peut renforcer fortement le dossier : 

• 70 % de clics en moins : la nouvelle interface réduit drastiquement le nombre d’actions nécessaires pour accomplir une tâche clé 

• Onboarding divisé par 4 : le temps de prise en main diminue fortement grâce à une nouvelle séquence de découverte 

• Suppression d’étapes : validations ou ressaisies inutiles disparaissent grâce à une réorganisation profonde du workflow 
• Nouvelle visualisation décisionnelle : l’utilisateur accède à une lecture inédite de ses données, changeant la manière de piloter son activité 

Le point déterminant n’est pas le « beau design », mais la capacité à démontrer que la structure même du parcours utilisateur a été repensée pour créer un usage sensiblement nouveau. 

3) Un vrai périmètre prototype 

Même sur une V2, il faut pouvoir isoler des phases d’expérimentation clairement identifiables : 

• Une phase de test restreinte avec un premier cercle limité d’utilisateurs pour valider les nouveaux usages 

• Un pilote chez un client, expérimenté dans des conditions réelles sur un périmètre maîtrisé 

• Un environnement de test isolé hors production, permettant d’expérimenter sans risque sur l’existant 

• Un groupe utilisateur témoin pour comparer les comportements et les taux d’adoption entre V1 et V2 

• Un environnement miroir permettant de comparer les résultats et d’objectiver les gains réels 

4) Bien distinguer la V2 innovante de la maintenance de la V1 

Le piège le plus structurel consiste à mélanger dans un même récit projet : 

• La V2 en phase de prototypage : travaux exploratoires, tests de nouveaux usages, validations de concepts 

• La maintenance de la V1 : corrections de bugs, mises à jour mineures, support correctif 

• Le support des grands comptes : demandes spécifiques, adaptations contractuelles, ajustements clients 

• Le stock de correctifs : anomalies, tickets de résolution, améliorations incrémentales 

La robustesse du dossier repose sur cette frontière : les temps, livrables et arbitrages liés à la phase exploratoire de la V2 doivent être documentés séparément de tout ce qui concerne l’exploitation de la V1. 

Quand une V2 devient-elle un nouveau sous-produit autonome ? 

Dans beaucoup de startups tech, la V2 n’est plus seulement une version. Elle devient un sous-produit autonome avec sa propre proposition de valeur, sa propre logique de vente, parfois son propre buyer persona. Les cas les plus caractéristiques : 

• Un assistant IA commercialisé en option, qui crée un usage autonome et une promesse distincte 

• Une V3 analytique avec une tarification propre, introduisant de nouveaux tableaux de pilotage vendus selon un modèle spécifique 

• Une verticalisation sectorielle, où le produit est reconfiguré pour répondre aux processus d’un marché vertical (santé, finance, RH…) 

• Un studio de configuration no-code issu d’outils internes, devenu interface produit autonome mise à disposition des clients 

Lorsque la nouvelle version peut être packagée séparément, ouvrir une nouvelle ligne de revenu ou répondre à un nouveau buyer persona, on s’approche très souvent d’un prototype de nouveau produit — ce qui renforce fortement la logique CII. 

Exemple 

Entreprise A transforme son back-office interne en V3 « Ops Studio » commercialisable à part entière : excellent angle CII. 

Quels sont les pièges les plus fréquents ? 

Les dossiers V2 / V3 se fragilisent souvent après une levée de fonds. La roadmap mélange soudain innovation produit, dette technique, sécurité, scalabilité et support entreprise. Le label « V2 » devient alors un fourre-tout budgétaire. 

Premier piège : tout mettre dans la V2 

Une roadmap V2 sur 12 mois contient souvent : 

• Un prototype de rupture : la partie naturellement rattachable au CII, lorsqu’elle vise à tester un nouvel usage ou une proposition de valeur différenciante 

• Une migration technique : changement d’infrastructure, refonte du socle ou évolution de stack, généralement non éligible 

• De la dette technique : travaux de nettoyage, refactorisation ou stabilisation du code existant 

• Des exigences de sécurité : conformité, renforcement des accès, amélioration de la résilience 

• Le support des grands comptes : développements spécifiques, adaptations contractuelles, demandes clients particuliers 

Deuxième piège : utiliser le numéro de version comme argument 

Le fait d’écrire « V2 » dans Jira ou Notion n’a aucune valeur en soi. Ce qui compte, c’est la supériorité objectivable par rapport à la version précédente. 

Troisième piège : confondre refonte technique et nouvelle génération 

Une réécriture technique complète n’est pas automatiquement un dossier CII si l’usage utilisateur reste identique. Migration d’infrastructure, refonte de stack ou modernisation applicative ne créent pas nécessairement une nouvelle génération produit. 

Quatrième piège : intégrer 100 % des coûts CTO et produit 

Une V2 mobilise souvent beaucoup de management, de coordination et de go-to-market. Ces éléments doivent être exclus du périmètre CII. Le 100 % « par confort » est rarement robuste face à un vérificateur. 

Bon à savoir 

Le vrai risque est le glissement progressif : une V2 démarre comme prototype, puis devient du standard sans que le périmètre fiscal soit ajusté. Les signaux à surveiller : la bêta est ouverte à tous les clients, les tickets deviennent majoritairement correctifs, la roadmap inclut surtout dette et support. À ce stade, la quote-part CII doit souvent être revue à la baisse. 

Comment prouver la supériorité de votre V2 ? 

La comparaison V1 vs V2 est souvent la pièce maîtresse du dossier. Plus l'écart est mesurable, plus le dossier est solide. 

Plus cette comparaison est objectivée, plus la V2 / V3 devient défendable. 

CIR vs CII : quel séquençage idéal sur une V2 ? 

Le cas classique en software est bien identifié : CIR sur le moteur ou le verrou technique qui rend la V2 possible, CII sur la nouvelle génération produit donc  le cockpit, le workflow ou la nouvelle ergonomie. 

Exemple 

Entreprise A développe sous CIR un moteur d’optimisation temps réel. Une fois le verrou levé, la V2 transforme ce moteur en workspace analyste prédictif : la couche produit devient un excellent sujet CII. 

Cette articulation reflète très bien la réalité des roadmaps SaaS et IA modernes. Les deux dispositifs ne s’excluent pas ; ils se complètent en couvrant deux couches distinctes du même projet. 

Points clés à retenir 

• Une V2 ou V3 peut rester éligible au CII si elle constitue une véritable nouvelle génération produit. La nouvelle version doit transformer de façon visible l’usage, le workflow ou la proposition de valeur, pas simplement enrichir l’existant. 

• Le critère central reste la supériorité fonctionnelle, technique ou ergonomique. Moins de clics, plus d’automatisation, nouveau cockpit, IA embarquée, réduction du temps de traitement : la V2 doit objectivement faire mieux que la V1. 

• Une simple itération de roadmap ou une refonte technique ne suffit généralement pas. Migration d’architecture, dette technique ou redesign UI restent souvent insuffisants si l’expérience utilisateur ne change pas réellement. 

• Le périmètre prototype doit être isolé au sein de la nouvelle version. Une roadmap V2 mélange souvent prototype, maintenance V1, sécurité et support. Seule la quote-part liée à la nouvelle génération testée en bêta ou pilote est pertinente. 

• La comparaison V1 vs V2 est souvent la meilleure preuve. Benchmarks de temps, clics, adoption, feedbacks bêta, nouveaux cas d’usage impossibles auparavant : plus l’écart est mesurable, plus le dossier est solide. 

• L’articulation CIR moteur / CII couche produit est souvent la lecture idéale. Les deux dispositifs se complètent et couvrent deux couches distinctes du même projet. 

Les meilleurs dossiers V2 reposent sur une qualification précise du périmètre, pas sur l’ambition de la roadmap. Si vous souhaitez vérifier si votre V2 ou V3 constitue un dossier CII défendable, contactez nos experts pour un diagnostic gratuit et confidentiel. 

FAQ 

Une V2 / V3 peut-elle encore passer au CII ? 

Oui, si elle constitue une nouvelle génération produit avec des gains significatifs démontrés par rapport à la version précédente. 

Une refonte UX peut-elle suffire ? 

Seulement si elle transforme réellement le workflow et apporte des gains mesurables. Un redesign purement esthétique ne suffit pas. 

Une réécriture technique complète est-elle éligible ? 

Pas automatiquement. Si l’usage reste identique pour l’utilisateur final, le dossier est généralement faible. 

Peut-on combiner CIR et CII sur une V2 ? 

Oui, c’est même fréquent dans les SaaS et projets IA : CIR sur le verrou technique, CII sur la couche produit.