La question n’est plus de savoir s’il faut automatiser, mais par où commencer. Automatisation robotisée des processus, plateformes de workflow, modèles d’IA : ces outils sont désormais à la portée de toutes les organisations, et la pression pour afficher des avancées est bien réelle. Pourtant, ce qui détermine le succès de ces investissements tient rarement à la technologie elle-même. Il tient à l’état du processus qu’on lui confie.
Un processus mal défini, appliqué de façon hétérogène ou alimenté par des données peu fiables ne s’améliore pas en étant automatisé. Il échoue simplement plus vite, à plus grande échelle et de manière moins visible. Préparer les opérations en amont n’est donc pas une perte de temps : c’est précisément ce qui donne de la valeur à l’automatisation.
L’automatisation amplifie le processus dont elle hérite
Dans un processus manuel, les collaborateurs expérimentés compensent discrètement les failles. Ils savent quel fournisseur envoie systématiquement des factures incomplètes, quels codes clients sont en doublon, quelle validation peut attendre sans risque. Ce savoir implicite n’apparaît dans aucune procédure, et il disparaît dès qu’un robot ou un modèle prend le relais. On connaît la suite : une automatisation qui fonctionne en recette, puis génère en production une file d’exceptions croissante, traitée par les équipes mêmes qu’elle devait soulager.
La leçon n’est pas de renoncer à automatiser, mais de rendre d’abord le processus explicite : ses étapes, ses règles de décision, ses exceptions et ses responsables.
Partir de la réalité du terrain
Les procédures décrivent le fonctionnement théorique. L’automatisation, elle, a besoin du fonctionnement réel. La phase de préparation doit donc s’appuyer sur l’observation et sur les données, et pas seulement sur des ateliers. Les outils de process mining sont utiles lorsque les journaux applicatifs sont suffisamment riches, mais les entretiens et l’observation directe avec les opérationnels restent irremplaçables.
- Cartographier le processus de bout en bout, de l’événement déclencheur au résultat final, en traversant les frontières entre directions et entre systèmes.
- Recenser les variantes et les exceptions, puis décider lesquelles supprimer, lesquelles standardiser et lesquelles laisser volontairement à l’appréciation humaine.
- Formaliser les règles de décision, y compris les seuils et critères que les collaborateurs expérimentés appliquent de manière informelle.
- Désigner un responsable métier du processus, garant de sa performance et de toute évolution de ses règles une fois automatisé.
- Établir une situation de référence (volumes, délais, taux d’erreur et de reprise) afin de pouvoir mesurer objectivement l’apport de l’automatisation.
La qualité des données relève de l’exploitation, pas seulement de la DSI
Une automatisation fondée sur des règles bute sur les données erronées ; un modèle d’IA, lui, apprend à partir d’elles. Dans les deux cas, la qualité des données de référence et des flux transactionnels conditionne celle des résultats. On confie volontiers ce sujet à la DSI, alors que la plupart des anomalies naissent dans les opérations : champs libres renseignés de façon hétérogène, référentiels maintenus par plusieurs équipes, documents reçus dans des formats que personne ne maîtrise.
Se préparer à l’automatisation, c’est donc attribuer la responsabilité des données critiques, définir ce qu’est une donnée « correcte » et placer les contrôles à la saisie plutôt que de compter sur des corrections en aval. Pour les cas d’usage d’IA, c’est aussi connaître l’origine des données d’entraînement et de référence, vérifier qu’elles reflètent les pratiques actuelles et que leur utilisation respecte les obligations de confidentialité et de protection des données.
Choisir quoi automatiser, et comment
Tout processus n’a pas vocation à être automatisé, et tout processus automatisable n’a pas besoin d’IA. Les activités stables, volumineuses et régies par des règles relèvent généralement d’un moteur de workflow ou de règles classique, prévisible et facile à auditer. L’IA trouve sa place lorsque les entrées sont non structurées ou variables (classement de documents, extraction d’informations, rédaction d’une première réponse) et lorsqu’une part d’incertitude dans le résultat peut être maîtrisée. La priorisation doit croiser la valeur métier, la maturité du processus, l’état des données, le niveau de risque et l’effort de maintenance dans la durée, et pas uniquement la rapidité de mise en œuvre.
Il est souvent judicieux de simplifier un processus avant d’en automatiser la moindre étape. Supprimer des validations redondantes, éviter les doubles saisies ou clarifier un passage de relais entre équipes peut, à soi seul, apporter une bonne part du bénéfice attendu, tout en offrant une base plus saine aux automatisations suivantes. Tant que le processus évolue, mieux vaut une solution légère et réversible qu’un développement lourd qu’il faudra reprendre.
Organiser la supervision humaine dès la conception
Une automatisation responsable intègre la supervision dès sa conception, au lieu de l’ajouter après un incident. Il s’agit de définir les décisions que le système peut prendre seul, celles qui exigent une validation humaine, et la manière dont les exceptions sont orientées vers des personnes disposant de l’autorité et du contexte nécessaires. Il s’agit aussi de conserver une piste d’audit : ce que le système a fait, sur quelles données, avec quelle version de ses règles ou de son modèle. Le contrôle interne, la sécurité de l’information et, le cas échéant, les juristes et la conformité doivent être associés avant le déploiement, et non sollicités pour le valider après coup.
Une automatisation que l’on ne sait ni expliquer, ni surveiller, ni arrêter n’est pas un actif opérationnel : c’est un risque non maîtrisé.
Les questions à poser avant de financer un projet
- Qui est responsable de ce processus aujourd’hui, et le restera-t-il une fois automatisé ?
- Connaissons-nous le fonctionnement réel du processus, exceptions comprises, ou seulement sa version documentée ?
- Les données dont dépend la solution ont-elles un responsable, sont-elles fiables et peuvent-elles légitimement être utilisées à cette fin ?
- Quelles décisions restent humaines, et comment les équipes seront-elles alertées lorsque le système doute ou se trompe ?
- Comment suivrons-nous la performance, détecterons-nous les dérives et assurerons-nous la maintenance une fois l’équipe projet partie ?
- Quel est le mode dégradé si l’automatisation doit être suspendue ?
Les organisations qui prennent le temps de répondre à ces questions automatisent souvent moins au départ, mais elles automatisent mieux. Elles se dotent surtout de la gouvernance, de la rigueur sur les données et de la confiance nécessaires pour passer à l’échelle. Une base plus solide qu’un portefeuille de pilotes qui n’atteignent jamais tout à fait la production.