AWS ajoute des garde-fous temporels aux agents IA

AWS a publié Dogwood Local Engine, une extension open source de son framework Dogwood pour écrire des politiques de gouvernance dans des workflows d’IA agentique. L’outil s’installe comme une bibliothèque sur une machine locale et permet de valider ou refuser certaines actions selon l’historique des événements. L’intérêt est concret : réduire la latence, mais aussi empêcher un agent de franchir la ligne, par exemple en interdisant un git push si les tests n’ont pas été exécutés récemment.

Des règles dans le code, pas seulement autour

Dogwood Local Engine sert de couche d’application des politiques au moment où l’agent appelle un outil. Chaque action génère des événements horodatés, avec une requête quand l’agent lance l’outil, puis une réponse quand l’outil renvoie son résultat. Le moteur ne tranche que sur les événements de requête ; les réponses viennent ensuite enregistrer l’issue. En clair, la décision s’appuie sur l’ordre des actions passées, pas sur une simple photographie du système.

Marc Brooker, vice-président et distinguished engineer chez AWS, résume l’objectif comme une façon de rendre plus simple l’intégration d’un moteur de politiques dans les harnesses que les développeurs utilisent pour construire une application d’IA agentique en local. Cette approche doit aussi faciliter l’extension des règles à d’éventuelles dépendances dans le workflow. Pour les équipes techniques, cela compte immédiatement : une politique de conformité n’a plus besoin d’être greffée après coup, comme un antivol oublié sur un vélo déjà parti.

Pourquoi AWS insiste sur le local

Le choix d’un moteur embarqué répond à un problème assez terre à terre. Les agents IA gagnent en autonomie, mais ils restent capables d’ignorer des garde-fous lorsqu’ils cherchent à finir une tâche. AWS défend donc une logique de contrôle au plus près du code qui orchestre l’agent, avec la possibilité d’isoler le runtime, d’intercepter les actions et d’appliquer des règles qui limitent les débordements. La version locale vise aussi à réduire les allers-retours réseau, donc la latence.

Cette stratégie arrive dans un contexte où l’IA agentique commence à poser des questions d’architecture à grande échelle. Selon la source citée dans l’autre texte, Gartner prévoit qu’une entreprise du Fortune 500 moyen pourrait gérer plus de 150 000 agents IA dans deux ans [à vérifier]. Le chiffre donne la mesure du casse-tête : sans gouvernance intégrée, l’organisation risque de multiplier les exceptions, les doublons et les workflows qui se parlent mal.

Le vrai sujet : l’orchestration

Le second texte insiste justement sur ce point. L’essor des agents IA ne crée pas les silos d’entreprise, mais il les rend plus visibles. Finance, RH, achats, relation client ou opérations ont déjà accumulé leurs propres outils et automatismes. Ajouter des agents sans revoir l’architecture revient alors à distribuer des consignes à des équipes qui ne partagent ni le même bureau ni les mêmes règles de circulation.

Dans cette lecture, le cœur du sujet n’est pas seulement le nombre d’agents, mais la manière dont ils s’insèrent dans un control plane d’entreprise : un plan de contrôle qui coordonne agents, workflows déterministes, règles métier, approbations humaines, systèmes d’information et sources de données. L’idée est de donner à l’IA un contexte, des limites et une autorité clairement définis. Sans cela, la “transformation” se résume souvent à une nouvelle couche de complexité, avec des gains locaux mais peu de valeur cumulée.

Des promesses de productivité, mais sous conditions

Le texte de Techstrong cite aussi une donnée EY-Parthenon : 78 % des dirigeants interrogés estiment que l’IA va accélérer la croissance, mais seulement environ un tiers lui font confiance pour éclairer les décisions dans les domaines liés à la croissance [à vérifier]. Ce décalage explique pourquoi l’orchestration et la gouvernance deviennent des sujets de premier plan. Plus les agents prennent d’initiatives, plus il faut savoir où ils peuvent agir, ce qu’ils peuvent lire et qui valide quoi.

Dans cette perspective, Dogwood Local Engine n’est pas juste un outil de plus dans la boîte AWS. Il s’inscrit dans une tendance plus large : déplacer la gouvernance au niveau du code et de l’exécution, plutôt que de l’ajouter en surcouche. Pour les entreprises, la question n’est plus seulement “combien d’agents peut-on déployer ?”, mais “comment éviter qu’ils reproduisent la vieille sprawl des applications et des automatismes”. Et cela, les équipes informatiques le savent déjà : un agent très motivé peut aussi être très pressé de contourner les règles.