L’IA agentique en entreprise : comment concilier autonomie et contraintes

Les équipes d’entreprise passent des assistants basés sur le chat à des systèmes capables d’effectuer des actions. Je vois le changement dans la façon dont les gens décrivent le travail. Ils demandent un assistant capable d’écrire du code, de déposer des tickets, de mettre à jour les enregistrements CRM, d’exécuter une liste de contrôle de conformité, de générer une pull request et de passer à l’étape suivante. Cette forme de travail nécessite un système agent.

Je définis un système agentique comme un logiciel qui transforme un objectif utilisateur en une séquence d’étapes, exécute ces étapes via des outils, garde une trace de ce qui s’est passé et produit un résultat vérifiable. Le modèle contribue à la planification et au langage. Le système environnant fournit l’autorité, l’état, la vérification et le contrôle.

( Voir aussi : « Comment exécuter GenAI d’entreprise comme un service de production »)

La question d’ingénierie reste cohérente dans tous les domaines. Comment donner au système suffisamment d’autonomie pour être utile tout en gardant les résultats prévisibles ? Une réponse de production vient de contraintes explicites et appliquées.

Définir la boucle des agents

Une boucle d’agent est le cycle répété que le système suit pour terminer son travail. J’utilise une boucle simple et je rends chaque étape observable.

1. Plan : l’agent choisit la prochaine action en fonction de l’objectif, de l’état actuel et de la politique.
2. Agir : L’agent appelle un outil avec des arguments structurés, puis enregistre le résultat.
3. Vérifier : le système vérifie le résultat par rapport aux attentes en matière de stratégie et de tâche.
4. Validation : le système écrit le changement d’état dans un magasin durable et produit un événement d’audit.

Ces mots ont des significations spécifiques dans la mise en œuvre. La planification produit une intention structurée. Action utilise une interface limitée avec un schéma défini. La vérification effectue des contrôles déterministes. Commit écrit l’état versionné et le contexte de trace.

Définir les outils et les contrats d’outils

Un outil est toute capacité appelable en dehors du modèle. Il peut s’agir d’une API, d’une requête de base de données, d’un moteur de workflow, d’une action de référentiel de code ou d’une étape d’automatisation du navigateur. L’utilisation des outils domine le risque opérationnel, car les outils peuvent modifier les systèmes d’enregistrement.

Un contrat d’outil est la limite qui garantit l’utilisation d’un outil en toute sécurité. Je l’écris dans le cadre de la revue de conception. Un contrat comprend les éléments suivants :

• Entrées : un schéma qui rejette les paramètres de forme libre et applique les types.
• Autorisations : le contexte d’identité, les étendues et les limites des données.
• Idempotence : une clé de requête et une règle de relecture afin que les nouvelles tentatives ne créent pas de modifications en double.
• Limites de débit : par utilisateur, par agent et par outil pour protéger les systèmes partagés.
• Sémantique des erreurs : codes d’erreur stables et conseils pour réessayer.
• Champs d’audit : ID de demande, acteur, heure, enregistrement cible et références avant/après.

Ce contrat transforme un agent en client de système distribué régulier. Cela devient testable. Cela devient déboguable. Cela devient quelque chose qu’une équipe opérationnelle peut posséder.

Définir la politique sous forme de règles exécutables

La politique dans un système agent signifie les règles que le runtime applique à chaque étape. Je traite la politique comme un module exécutable. Il se trouve dans le chemin de la requête. Il est versionné. Il émet un événement d’audit sur les décisions.

Les domaines de politique courants incluent l’accès aux données, les listes autorisées d’outils, les destinations approuvées pour les écritures, les citations requises pour le matériel récupéré et les règles de refus pour les demandes restreintes. La politique commence simplement et se développe en fonction de l’apprentissage incident.

Traiter l’État comme un composant de premier ordre

L’État est le registre durable de ce que l’agent sait et de ce qu’il a fait. Je garde l’état en dehors du modèle. Je le persiste avec un schéma clair. Je le versionne par étape.

Je stocke au moins l’objectif, les étapes du plan, les entrées et sorties des outils, les résultats de la vérification et la décision finale. Je stocke également les sources récupérées lorsque la récupération fait partie de la boucle. Cet état prend en charge la relecture pendant les incidents et prend en charge l’évaluation ultérieure.

Les équipes qui conservent leur état uniquement dans un tampon de conversation perdent la capacité de raisonner sur leur comportement à grande échelle. Un magasin d’état durable prend en charge les tentatives, les transferts et les rapports de gouvernance.

Utiliser la vérification comme porte d’entrée à l’action

La vérification est un ensemble de vérifications exécutées avant une écriture et après un appel d’outil. J’utilise des contrôles déterministes autant que possible. Je traite la sortie du modèle comme une entrée à valider.

Les exemples incluent la validation de schéma, les contrôles d’autorisations, les contrôles d’intégrité des références et les contraintes sur les systèmes cibles. Pour les flux de travail de contenu, la vérification inclut la couverture des citations et la vérification des données restreintes.

