Que sont les workflows agentiques ?

La logique d'infrastructure sous-jacente d'un système agentique actif repose sur des boucles continues de perception, de raisonnement et d'action. Lorsqu'un agent autonome ingère un objectif de haut niveau, il l'analyse immédiatement pour le décomposer en sous-tâches séquentielles et gérables. Cette décomposition est essentielle : elle permet au modèle de se concentrer sur les exigences immédiates, ce qui réduit considérablement la charge cognitive et évite les hallucinations qui se produisent souvent lorsque les modèles tentent de résoudre des problèmes complexes en une seule passe de calcul.

Pendant la phase d'exécution active, le modèle traite en continu la télémétrie en direct, déclenche les API requises et évalue les résultats de ses actions. Comme il fonctionne de manière dynamique, l'agent peut pivoter de façon autonome autour des erreurs d'exécution ou des formats de données inattendus pour atteindre le résultat cible sans attendre une intervention humaine manuelle à chaque étape.

Pour illustrer cela, prenons un scénario d'entreprise étape par étape dans lequel un workflow agentique aide à moderniser un composant d'application, en remplaçant un processus de dépannage manuel traditionnel :

L'agent ingère une alerte concernant la dégradation des performances d'un microservice et compare de manière autonome les déploiements actifs dans Google Kubernetes Engine (GKE) avec les modifications de code récentes dans Cloud Source Repositories pour définir le potentiel néfaste.

Le système interroge directement les journaux d'application dans Cloud Logging et les métriques dans Cloud Monitoring pour isoler l'appel d'API à latence élevée ou le conflit de ressources spécifique qui provoque le ralentissement.

À l'aide des API d'infrastructure, l'agent provisionne un cluster GKE temporaire et isolé pour appliquer et évaluer de manière sécurisée une modification de configuration ou un correctif de code proposé, sans affecter le trafic de production.

Lorsqu'une correction proposée ne parvient pas à résoudre la latence dans le bac à sable, l'agent change de stratégie. Au lieu de planter ou d'envoyer un ticket d'échec générique, il évalue l'utilisation des ressources du conteneur et tente d'autres optimisations, comme l'ajustement des paramètres d'autoscaling des pods ou la suggestion de refactorisation du code, jusqu'à ce qu'il trouve une solution fonctionnelle.

Après avoir validé la correction, l'agent prépare la solution pour un examen Human-in-the-Loop (avec intervention humaine) (HITL) obligatoire. Une fois qu'un architecte système humain a approuvé la modification, l'agent applique l'optimisation à la production et enregistre sa logique de dépannage complète dans la banque de mémoire à long terme pour accélérer les réponses aux incidents futurs.

Pour obtenir une autonomie fiable, les développeurs structurent ces workflows à l'aide de modèles de conception architecturale spécifiques qui guident la façon dont l'agent "réfléchit" et fonctionne dans son environnement.

• Le modèle de planification (décomposition des tâches) : lorsqu'un agent reçoit un objectif massif et complexe, tel que "migrer cette ancienne application vers GKE", il le décompose immédiatement en une séquence de sous-tâches plus petites et séquentielles : "analyser les dépendances", "conteneuriser les composants", "configurer la mise en réseau", "tester en préproduction". Cette décomposition réduit la charge cognitive du modèle, ancre son raisonnement dans des étapes gérables et empêche considérablement les hallucinations.
• L'outil utilise un modèle : les agents sélectionnent de manière dynamique l'API, le script ou la requête à exécuter en fonction du contexte de la sous-tâche en cours. En utilisant des frameworks comme Agentic RAG (Retrieval-Augmented Generation, génération augmentée par récupération), l'agent récupère activement le contexte requis à partir de bases de données, de dépôts de code ou du Web, au lieu d'attendre de le recevoir passivement dans un prompt. Par exemple, un agent peut utiliser les API de l'inventaire des éléments cloud pour comprendre l'infrastructure actuelle.
• Le modèle de réflexion (autocorrection) : il repose sur une boucle de rétroaction itérative dans laquelle un agent exécute une tâche (comme l'écriture d'un bloc de code Terraform), lit les journaux de compilation ou de déploiement obtenus, critique son propre résultat et réécrit automatiquement la solution jusqu'à ce que les tests soient concluants et que l'exécution réussisse. Ceci est essentiel pour générer de l'infrastructure as code (IaC) fiable.

Les workflows agentiques passent rapidement de frameworks conceptuels à des déploiements logiciels prêts pour la production dans les principaux secteurs d'activité. Ils améliorent considérablement la façon dont les applications sont créées, déployées et gérées dans le cloud.

Les agents peuvent analyser les applications sur site existantes, identifier les dépendances et générer des rapports détaillés et des plans de migration pour les déplacer vers des plates-formes cloud natives telles que GKE ou Cloud Run.

Les systèmes multi-agents peuvent surveiller les performances des applications, l'utilisation des ressources et les coûts en temps réel. Les agents peuvent suggérer ou appliquer automatiquement des optimisations, comme des ajustements de scaling, l'optimisation des réglages de base de données ou le refactoring de code, pour garantir que les applications s'exécutent de manière efficace et économique.

Les agents axés sur les développeurs peuvent lire les codebases existant s, comprendre la logique des applications et suggérer ou générer automatiquement des extraits de code refactorisés pour améliorer les performances, adopter des modèles cloud natifs ou renforcer la sécurité. Ils s'intègrent souvent à des outils comme Cloud Assist pour fournir des suggestions de code.

En cas de régression des performances, les agents peuvent lancer automatiquement des investigations, corréler les journaux et les métriques de Cloud Logging et Cloud Monitoring, et identifier les causes racines dans les composants d'application distribués, ce qui réduit le temps moyen de résolution. La fonctionnalité Investigations de Cloud Assist est conçue pour cela.

Les agents de sécurité peuvent analyser en continu le code des applications, les configurations et les environnements déployés pour détecter les failles et les cas de non-respect des règles. Ils génèrent automatiquement des étapes de correction ou alertent les équipes de sécurité.

Les agents peuvent générer des scénarios de test, exécuter des tests d'intégration et analyser les résultats des tests, ce qui fournit des boucles de rétroaction continues aux développeurs et accélère le cycle de vie du développement logiciel.