7 min de lectureLe joli logo dans la barre d’onglets peut attendre
Un besoin apparaît dans l’entreprise. Quelques recherches plus tard, quelqu’un a déjà ouvert quatre essais gratuits. Un outil a de jolies bulles reliées par des flèches. Un autre promet de tout faire grâce à l’intelligence artificielle. Un troisième vient d’être recommandé dans une vidéo dont le titre annonce, en majuscules, que plus rien ne sera jamais comme avant.
Nous voilà parfaitement renseignés. Sauf sur le processus.
Le choix d’une solution technique devrait découler de la compréhension du fonctionnement recherché, pas en être le point de départ. Sinon, l’entreprise finit facilement par plier sa façon de travailler aux capacités de l’outil : elle ajoute une étape parce que le logiciel la propose, accepte une limite parce qu’elle est déjà là, et bâtit peu à peu un processus très propre autour d’un besoin qui n’a jamais été clairement formulé.
La technologie a alors pris une avance confortable sur la réflexion.
Dessiner oblige à expliquer ce que l’on fait réellement
Prenons une demande entrante. Elle arrive où ? Qui la voit ? Comment reconnaît-on son sujet ? Existe-t-il plusieurs niveaux de priorité ? Que se passe-t-il quand une information manque ? À qui la demande est-elle attribuée, et comment cette personne sait-elle qu’elle doit agir ? Qu’est-ce qui indique ensuite que le dossier est terminé ?
En quelques questions, une activité que tout le monde jugeait « assez simple » a généralement gagné plusieurs branches. C’est normal. Un processus n’est pas qu’une suite d’étapes : il comprend des déclencheurs, des décisions, des attentes, des retours en arrière, des données, et des personnes qui n’ont pas toutes la même responsabilité.
La modélisation des processus existe depuis bien avant la vague actuelle d’automatisation. Le standard BPMN, maintenu par l’Object Management Group, offre par exemple un langage formel pour représenter les événements, les activités, les décisions et les flux d’un processus métier. La spécification BPMN 2.0.2 est publique.
Une PME n’a pas forcément besoin de maîtriser toute cette notation pour démarrer. Un tableau blanc, quelques rectangles et des flèches suffisent souvent. Le but n’est pas de produire un diagramme si élégant qu’il provoquera une émotion sincère chez les architectes logiciels. Le but, c’est que deux personnes regardent le même dessin et comprennent le même fonctionnement.
C’est déjà une belle performance collective.
Le processus officiel et le processus réel entretiennent parfois une relation lointaine
Sur le papier :
Le commercial met à jour le CRM après chaque interaction.
Dans la vraie vie :
Oui.
Enfin, normalement.
Sauf quand il est en déplacement.
Et Paul utilise encore son fichier, mais seulement pour les gros comptes.
Voilà.
Les procédures décrivent ce qui devrait se passer. Le travail quotidien montre ce qui se passe vraiment.
C’est précisément l’idée du process mining : reconstruire les flux effectifs à partir des journaux d’événements produits par les systèmes, afin d’observer les variantes, les retards et les chemins réellement empruntés. La communauté Process Mining présente cette discipline, à la rencontre de la science des processus et de la donnée.
Toutes les entreprises n’ont évidemment pas besoin d’une plateforme spécialisée. L’idée de fond, elle, reste excellente :
ne supposez pas que votre processus correspond à la procédure. Regardez ce qui se passe.
Parlez aux personnes qui l’exécutent. Observez les outils, les fichiers, les emails, les exceptions. Et intéressez-vous à ce tableur personnel dont on vous assurera d’abord qu’il n’est « pas vraiment utilisé ».
Il est utilisé.
Une bonne carte montre les décisions, pas seulement les étapes
Un workflow trop vague ressemble souvent à ceci :
Demande → Analyse → Traitement → Réponse
C’est impeccable, et nous n’avons presque rien appris.
Ce qui rend un processus intéressant, ce sont ses bifurcations :
- si le client est déjà connu ;
- si le montant dépasse un seuil ;
- si la pièce est absente ;
- si le système n’est pas certain ;
- si la demande concerne un cas sensible ;
- si une action précédente a déjà été effectuée.
C’est là que les différents types de traitement apparaissent. Une règle déterministe peut décider qu’un montant au-dessus d’un seuil appelle une validation. Une IA peut comprendre qu’un message parle d’une résiliation même si le mot n’y figure jamais. Une automatisation peut créer le ticket et rassembler les pièces. Une personne peut arbitrer la situation.
Le workflow devient alors moins une succession de boîtes qu’une répartition explicite des responsabilités.
Les exceptions doivent apparaître avant l’étape « on verra plus tard »
On a tendance à garder les cas particuliers pour la fin. D’abord, faisons marcher le scénario nominal, on verra le reste ensuite. C’est raisonnable pour un prototype. Ça l’est moins quand le processus touche déjà les clients, les paiements ou les opérations quotidiennes.
Une donnée manquante n’a rien d’un événement extraordinaire. Une API qui ne répond pas non plus. Un document au mauvais format encore moins. Le monde réel a un sens très personnel de la conformité.
Dessiner les exceptions avant de construire oblige à répondre à des questions utiles :
- Attend-on ?
- Réessaie-t-on ?
- Informe-t-on quelqu’un ?
- Peut-on reprendre manuellement ?
- Comment évite-t-on de traiter deux fois la même opération ?
- Que se passe-t-il si le système reste incertain ?
Ce sont rarement les points mis en avant dans les démonstrations les plus séduisantes. Ce sont souvent eux qui décident si l’automatisation sera encore utilisée six mois plus tard.
La carte révèle aussi les tâches qui devraient disparaître
Dessiner le processus ne sert pas seulement à préparer son automatisation. Cela permet parfois de découvrir qu’une étape n’a plus de raison d’être.
Pourquoi cette personne ressaisit-elle une donnée déjà présente ailleurs ? Pourquoi deux validations successives contrôlent-elles exactement la même chose ? Pourquoi le dossier attend-il systématiquement un export produit le vendredi, alors que l’information existe depuis le lundi ? Pourquoi fabrique-t-on ce reporting chaque semaine si personne ne prend de décision à partir de lui ?
Le simple fait de représenter le flux rend certaines incohérences visibles. Avant même d’écrire une ligne de code, les métiers voient leurs habitudes sous un nouveau jour, les équipes techniques saisissent mieux le besoin, et les responsabilités deviennent discutables, au bon sens du terme.
Puis quelqu’un finit généralement par demander :
Attendez. Pourquoi faisons-nous cette étape ?
Silence.
Excellente question.
Le premier outil d’automatisation vient peut-être de servir. C’était un feutre.
Puis seulement vient la question des outils
Une fois le processus compris, la technologie devient bien plus facile à choisir.
Une séquence stable de règles et d’API peut convenir parfaitement à une plateforme d’automatisation. Une logique très spécifique peut justifier un développement sur mesure. Un problème de compréhension de documents ou de messages peut appeler un modèle d’IA. Un travail vraiment variable, où il faut choisir dynamiquement des actions et des outils, peut éventuellement justifier un agent. Et parfois, un formulaire mieux conçu règle la moitié du problème.
C’est moins impressionnant en démonstration. Cela coûte aussi beaucoup moins cher.
Le choix devient plus rationnel, parce qu’on peut le relier à des exigences précises :
- volume ;
- criticité ;
- fréquence des exceptions ;
- systèmes à connecter ;
- compétences disponibles ;
- niveau de maintenance acceptable ;
- besoin d’autonomie ou de validation humaine.
On ne cherche plus « le meilleur outil ». On cherche l’outil suffisamment adapté au processus. La nuance évite bien des regrets d’abonnement annuel.
Le dessin doit rester vivant
Un workflow n’est pas un monument. Il doit évoluer quand les règles changent, qu’un logiciel est remplacé, qu’une nouvelle contrainte apparaît ou que les équipes trouvent un meilleur fonctionnement.
Mieux vaut donc une carte compréhensible et facile à maintenir qu’un document si sophistiqué que plus personne n’ose y toucher. Quelques bonnes pratiques suffisent :
- nommer clairement les étapes ;
- identifier les systèmes et les personnes ;
- distinguer les règles, l’IA et l’intervention humaine ;
- montrer les exceptions principales ;
- indiquer le début et le résultat attendu ;
- conserver une version à jour accessible à l’équipe.
Le dessin n’a pas besoin de tout raconter. Il doit permettre aux bonnes personnes de poser les bonnes questions.
Avant l’outil, le fonctionnement
Une entreprise qui commence par cartographier son processus n’avance pas moins vite. Elle évite simplement de confondre mouvement et progrès. Elle sait ce qui doit disparaître, ce qui peut être exécuté automatiquement, ce que l’IA peut préparer et où l’humain garde la décision.
À partir de là, n8n, Make, une API, du code ou un agent cessent d’être des solutions en quête d’un problème. Ils redeviennent ce qu’ils auraient toujours dû être :
des moyens de faire fonctionner un processus compris.