Méthode, Cartographie des processus

Diagnostic automatisation IA : la méthode en 5 jours

La méthode d'atelier en cinq jours pour cartographier vos flux d'information, repérer les ressaisies et les goulots, scorer vos processus et sortir avec une feuille de route à trois mois, sans parler d'outils.

Par Yanis Zedira. Publié le 30 août 2026. 10 min de lecture.

Un diagnostic d'automatisation sert à savoir où part le temps dans l'entreprise avant de décider quoi automatiser. Il se mène en cinq jours d'atelier, avec les équipes qui font le travail, et il produit trois choses : une cartographie des flux d'information, un classement des processus par potentiel, et une feuille de route à trois mois. Aucun outil n'y est choisi, aucune démonstration n'y est faite.

Ce n'est pas un audit informatique. On ne regarde ni le parc, ni les licences, ni l'architecture. On regarde qui reçoit quoi, par quel canal, ce qu'il en fait, et où l'information est ressaisie une deuxième fois. L'audit de trente minutes pour cartographier les pertes cachées est la version express que le dirigeant fait seul, sur un coin de table. Le diagnostic décrit ici en est le format accompagné et collectif : plus long, plus contradictoire, et beaucoup plus difficile à contester ensuite.

Pourquoi cartographier avant de lancer un projet ?

Parce que le dirigeant se trompe presque toujours sur l'endroit où part le temps. Ce n'est pas un défaut de compétence, c'est structurel : il voit les tâches qui l'interrompent, pas celles qui occupent une assistante trois heures chaque jeudi.

J'ai vu à plusieurs reprises la même scène. La direction arrive avec un sujet identifié, souvent la relation client, parce que c'est celui dont on parle en réunion. Au jour 2, la cartographie fait apparaître qu'une même information de commande est saisie trois fois, dans trois outils différents, par trois personnes différentes. Ce sujet-là n'était sur la liste de personne, il ne se voit dans aucun indicateur, et c'est le meilleur candidat de l'entreprise.

La cartographie sert aussi à éviter l'inverse : automatiser un processus qui va disparaître. Une entreprise sur le point de changer d'ERP, ou de fusionner deux équipes, n'a rien à gagner à automatiser un flux qui n'existera plus dans six mois. Cette information ne remonte qu'en atelier, quand tout le monde est dans la même pièce.

Enfin, elle produit un accord. Un projet décidé seul se subit. Un projet issu d'une semaine où les équipes ont elles-mêmes désigné les irritants ne rencontre pas la même résistance au moment de la mise en service.

Jour 1 : que fait vraiment chaque équipe ?

Le premier jour est un recensement, équipe par équipe, en séances de quatre-vingt-dix minutes. Une question ouvre chaque séance : citez tout ce que vous faites qui se répète, quelle que soit sa durée.

La consigne importante est de ne rien filtrer. Pas de tri entre ce qui est automatisable et ce qui ne l'est pas, pas de jugement sur la valeur de la tâche. Le tri viendra au jour 3, et il viendra avec une grille. À ce stade, une personne qui s'auto-censure fait disparaître le meilleur candidat.

Pour chaque tâche recensée, on note quatre informations : la fréquence, la durée typique, qui la fait, et ce qui la déclenche. Cette dernière colonne est celle qu'on oublie et c'est la plus utile. Une tâche déclenchée par un mail, une tâche déclenchée par une alerte d'un logiciel et une tâche déclenchée par un souvenir n'appellent pas du tout les mêmes réponses.

Une remarque de terrain : les séances par équipe donnent de bien meilleurs résultats qu'une séance plénière. Devant la direction, personne ne dit qu'il retape à la main un fichier chaque matin depuis quatre ans.

Jour 2 : d'où part l'information et où se perd-elle ?

Le deuxième jour est le cœur du diagnostic. On trace, pour cinq à huit processus clés, le trajet complet d'une information.

Quatre questions structurent chaque trajet. D'où part l'information : un client, un fournisseur, un capteur, un salarié ? Par quel canal arrive-t-elle : mail, téléphone, formulaire du site, papier, message sur un réseau ? Où est-elle stockée : un logiciel métier, un tableur, une boîte mail, la tête de quelqu'un ? Et qu'est-ce qui la fait avancer à l'étape suivante ?

Sur ce tracé, on marque deux symboles. Une ressaisie, chaque fois qu'une donnée déjà présente quelque part est retapée ailleurs à la main. Un goulot, chaque fois que le flux attend une seule personne, une validation, ou un moment précis de la semaine.

Les ressaisies donnent les gains les plus rapides et les moins risqués. Les goulots donnent les gains les plus importants, mais ils touchent souvent à l'organisation autant qu'à la technique, et il faut le dire clairement plutôt que promettre qu'un outil réglera un problème de délégation.

