Build log. Ce qui a été livré, semaine après semaine.

Un seul agent du constat à la pull request

Chaque constat que Polylane détecte est maintenant traité par un seul run d’agent. Il lit les preuves avec des outils en lecture seule sur ta télémétrie et le graphe de contexte, décide s’il y a une vraie issue, et quand la cause confirmée est un défaut de code dans un dépôt connecté, il écrit le correctif et ouvre la pull request dans le même run, sans passation entre les étapes de triage, d’enquête et d’autofix. La pull request s’ouvre sur une ligne Affected nommant la ressource, la valeur en dépassement par rapport à sa baseline et le nombre de dépendants qu’une panne atteint, et son raisonnement de sécurité se trouve dans une section visible Why it’s safe. Quand un correctif est hors de portée, le run consigne la raison et une prochaine étape claire sur l’issue au lieu de s’éteindre sans suite.

Grafana Cloud et Logfire rejoignent les intégrations d’observabilité

Connecte Grafana Cloud, ou un Grafana auto-hébergé, avec une URL de stack et un token de compte de service. Polylane ajoute un point de contact et une route de notification fourre-tout à la stack, chaque règle d’alerte existante et chaque règle que tu créeras plus tard lui parvient donc sans configuration par règle. Connecte Pydantic Logfire avec une clé API et l’agent reçoit des outils pour aller d’une route en échec au span exact qui a levé l’erreur, plus du SQL en lecture seule pour tout le reste ; le projet est surveillé pour le taux d’erreurs, le volume de requêtes et la latence p95 comme les autres fournisseurs.

Aussi cette semaine :

• Les issues rejetées ont droit à un second regard : un constat récurrent est trié à nouveau, un rejet est refusé quand les preuves n’excluent pas un incident sur une ressource critique, et un « pas d’incident » venant d’une personne reste définitif
• Connecter GitHub demande une seule fois s’il faut relire les pull requests, et une pull request qui corrige une issue connue reçoit un verdict vert ou jaune sur le fait qu’elle devrait la résoudre
• Un onglet Key questions sur chaque compte cloud, intégration et ressource surveillée de près montre les questions que Polylane pose à ta télémétrie, avec la requête de fournisseur derrière chacune
• Le graphe de contexte gagne les réplicas en lecture RDS et RDS Proxy, relie les dépôts aux charges de travail Kubernetes et Railway qui exécutent les images qu’ils construisent, et nomme les buckets S3 et les points d’accès RDS trouvés dans les variables d’environnement avant même que le compte AWS soit connecté
• La boîte de dialogue de connexion AWS montre le template CloudFormation généré avec copie et téléchargement, et il-central-1 est disponible
• Les tendances quotidiennes des logs sont enregistrées comme issues triées au lieu d’arriver par e-mail
• Colle ou dépose des images dans le composeur de chat de la console, et les vérifications ont leur propre page avec un lien à copier
• Les réponses Slack se terminent par la durée du run et le nombre d’actions effectuées, et le serveur MCP affiche un écran de consentement avant d’autoriser un client
• La CLI connecte Grafana Cloud, Mixpanel et OpenStatus avec polylane integration connect et Railway avec polylane cloud connect --provider railway, et demande s’il faut relire les pull requests lors de la connexion de GitHub (--no-pr-reviews pour refuser)
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Trois clouds de plus et ton gestionnaire de tickets rejoignent le graphe de contexte

Tu peux maintenant connecter ClickHouse Cloud, Convex et Turso : colle un token et leurs services, projets, déploiements et bases de données se synchronisent dans le graphe de contexte toutes les 15 minutes, avec des vérifications de santé et des outils d’agent. Linear est la première intégration de gestion de tickets : l’agent lit tes équipes, tes projets et tes tickets dans n’importe quel thread, crée des tickets depuis les enquêtes avec la trace des preuves jointe, et met à jour l’état, la priorité ou l’assignation, en te demandant confirmation avant chaque écriture. Les nouvelles ressources arrivent déjà câblées : les services ClickHouse secondaires sont reliés à leur primaire, les branches Turso à la base dont elles sont issues, et les services auth, storage, realtime et REST de Supabase à la base Postgres qu’ils desservent, une panne sur le primaire atteint donc tout ce qui en dépend.

Un seul rayon d’impact, partout

Le moteur de rayon d’impact derrière les revues de pull requests répond maintenant partout : les panneaux latéraux d’issues, les enregistrements de changement et les artefacts de threads montrent la même portée en aval, les agents peuvent la demander, et chaque pull request d’autofix nomme le niveau de la ressource affectée et ce qu’une panne à cet endroit atteindrait. Le graphe qu’il parcourt est plus dense : les distributions CloudFront sont reliées à leurs origines et à leurs web ACL WAF, les règles de security groups deviennent des arêtes d’accessibilité, les buckets R2 sont reliés aux files qu’ils notifient, et les définitions Step Functions produisent une arête pour chaque service qu’elles appellent. Un nouvel onglet Connections sur chaque ressource liste chaque arête avec sa direction, la façon dont elle a été découverte et les preuves derrière elle.

