Le manuel de Frascati, publié par l'OCDE, est le texte de référence international pour définir une activité de recherche et développement. En France, il structure l'appréciation de l'éligibilité au CIR. Il énonce cinq critères qui doivent être réunis simultanément : quatre sur cinq ne suffisent pas.
Appliqués à un projet logiciel, ces critères ont chacun un piège spécifique. Les voici dans l'ordre, avec ce qui passe et ce qui ne passe pas.
1. Nouveauté : nouveau pour qui ?
L'activité doit viser un résultat nouveau. Le piège tient à l'échelle de référence : la nouveauté s'apprécie par rapport à l'état des connaissances du domaine, pas par rapport à ce que sait faire l'entreprise.
| Ne remplit pas le critère | Peut le remplir |
|---|---|
| Réécrire un module existant dans un langage plus moderne | Concevoir un algorithme dont aucune approche publiée n'atteignait la garantie de complexité recherchée |
| Intégrer une bibliothèque tierce, même complexe | Étendre le domaine de validité d'une méthode connue au-delà de ce que la littérature établissait |
| Développer une fonctionnalité inédite dans votre produit mais courante sur le marché | Obtenir un résultat qu'aucune solution accessible ne permettait d'atteindre dans les contraintes posées |
La question à se poser en entretien : « si un ingénieur compétent d'une autre entreprise du secteur avait eu ce problème, aurait-il su le résoudre avec les moyens publiés ? » Si la réponse est oui, il n'y a pas de nouveauté au sens de Frascati.
2. Créativité : un apport conceptuel, pas un effort
Le critère exige la formulation de concepts ou d'hypothèses originales. En logiciel, il est régulièrement confondu avec l'ingéniosité de mise en œuvre.
Optimiser finement un pipeline de données, concevoir une architecture élégante ou trouver un contournement astucieux à une limitation d'API relève du savoir-faire, parfois de haut niveau, mais pas de la créativité au sens du manuel. Ce qui la caractérise, c'est une hypothèse formulée puis testée : « nous supposons que telle représentation permet de contourner telle limite théorique ».
3. Incertitude : le critère décisif
La plupart des dossiers logiciels rejetés se perdent ici. L'incertitude porte sur le résultat, pas sur le chemin ni sur le budget.
- « Nous ne savions pas combien de temps cela prendrait » : incertitude de projet, non éligible.
- « Nous ne savions pas quelle bibliothèque choisir » : incertitude de conception, non éligible.
- « Nous ne savions pas si un résultat exploitable était atteignable dans ces contraintes, et l'état de l'art ne permettait pas de trancher » : incertitude scientifique ou technique, éligible.
4. Systématicité : la trace, pas l'intention
Les travaux doivent être menés de façon planifiée et documentée. C'est le critère le plus facile à satisfaire sur le fond et le plus souvent perdu sur la forme : les équipes logicielles travaillent de manière systématique, mais leur trace est dispersée dans des outils qui ne parlent pas le langage du dossier.
Les pièces qui l'établissent existent presque toujours : tickets et épopées, messages de commit, comptes rendus de revues techniques, résultats de campagnes de tests, comparatifs de performance versionnés, décisions d'architecture consignées. Encore faut-il aller les chercher et les rattacher aux opérations. C'est le travail d'extraction que dymension prend en charge sur des volumes documentaires que personne ne dépouille à la main.
5. Transférabilité et reproductibilité
La connaissance produite doit pouvoir être transférée et reproduite par un tiers compétent. Ce critère est rarement contesté seul, mais il est révélateur : si les résultats de l'opération ne sont consignés nulle part et reposent sur la mémoire d'un développeur, c'est en général que la systématicité fait défaut elle aussi.
Un résultat négatif est parfaitement transférable : savoir qu'une approche ne fonctionne pas dans des conditions données est une connaissance. Les dossiers qui n'exposent que des succès se privent d'une part de leur démonstration.
Appliquer les critères au bon niveau
L'erreur structurante consiste à appliquer les cinq critères au projet plutôt qu'à l'opération de R&D. Un projet logiciel de dix-huit mois contient typiquement : de l'intégration, du développement courant, de la reprise de dette technique, et parfois trois mois de travaux réellement incertains.
Qualifier le projet entier revient à noyer la partie éligible dans un ensemble qui ne l'est pas, et à offrir au vérificateur une cible facile. Qualifier opération par opération donne un dossier plus petit, plus dense et nettement plus solide. Sur la manière de découper, voir notre méthode de rédaction du dossier technique.
Un bon dossier logiciel est souvent un dossier plus court que ce que l'entreprise espérait, et beaucoup plus difficile à contester.
Questions fréquentes
- Le développement d'une application avec de l'IA est-il éligible au CIR ?
- Pas automatiquement. Intégrer un modèle existant via une API relève de l'intégration technologique et non de la R&D. L'éligibilité suppose une incertitude propre : par exemple une méthode d'entraînement, d'évaluation ou de contrainte du modèle que l'état de l'art ne permettait pas de résoudre dans les conditions posées.
- Faut-il remplir les cinq critères de Frascati ou seulement certains ?
- Les cinq doivent être réunis simultanément pour qu'une activité soit qualifiée de R&D. En pratique, l'incertitude et la nouveauté sont les plus discriminants ; la systématicité et la transférabilité sont surtout des questions de preuve et de traçabilité.
- La refonte technique d'un produit existant peut-elle être éligible ?
- Rarement dans son ensemble, parfois pour une opération identifiée. Une migration ou une modernisation relève du développement courant. Si un verrou précis apparaît en cours de refonte, par exemple un objectif de performance qu'aucune approche connue n'atteignait dans les contraintes du système, cette opération-là peut être qualifiée isolément.
- Où trouver le manuel de Frascati ?
- Il est publié par l'OCDE et accessible publiquement. En France, son application au crédit d'impôt recherche est précisée par la doctrine administrative publiée au BOFiP et par le guide du CIR édité par le ministère de l'Enseignement supérieur et de la Recherche.