Automatiser une décision avec l’IA : le parcours complet en 5 étapes

Pourquoi suivre un parcours plutôt qu’une ressource isolée

Automatiser une décision avec l’IA touche plusieurs sujets distincts : ce qui peut être délégué, la façon de poser la question au modèle, l’appel technique, le seuil à partir duquel une réponse part sans relecture, et la trace à garder de chaque décision. Chacun de ces sujets a sa propre ressource, déjà publiée. Lire une seule de ces pages laisse un trou : celui qui appelle le modèle sans avoir fixé de seuil, ou qui fixe un seuil sans garder de journal, avance à l’aveugle.

Ce trou n’est pas théorique. Une équipe qui code l’appel au modèle avant d’avoir cadré ce qui peut réellement être délégué risque d’automatiser une décision qui aurait dû rester humaine. Une équipe qui fixe un seuil sans jamais relire ses journaux ne saura jamais si ce seuil est devenu trop permissif après quelques mois d’usage. Le parcours existe pour que les cinq sujets avancent ensemble, dans un ordre qui a du sens, plutôt que chacun de son côté.

Cette page est le point d’entrée unique de ce parcours. Elle s’adresse aux deux profils qui se posent la question : un décideur qui veut savoir ce qu’il peut confier à une IA sans y consacrer sa semaine, et un profil technique qui va brancher l’appel dans un workflow. Chaque étape annonce son niveau, du cadrage sans compétence technique jusqu’à l’appel de code. Aucune étape n’exige de créer un compte : tout se lit et s’applique librement, dans l’ordre ou en accédant directement à l’étape qui manque.

Le sommaire ci-dessus mène directement à chaque étape. Un lecteur pressé peut sauter au tableau des livrables, plus bas, pour repérer d’un coup d’œil la ressource qui correspond à son blocage du moment.

Étape 1 : cadrer la décision, ce que vous déléguez et ce que vous gardez

Avant d’écrire la moindre question ou d’appeler un modèle, la première étape consiste à trancher un point plus simple : cette décision peut-elle être déléguée à une IA ? La grille détaillée dans Déléguer une décision à une IA : 5 niveaux, 3 critères distingue cinq niveaux de délégation, de la simple suggestion à l’exécution autonome, et trois critères pour juger qu’un niveau reste valide : la réversibilité de la décision, le coût d’une erreur, et le volume de cas traités.

Une décision réversible, à faible enjeu et à volume répétitif est une bonne candidate à la délégation. Trier une demande entrante vers le bon service, par exemple, se corrige facilement si le mauvais service est saisi : le coût d’une erreur reste faible, et le volume justifie l’automatisation. Une décision irréversible ou qui touche directement un client reste, elle, une décision humaine, même assistée par un modèle : accorder un remboursement exceptionnel ou résilier un contrat n’ont pas le même coût d’erreur qu’un mauvais routage.

Ce cadrage se fait à l’échelle du décideur, sans compétence technique : c’est un choix d’organisation avant d’être un choix d’outil. Il vaut la peine de le faire par écrit, décision par décision, plutôt que de raisonner par grande catégorie d’activité : deux décisions qui semblent proches peuvent avoir un coût d’erreur très différent selon le client concerné ou le montant en jeu.

Étape 2 : écrire les questions typées que le modèle va évaluer

Une fois la décision cadrée, elle doit se traduire en questions que le modèle peut répondre par une forme fixée d’avance, jamais par un paragraphe. C’est ce que fait un modèle de décision comme Jev, présenté dans Jev (TypeSafe) : le modèle IA qui décide sans texte : il accepte des questions de type « Choice » (un choix parmi une liste d’options), « Score » (une position sur une échelle) ou « Noul » (une probabilité sur une question fermée). Chaque question typée renvoie aussi un niveau de confiance, chiffré.

Avant d’écrire ces questions, encore faut-il vérifier que la tâche relève bien d’un modèle de décision et non d’un grand modèle de langage. Le critère qui départage les deux est détaillé dans Modèle de décision ou IA/LLM : comment choisir : qui lit la sortie, du code ou une personne ? Si la réponse doit être lue et comprise par un humain, un modèle de décision n’est pas le bon outil.

L’outil « Générateur de questions de décision IA », en cours de publication, prendra une décision cadrée à l’étape 1 et proposera un jeu de questions typées prêt à tester. En attendant sa mise en ligne, cette étape se rédige à la main à partir des exemples de la fiche modèle Cloudflare.

Écrire une bonne question typée demande souvent plusieurs essais. Une option mal décrite, ou une échelle trop large, produit des réponses moins fiables qu’une formulation resserrée sur le cas réellement rencontré. Il est plus rapide de tester une question sur cinq ou six exemples réels avant de la brancher dans un workflow que de la corriger après coup, une fois l’appel en production.

Étape 3 : appeler le modèle depuis votre workflow

Les questions typées écrites, il reste à les brancher dans un appel réel. Pour une équipe technique, Jev sur Cloudflare Workers AI : test et guide d’implémentation donne le code officiel pour appeler Jev depuis un Worker Cloudflare : le binding, le format des questions et de l’état transmis, la réponse JSON obtenue, ainsi que les seuls chiffres publics disponibles à vérifier sur vos propres cas avant la production.

