Toutes les tâches répétitives ne méritent pas d'être automatisées, et toutes celles qui le méritent n'ont pas besoin d'intelligence artificielle. Avant de parler technique, il faut d'abord vérifier que la tâche coche les bonnes cases.
Repérer la bonne tâche
- Elle est répétitive et suit un schéma reconnaissable : rapprocher des factures avec des bons de commande, extraire les champs d'un formulaire scanné, regrouper des retours clients par thème.
- Le volume justifie le développement : automatiser une tâche faite deux fois par an coûte plus cher que de la faire à la main.
- L'erreur est tolérable ou vérifiable : un système qui se trompe une fois sur cent doit avoir un moyen de rattraper cette fois-là, pas juste espérer qu'elle n'arrive pas.
Ce qu'il y a réellement sous le capot
Souvent, le schéma est le même. D'abord une entrée : un e-mail, un document, un formulaire. Puis une étape de compréhension ou de classification, confiée en général à un modèle de langage plutôt qu'à un algorithme écrit à la main, parce qu'il gère mieux la variabilité du langage naturel. Vient ensuite une règle métier qui décide de l'action à mener, et enfin l'action elle-même : écrire en base de données, envoyer une notification, remplir un champ. L'intelligence artificielle n'intervient en général que sur l'étape de compréhension ; le reste est de la logique classique, plus simple et plus prévisible.
Le piège : automatiser sans filet
La partie la plus négligée d'un projet d'automatisation n'est pas le modèle, c'est ce qui se passe quand il se trompe. Un système bien construit prévoit systématiquement :
- Une journalisation des décisions, pour pouvoir reconstituer ce qui s'est passé quand quelque chose cloche.
- Un signal de confiance faible plutôt qu'une réponse devinée : le système doit savoir dire qu'il ne sait pas.
- Un point de contrôle humain pour les cas ambigus, plutôt qu'une décision automatique appliquée à l'aveugle.
Une automatisation sans ce filet n'est pas plus fiable qu'un processus manuel : elle est juste plus rapide à se tromper, et souvent plus difficile à corriger après coup.
La question qui doit toujours précéder le choix de l'outil reste la même : qu'est-ce qui, concrètement, prend du temps aujourd'hui et pourrait être fait automatiquement sans perdre en fiabilité ? Le reste — modèle, framework, architecture — se décide après.