Analyser les processus avant d'automatiser : relevé, évaluation, sélection

Elle revient dans presque tous les premiers échanges, généralement en passant et en pensant à une tâche qui coûte chaque semaine des heures à quelqu'un : retaper des devis, transférer des demandes, reporter des données d'e-mails dans un tableur. Ce souhait est compréhensible, et souvent justifié. La difficulté est ailleurs, à savoir dans la question de savoir ce qu'est exactement « ça ».

Supposons qu'une entreprise d'environ quinze salariés souhaite automatiser le traitement des demandes clients entrantes. Si l'on interroge la dirigeante, cela se passe ainsi : la demande arrive, elle est enregistrée, le devis part. Si l'on interroge l'assistante administrative, trois étapes de plus apparaissent : une question à l'entrepôt, un coup d'œil à la liste de prix d'il y a deux ans et une note manuscrite pour le patron. Toutes deux décrivent le même workflow et parlent de choses différentes.

Il est remarquable qu'aucune des deux descriptions ne soit fausse. La dirigeante connaît le workflow du point de vue du résultat, l'assistante du point de vue du travail quotidien. Ce n'est qu'ensemble qu'elles donnent une image, et même alors il manque souvent le point de vue de l'entrepôt ou de la comptabilité, qui participent en marge sans que personne ne pense à eux.

Ce scénario est un schéma type, non un cas isolé rapporté. Il montre pourquoi le travail commence avant l'automatisation. Un workflow que personne n'embrasse dans sa totalité ne peut pas être traduit de façon fiable en règles. Une cartographie des processus le rend visible avant que du temps et de l'argent ne soient investis dans un outil reposant sur une hypothèse incomplète.

Le schéma d'échec le plus fréquent est l'automatisation du détour. Si une facture est aujourd'hui imprimée, visée puis rescannée parce qu'un principe de double validation était autrefois exigé, on peut reproduire ce chemin avec un script. Ce serait plus rapide, mais pas plus intelligent. La vraie question, de savoir si la validation est encore nécessaire sous cette forme, reste sans réponse.

Le deuxième schéma d'échec, ce sont les exceptions. Un workflow fonctionne dans le cas normal et échoue sur les cinq cas particuliers qui surviennent sans cesse au quotidien : un client sans numéro de client, une commande avec livraison partielle, un document au mauvais format. Les humains règlent cela au passage parce qu'ils ont le contexte. Une automatisation sans exceptions documentées s'interrompt ou produit en silence des résultats faux, ce qui est pire.

Troisièmement, il manque souvent quelqu'un de responsable. En pratique, un processus a rarement un propriétaire, il se répartit entre des rôles qui se transmettent le travail. Quand une étape automatisée tombe alors en panne, personne ne sait qui doit le remarquer, la corriger ou décider si elle peut continuer à tourner. De ces trois schémas découle ce qu'une cartographie des processus doit saisir.

Celui qui a vu une fois ce qui est possible veut généralement se lancer tout de suite, et ce avec le processus qui l'agace le plus. C'est humain et rarement le meilleur choix. Ce qui dérange le plus n'est pas automatiquement ce qui s'automatise le mieux, et les tâches pénibles le sont souvent précisément parce qu'elles comportent beaucoup d'exceptions.

Nous évaluons donc les candidats selon quelques critères sobres. La fréquence indique combien de fois un workflow se produit par semaine ou par mois. La durée indique combien de temps de travail il mobilise à chaque passage. La sensibilité aux erreurs décrit à quelle fréquence surviennent reprises, questions de relance ou corrections. En contrepoids s'ajoute la régularité : plus une étape exige de jugement, moins elle se prête à un enchaînement fixe.

Concrètement, chaque candidat reçoit une fiche avec de brèves indications sur ces critères, expressément en tant qu'estimation approximative et avec la source en regard, par exemple « comptage dans la boîte mail, quatre semaines » ou « estimation de l'assistante ». On voit ainsi quel chiffre est établi et lequel est supposé. Les fiches sans indications fiables ne passent pas dans la sélection, mais d'abord dans une courte phase de mesure.

