Can't promise this will solve your problem, but...
I suppose that this will tell the system to launch the executable after bluetooth service are up and running, but it doesn't seems so
Something to keep in mind with system services is that it is very easy for the system to determine and depend upon when a service starts, but that is very narrowly defined in the sense that it will often be distinct from the not as simple and objectively definable "up and running" -- which may be easy to define in words for a specific service, but there are no checkpoints of that sort in general (there are some good reasons for this but I'll refrain from the tangent).
The take-away is that, in general, all the various depends/wants etc. are based on when processes start. With the systemd "targets", which group services, the relationship between core services in a target does provide a bit of checkpoint-esque ordering refinement, but even without the added complication of stage 1, 2, 3 etc for every process this can be a bit delicate.
So, this seems to me wrong-headed:
It is a common pattern to include a
unit name in both the After= and Wants= options, in which case the unit listed will be started before the unit that is configured with these options.
But, as per the Forward and reverse unit properties table in that man page,
Wants is the reverse of
WantedBy. So you are sort of saying that this service should start after
multi-user.target), but that this service should start when those targets start. It creates a sort of circular or non-sensical dependency.
WantedBy, this is just what indicates where and if the service should be included when you enable it. The simplest and most straight-forward way to use it is to just use
default.target. This means it will be included in the list of thing to start without nailing it down too specifically -- that can be fine tuned with dependencies on more specialized units/targets.
Obviously you need bluetooth working, and if you read through the bit on
After, something more appropriate might be:
Notice I've used
bluetooth.service there, not
bluetooth.target. This is because if you look, by default the bluetooth.target only includes one service, bluetooth.service, and since that is an actual service that starts a real executable, it is likely to be a more specific relation.
systemctl status [service name sans '.service'].