D'abord les règles, ensuite le modèle : comment choisir entre l'automatisation et l'IA
Le calcul du prix dans notre générateur de propositions commerciales n'a été fait ni par des personnes ni par le modèle. Il a été fait par des règles : un ensemble de postes, de remises, de taxes, de frais annexes — tout était appliqué à partir d'un tableau. Les règles ne se trompent pas en arithmétique, ne se fatiguent pas le vendredi et n'inventent pas un poste absent du tarif.
C'est la partie la plus ennuyeuse du système, et c'est elle qui a produit l'essentiel de l'effet. La question à se poser avant de choisir un outil est la suivante : cette tâche a-t-elle une réponse correcte unique, que l'on peut coucher dans une règle — ou non ? La réponse détermine non seulement le coût du déploiement, mais aussi qui répondra de l'erreur.
La frontière ne passe pas par la complexité de la tâche, mais par la nature de la bonne réponse. Si la bonne réponse est unique et peut être écrite, la tâche relève de l'automatisation déterministe : moins chère, reproductible et avec une responsabilité claire. Le modèle de langage est utile là où plusieurs réponses sont admissibles et où le choix entre elles exige une interprétation. Mélanger ces deux classes dans un même circuit est possible, mais uniquement avec une frontière explicite entre elles.
Trois signes qu'une tâche ne doit pas être confiée au modèle
Il est pratique de tester une tâche à l'aide de trois questions, et les trois trouvent leur réponse avant le choix d'un prestataire. Chacune écarte toute une classe de projets qui, sinon, emprunteraient la voie la plus coûteuse.
La bonne réponse est unique et vérifiable. Le coût d'une commande, pour des postes et une remise donnés, est unique. La date d'échéance est unique. L'existence d'une procédure d'exécution forcée à l'encontre d'un partenaire est un oui ou un non. Sur ce type de tâche, le modèle n'ajoute pas de qualité, il ajoute de la variance : il peut donner la bonne réponse, ou une réponse plausible. La règle donne la même réponse pour les mêmes données d'entrée, et c'est là sa propriété essentielle, pas sa limite.
L'erreur a un coût et un responsable désigné. Une erreur de calcul se paie sur la marge, une erreur de délai se paie en pénalité, une erreur de coordonnées bancaires se paie par un paiement envoyé au mauvais endroit. Quand l'erreur vient d'une règle, l'analyse prend quelques minutes : on ouvre la règle, on la lit, on la corrige, et l'erreur ne se reproduit plus. Quand l'erreur vient du modèle, l'analyse bute sur une question sans réponse courte — pourquoi, cette fois-ci, a-t-il répondu autrement.
Le résultat doit être identique à chaque répétition. Un document interne envoyé à un client, un rapport pour la direction, une écriture dans le système de référence (system of record) — partout où le résultat se compare au précédent, la reproductibilité compte plus que la flexibilité. Deux demandes similaires doivent produire deux réponses identiques, sinon c'est l'écart entre elles qui sera discuté, plutôt que le travail lui-même.
| Ce qu'il faut faire | Ce qui le prend en charge | Qui répond de l'erreur |
|---|---|---|
| Calculer le prix selon le tarif et les remises | Règle | L'auteur de la règle — l'erreur est reproductible |
| Vérifier un partenaire dans un registre | Règle et intégration | Le propriétaire de l'intégration |
| Empêcher l'envoi d'un document sans coordonnées | Champ obligatoire | Personne — l'envoi est impossible |
| Rédiger le commentaire d'un poste de devis | Modèle | La personne qui a validé le texte |
| Analyser un courrier entrant pour en dégager le sens et la tâche | Modèle | La personne dans le circuit de validation |
| Choisir un modèle de réponse selon le contenu de la demande | Modèle avec garde-fous | Le propriétaire du processus — selon le taux de choix erronés |
La troisième colonne compte ici plus que les deux premières. Dans la partie déterministe, la responsabilité est nominative et localisable ; dans la partie probabiliste, elle est diffuse et exige un mécanisme à part. Les projets qui ne passent pas ce test au départ finissent justement bloqués dessus.
Il faut aussi dire ce que ce test ne résout pas. Il ne répond pas à la question de savoir si une automatisation est nécessaire du tout : une tâche à réponse unique peut n'avoir lieu qu'une fois par trimestre et ne pas justifier une seule heure de développement. Et il n'élimine pas la partie la plus difficile du travail — établir quelle est la règle. Dans notre cas, la formalisation du calcul du prix a pris plus de temps que sa programmation : il s'est avéré que trois commerciaux avaient trois représentations différentes de la base sur laquelle la remise se calculait, et ce fait n'était apparu nulle part avant le déploiement.
C'est une découverte typique. La règle que « tout le monde connaît déjà », dès qu'on tente de l'écrire, se scinde en plusieurs versions divergentes, et ce seul travail d'analyse produit déjà un effet — indépendamment de ce par quoi la tâche sera finalement traitée.
Pourquoi les projets pilotes ne se transforment pas en profit
L'écart entre la démonstration et l'effet réel a été mesuré par plusieurs groupes indépendants, et les chiffres convergent dans la même direction, même si les méthodes diffèrent.
Près de 95% des organisations ayant investi dans l'IA générative en entreprise n'en ont tiré aucun retour mesurable. Les auteurs l'attribuent non pas à la qualité des modèles, mais aux propriétés du déploiement : les systèmes ne conservent pas le retour d'expérience, ne s'adaptent pas au contexte et ne s'améliorent pas dans le temps.
Ce rapport mérite une remarque à part. Il a été largement cité dans la presse, et les reprises ont déformé les paramètres de l'échantillon — au lieu de 52 entretiens et 153 dirigeants interrogés, d'autres chiffres circulaient. Il vaut mieux le vérifier dans le PDF original plutôt que dans les articles qui en parlent ; et il ne compare pas l'IA générative à l'automatisation déterministe — ce rapprochement est le mien, pas celui des auteurs du rapport.
Seules 39% des entreprises attribuent à l'IA un effet mesurable, quel qu'il soit, sur le profit opérationnel, et pour la plupart d'entre elles, cet effet représente moins de 5% de l'EBIT. Environ deux tiers des organisations n'ont pas encore commencé à déployer l'IA à l'échelle de l'entreprise.
La limite est évidente, et c'est moi qui la signale, pas un critique de l'article : ce sont des déclarations de dirigeants, et la société qui a mené l'enquête vend elle-même du conseil en déploiement d'IA. La méthode et l'échantillon sont divulgués en toute transparence, ce chiffre est donc utilisable — mais comme un témoignage des acteurs du marché sur eux-mêmes, pas comme une mesure.
Ce que coûtait l'automatisation déterministe avant l'IA
Les règles ont leur propre histoire mesurée, utile justement comme point de référence. L'automatisation robotisée des processus (RPA) s'est déployée exactement aux mêmes endroits — gestion documentaire, back-office, traitement des demandes — où l'on introduit aujourd'hui des modèles de langage.
74% des entreprises interrogées avaient déjà déployé l'automatisation robotisée des processus, et celles qui étaient allées jusqu'au résultat ont signalé une réduction moyenne des coûts de 32%. Dans le même rapport, la durée moyenne de retour sur investissement est cependant passée de 16 à 22 mois.
La source a quatre ans, et c'est un choix délibéré : j'ai besoin d'un fait structurel sur la maturité de l'automatisation par règles avant l'essor de l'IA générative, pas d'une actualité récente. Les données sont déclaratives, sans audit indépendant, et l'allongement du délai de retour sur investissement de 16 à 22 mois montre que les règles ont, elles aussi, une limite — le rapport n'enjolive pas le tableau.
À quoi ressemble un circuit combinant les deux
En pratique, le choix est rarement du tout ou rien. Dans un système opérationnel, les deux classes coexistent, et la valeur naît d'une frontière explicite entre elles, pas de la victoire de l'une sur l'autre.
L'ordre des étapes n'est pas décoratif. Les règles se placent avant le modèle, car il est moins coûteux d'écarter une entrée manifestement incomplète avant d'avoir payé pour un appel au modèle. L'humain dans la boucle (human-in-the-loop — le scénario où une personne valide ou rejette la décision) intervient là où l'erreur coûte de l'argent, pas là où elle paraît la plus inquiétante.
Et un mot à part sur la mesure. Les corrections effectuées par l'humain doivent revenir dans le jeu d'évaluation (evals — un ensemble de tâches de référence sur lesquelles le modèle est testé). Sinon, dans six mois, personne ne pourra dire si la situation s'est améliorée ou dégradée : il n'y aura rien à quoi comparer.
La marche à suivre qui économise le budget
Décomposer le processus en décisions
Pas en étapes, mais en points où quelque chose est choisi. Pour chaque point, répondre : la bonne réponse est-elle unique, ou y en a-t-il plusieurs ?
Traiter par des règles tout ce qui est univoque
Calculs, contrôles, champs obligatoires, routage selon des critères formels. C'est peu coûteux et cela se fait plus vite que le choix d'un prestataire.
Mesurer ce qui reste
Après la première étape, la tâche se réduit souvent au point que le modèle n'est plus nécessaire qu'à un seul endroit au lieu de cinq. Parfois, à aucun.
Construire la mesure pour ce qui reste
Jeu d'évaluation, taux de corrections humaines, taux de refus. Sans ces trois chiffres, vous ne distinguerez pas une amélioration d'un coup de chance.
Un modèle posé au-dessus d'un processus sans règles hérite de tous ses défauts et en ajoute un de son cru : désormais, l'erreur ne peut plus être reproduite.
Les questions les plus fréquentes
Comment savoir si une tâche a besoin d'un modèle de langage ou si des règles suffisent ?
Posez une seule question : cette tâche a-t-elle une bonne réponse unique, ou plusieurs réponses admissibles ? Un calcul, une vérification dans un registre, un routage selon un critère formel — une seule réponse, donc une règle. La rédaction d'un texte, l'analyse d'un courrier libre, le choix d'une réaction selon le sens d'une demande — plusieurs réponses admissibles, donc un modèle. Si l'on ne peut pas répondre à la question, c'est que la tâche est formulée de façon trop imprécise pour être automatisée.
L'automatisation déterministe est-elle dépassée ?
Non, c'est la répartition du travail qui a changé. Auparavant, il fallait formaliser le processus dans son intégralité, sinon il ne pouvait pas être automatisé, ce qui écartait la majorité des tâches. Aujourd'hui, on formalise la partie vérifiable, et la partie non formalisable est confiée au modèle. Le volume automatisable a augmenté, l'exigence de reproductibilité des calculs reste, elle, inchangée.
Qui répond de l'erreur du modèle dans un processus métier ?
Celui qui en a défini le périmètre d'application, et celui qui a validé le résultat. En pratique, cela suppose trois choses : un propriétaire du processus est désigné, les points où l'humain valide la décision sont fixés, et un suivi statistique des erreurs existe, avec un seuil au-delà duquel le scénario s'arrête. Si aucune de ces trois conditions n'est réunie, la responsabilité n'est pas répartie, elle est simplement non assignée.
Par où commencer si un budget IA est déjà alloué ?
Par un inventaire des décisions au sein d'un même processus, pas par le choix d'une plateforme. Prenez le processus comportant le plus de travail manuel, listez tous les points de décision et classez-les en univoques ou ambigus. Il s'avère généralement que les trois quarts des points sont univoques, et il est plus raisonnable de répartir le budget en conséquence : l'essentiel vers les règles et les intégrations, le reste vers le modèle pour les points restants.
La mécanique du calcul par règles, des blocs obligatoires et de l'envoi depuis la fiche d'affaire provient de la description de notre propre produit, Alego.Digital (générateur de propositions commerciales). Le circuit de vérification des partenaires dans le registre des procédures d'exécution forcée, avec notification du responsable et écriture du résultat dans le CRM, provient de la description d'un second produit maison de la même période. Ce sont des documents internes de l'entreprise de l'auteur ; ils n'ont pas été vérifiés par un tiers indépendant et sont présentés à titre d'illustration de la mécanique. L'exemple de circuit mixte du schéma est une généralisation de la pratique, et non la description d'un déploiement précis.
- MIT Project NANDA. The GenAI Divide: State of AI in Business 2025, août 2025. nanda.media.mit.edu
- McKinsey & Company (QuantumBlack). The State of AI: Global Survey, 5 novembre 2025. mckinsey.com
- Deloitte. Automation with intelligence: 4th Global Intelligent Automation Survey, 2022. deloitte.com