Agents IA : ce qu'il faut réellement savoir faire avant d'en parler en entretien

De quoi parle-t-on quand on dit « agent »

Le vocabulaire du secteur n'est pas stabilisé, et il serait malhonnête de prétendre imposer une définition. Nous appelons ici système agentique un système capable d'utiliser un modèle pour décider ou orchestrer certaines étapes à partir d'un objectif, en s'appuyant sur des outils et dans un cadre de contraintes. La part de décision laissée au modèle varie énormément d'un système à l'autre : c'est précisément cette part qui détermine la difficulté.

Ce qui suit ne cherche pas à défendre ou à contester l'intérêt des agents. L'objet est professionnel : quelles compétences distinguent quelqu'un capable de concevoir un système agentique exploitable, par rapport à quelqu'un capable d'en montrer un en démonstration ? La différence est nette, et elle se voit en entretien dès qu'on parle d'échecs.

Workflow déterministe et comportement agentique

Beaucoup de systèmes présentés comme agentiques sont des enchaînements fixes où un modèle intervient à quelques endroits précis : extraire des informations, rédiger, classer. Le déroulé est décidé par le code. C'est souvent le bon choix, et le dire n'est pas un aveu de manque d'ambition : un enchaînement fixe se teste, se rejoue, se corrige et se supervise beaucoup plus facilement.

Le comportement agentique commence là où le modèle choisit lui-même la suite : quel outil appeler, avec quels arguments, combien de fois, quand s'arrêter. On gagne en couverture des cas non prévus, on perd en prévisibilité. Une compétence clé consiste à placer cette frontière consciemment, étape par étape, plutôt que de la laisser s'installer par défaut.

Tool calling : le vrai contrat entre le modèle et le système

Faire appeler une fonction par un modèle est simple. Concevoir un outil qui reste sûr quand il est appelé au mauvais moment, avec des arguments approximatifs, deux fois de suite ou en parallèle, l'est beaucoup moins. La qualité d'un système agentique tient largement à la qualité de ses outils.

• Périmètre : un outil qui fait une chose, avec une description qui dit aussi quand ne pas l'utiliser.
• Validation : les arguments produits par un modèle sont des entrées non fiables ; ils se valident comme n'importe quelle entrée externe.
• Effets : distinguer explicitement les outils de lecture des outils qui modifient quelque chose. Ce sont deux régimes de risque différents.
• Retours : renvoyer des erreurs exploitables par le modèle, plutôt qu'une exception brute ou un message vide qui le laisse boucler.
• Quotas : borner le nombre d'appels, la profondeur et la durée totale, indépendamment de ce que le modèle décide.

État, contexte et orchestration

Un agent qui enchaîne des étapes accumule de l'information, et cette accumulation devient elle-même un problème : contexte qui grossit, informations obsolètes qui restent, décisions prises au début qui ne sont plus visibles à la fin. Il faut décider ce qui est conservé, sous quelle forme résumée, ce qui est réinjecté à chaque étape et ce qui appartient à un stockage externe plutôt qu'au contexte.

Côté orchestration, les questions concrètes sont : le déroulé est-il séquentiel ou parallèle, qui décide de l'arrêt, que se passe-t-il quand une étape rend un résultat partiel, et comment reprendre une exécution interrompue sans tout recommencer. Un système qui ne sait pas reprendre est un système qu'on relance en entier à chaque incident, avec le coût correspondant.

Actions à conséquences, permissions et validation humaine

Une réponse fausse se corrige. Un e-mail envoyé, un remboursement déclenché, un ticket clôturé, une ligne modifiée dans un système de gestion ne se corrigent pas de la même manière. Dès que le système agit, la conception change de nature : ce n'est plus seulement une question de qualité, c'est une question de responsabilité.

• Permissions : l'agent agit avec les droits de qui ? Ces droits doivent être ceux de l'utilisateur concerné, pas un compte technique aux pouvoirs étendus.
• Validation humaine : placée aux endroits où le coût d'une erreur est supérieur au coût de l'attente. Une validation systématique sur tout finit par être approuvée sans lecture.
• Réversibilité : privilégier les actions annulables, ou prévoir explicitement la compensation d'une action qui ne l'est pas.
• Idempotence : quand une action est rejouée après un incident réseau ou un retry, le système doit pouvoir reconnaître qu'elle a déjà été effectuée. C'est un point classique côté ingénierie, souvent absent des prototypes.
• Journal : conserver qui a demandé quoi, quelles actions ont été exécutées, avec quels arguments et quel résultat.

