Quels processus il vaut la peine d’automatiser, et comment les reconnaître

Quatre questions pour passer vous-même votre quotidien au crible : s’agit-il d’une chaîne avec un résultat, la machine reçoit-elle des données ou une image, une étape tranche-t-elle quelque chose à propos d’une personne, et le processus a-t-il déjà une échéance externe.

La question « que devrions-nous automatiser » arrive en général trop tard, parce qu’elle suppose que la réponse est une liste d’outils. Dans la pratique, la plupart des projets d’automatisation qui échouent ont commencé avec le bon outil, posé sur un travail mal choisi, et c’est le choix, non l’outil, qui a tranché le résultat.

Cet article n’essaie pas de définir ce qu’est l’automatisation des processus métier, parce qu’une définition ne tranche rien ; à la place, il donne quatre questions avec lesquelles vous pouvez vous-même passer votre travail quotidien au crible, et après chacune il montre à quoi ressemble un cas qui la passe, et un cas qui ne la passe pas. Ce crible ne coûte rien et tient dans un après-midi, mais il épargne nettement plus que n’importe quelle comparaison d’outils, parce qu’il répond à la question la plus en amont de la chaîne.

Première question : s’agit-il d’une chaîne avec un résultat, ou d’une suite de clics

C’est la frontière qui tranche le plus, et il vaut la peine de la tracer avec précision : un processus est une chaîne d’actions qui a des données d’entrée, un résultat et un responsable : l’émission d’une facture à partir d’une commande, l’embauche d’un nouveau salarié, le chemin d’une demande client depuis le formulaire jusqu’à la réponse. Une procédure, c’est-à-dire une action isolée, c’est la façon dont on exécute une étape précise : où cliquer, quoi copier, dans quel champ saisir un numéro.

On peut automatiser les deux, mais l’écart de rendement se compte en multiples, et c’est pourquoi l’ordre compte : si vous automatisez la chaîne, vous changez le résultat — le document arrive de lui-même en comptabilité, et plus personne ne le recopie. Si vous automatisez une suite de clics, vous accélérez une étape dans une chaîne dont le reste ne change pas, et le gain est exactement aussi grand que l’était la part de cette seule étape.

Le moyen pratique de le reconnaître est simplement de demander ce qui arrive ensuite au résultat, et la réponse dit en général tout : si c’est « alors quelqu’un prend ce fichier et le pose dans un autre système », la chaîne continue, et automatiser une étape revient à déplacer le goulot d’étranglement, non à le supprimer. Si la réponse est « alors le travail est fini et le résultat est dans le système », vous avez un processus avec un point d’arrivée clair, et ce sont précisément ceux-là qu’il vaut la peine de prendre en premier.

Prenons une chaîne typique et suivons-la jusqu’au bout, parce que c’est précisément ce suivi qui montre où le gain se cache vraiment : le client remplit un formulaire sur le site, la demande arrive par courriel, quelqu’un la recopie dans le système de suivi des clients, quelqu’un d’autre prépare un devis, et après confirmation un troisième émet la facture dans le logiciel de comptabilité. Ici il y a un processus avec un résultat clair (de la demande à la facture), et au moins trois endroits où les mêmes données sont saisies à nouveau, chaque fois avec une chance de se tromper.

Si, dans cette chaîne, on n’automatise que la recopie de la demande vers le système de suivi, le gain est réel, mais petit, parce que les deux autres recopies restent. Si l’on automatise toute la chaîne, c’est le caractère même du travail qui change : la personne ne recopie plus, elle vérifie et elle décide là où une décision est vraiment nécessaire. C’est pourquoi il vaut la peine de dessiner les limites de la chaîne avant toute conversation sur les outils, parce qu’elles fixent l’ampleur du gain possible.

La chaîne a aussi un responsable, et c’est une question que l’on oublie souvent de poser. Si aucune personne nommée ne peut dire comment le processus se déroule du début à la fin, l’automatisation sera une suite de suppositions sur la façon dont cela se passe probablement, et le premier cas réel les fera voler en éclats. Trouver le responsable tient en général dans une conversation, mais épargne plusieurs semaines, et c’est donc la part la moins chère du projet.