Aussi cette semaine :

• Une seule connexion AWS couvre maintenant n’importe quel ensemble de régions, ou toutes, avec CloudTrail et les alertes par région
• Les pull requests d’autofix demandent une revue au responsable de la ressource affectée, utilisent Conventional Commits par défaut, incluent un diagramme mermaid quand le correctif a une structure à montrer, et deviennent obsolètes après 14 jours sans activité pour qu’un meilleur correctif ne soit plus retenu
• Tu peux fixer un seuil de sévérité pour les enquêtes que Polylane démarre tout seul, par espace de travail ; les nouvelles alertes sont triées par un agent avec des outils en lecture seule avant de devenir des issues, et les enquêtes bloquées reprennent toutes seules
• Les cartes d’hypothèses dans un thread indiquent Confirmed, Refuted ou Inconclusive, et un thread qui attend ta réponse le dit
• Dis à l’agent Slack de s’en aller et il met le thread en sourdine jusqu’à ce que tu le @-mentionnes à nouveau ; la page Channels liste maintenant chaque canal de ton espace de travail avec un bouton Join pour ceux où Polylane n’est pas
• La page de topologie se met à jour en direct, sa recherche est en texte intégral sur les noms, alias et descriptions, et tout graphique dans un thread se télécharge en JSON, CSV ou PNG
• Chaque rapport épinglé à un board Mixpanel devient une vérification quotidienne
• Les runs d’autofix utilisent Node 24 et prennent la version depuis .nvmrc, .node-version ou engines.node
• La CLI connecte ClickHouse, Convex, Turso et Linear, lance la connexion AWS en arrière-plan pour que tu puisses connecter d’autres clouds en attendant, accepte --region all, et propose des canaux Slack à rejoindre juste après la connexion de l’app
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Construis ton graphe de contexte depuis le terminal avec ton propre agent de codage

Lance polylane map et la CLI démarre l’agent de codage que tu utilises déjà pour cartographier le dépôt courant : la topologie, les premières issues et un thread de premier run atterrissent dans ton espace de travail pendant que le terminal affiche un battement de cœur. Ta machine et son agent sont maintenant une connexion comme GitHub ou AWS, chaque machine écrit donc sa propre tranche du graphe et aucune ne peut écraser celle d’une autre. Pendant la cartographie, la page Topology montre la progression, les issues et le chat sur place, propose de connecter tes clouds en attendant, et te donne un lien de partage révocable. Connecter un agent de codage cloud en fait ton exécuteur d’autofix, et le serveur MCP de Polylane lui est ajouté automatiquement pour qu’il puisse interroger Polylane pendant qu’il écrit un correctif.

Railway, Mixpanel et OpenStatus rejoignent le graphe de contexte

Railway est un fournisseur cloud connectable : connecte-toi avec OAuth ou un token d’espace de travail et Polylane synchronise projets, services et déploiements, surveille les deploys, lit les logs et vérifie les métriques des services à la recherche d’issues. Mixpanel est la première intégration d’analytique produit, tu peux donc demander si les inscriptions ont chuté après un deploy, et une vérification quotidienne surveille les volumes d’événements pour repérer les ruptures de tracking. OpenStatus amène les moniteurs et les pages de statut dans le graphe, trie chaque panne et chaque rétablissement comme une alerte, et relie chaque moniteur à la ressource qu’il sonde. Datadog, Sentry, Better Stack, Honeycomb et Axiom relient maintenant sur le graphe les ressources qui leur rapportent, et l’agent peut publier des rapports de statut Better Stack et acquitter ou résoudre des incidents, chaque action derrière ta confirmation.

Aussi cette semaine :

• Connecter un compte cloud ou une intégration d’observabilité enregistre des issues tout seul : Polylane lit les 24 dernières heures de logs d’erreur à la recherche de motifs récurrents et lance les premières vérifications immédiatement
• Les revues de pull requests portent un registre de chaque mode de défaillance envisagé, marqué confirmé, plausible ou réfuté, avec un rayon d’impact nommant les ressources en aval qu’une panne atteint et la part de trafic qu’elles portent ; l’onglet Changes l’affiche nativement
• Les issues sont plus faciles à trier : une colonne et un filtre de sévérité, les doublons masqués par défaut, et l’alerte qui a ouvert une issue affichée au début de sa lignée
• Les pull requests d’autofix montrent leur diff complet dans un panneau latéral, rapportent leur résultat au thread qui les a demandées, et ne livrent plus une limite ou un délai relevé comme correctif
• Les réponses Slack joignent les graphiques sous forme d’images, et un long tour Slack renvoie vers la console pour que tu puisses suivre
• Connecte des serveurs MCP qui s’authentifient avec des en-têtes HTTP personnalisés, pas seulement un bearer token
• La recherche dans le graphe d’infrastructure bascule sur un tableau pour que les résultats se lisent en lignes
• La CLI connecte plusieurs clouds à la fois avec --multi, précochés d’après les marqueurs de ton dépôt, restreint le sélecteur avec --category observability, et ouvre dans ton navigateur une page de token Cloudflare en lecture seule préremplie
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Chaque issue reçoit une cause, et une réponse assortie

