CII : votre projet de logiciel est-il éligible ?

Pour un CEO ou un CFO de startup tech, la question revient souvent au mauvais moment : au moment de clôturer, quand plus personne ne se souvient précisément de ce qui relevait du prototype et de ce qui relevait de la roadmap classique. Pourtant, le Crédit d’Impôt Innovation (CII) peut avoir un impact direct sur votre trésorerie, votre autonomie de trésorerie et même la qualité de votre documentation en due diligence.

Le problème, c’est que beaucoup d’équipes produits assimilent encore : nouveauté produit = éligibilité CII, alors qu’en pratique, c’est beaucoup plus exigeant. 

Comme l’explique la doctrine administrative, dans le cadre d’une démarche de Crédit Impôt Innovation (CII), pour un projet logiciel, le vrai sujet, pour votre entreprise, est de savoir si vous avez conçu un prototype ou une installation pilote d’un produit nouveau présentant des performances supérieures, notamment sur le plan fonctionnel, technique, ergonomique ou de l’éco-conception. 

Cet article vous donne une grille de lecture rapide, fiable et orientée décision, pensée pour les dirigeants de petites structures tech qui veulent savoir si le dossier mérite d’être creusé.

Pourquoi ce sujet est-il devenu critique pour les CFO de startups ?

Depuis deux ans, beaucoup de PME tech ont professionnalisé leur approche du CIR, mais le CII reste souvent sous-exploité ou mal cadré. Pourtant, c’est là que vous avez une belle carte à jouer.

Le problème n’est pas l’absence d’innovation. Il vient surtout du fait que les équipes confondent :

• innovation produit : ajout d’un nouveau module, d’un cockpit, d’un builder ou d’une couche IA qui améliore réellement l’offre, mais sans toujours constituer un prototype autonome au sens fiscal ;
• différenciation commerciale : évolutions très utiles pour mieux vendre (packaging enterprise, nouvelles permissions, reporting, white-label, connecteurs), qui créent de la valeur business sans relever nécessairement d’une supériorité produit éligible au CII ;
• accélération de roadmap : multiplication des mises en production, recrutement de nouvelles équipes produit et technique, réduction de la dette technologique ou accélération du délai de mise sur le marché après une levée, qui augmentent la vitesse d’exécution mais pas automatiquement l’éligibilité
• véritable prototype éligible au sens fiscal : périmètre clairement isolé, testé en bêta, sandbox ou pilote, avec une supériorité fonctionnelle, technique ou ergonomique objectivable par rapport à l’existant.

Quels sont les enjeux pour le DAF ?

Pour un DAF, l’enjeu dépasse largement la fiscalité :

• amélioration de la trésorerie, grâce à une meilleure combinaison entre aides publiques, allègements et financement ; pensez d’ailleurs au financement par dette ! 
• allongement de la visibilité financière, en donnant à l’entreprise plusieurs mois supplémentaires avant un nouveau besoin de financement ;
• réduction de la consommation nette de cash, notamment sur les équipes R&D et produit ;
• meilleure qualité du dossier investisseurs, avec une documentation plus propre et plus rassurante ;
• plus de sérénité lors des audits d’acquisition ou de levée, grâce à un périmètre bien justifié ;
• diminution du risque de correction après l’opération, qu’il s’agisse d’une levée de fonds, d’une acquisition ou d’un audit approfondi.

C’est particulièrement vrai pour les sociétés SaaS, IA, cyber, fintech et software infra, où une partie de la roadmap crée régulièrement de nouveaux produits ou sous-produits à forte valeur d’usage.

Quel est LE principe clé du CII que vous devez retenir ?

C’est très simple : il finance un prototype, pas la roadmap du quotidien.  La première confusion consiste à considérer que toute avancée logicielle est “innovante” au sens fiscal. Ce n’est pas le cas.

Le CII vise la conception de prototypes ou d’installations pilotes d’un produit nouveau. Pour un éditeur logiciel, cela correspond souvent à :

• un nouveau module produit créant une vraie rupture d’usage ;
• un moteur métier inédit ;
• une nouvelle couche ergonomique améliorant fortement le workflow ;
• un pilote IA qui transforme la manière d’utiliser le produit ;
• une nouvelle ligne de produit SaaS testée avec des bêta-clients.

