Le salaire d’un développeur à l’étranger compte-t-il en JEI ?

Quand on échange avec des fondateurs de startups ou des DAF, cette question revient souvent : si je recrute un développeur très senior au Portugal, au Maroc, en Europe de l’Est ou en Amérique latine, est-ce que son salaire peut m’aider à atteindre le seuil JEI ?

C’est une excellente question, surtout aujourd’hui où le recrutement international est devenu la norme pour accéder rapidement à des profils tech rares.

La bonne nouvelle, c’est que le fait qu’un développeur travaille à l’étranger n’empêche absolument pas, à lui seul, l’intégration de sa rémunération dans le ratio JEI.

En revanche, tout va dépendre de la manière dont vous l’avez recruté, de la façon dont son temps est affecté à la R&D, et surtout de la manière dont la charge est portée dans vos comptes.

Autrement dit : ce n’est pas la géographie qui fait le risque, c’est le montage juridique et comptable. Nous allons vous expliquer ça de manière concrète.

Le salaire d’un développeur à l’étranger peut-il entrer dans le ratio JEI ?

Oui, dans beaucoup de cas, la réponse est oui, selon l’administration fiscale. Ce qui compte pour la JEI, ce n’est pas l’adresse du développeur, mais le fait que sa rémunération corresponde à une véritable dépense de personnel liée à des travaux de recherche et développement.

Comme le montre le BOFIP, pour qu’un salaire soit retenu sereinement, il faut généralement pouvoir cocher plusieurs cases :

• le développeur travaille sur des sujets comportant une incertitude technique réelle ;
• son temps est affecté à la création d’une nouvelle brique produit, d’un algorithme, d’une architecture complexe ou d’un prototype ;
• la société française supporte bien la charge ;
• le temps passé sur ces travaux peut être justifié et tracé.

Dit autrement, si votre développeur conçoit, par exemple :

• un moteur de recommandation propriétaire,

• une couche d’orchestration temps réel,

• une architecture IA innovante,

• un protocole de synchronisation inédit,

• une infrastructure à très forte contrainte de scalabilité,

alors on est souvent dans une zone favorable.

À l’inverse, si la mission consiste principalement à :

• corriger des bugs connus,

• intégrer des API standards,

• maintenir une base de code existante,

• produire du front classique,

• faire du delivery client,

la dépense sera beaucoup plus difficile à défendre comme R&D.

Le seuil de 15 % existe-t-il encore ?

C’est probablement la confusion la plus fréquente. Pendant longtemps, beaucoup d’articles et de cabinets parlaient du ratio JEI à 15 %. C’était vrai, mais ce n’est plus la règle générale. Aujourd’hui, pour les dossiers récents,l’administration fiscale vise un seuil de 20 % des charges engagées au titre de la R&D.

Le seuil de 15 % ne subsiste plus que pour des situations transitoires sur d’anciens exercices. Concrètement, quand vous vous posez la question pour un recrutement en 2026, il faut raisonner ainsi : Est-ce que cette rémunération contribue à mon ratio JEI de 20 % ?

C’est ce raisonnement qui doit guider vos simulations financières, votre BP et vos recrutements tech.

Le full remote à l’étranger change-t-il quelque chose ?

Dans la majorité des cas, non. Le fait qu’un développeur soit en full remote depuis Lisbonne, Barcelone, Dubaï ou Buenos Aires ne change pas la nature fiscale de son travail. 

Ce qui intéresse l’administration, c’est la nature des travaux réellement menés.

Si la personne contribue à résoudre un verrou technique, à mener des expérimentations ou à faire émerger une innovation logicielle, le fait qu’elle travaille hors de France n’est pas le sujet principal. 

En revanche, dans la pratique, le full remote impose une exigence supplémentaire : mieux documenter le travail effectué.

Je conseille toujours aux clients de renforcer la preuve via :

• des tickets Jira explicitement taggés R&D ;
• des feuilles de temps mensuelles, pour cela, voir nos templates ;
• des documents d’architecture ;
• des comptes rendus d’essais ;
• des POC et benchmarks ;
• des notes sur les échecs et itérations.

