Résumé exécutif

logIQ est la capacité d’enquête et de remédiation agentique d’HCLTech, construite sur AWS. Au lieu de donner aux ingénieurs un autre tableau de bord à surveiller, il leur fournit un premier intervenant toujours actif. Dès qu’une alerte se déclenche, logIQ commence automatiquement à enquêter et, pour les classes de défaillance qu’il reconnait déjà, il résout le problème avant qu’un ingénieur ne soit appelé.

La conception repose sur une séparation stricte : l’agent qui enquête n’est jamais celui qui agit. Un deuxième agent prend en charge la remédiation et chaque changement qu’il effectue, qu’il s’agisse d’une automatisation en direct ou d’une demande de fusion contre l’infrastructure en tant que code, se fait dans les contrôles de déploiement déjà en place dans l’entreprise. L’objectif est simple : éliminer les 30 à 90 minutes que chaque incident perd actuellement à la priorisation manuelle avant même que la remédiation puisse commencer.

Introduction

La plupart des processus de gestion d’incident se ressemblent d’une organisation à l’autre. Une alerte se déclenche, un ingénieur est appelé et avant qu’une correction ne puisse être apportée, l’ingénieur passe la première étape de l’incident à établir ce qui s’est passé : extraire les journaux, vérifier les déploiements récents et cartographier les ressources concernées. Cette corvée est le prix à payer pour en arriver à la correction, et il est payé à chaque incident, peu importe le moment de la journée.

logIQ est conçu pour combler cet écart : une suite nuagique-native, agentique qui traite l’enquête et la remédiation comme deux tâches distinctes et automatisables plutôt qu’un seul travail indifférencié confié à un unique ingénieur. Il fournit un modèle opérationnel permettant de passer d’une alerte à une résolution documentée sans dépendre de la disponibilité immédiate d’une personne pour amorcer le processus.

Le besoin

Pensez à ce qui se passe lorsqu’une alerte se déclenche aujourd’hui. Un ingénieur est appelé et la résolution est retardée avant même de commencer, parce que les journaux sont dans un outil, l’historique des déploiements dans un autre et la topologie des ressources dans un troisième, rien ne permettant de les corréler automatiquement. Un diagnostic qui devrait aller vite devient une enquête manuelle répétée identiquement à chaque incident, peu importe à quel point la cause sous-jacente est courante.

logIQ comble l’écart entre le déclenchement d’une alerte et l’action de quelqu’un. Plutôt que de s’arrêter à la notification, il enquête automatiquement, applique une solution connue lorsque c’est possible et remet un résumé structuré à un ingénieur seulement si l’incident exige vraiment un jugement humain. Cela permet de garder la réponse aux incidents cohérente et vérifiable tout en opérant dans les processus de gestion du changement déjà adoptés par les entreprises : Git et l’infrastructure en tant que code, et non autour de ceux-ci.

Architecture de la solution

• La plateforme fonctionne comme un pipeline en trois étapes : détection, investigation et correction. Tout outil de surveillance peut le déclencher ; un agent effectue le diagnostic qu’un ingénieur ferait autrement manuellement et un deuxième agent agit en fonction du résultat sans sortir du contrôle de changement existant
• Intégration universelle des alertes : logIQ accepte les webhooks de toute plateforme de surveillance, y compris Datadog, Splunk, PagerDuty, New Relic, Grafana et ServiceNow. Les sources indirectes transitent d’abord par Amazon SNS et une fonction Lambda signée, mais le point d’entrée se comporte de la même façon peu importe quel outil a déclenché l’alerte : un événement authentifié amorce la chaîne
• Investigations corrélées : Une fois déclenché, AWS DevOps Agent interroge CloudWatch, CloudTrail et OpenSearch, puis vérifie les résultats par rapport à l’historique récent des validations dans GitHub et GitLab. La plupart des défaillances en production remontent à une modification, donc cette étape de corrélation est généralement la voie la plus rapide vers une cause racine, complétée en quelques minutes plutôt que les 45 à 90 d’un triage manuel typique
• Correction par trois parcours réglementés : Une fois l’investigation terminée et une conclusion structurée produite, l’agent de correction logIQ sélectionne exactement une voie : un cahier d’exécution SSM Automation rédigé à l’avance pour des défaillances connues, une demande de tirage dans le dépôt d’infrastructure comme code pour les changements à rendre persistants, ou un transfert complet à l’ingénieur de garde pour tout ce qui est nouveau. Aucune voie ne permet qu’un changement non révisé soit appliqué directement à un environnement de production