A l’inverse, qu’est-ce qui relève rarement du CII ?

À l’inverse, relèvent rarement du CII les corrections de bugs, refontes front classique, intégration d’API standard, migration cloud, optimisation incrémentale et backlog de maintenance.

La bonne question qu’il faut se poser est la suivante : sommes-nous en train de créer un prototype de produit nouveau, ou simplement d’améliorer une version déjà commercialisée ?

Quel test simple pour savoir si votre logiciel est éligible ?

Voici 4 questions simples à vous poser pour savoir si votre logiciel est éligible.

1) Est-ce réellement nouveau sur votre marché ?

Le CII s’apprécie par rapport au marché de référence, pas seulement à votre produit actuel.

Entreprise A développe un cockpit IA pour équipes conformité qui réduit de 70 % le temps de revue documentaire par rapport aux solutions du marché. Le pilote testé chez 3 clients est un bon candidat CII.

Entreprise B ajoute des dashboards plus lisibles et une meilleure navigation à son SaaS existant. Valeur business forte, mais dossier CII faible.

2) Est-on encore au stade prototype ou pilote ?

Le CII est plus robuste avant le lancement commercial large. Une fois la fonctionnalité déployée à tous les clients, les itérations ultérieures relèvent souvent du “delivery produit” classique.

Attention à éviter l’innovation trop commerciale.

3) Peut-on isoler le périmètre de coûts ?

Le CFO doit pouvoir isoler :

• les développeurs affectés au prototype ;
• les environnements de test dédiés ;
• les UX tests ;
• les benchmarks ;
• la sous-traitance spécifique CII ;
• les coûts de design produit liés au pilote.

4) Peut-on prouver la performance supérieure ?

Les mots “plus intelligent”, “plus rapide”, ou “plus scalable” ne suffisent pas.

Il faut des preuves tangibles :

• benchmark ;
• temps de traitement ;
• baisse du nombre de clics ;
• automatisation d’étapes ;
• gains mesurés ;
• ergonomie objectivée par tests utilisateurs.

N’hésitez pas à nous contacter si vous avez la moindre question à ce sujet, nous serons ravis de vous aider.

Comment reconnaître un vrai prototype logiciel éligible au CII ?

Dans la pratique, les meilleurs dossiers CII en software partagent souvent quatre caractéristiques très concrètes.

1) Un périmètre produit autonome

Le prototype doit pouvoir être décrit comme un objet produit identifiable et isolable.

Il ne s’agit pas d’une simple succession de tickets dans la roadmap, mais d’un périmètre cohérent que l’on peut nommer et tester : un nouveau cockpit, un module métier inédit, une nouvelle interface de pilotage, un builder, un moteur visible côté utilisateur ou encore un nouveau workflow SaaS.

La question simple à se poser est : “Peut-on décrire ce prototype comme une brique produit autonome ?” Si la réponse est non, le dossier devient souvent fragile.

2) Une supériorité démontrable

Le prototype doit apporter une amélioration fonctionnelle, technique ou ergonomique objectivable par rapport à l’existant.

Par exemple :

• réduction du nombre de clics
• automatisation d’une tâche manuelle
• nouveau niveau de collaboration
• temps de traitement divisé
• visibilité métier impossible auparavant
• nouveau cas d’usage rendu possible

Le CII ne rémunère pas la nouveauté “marketing”, mais une performance supérieure démontrable.

3) Une phase de test réelle

Un vrai prototype passe généralement par une bêta, une sandbox, un pilote client ou un environnement de test isolé.

Cette phase est essentielle, car elle permet de montrer que l’entreprise n’est pas dans une simple mise en production classique, mais dans une démarche de validation d’une nouvelle génération produit.

Les feedbacks bêta, tests UX, benchmarks ou itérations de design deviennent alors des pièces centrales.

4) Des coûts isolés et traçables

Le prototype doit être suivi avec un périmètre analytique propre : temps passés, tickets, sprints, design docs, benchmarks, tests, feedbacks.

