Comment savoir si un processus est automatisable : 8 critères pour l’évaluer

« Celui-là, on devrait pouvoir l’automatiser. » La phrase revient dans toutes les réunions, et elle est rarement fausse : techniquement, presque tout est automatisable. La vraie question n’est pas de savoir si c’est possible, mais si cela vaut la peine, et si l’automate tiendra dans le temps. C’est là que se jouent la plupart des échecs.

Un projet d’automatisation échoue rarement le jour de sa mise en production. Le plus souvent, il se dégrade progressivement : l’application évolue, les exceptions s’accumulent, plus personne ne maintient les scripts, et six mois plus tard l’équipe revient au traitement manuel.

Dans ce cas, le problème ne vient pas nécessairement de la technologie : le processus, le périmètre ou la gouvernance étaient insuffisamment préparés.

Pourquoi le choix du processus compte plus que l’outil

Le marché regorge de plateformes RPA, d’orchestrateurs et de solutions no-code très convaincantes en démonstration. Elles fonctionnent. Mais aucune ne compense un mauvais choix de périmètre.
Bien choisir le processus à automatiser, c’est :

• Un ROI atteint en mois, pas en années : les gains se matérialisent sur des volumes réels
• Un automate qui vieillit bien : moins de reprises, moins de maintenance imprévue
• Des équipes convaincues : un premier cas réussi ouvre la porte aux suivants
• Un risque maîtrisé : pas de robot incontrôlé sur des données sensibles

À l’inverse, un premier cas mal choisi coûte deux fois : il consomme un budget et dégrade la confiance dans la démarche. Dans beaucoup d’organisations, un projet d’automatisation raté gèle le sujet pour deux ans.

Les 3 dimensions à analyser avant d’automatiser

Dans la pratique, le processus candidat est rarement choisi sur des critères explicites. Il est choisi parce qu’il est visible, parce qu’une équipe s’en plaint, ou parce qu’un sponsor y tient. Ce sont de mauvais indicateurs : le processus le plus pénible n’est pas toujours le plus automatisable, et le plus automatisable n’est pas toujours le plus rentable.
Pour trancher, il faut regarder trois dimensions distinctes, qui ne se compensent pas :

• La faisabilité : l’automate peut-il être construit, et surtout maintenu ?
• La rentabilité : le gain justifie-t-il l’investissement et le coût de maintenance ?
• La gouvernance et le risque : l’organisation est-elle prête à confier cette tâche à une machine ?

Un processus faisable mais non rentable produit un automate coûteux. Un processus rentable mais non faisable produit un chantier sans fin. Voici, dans chacun de ces trois axes, les critères qui font réellement la différence.

Faisabilité

1. Le niveau de règles métier : le processus est-il déterministe ?

C’est le critère numéro un, et de loin. Un processus automatisable est un processus où la même entrée produit toujours la même sortie. Dès qu’un humain doit arbitrer, interpréter un cas particulier ou « voir au cas par cas », l’automate se heurte à une frontière.

Attention au piège classique, un processus décrit comme simple, cache souvent une longue liste d’exceptions que les opérateurs traitent par habitude, sans même les considérer comme des exceptions. Ce sont elles qui feront exploser la charge de développement.

Conseil pratique : demandez à l’opérateur de dérouler le processus sur dix cas réels tirés au hasard. Comptez combien de fois il dit « sauf si ». Au-delà de deux ou trois, le périmètre doit être réduit avant d’être automatisé.

2. La stabilité de l’application cible

Un automate est un client fidèle mais rigide : il reproduit exactement ce qu’on lui a appris. Si l’application sous-jacente change tous les mois, chaque évolution devient une reprise de développement. Le coût de maintenance finit par dépasser le gain.

Interrogez la roadmap avant de vous engager :

• L’application est-elle en fin de vie, en refonte ou en migration prévue ?
• À quelle fréquence les écrans, les champs ou les règles évoluent-ils ?
• Existe-t-il un canal d’information entre l’éditeur ou l’équipe applicative et vous ?

Un processus stable sur une application stable est un candidat idéal. Un processus stable sur une application en pleine refonte doit attendre.

3. La nature des interfaces : API ou écran ?

Toutes les automatisations ne se valent pas techniquement. Quand l’application expose des API ou des services, l’automate s’appuie sur un contrat stable et documenté. Quand il faut passer par l’interface graphique : simulation de clics, lecture d’écran, scraping, chaque évolution cosmétique peut casser le robot.

L’écart de robustesse entre les deux approches est considérable, et il ne se voit pas dans le chiffrage initial. Il se voit au bout d’un an, dans le budget de maintenance.

Le nombre d’applications impliquées compte tout autant. Un processus qui traverse quatre systèmes, dont deux appartiennent à des tiers, multiplie les points de rupture : authentification, indisponibilité, changement de version non annoncé. Chaque frontière franchie est un risque supplémentaire.

4. La qualité des environnements, des données et de la documentation

Ce sont les critères que l’on découvre trop tard, une fois le projet lancé. Ils ne bloquent jamais une automatisation à eux seuls, mais ils allongent systématiquement les délais.

• Environnements : disposez-vous d’un environnement de recette stable et disponible, ou l’automate devra-t-il être mis au point directement en production ?
• Jeux de données : les données sont-elles structurées, cohérentes, représentatives ? Un automate ne devine pas ce qu’un humain corrige instinctivement
• Documentation : le processus est-il formalisé, ou existe-t-il uniquement dans la tête de la personne qui l’exécute depuis huit ans ?

Un processus non documenté n’est pas non automatisable. Mais il faut prévoir la phase de formalisation dans le chiffrage, elle prend souvent plus de temps que le développement lui-même.