La validation humaine n'est utile que si la personne dispose de ce qu'il faut pour décider : ce que l'agent s'apprête à faire, sur quelles données il s'appuie, et ce qui se passe si elle refuse. Une boîte de dialogue « Confirmer ? » sans contexte ne protège de rien.

Retries, timeouts, erreurs partielles

Un système agentique appelle plusieurs services, dont au moins un modèle dont le temps de réponse varie. Les défaillances ne sont pas exceptionnelles, elles sont ordinaires. Trois comportements distinguent immédiatement un prototype d'un système exploitable.

1. 1

   Borner le temps et le nombre d'essais

   1

   Timeout par appel d'outil et budget global d'exécution. Un agent sans borne finit par boucler, coûter et bloquer un utilisateur qui attend. Le nombre de tentatives se décide par type d'erreur : réessayer une indisponibilité temporaire a du sens, réessayer une erreur de validation n'en a aucun.

2. 2

   Traiter les échecs partiels

   2

   Trois étapes sur cinq réussies, la quatrième échoue : le système doit savoir s'il continue, s'il s'arrête, s'il annule ce qui a été fait ou s'il rend un résultat incomplet clairement signalé. C'est une décision produit autant que technique, et c'est souvent ce qui manque le plus.

3. 3

   Rendre l'échec lisible

   3

   À l'utilisateur : ce qui a été fait, ce qui ne l'a pas été, ce qu'il peut faire ensuite. À l'équipe : une trace complète permettant de rejouer le cas. Un système qui échoue proprement est plus exploitable qu'un système qui réussit un peu plus souvent mais échoue silencieusement.

Évaluation et observabilité

Évaluer un agent est plus difficile qu'évaluer une réponse unique, parce que le résultat dépend d'un chemin. Deux exécutions identiques en apparence peuvent emprunter des chemins différents. Il faut donc évaluer à la fois le résultat final et le déroulé : les bons outils ont-ils été appelés, dans un ordre acceptable, sans appels inutiles coûteux ?

• Jeux de cas rejouables, incluant des cas d'échec connus et des entrées ambiguës, pas seulement le scénario nominal.
• Traces par exécution : étapes, outils appelés, arguments, durées, coûts, décision d'arrêt.
• Indicateurs d'exploitation : taux d'exécutions abouties, taux d'interventions humaines, coût moyen et coût maximal par exécution, distribution des durées.
• Détection des dérives après un changement de modèle, de version d'outil ou de consigne : sans rejeu, ces régressions se découvrent en production.

Démonstration impressionnante contre système récupérable

La comparaison suivante ne concerne pas la difficulté technique, mais l'exploitabilité. Le second système est moins spectaculaire ; c'est celui qu'une équipe peut mettre entre les mains d'utilisateurs.

Les limites de l'autonomie, et savoir les nommer

Plus la latitude du modèle est grande, plus la variance augmente, plus le coût par exécution devient difficile à prévoir et plus le diagnostic se complique. Ce n'est pas une raison d'y renoncer, c'est une raison de la doser. Savoir dire « ici je n'aurais pas donné cette liberté au modèle, parce que le cas est stable et que la vérification coûte plus cher que le code » est un signe de maturité professionnelle.

Sur la sécurité, le point spécifique aux agents est que du texte non maîtrisé — document récupéré, page web, message d'un utilisateur — peut se retrouver interprété comme une instruction. Un système qui agit doit donc traiter tout contenu externe comme une donnée, contraindre ce que les outils autorisent, et ne jamais faire dépendre une autorisation du seul jugement du modèle.

MCP peut servir à exposer des outils de manière homogène à un système agentique. C'est une brique possible parmi d'autres, utile à connaître, mais elle ne remplace aucune des questions ci-dessus : périmètre des outils, permissions, validation, reprise et observabilité restent à votre charge.

Ce que cela donne en entretien

Les questions qui départagent sont rarement « savez-vous faire du tool calling ». Elles ressemblent plutôt à : que se passe-t-il si l'outil répond en erreur au troisième appel ? comment évitez-vous qu'une action soit exécutée deux fois ? comment savez-vous que votre agent s'est trompé, sans qu'un utilisateur vous le dise ? combien coûte une exécution, au pire ?

Si votre expérience se limite à un prototype, présentez-le comme tel et enchaînez sur ce que vous ajouteriez avant de le confier à des utilisateurs. C'est une réponse solide. Prétendre à une expérience de production que vous n'avez pas se détecte à la deuxième question.

• Agents
• Évaluation
• Production