Le développement logiciel agentique construit des applications dans lesquelles un modèle sélectionne des étapes intermédiaires, recueille de l’information, modifie un état de travail et appelle des outils vers un objectif borné. La discipline définit environnement, pouvoirs, outils, mémoire, arrêts, évaluation et reprise qui rendent cette boucle variable utile et contenable.
Un agent s’adapte à un cas non codé dans un workflow fixe, mais chaque choix élargit l’espace d’échec. Un plan plausible peut viser le mauvais dossier, répéter un effet, suivre une instruction cachée, épuiser un budget ou déclarer la fin sans confirmation. Les démonstrations cachent souvent ces défauts avec des données propres, des droits larges, une supervision experte et aucune concurrence.
Accordez la plus petite unité d’autonomie utile. Commencez par un workflow déterministe et ne rendez dirigée par le modèle que l’étape réellement variable. Les outils offrent une capacité étroite sous autorisation serveur, jamais une session utilisateur générale. L’état est durable, typé et rejouable. Les effets matériels exigent une décision de politique indépendante et, si nécessaire, une confirmation responsable. Évaluez la trajectoire et le résultat, pas seulement la prose finale.
Périmètre
Ajouter de l’autonomie seulement là où la variation crée de la valeur
L’autonomie n’est pas une fonction produit en soi. C’est le choix de déléguer une partie du contrôle à un composant probabiliste. Dessinez d’abord la tâche sans agent: déclencheur, entrées, décisions, systèmes, sorties et exceptions. Routage stable, autorisation, calcul et transition d’état restent dans le code ordinaire. Le choix par le modèle devient utile lorsque la prochaine étape dépend d’une preuve variable qu’il serait économiquement difficile d’énumérer.
Définissez l’objectif pour que l’application puisse le vérifier. «Résoudre la demande» laisse au modèle la notion de résolution. «Préparer une classification proposée avec preuve citée et router les conflits vers le responsable» a une fin observable. Énumérez non-objectifs et actes interdits. Limitez population et temps. Un agent de recherche interne ne devient pas un agent de communication client simplement parce qu’il découvre un outil d’envoi.
- Modéliser le workflow déterministe avant l’agent.
- Déléguer la plus petite décision variable.
- Définir la fin en termes observables de l’extérieur.
- Nommer les non-objectifs et résultats interdits.
- Borner les cas éligibles et la durée.
Exécution
Posséder l’état, l’arrêt et la reprise hors de la conversation
L’historique des messages est un contexte, pas le dossier canonique. Stockez objectif, acteur, phase, preuves recueillies, approbations, résultats d’outil et fin dans un état applicatif typé. Distinguez un fait proposé d’une observation confirmée et une inférence d’un résultat externe. Un redémarrage reconstruit la tâche sans demander au modèle de se souvenir. Le contexte sensible reçoit accès, conservation et suppression explicites au lieu de s’accumuler indéfiniment en mémoire.
Toute boucle a besoin de limites et de tests de progrès. Bornez étapes, durée, jetons, argent, reprises, éventail et nombre d’effets. Définissez le progrès et arrêtez les cycles qui ne réduisent aucune condition ouverte. Les dépendances ont délai et coupe-circuit. Après un succès partiel, interrogez l’état durable avant de reprendre. La récupération peut continuer depuis un point, compenser, router vers une personne ou échouer. Elle ne peut pas être créée par le récit.
- Garder un état canonique typé hors de la conversation.
- Séparer observation, inférence, proposition et confirmation.
- Budgéter étapes, temps, coût, reprises et effets.
- Détecter absence de progrès et dépendance dégradée.
- Concevoir reprise, compensation et intervention humaine.
Preuve
Tester le chemin emprunté, pas uniquement la réponse finale
Un agent peut atteindre le bon résultat par un trajet interdit, par exemple lire une donnée non autorisée puis l’omettre. L’évaluation enregistre choix des outils, arguments, observations, décisions intermédiaires, contrôles, états et effets. Testez cas normaux avec données manquantes, ambiguïté, conflit, injection indirecte, dépendance lente et succès partiel. Des assertions déterministes vérifient droits et état, des grilles le jugement et des simulations le comportement des outils.
Progressez par niveaux d’exposition: environnement simulé, ombre sans action, puis propositions approuvées explicitement. N’élargissez l’autonomie que pour les familles et outils soutenus par la preuve. Les ressources NIST sur développement sécurisé et risque IA insistent sur le cycle de vie et les responsabilités documentées. Gardez une version livrée, les résultats externes confirmés et un arrêt indépendant. Tout incident devient un cas de trajectoire minimisé avant une nouvelle extension.
- Noter résultat, trajectoire, politique et efficacité séparément.
- Tester observation malveillante et succès partiel des outils.
- Passer de simulation à exposition réelle bornée.
- Élargir par famille et outil plutôt que par étiquette générale.
- Préserver arrêt, rejeu et preuve de régression.
Ce qui caractérise un bon résultat
Résultats concrets pour développement logiciel agentique
- L’agent a un objectif, un contexte, des non-objectifs et une condition d’achèvement mesurable.
- Chaque outil possède un but étroit, un contrat typé, une identité minimale et une classe d’effet.
- Les observations non fiables restent distinctes de la politique système et des instructions autorisées.
- La mémoire de travail, l’état métier durable et la preuve d’audit sont séparés par but et conservation.
- Des budgets bornent étapes, temps, coût, reprises, appels d’outil et impact externe.
- Les actions à fort impact passent l’autorisation déterministe et la confirmation adaptée.
- Le système peut reprendre, compenser, arrêter ou restaurer sans demander au modèle d’inventer les événements.
- L’évaluation mesure résultat, trajectoire, respect des règles, efficacité et reprise sur des cas difficiles.
Modèle opératoire
Comment exécuter le travail
- 01
Borner la tâche et l’autonomie
Définissez acteur initial, objectif, cas éligibles, preuve de fin, résultats interdits et horizon. Cartographiez d’abord un workflow conventionnel. Identifiez la plus petite décision qui bénéficie d’un plan par le modèle et gardez les transitions stables déterministes.
- 02
Concevoir les outils typés et les pouvoirs
Exposez des opérations propres à la tâche avec entrées et sorties validées. Le code résout identité, accès à la ressource et politique pour chaque appel. Séparez lecture, proposition et exécution, employez des identités étroites et l’idempotence pour les effets.
- 03
Ingénierie de l’état et de la boucle
Stockez l’état canonique hors de la conversation. Consignez observations, décisions, résultats d’outil et versions. Fixez maximum d’étapes, temps, dépense, reprises et détection d’absence de progrès. Représentez explicitement terminal, bloqué, échoué et en attente d’approbation.
- 04
Évaluer trajectoires et attaques
Créez des environnements représentatifs avec cas normaux, information absente, instructions conflictuelles, panne d’outil et contenu malveillant. Notez accomplissement, choix intermédiaires, autorisation, effets, efficacité, explication et arrêt sûr.
- 05
Livrer sous limites observables
Commencez par simulation, ombre ou approbation obligatoire, puis élargissez par cas et outil. Tracez versions et effets confirmés, surveillez budgets et politiques et gardez arrêt, retour arrière, reprise manuelle et rejeu d’incident.
Évaluation
Les questions qui changent la décision
- La tâche exige-t-elle un plan adaptatif ou un workflow avec une étape assistée est-il plus sûr et moins cher?
- Quelle preuve établit l’achèvement indépendamment du récit du modèle?
- Quels outils sont nécessaires et peut-on séparer lecture, brouillon et exécution?
- Quelle autorité est utilisée pour chaque ressource et chaque action externe?
- Quel état survit à une reprise ou un redémarrage et quel contexte doit expirer?
- Quelles limites arrêtent boucle, doublon, dépense et extension de périmètre?
- Quelle action exige confirmation, double contrôle ou ne doit jamais être déléguée?
- Quel environnement représentatif teste toute la trajectoire avant la production?
Modes d’échec
Où les équipes perdent le contrôle
Une injection dans un document ou résultat d’outil peut rediriger le plan.
Une fonction d’outil excessive peut exposer des actions sans rapport avec l’objectif.
Des droits larges peuvent appliquer un appel correct au mauvais locataire ou dossier.
L’historique de conversation peut diverger de l’état métier après un échec partiel.
Une reprise peut doubler paiement, message, suppression ou transition.
L’agent peut produire des plans différents en apparence, tourner en boucle et consommer le budget.
Une délégation entre agents peut masquer l’auteur et l’autorité d’une décision.
La mémoire longue peut garder une information sensible ou fausse au-delà de son but.
Une approbation humaine peut devenir automatique si contexte et conséquence sont opaques.
Une mesure de succès peut récompenser la fin tout en ignorant violation et nettoyage.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- résultats correctement terminés par famille et version
- violations critiques de politique et d’autorisation avant et après exécution
- choix d’outil et validité des arguments par opération
- effets confirmés, doublés, compensés et orphelins
- étapes, délai, utilisation et coût par résultat réussi
- arrêts de progrès, budget et sécurité déclenchés à bon escient
- approbation, rejet, modification et reprise par une personne
- régressions de trajectoire détectées avant extension
- reprise réussie après panne de dépendance, worker et outil
- incidents reproductibles depuis l’état, les versions et événements
Questions
Questions fréquentes
Qu’est-ce que le développement logiciel agentique?
C’est l’ingénierie d’applications où un modèle choisit étapes et outils vers un objectif borné. Elle couvre contrats des outils, autorisation, état, mémoire, arrêts, évaluation, observabilité, pouvoir humain et reprise, pas seulement un prompt de planification.
Quand faut-il utiliser un agent IA?
Quand une preuve variable rend la prochaine étape difficile à énumérer et que le résultat reste mesurable et contenable. Si le routage et l’état sont stables, préférez un workflow déterministe avec une étape assistée par modèle.
Comment sécuriser un agent IA?
Minimisez outils, fonctions, droits et autonomie. Imposez identité et autorisation hors modèle, traitez les observations comme non fiables, validez les schémas, rendez les effets idempotents, exigez les approbations adaptées, bornez les ressources et gardez une preuve rejouable.
Comment tester un logiciel agentique?
Utilisez des environnements représentatifs et inspectez les trajectoires complètes. Testez succès, politique, arguments, états, budgets, attaques, pannes, reprise et confirmation externe. Une bonne phrase finale ne justifie pas un trajet dangereux.
Sources
Sources primaires
- LLM06:2025 Excessive Agency OWASP GenAI Security Project
- Secure Software Development Practices for Generative AI National Institute of Standards and Technology
- AI Risk Management Framework Core National Institute of Standards and Technology
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→