Sans cette isolation, le risque est de mélanger prototype, maintenance, dette technique et delivery.

Pourquoi est-il plus que nécessaire de distinguer Innovation Produit vs Innovation de Service ?

C’est souvent le problème des logiciels et des applis : on confond la nouveauté de l'usage avec la nouveauté technique. Pour sécuriser votre dossier, il ne faut pas confondre l’innovation produit (qui doit être quantifiable) avec l’innovation de service.

• Le cas Dogami : Prenons l’exemple d’une application comme Dogami, pour trouver des gens avec qui promener son chien. Oui, c’est innovant, mais si ça repose sur des technologies très éprouvées, ce n'est pas de l'innovation produit au sens fiscal.
• L’exigence du benchmark et du quantifiable : L'innovation ne se décrète pas, elle se mesure. Vous devez impérativement établir un benchmark, citer des solutions concurrentes et dire en quoi votre solution est mieux d’un point de vue physique / caractéristiques.

La fonctionnalité peut être innovante, mais vous devez insister sur le quantifiable pour expliquer en quoi c'est mieux :

• Vitesse d'exécution.
• Simplicité technique.
• Temps de chargement.
• Espace de stockage, etc.

Quels pièges éviter ?

Le plus gros risque est ensuite de surqualifier la roadmap.

Piège n°1 : Assimiler toute la roadmap au CII

Très fréquent après une levée. Une roadmap de 12 mois peut ne contenir que 10 à 20 % de véritable prototype produit, le reste relevant de la maintenance, de la sécurité, de la scalabilité, du support enterprise ou du refactoring.

Piège n°2 : Inclure 100 % du salaire du CTO

Même dans une petite structure, un CTO consacre du temps au recrutement, management, incidents de production, architecture transverse, relation investisseurs ou support avant-vente.

Piège n°3 : Seule la quote-part directement liée au prototype est défendable.

Exemples pour mieux comprendre : 

• Entreprise A retient 30 % du CTO, justifiés par les sprint reviews et arbitrages du prototype : dossier solide.
• Entreprise B retient 100 % “car il pilote l’innovation” : dossier fragile.

Piège n°4 : Oublier la preuve

Le meilleur prototype devient indéfendable sans preuves. Les meilleures pièces sont souvent déjà disponibles : tickets Jira taggés, PR GitHub, specs produit, design docs, tests UX, benchmarks et feedbacks bêta.

CIR vs CII pour les logiciels : lequel choisir ?

C’est souvent le point le plus important pour les sociétés tech. Le CIR finance la levée d’une incertitude technique ou scientifique. Le CII finance la transformation de cette innovation en prototype produit présentant des performances supérieures.

En logiciel, le séquencement classique est le suivant :

• phase 1 : CIR :  résolution du verrou technique (moteur IA, orchestration, algo, infra complexe)
• phase 2 : CII :  prototype produit, UX, workflow, cockpit, bêta version

Exemple : 

Entreprise A conçoit un moteur de détection temps réel avec une vraie incertitude sur la latence : CIR. Puis elle transforme ce moteur en interface analyste avec gains UX démontrés : CII.

Cette articulation est souvent idéale pour les startups SaaS et IA.

Quels projets logiciels sont souvent de bons candidats ?

Les meilleurs dossiers concernent souvent :

• copilotes IA métier ;
• moteurs de workflow ;
• outils no-code ;
• simulation / digital twin ;
• produits cyber ;
• couches temps réel ;
• nouvelles interfaces métier complexes.

Exemples : 

• Entreprise A crée un espace de travail d’analyse du risque assisté par IA divisant le temps d’analyse par 3 : bon profil CII.

• Entreprise B refond l’interface utilisateur React (bibliothèque Javascript) du même espace d’analyse du risque : profil faible.

Points clés à retenir

• Le CII concerne uniquement les PME au sens communautaire
  Avant même d’analyser le projet, il faut valider les seuils d’effectif, de chiffre d’affaires et d’indépendance capitalistique. Beaucoup de dossiers techniquement solides tombent simplement parce que ce prérequis n’a pas été vérifié assez tôt.