Deuxième question : la machine reçoit-elle des données, ou une image

C’est la différence technique la plus importante de toute l’automatisation, et en France elle a désormais aussi un versant réglementaire. Si le système reçoit des données structurées (XML, JSON, un enregistrement dans une base), il peut les traiter sans deviner. S’il reçoit une image, c’est-à-dire un fichier PDF ou une page scannée, alors avant tout traitement quelqu’un doit deviner ce qui s’y trouve écrit, et c’est précisément cette part de devinette qui produit les erreurs qu’ensuite quelqu’un corrige à la main.

L’exemple des factures le montre le mieux, parce que les deux possibilités y coexistent et portent presque le même nom. La facture électronique structurée, dite aussi au quotidien facture électronique, est un document lisible par une machine dans un format déterminé — en France elle correspond à la norme européenne EN 16931, le plus souvent sous la forme Factur-X, transmise par une plateforme agréée. Le système du destinataire peut la comptabiliser sans intervention humaine, et c’est précisément ce format auquel s’attachent les échéances réglementaires.

Une facture PDF, que le destinataire a accepté de recevoir par voie électronique, reste un document valable : l’article 289 du code général des impôts soumet la transmission et la mise à disposition des factures électroniques à l’acceptation du destinataire. Mais elle vaut comme facture, non comme facture électronique, et pour la machine c’est encore une image.

Il s’ensuit une conclusion qui fait économiser beaucoup d’argent : la reconnaissance de factures PDF par OCR (reconnaissance optique de caractères) n’est pas la mise en place de la facture électronique. C’est une opération distincte, que l’on a raison d’automatiser, parce qu’elle réduit la recopie, mais elle ne crée pas un document structuré et ne satisfait pas à l’obligation d’en émettre un. Une entreprise qui tient l’OCR pour la réponse à l’obligation réglementaire découvre au bout de quelques années qu’elle a automatisé le mauvais bout, et le projet doit alors recommencer — avec le système qui émet les factures, non avec celui qui les reçoit.

Le contrôle pratique est ici simple : demandez dans quel format le système est capable d’émettre et de recevoir les données. Si la réponse est « on peut exporter en CSV », ce sont déjà des données structurées, seulement incomplètement automatisées. Si la réponse est « on peut imprimer » ou « on peut enregistrer en PDF », l’image est la seule sortie, et la suite exigera une interface, ou restera de la conjecture.

Sachez aussi que la réponse est souvent meilleure que ce que l’entreprise croit, parce que beaucoup de logiciels de comptabilité et de gestion de stock ont une interface, seulement personne ne l’a jamais demandée, le quotidien se contentant d’un export. Une question au fournisseur — le système a-t-il une interface de programmation (API), et que peut-on en faire — tranche souvent si le projet mérite seulement d’être lancé.

Troisième question : l’étape tranche-t-elle quelque chose à propos d’une personne

La plus grande part de l’automatisation consiste à déplacer des chiffres d’un système à l’autre, et il n’y a là aucune question juridique particulière. Il existe pourtant un groupe d’étapes qu’il faut reconnaître à part : celles qui tranchent quelque chose à propos d’une personne précise — l’embaucher, lui accorder un crédit, la licencier, lui verser une allocation.

L’article 22 du règlement général sur la protection des données — décision individuelle automatisée, y compris le profilage — dispose que la personne a le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé et produisant des effets juridiques la concernant ou l’affectant de manière significative de façon similaire. Des exceptions existent (nécessité contractuelle, droit qui prévoit des garanties, consentement explicite), mais il reste alors le droit d’obtenir une intervention humaine, d’exprimer son point de vue et de contester la décision. Les lignes directrices des autorités de contrôle ajoutent une nuance importante : l’intervention humaine doit être véritable, et un simple bouton de validation que l’on actionne sans regarder le contenu ne fait pas sortir le processus de l’article 22.