Polylane classe maintenant la raison de chaque issue : un défaut de code, une infrastructure instable, un client externe, un comportement attendu ou inconnu, chacun avec un niveau de confiance, et répond en conséquence. Un défaut de code reçoit un correctif. Un échec de CI instable reçoit une demande de relance du workflow plutôt qu’un patch, et une relance réussie résout l’issue toute seule. Un comportement attendu est rejeté ou sa signature d’alerte est mise en silence avec la raison consignée, et tout ce qui est incertain va à une personne. La page de l’issue montre le verdict, chaque décision et qui l’a prise, et les preuves derrière un dépassement : la métrique qui dévie, les lignes de log causales et la trace.

Tu décides quand l’autofix tourne

Un interrupteur Open autofix pull requests se trouve maintenant sur l’espace de travail et sur chaque dépôt, et un nouveau mode Ask first retient chaque correctif déclenché par la machine comme un run en attente jusqu’à ce que tu cliques sur Approve and run ; les correctifs que tu demandes dans un thread ne sont jamais retenus. Tout autofix en cours peut être annulé avant l’ouverture de sa pull request, depuis la console, le chat ou Slack. Les pull requests portent un label severity: et s’ouvrent sur ce qui a causé le correctif : la ressource affectée, la métrique en dépassement et les lignes de log qui se sont déclenchées. Chaque patch passe une revue de sécurité des données, un patch qui enverrait de nouvelles données vers les logs, les exports ou l’analytique est donc révisé ou retenu.

Aussi cette semaine :

• Connecter GitHub ouvre maintenant une première pull request en moins d’une minute, qui ajoute les instructions Polylane à AGENTS.md, aux règles Cursor et à tes autres fichiers d’instructions d’agent, la pull request d’observabilité suivant ensuite, annulable depuis la console
• Un e-mail quotidien de tendances des logs n’arrive que les jours où quelque chose a changé, comme un nouveau modèle d’erreur ou un service qui logge bien au-dessus de son volume normal, chacun avec un bouton Investigate
• Demande à l’agent de surveiller un run de CI ou une release et il cesse d’interroger en boucle, se réveillant quand l’événement GitHub arrive
• Les signaux récurrents intentionnels reçoivent un correctif qui rend le comportement explicite dans ton code plutôt qu’une alerte mise en silence, et les issues d’alerte qui deviennent silencieuses se résolvent toutes seules
• L’agent Slack parle à la première personne, et les images qu’on lui envoie dans Slack s’affichent maintenant dans la console
• Le chat de la console replie chaque phase de réflexion et ses appels d’outils en une seule ligne, propose une pastille Quick answer après 30 secondes, et Try again après une réponse interrompue
• Les nœuds de lignée s’affichent en aperçu au survol et se parcourent au clavier, les services externes comme googleapis.com reçoivent un wiki, et les mouvements d’autoscaling n’encombrent plus le fil des changements
• Le menu d’apparence gagne une option System
• La CLI gagne polylane scan, qui trouve les risques clés dans tes comptes connectés et te laisse en choisir un pour enquêter, et polylane autofix watch, qui affiche les URL des pull requests au fil de leur ouverture, et les assistants de connexion nomment les permissions de token exactes de chaque fournisseur
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Modal et Supabase rejoignent le graphe de contexte

Colle la paire de tokens que Modal fournit pour la connexion en CLI et tes environnements, apps, fonctions, sandboxes, volumes et files apparaissent dans le graphe de contexte, avec les logs des apps lus dans un digest, des vérifications de coût et de volume d’erreurs qui ouvrent des issues, et chaque dépôt relié à l’app sur laquelle sa CI lance modal deploy. Connecte une organisation Supabase via OAuth ou un token d’accès personnel et les bases de données, edge functions, branches, buckets, auth et stockage de chaque projet se synchronisent toutes les 15 minutes, avec des dashboards, des logs et des vérifications sur chacun. L’agent reçoit des outils en lecture seule pour les deux, une enquête lit donc ce que Modal ou Supabase fait maintenant plutôt que ce que la dernière synchronisation a enregistré.

Parler à l’agent pendant qu’il travaille

Envoyer un message en plein tour annulait le tour et jetait des minutes de travail. Maintenant le composeur reste actif : ton message est pris en compte à la prochaine étape de l’agent et affiché dans la transcription à l’endroit où il a été lu. Un message qui n’arrive jamais le dit, avec une option pour réessayer. Arrêter et envoyer partagent un seul bouton, Esc arrête le tour, et en voix l’agent cesse de répondre à la question que tu as interrompue.