Plus la personne est loin géographiquement, plus il faut que la piste d’audit soit propre.

Le mode de recrutement change-t-il le traitement JEI ?

Oui, et c’est souvent là que tout se joue.

En pratique, deux développeurs qui font exactement le même travail technique peuvent avoir un traitement fiscal très différent selon leur mode d’embauche.

Entreprise A : une startup SaaS française recrute un senior backend engineer basé au Portugal en CDI direct. Il consacre 70 % de son temps à la conception d’un moteur de compression propriétaire capable de réduire les coûts d’infrastructure en temps réel. 

La société suit précisément les sprints R&D et archive les benchmarks de performance. Dans ce cas, la quote-part de 70 % du coût chargé est généralement la plus simple à défendre dans le ratio JEI.

Le CDI direct avec la société française est-il le meilleur cas ?

Clairement oui. Quand votre société française porte directement le contrat de travail, on est dans le cas le plus simple à défendre.

La logique est fluide :

• vous êtes l’employeur ;
• la charge salariale est dans vos comptes ;
• la personne est intégrée à votre équipe R&D ;
• son temps peut être ventilé entre innovation et hors innovation.

Dans ce cas, la quote-part réellement consacrée à la R&D a de bonnes chances d’entrer dans le ratio JEI.

Exemple client :

• startup SaaS française,
• CTO basé à Paris,
• senior backend engineer basé au Portugal,
• contrat direct porté par la SAS,
• 70 % du temps sur un moteur de compression propriétaire.

Dans ce cas, 70 % du coût chargé est généralement défendable dans l’assiette.

Entreprise B : une marketplace française recrute un machine learning engineer en Amérique latine via Deel. Sur le plan opérationnel, le profil travaille comme un membre clé de l’équipe IA. Mais comptablement, la facture inclut salaire, frais de conformité locale et marge EOR. Avant de l’intégrer au ratio JEI, l’entreprise doit retraiter la facture pour isoler la part réellement défendable, sous peine de surévaluer artificiellement ses dépenses de R&D.

Un EOR type Deel ou Remote est-il plus risqué ?

EOR : une organisation tierce qui vous permet d'embaucher du personnel à l'étranger en agissant en votre nom en tant qu'employeur légal dans le pays concerné.

La réponse est oui, il faut être plus prudent.C’est le sujet du moment pour les startups en hypercroissance. Sur le plan opérationnel, l’EOR est parfait : recrutement rapide, conformité locale, paie simplifiée. Mais sur le plan fiscal, la question est plus subtile.

Très souvent, la facture EOR apparaît comptablement comme :

• une prestation externe,
• un coût RH externalisé,
• une refacturation de mise à disposition.

Du coup, on n’est plus automatiquement dans la dépense de personnel interne. Et c’est là que le ratio JEI peut être fragilisé. Avant d’intégrer ces montants, il faut analyser :

• la structure du contrat tripartite ;
• la propriété intellectuelle ;
• le lien hiérarchique réel ;
• la ventilation entre frais EOR et coût salarial ;
• la possibilité d’assimiler la charge à de la sous-traitance R&D.

Notre avis Myriad

Ne jamais intégrer un coût Deel ou Remote sans revue préalable par le cabinet spécialisé qui vous accompagne ou l’expert-comptable.

Entreprise C : une fintech française travaille depuis 18 mois avec un développeur freelance basé en Serbie, quasiment à temps plein. Le CTO le considère comme un membre de l’équipe, mais juridiquement il facture en prestation mensuelle. La tentation est forte d’intégrer 100 % de la facture dans le ratio JEI. Pourtant, sans analyse précise du contrat, de la propriété intellectuelle et de l’éligibilité en sous-traitance R&D, c’est typiquement le genre de poste qui peut être remis en cause lors d’un contrôle.

Et le freelance étranger ?

Le freelance est encore plus sensible. Même si la personne travaille à plein temps avec vos équipes, la dépense ressemble juridiquement à une prestation. Elle peut parfois être valorisée dans une logique CIR selon les cas, mais pour le ratio JEI, il faut être beaucoup plus conservateur.