Ce n’est pas une interdiction d’automatiser, mais une indication de ce qui, dans un tel processus, est automatisable : on peut automatiser le travail préparatoire (collecte des données, contrôles, préparation d’une proposition), mais la décision elle-même reste à la personne qui la prend vraiment. En pratique cela change le périmètre du projet, et il vaut la peine de le voir avant le développement, non après.

À côté de cela, il est utile de connaître une échéance qui n’est pas encore arrivée, mais qui pèse sur les plans de long terme : les exigences du règlement sur l’intelligence artificielle applicables aux systèmes à haut risque dans le domaine de l’emploi, c’est-à-dire le recrutement et les décisions de personnel, commencent à s’appliquer le 2 décembre 2027. Cela veut dire qu’aujourd’hui le choix est plus libre, mais que pour un système que l’on construit pour durer, cette date doit figurer dans le plan.

Quatrième question : le processus a-t-il déjà une échéance externe

Pour une partie des processus, l’échéance n’est pas fixée par les priorités de l’entreprise, mais par une obligation externe, et ceux-là montent d’eux-mêmes en tête de liste, parce qu’il n’y a plus à décider s’il faut le faire, seulement quand et comment. En France, l’exemple le plus net est à nouveau les factures, et il y a trois dates distinctes que l’on confond souvent.

D’abord, une entreprise qui facture une personne publique dépose déjà ses factures au format structuré sur Chorus Pro depuis le 1er janvier 2020. Ensuite, depuis le 1er septembre 2026, toutes les entreprises doivent pouvoir recevoir une facture électronique, et les données correspondantes parviennent aussi à l’administration fiscale par la plateforme agréée. Troisièmement, l’obligation d’émettre une facture structurée à une autre entreprise s’ouvre le 1er septembre 2027 pour les PME et les micro-entreprises — les grandes entreprises et les entreprises de taille intermédiaire y sont tenues dès 2026, et les autres peuvent déjà émettre sans y être encore contraintes.

C’est précisément cette troisième date qui, dans la circulation publique, est le plus souvent fausse, et la raison est simple : le calendrier initial prévoyait une échéance plus tôt, elle a ensuite été reportée, et une partie des articles secondaires ne l’a jamais corrigée. Pour une entreprise qui établit son budget, l’écart d’une année n’est pas mince, donc la date vaut la peine d’être vérifiée à la source, non dans un récit de seconde main.

Des échéances externes existent aussi ailleurs : le décompte du temps de travail doit être objectif et accessible, les pièces comptables ont des durées de conservation, et les contrats portent souvent des dates de comptes rendus. Le point commun est que ces échéances ne se négocient pas, et qu’un processus qui en a une donne un motif clair au travail — à la différence d’un processus que l’on automatise parce que cela paraît moderne.

À quoi ressemble le processus qu’il vaut la peine de prendre en premier

Si l’on réunit les quatre questions, on obtient un portrait assez concret, que l’on peut coller à n’importe quelle liste : le premier candidat le plus précieux est une chaîne avec un résultat clair, où les données existent déjà sous forme structurée ou peuvent le devenir, où aucune étape ne tranche rien à propos d’une personne, et qui a une échéance externe ou du moins un volume mesurable.

Dans la pratique, cela ressemble en général à ceci : une commande de la boutique arrive dans le système comptable sans recopie ; une chaîne de validations où la demande va à la bonne personne et revient avec une marque ; une synchronisation des données entre l’entrepôt et le site, où quelqu’un exporte aujourd’hui un fichier deux fois par jour. Les trois ont un trait commun — entre deux systèmes circule aujourd’hui un humain avec un fichier.

C’est précisément ce trait le plus facile à voir et le plus difficile à oublier, donc c’est par lui qu’il vaut la peine de commencer l’inventaire. Écrivez où, dans votre entreprise, quelqu’un exporte, copie ou recopie, combien de fois et combien de temps. Cette liste est en général plus courte qu’on ne l’attend, et il s’y trouve presque toujours une ligne qui se détache.

