RPA ou IA : deux réponses à deux problèmes différents
L'automatisation classique traite les règles, l'IA traite l'ambiguïté. Comment savoir laquelle vous faut, et pourquoi la première suffit souvent.
Écrit par les consultants de Lick & Shannon Partners. Nous ne vendons aucune des deux technologies, ce qui rend la comparaison plus simple à écrire honnêtement.
Ce que chacune sait faire
L'automatisation classique — souvent appelée RPA — exécute des règles écrites à l'avance. Elle est déterministe : à entrée identique, sortie identique, toujours. Elle est auditable, prévisible, peu coûteuse à exploiter, et elle échoue franchement quand l'entrée sort du cadre prévu.
L'IA interprète. Elle traite des entrées qu'on n'a pas anticipées, des formulations qui varient, des documents dont la mise en page change. Elle est probabiliste : elle a raison la plupart du temps, et elle ne prévient pas quand elle a tort.
Cette dernière propriété commande tout le reste. Une automatisation classique qui plante s'arrête ; une IA qui se trompe continue.
Le test qui tranche en une question
Une seule question suffit dans la grande majorité des cas : pouvez-vous écrire la règle ?
Si vous pouvez formuler « quand ceci, alors cela », y compris avec vingt conditions imbriquées, c'est de l'automatisation classique. C'est moins cher, plus fiable, et vous saurez toujours expliquer pourquoi le système a fait ce qu'il a fait — ce qui compte le jour d'un contrôle ou d'un litige.
Si la règle dépend d'une interprétation — comprendre l'intention d'un message, lire un document dont la structure change à chaque fournisseur, classer une demande formulée en langage libre — alors l'IA a sa place.
Le test se fait en séance, sur un tableau, en une demi-heure. Il évite l'essentiel des surinvestissements que nous rencontrons.
Pourquoi l'automatisation classique est souvent suffisante
Dans les entreprises où nous intervenons, une large part des besoins exprimés comme « il nous faudrait de l'IA » se traitent par des règles. Trois raisons à cet écart :
- Le processus n'avait jamais été décrit. Une fois écrit, on découvre qu'il suit des règles — elles n'étaient simplement formalisées nulle part.
- L'ambiguïté était en amont. Ce n'est pas la tâche qui est ambiguë, c'est la donnée qui arrive mal structurée. Corriger la source coûte moins cher que d'interpréter en aval, indéfiniment.
- Le vocabulaire du moment. « IA » sert aujourd'hui à désigner toute automatisation, y compris quand il s'agit d'un tableur bien conçu.
Ce n'est pas un argument contre l'IA. C'est un argument pour mesurer avant de choisir : une automatisation classique déployée en trois semaines libère le budget pour un vrai cas d'IA ensuite.
Les cas où il faut les deux
Les architectures les plus solides que nous voyons combinent les deux, avec une répartition nette des rôles.
L'IA à l'entrée, les règles ensuite. L'IA lit un document et en extrait des données structurées ; à partir de là, tout est déterministe. On concentre l'incertitude sur une seule étape, contrôlable, au lieu de la laisser se diffuser dans tout le processus.
Exemple typique : une facture fournisseur est lue par un modèle qui en sort le fournisseur, le montant et l'échéance. Ces trois valeurs passent ensuite par des règles — contrôle de cohérence, imputation, seuil de validation. Le point de contrôle est unique et facile à mesurer : le taux d'extraction correcte.
Cette organisation a un autre mérite : le jour où un meilleur modèle apparaît, on remplace l'étape d'entrée sans toucher au reste.
Ce test tranche la plupart des cas en une demi-heure. Il ne dit pas si votre processus est prêt à être automatisé, ni si l'ambiguïté que vous constatez ne viendrait pas d'une donnée mal structurée en amont — ce qui change complètement la réponse.
Faire chiffrer le gain sur un processus
Un processus, son coût actuel, son coût après automatisation. Sans engagement d'outil.
Pour aller plus loin