Cela devient intéressant quand on met les critères côte à côte. Une opération rare, mais qui coûte une demi-journée à chaque fois, peut être plus rentable qu'une autre qui se produit chaque jour et dure deux minutes. À l'inverse, une étape fréquente, courte et sujette aux erreurs est souvent le meilleur point d'entrée, car même de petites améliorations évitent de nombreuses erreurs. La pondération dépend de l'entreprise, et c'est précisément pourquoi la discussion à ce sujet est utile.

L'alternative évidente à la cartographie des processus est le tâtonnement : brancher un outil, lancer une première exécution, corriger. Pour de toutes petites tâches autonomes, c'est défendable, par exemple lorsqu'une seule personne réalise seule une seule étape. Dès que plusieurs rôles, systèmes ou clients sont impliqués, corriger après coup devient coûteux, car chaque correction touche d'autres intervenants et les erreurs se voient tard.

La deuxième alternative est un modèle de processus exhaustif, comme il est d'usage dans les grandes organisations, avec notation, outil et série d'ateliers. Pour une entreprise de dix à cinquante salariés, l'effort est rarement proportionné au résultat. Nous gardons volontairement la cartographie légère : un entretien par rôle, une demi-heure d'observation au poste de travail, un schéma du déroulement tenant sur une page. Cela suffit pour prendre des décisions.

Notre ordre est : comprendre, simplifier, décider, puis automatiser. Simplifier est l'étape souvent sautée. Parfois, le besoin disparaît dès qu'une double saisie est supprimée ou qu'une validation est abandonnée. Ce n'est pas un échec du projet, mais son résultat le plus favorable, car une étape qui n'existe plus n'a besoin ni de maintenance ni de surveillance.

Une troisième alternative est l'achat d'une solution métier qui apporte le workflow « clé en main ». Cela peut fonctionner si votre entreprise correspond au standard du secteur. Si elle s'en écarte, vous adaptez soit le logiciel à votre workflow, soit votre workflow au logiciel. Les deux sont légitimes, mais il doit s'agir d'une décision consciente, et pour cela il faut avoir une image de son propre workflow.

Le prix de cette démarche, c'est du temps au départ. Le relevé retarde l'avancement visible de quelques jours à quelques semaines, selon le nombre de processus. En contrepartie, on évite des remaniements ultérieurs. Si vous êtes pressé, vous pouvez commencer par un seul processus bien délimité et y limiter le relevé.

L'entretien ne commence pas par la question du processus, mais par un cas concret. « Racontez-moi la dernière demande que vous avez traitée » apporte plus que « Comment cela se passe-t-il d'habitude ? ». La première question fait remonter le souvenir de détails réels, la seconde la version idéalisée. Nous demandons à voir les fichiers, les boîtes mail et les notes sur papier dans la mesure du possible, et nous demandons après chaque étape : que se passe-t-il avant, que se passe-t-il après, et qui attend cela ?

L'observation complète l'entretien là où les gens ne perçoivent plus consciemment leur propre travail. Celui qui tient le même tableau depuis des années ne mentionne plus le réflexe d'aller chercher la seconde liste. Observer révèle aussi les temps d'attente : un processus qui dure une heure sur le papier prend en réalité deux jours, parce qu'un dossier attend sur un bureau que quelqu'un revienne. Cet écart entre temps de traitement et délai de bout en bout est central pour l'évaluation.

De ces échanges naît la cartographie du processus, d'abord sous forme de simple séquence : déclencheur, étapes, résultat. Chaque étape reçoit quatre informations : qui l'exécute, sur quel support, à quelle fréquence elle survient et quelles exceptions existent. Nous marquons en couleur les ruptures de support, car elles sont presque toujours à la fois des sources d'erreurs et de bons points d'entrée. C'est là qu'on ressaisit, copie ou classe, et c'est là que naît l'essentiel des questions en retour.

La confrontation est essentielle. Nous montrons la cartographie aux personnes concernées et demandons : est-ce bien cela ? Les corrections sont le véritable gain de connaissance, car elles révèlent où les perceptions divergent. Ce n'est que lorsque tous disent « chez nous, ça se passe comme ça » que le processus actuel est considéré comme relevé.