Rentabilité

5. La fréquence et le volume : le vrai moteur du ROI

Un automate a un coût fixe de construction et un coût de fonctionnement quasi nul. Sa rentabilité est donc directement proportionnelle au nombre de fois où il tourne. C’est une évidence arithmétique, et pourtant c’est le critère le plus souvent sous-estimé.

Deux dimensions se cumulent :

• La fréquence d’exécution : quotidienne, hebdomadaire, mensuelle, ponctuelle ?
• Le volume traité par exécution : dix lignes ou dix mille ?

Une exécution quotidienne sur 10 000 enregistrements n’a rien à voir avec une exécution trimestrielle sur 50. Le premier cas se rentabilise en quelques semaines, le second probablement jamais. Un processus rare reste un excellent candidat à la simplification ou à l’outillage léger et non à l’automatisation complète.

6. Le coût réel de l’exécution manuelle

Le calcul ne doit pas se limiter à « temps passé × coût horaire × fréquence ». Il faut aussi intégrer les coûts indirects :

• Le temps de reprise après interruption, quand la tâche est fractionnée dans la journée
• Les délais d’attente induits pour les autres équipes ou pour le client final
• Le coût d’opportunité : ce que les collaborateurs feraient de plus utile de ce temps
• La dépendance à une personne unique, et le risque associé à son absence

Une tâche d’une heure par jour réalisée par un expert mobilise non seulement une heure de travail, mais aussi une capacité rare qui pourrait être consacrée à l’analyse, au contrôle ou à l’amélioration continue.

7. Le taux d’erreur actuel : le critère caché

C’est l’argument le plus fort et le moins utilisé. Si le processus manuel génère régulièrement des erreurs : saisies incorrectes, oublis, incohérences détectées en aval, l’automatisation n’apporte pas seulement du temps : elle apporte de la fiabilité.

Et dans beaucoup de contextes, le coût d’une erreur dépasse largement le coût du temps passé : reprise en aval, réclamation client, écart comptable, incident de production.

Quand un processus cumule un volume élevé et un taux d’erreur significatif, le dossier se défend tout seul.

À l’inverse, un processus manuel exécuté sans erreur depuis des années sur un faible volume n’a pas de problème de qualité à résoudre. Il a, au mieux, un problème de confort.

Gouvernance & risque

8. La sensibilité des données et maturité organisationnelle

Dernier axe, souvent traité en dernier alors qu’il devrait être posé dès le cadrage : l’organisation est-elle prête à laisser une machine exécuter cette tâche ?

La question est d’abord réglementaire : données personnelles, financières, de santé ou soumises à un cadre sectoriel. Plus les données sont sensibles, plus le niveau de contrôle attendu sur l’automate est élevé : traçabilité des exécutions, gestion des habilitations, journalisation, capacité à rejouer ou à justifier une opération.

Elle est ensuite organisationnelle. Qui sera responsable de l’automate une fois le projet terminé ? Qui le surveille, qui l’arrête, qui le corrige ? Un automate sans propriétaire identifié est un automate qui dérivera silencieusement. La gouvernance ne rend pas un processus automatisable ou non, elle détermine le niveau d’exigence à intégrer dès la conception.

Exemples de processus à examiner en priorité

Les meilleurs candidats sont souvent des processus répétitifs, standardisés et contrôlables. Par exemple :

• RH (SIRH) : non-régression des processus clés après chaque mise à jour de l’éditeur (embauche, mutation, sortie), vérification des flux vers la paie et l’annuaire, contrôle des règles de sécurité (qui voit quelles données selon son périmètre).

• Finance (ERP) : test de bout en bout du cycle achat (commande, réception, facture, paiement), vérification des workflows d’approbation selon les seuils de montant, contrôle des écritures générées automatiquement.

• IT / transverse : tests des interfaces entre applications, vérification des habilitations et du SSO, collecte automatique des preuves d’exécution pour l’audit.

Ces exemples doivent toujours être évalués dans leur contexte : volumétrie, stabilité applicative, exceptions, sensibilité des données et coût de maintenance.

En résumé

Ces critères n’ont pas tous le même poids. La stabilité de l’application, le niveau de règles métier, la nature des interfaces, la fréquence et le volume sont structurants : un score faible sur l’un d’eux suffit à disqualifier un candidat, même si tout le reste est au vert.

La documentation ou la complexité technologique, elles, allongent les délais sans remettre en cause le principe. Une grille d’évaluation utile est donc une grille pondérée.

Par où commencer ?

N’automatisez pas votre processus le plus complexe en premier, même si c’est celui qui fait le plus mal. Commencez par celui qui coche le plus de critères : un processus stable, répétitif, à forte volumétrie et à faible enjeu réglementaire. Un premier succès rapide construit la crédibilité nécessaire pour attaquer les cas difficiles ensuite.

Et surtout, objectivez la décision. Une grille partagée entre la DSI, le métier et la direction évite les arbitrages au ressenti et rend la discussion possible : quand un processus est écarté, chacun voit sur quel critère il a échoué.

C’est exactement ce que nous avons cherché à outiller chez SQORUS. À force de mener ces cadrages chez nos clients, nous avons formalisé notre grille d’évaluation dans un outil en ligne : quatorze critères répartis sur les trois axes : faisabilité, rentabilité, gouvernance, pondérés selon leur importance réelle, avec un score par axe et un verdict argumenté. Le tout exportable en PDF ou en CSV pour alimenter votre comité de décision.

Évaluez le potentiel d’automatisation de votre processus en quelques minutes : accédez à l’outil d’évaluation SQORUS.

FAQ – Évaluer le potentiel d’automatisation d’un processus