Deux fonctions automatisées à 100 %, pas dix à 20 %

Les SaaS génériques et les plateformes d'intégration low-code sont conçus pour couvrir le plus de cas d'usage possible, ce qui veut dire que chacun reçoit une implémentation superficielle, à 70 % du chemin. On construit l'inverse : un outil qui fait deux fonctions à 100 %, de bout en bout, plutôt que dix à 20 %. Moins de fonctionnalités, mais chacune ferme vraiment la boucle, sans rattrapage manuel une fois que l'automatisation « se termine ».

Pourquoi la largeur est le mauvais réflexe par défaut

Une plateforme configurée pour toucher dix process finit en général par en automatiser dix à moitié : les 80 % faciles de chaque flux sont gérés, et les 20 % compliqués, l'exception, le cas particulier, le client bizarre, retombent quand même sur le bureau de quelqu'un. C'est le pire des deux mondes : vous avez payé pour de l'automatisation et vous faites toujours le travail manuel, avec un outil de plus à surveiller en prime.

Partir du point de douleur, pas de la liste de fonctionnalités

On ne part pas de ce qu'une plateforme sait faire, on part de ce qui fait vraiment mal : le copié-collé de deux minutes répété cinquante fois par jour, le rapport toujours en retard parce que quelqu'un doit le compiler à la main, le passage de relais entre la finance et la logistique qui casse chaque fin de mois. On choisit le ou les deux micro-processus qui génèrent le plus de friction, et on les automatise complètement, exceptions incluses, avant de toucher au reste.

Le calcul derrière une petite automatisation qui n'a l'air de rien

Dix minutes économisées par personne et par jour paraissent négligeables jusqu'à ce qu'on multiplie. Dix salariés à dix minutes par jour, ça fait 100 minutes par jour, environ 700 minutes par semaine, près de 2 800 minutes par mois, plus de 46 heures. À un coût chargé même modeste de l'heure, c'est de l'argent réel chaque mois, pour une tâche que personne ne pensait valoir la peine d'automatiser parce qu'elle paraissait trop petite.

• Chronométrer la tâche honnêtement : minutes par occurrence fois occurrences par semaine, pas une estimation de mémoire.
• Multiplier par le nombre de personnes qui la font, pas seulement l'estimation d'une seule personne.
• Convertir en coût mensuel avec un taux horaire chargé, puis comparer ce chiffre au coût de construction de l'automatisation.

Parfois il n'y a pas d'API, et ce n'est pas un problème

L'automatisation la plus propre connecte des systèmes via une API. Mais certains des process qui génèrent le plus de friction tournent sur des outils qui n'en proposent aucune, une vieille application de bureau, un portail partenaire qui n'accepte que la saisie manuelle dans un navigateur. Quand c'est la réalité, agir directement sur l'écran de l'utilisateur est un choix légitime et documenté honnêtement, pas un raccourci qu'on cache, et on priorise son remplacement par une vraie intégration dès qu'un chemin plus propre existe.

Ce que ça signifie pour vous

Un audit rapide de la façon dont votre équipe travaille réellement, pas de la façon dont le process est documenté, fait généralement émerger deux ou trois candidats en une journée ou deux. On automatise en priorité celui qui génère le plus de friction, complètement, avant de passer au suivant, pour que chaque fonction livrée soit une fonction que vous pouvez arrêter de surveiller, pas une de plus à garder à l'œil.

Questions fréquentes

Comment choisissez-vous les deux fonctions à automatiser en premier ?

On observe comment le process tourne réellement aujourd'hui, pas comment l'organigramme dit qu'il tourne, puis on classe les étapes par minutes perdues fois fréquence. L'étape qui génère le plus de friction et revient le plus souvent gagne, même si elle a l'air ingrate, un copié-collé répétitif bat toujours un cas rare.

Automatiser sans API, ce n'est pas juste un bricolage fragile ?

Parfois il n'y a aucune API à laquelle se connecter, une vieille application de bureau, un portail partenaire qui n'accepte que la saisie manuelle. Dans ces cas, agir directement sur l'écran de l'utilisateur est la seule option, pas un raccourci qu'on préfère. On documente la fragilité ouvertement et on priorise une vraie intégration par API dès qu'une devient disponible.

Si le process change le trimestre prochain, l'automatisation n'est pas gâchée ?

C'est exactement pour ça qu'on cadre étroit : un outil construit pour une fonction coûte assez peu, en temps et en argent, pour être reconstruit si le process bouge. C'est l'arbitrage qu'on fait exprès, une plateforme large configurée pour dix fonctions est ce qui reste vraiment coincé quand l'activité change, pas un petit outil construit pour une seule.

Automatiser une tâche, ça veut dire supprimer la personne qui la faisait ?

Pas forcément, et c'est votre décision, pas la nôtre. Certains clients réaffectent ce temps vers des tâches à plus forte valeur ajoutée pour la même personne ; d'autres réduisent effectivement l'effectif sur des rôles purement répétitifs. On construit l'outil dans les deux cas, ce que vous faites du temps libéré est une décision managériale qu'on ne prend pas à votre place.