On parle beaucoup de ce qu'il faut automatiser. Plus rarement de ce qu'il ne faut pas automatiser. Pourtant, chez une PME de distribution, d'installation ou de SAV en Isère comme ailleurs, une partie des tâches répétitives ne justifie tout simplement pas d'être automatisée, et vouloir le faire quand même coûte plus cher que le problème qu'on croit résoudre.
Voici les situations où, chiffre en main, mieux vaut s'abstenir, ou attendre.
1. Le volume est trop faible
Le retour d'une automatisation se calcule simplement : temps gagné par occurrence × fréquence × coût horaire. Quand la fréquence est basse, le numérateur s'effondre. Une tâche pénible mais réalisée deux fois par mois, même en 20 minutes, représente moins de 8 heures par an. Face à plusieurs jours de mise en place et à la maintenance, l'équation ne tient pas.
La pénibilité ressentie n'est pas le bon critère. Une tâche peut être agaçante et rester non rentable à automatiser. Ce qui compte, c'est le temps cumulé sur l'année.
2. Les exceptions sont la règle
Une automatisation est rentable quand un cas majoritaire se répète à l'identique. Si chaque dossier a ses particularités, ses dérogations, ses « sauf pour ce client-là », on passe son temps à coder des exceptions, puis à gérer celles qu'on n'avait pas prévues.
Règle simple : si moins de 70 % des cas suivent le même chemin, l'automatisation intégrale n'est pas mûre. Il vaut souvent mieux n'automatiser que le tronc commun et laisser l'humain traiter les exceptions.
3. Le process n'est pas stable
Automatiser, c'est figer une façon de faire dans un outil. Si le process change encore tous les mois, ou s'il n'existe qu'informellement dans la tête d'une personne, on automatise une cible mobile. Chaque changement casse ce qui a été construit.
Dans ce cas, l'étape utile n'est pas l'automatisation : c'est d'abord stabiliser et écrire le process. On automatise ensuite, une fois qu'il ne bouge plus.
4. L'outil ne s'y prête pas (encore)
Certains logiciels métier n'offrent ni API, ni export exploitable, ni point d'accroche. Forcer une automatisation par-dessus (capture d'écran, robots fragiles) crée une mécanique qui casse à la moindre mise à jour. Mieux vaut attendre une version qui expose ses données, ou traiter le sujet à l'occasion d'un changement d'outil déjà prévu, plutôt que de bricoler.
Récapitulatif : les signaux « on n'automatise pas »
| Signal | Pourquoi ça bloque | Ce qu'on fait à la place |
|---|---|---|
| Volume faible | Le gain annuel ne couvre pas la mise en place et la maintenance | On laisse en manuel, on documente |
| Beaucoup d'exceptions | Coder tous les cas coûte plus que le temps gagné | On automatise le tronc commun uniquement |
| Process instable | Chaque changement casse l'automatisation | On stabilise et on écrit le process d'abord |
| Outil fermé | Pas d'API ni d'export, montage fragile | On attend, ou on traite au prochain changement d'outil |
Pourquoi on vous le dit
Un prestataire payé pour automatiser a intérêt à toujours dire oui. Nous faisons l'inverse : si une tâche ne doit pas être automatisée, on l'écrit noir sur blanc dans le diagnostic. C'est le sens du diagnostic de cadrage d'une journée (1 500 € HT) : trois cas d'usage chiffrés et priorisés, avec l'hypothèse de calcul affichée, et le droit de conclure que le meilleur chantier est ailleurs. Un diagnostic qui vous appartient, avec ou sans suite.
Savoir quand ne pas automatiser, c'est ce qui rend crédible le reste. Automatiser ce qui compte vraiment commence par écarter ce qui ne le mérite pas.