J’utilise également une politique de confiance pour les actions à fort impact. Le système peut nécessiter une étape d’approbation humaine pour certains outils ou destinations. L’approbation fonctionne mieux lorsqu’elle est limitée à une action claire avec un contexte et des preuves.

Construire un harnais d’évaluation autour de la boucle

L’évaluation des agents se concentre sur l’achèvement des tâches de bout en bout et sur les propriétés de sécurité. Je définis les critères de réussite des tâches comme des faits observables. Le ticket existe. L’enregistrement a été mis à jour avec les champs corrects. La demande d’extraction réussit les contrôles. La demande de modification dispose des approbations appropriées.

Je crée des suites de scénarios qui couvrent les tâches de routine et les cas extrêmes. Je les exécute avec des graines fixes lorsque cela est possible et avec des simulations d’outils stables. J’exécute également un petit ensemble de tests en direct sur un environnement de test avec des données réalistes.

Je suit les métriques liées aux opérations. Taux d’achèvement des tâches par scénario. Étapes moyennes par tâche. Taux d’erreur des outils. Taux d’échec de la vérification. Taux d’approbation humaine. Temps moyen de récupération lorsqu’un outil renvoie des résultats partiels.

Un modèle de référence pratique

Je construis des agents de production avec un modèle de superviseur. Un superviseur est propriétaire de la politique, du routage et de l’état. Des travailleurs spécialisés gèrent des tâches précises telles que la récupération, la synthèse d’un ticket ou une action de référentiel. Les travailleurs fonctionnent avec les autorisations minimales requises pour leur contrat.

Un croquis simplifié ressemble à ceci :

def run_task(goal, user):
    ctx = start_context(goal, user)
    while ctx.open_steps:
        intent = planner.propose_next(ctx)
        intent = policy.enforce_intent(intent, ctx)
        call = tool_router.bind(intent, ctx)
        result = call.execute(idempotency_key=ctx.step_key)
        checks = verifier.run(intent, result, ctx)
        ctx = commit_step(ctx, intent, result, checks)
        if checks.requires_approval:
            ctx = wait_for_approval(ctx)
    return ctx.outcome

Cette structure conserve l’autorité du superviseur. Il maintient les autorisations des outils étroites. Il offre aux équipes opérationnelles un endroit unique pour appliquer les politiques et observer les comportements.

Des pratiques opérationnelles qui maintiennent la stabilité des agents

J’utilise un petit ensemble de pratiques lorsque les équipes souhaitent que les agents fonctionnent en toute sécurité en production.

• Commencez par des flux de travail à faible rayon de souffle. Les tâches de lecture lourdes et la génération de brouillons renforcent la confiance et l’instrumentation.
• Expédié avec une liste d’autorisation d’outils limitée. Développez en fonction des résultats mesurés et de l’apprentissage incident.
• Utilisez des déploiements par étapes. Commencez par les utilisateurs internes, puis une petite cohorte, puis une exposition plus large.
• Gardez les schémas d’outils stricts. Les paramètres des outils de forme libre créent des écritures imprévisibles.
• Fixez des budgets. Appliquez un nombre maximal d’étapes par tâche, un nombre maximal d’appels d’outils et un plafond de coûts.
• Tenir à jour les runbooks. Incluez la restauration, la désactivation des commutateurs par outil et les itinéraires de remontée vers les humains.

Liste de contrôle minimale viable

Je recherche ces éléments avant qu’une équipe n’exécute des flux de travail agents à grande échelle.

• Une définition écrite de la boucle agent, avec des traces à chaque étape.
• Contrats d’outils avec schémas, autorisations, idempotence, limites de débit et champs d’audit.
• Module de stratégie avec gestion des versions et application dans le chemin de la requête.
• Magasin d’état durable avec des enregistrements par étapes pour la rediffusion et les rapports de gouvernance.
• Portes de vérification sur les écritures et les actions à fort impact.
• Suite d’évaluation qui mesure l’achèvement des tâches et les propriétés de sécurité.
• Contrôles opérationnels, y compris les budgets, le déploiement par étapes et la désactivation des commutateurs par outil.

Les contraintes sont essentielles

Les systèmes agentiques conviennent au travail des entreprises car ils connectent les interfaces linguistiques aux systèmes d’entreprise. Les systèmes fonctionnent bien lorsque l’autonomie s’inscrit dans des contraintes explicites. Les contraintes transforment le comportement des agents en quelque chose que les équipes peuvent mesurer, améliorer et auquel elles peuvent faire confiance.

—

Forum des nouvelles technologies offre un lieu aux leaders technologiques, y compris les fournisseurs et autres contributeurs externes, pour explorer et discuter des technologies d’entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous considérons comme importantes et du plus grand intérêt pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas de matériel marketing pour la publication et se réserve le droit de modifier tout le contenu contribué. Envoyer tout demandes de renseignements à doug_dineley@foundryco.com.