La couche de raisonnement agentique

La conception repose sur une séparation claire entre l’agent qui enquête et l’agent qui agit, coordonnée par Amazon EventBridge.

• Enquête : gérée par l’agent DevOps. Cet agent a une seule responsabilité : établir une constatation structurée en consultant les journaux, les métriques et la topologie en temps réel, puis en corrélant le début des symptômes avec l’historique des déploiements. Il recommande, mais n’exécute pas. Cette limite permet à cet agent de s’exécuter automatiquement à chaque alerte, sans risque d’agir avec une vision incomplète de l’incident
• Remédiation : gérée par l’agent de remédiation logIQ. Ce second agent reçoit la constatation via EventBridge et Lambda, et son champ décisionnel est délibérément restreint : panne connue, modification persistante ou incident nouveau. Chaque résultat correspond à une action prédéfinie, ce qui permet à la remédiation de rester déterministe plutôt qu’improvisée
• Le contrôle des changements n’est jamais contourné parce que les pannes connues passent par l’automatisation SSM derrière une porte d’approbation. Les modifications persistantes sont réalisées via une demande de tirage dans le référentiel IaC, tel que CloudFormation, plutôt que par une modification directe en temps réel. Dans les deux cas, le processus de révision existant de l’entreprise demeure le système de référence pour ce qui a changé et pourquoi. logIQ ne remplace pas ce processus. Il lui fournit l’information nécessaire pour agir plus rapidement

Mise en œuvre technique

• Une alerte est déclenchée par n'importe quel outil de surveillance, y compris Splunk, Datadog, New Relic, Grafana ou PagerDuty
• L'alerte est livrée sous forme de HTTP POST à un point de terminaison webhook. Les sources indirectes transitent d'abord par Amazon SNS et une fonction Lambda de signature, afin que chaque événement atteignant le point de terminaison soit authentifié
• Le webhook remet l'information à DevOps Agent, qui interroge Amazon CloudWatch, AWS CloudTrail et Amazon OpenSearch, ainsi que des outils d'observabilité externes connectés comme Splunk, puis il établit une corrélation des symptômes avec l'historique des validations dans Git
• DevOps Agent construit une topologie en direct des ressources affectées et produit une constatation structurée avec un plan de remédiation recommandé
• La constatation passe par Amazon EventBridge, puis via Lambda jusqu'à l'agent de remédiation logIQ
• Pour une défaillance connue, l'agent de remédiation déclenche un runbook d'automatisation SSM, qui s'exécute derrière une étape d'approbation
• Pour un changement d'infrastructure persistant, l'agent de remédiation ouvre une demande de tirage contre le dépôt IaC, tel que CloudFormation, gardant le changement à l'intérieur des contrôles de déploiement existants
• Pour un incident nouveau, l'agent de remédiation envoie les constats complets et le plan recommandé à l'ingénieur de garde via Amazon SNS. Chaque incident, y compris ceux nécessitant une intervention humaine, commence avec du contexte plutôt qu'une enquête vierge

Architecture technique et services AWS

Services AWS utilisés dans la solution :

