Poker planning

If you are going to the trouble of estimating time, why do you need to use Story Points?  Just use the time estimates.  Story points are meant to be relative estimates.  You estimate stories relative to other stories.  Story A is smaller than Story B but larger than Story C.  The fibonacci sequence is used because it not linear but shows a gradually increasing progression.  Trying to decide the difference between a 3 or a 4 is more difficult than between a 3 and 5.  

Story Points are not required by Scrum, just as User Stories are not.  All that is required is a Product Backlog Item that is fully understood by the Scrum Team and that the Developers feel can be done in a single Sprint. Product Backlog Items reach the "can be done in a single sprint" state by the practice of refinement.  This is from the Scrum Guide's section that describes the Product Backlog.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Notice that the "such as" statement.  It doesn't say "must have" or even "should have". It indicates that those are details that could be provided.  The following sentence provides even more emphasis that the attributes will vary based upon need.

Your team appears to want time estimates so use time estimates.  Adding the additional mapping of hours to story points justs adds complexity and obfuscates information. 

We are currently reviewing the way we calculate story points on user stories because we feel we don’t have a good proportionality in the time spent between a 1 and 2 story points US for example.

Is this suspected at the time? If so, why don't the Developers just take the matter into account in Sprint Planning, and adjust accordingly?

The purpose of estimation is for Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control. So as long as they can say "that's about the right amount of work for us", that's fine.

Hence we estimate the time spent on several US so that we map this time to SP. The development team want to estimate each US by dividing the front, back and QA estimation

Might this detract from the shared responsibility of Developers to figure out how much work they can collectively accommodate each Sprint? I think you're right to have certain suspicions.

We are currently reviewing the way we calculate story points on user stories because we feel we don’t have a good proportionality in the time spent between a 1 and 2 story points US for example. Hence we estimate the time spent on several US so that we map this time to SP. The development team want to estimate each US by dividing the front, back and QA estimation. I have a feeling that there is more value that each team member makes an estimation as a whole. Do you have tips for a best practice?

At that time, was this suspected? Should that be the case, why don't the developers simply consider the issue during Sprint Planning and make the necessary adjustments?

To help developers understand how much work they can do in a sprint, estimating is undertaken. Value delivery and empirical process control are the main components of all else. It is therefore OK if they can state, "That's about the right amount of work for us."