Déterministe vs probabiliste : la notion à comprendre avant tout projet IA

Tu as lancé un projet IA en interne. Sur les dix premiers tests, tout est parfait. Puis un collaborateur relance exactement la même demande et obtient une réponse différente. Pas fausse, mais différente et là, la question tombe : « Comment on met ça en production si on ne sait pas ce qui va sortir ? »

Cette question n’est pas un détail technique. C’est la notion qui sépare les projets IA qui tiennent en production de ceux qui finissent au placard. Et presque personne ne l’explique avant de vendre le projet.

TL;DR

• Déterministe : mêmes entrées → toujours la même sortie. C’est ton ERP, ton scénario Make, ta requête SQL. Vérifiable, testable, auditable.
• Probabiliste : mêmes entrées → une sortie plausible, qui varie. C’est un modèle de langage. Il ne récupère pas une réponse, il en génère une.
• L’erreur classique : brancher du probabiliste là où le métier exige du déterministe (calcul d’une facture, application d’un barème, contrôle réglementaire).
• La règle : l’IA excelle sur ce qui était jusqu’ici impossible à automatiser (comprendre, reformuler, classer du texte libre). Elle est le mauvais outil pour ce qu’un if fait déjà parfaitement.

Pourquoi une IA ne donne pas deux fois la même réponse ?

Un logiciel classique applique une règle. Tu lui donnes une commande de 3 articles à 12 €, il renvoie 36 €. Toujours. Le jour où il renvoie 37 €, c’est un bug, et tu peux le retrouver dans le code.

Un modèle de langage ne fonctionne pas comme ça. Il prédit, mot après mot, la suite la plus vraisemblable de ce que tu lui as écrit. À chaque étape, il évalue des milliers de continuations possibles et en choisit une. Le résultat n’est pas récupéré dans une base : il est fabriqué.

C’est exactement pour ça que l’IA sait faire des choses qu’aucun script ne savait faire :

• résumer un mail de 40 lignes écrit dans un français approximatif ;
• comprendre qu’un technicien qui dit « la pompe fait un bruit de casserole » décrit une panne mécanique ;
• classer 200 réclamations clients rédigées chacune différemment.

Aucune règle if n’aurait couvert ces cas. Le probabiliste, c’est ce qui rend possible l’automatisation du texte libre, du non-structuré, de l’humain.

La contrepartie est directe : tu ne peux pas exiger d’un modèle probabiliste la garantie qu’on exige d’un script. Ce n’est pas un défaut à corriger, c’est sa nature.

Où placer la frontière dans un projet réel ?

La bonne question n’est pas « est-ce que j’utilise de l’IA ? », mais « quelle partie de la chaîne a besoin de garanties, et quelle partie a besoin de compréhension ? »

Prends un cas concret vu en entreprise : le traitement des mails entrants d’un service client.

Étape	Nature	Qui fait le travail
Récupérer les mails de la boîte	Déterministe	Connecteur IMAP / API
Comprendre la demande, l’intention, l’urgence	Probabiliste	Modèle de langage
Ranger dans la bonne catégorie (parmi 8 fixes)	Probabiliste, sortie contrainte	Modèle + liste fermée
Appliquer le SLA associé à la catégorie	Déterministe	Règle métier
Envoyer au bon service	Déterministe	Automatisation

Le modèle ne fait qu’une chose : transformer du texte libre en information exploitable. Tout le reste (le routage, les délais, les seuils) reste du code classique, testable et auditable.

C’est le pattern qui marche : l’IA comprend, le code décide. Dès que tu laisses le modèle décider d’un montant, appliquer un barème ou trancher un cas réglementaire, tu as mis du probabiliste dans une case qui exige du déterministe.

Cette logique de cartographie (savoir quelle étape fait quoi avant d’automatiser) est exactement la même que celle qui fait échouer les projets d’automatisation n8n et Make copiés-collés depuis un template.

Comment cadrer une sortie probabiliste sans la dénaturer ?

Tu ne rendras jamais un modèle déterministe. En revanche, tu peux réduire drastiquement l’espace de ce qu’il peut produire. Trois leviers, du plus simple au plus structurant :

1. Fermer la liste des sorties possibles

Ne demande pas « quelle est la catégorie de ce mail ? ». Demande « réponds uniquement par l’une de ces 8 valeurs ». Une réponse libre est ingérable en aval ; une valeur parmi 8 se teste, se compte, se monitore.

2. Imposer un format structuré

Un modèle qui renvoie du JSON conforme à un schéma défini à l’avance est infiniment plus exploitable qu’un modèle qui renvoie un paragraphe. Le code en aval sait alors ce qu’il reçoit, et peut rejeter proprement ce qui ne correspond pas.

3. Garder un humain sur les décisions à conséquence

C’est le point le plus important, et le plus souvent sacrifié pour gagner du temps. Une IA qui prépare une réponse client, c’est un gain de temps massif. Une IA qui envoie la réponse client sans relecture, c’est un risque juridique que personne n’a chiffré.

Le cas d’école rencontré sur le terrain : une réponse générée automatiquement, envoyée sans validation, qui engage l’entreprise sur un engagement qu’elle n’a jamais voulu prendre. Résultat : un litige à 5 000 €. Le gain de temps sur six mois de traitement automatique ne couvrait pas la moitié de l’addition.

La règle simple : plus l’action est difficile à annuler, plus la validation humaine est obligatoire. Préparer un brouillon, classer, résumer, extraire → automatisable. Envoyer, signer, payer, supprimer → validation humaine.

