Here are my thoughts / understanding ...
From what i've seen, it's seems that we have multiple copies of the boot loader ( seems to be at least two).
Correct - the flash chip is sufficiently large to hold multiple copies of the bootloader code. I'm guessing there are 2 copies.
And the upgrade seems to write a new version , calculate the checksum and after that switch to the right version
This assumes the calculated checksum matches the stored checksum (presumably, the correct checksum was stored on the flash as part of the new version). It's important to keep in mind that when the Z-Wave chip reports the flash has been written successfully, the chip has not verified the contents were actually stored correctly. Here's an analogy. I've asked you to remember 5 items on a shopping list and you say "No problem". After 10 minutes, I ask you to tell me what the 5 items are an you forgot an item.
Regarding the the switch maybe the issue is related with the fact that one of the copie dont have the right checksum ( the FC8B).
It's necessary to assume the firmware upgrade file you downloaded contained the correct checksum. The problem is that the Z-Wave chip read the contents of the flash chip to calculate a checksum, and the calculated checksum did not match the stored checksum. This happens when the flash chip does not store the data correctly.
Can you help us and tell us what can be done in order check the checksums of the versions available in the flash subsystem ?
It's not appropriate for me to speak for @PoltoS, but I do think it's appropriate to believe what he already wrote - "Looks like a broken flash". The Z-Wave serial API includes a function to calculate a checksum for data in an address range(ZW_FirmwareUpdate_NVM_isValidCRC), but for some reason, a proprietary API call (0xF4) is used instead of the standard Z-Wave API call. I'm guessing the proprietary API call is associated with the license key. Regardless of the purpose, it should be possible to manually run the 0xF4 API call (with luck, the ZMESerialUpdater has the complete serial port interaction since the expert UI log file only reports the API value, not the complete serial port interaction; worst case, you can use debug tools to monitor the tty file descriptor).
The issue seems to be not "unique" since somebody else already encountered the exact same issue.
I'm guessing the other person also had a faulty flash chip. You might want to put your UZB into a refrigerator for 10 minutes to cool it down and then try the ZMESerialUpdater tool or expert UI again (and again and again). Perhaps the upgrade might be successful.