Mettre un agent IA dans son produit :
le cadre de décision avant le premier prompt

Tous les trimestres, la même question remonte dans les comités de direction : « Et nous, on met un agent IA dans le produit quand ? » La concurrence en annonce un, un investisseur en parle, une démonstration a impressionné tout le monde. La question arrive formulée comme une évidence, avec une date plutôt qu'un pourquoi.

C'est le mauvais point de départ.

La bonne question n'est pas « quand », c'est « pour quelle tâche, et qu'est-ce qui se passe quand il se trompe ». Un agent IA est un excellent outil pour une petite famille de problèmes, et un générateur de dette et d'incidents pour tous les autres. La décision se prend avant la première ligne de prompt, sur une page, avec trois conditions. Voici le cadre que j'utilise pour la prendre.

Dans le guide no-code, low-code et automatisation, je posais déjà une règle : générer du code n'est pas le maintenir. Les agents en sont l'étage suivant. Ils ne génèrent plus seulement du code, ils prennent des décisions à l'intérieur de votre produit, au nom de vos utilisateurs. Raison de plus pour cadrer avant de construire.

1. Qu'est-ce qu'un agent IA, et en quoi est-ce différent d'un workflow ?

Un agent IA est un programme qui reçoit un objectif plutôt qu'une suite d'étapes, choisit lui-même les actions à enchaîner (chercher une information, appeler un outil, rédiger, recommencer) et décide quand il a terminé. Un workflow, même rempli d'IA, suit un chemin que quelqu'un a dessiné à l'avance : si ceci, alors cela.

La différence n'est pas technique, elle est de responsabilité. Dans un workflow, c'est vous qui avez décidé de l'enchaînement, et chaque étape peut être testée isolément. Dans un agent, c'est le modèle qui décide, à chaque exécution, et deux exécutions avec la même entrée peuvent prendre deux chemins différents.

Autrement dit : un workflow est prévisible et rigide, un agent est souple et imprévisible.

Aucun des deux n'est supérieur. Ils ne répondent pas au même problème, et la plupart des projets d'« agent » que l'on voit passer sont en réalité des workflows déguisés, plus chers et moins fiables que s'ils avaient été construits comme des workflows.

2. Ce qu'un agent fait vraiment mieux qu'un workflow

Un agent gagne quand le chemin ne peut pas être dessiné à l'avance. Pas parce qu'on a la flemme de le dessiner : parce qu'il change à chaque cas. Trois situations reviennent.

• L'entrée est floue et variée. Une demande de support rédigée en langage libre, un document dont la structure change d'un client à l'autre, une question qui peut porter sur dix sujets différents. Un workflow exige qu'on classe l'entrée avant de la traiter ; un agent peut la lire telle qu'elle est.
• Le nombre d'étapes dépend de ce qu'on découvre. Diagnostiquer un problème, rassembler les pièces d'un dossier, chercher une information dans plusieurs sources : on ne sait pas à l'avance combien d'allers-retours il faudra. C'est le terrain naturel d'un agent.
• Le résultat attendu est une synthèse, pas un calcul. Résumer, comparer, proposer une première version. Là où un humain aurait eu besoin de jugement, et où ce jugement peut être relu.

Remarquez ce que ces trois situations ont en commun : de la variabilité à l'entrée, et un humain capable de juger la sortie. Gardez ça en tête, c'est la moitié du cadre.

