« On a déjà essayé, ça n'a pas marché » : l'objection qui arrête un projet d'automatisation sur deux
C'est souvent la première phrase, avant même qu'on ait parlé de prix ou de méthode. Un dirigeant de TPE ou de PME a déjà payé pour un logiciel, une formation, parfois un prestataire : l'outil est resté ouvert trois semaines, puis tout le monde est retourné au tableau Excel ou au carnet. Résultat : une méfiance légitime envers tout ce qui ressemble, de près ou de loin, à « on va automatiser votre gestion ».
Pourquoi cette objection est fondée
Elle n'est pas irrationnelle. Dans la grande majorité des échecs qu'on nous raconte, le schéma est le même, et il n'a rien à voir avec l'automatisation en elle-même :
- le projet a imposé de changer d'outil principal (CRM, facturation, messagerie) alors que l'équipe maîtrisait déjà le sien ;
- la mise en route s'est arrêtée à la livraison : personne n'est revenu un mois après pour corriger ce qui coinçait réellement à l'usage ;
- le projet a été pensé pour « tout changer » d'un coup, au lieu de commencer par une seule tâche répétitive et mesurable (les devis, les relances, le tri de la boîte mail).
Un outil qu'on doit réapprendre, sans personne pour ajuster derrière, finit toujours fermé dans un onglet. Ce n'est pas un échec de l'automatisation : c'est un échec de méthode.
Ce que montrent les faits, une fois qu'on regarde les projets qui tiennent
Les automatisations qui restent utilisées un an après ont presque toujours trois points en commun. Elles partent des outils déjà en place (Qonto, EBP, Batigest, Pennylane, Google Workspace, selon le métier), sans migration ni changement d'habitude côté équipe. Elles démarrent sur UNE tâche précise, pas sur toute la gestion : un devis généré depuis un brief vocal, une relance de facture impayée, une fiche créée automatiquement dans HubSpot ou Notion quand un formulaire est rempli. Et elles sont suivies après la mise en route : un ajustement dans les deux premières semaines fait presque toujours la différence entre un outil adopté et un outil abandonné.
Techniquement, ce qui relie ces outils entre eux (Make, n8n, ou une connexion directe par API) est devenu fiable et courant : connecter Qonto à un tableau de suivi, ou un formulaire de site à Airtable et Brevo, ne demande plus de développement lourd. Le risque n'est donc plus dans la technique : il est dans la façon de conduire le projet.
Ce qui reste vrai, et qu'il ne faut pas balayer
Un mauvais projet d'automatisation reste un vrai risque : du temps perdu, une équipe qui se braque, parfois une tâche mal reprise qui coûte plus cher qu'avant. Dire « ça ne peut plus arriver » serait malhonnête. La question utile n'est donc pas « l'automatisation marche-t-elle ? », mais « ce projet précis est-il construit pour tenir, ou pour impressionner à la démonstration puis s'arrêter à la livraison ? ».
Ce qu'on vérifie avant de se lancer
- Le projet part-il des outils déjà utilisés par l'équipe (Qonto, Notion, WhatsApp Business, Google Workspace, le logiciel métier en place), sans en imposer un nouveau à apprendre ?
- La première étape porte-t-elle sur une seule tâche mesurable, avec un temps avant/après qu'on peut chiffrer ?
- Y a-t-il un suivi prévu après la mise en route, ou le prestataire disparaît-il une fois la facture envoyée ?
- Peut-on revenir en arrière facilement si une étape ne convient pas, sans perdre ce qui existait avant ?
Si ces quatre réponses sont oui, l'expérience précédente, ratée, ne dit rien sur celle-ci : elle dit seulement que la méthode d'avant n'était pas la bonne.