Le piège classique : 

c’est la startup qui considère un freelance long terme comme un quasi-salarié et intègre 100 % de la facture dans ses dépenses R&D. En cas de contrôle fiscal, c’est souvent l’un des premiers postes revus.

Comment bien documenter la part R&D du développeur ?

C’est ici que beaucoup de dossiers perdent en qualité. Un bon dossier JEI ne repose pas uniquement sur la conviction du CTO. Il repose sur des preuves contemporaines et traçables.

Voici ce que nous, mais surtout l’administration fiscale aime voir dans un dossier solide :

• une fiche de mission claire : elle doit expliquer le rôle du développeur dans la résolution d’un verrou technique ;
• des timesheets réalistes : pas besoin d’être au quart d’heure, mais il faut une logique mensuelle ou par sprint ;
• une documentation produit : ADR, schémas d’architecture, benchmark, documentation de protocole ;
• des preuves d’expérimentation : essais, itérations, versions abandonnées ;
• une note d’éligibilité annuelle : pourquoi le travail relève de la R&D fiscale.

Exemple de ventilation réaliste :

• 50 % : recherche sur architecture distribuée,
• 20 % : POC IA,
• 20 % : delivery produit,
• 10 % : maintenance.

Dans ce cas, on retient généralement 70 % maximum.

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

Voici les erreurs que nous voyons le plus souvent chez nos clients.

Confondre innovation produit et R&D fiscale

C’est sans doute l’erreur la plus fréquente. Le fait d’avoir un produit nouveau, une UX brillante ou une fonctionnalité inédite sur le marché ne suffit pas à créer de la R&D au sens JEI.Le test n’est pas commercial, il est technique et fiscal.

La vraie question est : existait-il une incertitude technique réelle qu’une équipe compétente ne pouvait pas lever immédiatement avec l’état de l’art ?

Par exemple :

• créer un nouvel outil SaaS dans un marché existant → pas forcément R&D

• développer un moteur de recommandation qui résout un problème de cold start inédit → potentiellement oui

• concevoir une architecture distribuée avec contraintes temps réel extrêmes → souvent défendable

• refaire un workflow plus fluide → rarement suffisant

Le piège startup classique consiste à dire : “notre produit est innovant, donc toute la tech est JEI”. En contrôle, ce raisonnement tombe très vite.

Intégrer 100 % du salaire par confort

C’est extrêmement fréquent avec :

• CTO
• lead engineer
• VP Engineering
• founding engineer
• head of AI

Sur le papier, ce sont des profils très techniques. Mais fiscalement, seul le temps réellement consacré à la R&D est retenu. La doctrine est très claire : lorsqu’un salarié n’est affecté qu’en partie à la recherche, sa rémunération est prise au prorata du temps effectivement consacré, et tout forfait de confort est exclu.

Or, dans la vraie vie d’une startup, un senior fait aussi :

• management d’équipe
• recrutement
• mentoring
• arbitrages produit
• réunions investisseurs
• support incidents
• run et dette technique
• roadmap trimestrielle

Tout cela n’entre pas automatiquement dans le ratio JEI. Le piège classique : prendre le salaire chargé du CTO et le passer à 100 % “parce qu’il est le cerveau tech”.C’est souvent le premier point challengé.

Mal traiter les coûts EOR

Sujet très fréquent avec les startups remote-first. Quand un développeur passe via un EOR (Deel, Remote, Oyster, etc.), la tentation est d’intégrer la facture totale dans les dépenses JEI. C’est fragile.

Il faut distinguer :

• la rémunération brute + charges sociales obligatoires
• la marge EOR
• les frais RH / onboarding
• les frais de conformité locale
• les frais de change ou de paiement

Seule la partie correspondant à une véritable dépense de personnel supportée par la société est défendable dans le ratio JEI. Les frais administratifs ou la marge de l’intermédiaire n’ont pas naturellement vocation à suivre.