Pourquoi les démos marchent toujours et les déploiements coincent ?

Une démo, c’est une personne seule, avec trois documents propres, sur un cas qu’elle a choisi. Un déploiement, c’est trente collaborateurs, des milliers de documents hétérogènes, et des cas que personne n’avait prévus.

Ce qui casse en passant de l’un à l’autre est presque toujours la même chose :

1. Le volume de données. Le comportement d’un système qui pioche dans 3 documents n’a rien à voir avec celui qui doit trancher entre 3 000. C’est là que la plupart des projets de recherche documentaire s’effondrent, un sujet qui mérite d’être traité à part, et qui commence par le travail de structuration de la connaissance.
2. La variabilité des entrées réelles. Les vrais documents sont scannés de travers, mal nommés, incomplets.
3. Les utilisateurs. Ils ne formulent pas leurs demandes comme la personne qui a conçu la démo.

Un test qui passe dix fois de suite sur un cas propre ne prouve rien sur la production. Ce qu’il faut mesurer, c’est le taux d’erreur sur des cas réels tirés au hasard, et surtout : ce qui se passe quand le modèle se trompe. Est-ce qu’un humain le voit ? Est-ce que c’est rattrapable ? Ou est-ce que ça part directement chez le client ?

Et la donnée dans tout ça ?

Le caractère probabiliste change aussi la question de la confidentialité. Un script qui traite un contrat le lit et le referme. Un modèle hébergé chez un tiers reçoit le contenu du contrat sur une infrastructure que tu ne maîtrises pas.

Ce n’est pas rédhibitoire : c’est un arbitrage à poser explicitement, pas à découvrir six mois après le lancement. La CNIL publie des recommandations concrètes sur le développement de systèmes d’IA, et elles se lisent avant le projet, pas pendant l’audit.

Trois questions à poser avant le premier appel d’API :

• Quelles données sortent de l’entreprise, et lesquelles ne doivent jamais sortir ?
• Existe-t-il un traitement local possible pour les documents sensibles ?
• Qui, en interne, est capable de répondre à ces deux questions dans six mois ?

Checklist : cadrer un projet IA avant de coder

• J’ai listé chaque étape du processus et marqué chacune « déterministe » ou « probabiliste ».
• Aucun calcul, barème ou contrôle réglementaire n’est confié au modèle.
• Les sorties du modèle sont contraintes : liste fermée ou format structuré.
• Toute action irréversible passe par une validation humaine explicite.
• J’ai testé sur des cas réels tirés au hasard, pas sur des cas choisis.
• Je sais ce qui se passe quand le modèle se trompe, et qui s’en aperçoit.
• J’ai tranché la question des données sensibles avant le premier appel d’API.

Si une seule case reste vide, le projet n’est pas prêt à sortir de la démo.

FAQ

Peut-on rendre une IA totalement déterministe ?

Non, et il ne faut pas chercher à le faire. Même en réduisant la variabilité au maximum, un modèle de langage reste génératif : sa sortie dépend de son contexte complet. La bonne stratégie n’est pas de supprimer la variabilité, mais de la confiner à l’étape où elle apporte de la valeur (la compréhension du texte) et de garder tout le reste de la chaîne en code classique, testable et auditable.

Comment expliquer cette différence à une direction non technique ?

Une analogie fonctionne bien : un logiciel classique, c’est une calculatrice (même calcul, même résultat, toujours. Une IA générative, c’est un collaborateur compétent) tu lui poses deux fois la même question, il te répond deux fois correctement, mais pas avec les mêmes mots. Personne ne demande à un collaborateur d’être une calculatrice ; on lui confie ce qui demande de la compréhension, et on garde la calculatrice pour les chiffres.

Faut-il abandonner l’automatisation classique quand on adopte l’IA ?

Surtout pas. Les deux sont complémentaires, et les meilleurs projets sont hybrides : une automatisation déterministe qui orchestre le flux, avec un appel à un modèle uniquement sur les étapes qui demandent de comprendre du texte libre. Remplacer un scénario Make fiable par un agent IA « parce que c’est plus moderne » est une régression : tu échanges une garantie contre une probabilité, sans rien gagner.

Quel type de tâche est le meilleur candidat pour un premier projet ?

Une tâche qui existe déjà, que quelqu’un fait à la main aujourd’hui, qui manipule du texte libre, et dont l’erreur est visible et rattrapable. Typiquement : préparer un brouillon de réponse, résumer des comptes-rendus, extraire des informations d’un document. On mesure le temps gagné sur un périmètre réduit avant d’élargir.

Conclusion

Le déterministe et le probabiliste ne s’opposent pas : ils se répartissent le travail. L’IA ouvre l’automatisation à tout ce qui était jusqu’ici hors de portée, le langage, le non-structuré, l’implicite. Elle ne remplace pas la fiabilité d’une règle métier, et il ne faut rien lui demander de tel.

Avant ton prochain projet, fais l’exercice : prends ton processus, découpe-le en étapes, et marque chacune d’un « D » ou d’un « P ». Si un « P » se retrouve sur une étape qui engage l’entreprise, tu viens d’éviter ton premier incident.

Cet article s’appuie sur la MasterClass « Les vrais cas d’usage de l’IA », qui détaille les retours terrain de six entreprises accompagnées. La suite de cette série passe en revue les cas d’usage réellement déployés, et ce qu’ils ont coûté.