Aussi cette semaine :

• L’agent Slack publie des cartes Approve et Deny quand un changement a besoin d’une validation, montre sa liste de tâches dans son message de statut, et ferme une pull request qu’il a ouverte quand tu le lui demandes
• Réagis avec une coche sur une carte d’incident dans Slack pour le résoudre, ou avec un sens interdit pour le marquer comme pas d’incident ; la carte se met à jour sur place et la chronologie enregistre qui a agi
• Un onglet Channels sur l’intégration Slack liste chaque canal où Polylane se trouve, et l’agent enregistre lui-même les instructions d’un canal quand tu lui dis comment s’y comporter
• Les pull requests d’autofix s’ouvrent sur une section Avant / Après rédigée d’après le diff, un onglet Implementation montre le thread qui a écrit le patch, et un plan faible est rejeté avant de coûter un run
• Polylane vérifie qu’il n’y a pas déjà une pull request ouverte avant de dépenser une enquête, et conserve le travail d’un tour d’autofix lent au lieu de le jeter
• Les revues de pull requests s’activent ou se désactivent par dépôt depuis la page Repositories, en masse, ou pour toute une intégration GitHub avec un seul interrupteur
• Les cartes publiées te donnent maintenant un lien en deux minutes environ, sous forme de brouillon qui s’affine à la même URL, avec les problèmes listés à côté du graphe et un bouton Investigate sur chacun
• L’inscription crée tout de suite un espace de travail pour toi, l’adhésion automatique par domaine est désactivée par défaut, et un lien vers un espace de travail dont tu n’es pas membre propose un écran de demande d’accès
• La CLI t’inscrit avec Google, GitHub ou e-mail via polylane auth signup, rend polylane cloud connect et polylane integration connect interactifs, et polylane setup configure maintenant Cline, Roo Code, Goose, Pi et Warp
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Les échecs de CI deviennent des issues, des enquêtes et des correctifs

Chaque run GitHub Actions en échec sur un dépôt connecté devient maintenant une issue Polylane. Les échecs répétés d’un même workflow se replient en une seule issue ; un run vert la résout et un échec dans les 24 heures la rouvre. Le triage lit les jobs, les étapes et les annotations de vérification en échec, et quand il confirme un vrai problème, il démarre une enquête et met un autofix en file contre la branche fautive. Le correctif arrive comme une pull request d’autofix normale.

Suivre la chaîne de la vérification à la pull request

Chaque issue, enquête, autofix et vérification connaît maintenant ses voisins. Un graphe de lignée sur l’onglet Overview de l’issue dessine toute la chaîne, de la vérification qui l’a levée à l’enquête, puis à l’autofix et sa pull request. Cliquer sur n’importe quelle carte l’ouvre dans un panneau latéral, et les issues en doublon pointent toujours vers la racine qui porte l’enquête. Les pages d’autofix s’ouvrent maintenant sur le résultat : la pull request, la raison pour laquelle le run a été sauté (avec un bouton Run anyway), ou la raison de son échec (avec Run again).

Aussi cette semaine :

• Publie une carte publique de ton architecture : lance le prompt de cartographie dans ton agent de codage et il publie une carte notée et versionnée que n’importe qui peut parcourir, interroger, ou depuis laquelle confier directement un problème à Polylane pour enquête
• Les commentaires de revue s’ouvrent sur View the full analysis : l’analyse complète, des graphiques interactifs et des extraits de logs entiers, lisibles par les lecteurs de la pull request via un lien invité ; les pull requests d’autofix relient tout leur run de la même façon
• Les revues montrent leurs preuves : un verdict validé joint la série de métriques ou l’extrait de log sur lequel il repose, le briefing liste les issues passées qui ont touché les mêmes ressources, et la vérification d’impact en production est maintenant activée par défaut pour chaque dépôt
• Après une enquête, Polylane demande si un signal manquant l’a rendue plus difficile ; si oui, une pull request de suivi ajoute exactement ce logging ou ce tracing, en commençant par l’enquête qu’il aurait raccourcie
• Deux nouvelles connexions : les clusters Kubernetes via un agent en lecture seule dans le cluster, aucun kubeconfig ne quitte donc le cluster, et Better Stack, dont les incidents entrent dans le triage et dont l’agent peut interroger les moniteurs
• Les services externes que ton code appelle (Stripe, Datadog, etc.) rejoignent le graphe de contexte à partir des URL des variables d’environnement, sous leur propre catégorie External services, et un graphe de 3 000 ressources s’ouvre maintenant en quelques secondes
• Dans les threads à plusieurs personnes, l’agent sait qui a dit quoi, et chaque mémoire qu’il enregistre est revérifiée chaque jour puis modifiée ou supprimée quand elle devient obsolète
• Les admins peuvent exporter un espace de travail en archive JSON, et supprimer un espace de travail le met d’abord en quarantaine, avec une fenêtre de 60 jours avant la purge
• L’allocation mensuelle de tokens de chaque forfait est cinq fois plus grande, plus aucun forfait ne plafonne les membres de l’espace de travail, et un nouveau réglage Privacy & data permet aux admins d’exclure l’espace de travail de l’entraînement des modèles
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Polylane est un coéquipier dans Slack