À partir du processus actuel, nous concevons le processus cible en deux temps. D'abord on supprime et on regroupe : quelles étapes n'apportent aucune valeur au client ni à un contrôle démontrablement nécessaire ? Quelle information est saisie deux fois ? Ensuite on décide lesquelles des étapes restantes une machine peut reprendre et lesquelles restent aux personnes. Cette séparation en deux temps évite que l'automatisation serve de substitut à une décision qui devrait en réalité être prise dans l'entreprise.

Pour la mise en œuvre technique, le relevé et le choix des outils sont deux questions distinctes. Les processus à base de règles avec des déclencheurs clairs se résolvent le plus souvent avec des outils de connexion entre les systèmes existants, sans logiciel dédié. Là où il faut interpréter des textes, des e-mails ou des documents, un modèle de langage peut prendre en charge certaines étapes, par exemple classer des demandes ou extraire des champs. Il faut alors prévoir un contrôle de plausibilité en amont ou en aval, car ces modèles se trompent parfois sans le signaler.

À partir du relevé, chaque étape automatisée reçoit trois définitions. Premièrement, un contrôle d'entrée : quelles données doivent être présentes pour que l'étape puisse démarrer ? Deuxièmement, une sortie pour les exceptions, qui confie le cas à une personne désignée plutôt que de deviner. Troisièmement, une trace, c'est-à-dire un journal qui permet de retrouver ce qui s'est passé, quand et avec quel résultat. Sans ces trois éléments, il est difficile de juger en exploitation si l'automatisation améliore quelque chose.

Un exemple pratique : une demande arrive par formulaire. Le processus cible vérifie les champs obligatoires, crée le contact, attribue la demande à une personne et envoie un rappel après le délai convenu. L'offre elle-même reste rédigée par un humain, car le prix et l'étendue se négocient au cas par cas. L'automatisation n'est pas devenue plus petite ici, elle a été déplacée aux bons endroits.

Le premier cas particulier est l'exception qui n'en est pas une. Lors du relevé apparaît un cas particulier que tout le monde décrit comme rare. Le comptage dans la boîte mail montre alors qu'un tiers des dossiers sont concernés. Cela change fondamentalement la planification : soit le cas particulier relève du processus standard, soit le processus standard est moins standardisé qu'on ne le pensait. Nous vérifions donc ces affirmations sur un échantillon des dernières semaines, et pas seulement de mémoire.

Le deuxième cas est le savoir qui n'est écrit nulle part. Une collaboratrice de longue date sait quel client veut toujours une confirmation par téléphone et quel fournisseur s'écarte volontiers sur les quantités. Ces règles ne sont pas documentées et ne se trouvent en entretien qu'en interrogeant précisément sur les surprises : qu'est-ce qui n'a pas fonctionné récemment, et à quoi l'avez-vous remarqué ? Ce savoir d'expérience est soit traduit en règle, soit consigné comme motif de contrôle humain.

Troisièmement, le scepticisme de l'équipe. Celui qui relève des processus pose des questions sur le travail des autres, et cela peut ressembler à du contrôle ou à la préparation d'une suppression de postes. Nous énonçons l'objectif ouvertement : il s'agit de déléguer la routine et de dégager du temps pour des tâches qui demandent du jugement, pas d'évaluer des personnes. Les propos tenus en entretien restent anonymes dans la cartographie, et les personnes concernées voient le résultat avant qu'il ne soit transmis.

Quatrièmement, il existe des processus soumis à un cadre légal ou contractuel, par exemple des obligations de conservation ou de documentation. Nous ne connaissons ces exigences que dans leurs grandes lignes et ne les tranchons pas de manière définitive. Elles font partie du relevé comme contrainte, et en cas de doute, c'est un conseil fiscal ou juridique qui devrait décider de ce qui doit subsister dans le processus cible.

L'intérêt d'un relevé de processus réside d'abord dans les décisions, pas dans les automatisations. Vous savez ensuite quels processus valent la peine, lesquels modifier en premier et lesquels restent manuels. Cela réduit le risque d'investir dans des outils qui résolvent le mauvais goulot d'étranglement. Cet intérêt est réel mais difficile à chiffrer en euros, et nous n'avançons aucun montant.

