IA ou automatisation : là où le choix se paie

La différence tient en un mot, et il est moche : déterministe. Une automatisation l’est, la même entrée donnant toujours la même sortie. L’intelligence artificielle ne l’est pas, puisqu’elle produit à partir d’un contexte.

Cette distinction est partout, y compris sur ce site. Ce qu’on ne lit nulle part, c’est ce que le mauvais choix coûte quand il est fait. C’est le sujet ici, et il y a un prix au centime près pour l’illustrer.

Le prix d’un mauvais placement

Sur un catalogue que je tiens, un fournisseur a basculé une ligne de son tarif dans une autre tranche, le 28 mai 2026. Résultat : le prix public s’est retrouvé dans la colonne du prix net.

Aucune intelligence artificielle là-dedans. Un traitement déterministe, qui a fait exactement ce pour quoi il était écrit : prendre la valeur de la colonne et la reporter. Il l’a fait correctement. Il a reporté une valeur fausse. Les deux phrases sont vraies en même temps, et c’est tout le problème.

Vous pouvez relire la règle : elle ne parle jamais de justesse. Le déterminisme garantit la répétabilité, pas la justesse. Un traitement qui recopie fidèlement une erreur est un traitement qui marche. Il marche même parfaitement.

Ce qui aurait dû arrêter ce prix, ce n’est pas un test technique : la valeur était un nombre, elle rentrait dans le champ, tous les contrôles de format passaient. C’est une règle de métier. Un prix net supérieur au prix public n’existe pas. Un prix qui triple d’un import à l’autre mérite au minimum une alerte.

Ces règles-là ne s’écrivent qu’après avoir vu le cas. C’est pour ça que je découpe les chantiers en lots et que chaque lot ajoute des règles au suivant, ce que je raconte dans un catalogue livré par lots.

L’erreur symétrique, plus rare et plus grave

L’autre sens existe aussi : confier à un modèle un travail qui demandait une automatisation.

Ça arrive quand on découvre l’intelligence artificielle et qu’elle impressionne. Elle sait lire un tableau, alors on lui demande de recopier les lignes de ce tableau vers un logiciel de gestion. Elle le fait. Quatre-vingt-dix-neuf fois sur cent.

La centième, elle intervertit deux colonnes, ou elle arrondit, ou elle complète une case vide par ce qui lui semble cohérent. Personne ne le voit. Rien ne signale jamais une réponse plausible, c’est la définition d’une réponse plausible. Sur une facture, ça se termine devant votre client. Et si vous vous demandez ce que vaut le taux de réussite qu’on vous annoncera, la réponse est dans 99 % de bonnes réponses, ça fait combien d’erreurs.

Ma règle tient en deux phrases et je ne la négocie pas : reporter une valeur qui existe déjà est un travail déterministe. Interpréter un texte libre est un travail pour un modèle. Et rien de ce qui est irréversible, envoyer, facturer, supprimer, n’est décidé par une machine qui interprète.

Ce qui est vrai des deux

On m’oppose parfois que le code, lui, ne dérive pas. J’ai longtemps répondu ça aussi, et c’est faux.

Un outil en service dérive, simplement plus lentement, et pour des raisons extérieures à lui. Le fournisseur change son format. Une interface disparaît. Une règle fiscale décale une colonne. Le programme, lui, n’a pas bougé d’une ligne, et il produit désormais un résultat faux avec une régularité parfaite.

La différence avec un modèle n’est donc pas que l’un serait fiable et l’autre pas. C’est le délai avant qu’une erreur devienne visible, et la façon de la rattraper. C’est le sujet de la panne silencieuse.

Comment je tranche, en pratique

Trois questions devant chaque étape d’une chaîne, celles que reprend aussi le guide par où commencer avec l’IA en PME et que les questions résument.

L’information à produire existe-t-elle déjà quelque part sous une forme exacte. Si oui, on la transporte, on ne la régénère pas.

Le résultat doit-il être identique à chaque exécution. Si oui, aucun modèle dans cette étape.

Que se passe-t-il si cette étape se trompe et que personne ne le voit pendant un mois. Si la réponse fait mal, il faut un contrôle de vraisemblance. Et quelqu’un valide avant l’irréversible.

La plupart des chantiers que je livre mélangent les deux approches dans la même chaîne, et c’est normal : une commande arrive par courriel en texte libre, un modèle en extrait les lignes et les quantités, un traitement déterministe vérifie que chaque référence existe et que les montants se recoupent, puis quelqu’un valide avant que quoi que ce soit parte en production. Ce qui compte, c’est que la frontière soit posée à la conception et qu’elle soit écrite quelque part que vous puissiez relire. Posez la question à qui vous construira votre outil : sur quelles étapes une machine interprète, et sur lesquelles elle se contente de transporter. Si la réponse est floue, la frontière n’existe pas.