Guide · Diagnostic d’automatisation
Auditer un processus avant d’y brancher un agent IA.
L’audit suit un dossier réel, repère les décisions et sépare les règles stables du travail qui demande une interprétation. On sait alors ce que l’agent IA peut préparer, ce qu’une règle exécute et ce que l’équipe tranche.
Voir le diagnostic d’automatisation
Ce que ce guide établit
- 01
Entrée observable
Un événement précis déclenche le processus : e-mail, formulaire, fichier ou changement de statut.
- 02
Sortie utile
Le résultat attendu est vérifiable : dossier complet, donnée rapprochée, brouillon prêt ou tâche assignée.
- 03
Exceptions connues
Les cas ambigus, les pièces manquantes et la reprise manuelle sont décrits avant le pilote.
Pourquoi l’audit vient avant l’outil.
Un processus n’est pas une liste de logiciels. C’est une suite de décisions, de transferts et d’attentes qui commence par un événement et se termine par un résultat. Deux entreprises utilisant le même CRM peuvent avoir des flux complètement différents : l’une reçoit des demandes structurées, l’autre doit interpréter des e-mails et des pièces jointes. Installer le même scénario chez les deux reviendrait à automatiser une supposition.
L’audit trace la frontière entre les règles et l’agent IA. Une règle stable traite un identifiant, un statut ou une échéance. L’agent IA intervient sur un e-mail, une pièce jointe ou un libellé variable. Une étape encore mal définie retourne à l’équipe pour être simplifiée. Cette frontière empêche le modèle de prendre une décision que le métier n’a jamais formalisée.
France Num propose de regarder la fréquence de la tâche, le temps consommé, le nombre de personnes concernées, sa complexité et l’impact d’une erreur. Cette base est utile, mais elle doit être complétée par la disponibilité des données, la qualité des accès techniques et la capacité de l’équipe à traiter une exception. Un processus très coûteux en temps n’est pas un bon premier candidat si chaque dossier suit une règle différente.
Ne pas confondre irritant et priorité
La tâche dont tout le monde parle n’est pas toujours celle qui consomme le plus de temps cumulé ou qui bloque le plus de dossiers.
Ne pas confondre démonstration et processus
Extraire une ligne d’un PDF est une fonction. La rattacher au bon dossier, gérer le doublon et demander une validation forme le processus.
Cartographier le flux réel, pas la procédure idéale.
Commencez par un exemple terminé récemment. Reprenez le premier message, les pièces reçues, les fichiers consultés, les décisions prises et les relances. Notez qui intervient, dans quel outil et ce qui lui manque à ce moment précis. Une procédure écrite décrit ce qui devrait arriver ; le dossier réel révèle les contournements, les doubles saisies et les contrôles informels qui font tenir le travail.
La cartographie minimale tient sur une ligne : déclencheur, étapes, décisions, sortie, responsable. Ajoutez ensuite le temps d’attente entre deux étapes. Dans beaucoup de PME, la saisie elle-même dure quelques minutes mais le dossier attend deux jours parce que personne ne sait qu’une pièce est arrivée. Automatiser seulement la saisie ne résout alors pas le problème principal ; une notification ou une file partagée peut avoir plus d’effet.
Pour chaque donnée, identifiez une source de vérité. Le nom du client vient-il du CRM, de l’ERP ou du message reçu ? Quel statut fait foi ? Qui peut corriger une valeur ? Sans réponse, le scénario risque de propager des incohérences plus vite qu’une personne ne les créait. L’audit doit aussi relever les droits d’accès, les formats disponibles et la fréquence des changements chez les éditeurs.
Déclencheur
Ce qui démarre le flux doit être détectable sans interprétation humaine cachée.
Décisions
Chaque embranchement doit avoir une règle, un propriétaire et une réponse lorsque l’information manque.
Sortie
Le résultat doit être visible dans l’outil où l’équipe travaille déjà, pas dans une interface isolée.
Noter les candidats avec une grille simple.
Une note parfaite n’est pas nécessaire. Le but est de comparer plusieurs candidats avec les mêmes questions. Relevez la fréquence mensuelle, le temps actif moyen, le nombre de personnes impliquées et le délai d’attente. Ajoutez une note de stabilité des règles, une note de qualité des données, une note d’impact en cas d’erreur et une note de réversibilité. Les mesures inconnues restent inconnues : elles deviennent une tâche de collecte, pas un chiffre approximatif.
Un bon premier pilote combine généralement une fréquence suffisante, des règles majoritairement stables, une erreur réversible et un responsable disponible. Le traitement des demandes entrantes, la préparation d’un dossier ou la synchronisation de deux outils répondent souvent à ce profil. En revanche, une décision réglementaire, un paiement ou un engagement commercial doit rester derrière une validation explicite même si les étapes préparatoires sont automatisées.
La grille doit aussi faire apparaître le coût du maintien en condition opérationnelle. Qui reçoit l’alerte lorsqu’un connecteur échoue ? Combien de temps l’historique est-il conservé ? Comment tester une modification ? Une automatisation rentable le jour du lancement mais opaque trois mois plus tard déplace simplement la charge vers une crise future.
Transformer l’audit en pilote mesurable.
Le périmètre du pilote tient en une phrase précise : « lorsqu’un e-mail de demande de devis arrive dans cette boîte, reconnaître le client, rattacher les pièces, préparer les champs du CRM et demander une validation ». Cette phrase exclut volontairement les autres boîtes, les autres demandes et les décisions commerciales. Elle donne une entrée, une sortie et une validation observables.
Conservez une mesure de départ sur une période représentative : nombre de dossiers, temps actif, délai de traitement, erreurs corrigées et dossiers repris. Pendant le pilote, utilisez les mêmes définitions. Ne transformez pas une impression positive en pourcentage de gain. Le résultat utile peut être un délai plus stable, une meilleure traçabilité ou moins d’allers-retours, même si le temps moyen bouge peu.
Enfin, testez les exceptions avant la mise en production : document illisible, client inconnu, doublon, API indisponible, droit expiré, réponse IA sous le seuil de confiance. Pour chacune, l’équipe doit savoir où retrouver le dossier et quelle action effectuer. La reprise manuelle n’est pas un échec du projet ; c’est une fonction indispensable du système.
Vous avez plusieurs processus candidats ?
Le diagnostic Flux45 suit un dossier réel, compare les candidats et livre un périmètre de pilote avec règles, exceptions et mesure de départ.
Voir le diagnostic d’automatisationUn exemple réel vaut mieux qu’une liste d’outils.
Apportez un dossier, un e-mail ou un passage entre deux logiciels. Nous le transformons en périmètre testable, exceptions comprises.
Premier échange non facturé. Le devis précède toute connexion à vos systèmes.