Mentionne Polylane dans Slack et il réagit tout de suite, montre qu’il réfléchit et diffuse sa réponse au fil de l’écriture. Les longs tours affichent une progression en direct, et un run échoué dit ce qui s’est passé et comment reprendre au lieu de se taire. Polylane apparaît dans l’onglet Agents de Slack avec des prompts suggérés, et dans les canaux dont il fait partie, il rejoint sans y être invité les conversations où il peut aider, sauf si tu règles un canal en mention seule. Quand un autofix démarre depuis un thread Slack, ce thread entend la suite : le lien de la pull request, les échecs de CI et leurs correctifs, les réponses aux revues, et une réaction quand elle est fusionnée.

Des issues attrapées d’après ce que disent tes logs

Polylane lit maintenant ce que disent tes logs, pas seulement leur tendance. Un flux régulier de plantages qui n’a jamais franchi un seuil ni bougé une baseline est enregistré comme une issue, reste ouvert tant que l’erreur continue d’apparaître et se résout tout seul quand elle cesse. Chaque nouvelle issue est comparée aux issues ouvertes dans tout ton espace de travail : les doublons confirmés sont liés et partagent une seule enquête au lieu d’en démarrer une deuxième. Les lignes de log sont regroupées par forme, un format d’identifiant inconnu ne crée donc pas une nouvelle issue et ne fait pas osciller une issue existante.

Aussi cette semaine :

• Les revues de pull requests livrent maintenant des correctifs, pas seulement des verdicts : les petits trous d’observabilité dans les lignes que tu as changées arrivent en commentaires de suggestion en un clic, les plus gros en pull request d’amélioration empilée sur ta branche, et ni l’un ni l’autre ne change le verdict validé ou refusé
• Les revues et les pull requests d’autofix vérifient tout le catalogue des dangers de déploiement : les renommages puis suppressions que d’anciens pods lisent encore, les CREATE INDEX bloquant les écritures sur des tables très sollicitées, les variables d’environnement que rien ne provisionne, et les prérequis dans le système de quelqu’un d’autre, chacun listé avec un responsable jusqu’à sa prise en compte
• Les personnes et les équipes rejoignent le graphe de contexte : CODEOWNERS, les auteurs de deploys et les tags de responsable deviennent des nœuds personne et équipe avec des arêtes owns, et les différentes orthographes d’une même personne se résolvent en un seul nœud
• Chaque dépôt nouvellement connecté reçoit une pull request d’autofix d’observabilité écrite dans les conventions propres du dépôt, et les descriptions des pull requests d’autofix s’ouvrent maintenant sur un résumé en langage clair
• View Thread sur un commentaire de revue ouvre l’enquête en lecture seule pour quiconque peut voir la pull request, sans compte, et tu reçois une notification quand un verdict change
• Le graphe d’infrastructure est de nouveau une hiérarchie de haut en bas, regroupée par compte cloud, et dans la vue topologie tu peux maintenir une ressource pour voir son rayon d’impact se propager le long de ses arêtes, ou en faire glisser une pour entraîner ses voisines
• La page Autofixes a une recherche et des filtres qui vivent dans l’URL, et modifier une ligne ne redessine plus le tableau
• Les espaces de travail Free ont droit à 10 enquêtes par jour, contre 1 auparavant
• La CLI gagne polylane setup, qui enregistre le serveur MCP et le skill de Polylane auprès de chaque agent de codage de ta machine (--agent en choisit un)
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Chaque pull request, relue pour son impact en production

Polylane lit maintenant chaque pull request et répond à une seule question : la production se dégrade-t-elle quand ceci est fusionné ? Il parcourt le graphe de contexte du dépôt jusqu’aux ressources sur lesquelles le code est livré, vérifie le changement face à la topologie et à la télémétrie réelles, et commente son verdict sur la pull request : validé ou refusé, avec les preuves et les ressources affectées jointes. Une vérification « Polylane production impact » peut être rendue obligatoire dans la protection de branche pour bloquer une mauvaise fusion.

Les pull requests d’autofix acceptent les retours

Laisse un commentaire de revue sur une PR d’autofix et Polylane répond ou pousse le changement demandé. Réponds dans le thread Slack où la PR a été annoncée et il répond directement là. Quand la CI échoue sur une branche d’autofix, Polylane diagnostique les vérifications échouées et pousse un correctif sans qu’on lui demande. Et quand il écrit du code, il suit tes règles maison : AGENTS.md, CLAUDE.md, les règles Cursor, et la convention de messages de commit qu’il déduit de ton historique git.