Pour une équipe sans développeur disponible, Trier des demandes de formulaire avec l’IA : la méthode détaille le même appel assemblé dans un scénario n8n : réception du formulaire, appel du modèle, puis branche selon la réponse obtenue. Les deux voies appellent le même modèle ; elles diffèrent par l’outil qui porte l’appel, pas par la question posée à l’étape 2.

Dans les deux cas, l’appel renvoie une réponse par question déclarée à l’étape 2, chacune accompagnée de sa confiance. Cette réponse ne suffit pas encore à agir seule : c’est l’objet de l’étape suivante, qui décide à partir de quelle confiance elle peut partir sans relecture.

Étape 4 : fixer le seuil de décision et le point de contrôle humain

Un modèle de décision renvoie une probabilité, jamais une certitude. La question qui reste, et qui n’appartient à aucun modèle, est celle du seuil : à partir de quelle confiance une réponse part-elle sans relecture, et en dessous de quel seuil repasse-t-elle par une personne ? Avant d’envoyer une réponse IA, vérifiez ces 4 points détaille l’architecture à mettre en place : questions typées, seuil de blocage, relecture humaine pour les cas sous le seuil, et un protocole de test à faire tourner avant la mise en production.

Ce seuil reste un choix de votre organisation, pas un réglage du modèle. Un seuil trop bas laisse partir des décisions fragiles sans relecture ; un seuil trop haut renvoie presque tout vers une personne et annule l’intérêt de la délégation. L’outil « Simulateur de seuil de confiance », en cours de publication, permettra de tester plusieurs seuils sur des cas déjà rencontrés avant de figer un choix.

En attendant sa mise en ligne, un premier seuil peut se fixer en rejouant à la main une série de cas déjà traités : on regarde, pour chaque niveau de confiance envisagé, combien de réponses auraient été correctes et combien auraient dû repasser par une personne. Ce test manuel, même sommaire, vaut mieux qu’un seuil choisi au jugé, et il peut être resserré dès que le journal de l’étape 5 montre des cas mal tranchés.

Étape 5 : journaliser chaque décision et la relire

Une décision automatisée qui n’est jamais relue ne s’améliore pas et ne peut pas être défendue en cas d’erreur. Journal des décisions IA : la méthode en 4 étapes propose une méthode et un modèle de journal prêt à remplir : le contexte transmis au modèle, la réponse obtenue, le choix final retenu, et le résultat constaté ensuite.

Cette dernière étape referme le parcours sur la première : la relecture régulière du journal révèle souvent qu’un critère de cadrage était mal placé, qu’une question typée manquait une situation, ou que le seuil retenu à l’étape 4 devait être resserré. Le parcours n’est pas linéaire une fois en production : il boucle, étape 5 vers étape 1, à chaque relecture.

La fréquence de cette relecture reste à décider selon le volume traité : une relecture hebdomadaire suffit pour un volume faible, un rythme plus rapproché se justifie dès que le nombre de décisions automatisées augmente. Ce qui compte est que la relecture ait lieu, avec un responsable identifié, et non qu’elle suive un calendrier figé dès le départ.

Ce que ce parcours ne remplace pas

Un modèle de décision renvoie une probabilité, jamais une certitude. Le seuil à partir duquel une décision part sans relecture, la relecture humaine elle-même, et le journal qui garde la trace de chaque cas restent dans le code et l’organisation du lecteur, pas dans le modèle. Aucune des cinq étapes ne dispense de cette responsabilité.

La Refonte n’a pas encore exécuté Jev depuis son propre Worker : les ressources techniques de ce parcours documentent un protocole et le code officiel de l’éditeur, pas un déploiement en production chez nous. Suivre ce parcours ne garantit ni une décision toujours juste, ni une conformité juridique automatique : en cas de doute sur un cadre réglementaire, l’avis d’un juriste reste nécessaire, cette page n’en tient pas lieu.

Les chiffres de latence, de coût ou de fenêtre de contexte cités dans les ressources techniques de ce parcours viennent de l’éditeur du modèle ou de relevés ponctuels sur une démonstration publique. Ils décrivent un état constaté à un moment donné, pas une garantie de performance sur votre propre volume de décisions.

Pour aller plus loin selon votre situation

Les cinq étapes de ce parcours se lisent dans l’ordre pour cadrer un premier cas, ou séparément pour combler un trou précis : un seuil mal fixé, un journal jamais tenu, une question mal typée. Les deux outils cités plus haut, le générateur de questions et le simulateur de seuil, viendront s’insérer directement dans les étapes 2 et 4 une fois publiés, sans changer la méthode décrite ici.

Si vous préférez appliquer ce parcours accompagné, sur vos propres cas plutôt que sur les exemples de cette page, nos équipes forment vos collaborateurs à chaque étape. Cette option convient particulièrement quand plusieurs décisions doivent être cadrées en même temps, ou quand aucune ressource technique n’est disponible en interne pour l’étape 3.