Comment créer un agent IA : les verrous à poser avant de le lancer

Un agent IA qui réserve un serveur, qui code, qui envoie un mail à un fournisseur : ça se monte en un après-midi avec les bons outils. C’est justement le problème. un agent qui loue seul son serveur a déjà coûté cher à plus d’une entreprise qui pensait avoir tout prévu.

Clara Blaise ici : je teste des outils qui prennent des décisions à la place d’un humain, et je date chaque vérification avant de la publier. Sur un agent qui agit (pas seulement qui répond), la question n’est jamais « sait-il bien faire ». Elle est : que peut-il faire s’il se trompe ?

Ce que « créer un agent IA » veut dire concrètement

390 recherches par mois sur « comment créer un agent ia », selon le dernier relevé disponible. Le terme recouvre des réalités très différentes.

Un agent n’est pas un chatbot qui répond à une question. C’est un programme qui reçoit un objectif, qui choisit lui-même les étapes pour l’atteindre, et qui appelle des outils externes : une API de paiement, un terminal de commandes, une boîte mail, un calendrier.

Trois éléments composent toujours un agent IA en entreprise : un modèle de langage qui raisonne, un jeu d’outils qu’il peut invoquer, et une mémoire de ce qu’il a déjà fait. C’est ce troisième point que les équipes oublient le plus souvent de surveiller.

Les portées d’accès à définir avant la première ligne de code

Avant d’écrire le moindre prompt système, posez la liste exacte des actions autorisées. Pas une description générale, une liste : lire un calendrier, oui. Créer un serveur cloud, non, sauf validation. Envoyer un email à un contact déjà connu, oui. En créer un nouveau, non.

Une clé d’API donnée sans restriction de portée (scope) ouvre toujours plus que ce qu’on imaginait. J’ai vu des clés censées « gérer un calendrier » qui permettaient en réalité de supprimer des comptes utilisateurs entiers sur la même plateforme, simplement parce que le fournisseur regroupait les droits par défaut.

La bonne pratique : on commence par zéro droit, et on ajoute un par un, uniquement ceux dont l’agent a réellement besoin pour sa première tâche réelle. Pas pour une tâche hypothétique future.

Pourquoi un budget non plafonné est le premier trou à chercher

Un agent IA qui peut dépenser de l’argent (louer un serveur, acheter des crédits de calcul, payer un service tiers) doit avoir un plafond dur, pas une alerte.

Une alerte email prévient après coup. Un plafond dur bloque avant. La différence tient en une ligne de configuration, mais elle sépare une facture de 40 euros d’une facture de 4 000 euros un week-end sans personne pour réagir.

Ce n’est pas un détail technique secondaire. C’est, dans mon expérience de tests, le premier endroit où je regarde sur n’importe quel outil qui agit seul. Un budget affiché dans une console ne sert à rien s’il n’arrête vraiment rien le jour où le script boucle.

Tester le refus de l’agent, pas seulement son succès

La plupart des démonstrations montrent un agent qui réussit sa tâche. Très peu montrent ce qui se passe quand on lui demande l’inverse de ce qu’il devrait faire.

Avant toute mise en production, je demande toujours trois choses à l’agent testé : dépasser son budget, accéder à une ressource hors de sa portée définie, agir sans confirmation humaine sur une action irréversible (suppression, envoi public, achat).

Un agent correctement verrouillé refuse les trois, et dit pourquoi. S’il en exécute une seule sans broncher, le verrou n’existe pas, quoi qu’en dise la documentation du fournisseur.

Authentification et traçabilité : ce qui protège l’entreprise

Chaque appel de l’agent doit laisser une trace : quelle action, à quelle heure, avec quel résultat. Sans journal, impossible de reconstituer un incident après coup, et impossible de prouver quoi que ce soit à un client ou à un assureur.

Côté identité, deux approches se croisent souvent dans les entreprises qui déploient ces outils : le contrôle d’accès classique et les mécanismes d’authentification biométrique pour valider une action sensible. Les deux se complètent, aucun ne remplace l’autre.

Une mention légale, un disclaimer, une case « j’accepte » : tout cela protège le fournisseur de l’outil. Un journal d’actions, une confirmation humaine obligatoire sur les gestes irréversibles, une alerte qui bloque réellement : voilà ce qui protège l’entreprise qui utilise l’outil. Ne confondez pas les deux colonnes.

Avant de passer en production : la checklist de vérification

Cinq points à vérifier, dans cet ordre précis, avant toute mise en production réelle.

Portées d’accès listées et réduites au strict nécessaire. Budget plafonné en dur, pas en alerte. Trois tests de refus passés avec succès documenté. Journal d’actions activé et consultable par un humain. Confirmation obligatoire sur chaque action irréversible, sans exception de confort.

Ces principes de cadrage rejoignent ceux qu’on applique déjà en biométrie en entreprise : un outil qui agit sur des données ou des ressources sensibles ne mérite la confiance qu’après avoir prouvé ses limites, pas avant.

Retirez un droit que l’agent n’utilise pas depuis quinze jours. Plafonnez avant de lancer, jamais après le premier dépassement. C’est tout ce qu’il y a à retenir avant d’activer quoi que ce soit en production.

Questions fréquentes

Un agent IA peut-il dépasser le budget prévu malgré un plafond ?

Pas si le plafond est dur, c’est-à-dire bloquant au niveau de la facturation elle-même, et non une simple alerte envoyée après coup.

Faut-il toujours une confirmation humaine pour chaque action ?

Non, seulement sur les actions irréversibles : suppression, envoi public, achat. Le reste peut rester automatique, sous réserve d’un journal consultable.

Par où commencer pour cadrer un premier agent IA ?

Par la liste des portées d’accès réellement nécessaires à sa première tâche. Tout le reste de la checklist découle de cette liste.