Sélection des processus RPA : catalogue de critères pour les processus automatisables

Tout processus qui semble répétitif ne convient pas automatiquement à l'automatisation robotisée des processus (RPA). Avant d'investir du temps dans l'enregistrement et la construction d'un flux de bureau, il vaut la peine de jeter un regard objectif sur le processus lui-même : est-il basé sur des règles, quelle est la stabilité de l'interface avec laquelle il travaille, et à quelle fréquence est-il réellement exécuté ? Dans sa documentation officielle sur Power Automate, Microsoft distingue volontairement deux types d'automatisation, l'automatisation numérique des processus basée sur API et l'automatisation robotisée des processus basée sur l'interface utilisateur, et cette distinction est précisément le premier filtre de tout catalogue de critères pour la sélection des processus.

Cet article vous montre selon quels critères évaluer les processus pour la RPA, quand il vaut mieux miser sur des flux cloud basés sur des API, et comment le process mining et le task mining vous aident à trouver des candidats de manière systématique plutôt qu'à l'instinct.

RPA ou plutôt automatisation via API ?

La première étape de toute sélection de processus n'est pas du tout une question de RPA, mais une question d'architecture. Selon la documentation Microsoft sur les types d'automatisation, vous devriez privilégier l'automatisation numérique des processus via des flux cloud pour toute application disposant d'un connecteur prêt à l'emploi ou d'une API ouverte. Selon Microsoft, les API restent généralement stables même lors des évolutions de l'application, car les éditeurs de logiciels veillent activement à ne pas casser les interfaces existantes.

La RPA n'entre en jeu que lorsque cela manque précisément : une application legacy, un ancien logiciel Windows ou un portail web sans API documentée. Avec la RPA, vous apprenez à Power Automate à imiter les clics de souris et les saisies au clavier comme le ferait un humain. L'inconvénient est explicitement mentionné dans la même documentation : la RPA est sujette à se casser lors de changements de mise en page de l'interface ou de mises à jour de l'ordinateur local, et les instructions données au bot doivent être très précises, par exemple s'il s'agit vraiment toujours de la cellule B3 ou de la première cellule vide de la colonne B. C'est pourquoi un catalogue de critères pour la RPA ne se demande pas seulement si un processus est automatisable, mais aussi si la RPA est réellement le bon type d'automatisation pour ce processus.

Le catalogue de critères : sept caractéristiques d'un bon candidat RPA

Un processus se prête d'autant mieux à la RPA que plusieurs des points suivants s'appliquent. Si plusieurs d'entre eux manquent simultanément, soit une modification du processus est nécessaire avant l'automatisation, soit une autre voie d'automatisation est plus judicieuse.

• Basé sur des règles, sans marge d'appréciation : le processus suit des logiques fixes si-alors plutôt que des décisions au cas par cas. Dès qu'un gestionnaire décide sur la base de son expérience ou de son instinct, le processus ne convient pas à la RPA classique, à moins que vous ne le complétiez par des étapes intermédiaires assistées par l'IA.
• Volume élevé et répétition régulière : un processus effectué manuellement en cinq minutes dix fois par an justifie rarement l'effort d'enregistrement, de test et de maintenance d'un bot. Les processus avec des exécutions quotidiennes ou hebdomadaires s'amortissent nettement plus vite.
• Données d'entrée numériques et structurées : les formulaires, tableaux, e-mails à format fixe ou champs de base de données peuvent être lus de manière fiable. Les notes manuscrites, le texte libre sans structure ou les appels téléphoniques sont un mauvais point de départ pour la RPA pure.
• Interface applicative stable : comme la RPA, selon Microsoft, travaille directement avec l'interface écran, vous avez besoin d'applications dont la mise en page change rarement. Les applications web fréquemment mises à jour, avec des positions d'éléments changeantes, augmentent considérablement le risque de maintenance.
• Point de départ et d'arrivée clairement définis : un bon candidat commence par un déclencheur clair, par exemple un e-mail entrant ou un nouvel enregistrement, et se termine par un résultat vérifiable. Les processus qui s'étalent sur plusieurs jours ou qui attendent des retours externes peuvent certes être automatisés, mais nécessitent une modélisation de processus plus soignée.
• Faible taux d'exceptions : si le processus se déroule exactement de la même manière dans plus de 80 à 90 % des cas, l'automatisation du chemin standard en vaut la peine, tandis que les exceptions rares continuent d'être traitées manuellement ou escaladées vers une personne.
• Bénéfice mesurable : les gains de temps, la réduction des erreurs ou l'accélération du délai de traitement devraient pouvoir être chiffrés approximativement à l'avance. Sans bénéfice quantifiable, il manque la base pour justifier l'effort de construction et d'exploitation.

Attended ou unattended : le processus détermine le mode de fonctionnement

Même si un processus est fondamentalement adapté à la RPA, le mode de fonctionnement approprié varie considérablement. Avec le attended RPA, le bot travaille directement avec une personne qui démarre l'exécution et reste devant l'écran, par exemple pour des tâches de service client où un collaborateur vérifie la dernière étape. Avec le unattended RPA, le processus s'exécute entièrement en arrière-plan sans supervision humaine.

Pour les candidats unattended, selon la documentation Microsoft sur les flux de bureau non surveillés, des exigences techniques supplémentaires s'appliquent, qu'il convient déjà de prendre en compte lors de la sélection des processus :

• L'ordinateur cible doit être entièrement déconnecté et disponible ; sous Windows 10 et 11, une session active verrouillée empêche déjà l'exécution non surveillée.
• La résolution d'écran de la session à distance peut différer de la résolution avec laquelle le flux a été initialement enregistré, ce qui peut provoquer des erreurs au niveau des éléments d'interface si elle n'est pas fixée au préalable.
• Les exécutions non surveillées ne peuvent pas être lancées avec des droits élevés, ce qui peut constituer un critère d'exclusion pour les processus nécessitant des droits d'administration.

