17 200 magasins de proximité, du carburant, des bornes de recharge, 27 pays. Et une équipe DevOps qui reçoit désormais dans Slack un résumé d’incident en moins de quinze minutes de moyenne. Circle K n’est pas une société d’infogérance, c’est une chaîne de magasins. C’est exactement pour ça que son cas vaut le détour : le triage automatique d’incidents n’est plus un joujou de labo réservé aux géants du logiciel.
Le tableau d’avant, l’équipe le décrit sans poésie. Une alerte tombe sur Grafana. L’ingénieur de garde passe de CloudWatch à OpenSearch, vérifie l’état des tâches ECS sur plusieurs comptes AWS, recroise les symptômes avec un runbook hébergé sur GitHub. Quatre outils, aucune synthèse, et la réparation qui attend. Le billet d’AWS parle d’un motif que « beaucoup d’équipes DevOps connaissent » : 45 à 60 minutes avant de pouvoir commencer à réparer.
La chaîne montée par Circle K avec Marek Klatowicz, Cloud DevOps Engineer chez le groupe, est d’une banalité assumée. Grafana publie sur SNS, SNS pousse dans SQS, une Lambda dépile la file et déclenche un Flow Bedrock. À l’intérieur, deux agents tournent en parallèle. Le premier fouille l’infrastructure sur plusieurs comptes organisés avec AWS Organizations : tâches ECS, santé des cibles derrière le load balancer, métriques et logs CloudWatch. Le second interroge les traces applicatives dans Amazon OpenSearch Service. Bedrock Knowledge Bases se charge de l’ingestion et de la recherche dans les fiches produit internes, ce qui évite de monter une base vectorielle à côté.
Résultat annoncé : moyenne de triage sous les 15 minutes, soit 67 à 75 % de réduction.
Maintenant, la partie que le communiqué ne crie pas. Cette fourchette s’appuie sur les métriques internes de réponse aux incidents de l’équipe, dit le texte noir sur blanc. Le 45 à 60 minutes, lui, n’est pas présenté comme la mesure d’avant chez Circle K, mais comme le motif générique que connaissent les équipes DevOps. Les deux chiffres ne sortent ni de la même paire de dates ni du même instrument. Tu peux les trouver crédibles, tu peux t’en servir pour un business case, mais tu ne tiens pas un protocole expérimental.
Deuxième détail, plus gênant : le chrono s’arrête au moment où la réparation commence. Le système livre du contexte actionnable, il est déployé, la mesure est faite. Rien dans le billet ne dit si la panne est résolue plus vite, ni si le taux d’escalade baisse. Gagner une heure de diagnostic à 3 h du matin, c’est déjà énorme pour l’humain de garde. Ce n’est pas la même promesse que « nos incidents durent moins longtemps ».
Flows retourne à l’atelier, AgentCore prend la main
Le vrai signal pour ceux qui construisent, c’est la migration. L’équipe a d’abord tout câblé sur Amazon Bedrock Flows, l’orchestrateur visuel, avant de passer à Bedrock AgentCore. Le billet raconte les deux architectures, l’initiale et celle d’arrivée, sans jamais commenter le déménagement.
Le graphe dessiné à la souris tient la route au démarrage, moins quand le nombre de services et d’alertes grimpe. AgentCore, présenté comme une plateforme pour construire, connecter et optimiser des agents à l’échelle avec n’importe quel framework ou modèle, récupère l’exécution. Si tu bricoles encore tes enchaînements dans Flows en te persuadant que c’est l’état de l’art maison, un client d’AWS vient de changer d’adresse.
L’autre arbitrage, c’est le classique faire ou acheter. L’équipe a évalué des frameworks d’agents open source auto-hébergés. Ce qui a tranché n’est pas technique : héberger les modèles, versionner les prompts, orchestrer les outils et tenir les contrôles de sécurité, ça se paie en personnes. Circle K tournait déjà sur AWS, avec ses politiques IAM, ses VPC et ses pipelines de logs, donc Bedrock s’est branché dessus. Ce n’est pas un réquisitoire contre l’open source, c’est le constat qu’une équipe DevOps de chaîne de magasins n’a aucune envie de devenir hébergeur de modèles. Le coût de sortie, lui, ne figure sur aucune slide.
Un point à retenir si tu envoies des logs de production dans un LLM : Amazon Bedrock ne partage pas les données client avec les fournisseurs de modèles et ne s’en sert pas pour l’entraînement. Pour des logs qui charrient des détails d’infrastructure et parfois des données sensibles, c’était la condition d’entrée.
Le même jour, l’ingénieur qui garde la main
AWS a publié un second billet le 2 novembre, sur un assistant d’ingénierie aérospatiale qui évalue des substitutions de composants obsolètes. Le décor change : sept roues de réaction (0,003 à 5,0 Nms de moment cinétique) d’un fabricant fictif, AnyCompany, avec cinq notebooks Jupyter en libre-service.
L’architecture, elle, cause. Un planificateur (Claude Haiku 5.5) route le boulot vers trois agents spécialisés (Claude Sonnet 5.5), et un superviseur (Claude Opus 5.5) synthétise dès que plusieurs spécialistes ont tourné. Trois paliers de modèles pour une seule question d’ingénieur. Amazon Nova Multimodal Embeddings range photos produit, courbes de couple et texte dans le même espace vectoriel, ce qui permet d’interroger un graphique comme on interroge un paragraphe. Pour la recherche par image, l’agent tape directement dans un index S3 Vectors, parce que l’API de retrieval des knowledge bases managées n’accepte pas d’image en entrée. Une chaîne fixe (Knowledge, Evaluation, Supervisor) rédige ensuite le document d’évaluation d’impact formel, l’IIA.
La règle de conception annoncée mérite d’être encadrée : « l’ingénieur prend toutes les décisions, le système assemble les preuves pour lui ». Aucune substitution approuvée par la machine. Sur une pièce critique pour un vol, c’est le minimum syndical. Sur un dataset inventé et sept références, c’est aussi facile à écrire qu’à tenir.
Deux billets, deux métiers, une seule règle répétée : la machine fouille et rédige, l’humain tranche. Le jour où AWS publiera l’inverse sans glisser « garde-fou » ni « validation humaine » dans le texte, on saura que quelque chose a réellement bougé. En attendant, Circle K a gagné du temps sur le fait de comprendre, pas sur le fait de réparer. C’est déjà ça, mais ce n’est pas la même facture.
Sources :
Comments are closed