Process for creating US

The word "release" appears in the Scrum Guide one time.  

 If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Increments are expected to be usable but that does not mean it has to be released.  The team needs to be making progress towards the ability to release a feature and are able to gain feedback on the increments from the stakeholders.  

so if I want to make sure we build incrementally, I have to modify the interface to have some kind of transition state to be able to potentially deliver something at the end of a sprint (3 weeks).

Why do you have to do that? Product Backlog Items need to be of a size that the Developers feel they can accomplish the work in a single Sprint.  I realize that your group uses "INVEST" but the "S" does not mean as small as you can get it, it means small enough to fit into a single Sprint. The Developers are the ones that decide if that condition is met. Based upon your comments, all the Developers are doing during the Sprints is cleaning up the prototype to be production worthy.  So have them create items in the Product Backlog to describe that work and not something to build it from scratch.  That gives them the ownership of their own work.  Refinement is an ongoing process.  You have reached another state of refinement where the Developers provide the details of the final work that is needed not to build something all over again.

Thank you for your answer! Actually prototype is a big word, we just have the UI, so developers have to develop it from scratch. I was hence thinking to find a way to split the functionality in ways that don’t modify anything in the UI (for example a vertical slice of functionality with the whole interface A) but if it’s too big, should I create a simpler interface that’s not the final expected result in order to be able to have a US that fits in a sprint? The developers feel that even if it takes more than a sprint it’s useless to go through an artificial US that won’t be released, they prefer to go for the whole.

Today, we divide the conception into 3 parts : getting the broad requirements into a word document (using a MOSCOW) then we have a meeting to make sure the requirements fit their expectations, then we present a prototype of the solution, we have a second meeting to make sure it fits the requirements, and then we split the functionality into user stories.

If it was possible to do that, you wouldn't need Scrum at all. You wouldn't need to Sprint and obtain empirical feedback. You'd already know that requirements match expectations and the solution fits.

Product Backlog refinement is the art and science of making work ready for Sprint Planning, meaning that the Developers are satisfied it can be Done in a Sprint. If they are using the INVEST criteria to guide them, they really don't need to take things further than that.

Note that this is a quality concern, not a functional one. Scrum is about learning to build the right thing at the right time. Functionally, a delivered feature might not be what's needed. What we would then have, however, is the empirical evidence we need to try something else in a future Sprint, reassured each time that if we crash and burn, it's not a quality problem.

Just because you have the entire interface, does not mean you have to make it all functional at once.  The splits that have been suggested still have validity.  You are using the interface created for the prototype and introducing code to make it function.  Ask the Developers to explain how they will approach the actual work. I'm going to assume that they have some plan for how to break the work into tasks.  If that is the case, then bring enough tasks into the Sprint to deliver a usable increment.  Also keep in mind that there is nothing in the Scrum Guide that says the increment has to usable by the stakeholders. The guide just states it must be usable.  If at the end of the Sprint, there is an increment that is usable by the Developers, that expectation has been met.  Ideally, you will still be able to show some functionality to the stakeholders so it would be good to have some of the functionality of the User Interface working.  But it does not have to be completely functional. 

What has worked for some of my Scrum Teams is for the Product Owner to create a Product Vision and then to get together in a room for an afternoon (or virtually on a collaboration tool such as Mural) to create a story map. You can google how to do create story maps and look at Jeff Patton's website; it isn't hard to learn. Your Product Backlog then gets populated from the story map. The vertical stories hanging from each epic help visualize priority.

The story map will also allow the folks in that session to consider and visualize a first release (perhaps a Minimal Viable Product) and future releases.

Perhaps a rough prototype can be sketched out on paper, but to get the best product, I would think prototyping would be done every Sprint and then turned into an Increment, rather than done upfront like a waterfall project. Scrum is iterative (i.e. a Sprint) and incremental. 

You may want to check out books such Lean Startup, Lean UX, and other blogs here: https://www.scrum.org/resources/suggested-reading-professional-scrum-user-experience