Le deuxième trait qui fait sortir un candidat, c’est le coût de l’erreur, et on l’oublie d’habitude dans le calcul : si une erreur de recopie, dans cette chaîne, veut dire une facture fausse pour le client, un stock faux en entrepôt ou une échéance manquée, alors le gain de l’automatisation n’est pas seulement les heures économisées, mais aussi les erreurs évitées, et c’est en général le plus grand des deux nombres. Un processus dont l’erreur est invisible et sans mal est, de ce point de vue, un moins bon candidat, même s’il prend autant de temps.

Le troisième trait est la façon dont le volume change avec l’entreprise, et c’est le plus important des trois : un travail qui grandit avec l’entreprise, parce que plus de commandes veulent dire plus de recopies, devient avec le temps de plus en plus cher, et c’est là que l’automatisation se rentabilise deux fois : elle libère du temps aujourd’hui et retire un coût qui, sinon, augmenterait. Un travail dont le volume ne bouge pas, quel que soit le chiffre d’affaires, ne donne pas ce second gain.

Au portrait il vaut la peine d’ajouter une chose sur l’ordre, parce que les entreprises s’y trompent plus souvent que sur le choix de l’outil : le premier processus automatisé ne doit pas se choisir selon lequel est le plus grand ou le plus douloureux, mais selon lequel est le mieux compris et le plus vite mené à bout, parce que le premier projet apprend à l’entreprise comment de tels projets se font — comment décrire les exceptions, comment tester et comment traiter les erreurs. Cette leçon coûte beaucoup moins cher sur un travail simple que sur celui dont dépend le flux de trésorerie.

À quoi ressemble le processus qu’il ne vaut pas la peine de prendre en premier

Aussi utile que de reconnaître un bon candidat, il l’est de reconnaître ce qui a l’air séduisant mais se rentabilise mal, et il y a quatre de ces cas. Le premier est un travail rare (une fois par trimestre ou une fois par an), parce que le coût de développement reste le même, mais l’économie se divise par quatre, ou par un.

Le deuxième est un processus dont les règles bougent encore, et c’est le cas où la hâte coûte le plus cher : si les règles ont changé trois fois au cours du dernier semestre, l’automatisation figera la version qui de toute façon va encore changer, et la maintenance absorbera le gain. Ici le bon ordre est de s’accorder d’abord sur les règles, et seulement ensuite de les automatiser, même si dans la pratique c’est souvent l’inverse.

Le troisième est un travail où chaque cas est une exception, et la limite est dans la nature même de la tâche, parce que l’automatisation s’en sort bien avec le fréquent et le prévisible, mais mal avec une situation où dix cas font dix chemins différents ; là, le jugement humain est le travail lui-même, et le remplacer par un arbre de règles crée en général plus d’exceptions qu’il n’en lève.

Ces trois cas ont un trait commun : l’automatisation y fige quelque chose qui n’est pas encore prêt à l’être. Le travail rare n’est pas assez rodé pour qu’il vaille de le figer ; le processus mouvant cherche encore sa forme ; le travail d’exceptions est, par nature, un jugement. Dans les trois, la bonne conduite est d’attendre ou de mettre d’abord de l’ordre, non d’automatiser plus vite.

Le quatrième est le cas où l’on imite l’écran parce que le système n’a pas d’interface. C’est parfois le seul chemin possible, mais c’est aussi le plus fragile : il suffit d’un changement à l’écran, et le travail s’arrête. Si le système a une interface, ou si on peut l’exiger, c’est presque toujours un meilleur choix que d’imiter l’écran.

Qu’advient-il des personnes dont on automatise le travail

Cette question, les propositions d’automatisation la contournent en général, alors que dans l’entreprise on la pose dès le premier jour, et laissée sans réponse elle devient une résistance silencieuse, capable d’arrêter le projet plus sûrement qu’aucun problème technique. La réponse honnête, dans la plupart des petites et moyennes entreprises, est que l’automatisation libère du temps, non une personne : la recopie est la part du travail que personne ne veut, et sa disparition veut en général dire que la même personne arrive enfin à faire ce pour quoi le temps manquait.

