Finally the problem was in the normal used for SSR. Retrieving the z component from the stored xy format by the Pythagorean theorem works well if the sign of z can be fixed. Apparently when the camera rotate around the x axis (e.g. axis parallel to screen width in my case) the sign and/or the retrieved z value are not consistent (I have to check that) and so it is better to store the normal in full xyz R10B10G10 format. Doing so solved my problem with good precision. Alternative packed format for SSR normal could be another answer. For instance Spheremap Transform with R16G16 format works well too.

Finally the problem was in the normal used for SSR. Retrieving the z component from the stored xy format by the Pythagorean theorem works well if the sign of z can be fixed. Apparently when the camera rotate around the x axis (e.g. axis parallel to screen width in my case) the retrieved z value is not consistent and so it is better to store the normal in full xyz R10B10G10 format. Doing so solved my problem with good precision. Alternative packed format for SSR normal could be another answer. For instance Spheremap Transform with R16G16_UNORM format works well too with no impact compared to R10G10B10A2 considering the additional coding/decoding instructions. R16G16_FLOAT gave me small flickering in the mirrored pixels. R8G8 is not precise enought for this purpose with bad reflexion aspect.

coding spheremap normal
float2 NOut = mad(N.xy, 1.0/sqrt(N.z*8+8), 0.5);
decoding
float2 NIn = mad(txNormal.sample().rg, 4, -2);
float f = dot(NIn ,NIn ); 
float3 NOut = float3(NIn*sqrt(1-f*0.25), 1-f*0.5);

Finally the problem was in the normal used for SSR. Retrieving the z component from the stored xy format by the Pythagorean theorem works well if the sign of z can be fixed. Apparently when the camera rotate around the x axis (e.g. axis parallel to screen width in my case) the sign and/or the retrieved z value are not consistent (I have to check that) and so it is better to store the normal in full xyz R10B10G10 format. Doing so solved my problem with good precision. Alternative packed format for SSR normal could be another answer if a sign can be stored.

Finally the problem was in the normal used for SSR. Retrieving the z component from the stored xy format by the Pythagorean theorem works well if the sign of z can be fixed. Apparently when the camera rotate around the x axis (e.g. axis parallel to screen width in my case) the sign and/or the retrieved z value are not consistent (I have to check that) and so it is better to store the normal in full xyz R10B10G10 format. Doing so solved my problem with good precision. Alternative packed format for SSR normal could be another answer. For instance Spheremap Transform with R16G16 format works well too.