• Amazon SNS : Reçoit et transmet les alertes provenant de sources de surveillance indirectes dans le pipeline de détection
• AWS Lambda : Signe les événements webhook entrants et achemine les résultats structurés de l’enquête vers la remédiation
• Agent AWS DevOps : Effectue l’enquête automatisée, interroge les journaux, les métriques et la topologie, puis corrèle les constats avec l’historique des déploiements
• Amazon CloudWatch : Fournit les métriques et la télémétrie opérationnelle utilisées lors de l’enquête
• AWS CloudTrail : Fournit l’historique de l’audit et de l’activité API utilisé pour identifier les changements récents
• Amazon OpenSearch : Permet la recherche et la corrélation des journaux à travers l’environnement affecté
• GitHub / GitLab (intégrations natives) : Fournissent l’historique des commits et des déploiements utilisé pour relier les symptômes à un changement précis
• Amazon EventBridge : Achemine les résultats structurés de l’agent d’enquête vers l’agent de remédiation
• Agent de remédiation logIQ : Associe chaque constat à l’un des trois parcours de remédiation encadrés et exécute la décision
• Automatisation AWS Systems Manager (SSM) : Exécute des runbooks préautorisés et validés pour les types de pannes connus, derrière une étape d’approbation
• Répertoire Infrastructure as Code (CloudFormation) : Reçoit les demandes de fusion pour les changements d’infrastructure persistants, en les maintenant dans les processus de révision existants

Valeur pour les utilisateurs :

• Cessez de payer la taxe de triage à chaque incident : les enquêtes débutent en quelques secondes après une alerte, en corrélant automatiquement les journaux, l’historique de déploiement et l’état des ressources en temps réel, remplaçant ainsi les 45 à 90 minutes de triage manuel typiques d’un incident P2
• Résolvez plus rapidement, avec moins de variabilité : les classes d’échec connues suivent des guides d’intervention (runbooks) pré-rédigés et validés, éliminant la variabilité liée à l’ingénieur qui prend en charge un incident donné
• Contrôle des changements jamais contourné : les modifications persistantes de l’infrastructure passent par une demande de fusion (pull request) plutôt qu’un changement direct, ainsi chaque modification passe tout de même par le processus de révision sur lequel l’organisation s’appuie déjà
• Séparation claire entre investigation et action : l’enquête et la correction sont effectuées sous des rôles distincts, des seuils d’approbation sont intégrés au processus d’exécution et chaque action est consignée
• Couverture qui s’élargit avec le temps : lorsqu’un·e ingénieur·e résout un incident inédit, cette solution devient un guide d’intervention potentiel, ce qui fait croître continuellement l’ensemble des classes d’échec que logIQ peut corriger automatiquement

Appel à l'action : Aucun incident ne devrait jamais commencer à froid !

• Évaluer en quelques jours : Un examen rapide des sources d’alerte actuelles, de la charge de garde et des classes de défaillance récurrentes produit une liste priorisée de candidats pour une couverture automatisée
• Piloter rapidement : Une preuve de concept effectuée sur des scénarios de défaillance représentatifs de votre environnement valide la précision de l’investigation et la sécurité de la correction avant un déploiement plus large

« De l’alerte à l’action : détecter, enquêter, remédier. »

• Détecter : Accepter les alertes provenant de tout outil de surveillance via un seul point d'entrée webhook authentifié
• Enquêter : Corréler les journaux, la topologie et l’historique de déploiement en un constat structuré, automatiquement, à chaque alerte
• Remédier : Acheminer chaque constat vers une action régie, qu'il s'agisse d'un runbook validé, d'une demande de fusion ou d'un transfert complet à un ingénieur, sans jamais contourner les contrôles existants avec une modification active non révisée

Les entreprises et les partenaires AWS peuvent faire appel à HCLTech pour planifier une présentation ou une démonstration de logIQ et découvrir comment une capacité DevOps agentique peut réduire le MTTR sans aucun compromis sur la gouvernance

Étiquettes : DevOps, gestion des incidents, AIOps, IA agentique, Agent DevOps AWS, analyse des causes fondamentales, automatisation SSM, infrastructure sous forme de code, réduction du MTTR, GitOps