I ran some test yesterday at the customer site (and increased log level) :
- the CAD software crashed after saving an assembly and that did not cause the smb process to "hang", so I was wrong on this point.
- I realised I cannot use the avg. load as a trigger in the script, as the server will regularly go above 1.0 avg load when several users are saving/accessing large files at the same time or when the backup is running. I'll have to monitor the smb process (and now I reconsidering using such "kill process" script, I'll focus more on solving the root cause).

One other thing the customer complains about is that the smb server access is sometime very slow, while the avg load is quite low (no more than 0.1), independently from the client (there are some mix of win XP/32 and XP/64, seven/32 and seven/64, all user experience the same slowliness at the same time when this happens).
I was on site once when this happened and could not see any reason for this from the smb logs. Access to other file shares on other server was normal, no error reported on the network switch on the ports of the server nor the clients. The situation returned to normal few minutes after, and I ran some tests on the file server (copying/reading small/medium/larg files and measuring the bandwidth) and the performances were as expected (60~70 MB/s).
But I'm not sure that both problems are related.
I'm still convinced one cause of the problem is the CAD software as only the files accessed by this software are impacted, none of the office softwares or calculation software are experiencing the same issue. And of course they are using different flavor of the software (different versions and some 32 and/or 64 bits).