Concevoir : de l'intention à l'agent qui agit
Tout commence par une intention claire : que doit accomplir l'agent, pour qui, dans quelles conditions, et à quoi ressemble un échec acceptable. Beaucoup d'agents déçoivent non par faiblesse technique, mais parce que l'objectif n'a jamais été formulé avec précision. Écrire cette intention, la relire à froid, la discuter avec ceux qui utiliseront l'agent : ces étapes modestes préviennent une grande part des désillusions ultérieures. L'outillage, aussi soigné soit-il, ne compense jamais un besoin mal défini au moment du départ. Une intention floue produit un agent qui répond à côté de la question qui se pose vraiment.
De cette intention découle le périmètre d'action. L'agent doit-il seulement proposer, ou peut-il exécuter lui-même une action : envoyer un message, modifier une fiche, déclencher une commande ? Plus son autonomie s'élargit, plus le risque et la responsabilité augmentent, et plus le nombre de personnes à consulter grandit. Cette question se tranche avant toute ligne de code, parce qu'elle conditionne le choix des outils comme le niveau de contrôle à prévoir. Un agent puissant qui n'aurait pas de bornes claires devient très difficile à gouverner. Le périmètre d'action est le premier document de gouvernance d'un agent, avant même son code.
Encadrer les accès et la mémoire de l'agent
Un agent utile travaille sur des sources d'information réelles : bases internes, documents, interfaces applicatives. Les outils de connexion simplifient ces branchements, mais chacun ouvre une voie d'accès qu'il faut maîtriser. Le principe à tenir est simple : l'agent ne reçoit que les droits strictement nécessaires à sa tâche, et jamais davantage. Un agent chargé de lire un catalogue n'a aucune raison de disposer d'un droit d'écriture sur le système de facturation qui l'entoure. Chaque droit accordé est une porte qui, une fois ouverte et laissée ainsi, se referme difficilement.
La mémoire pose un problème distinct. Un agent qui retient l'historique de ses échanges produit des réponses mieux contextualisées, mais conserve aussi des informations qui peuvent devenir gênantes avec le temps. Que garder, combien de temps, pour quel usage, et sous quelle base légale : ces questions relèvent directement du RGPD dès qu'elles concernent des personnes identifiables. Concevoir la mémoire comme un choix explicite, avec une durée de conservation décidée à l'avance, évite de transformer un confort de conversation en risque juridique durable. Une mémoire non bornée accumule au fil des mois des fragments que personne ne relit plus.
Tester un agent avant de le lâcher en production
Un agent se comporte différemment selon les formulations, les données et le contexte du jour. Un test sur quelques exemples bien choisis ne suffit pas à garantir sa fiabilité ; il faut éprouver ses réponses sur des cas marginaux, ambigus, voire hostiles. Les outils qui permettent de rejouer un même scénario à chaque évolution du modèle s'avèrent précieux : ils transforment une impression en mesure reproductible, et signalent une régression avant qu'un utilisateur ne la découvre en situation réelle. La reproductibilité des tests distingue une vérification sérieuse d'une impression trop rapide.
Ces tests doivent inclure les situations d'échec, pas seulement les cas où tout se passe bien. Que fait l'agent quand une source est indisponible, quand la demande sort de son périmètre, quand il ne sait pas répondre ? Un comportement de repli clair, qui admet l'incertitude au lieu d'inventer une réponse plausible, vaut mieux qu'une assurance trompeuse. Prévoir ce repli fait partie intégrante de la conception, et non des corrections ajoutées après coup sous la pression d'incidents. L'utilisateur préfère un agent qui dit son incertitude à un agent qui affirme sans fondement.
Documenter l'agent pour qu'il reste maintenable
Un agent vit, évolue et change de modèle sous-jacent, ce qui altère parfois son comportement sans qu'on ait touché à sa logique propre. Sans documentation, cette dérive devient impossible à expliquer à distance et à corriger sereinement. Noter l'objectif, le périmètre, les sources, les limites connues et les décisions prises lors de la conception permet à une personne nouvelle de reprendre le travail sans tout redécouvrir. Cette trace sert aussi le jour où quelqu'un demande des comptes sur une décision particulière de l'agent. La documentation permet à un agent de survivre au départ de celui qui l'a conçu.
La documentation rejoint ici les attentes de gouvernance liées aux usages à haut risque : savoir ce qu'un système fait, comment le surveiller et comment le corriger. Les outils pour concevoir des agents IA produisent souvent journaux et versions, encore faut-il les exploiter avec méthode et les conserver assez longtemps. Un agent bien conçu mais mal documenté redevient opaque au bout de quelques mois, et se retrouve abandonné non par inutilité, mais parce que plus personne n'ose y toucher. Un outil bien documenté reste utile des années, un outil obscur meurt en quelques mois.
Aller plus loin
Concevoir un agent IA fiable demande de réunir plusieurs compétences : cadrage fonctionnel, sécurité des accès et gouvernance des données. Notre catalogue des 31 formations accompagne celles et ceux qui veulent mener ces projets de bout en bout.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations