IA générative ou règles déterministes : quand utiliser un LLM
Un LLM sait lire, résumer et rédiger là où une règle échoue. Une règle garantit un résultat identique à chaque exécution, ce qu'aucun LLM ne promet. La vraie question n'est pas de choisir un camp, mais de savoir quelle partie d'un traitement confier à l'un et à l'autre.
Publié le 22 septembre 2026
Deux outils qui ne résolvent pas le même problème
Une règle déterministe, c'est du code ou un moteur de règles : pour une même entrée, elle produit toujours la même sortie. On peut la tester de façon exhaustive, l'auditer ligne par ligne et expliquer chaque décision. Sa limite est connue : elle ne traite que ce qui a été prévu. Un courrier formulé autrement, un champ mal rempli, une pièce jointe au format inattendu, et la règle échoue ou, pire, se trompe en silence.
Un grand modèle de langage (LLM) fonctionne à l'inverse. Il comprend un texte libre, extrait une information d'un document mal structuré, rédige une réponse adaptée au contexte. Mais sa sortie est probabiliste : deux exécutions peuvent donner deux formulations, parfois deux conclusions différentes. Il peut aussi produire une réponse plausible et fausse, sans le signaler.
Même entrée, même sortie. Testable, auditable, explicable. Aveugle à tout ce qui n'a pas été prévu.
Comprend le langage naturel et les documents désordonnés. Sortie variable, erreurs possibles et silencieuses.
Opposer les deux revient donc à comparer un tournevis et un scanner. La bonne question est : dans mon traitement, quelle étape demande de comprendre, et quelle étape demande de garantir ?
Quand une règle déterministe suffit, et gagne
Certains traitements n'ont rien à gagner d'un LLM, et beaucoup à y perdre :
- Les calculs : un montant, une échéance, un taux, un solde. Un LLM peut se tromper sur une addition ; une ligne de code, non.
- Les contrôles de conformité : un seuil réglementaire, une habilitation, une date limite. La réponse doit être la même pour tous et justifiable devant un auditeur.
- Les entrées structurées : un formulaire aux champs définis, un fichier au format stable, un appel d'API. Les données sont déjà propres, il n'y a rien à interpréter.
- Les décisions à fort enjeu : accorder un droit, valider un paiement, supprimer une donnée. On veut pouvoir rejouer la décision et obtenir le même résultat.
Dans ces cas, un LLM ajoute un coût d'inférence, un délai et un risque d'erreur, sans bénéfice. Si la règle s'écrit simplement, écrivez la règle.
Quand un LLM apporte ce qu'aucune règle ne peut faire
À l'inverse, le LLM devient pertinent dès que l'entrée est du langage humain ou un document non standardisé :
- Lire et classer des courriels, des tickets, des réclamations formulés librement.
- Extraire une information d'un contrat, d'une facture ou d'un compte rendu dont la forme varie.
- Résumer un long document ou un historique d'échanges.
- Rédiger une réponse, un brouillon, une synthèse adaptée au destinataire.
- Rechercher par le sens dans une base documentaire, et non par mots-clés exacts.
Tenter de couvrir ces cas avec des règles produit des arbres de décision interminables, fragiles, et qui échouent au premier cas imprévu.
Le bon modèle : le LLM propose, une règle valide
Dans la plupart des processus métier, les deux se combinent. Le LLM traite ce qui est ambigu et produit une proposition structurée ; une couche déterministe la contrôle avant toute action.
- Le LLM interprèteIl lit la demande, en extrait les éléments utiles et propose une action : créer un ticket, répondre à un client, mettre à jour un enregistrement.
- Une règle contrôleLe format est-il valide ? Les montants sont-ils dans les bornes ? L'utilisateur a-t-il le droit de faire cette action ?
- Un humain valide si l'action engageToute action qui écrit, envoie ou supprime est suspendue jusqu'à confirmation explicite.
- Tout est tracéLa proposition, le contrôle et la décision humaine sont journalisés, pour pouvoir rejouer et expliquer.
Ce découpage a un avantage décisif : la partie probabiliste n'a jamais le dernier mot. Une erreur du modèle est arrêtée par le contrôle ou par la personne qui valide, au lieu de se propager dans le système d'information. C'est aussi ce qui rend l'ensemble défendable devant un auditeur : les décisions qui engagent reposent sur des règles écrites et sur des validations tracées.
Une validation humaine n'a de valeur que si la personne voit exactement ce qui va être exécuté : le destinataire, le contenu, les données modifiées. Valider un résumé vague de l'action revient à ne rien valider.
Une grille pour décider, étape par étape
Plutôt que de trancher pour un processus entier, examinez chaque étape avec quatre questions :
| Question | Si la réponse est oui | Si la réponse est non |
|---|---|---|
| L'entrée est-elle du texte libre ou un document non standardisé ? | LLM pour interpréter | Règle ou code |
| Le résultat doit-il être identique à chaque exécution ? | Règle, au moins pour contrôler | LLM envisageable |
| Une erreur a-t-elle un effet difficile à rattraper ? | Contrôle déterministe et validation humaine | Contrôle a posteriori possible |
| Faut-il justifier la décision devant un tiers ? | Règle écrite et trace de la décision | Trace simple |
Une même chaîne comporte souvent les deux réponses : un LLM pour lire une demande de remboursement rédigée par un client, une règle pour vérifier le plafond, une validation humaine au-delà d'un montant, du code pour exécuter le virement.
Les erreurs les plus fréquentes
Confier un calcul ou un contrôle au modèle
Demander à un LLM de vérifier qu'un montant respecte un plafond, c'est accepter qu'il se trompe parfois. Le modèle peut extraire le montant ; la comparaison au plafond doit rester du code.
Laisser le modèle agir sans garde-fou
Un agent qui peut envoyer un courriel ou modifier un enregistrement sans contrôle transforme chaque erreur de compréhension en incident. Les actions qui écrivent doivent passer par une validation.
Écrire des règles pour tout le langage naturel
À l'inverse, vouloir tout couvrir par des règles conduit à des centaines de cas particuliers, que plus personne ne sait maintenir. Si l'entrée est du langage, laissez le modèle l'interpréter et contrôlez sa sortie.
Juger sur une démonstration
Un LLM impressionne sur dix exemples choisis. Mesurez-le sur un échantillon représentatif de vos cas réels, y compris les cas limites, avant de décider où il intervient.
Questions fréquentes
Un LLM peut-il remplacer un moteur de règles ?
Non, pas pour les décisions qui doivent être reproductibles et justifiables. Il peut en revanche alimenter un moteur de règles en transformant un texte libre en données structurées que les règles savent traiter.
Peut-on rendre un LLM déterministe ?
On peut réduire la variabilité de ses réponses par le paramétrage et par un format de sortie imposé, mais cela ne garantit ni la même réponse à chaque fois, ni une réponse juste. La garantie vient d'un contrôle déterministe placé après le modèle.
Faut-il une validation humaine sur toutes les actions ?
Non. La lecture, la recherche et la rédaction de brouillons peuvent s'exécuter librement. La validation se justifie pour les actions qui écrivent, envoient ou suppriment, parce que leurs effets sont difficiles à rattraper.
Où se situe SmartAGT
SmartAGT applique ce modèle par construction. Les agents lisent, recherchent et rédigent librement ; toute action qui écrit ou exécute dans un outil connecté est mise en pause de façon déterministe, jusqu'à ce qu'une personne la confirme ou la refuse.
L'opérateur voit exactement ce qui va être exécuté avant de décider, et chaque décision rejoint une chaîne d'audit vérifiable. Le détail est sur la page Sécurité.