Les processus qui doivent s'exécuter la nuit, le week-end ou à une cadence élevée, par exemple l'importation de factures ou le rapprochement de données de référence, sont des candidats unattended classiques. Les processus comportant des étapes de validation ou un contrôle ponctuel restent plutôt du ressort de la RPA attended ou d'une forme hybride combinant flux cloud et étape d'approbation.

Trouver des candidats systématiquement plutôt qu'au hasard

Plutôt que de sélectionner les processus à l'instinct, Power Automate propose deux outils, le process mining et le task mining, qui identifient les candidats sur une base de données. Selon la présentation Microsoft du process mining et du task mining, le process mining est mieux adapté pour rendre visibles les inefficacités dans des flux à l'échelle de l'entreprise, comme la comptabilité clients ou l'order-to-cash, via des journaux d'événements. Le task mining, en revanche, se concentre sur des activités de bureau individuelles en analysant les actions utilisateur enregistrées et en montrant quelles applications accaparent le plus de temps.

Les deux fonctions signalent les candidats à l'automatisation directement dans la carte des processus. Selon la documentation sur les recommandations d'automatisation, des icônes de recommandation bleues sur les activités de la carte des processus indiquent où une automatisation est envisageable. Via l'option Automatiser les activités, vous accédez directement au concepteur de formulaires Power Automate, qui propose des suggestions de connecteurs adaptés aux activités signalées. Vous voyez ainsi en un coup d'œil si une activité est mieux résolue via un connecteur standard sous forme de flux cloud ou réellement via la RPA.

Checklist pratique : cinq étapes vers un candidat solide

1. Délimiter clairement le processus : définissez le début, la fin et toutes les variantes avant même de parler d'automatisation.

2. Vérifier l'option API : si un connecteur ou une API ouverte existe pour les applications concernées, l'automatisation par flux cloud est presque toujours le choix le plus robuste.

3. Appliquer le catalogue de critères : vérifiez le caractère basé sur des règles, le volume, la structure des données, la stabilité de l'interface, le taux d'exceptions et le bénéfice à l'aide des sept caractéristiques ci-dessus.

4. Définir le mode de fonctionnement : décidez, en fonction du besoin de supervision et de la cadence, si la RPA attended ou unattended convient.

5. Valider avec des données : utilisez le process mining ou le task mining pour confronter votre évaluation à des données d'exécution réelles plutôt qu'à des suppositions.

Quiconque suit ces cinq étapes de manière cohérente évite la cause la plus fréquente d'échec des projets RPA : un bot construit sur un processus instable ou trop peu fréquent, qui génère au bout de quelques semaines déjà plus d'efforts de maintenance qu'il n'en économise. Si vous n'êtes pas sûr de savoir lesquels de vos processus sont réellement mûrs pour l'automatisation, un inventaire structuré aide souvent davantage que la tentative de s'attaquer d'emblée au plus gros processus. Avec le conseil Power Automate de NordFlux, nous parcourons avec vous précisément ce catalogue de critères à travers votre paysage de processus, afin que vos collaborateurs numériques soient déployés là où ils ont réellement un impact, tout en vous laissant à tout moment le contrôle de la sélection et de l'exploitation.

Questions fréquentes

Quel est le critère le plus important dans la sélection des processus RPA ?

Il n'existe pas un seul critère le plus important, mais le caractère basé sur des règles pèse le plus lourd : dès qu'un processus exige des décisions discrétionnaires situationnelles, la RPA classique atteint ses limites, indépendamment du volume ou du bénéfice par ailleurs. Vérifiez donc d'abord si le processus se déroule vraiment selon des règles fixes avant d'évaluer les autres critères.

Quand devrais-je automatiser un processus via des flux cloud plutôt que via la RPA ?

Chaque fois qu'un connecteur ou une API ouverte existe pour les applications concernées. Selon Microsoft, les API sont nettement plus stables que les interfaces utilisateur, car les éditeurs évitent activement de casser les interfaces existantes, alors que les mises en page à l'écran changent souvent lors des mises à jour, rendant les flux RPA plus sujets aux pannes.

Comment trouver des candidats RPA sans évaluer chaque processus individuellement ?

Le process mining et le task mining dans Power Automate analysent automatiquement les journaux d'événements et les actions utilisateur enregistrées, et signalent les possibilités d'automatisation directement dans la carte des processus. Cela remplace l'examen manuel individuel par une priorisation basée sur les données, tout en montrant si un connecteur ou un flux de bureau est la solution la plus adaptée.

Qu'est-ce qui distingue la RPA attended de la RPA unattended dans la sélection des processus ?

La RPA attended convient aux processus où une personne participe activement à l'écran et démarre délibérément le bot, par exemple en contact direct avec le client. La RPA unattended convient aux processus sans besoin de supervision, censés s'exécuter en arrière-plan, mais nécessite pour cela un ordinateur cible entièrement déconnecté et une résolution d'écran fixe, afin que la reconnaissance de l'interface fonctionne de manière fiable.

Un processus avec de nombreuses exceptions peut-il quand même être automatisé ?

Partiellement. Si la majorité des cas suit le même schéma et que seule une petite part diverge, vous automatisez le chemin standard et acheminez les exceptions vers une personne via une escalade. Si, en revanche, le taux d'exceptions atteint 30 % ou plus, il vaut généralement la peine de simplifier ou de mieux réglementer le processus avant de l'automatiser.