Le cas normal est la partie facile
Toute démonstration montre le cas normal. Le travail est dans l'exception — et en logistique, l'exception est le quotidien.
La RPA est dépassée
Et c'est une bonne nouvelle. Ce qui exigeait pendant des années un modèle par expéditeur, un modèle le lit aujourd'hui sans modèle — la limite passe de « structuré » à « lisible ».
La RPA était la réponse à une interface manquante. Qui s'y met aujourd'hui construit de la maintenance pour un problème résolu.
Le vrai saut : autrefois, chaque forme d'expéditeur exigeait son propre modèle. Aujourd'hui, un courriel de commande est lu sans que personne en connaisse le format. Cela déplace la limite de « structuré » à « lisible ».
Ce qu'était la RPA
Un script pilote des écrans de saisie, clic après clic. Pendant des années, le seul chemin vers des systèmes sans interface.
Pourquoi cela bascule
Cela casse au prochain changement de champ, et en silence. Et cela ne sait faire que ce que quelqu'un a prescrit pas à pas.
Tient encore
Ancien système sans interface, remplacement en vue, processus inchangé. Un pont n'a pas besoin d'être beau.
Ne tient plus
Tout ce qui exige de comprendre. Cela n'a jamais été la force de la RPA.
N'a jamais été juste
Piloter l'écran alors qu'il existe une interface.
Un client envoie sa commande par courriel — tantôt un tableau, tantôt trois lignes de texte libre.
Exemple pratique : le courriel de commande sans structure fixe
Tantôt un tableau, tantôt du texte libre, tantôt trois lignes avec « comme la semaine dernière ». Le cas montre pourquoi « quatre-vingts pour cent reconnus » et « quatre-vingts pour cent traités » sont deux affirmations différentes.
Trois sorties
Sûr → automatique. Incertain → brouillon, une personne confirme. Incertain → file d'exceptions avec le texte d'origine.
Où se trouve le bénéfice
Pas dans la minute économisée. Une commande à 22 h 01 dans le système est affrétable le lendemain matin — le gain est dans la nuit.
« 80 pour cent automatisés » n'est pas une réussite tant qu'il n'est pas dit qui s'occupe des 20 autres.
Un avoir client arrive. L'IA le lit et affecte les postes.
Et pourquoi les projets échouent quand même
Presque jamais sur l'idée, presque jamais sur la technique. L'erreur la plus chère est rarement le mauvais outil, mais le mauvais moment — et celui-ci se décide avant que quoi que ce soit soit acheté.
Qui ne décide pas de l'ordre se le fait livrer par celui qui demande le plus fort.
Données de base : des interlocuteurs périmés et des entreprises sous trois orthographes rendent toute automatisation inutilisable. Ce qui agit, ce n'est pas le nettoyage unique, mais le contrôle dans le processus.
L'ordre
L'erreur la plus chère est rarement le mauvais outil, mais le mauvais moment : un système d'affrètement avant le nettoyage des données, un portail avant le processus derrière.
Le processus non écrit
Ce qui est un processus en démonstration, ce sont en exploitation trois variantes que trois personnes traitent différemment. La machine en reproduit une.
Un système d'affrètement est mis en place. Le choix avait été soigneux.
Où se trouve aujourd'hui la meilleure solution
Ce qui est nommé, c'est le modèle, pas le fournisseur — un nom de produit vieillit, une idée non.
L'exception comme produit à part entière
File d'attente propre, indicateur propre, un nom à côté. C'est seulement ainsi qu'on voit si l'automatisation agit ou ne fait que déplacer la pile.
L'interface avant la reconstitution
Avant que quelque chose pilote un écran : existe-t-il une interface, et pourquoi ne l'utilisons-nous pas ? La question est plus vieille que l'IA et celle-ci n'y répond pas.
Le taux de passage comme mesure
Pas le nombre d'étapes automatisées, mais la part qui passe sans intervention humaine. Tout le reste peut s'embellir dans le calcul.