28 % des échecs viennent du mauvais choix de processus à automatiser. 70-85 % des projets sous-performent. La grille des 5 critères qui décident vraiment : fréquence, prévisibilité, coût d'erreur, gain réel, durée de vie estimée. Plus la liste honnête des 5 cas à ne jamais automatiser. Avant de coder, tranche.
Ta boîte mail déborde, tu te dis « je devrais automatiser ». Tu construis cinq scénarios un samedi. Lundi, ça marche. Trois mois plus tard, trois sont cassés, un ne sert à personne, un te fait perdre du temps en corrections.
Tu n'es pas seul : une grande partie des échecs d'automatisation vient du choix du mauvais processus, pas de l'outil. Le problème est en amont. La plupart des gens automatisent ce qui les agace, pas ce qui le mérite. Voici comment distinguer les bons des mauvais cas d'usage avant de te lancer.
L'industrie a intérêt à te faire croire que tout se joue dans le choix de l'outil (Zapier vs Make vs n8n). Faux : la cause n°1 d'échec n'est pas l'outil, c'est le processus choisi. Automatiser un processus qui change trop souvent, plein d'exceptions ou qui demande du jugement à chaque étape, c'est produire du mauvais résultat à grande vitesse.
Tout se joue donc avant : quoi automatiser. Voici comment distinguer les bons des mauvais cas d'usage.
Pour qu'un processus mérite d'être automatisé, il doit cocher au moins 4 des 5 critères. 3 sur 5 = zone grise, fais un mini-pilote avant d'investir. 2 ou moins = ne lance pas, peu importe combien le sujet te séduit.
Pour chaque processus candidat, donne-toi un score sur 5. Critère 1 : ≥ 5 fois/semaine ? +1. Critère 2 : structure stable à 80 % ? +1. Critère 3 : coût d'erreur faible OU HITL prévu ? +1. Critère 4 : gain réel ≥ 3x coût total ? +1. Critère 5 : stable ≥ 12 mois ? +1. Score 4-5/5 = lance, ROI quasi-garanti. Score 3/5 = pilote 1 mois sur petit périmètre avant scaler. Score ≤ 2/5 = ne lance pas, peu importe combien le sujet te séduit. Cette discipline simple élimine 80 % des échecs documentés.
Au-delà des critères qualifiants, certaines catégories de processus sont structurellement de mauvais candidats, peu importe la fréquence ou le volume. Liste honnête que peu d'éditeurs te donneront — automatiser ces cas est garanti d'échouer.
Évaluer la qualité d'une candidature pour un poste sénior. Décider si un client mérite un geste commercial. Gérer un conflit interpersonnel. Trancher une décision stratégique. Ces décisions intègrent des dizaines de signaux faibles, contexte historique, intuition métier. Une IA peut aider en présentant une analyse — mais la décision reste humaine.
Anti-pattern : déléguer la décision à l'IA « pour aller plus vite ». Tu te retrouves avec des décisions médiocres prises rapidement, ce qui est pire que des décisions correctes prises lentement. La vitesse n'est pas le seul critère.
Rédiger une lettre de licenciement. Écrire une condoléance à un client. Concevoir une stratégie de marque. Un agent IA peut générer un draft, mais le résultat final demande une touche humaine que l'automation ne reproduit pas. Si tu déploies de l'IA sur ces cas, tu produis du contenu qui sonne « générique » et qui dégrade ta relation au lieu de la renforcer.
Cas frontière acceptable : assistance à la rédaction (premier draft IA, validation et personnalisation humaine). Le mot-clé est assistance, pas automation.
Un automatisation qui évolue toutes les 2-3 semaines (réorganisation continue, expérimentation produit, processus en formation). Tu construis l'automation, deux semaines plus tard la séquence change, tu refais. Au bout de 3 cycles, tu réalises que tu passes plus de temps à maintenir qu'à exécuter manuellement.
Règle : stabilise le processus humain pendant au moins 3 mois avant de penser à automatiser. Si tu ne peux pas tenir un format stable 3 mois, le process n'est pas mature pour l'automation.
Si chaque cas demande un traitement spécifique, l'automation aura un taux d'échec qui rend la maintenance ingérable. Exemple : gestion de demandes clients qui mélangent demande commerciale + plainte + question technique + demande de remboursement, avec des règles différentes selon segment client. Trop de branches, trop d'exceptions = automation fragile.
Test : écris la liste des cas de figure possibles. Si tu as plus de 10 branches conditionnelles, tu n'automatises pas un processus — tu réinventes une application métier custom. Mauvais usage de Zapier/Make/n8n.
Le piège n°1 documenté : « automating broken processes ». Le process humain est mal défini, plein de raccourcis non documentés, avec des étapes que personne ne fait correctement. Tu te dis « automatisons-le, ça forcera la rigueur ». Faux. Tu obtiens une version automatisée du même mauvais process, sauf qu'elle s'exécute 100 fois plus vite.
Règle d'or : répare le automatisation d'abord, ensuite automatise. Documente le process humain. Simplifie-le. Élimine les étapes inutiles. Crée un seul source of truth. Puis automatise. Sauter l'étape de clarification est la source documentée de la majorité des disasters d'automation (Go Rogue Ops, mars 2026).
Automatiser un mauvais process, c'est obtenir un mauvais résultat à grande vitesse. La discipline n'est pas glamour mais elle paie : commence par fixer le process humain. Puis automatise.
Une fois qu'un processus passe les 5 critères et n'est dans aucun des 5 cas à éviter, calcule le ROI. Pas avec des chiffres optimistes. Avec la formule honnête. Si elle ne tient pas, n'automatise pas.
Premièrement : le calcul vitrine (« 12,5h économisées × 30 €/h = 375 € ») sur-estime de 30-50 % la valeur réelle. Les automations couvrent 70-80 % d'un processus, pas 100 %. Ne tombe pas dans ce piège.
Deuxièmement : le coût total à comparer n'est pas le sticker price de Zapier. Tu paies 6 composantes : plateforme + tokens + hosting + config + maintenance + review humaine. Sticker = ~30 % du coût total réel.
Troisièmement : le ratio 3,6x dans cet exemple est le sweet spot. Au-dessus de 3x, lance avec confiance. Entre 1x et 3x, fais un pilote 1 mois pour vérifier les hypothèses. En dessous de 1x, abandonne — peu importe la fierté technique.
Quatrièmement : mesure avant de construire. « On a l'impression de gagner du temps » ne convainc personne. Sans baseline (temps manuel, erreurs, coûts), tu ne pourras pas démontrer le ROI 6 mois plus tard. Et tu ne pourras pas justifier de scaler à d'autres processus.
Beaucoup d'utilisateurs comparent « coût d'abonnement » à « heures économisées » et concluent que tout est rentable. Erreur. Les 6 composantes du coût total : (1) abonnement plateforme, (2) tokens IA selon volume, (3) hosting si self-hosted, (4) temps de configuration amorti, (5) maintenance mensuelle (1-2h minimum), (6) review humaine pour drift detection. Direct labor savings sous-estiment ROI de 30-50 % — mais coût caché sous-estime le coût total dans des proportions similaires. Honnêteté complète des deux côtés = décision juste.
La grille des 5 critères + la liste des 5 cas à éviter + la formule ROI honnête forment ton filtre de qualité avant de toucher à l'outil. Discipline apparemment ennuyeuse, qui élimine 80 % des échecs documentés. Mon process personnel : liste de 10 candidats par trimestre → score sur 5 critères → top 2-3 → mesure baseline 1 semaine → construction 4-8h → pilote 30 jours avec métriques → décision continuer/ajuster/abandonner. Cette boucle me prend 1-2h/semaine pour entretenir une stack de 5-7 automations actives qui me font économiser 20-30h/mois. ROI : ~10x. C'est reproductible si tu acceptes la discipline. Suite logique : article 4.3 sur la construction concrète — comment passer de la décision « je vais automatiser ça » à un automatisation qui tourne en 30 minutes.
Tu sais maintenant choisir quoi automatiser. Pour aller plus loin : article 4.1 sur l'anatomie d'une automation (la structure déclencheur → IA → action). Article 2.6 sur Zapier/Make/n8n (les plateformes pour bâtir). Article 2.1 sur MCP (le standard 2026 pour connecter). Article 3.7 ★ sur le coût réel des agents (anticiper la facture token de tes étapes IA). Article 3.6 sur le human-in-the-loop (calibrer la supervision). Article 3.5 sur tester un agent (mesurer la fiabilité avant de scaler). Article 2.8 ★ sur la sécurité connecteurs (la couche gouvernance de ton automation). Pour le panorama complet : la rubrique R4.