What is the ideal cycle to create a functionality in scrum?

Hum, posted too soon.

Currently, regarding features, we gather requirements with a MOSCOW, do the detailed UI to show and have approval from stakeholders and then develop based on this extensive detailed UI (we copy paste the UI into the separate user stories). Does scrum have some guidance on how the UI/UX is integrated? Do you do the whole UI of the functionality before developing? I feel it gives good projection to stakeholders but it feels a bit like a waterfall thing…

A good user story is a placeholder for a conversation about a potential requirement. The value of it lies in the conversations that are to be had during the Sprint in which it is actioned. Think of it as a catalyst for future creativity and collaboration. It isn't really meant to be a projection at all.

It is waterfall.  If the stakeholders "sign off" on an interface but don't receive a fully functional one for weeks/months, then you lose the ability to adapt to changes in needs.  The way that the world's economy changes, what you need today may not be what you need in 6 weeks.  Use the "detailed UI" as the starting point but get feedback from the stakeholders as often as you can to make sure that you are still on the path to what is needed at the time it is delivered. Don't be afraid to change it.  In fact, be prepared to make changes more than once during the delivery cycle.

I thought doing extensive research beforehand, showing a detailed interface was more like a waterfall model but if I’m willing to do some increments at each sprint , get feedback from stakeholders at the retro than we fall back into an agile delivery. I feel this link is quite a good representation of my understanding (team A) @Daniel : https://cutlefish.substack.com/p/tbm-752-two-bets

Big question : who are the stakeholders actually? Currently, in my company, those are the CEO, head of sales, head of customer care. But to remove uncertainty shouldn’t we ask the clients directly? How do you integrate them in the process at the retro or somewhere else when what you’ve developed is not releasable yet because it is just usable by developers or has not reached the MMF state?

Big question : who are the stakeholders actually? Currently, in my company, those are the CEO, head of sales, head of customer care.

Here is the official Scrum.org glossary definition of stakeholder. 

• Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Those folks you mentioned are most likely stakeholders.

But to remove uncertainty shouldn’t we ask the clients directly? How do you integrate them in the process at the retro or somewhere else when what you’ve developed is not releasable yet because it is just usable by developers or has not reached the MMF state?

Interviewing customers, something a Product Owner might do, could be valuable. The entire Scrum Team can get feedback from stakeholders on the latest product Increment at every Sprint Review. Yet that's not nearly as valuable as releasing a Product Increment early and often to get some validated learning. Everything else is just a guess that the features added to the Increment is valuable until you actually out it in the hands of your end users/customers. The best Scrum Teams run short Sprints and release multiple times a Sprint to gain feedback and reduce risk. In Scrum there's no excuse to delay empiricism (transparency, inspection, adaption).

A quote from Henry Ford:

• When asked about customer input in the development of the Ford Model T, Henry Ford famously said, "If I had asked people what they wanted, they would have said faster horses."