AFAIK, and IANAL, in France, you'd still need to support 2 versions from day one:
https://en.wikipedia.org/wiki/Toubon_Law
I just internationalised a UK startup to enter other EU markets, since doing so it has been a non-trivial amount of extra work just to keep it up. Not immense, but definitely a drag. There's all sorts of little extra cognitive overhead once a product supports two languages. Button widths, text lengths, layouts, email layouts, normalised date formats, even icons (for example we'd used a £ icon to indicate paid). We use SendWithUs templates, and now we have to upload all the translations too as part of a deploy. And that's not even counting the extra time to do the translation, upload it, etc.
Silly little things that a lot of programmers use without thinking, like basic date formatting like "ddd HH:mm", you simply can't do that any more. You need to agree shared formats and they don't always fit as you'd like them to, or quite convey the info you want them to. For example recently I'd have loved to say "Today 9:15", "Tomorrow 12:15", "Thu 14:15" or "Next Week", just for one specific place. But then you need to create a function to perform l10n on that and suddenly you're adding a big bit of extra functionality and you end up falling back on the shared .ToL10nDateTime() even though it's objectively worse at conveying the info you need to convey.
We've got a bunch of work in Alpha at the moment that's English only because we were under such time pressure to deliver it for one client. The time to insert all the place holders and do the client-side i18n meant we've parked it all to get the functionality out of the door for that client. Even though it will take more time in the long run.
As I understand it, a hypothetical French startup equivalent would be breaking the law by doing that.