• Un logiciel peut être éligible s’il correspond à un prototype de produit nouveau.
  L’enjeu n’est pas d’avoir “un logiciel innovant” au sens marketing, mais bien un prototype ou pilote identifiable, avec un périmètre autonome, une logique produit claire et une phase de test avant industrialisation.
• La supériorité fonctionnelle, technique ou ergonomique doit être démontrable.
  C’est souvent le cœur du dossier. Il faut pouvoir montrer, preuves à l’appui, que le prototype fait objectivement mieux : moins d’actions utilisateur, meilleur taux d’automatisation, workflow plus rapide, UX transformée, précision accrue, ou réduction du temps de traitement.
• La roadmap courante n’est généralement pas suffisante.
  Les sprints de delivery, la maintenance, les évolutions demandées par les clients, les optimisations de performance ou les refontes visuelles restent rarement dans le périmètre. Le CII vise la création d’un nouveau produit ou sous-produit, pas l’amélioration continue de l’existant.
• Il faut isoler précisément les coûts.
  Côté finance, la solidité du dossier repose sur la capacité à distinguer sans ambiguïté : temps salariés, UX, benchmarks, environnements pilotes, sous-traitance dédiée, et coûts exclus (run, incidents, support, maintenance). Si le CFO ne peut pas reconstituer le périmètre rapidement, le dossier est mécaniquement plus fragile.
• La qualité de la preuve conditionne souvent la solidité du dossier.
  Les meilleurs dossiers s’appuient sur des éléments déjà existants : tickets Jira, pull requests, specs produit, comptes rendus de tests utilisateurs, résultats bêta, benchmarks, captures d’écran de pilotes. En pratique, la documentation pèse souvent autant que la nature du projet lui-même.
• Bien articuler CIR en amont et CII en aval renforce fortement le dispositif.
  Dans beaucoup de sociétés software, la trajectoire idéale est : CIR pour la levée du verrou technique, puis CII pour la transformation en prototype produit supérieur. Cette séquence reflète mieux la réalité d’une roadmap tech et sécurise la logique économique du dossier.
• Le bon moment pour piloter le CII est pendant l’année, pas à la clôture.
  Plus le suivi est fait tôt, plus il est simple d’isoler les coûts, de conserver les preuves et de distinguer le prototype de l’exploitation courante (run)V. Pour un CFO, c’est souvent un sujet de process plus que de fiscalité pure.

FAQ

Une fonctionnalité SaaS peut-elle être éligible ?

Oui, si elle fait partie d’un prototype ou pilote de produit nouveau avec performance supérieure démontrée.

Un projet IA est-il un bon candidat ?

Souvent oui, surtout lorsqu’il crée un nouveau workflow utilisateur ou une nouvelle ergonomie métier.

Une refonte UX peut-elle passer ?

Une refonte cosmétique seule, rarement. Une nouvelle logique d’interaction avec gains mesurables peut être défendable.

Peut-on combiner CIR et CII ?

Oui, très souvent en logiciel, à condition de bien séparer les dépenses.

Checklist pour votre projet avant dépôt

• nous sommes bien une PME au sens communautaire
• le projet correspond à un prototype ou pilote
• il n’était pas encore industrialisé
• nous avons une preuve de performance supérieure
• les temps salariés sont tracés
• la roadmap run / maintenance est exclue
• la sous-traitance est isolée
• le CIR et le CII sont séparés
• le dossier peut être expliqué clairement en 10 minutes

Un dernier réflexe avant de déposer

Si votre équipe finance n’est pas capable d’expliquer simplement : ce qui est nouveau, pourquoi c’est supérieur, et quels coûts appartiennent exactement au prototype, alors le dossier mérite probablement un cadrage complémentaire.

Une revue rapide avant dépôt permet souvent de sécuriser le périmètre, mieux articuler CIR et CII, et éviter les erreurs de quote-part salariale. C’est généralement le type d’échange qui fait gagner le plus de sérénité à un CFO… pour moins d’une heure de travail préparatoire. N’hésitez pas à nous contacter. 

Nous organisons un webinaire sur le CII le 5 mai, voici le lien pour vous inscrire !