Il s’ensuit une recommandation pratique, qui a l’air douce, mais qui est une question pure de conduite de projet : la personne qui fait le travail aujourd’hui doit être associée au projet comme celle qui le connaît le mieux, et non tenue au courant du seul résultat. Elle connaît les exceptions que personne n’a écrites, et ce sont précisément les exceptions qui cassent l’automatisation. Un projet où cette conversation a lieu au début coûte moins cher qu’un projet où elle a lieu après la première erreur.

Il est aussi honnête de dire l’autre face, parce que le contraire serait de faire semblant : si, dans l’entreprise, le travail de quelqu’un consiste entièrement à porter des données d’un système à l’autre, alors l’automatisation remplace vraiment ce travail, et c’est une conversation sur un changement de rôle, que mène la direction de l’entreprise, non le prestataire. Une proposition qui ne pose pas cette question du tout n’est pas délicate — elle n’est simplement pas pensée jusqu’au bout.

Comment calculer votre propre chiffre

Le calcul dont la décision a besoin tient sur une page et n’exige ni consultant ni étude. Il faut quatre nombres : combien de fois par semaine ce travail a lieu, combien de minutes il prend chaque fois, ce que coûte l’heure de la personne qui le fait, et à quelle fréquence une erreur s’y produit, que quelqu’un corrige ensuite.

Les trois premiers donnent le coût direct du temps sur l’année, et ce nombre est en général plus petit qu’on ne l’attendait — c’est précisément pourquoi fonder le projet sur lui seul échoue souvent. Le quatrième nombre est celui qui tranche le plus souvent, parce que le prix de l’erreur est rarement le seul temps de la corriger : une facture fausse veut dire une correspondance avec le client, un stock faux veut dire soit un article qui reste invendu, soit une commande pour un article qui n’est plus en entrepôt, et une échéance manquée veut parfois dire une pénalité.

En face de ces nombres on pose le coût de développement et la maintenance, et c’est précisément la maintenance qu’on oublie. Une automatisation qui relie deux systèmes n’est vivante que tant que le sont les deux interfaces, donc le plan doit laisser une place aux changements qu’exigera quelqu’un d’autre. Si le calcul n’est rentable que lorsqu’on n’inscrit pas le coût de maintenance, alors en réalité il ne l’est pas du tout.

Une autre chose qu’il vaut la peine d’éclaircir avant la conversation, c’est la fréquence à laquelle les systèmes changent. Un service en nuage, qui se met à jour tout seul, peut changer l’interface sans prévenir, tandis qu’un logiciel installé sur place reste le même pendant des années, mais sa mise à jour exigera un jour de tout revérifier. Aucune des deux formules n’est inférieure à l’autre, mais elles demandent un plan de maintenance différent, et une proposition qui ne le reflète pas sera trop bon marché précisément à l’endroit où naîtront ensuite les coûts.

Pourquoi il ne faut pas croire les pourcentages des études

Dans les propositions d’automatisation apparaît presque toujours un chiffre : que l’on peut automatiser la moitié du travail, que les projets échouent dans un tiers des cas, que quelqu’un a économisé des dizaines de milliers d’heures. Ces chiffres existent et se citent, mais ils ne décrivent presque jamais l’entreprise à laquelle on les montre, et c’est précisément ce qui en fait une mauvaise base de décision.

L’indicateur largement cité selon lequel une grande part des activités serait automatisable est un calcul sur des tâches dans la masse salariale d’un pays donné et d’une année donnée, avec les techniques de cette année-là, et l’a publié un cabinet de conseil qui vend ce même service. L’indicateur sur les échecs de projets vient de l’expérience d’un consultant avec des clients qui l’ont appelé après les premiers échecs, donc l’échantillon est faussé déjà par construction. Le chiffre des heures économisées décrit un service comptable précis de quarante personnes, dans un autre pays, il y a plusieurs années.