Un point de vigilance qui revient tout le temps : le tableur parallèle. Presque toutes les entreprises ont un fichier partagé qui contient la vraie information, mise à jour à la main, à côté du logiciel officiel. Ce fichier est le meilleur indicateur de l'endroit où le système en place ne répond pas au besoin réel.

Jour 3 : comment noter les processus objectivement ?

Le troisième jour transforme la cartographie en classement. Chaque processus recensé reçoit une note sur cinq critères, et le résultat se discute en groupe.

La note se calcule, mais elle ne décide pas seule. Elle sert à écarter les faux bons candidats et à faire remonter ceux que personne n'avait cités. Le débat sur les écarts de notation entre deux équipes est souvent plus instructif que le classement final.

Un mot sur ce qu'on ne note pas : l'enthousiasme. Le processus dont l'équipe a le plus envie n'est pas nécessairement celui qui rend le plus. On garde l'information de côté, parce qu'une équipe motivée fait réussir un chantier, mais on ne la met pas dans la grille.

Jour 4 : quels chantiers retenir en priorité ?

Le quatrième jour sélectionne. Deux ou trois quick wins, plus un seul chantier structurant. Pas davantage, et l'exercice consiste surtout à dire non.

Un quick win se reconnaît à trois signes : il se livre en deux à quatre semaines, il ne dépend d'aucune décision extérieure au groupe présent, et son résultat se voit sans instrument de mesure. Une notification automatique qui remplace un contrôle manuel quotidien, un formulaire qui remplit directement le logiciel au lieu d'un mail retapé, une relance qui part seule. Ces chantiers ne transforment rien, et ce n'est pas leur rôle : ils financent la crédibilité du reste.

Le chantier structurant est différent. Il porte sur le goulot principal identifié au jour 2, il demande deux à trois mois, il touche souvent plusieurs équipes. Un seul suffit, parce qu'il consommera l'essentiel de l'attention disponible. Le guide pour automatiser son entreprise détaille la conduite de ce type de chantier.

Pour chaque élément retenu, on écrit quatre lignes : ce qui change concrètement pour les utilisateurs, l'indicateur qui dira si c'est réussi, sa valeur aujourd'hui, et qui porte le sujet côté métier. Sans cette dernière ligne, le chantier n'existe pas.

Jour 5 : que contient la feuille de route ?

Le dernier jour produit le document de sortie. Il est court, entre six et dix pages, et il se lit par quelqu'un qui n'était pas dans la salle.

La dernière ligne est celle qu'on supprime le plus souvent et celle qui a le plus de valeur à six mois. Écrire pourquoi un sujet a été écarté évite qu'il revienne trois fois dans l'année, et évite aussi qu'on l'écarte à tort quand la raison a disparu.

Les garde-fous méritent une vraie section. Quelles données sortent de l'entreprise et lesquelles ne sortent pas, qui valide avant envoi au client, ce qui est journalisé, et comment on revient en arrière. Le cadre du RGPD appliqué à l'automatisation IA donne la base à reprendre ici, avant tout choix technique.

Ce que je vois le plus souvent chez un client

L'erreur la plus fréquente est de faire venir un prestataire outil au jour 1. La démonstration prend toute la place, le groupe se met à discuter de fonctionnalités, et la cartographie ne se fait jamais. Un diagnostic qui parle d'outils avant le jour 5 a raté son objet. La question du choix technique se traite après, et le comparatif des plateformes d'automatisation y répond quand le moment est venu.

La deuxième chose que j'observe, c'est la sous-estimation systématique des durées au jour 1. Les gens annoncent dix minutes pour une tâche qui en prend vingt-cinq, parce qu'ils comptent le geste et pas la reprise de contexte, ni les allers-retours pour retrouver l'information. Quand un chiffre paraît bas, je demande de refaire la tâche en direct, montre en main. L'écart est régulièrement du simple au double.

Le troisième point est humain. Une semaine d'atelier fait remonter des irritants que les équipes portent depuis des années. Si rien ne bouge dans les trois mois, la confiance est plus abîmée qu'avant le diagnostic. C'est pour cela que les quick wins ne sont pas optionnels : leur fonction est de prouver que la semaine a servi à quelque chose.

Passer à l'action

Faites le jour 2 tout seul, cette semaine, sur un seul processus. Prenez votre flux de commandes ou de demandes entrantes, une feuille, et tracez le trajet d'une information réelle depuis son arrivée jusqu'à sa clôture. Marquez d'une croix chaque endroit où quelqu'un retape une donnée qui existe déjà ailleurs. Comptez les croix. Ce chiffre vous dira, en vingt minutes, si un diagnostic complet vaut le coup chez vous.

Si vous préférez le cadre accompagné, avec les équipes dans la salle et un tiers qui pose les questions gênantes, parlons-en lors d'un appel de trente minutes. On regarde votre organisation, le nombre d'équipes à couvrir et le format adapté. Les créneaux sont sur le calendrier de YZ Automation.