Guide
Ajouter un agent IA à une application existante.
Ce guide s'adresse à ceux qui envisagent d'ajouter un agent à un logiciel déjà en service. Il porte sur les décisions à prendre avant d'écrire du code, et sur ce qui détermine la réussite ou l'enlisement.
La première décision n’est pas technique
La tentation est d'ouvrir largement : brancher l'agent sur tout ce que l'application sait faire, et laisser les utilisateurs découvrir. C'est la façon la plus sûre de produire une démonstration impressionnante et un produit inutilisable.
Une application en service a des règles, des cas particuliers et des états incohérents hérités. Un agent qui agit dessus sans périmètre défini rencontrera ces cas — et son comportement dans ces situations déterminera la confiance qu'on lui accorde.
Commencer par une tâche permet d'observer ces cas sur un terrain maîtrisé.
Les pièges que nous avons rencontrés
Ceux-ci viennent de la construction de l'agent de BANANA-CONTENT, pas d'une revue de littérature.
Confondre réponse et effet
Un agent qui dit avoir fait quelque chose n'a rien prouvé. Le succès doit venir de l'application, pas du récit de l'agent.
Le demi-succès silencieux
Sur un traitement par lot, si les échecs partiels ne remontent pas explicitement, l'utilisateur croira l'opération terminée. C'est la source de confiance perdue la plus difficile à regagner.
Le contexte qui disparaît
Si l'état de la conversation vit en mémoire du processus, un redémarrage efface une promesse déjà faite à l'utilisateur. Ce qui compte doit être persisté avant d'être annoncé.
La préférence qui ressuscite
Une consigne supprimée peut revenir par un résumé, un cache ou un index. Vérifiez le chemin complet de l'oubli, pas seulement le bouton de suppression.
Les cinq décisions à prendre
- 01
Choisir la tâche de départ
Une tâche fréquente, dont le résultat est visible dans l'application et vérifiable. Évitez le cas spectaculaire mais rare : il ne vous apprendra rien sur l'usage réel, et son échec sera très visible.
- 02
Inventorier ce qui est accessible
Quelles données sont lisibles par programme ? Quelles fonctions sont appelables ? Cet inventaire révèle souvent que le blocage n'est pas là où on le croyait : une API existe mais ne couvre pas l'écriture, ou l'inverse.
- 03
Décider du niveau d’autonomie
Lecture et conseil, préparation d'un changement, exécution : ce sont trois niveaux distincts. Beaucoup de valeur vient du premier. Ouvrir l'exécution d'emblée ajoute du risque sans garantir du bénéfice.
- 04
Préserver le modèle de droits
L'agent doit agir dans le périmètre de l'utilisateur connecté, pas avec un compte technique qui verrait tout. Cette décision est structurante : la reprendre après coup est coûteux.
- 05
Définir ce qu’on mesurera
Avant de commencer, décidez ce qui prouvera que cela fonctionne. « Les utilisateurs l'utilisent » ne suffit pas : la tâche est-elle terminée, et sans correction manuelle derrière ?
Les questions à poser à un intégrateur
Comment l'agent obtient-il ses droits ?
La réponse attendue : du serveur, à partir de l'identité de l'utilisateur connecté. Si un texte saisi ou une configuration cliente peut influencer ce niveau, c'est un problème de conception.
Que se passe-t-il quand une action échoue à moitié ?
Un fournisseur sérieux a une réponse précise à cette question. Si elle est vague, l'interface le sera aussi.
Comment les capacités évoluent-elles avec notre produit ?
Cherchez une déclaration versionnée plutôt qu'un couplage direct au code : sinon chaque évolution de votre application demandera une reprise.
Discutons de votre application.
Nous commençons toujours par regarder ce qu'elle expose déjà.