Aussi cette semaine :

• Les dépôts ont rejoint le graphe de contexte : Polylane lit Terraform, CloudFormation, Pulumi, CDK et les manifestes de déploiement (wrangler.jsonc, fly.toml, vercel.json, render.yaml) pour relier chaque dépôt aux ressources qu’il déploie, avec un onglet Resources pour les liens manuels
• Tu peux orienter les revues par dépôt avec tes propres instructions, « ne jamais signaler les migrations de schéma » par exemple, et quand un push ultérieur répond à un point signalé, Polylane le marque résolu tout seul
• Les risques clés des rapports font l’objet d’une enquête, pas seulement d’une liste : clique sur l’un d’eux, ou enquête sur tous, et les verdicts arrivent en direct, les risques confirmés remontant en tête avec un résumé de ce qui a été trouvé
• La topologie est maintenant la porte d’entrée de la console : chaque ressource est un point, coloré par catégorie et dimensionné par niveau, avec les points chauds d’issues qui pulsent en rouge et les ressources les plus modifiées entourées d’un anneau en pointillés
• PlanetScale est maintenant un fournisseur : connecte-toi avec OAuth, les bases de données et les branches se synchronisent dans le graphe de contexte, et Query Insights pilote des vérifications automatiques pour les erreurs de requêtes, la latence p99, les pics de latence et l’effondrement du volume de requêtes
• Les nouveaux comptes cloud démarrent en lecture seule : chaque écriture via l’API du fournisseur est refusée jusqu’à ce qu’un admin bascule l’interrupteur, compte par compte
• La synchronisation Vercel a gagné neuf types de ressources (sandboxes, workflows, crons, feature flags, AI Gateway, microfrontends, groupes d’accès, drains, registre de conteneurs), et les rollbacks sont correctement suivis : Polylane suit le déploiement qui sert réellement la production, pas le plus récent
• Le graphe de contexte s’est densifié : les tunnels Cloudflare sont reliés aux zones et aux services d’origine qu’ils desservent, Hyperdrive passe par les tunnels, et les variables d’environnement en forme d’URL deviennent des arêtes entre clouds et comptes
• Chaque dépôt porte un score d’instrumentation sur 100 (routes sans logging, appels console nus, capture d’erreurs manquante), et les ressources qui servent du trafic sans logger ou qui deviennent soudain silencieuses sont signalées
• Les logs ont gagné une mémoire : chaque ressource tient un registre de ses motifs récurrents avec leurs taux historiques, et les issues montrent les requêtes en échec avec les lignes de log exactes qui leur appartiennent
• Les réponses Slack sont plus serrées : une réponse par tour, un formatage et des @-mentions corrects, et le silence quand un message n’est pas pour l’agent
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Ton agent de codage peut maintenant voir tout ce que Polylane voit. Les outils que Polylane a construits pour ses propres agents : le graphe d’infra en direct sur tous tes clouds, les requêtes d’observabilité vers chaque fournisseur connecté, la recherche de code dans tes dépôts, toute l’API REST, sont désormais exposés à Claude Code, Cursor, Codex, OpenCode et VS Code via un seul serveur MCP, ou la CLI. Un seul point d’accès, une connexion par navigateur, et ton agent répond à « qu’est-ce qui a planté en production pour le service que cette PR touche ? » sans quitter l’éditeur. Les écritures passent par une politique de refus par défaut, et la fusion reste humaine.

Les écarts et les alertes ont disparu. Pas les signaux, la séparation : tout ce que Polylane détecte et chaque alerte que tes fournisseurs transfèrent atterrit maintenant au même endroit, sous forme d’issues. Une seule liste, un seul cycle de vie et une vraie déduplication : le même problème qui se déclenche cinquante fois est une issue avec un compteur d’occurrences, pas cinquante lignes. Les issues externes renvoient directement à l’alarme dans la console du fournisseur, et les automatisations peuvent maintenant se déclencher sur les verdicts de triage.

La supervision est devenue plus maligne sur ce qu’il faut surveiller. Pour chaque compte connecté, Polylane génère maintenant des questions de supervision : ce qu’un ingénieur on-call voudrait voir répondu en continu. Il lit tes dépôts pour trouver les logs d’erreur, les spans et les métriques personnalisées que tu as réellement écrits, transforme chaque question en requête de fournisseur, la valide sur des données réelles et exécute celles qu’il garde toutes les quelques minutes comme vérifications. Les séries liées partagent maintenant un graphique : p95 et p99 ensemble, les 5xx par service sur un même axe.

Aussi cette semaine :

