I remember someone on IRC having the exact same problem. That user was on OVH’s shared hosting plan, which seems to be the case here as well (according to whois).
OVH’s hosting service added a new feature a while ago that automatically obtains and installs certificates through Let’s Encrypt. I’m not quite sure if it’s available for every plan, and whether it’s enabled by default for everyone just yet. It seems the way they implemented domain ownership validation was to intercept requests to the .well-known/acme-challenge path and append their account key fingerprint to the end of the token (that’s 4K4utefY9yjK6O3GXVnksPSwhG6YDukVVE4ygo3LW0w in your case, with your account key fingerprint being uTELhyXiXjGZE6oY-Nal7LiiJvKQly-pLZ6KCDnZqnM and OVH’s being 4E3VCTFsySjUrqnCg0ooULx-3kbdPBygi0aWkvg5Gd8 - which happens to match the one I found in my IRC logs from that other user 
).
I would definitely recommend contacting support so they’re made aware that this is breaking domain validation for everyone on their shared hosting plan. Since there’s no way of telling if and when they’ll fix this, you might want to take a look at the DNS-based challenge (DNS-01) as an alternative in the meantime. This will work as long as you’re able to create a TXT record for your domain. Certbot currently does not support this yet, but you can use one of the other clients with DNS-01 support, such as lego.