Il n’en résulte pas que l’automatisation n’est pas rentable, mais que le bon chiffre est le vôtre : combien de fois par semaine ce travail a lieu, combien de temps il prend et ce que coûte l’heure. On peut faire ce calcul sur une page, il décrit précisément votre entreprise, et c’est le seul sur lequel il vaut la peine de fonder une décision.

Ce qu’il faut savoir des systèmes avant de demander un devis

Une fois le candidat choisi, l’étape suivante n’est pas de demander un devis, mais cinq minutes de recherche sur les systèmes eux-mêmes, parce que c’est cela qui tranche si la conversation avec le prestataire portera sur une solution ou sur une possibilité. Établissez si chaque système en jeu a une interface de programmation, si elle est disponible au niveau de votre licence, et si le fournisseur en demande un paiement séparé, parce que les trois réponses ont l’habitude de différer.

La deuxième question est de savoir qui conserve les données et qui a le droit de les modifier. Si deux systèmes portent la même information, par exemple les coordonnées d’un client ou le stock d’un article, il faut avant de les relier décider lequel est la référence, sinon l’automatisation se mettra à les recopier l’un par-dessus l’autre et le résultat sera pire qu’avant. Cette décision est gratuite si on la prend au début, et chère si on la découvre pendant les tests.

La troisième est la question de ce qui se passe quand quelque chose échoue. Dans chaque automatisation il y a des cas qui ne passent pas (il manque un champ, le système ne répond pas, les données se contredisent), et il leur faut un endroit où aboutir, et une personne qui les regarde. Une automatisation sans traitement des erreurs fonctionne aussi longtemps que tout va bien, et cela ne dure jamais longtemps.

Il faut aussi décider d’avance à quoi vous mesurerez si cela a réussi, parce que sans cela le projet ne se termine jamais, il s’interrompt simplement. La mesure peut être tout à fait simple : combien de fois par mois quelqu’un recopie encore des données à la main, combien d’erreurs on a corrigées le mois dernier, et combien de temps une demande met du formulaire à la réponse. Il vaut la peine de relever ce nombre une fois avant de commencer le travail, pour avoir ensuite de quoi comparer. Les entreprises qui ne font pas cette mesure se disputent au bout de six mois pour savoir si quoi que ce soit a changé.

Enfin, il faut se souvenir que l’automatisation n’est pas un travail une fois pour toutes, mais quelque chose qui reste dans l’entreprise et demande un propriétaire, comme n’importe quel autre système. Une fois le processus relié, quelqu’un doit savoir où regarder s’il s’arrête, et quelqu’un doit avoir le droit de l’arrêter si le résultat a l’air faux. Dans les entreprises où ce rôle n’est pas nommé, l’automatisation cesse silencieusement de fonctionner, et on s’en aperçoit seulement au bout d’un mois, quand quelqu’un cherche un document disparu.

Par où commencer concrètement

Le commencement n’est ni le choix d’un outil, ni la demande d’un devis, mais une semaine pendant laquelle on écrit ce qui se passe : quel travail se répète, combien de fois, combien de temps, et à quel endroit une personne y porte des données d’un système à l’autre. Ensuite, posez à chaque ligne les quatre questions de cet article, et la plus grande part de la liste tombera déjà après les deux premières.

Il reste en général un ou deux candidats, et c’est bien, parce que c’est aussi autant qu’il vaut la peine de commencer en même temps : deux travaux achevés donnent plus que six commencés. Une fois le candidat choisi, l’étape suivante est d’établir si les systèmes en jeu ont des interfaces, parce que cela tranche à la fois le prix et la solidité de la solution.

Si à ce stade le processus qui est le vôtre est clair, mais pas la façon de le relier, vous pouvez en parler avec nous : l’automatisation des processus métier, dans notre pratique, ce sont des intégrations et des flux de travail entre les systèmes que vous avez déjà. Si vous voulez d’abord comprendre ce qui distingue les différentes approches et familles d’outils, écrivez-nous ou envoyez-nous votre liste — souvent la réponse est qu’il suffit d’une connexion, pas d’une plateforme.