• La console s’ouvre maintenant sur Home : résumé du fil, décisions en attente de toi, points chauds d’issues et de changements, et un panneau de bonnes pratiques listant les portes laissées ouvertes dans ton architecture
• Factory rejoint Cursor et Devin comme exécuteur d’autofix, les PR externes renvoient à l’enquête qui les a produites, et une PR fermée sans fusion est maintenant un résultat suivi
• La supervision est un interrupteur par ressource : désactive-la et Polylane continue d’enregistrer les changements sans ouvrir d’issues, et une carte de couverture montre exactement ce qui est surveillé et à quelle fréquence
• Métriques et logs Vercel : colle un token d’accès personnel (validé pendant la saisie) et choisis quelle télémétrie collecter
• Connecter AWS ne te laisse plus sur une page blanche : la console attend ta stack CloudFormation, bascule sur le compte dès qu’il se manifeste, et le dit clairement s’il ne le fait jamais
• Un digest hebdomadaire à l’échelle de l’espace de travail : un seul interrupteur envoie à chaque membre un résumé des incidents, issues, autofixes, changements et ressources inactives
• Les issues Sentry arrivent avec la vraie exception jointe avant le début du triage : type, message, principales frames de la pile et tags
• Un triage plus silencieux : la sévérité reflète l’impact en cours plutôt que le pire cas, et les vagues de sondes de bots contre wp-login.php et .env n’ouvrent plus d’incidents
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Les rapports ont grandi cette semaine. Ce que Polylane trouve dans un compte était un résultat jetable que tu regardais défiler ; c’est maintenant un rapport avec sa propre URL. Il y a une page de rapports avec filtrage et actions groupées, une progression en direct pendant qu’une revue tourne, la topologie et des questions de départ quand elle arrive, et un lien de partage public quand tu veux le montrer à quelqu’un hors de ton espace de travail. Ça fonctionne sur les comptes cloud et sur tes intégrations Datadog, Honeycomb, Axiom et Sentry.

Le fil a reçu le même traitement. Il s’ouvre maintenant sur un résumé à 30 jours de ce que Polylane a vraiment fait pour toi (issues attrapées, changements ayant causé des issues, PR d’autofix, écarts résolus, chacun avec une sparkline), un score de santé et un tableau « en attente de toi » des décisions qui exigent un humain. Et sous le capot, les threads d’incident sont passés sur des workflows durables, les enquêtes survivent donc aux deploys et aux redémarrages, et l’exécuteur d’autofix intégré fait maintenant tourner l’agent de codage open source pi, avec la transcription complète lisible derrière chaque PR.

Aussi cette semaine :

• Les webhooks de règles d’alerte et d’issues Sentry ouvrent maintenant des incidents : triés par un agent dès leur arrivée, avec des badges de statut et de verdict et une enquête en un clic
• Les écarts récurrents conservent les métriques, les logs et les traces capturés à chaque occurrence, consultables de la plus récente à la plus ancienne, au lieu de la dernière seulement
• Les pages d’écart s’ouvrent sur des cartes de métriques avec sparkline montrant la valeur, la baseline et la déviation, une vue du rayon d’impact et un résumé des logs
• L’historique des changements par ressource : des signaux de changement sur le panneau de détail de chaque nœud, et les ressources les plus modifiées remontées dans le fil
• Les advisories sont calculées côté serveur, chacune marquée comme corrigeable sur place ou avec des indications
• Fiabilité des threads : les tours obsolètes sont balayés automatiquement, les problèmes de capacité des modèles se replient proprement, et les tours qui s’emballent sont coupés au lieu de tourner en rond
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Personne ne veut mille lignes de logs brutes déversées au milieu d’une enquête. Cette semaine, chaque requête de télémétrie que les agents exécutent (CloudWatch, Datadog, Honeycomb, Axiom, Sentry, Cloudflare, Vercel, Fly, Render, X-Ray) a gagné un mode résumé : le résultat complet, non tronqué, est distillé en sévérité, nombre d’erreurs, motifs récurrents et la poignée de lignes qui valent vraiment la lecture, citées mot pour mot. Les threads restent lisibles, et l’agent cesse de noyer son propre contexte dans les logs.

Connecter un compte s’est aussi amélioré. Juste après la connexion, tu reçois maintenant un rapport structuré des risques classés, des métriques clés et des digests de logs et de traces, avec des questions de départ pour creuser. Et pour Cloudflare, une nouvelle fenêtre préremplit chaque permission dont Polylane a besoin et te laisse choisir entre lecture seule (enquêter et expliquer seulement ; les changements n’arrivent jamais autrement qu’en PR) et accès complet, pour que personne n’ait plus à choisir les permissions de token d’API à la main.

Aussi cette semaine :