Le piège fréquent : intégrer 12 000 € de facture mensuelle EOR alors que 2 000 € correspondent à des frais de structure. Sur plusieurs profils et 12 mois, l’impact sur le seuil JEI peut être énorme.

Oublier la preuve

C’est le risque le plus sous-estimé. Même lorsqu’une dépense est parfaitement légitime, elle devient fragile si vous ne pouvez pas expliquer précisément :

• quel était le verrou technique
• quelles hypothèses ont été testées
• quel temps a été passé
• quels salariés sont intervenus
• quels livrables ont été produits
• pourquoi la solution n’était pas évidente

La doctrine impose précisément de pouvoir justifier le temps d’affectation réel des personnels de recherche. Concrètement, les meilleures preuves en startup sont :

• tickets Jira taggés R&D
• RFC / design docs
• PR liées à des spikes techniques
• benchmarks d’architecture
• notebooks de recherche IA
• compte-rendus d’expérimentation
• timesheets simples mais datées
• décisions d’abandon d’une piste

Le piège classique : “on reconstruira le dossier si l’administration nous contrôle.” Deux ans plus tard, personne ne se souvient du vrai niveau d’incertitude.

Comment raisonner simplement en tant que dirigeant ?

Si on devait l’expliquer à un client en une phrase : Si votre développeur étranger travaille réellement sur un verrou technique pour votre startup, et que la société française supporte proprement la charge, alors oui, son coût peut souvent contribuer au seuil JEI.

Le vrai sujet n’est pas “étranger ou non”.

Le vrai sujet, c’est :

• qui l’emploie,
• sur quoi il travaille,
• combien de temps,
• quelles preuves vous gardez.

C’est cette logique simple qui permet d’éviter les mauvaises surprises.

Points clés à retenir

Si vous devez retenir l’essentiel en tant que dirigeant, DAF ou CTO, voici la grille de lecture la plus utile.

• Le seuil JEI à viser est désormais de 20 % : beaucoup d’entreprises continuent de raisonner avec l’ancien seuil de 15 %, ce qui fausse les simulations de BP, les recrutements et parfois même la stratégie de financement. Pour tous les dossiers récents, il faut projeter votre ratio avec le seuil de 20 %.
• Le pays de résidence du développeur n’est pas le vrai sujet : Portugal, Maroc, Espagne, LATAM ou Europe de l’Est, cela ne change pas automatiquement l’éligibilité. Ce qui compte, c’est la nature technique des travaux et la façon dont la charge est portée.
• Le montage contractuel fait toute la différence : un CDI direct porté par la société française reste le cas le plus simple. À l’inverse, un EOR ou un freelance impose une revue beaucoup plus prudente avant intégration dans le ratio.
• Seule la quote-part réellement R&D doit être retenue : dans la vraie vie, très peu de développeurs sont à 100 % sur des verrous techniques toute l’année. Il faut isoler la part innovation du management, du support, du delivery et du run.
• La documentation est votre meilleure assurance : timesheets, tickets, benchmarks, ADR, POC, notes techniques et arbitrages d’architecture sont souvent ce qui sauve un dossier en cas de contrôle.
• Les coûts EOR doivent être retraités intelligemment : intégrer une facture Deel ou Remote brute sans distinguer marge, frais administratifs et coût salarial réel est une erreur classique.
• Le bon réflexe est de raisonner par personne et par sprint : plutôt que de faire un calcul annuel théorique, il est souvent plus robuste de suivre la quote-part R&D au fil des sprints ou des milestones produit.
• Pour aller plus loin, consultez notre ebook JEI !

FAQ

Un développeur basé au Portugal peut-il compter dans le ratio JEI ?

Oui, très souvent. Le fait qu’il soit au Portugal n’a pas d’impact direct. Si votre SAS française supporte le coût, qu’il travaille sur un sujet présentant une vraie incertitude technique et que vous pouvez documenter son temps, la quote-part R&D peut généralement être intégrée.

Exemple concret : un backend engineer au Portugal qui travaille sur un moteur d’indexation propriétaire ou une architecture distribuée temps réel peut parfaitement contribuer au ratio.

