PMania 3/6 - Ces nouveaux collègues qui n'attendent plus vos ordres : comprendre les agents IA

le 28/09/2026 par Reine Ramade

Tags: Product & Design, Product Management

PMania - Chroniques d'un PM augmenté par l'IA, épisode 3 sur 6

Il y a une différence importante entre demander à quelqu'un de faire quelque chose et lui déléguer réellement la tâche. Demander, c'est donner une instruction et attendre un résultat qu'on contrôle à chaque étape. Déléguer, c'est accepter que la personne, ou dans notre cas l'agent, prenne des décisions intermédiaires sans repasser par vous à chaque micro-étape. C'est le glissement qui s'est produit avec l'IA en 2025-2026 : on est passé d'une IA qui répond à une IA qui agit.

Ce qu'est réellement un agent

Un chatbot classique fonctionne en boucle fermée : une entrée, une sortie, pas de mémoire, pas d'action sur le monde extérieur.

“Un agent IA, c'est un modèle de langage couplé à des outils, capable d'exécuter plusieurs étapes de manière autonome pour atteindre un objectif.”

Il ne répond plus à une question, il accomplit une tâche.

Le mécanisme derrière la plupart des agents porte un nom : la boucle ReAct (Raisonne, Agit, Observe). L'agent raisonne sur ce qu'il doit faire, agit en appelant un outil, observe le résultat, puis reboucle si l'objectif n'est pas atteint, jusqu'à produire une réponse finale. Concrètement, un cycle de fonctionnement d'agent tient en quatre étapes : comprend la mission, planifie le travail, agit et coordonne, synthétise et capitalise.

Schéma circulaire présentant le fonctionnement d’un agent IA en quatre étapes : comprendre la mission en analysant l’intention, le contexte et les contraintes ; planifier le travail en décomposant la tâche ; agir et coordonner en utilisant des outils ou d’autres agents ; puis synthétiser et capitaliser en produisant une réponse contextualisée et en mettant à jour sa mémoire.

Les outils : le cœur de l'agentique

C'est le point clef à retenir : chaque outil exposé à un agent est une décision produit, pas un détail technique. Un outil, c'est une fonction que l'agent peut appeler : recherche web, lecture ou écriture de fichiers, appel d'API, exécution de code, envoi d'email. Un agent qui peut lire des fichiers est un produit très différent d'un agent qui peut les supprimer.

En tant que PM, décider quels outils exposer, avec quelles permissions, et dans quel périmètre de données, c'est déjà de la conception produit, pas de la plomberie technique qu'on délègue sans regarder.

C'est là qu'intervient le MCP (Model Context Protocol) : un protocole standardisé qui permet à un agent de se connecter à des outils externes de façon uniforme, un peu comme une prise universelle. Fichiers et disque, API externes, bases de données d'un côté ; exécution de code, recherche web, outils SaaS (Slack, CRM) de l'autre. Chaque connexion autorisée est un choix de permission, pas un simple branchement technique.

Le curseur le plus important : le human-in-the-loop

S'il ne fallait retenir qu'un seul réglage produit sur un système agentique, ce serait celui-ci : à quel moment l'agent doit-il s'arrêter et demander une confirmation humaine ? Trop peu de points d'arrêt, et on prend le risque d'actions non souhaitées. Trop de points d'arrêt, et la friction annule toute la valeur de la délégation.

Ce curseur se pense comme un gradient, pas comme un interrupteur :

Niveau	Ce que ça veut dire
Copilote	L'humain valide tout, l'agent propose
Supervisé	Validation humaine uniquement sur les actions clés
Autonome	Exécution bout en bout, sans validation intermédiaire

Le bon niveau dépend directement de la réversibilité de l'action. C'est pourquoi il faut poser cette question avant de lâcher un agent sur un produit : sur cette fonctionnalité, quel est le ratio « informer » vs « agir » ? Et si l'agent agit, quelles actions sont réversibles ?

Contexte et mémoire : ce que l'agent retient, et pourquoi ça compte

Un agent peut s’appuyer sur deux types de mémoire :

Une mémoire à court terme : le contexte de la session en cours (context window).
Une mémoire à long terme : des informations stockées de manière persistante et accessibles d’une session à l’autre.

Cette mémoire n'est pas un détail technique de plus : elle soulève des questions de confidentialité, de cohérence et d'expérience utilisateur que le PM doit trancher explicitement dans ses specs. Que retient l'agent d'une session à l'autre ? Qui peut y accéder ? Combien de temps ces données sont-elles conservées ?

Techniquement, un système agentique complet s'appuie sur plusieurs briques qu'il vaut mieux connaître même sans les coder soi-même : un moteur d'inférence (le LLM qui raisonne), une interface d'exécution (IDE, terminal, client lourd), des skills et outils invocables, une couche mémoire (store & retrieve pour la planification), une base de connaissances contextuelle, des protocoles de transport (MCP, API REST) pour parler aux outils, et, trop souvent oubliée, une couche de gouvernance : conformité, garde-fous, journal d'audit.

“La brique de gouvernance est la brique qui transforme un agent expérimental en agent qu'on peut réellement mettre en production.”

Les 5 décisions clés du PM sur un produit agentique

Avant de lâcher un agent sur votre produit, cinq décisions vous reviennent, et à personne d'autre dans l'équipe :

Périmètre d'action : quels outils, quelles données, quelles limites ?
Niveau d'autonomie : copilote ou agent ? Où placer la validation humaine ?
Gestion des erreurs : que se passe-t-il si l'agent échoue en cours de route ?
Transparence : l'utilisateur voit-il ce que l'agent fait, et pourquoi ?
Évaluation (evals) : comment mesurer objectivement que l'agent réussit sa tâche ? (J'y consacre le prochain épisode, avec la sécurité et la rédaction de specs.)

Les questions à se poser avant de lâcher un agent sur son produit

Quatre questions à poser systématiquement en revue de design, avant même de discuter des outils à connecter :

Illustration présentant quatre questions clés à se poser avant de déployer un agent IA : quelle part de son rôle consiste à informer ou à agir, et ses actions sont-elles réversibles ; qui est légalement responsable en cas d’erreur ; comment rendre ses actions compréhensibles pour l’utilisateur ; et dispose-t-on d’une suite d’évaluations avant de modifier ou déployer son comportement.

Ces questions n'ont pas de réponse générique : elles dépendent entièrement du produit, de l'utilisateur, et de la réversibilité des actions en jeu. Mais ne pas se les poser du tout, c'est le vrai risque.

Ce qu'il faut retenir

Un agent agit, il ne se contente plus de répondre : ça change la nature du risque produit.
Le human-in-the-loop est le réglage produit le plus important : il se pense selon la réversibilité de chaque action, pas comme un interrupteur unique.
Chaque outil exposé à un agent est une décision produit à part entière, pas un détail d'implémentation technique.
La mémoire d'un agent, ce qu'il retient d'une session à l'autre, engage des choix de confidentialité et d'expérience utilisateur qui relèvent de la spec, pas du code.

Comprendre ce qu'est un agent ne suffit pas : il faut ensuite le piloter au quotidien. C'est l'objet du prochain épisode : specs comportementales, evals, et la sécurité.

Pour aller plus loin : cette série s'appuie notamment sur le contenu de la formation OCTO Academy « L'IA au service du Product Management » ; si le sujet vous intéresse au-delà de ces articles, elle existe.

PMania, chroniques d'un PM augmenté par l'IA