• Les niveaux de ressources se reclassent automatiquement chaque jour, et tu peux maintenant surcharger le niveau de n’importe quelle ressource à la main (les surcharges sont épinglées) ou relancer la classification pour tout un compte
• Chaque écart dispose d’un bouton d’enquête en un clic qui ouvre un thread d’incident, avec une déduplication pour que le même écart n’engendre jamais de doublons
• Les questions de départ suggérées par l’IA apparaissent maintenant sur les changements, les évaluations de runs de vérification et les ressources individuelles, pas seulement après la connexion
• polylane automation create et POST /automations acceptent des déclencheurs, des instructions et des outils personnalisés, pour que tu construises des automatisations qu’aucun template ne couvre
• Un panneau latéral de run de vérification pour inspecter les métriques, les logs et les traces d’une seule évaluation, avec les actions d’enquête et de question intégrées
• La supervision par ressource collecte maintenant des preuves structurées : principaux et nouveaux modèles de logs, totaux par sévérité, taux d’erreurs et de fautes, et p50/p95/p99 par opération
• Une réparation en un clic pour les diagrammes Mermaid cassés dans les wikis de ressources
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Connecter un compte a enfin un vrai moment. Au lieu de te renvoyer sur un dashboard, Polylane t’amène maintenant sur une page qui explique ce qu’il voit dans le compte que tu viens de connecter, commence tout de suite à chercher des issues et propose trois questions sur mesure qui valent la peine d’être posées à l’agent. Les cinq premières minutes sont passées de « et maintenant ? » à une vraie conversation sur ton infrastructure.

L’autre thème de la semaine, c’est la confiance. Quand un agent veut effectuer une action qui modifie quelque chose, le thread te montre maintenant la méthode, le chemin, le corps et la raison, et attend ton approbation, les suppressions étant signalées comme destructrices. Et chaque incident déclare désormais où il en est à la fin de chaque tour d’agent (action humaine requise, décision requise, en attente d’un changement, échoué ou résolu), pour que tu voies d’un coup d’œil quelles enquêtes ont vraiment besoin de toi.

Aussi cette semaine :

• Chaque passe de supervision est enregistrée comme un run de vérification (sain, dépassé ou stable), ce qui donne à chaque ressource une chronologie d’évaluations que tu peux inspecter, plus un déclenchement manuel
• Les ressources sont automatiquement classées en niveaux 1 à 4 selon leur criticité opérationnelle, à partir de la topologie, du trafic et des changements récents ; les niveaux pilotent maintenant la priorisation des écarts
• La synchronisation AWS gagne Kinesis, KMS, Secrets Manager et Service Discovery
• Tu peux découvrir et relier des dépôts GitHub à un compte cloud, en rattachant le code à l’infra sur laquelle il tourne
• La limitation de débit et le regroupement des requêtes sont arrivés dans chaque client de fournisseur, les enquêtes ne sont donc plus ralenties par les API des fournisseurs
• Change intelligence rattache maintenant les événements de changement des fournisseurs aux ressources précises qu’ils ont touchées, affichées dans le fil
• Une vue glissante sur 24 heures de la consommation d’incidents par rapport aux limites de ton espace de travail
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité

Autofix s’est ouvert cette semaine. Tu peux maintenant connecter Cursor et faire passer les pull requests d’autofix par ses agents cloud plutôt que par l’agent intégré : quand une enquête aboutit à une ligne de code, Polylane passe le relais pour le correctif et Cursor ouvre la PR. Choisis un exécuteur par défaut par espace de travail dans Settings → Integrations.

Les automatisations sont aussi plus faciles à démarrer. Il y a désormais un catalogue de templates prêts à l’emploi, avec le déclencheur, les instructions de l’agent et les actions déjà câblés, installables en une étape depuis la console, la CLI (polylane automation from-template) ou l’API. Les templates se filtrent par catégorie et par fournisseur, et n’activent que les actions des fournisseurs que tu as réellement connectés. En parallèle, de nouveaux contrôles de triage te donnent un interrupteur général plus des interrupteurs par règle d’alerte sur chaque compte cloud et chaque intégration, pour que tu décides exactement quelles alertes Polylane prend en charge et enquête.

Aussi cette semaine :

• Une couverture Cloudflare bien plus large dans le graphe : zones, load balancing, rulesets WAF et de sécurité, Tunnels, Spectrum, Access, Stream, Images et davantage de ressources Workers
• Des arêtes entre clouds : un enregistrement DNS chez un fournisseur qui pointe vers une ressource chez un autre apparaît maintenant comme une vraie arête dans le graphe
• Une détection d’écarts plus silencieuse : un garde-fou déterministe écarte les pics isolés et le bruit proche d’une baseline nulle avant le triage, la détection respecte le sens qui est vraiment mauvais pour chaque métrique, et les écarts issus des enregistrements de changement sont dédupliqués sur 24 heures au lieu de réveiller à nouveau
• L’onglet Changes montre l’impact d’un coup d’œil : un badge d’impact, les risques, la vérification post-changement et les ressources affectées sous forme de puces
• Les points d’accès LLM personnalisés listent maintenant les modèles qu’ils annoncent réellement, pour que tu choisisses parmi de vrais modèles au lieu de taper des identifiants
• Les secrets de clients OAuth peuvent être renouvelés sans recréer le client
• Et comme toujours : des améliorations de fiabilité, de performance et de stabilité