So, after trying the solution proposed by @vanadium to no avail, I reasoned that in the absence of shock to the drive or creaky noises, and given the fact that I had interrupted a windows update, this was probably a logical failure caused by an I/O error.

I burned a live USB stick with SystemRescueCD, a special purpose linux distribution which comes with utilities useful when trying to fix an installation.

I first used ddrescue with the option -n to copy the damaged partition to an external hard drive which I call the clean copy. -n allows for a first quick pass and minimizes damage to the reading head. As I conjectured, I was able to read 100% of the bytes in the partition.

I then used dd to copy the clean copy on a second external hard drive, the working copy. This ensures that if any work I do on the working copy is destructive, I can go back to the clean copy without having to copy from a potentially failing drive.

I then ran TestDisk on the partition located on the working copy. Following the menu, I selected the partition, and TestDisk provided me with a list of the superbloxks in the failed filesystem.

Superblocks are the blocks in memory containing the metadata about the structure of the filesystem. TestDisk detected that the file system was an ext4 filesystem and proposed a command to fix the filesystem :
fsck.ext4 -p -b <start of superblock> -B <size of superblock> /path/to/working/copy

The arguments <start of superblock> and <size of superblock> were taken from the output of TestDisk.

After running this command, the first superblock which had been corrupted was fixed, and the files were accessible in their entirety. I then backed them up on a third hard drive which I usually used for Windows backups.

Total cost : roughly 200$ to acquire the external hard drives. A data recovery company had quoted me 800$ to do this job.