Une facture Deel ou Remote peut-elle être retenue ?

Oui, mais jamais automatiquement. C’est précisément le type de sujet qui nécessite une revue ligne par ligne. Il faut distinguer :

• le coût salarial refacturé ;
• la marge EOR ;
• les frais RH et conformité ;
• les coûts administratifs ;
• la part réellement affectée à la R&D.

Dans certains cas, une partie peut être défendable. Dans d’autres, il vaut mieux rester conservateur.

Peut-on intégrer 100 % du salaire d’un lead developer ?

En pratique, c’est rare. Même un profil très senior passe souvent du temps sur :

• le management technique,
• la coordination d’équipe,
• les arbitrages roadmap,
• le recrutement,
• les échanges clients ou produit.

La bonne approche consiste à isoler uniquement la quote-part consacrée à la résolution de verrous techniques.

Le full remote augmente-t-il le risque fiscal ?

Pas sur le fond. Le risque ne vient pas du remote lui-même, mais du fait que les entreprises documentent souvent moins bien le travail de profils internationaux. Plus la personne est éloignée, plus il faut une discipline documentaire forte : tickets, temps passés, POC, benchmarks, décisions techniques.

Un freelance long terme peut-il entrer dans le seuil ?

C’est le cas le plus sensible. Même s’il travaille quasiment comme un salarié, sa facture reste souvent juridiquement une prestation. Il faut donc analyser si la dépense peut être traitée dans une logique de sous-traitance R&D ou si elle doit être exclue du ratio JEI.

Par prudence, beaucoup de dossiers préfèrent ne pas la survaloriser.

Checklist

Voici la checklist que je recommande aux clients avant d’intégrer un développeur étranger dans le ratio JEI.

1) Vérifier la nature des travaux

• Le développeur travaille sur un verrou technique réel et documentable
• Il ne s’agit pas seulement de maintenance, run ou delivery
• Le projet comporte des phases d’expérimentation, test ou itération
• Les échecs techniques et pivots sont conservés comme preuves

2) Vérifier le montage contractuel

• Le contrat est porté directement par la société française
• Si EOR : la structure de facturation a été revue
• Si freelance : le traitement fiscal a été validé
• La propriété intellectuelle est bien cédée à l’entité française

3) Fiabiliser le suivi du temps

• Une ventilation mensuelle ou par sprint existe
• La quote-part R&D est réaliste (50 %, 70 %, etc.)
• Les temps de management et delivery sont exclus
• Les feuilles de temps concordent avec Jira / Linear / Git

4) Sécuriser la piste de preuve

• Les tickets R&D sont identifiés clairement
• Les ADR et schémas d’architecture sont archivés
• Les benchmarks, POC et prototypes sont conservés
• Une note annuelle explique pourquoi la dépense est éligible

5) Contrôler l’impact sur le ratio

• Le calcul utilise bien le seuil de 20 %
• Les coûts non éligibles ont été retraités
• Les factures EOR incluent uniquement la part défendable
• Le ratio final a été revu avec l’expert-comptable ou le fiscaliste

Besoin de sécuriser votre ratio JEI ?

Si vous avez recruté des profils tech à l’étranger et que vous voulez savoir ce qui entre réellement dans votre seuil JEI de 20 %, le plus efficace est de faire une revue rapide par personne, contrat et sprint.

En pratique, c’est souvent ce qui permet de :

• sécuriser le statut JEI avant un contrôle ;
• éviter de surévaluer les coûts Deel ou freelance ;
• fiabiliser le BP et les projections de trésorerie ;
• préparer une levée avec un dossier fiscal propre ;
• aligner finance, CTO et expert-comptable.

Le bon réflexe : prenez vos 5 plus gros profils R&D (France + international), isolez leur quote-part innovation et challengez la documentation disponible. Vous verrez immédiatement si votre ratio est robuste ou artificiellement gonflé.

Vous souhaitez vérifier si vos projets sont éligibles ? Contactez nos experts pour un diagnostic CIR gratuit et confidentiel, ou lisez notre ebook JEI pour mieux comprendre.