Automatiser un process métier avec l'IA

Beaucoup de process métier reposent encore sur des gestes que personne ne devrait faire à la main. Recopier un montant d'un PDF vers un tableur. Trier des e-mails entrants selon leur objet. Extraire trois lignes d'une facture pour les ranger ailleurs. Pris un par un, ces gestes durent quelques secondes. Multipliés par le volume d'une journée, ils mangent des heures et laissent passer des erreurs que personne ne voit avant le contrôle de fin de mois.

L'automatisation classique sait déjà traiter une grande partie de ces gestes, à une condition : que la donnée arrive toujours au même endroit, dans le même format. Une règle qui lit la troisième colonne d'un fichier marche tant que la colonne ne bouge pas. Le jour où le fournisseur change la mise en page de sa facture, où l'objet de l'e-mail varie d'un client à l'autre, où le document arrive en photo plutôt qu'en texte, la règle casse. C'est là que l'IA prend le relais : elle lit un contenu qui change de forme sans changer de sens, et continue de faire le tri quand une règle rigide aurait abandonné.

Ce que recouvre l'automatisation d'un process

Un process, c'est une suite d'étapes qui transforme une entrée en sortie. Une commande devient une ligne de stock. Un justificatif devient une écriture comptable. Un message entrant devient un ticket affecté à la bonne personne. Automatiser ce process, ce n'est pas le confier en bloc à une machine. C'est repérer les étapes mécaniques, celles où la décision suit toujours la même logique, et les faire exécuter sans intervention, en laissant le reste aux gens.

Quand l'IA entre dans cette chaîne, elle occupe en général un poste précis : comprendre une entrée pas tout à fait structurée. Lire un document scanné et en sortir les bons champs. Classer une demande dans la bonne catégorie quand l'objet est écrit en langage libre. Rapprocher deux références qui désignent la même chose sans être écrites pareil. Le reste de la chaîne, le calcul, l'enregistrement, le routage, reste du code ordinaire, prévisible et testable. L'IA traite l'ambiguïté du début ; la mécanique fiable s'occupe de la suite.

Où ça sert vraiment

Le bon candidat, c'est une tâche à la fois répétitive et tolérante. Répétitive parce qu'elle revient assez souvent pour que le temps gagné compte. Tolérante parce qu'une erreur de temps en temps se rattrape sans casse, par un contrôle en aval ou par une reprise humaine. Le traitement de documents entrants coche souvent ces deux cases : il y en a beaucoup, leur forme varie, et une pièce mal lue se corrige avant l'étape suivante.

Les saisies répétées sont un autre terrain franc. Quand une même information voyage d'un outil à l'autre par copier-coller, chaque recopie est une occasion de se tromper et une minute perdue. Faire lire la source par un modèle, puis écrire la cible par du code, supprime le geste sans supprimer le contrôle : on garde une trace de ce qui a été lu et de ce qui a été écrit, et on peut rejouer le parcours quand un chiffre cloche.

Le tri et l'extraction ferment la liste des usages qui tiennent. Orienter une demande vers le bon service, sortir d'un contrat la date d'échéance et le montant, repérer parmi des centaines de pièces celles qui manquent. Autant de gestes où la valeur n'est pas dans la difficulté de chaque cas, mais dans le volume et la régularité.

Comment on s'y prend

On commence par cartographier le geste réel

Avant de coder quoi que ce soit, on regarde comment la tâche se fait aujourd'hui, avec la personne qui la fait. D'où vient la pièce, ce qu'elle contient quand elle est bien remplie et quand elle l'est mal, ce qui déclenche un doute, ce qui justifie une exception. Cette cartographie sépare le mécanique, qui peut partir en automatique, du jugement, qui doit rester humain. Sauter cette étape, c'est automatiser un process qu'on a mal compris, et reproduire ses défauts plus vite.

On découpe au lieu de tout confier au modèle

On réserve l'IA à ce qu'elle fait mieux que le code : interpréter une entrée floue. Tout ce qui peut s'écrire en règle stable reste en règle stable, parce que c'est moins cher, plus rapide et plus facile à vérifier. Un modèle qui lit une facture rend un résultat ; un bout de code contrôle ensuite que le total colle, que la date existe, que le fournisseur est connu. Si un champ manque ou paraît douteux, la pièce part vers un humain au lieu de filer en aval avec une valeur inventée.

On mesure sur les cas réels avant de basculer

Un traitement automatique ne se juge pas sur trois exemples choisis. On le fait tourner sur un lot représentatif, on compare sa sortie à ce qu'aurait produit la main, et on regarde le taux d'erreur que cela laisse. Tant que ce taux dépasse ce que le contrôle en aval peut absorber, on garde l'humain dans la boucle et on resserre. La bascule vers le tout-automatique se mérite, elle ne se décrète pas au lancement.

Les limites, posées d'avance

Un modèle se trompe, et il peut se tromper avec assurance. Sur un process automatisé, l'enjeu n'est pas d'éliminer l'erreur, c'est de la voir et de la rattraper avant qu'elle coûte. D'où les contrôles en sortie, la trace de chaque lecture, et la règle simple qu'un cas incertain remonte à une personne plutôt que de passer en silence. On borne aussi ce que l'automatisme décide seul : il extrait et propose, et un paiement ou la suppression d'une donnée attend une main humaine sur le bouton.

Toutes les tâches ne valent pas ce travail. Une opération rare, ou qui change de logique à chaque fois, demande plus d'effort à automatiser qu'elle n'en fait gagner. Et quand une règle figée suffit déjà, l'IA n'a rien à faire là : elle coûterait plus et tomberait en panne plus souvent pour le même résultat. Notre métier, sur un cas comme celui-ci, commence par dire honnêtement si le jeu en vaut la chandelle. Quand la réponse est non, le dire fait partie du travail.