Là où l'on automatise ensuite, l'effet se lit sur quelques indicateurs. Le délai de bout en bout montre combien de temps un dossier met de la réception à la clôture. Le nombre de questions en retour et de corrections montre si les erreurs deviennent plus rares. Le temps de traitement manuel par dossier, relevé sur quelques semaines avec un simple décompte à la main ou des horodatages, montre l'allègement réel. Il est important de relever ces valeurs avant, sinon la comparaison fait défaut.

Il y a aussi des limites. Le temps gagné dépend de l'entreprise et ne peut être estimé que grossièrement à l'avance. Une automatisation peut en outre créer du travail nouveau : il faut traiter les exceptions, lire les journaux et entretenir les règles. Une comparaison honnête inclut cet entretien. Après la mise en service, comptez avec une phase d'ajustement des processus, et jugez le résultat au bout de quelques semaines, pas après les premiers jours.

Le gain de clarté n'est pas mesurable, mais il se ressent. Lorsque les responsabilités sont nommées, les ruptures de support réduites et les exceptions connues, l'entreprise se pilote mieux, même sans technique. Certaines équipes rapportent dans de tels projets que le relevé lui-même était déjà la plus grande avancée. On ne peut pas le garantir, mais c'est un effet secondaire plausible.

Premièrement : commencez par un processus, pas par tous. Un seul processus bien délimité donne un résultat rapidement et montre si la démarche convient à votre entreprise. Deuxièmement : mesurez avant d'intervenir. Sans valeur de départ, toute affirmation sur le succès reste une opinion. Un simple décompte à la main sur deux semaines suffit déjà pour repérer des ordres de grandeur.

Troisièmement : consignez ce qui reste volontairement manuel, et justifiez-le. Cela concerne les étapes qui relèvent du jugement ou de la relation, comme l'échange avec un client mécontent ou la décision de prix pour une commande spéciale. Les étapes dont une erreur cause un dommage important, comme les validations de paiement, devraient aussi garder une confirmation humaine. Et les cas si rares que le développement et l'entretien ne seraient jamais amortis restent eux aussi aux mains des personnes.

Quatrièmement : introduisez les automatisations progressivement. Un état intermédiaire où le système fait une proposition et où un humain confirme met au jour les hypothèses erronées avant qu'elles aient des conséquences. Ce n'est que lorsque les propositions s'avèrent justes sur une période assez longue qu'il vaut la peine d'assouplir la confirmation. Cinquièmement : désignez pour chaque processus automatisé une personne responsable qui en examine régulièrement l'état.

Ces règles n'ont rien de spectaculaire, et c'est précisément leur valeur. Elles déplacent le centre de gravité de la technique vers la décision. Aujourd'hui, la technique est rarement le facteur rare ; la clarté sur son propre processus, si.

Qui veut analyser et automatiser des processus devrait faire les deux dans cet ordre. L'analyse clarifie comment l'entreprise travaille réellement, où l'information se perd et ce qui n'existe que par habitude. L'automatisation intervient là où elle allège de façon démontrable. Entre les deux se situe la décision honnête sur ce qui peut rester, ce qui change et ce qui reste volontairement du travail manuel.

L'étape suivante est modeste et ne demande aucun projet. Choisissez un processus qui vous coûte régulièrement du temps et demandez à deux personnes concernées de le décrire séparément, simplement en mots-clés sur une feuille. Les différences entre les deux feuilles constituent le premier constat. Si elles sont grandes, il vaut la peine de relever le processus plus précisément avant de choisir le moindre outil.

La même règle vaut pour l'échange avec les prestataires. Une offre qui promet un gain de temps fixe sans regarder votre processus repose sur des hypothèses que personne n'a vérifiées. Demandez quelles étapes l'outil prend en charge, ce qui se passe en cas d'exception et qui surveille l'exploitation. Celui qui sait répondre concrètement s'est penché sur votre processus.

Nous accompagnons volontiers ce relevé et vous dirons franchement, après un premier échange, si une automatisation est rentable ou si une simplification suffit. Le second résultat est lui aussi bon. Il vous évite un projet qui aurait coûté plus qu'il ne rapporte.