Deux écosystèmes qui ne se concurrencent pas
La France apporte une tradition de recherche et un cadre réglementaire construit ; l'Inde apporte une échelle d'exécution et un vivier d'ingénierie sans équivalent. Ces forces ne se disputent pas le même terrain, et c'est ce qui rend la coopération réaliste.
Je suis arrivé d'Inde enfant, j'ai fait ma thèse en France, et j'ai travaillé sur les deux terrains. Le constat n'est pas diplomatique : les deux écosystèmes échouent sur des choses différentes.
La France produit d'excellents modèles et peine à les déployer à grande échelle. L'Inde déploie à une échelle que l'Europe ne connaît pas et importe l'essentiel de son cadre normatif.
La complémentarité est donc structurelle, pas conjoncturelle.
Ce qui se construit concrètement
Les projets qui avancent portent sur la formation, le transfert de méthode et l'accès au marché, pas sur le développement conjoint de modèles. C'est moins spectaculaire et beaucoup plus solide.
La formation d'abord : les écoles et programmes qui font circuler des étudiants et des intervenants dans les deux sens produisent un effet durable, parce qu'il porte sur des personnes et non sur un protocole d'accord.
Le transfert de méthode ensuite. Le cadre européen sur l'IA est devenu une référence internationale, y compris pour des entreprises qui n'y sont pas soumises. Savoir le mettre en œuvre est une compétence exportable.
L'accès au marché enfin, dans les deux sens : une entreprise française qui veut opérer en Inde et une entreprise indienne qui veut vendre en Europe rencontrent des difficultés symétriques, dont beaucoup sont réglementaires.
Où la coopération bute réellement
- Le transfert de données, qui reste la question la plus dure et la moins traitée dans les annonces.
- L'écart de tarification des outils, qui crée des conditions d'exercice différentes pour les mêmes équipes. Voir le même produit à 6 euros et à 20 euros.
- La reconnaissance des qualifications, qui freine la circulation des profils bien plus que les visas.
- La dépendance commune à des infrastructures de calcul situées ailleurs. Voir financer le calcul sans entrer au capital.
Ce que le cadre européen exporte réellement
Ce n'est pas le texte lui-même qui s'exporte, c'est la méthode : documenter, tracer, superviser, désigner un responsable. Cette méthode est utile indépendamment de toute obligation.
Une entreprise indienne qui vend en Europe doit s'y conformer. Mais celles que je vois adopter ces pratiques ne le font pas d'abord pour ça : elles le font parce qu'un système documenté et journalisé se diagnostique, et que c'est un avantage d'exploitation.
C'est le constat que je fais partout : les exigences réglementaires qui tiennent sont celles qui servent aussi à l'ingénierie. Les autres sont contournées ou subies.
Ce recouvrement entre conformité et bonne exploitation est développé dans ce qui doit exister avant l'échéance.
Ce qu'une entreprise française peut en tirer
Un accès à une capacité d'exécution qu'elle ne trouve pas chez elle, à condition de ne pas la traiter comme un centre de coûts. La distinction décide de la réussite.
Le schéma qui échoue est ancien et connu : sous-traiter l'exécution en gardant la conception, avec une spécification écrite d'un côté et exécutée de l'autre. Sur des systèmes d'IA, il échoue plus vite encore, parce que les décisions qui comptent se prennent au contact des données réelles.
Le schéma qui fonctionne intègre les équipes sur le même travail, avec les mêmes accès et les mêmes arbitrages. Cela suppose de traiter la question du transfert de données en premier, et non en dernier.
C'est la même logique que celle du travail en immersion que je décris dans Forward Deployed Engineer : le métier, pas le titre : les décisions se prennent là où sont les données et les utilisateurs.
La question qui décide d'un partenariat sur ce terrain
« Où vivront les données, et sous quel droit ? » Elle se traite avant la signature. Traitée après, elle transforme un partenariat en projet de mise en conformité.
Ce que j'observe des deux côtés
L'écart d'appétence pour le risque est plus déterminant que l'écart technique, et personne n'en parle. C'est ce qui surprend le plus les équipes qui travaillent ensemble pour la première fois.
Une équipe française mettra plus de temps à mettre en service, avec un dossier plus complet et moins d'incidents. Une équipe indienne mettra en service plus vite, corrigera en production, et itérera davantage.
Aucune des deux approches n'est supérieure. Elles conviennent à des contextes différents, et leur rencontre produit des frictions prévisibles qu'il vaut mieux nommer au démarrage qu'découvrir au troisième mois.
La règle que j'applique : décider explicitement, projet par projet, quel régime s'applique. Un système qui touche des données personnelles suit le régime prudent ; un outil interne d'exploitation suit le régime rapide.
Questions fréquentes
Sur quoi porte réellement la coopération ?
Sur la formation, le transfert de méthode et l'accès au marché, pas sur le développement conjoint de modèles. Ces trois axes sont moins spectaculaires et plus solides.
Où la coopération bute-t-elle ?
Sur le transfert de données, l'écart de tarification des outils, la reconnaissance des qualifications, et une dépendance commune à des infrastructures de calcul situées ailleurs.
Qu'exporte le cadre européen ?
La méthode plutôt que le texte : documenter, tracer, superviser, désigner un responsable. Les entreprises l'adoptent parce qu'un système journalisé se diagnostique, pas seulement par obligation.
Quel schéma de collaboration fonctionne ?
L'intégration des équipes sur le même travail, avec les mêmes accès. La sous-traitance d'exécution échoue vite sur des systèmes d'IA, où les décisions se prennent au contact des données réelles.