Bonjour, est-ce que tu ne peux pas te servir du CMS headless uniquement pour fournir l'API (donc il ne distribue pas les fichiers de l'application client) puis déployé l'application client a part (par exemple si tu utilises Heroku pour héberger l'application, tu hébergerais deux applications une qui contient l'API donc le CMS Headless et l'autre qui contient l'application front-end donc l'application React.js)
Puis avec l'application React.js, tu consommes l'API via des requêtes réseaux
MDN fetch API Guide.
La documentation de Strapi propose une implémentation de React.js sous cet forme-là.
Strapi integrations React.js
Pour illustré si dans le composant Article tu as besoin de demander un article à ton API tu pourrais le faire de cette façon-là:
Le côté un peu non-pratique c'est que tu te retrouves avec deux applications à gérer,
mais tu as aussi l'avantage que les applications sont découplées,
tu peu par exemple imaginer une deuxième interface (pour mobile où application de bureau par exemple),
qui consommerait la même API.
Dans un cas plus en lien avec ton application,
tu as un composant Contact, qui présente un formulaire de contact et une fonction qui écoute la soumission du formulaire,
qui pour l'instant ce contente de loggé les données envoyées:
Si c'est ton API Headless qui doit validé/stocké les données du formulaire,
ici tu pourrait envoyer une requête réseaux de la même façon qu'avec le composant illustratif Article
A noter que dans une application React.js lorsque qu'on envoie une requête réseau comme dans les codes illustratif que j'ai montré, il faudrait utiliser un AbortController pour pouvoir annulé la requête si le composant ce fait démonté de l'arbre avant que la requête n'est aboutie, le problème si on le fait pas c'est que la réponse de la requête peut être traitée par notre composant "out of tree" et le composant va essayer de mettre à jour sont état local alors qu'il est démonté, ce qui provoquera une erreur Can't perform a React state update on an unmounted component