3. Ce qu'un workflow fait mieux qu'un agent (c'est-à-dire presque tout le reste)

Dès que le chemin peut être écrit, écrivez-le. Un workflow coûte moins cher à chaque exécution, se teste, se débogue, et se comporte demain comme aujourd'hui. Un agent consomme davantage d'appels au modèle pour arriver au même résultat, et vous fait payer sa souplesse même quand vous n'en avez pas besoin.

Les cas où un workflow gagne sans discussion :

• La tâche est répétitive et ses règles sont connues. Envoyer une relance, créer une fiche, router un ticket selon trois critères. Une règle explicite bat un modèle qui la devine.
• Une erreur coûte cher ou ne se rattrape pas. Facturer, rembourser, supprimer, envoyer un message à tous vos clients. L'imprévisibilité n'est pas un détail ici, c'est le risque principal.
• Le résultat doit être identique d'une fois sur l'autre. Un calcul, une conformité, un document réglementaire. Ce que vous voulez, c'est la reproductibilité, pas la créativité.

La solution la plus solide est souvent hybride : un workflow qui tient la structure, et un appel au modèle à une seule étape bien bornée, par exemple pour classer une demande ou extraire trois champs d'un texte libre. Ce n'est pas un agent, et c'est très bien ainsi.

La question n'est pas « peut-on le faire avec un agent ? ». On peut presque toujours. La question est « qu'est-ce que l'agent apporte qu'un chemin écrit ne donnerait pas ? ».

4. Les trois conditions à réunir avant d'écrire un prompt

Quand un cas passe le tri précédent, il reste trois conditions. Si une seule manque, je ne lance pas le projet ; je le reformule jusqu'à ce qu'elle soit réunie, ou je le range.

• Condition 1 : une sortie vérifiable. Quelqu'un doit pouvoir dire, sans ambiguïté, si le résultat est bon ou mauvais. Concrètement : vous savez constituer une série de cas réels avec la réponse attendue, et la rejouer à chaque changement de prompt ou de modèle. Si personne ne sait dire ce qu'est une bonne réponse, l'agent ne sera jamais « fini », seulement « impressionnant en démonstration ».
• Condition 2 : une erreur rattrapable. L'agent se trompera, c'est une propriété du système, pas un bug qu'on corrigera plus tard. La question est donc : qui voit l'erreur, quand, et que coûte-t-elle ? Si l'erreur est visible avant d'atteindre l'utilisateur, ou réversible après, la condition est remplie. Si elle part directement chez un client, ou déclenche une action définitive, elle ne l'est pas.
• Condition 3 : un périmètre d'action fermé et un propriétaire nommé. L'agent n'accède qu'aux outils et aux données dont il a besoin, avec les droits les plus faibles possibles, et une personne de l'équipe produit en est responsable : de sa qualité, de son coût, de ses incidents. Un agent « de tout le monde » est un agent de personne, et il dérive.

Ces trois conditions ont un point commun : aucune ne parle de technologie. Elles parlent d'organisation. C'est pour ça qu'elles se tranchent au niveau du décideur, pas de l'équipe technique.

5. Quand un agent IA est-il une mauvaise idée ?

Un agent est une mauvaise idée dès que le coût d'une erreur dépasse la valeur de la souplesse qu'il apporte. C'est le seuil. Il ne dépend pas de la qualité du modèle, il dépend de votre métier.

Quelques signaux qui disent qu'on l'a franchi :

• On ajoute des garde-fous jusqu'à réécrire le workflow. Chaque incident amène une règle de plus, chaque règle réduit la liberté de l'agent, et au bout de trois mois on a un workflow fragile qui passe par un modèle. Autant l'écrire franchement.
• On ne sait pas combien coûte une tâche. Un agent qui boucle, relance un outil ou relit dix documents peut coûter beaucoup plus cher que prévu sur certains cas. Si personne ne suit le coût par tâche, la facture arrive avant le diagnostic. C'est la même logique que la facture qui grossit avec l'usage décrite dans le guide no-code, un étage au-dessus.
• La validation humaine devient un tampon. On a mis un humain dans la boucle, mais il valide cent propositions par jour sans les lire. Il ne rattrape plus rien ; il porte seulement la responsabilité.
• L'agent parle à vos utilisateurs sans qu'ils le sachent. C'est un risque de confiance, et désormais une question réglementaire. Selon la page de la Commission européenne consacrée au cadre réglementaire de l'IA (consultée le 14 octobre 2026), les règles de transparence du règlement européen sur l'IA entrent en application en août 2026, et une personne qui échange avec un chatbot doit être informée qu'elle interagit avec une machine. Faites valider par votre conseil ce que cela implique précisément pour votre produit ; mais la décision d'affichage, elle, se prend au cadrage, pas après la mise en ligne.

Le piège le plus fréquent n'est pas l'agent qui échoue franchement. C'est l'agent qui réussit huit fois sur dix, assez pour qu'on le mette en production, pas assez pour qu'on lui fasse confiance. Les deux cas restants finissent toujours chez quelqu'un : votre support, votre équipe, ou votre client.

6. La page à écrire avant le premier prompt

Tout ce qui précède tient sur une page, et cette page est le vrai livrable de la décision. Elle se rédige avant de choisir un modèle, un fournisseur ou un framework. Voici ce qu'elle contient.

• La tâche, en une phrase. Pas « un assistant intelligent pour nos clients » : « répondre aux questions de facturation à partir de l'historique du compte ».
• Le critère de réussite. Ce que « bonne réponse » veut dire, et la série de cas réels qui servira à le mesurer.
• Le coût d'une erreur et son filet. Qui la voit, à quel moment, comment on revient en arrière.
• Le périmètre d'action. La liste fermée des outils et des données accessibles, et les droits accordés à chacun.
• Le propriétaire. Une personne, pas une équipe.
• Le budget par tâche et le plafond mensuel. Avec ce qui se passe quand le plafond est atteint.
• La sortie de secours. Ce que fait le produit si l'agent est coupé demain : un workflow simple, un formulaire, un humain. Si la réponse est « rien ne marche plus », vous avez créé une dépendance, pas une fonctionnalité.

Cette page a un effet secondaire précieux : elle rend visibles les désaccords. Le produit pense que l'agent doit tout faire, le support pense qu'il ne doit rien envoyer seul, la direction pense que ça ne coûtera presque rien. Mieux vaut que ces trois avis se rencontrent sur une page que dans un incident.

7. Comment introduire un agent sans parier le produit ?

En lui donnant de l'autonomie par paliers, et en ne passant au palier suivant que lorsque la mesure le justifie. C'est la même logique que la démarche décrite sur ce site, avec son sprint pilote : petit, mesuré, puis élargi.

• Palier 1 : l'agent propose, un humain décide. Il prépare une réponse, un brouillon, une synthèse ; rien ne part sans validation. C'est ici qu'on constitue la série de cas et qu'on mesure le taux de propositions acceptées telles quelles.
• Palier 2 : l'agent agit seul sur les cas simples. Une fois la mesure stable, on lui confie la partie la plus prévisible du flux, et tout le reste remonte à un humain. On suit le coût par tâche et les erreurs rattrapées.
• Palier 3 : l'agent agit seul sur un périmètre élargi. Seulement si les deux paliers précédents ont tenu, et toujours avec la sortie de secours en état de marche.

Beaucoup de projets n'ont jamais besoin du palier 3. Un agent qui prépare bien et qu'un humain valide en dix secondes crée souvent plus de valeur, avec moins de risque, qu'un agent autonome qu'il faut surveiller en permanence. Ce n'est pas un échec de s'arrêter au palier 1 : c'est souvent la bonne architecture.

Ce qu'il faut vraiment retenir

Mettre un agent IA dans son produit n'est pas une décision technologique, c'est une décision de responsabilité : qui juge la sortie, qui rattrape l'erreur, qui paie la facture. Les modèles changeront tous les six mois ; ces trois questions resteront.

• Commencez par le workflow : si le chemin peut être écrit, écrivez-le. L'agent n'a de sens que là où le chemin change à chaque cas.
• Réunissez les trois conditions : une sortie vérifiable, une erreur rattrapable, un périmètre fermé avec un propriétaire nommé.
• Connaissez votre seuil : dès que le coût d'une erreur dépasse la valeur de la souplesse, l'agent est une mauvaise idée.
• Écrivez la page avant le prompt : tâche, critère de réussite, filet, périmètre, propriétaire, budget, sortie de secours.
• Montez par paliers : proposer, puis agir sur les cas simples, puis seulement élargir. S'arrêter au premier palier est souvent la bonne réponse.

Un agent bien cadré est l'une des choses les plus utiles qu'un produit puisse ajouter aujourd'hui. Un agent mal cadré est une démonstration qu'on a mise en production. La différence ne se joue pas dans le prompt : elle se joue sur la page écrite avant.

À lire aussi

• No-code, low-code et automatisation : le guide 2026 pour décideurs, l'étage du dessous : ce que ces outils font vraiment, ce qu'ils coûtent, et où ils vous piègent.
• Une équipe qui code avec l'IA : quels rituels Scrum ajuster, la même bascule vue côté équipe : quand l'IA produit, la vérification devient le vrai travail.

Ce cadrage est exactement le volet technique de l'Audit 360° : regarder un projet d'IA avant qu'il ne coûte, trier ce qui relève de l'agent et ce qui relève du workflow, écrire la page qui rend la décision tenable. Le choix du modèle vient après, et il est presque toujours la partie facile.