Automatiser avec ou sans IA : la question à poser avant de choisir l'outil

Depuis deux ans, les demandes qu’on reçoit commencent presque toutes par « on voudrait automatiser ça avec l’IA ». Dans la majorité des cas, après vingt minutes de cartographie, le processus n’a pas besoin d’IA. Il a besoin d’un flux de travail bien construit. Dans une minorité de cas, c’est l’inverse : on a essayé de l’automatiser avec des règles et ça n’a jamais tenu, parce que l’entrée ne se laisse pas réduire à des règles.

La différence entre les deux n’est pas une question d’outil. C’est une question de nature du processus, et elle se tranche avant de regarder un seul produit.

Deux familles, pas une

L’automatisation par règles est déterministe. La même entrée produit toujours la même sortie. Une facture arrive, le montant dépasse un seuil, elle part en approbation. On peut l’écrire, la tester, l’expliquer à un vérificateur. Elle ne coûte rien à l’exécution et elle ne se trompe jamais de la même façon deux fois : quand elle échoue, c’est que la règle était incomplète, et on la corrige.

L’automatisation par jugement est probabiliste. Un modèle interprète une entrée variable et produit une sortie plausible. Un courriel de client arrive, le modèle en extrait l’intention et les champs utiles. La même entrée peut produire deux sorties légèrement différentes. Ça coûte à chaque appel, ça se teste par échantillonnage plutôt que par cas, et ça se trompe de façon imprévisible.

	Règles	Jugement (IA)
Entrée	Structurée, forme fixe	Variable, langage naturel, documents
Sortie	Identique à chaque fois	Plausible, peut varier
Erreur	Prévisible, corrigeable une fois pour toutes	Imprévisible, à surveiller en continu
Test	Cas par cas, exhaustif	Par échantillon, jamais exhaustif
Coût	Fixe, quasi nul à l’exécution	Par appel, croît avec le volume
Quand une décision touche une personne	Explicable ligne par ligne	À documenter avec soin

La dernière ligne compte au Québec. Notre billet sur les recommandations de la CAI explique pourquoi une décision fondée sur un traitement automatisé entraîne des obligations, et pourquoi la Commission veut les étendre aux décisions partiellement automatisées. Une règle écrite se défend en une phrase. Un jugement de modèle se défend avec un dossier.

Trois questions pour trancher

1. Pouvez-vous écrire la règle ? Pas « on sait ce qu’il faut faire ». La règle, complète, avec ses exceptions, en une page. Si vous y arrivez, c’est une automatisation par règles, et y mettre un modèle de langage ajoute du coût, de la variabilité et de la documentation pour rien. Si vous n’y arrivez pas après une heure d’essai honnête, le processus repose sur du jugement.

2. L’entrée a-t-elle une forme fixe ? Un formulaire, un champ de base de données, un fichier au format connu : forme fixe, règles. Un courriel, un PDF numérisé, une conversation, une demande en texte libre : forme variable, et c’est précisément là que l’IA gagne sa place. Non pas parce qu’elle décide mieux, mais parce qu’elle transforme une entrée variable en entrée structurée.

3. Que coûte une mauvaise réponse ? Une suggestion de catégorie qu’un humain corrige en un clic : l’erreur est bon marché, le jugement est acceptable. Un rejet de dossier, un montant payé, une donnée envoyée au mauvais destinataire : l’erreur est chère, et la décision finale doit revenir à une règle ou à une personne, jamais au modèle seul.

Le montage qui fonctionne dans la plupart des cas

Les processus réels sont rarement purs. Le montage qui tient le mieux a trois étages :

L’IA en bordure, là où l’entrée est variable. Elle lit, classe, extrait. Elle transforme un courriel en cinq champs. Elle ne décide rien.

Les règles au centre. Une fois les cinq champs remplis, tout ce qui suit est déterministe : seuils, acheminements, validations, écritures dans les systèmes. C’est testable, et c’est cette partie qu’un vérificateur examinera.

Une personne au point de décision, là où l’erreur coûte cher. Pas partout, ce qui tuerait le gain. À l’endroit précis où la troisième question a répondu « cher ».

Ce montage règle aussi la question de conformité par construction : le modèle ne prend pas de décision concernant une personne, il prépare la décision. La ligne est nette et elle est documentée par l’architecture elle-même.

Les deux erreurs qu’on voit le plus

Un modèle de langage là où un if suffisait. Vérifier qu’un champ est rempli, extraire un numéro de commande d’un format connu, router selon un code de département. Ça marche, ça coûte à chaque appel, et le jour où ça se trompe, personne ne comprend pourquoi.

Des règles là où l’entrée est libre. Trois ans d’expressions régulières pour lire des courriels de clients, un classeur d’exceptions qui grossit chaque mois, et un employé qui corrige à la main ce que la règle rate. C’est le cas où l’IA en bordure fait disparaître le classeur d’exceptions.

Avant l’outil

Cartographiez le processus, posez les trois questions sur chaque étape, puis seulement regardez les outils. Notre billet sur le choix du premier processus donne la méthode de cartographie, et celui sur la mesure des gains permet de savoir si le montage a payé.

Pour dégrossir en deux minutes : notre outil de sélection pose les 7 questions qui comptent, sans rien collecter. Et si vous hésitez sur un processus précis, l’audit initial commence exactement par ces trois questions.