the following line 67 belongs to your first error message:

yt11 := std_logic_vector(signed(y1m) + signed(h2)*signed(f01));
...
ft11 := std_logic_vector(signed(a)*(signed(yt12)-signed(yt11)));

Are you aware, that a multiplication of two signed variables of length 
32 results in a signed variable of length 64? (If you multiply the 
single decimal digit 9 with another 9, you need two digits for the 
result 81). Also adding two numbers of length 32 can give a result with 
a bigger length. This longer result will not fit into yt11.

Besides the length of your standard-logic-vectors your complete 
calculation is set up in a way that would give a terrible synthesis 
result. My most urgent recommendations would be:
a) avoid working with variables unless you really know what you're 
doing. Work with signals instead.
b) work with clocked processes, which lead to clocked registers in the 
synthesis result.
c) work with pipelines: calculate an intermediate result (like yt11) in 
one clock cycle, and use the result in the following clock cycle to 
calculate ft11. Don't try to execute all caclulations "at once".

Louis Louis wrote:
> but my program is a loop

mistake Nr. 1: you do not have a program at all. VHDL-code is a 
description of hardware. If you write VHDL for synthesis you must have 
an idea of the hardware you want to generate. What looks like a program 
is only a textual description of hardware. (For simulation you can 
pretty much ignore that, but not for synthesis).

Louis Louis wrote:
> when I arrive at the end
> of the program with the good length for the vectors, it's said that the
> vector I corrected before don't have the good length.

So the numbers in your repeated calculation grow bigger and bigger til 
they run to infinity? Most probably you have to scale your numbers 
inbetween: if a calculation gives a result of 96 bit length, then maybe 
only the most significant 32 bit carry real information while the 64 
lower significant bits carry only noise. Then you just take the 
uppermost 32 bit for further calculation and ignore the 64 bit of noise.

But you have to be carefull: depending on the calculations you execute 
it could also be, that the uppermost 32 bit are all 0 (or all 1 for 
negative numbers) and the real information is e.g. in the bits 60 downto 
28. Have a close look at your calculations and the numbers you put in, 
and evaluate manually, what extreme-values you may reach.

As an example: in your code you use 32 bits to describe the decimal 
number 3. If you multiply this with any 32 bit number, the result will 
be 64 bit wide, but the uppermost 30 bit will carry no information 
besides the sign of your result. The numeric information will start from 
bit 33 downwards.

Louis Louis wrote:
> I will try that you said, when you said to work with clocked process,
> you mean that it,s needed to put a wait instruction at each line of
> calculation ?

No, I did not mean that for sure.

As I stated above: you need an idea, how your description is converted 
in real hardware, so that you can write reasonable VHDL code. I 
recommend that you work through a book for synthesizable VHDL. In German 
my proposal would be Reichard/Schwartz: VHDL-Synthese, I'm sure there 
are good books in English too.

the after will be ignored by the synthesyser, FPGAs don't have a 
generic delay element.

Z <= std_logic_vector(Z_buff) after 1ns;

This means that once you have fixed your vector size problem, the 
synthesyser will bark at you about the missing sensitivity list or 
clock, just like the simulator.

So for implementing it on the FPGA you need to add a clock from some 
external source.

begin
   wait until rising_edge(clk);
   y1m := X_buff;

   ...

Once you have fixed this, and probably some other problems, you will be 
able to build it, but only to find out that it will support only a very 
low clock rate.

Since your requires the output from the previous cycle, and even inside 
each stage requires the result from the previous stage there isn't much 
you can do for speeding it up.
Of course speed may be not your goal, i don't know.