Mise à jour produit KENSAI : 3 nouvelles règles de détection, correctif sitemap et publication multilingue le jour même

KENSAI a déployé trois nouvelles règles de scan, réparé l’accès sitemap pour les robots et renforcé la chaîne de publication multilingue afin que les articles du jour restent alignés dans toutes les langues prises en charge.

Ce qui a été livré aujourd’hui

La mise à jour du jour est volontairement pragmatique : meilleure détection, meilleure hygiène de publication et meilleure crawlabilité. Nous avons resserré trois parties de la chaîne KENSAI qui créaient trop de friction entre la recherche, la publication et la visibilité dans les moteurs.

Le résultat est moins spectaculaire qu’un nouveau tableau de bord, mais bien plus utile : plus de découvertes captées automatiquement, moins d’écarts silencieux entre les index linguistiques et des sitemaps que les robots peuvent enfin récupérer proprement.

1) Trois nouvelles règles élargissent la couverture de détection

Le scanner gagne trois règles issues de schémas observés dans de vrais findings : des identifiants codés en dur dans le code ou la configuration, l’exposition de données sensibles dans des réponses publiques et une règle combinée CORS plus fuite d’information pour les endpoints qui exposent des données tout en faisant confiance aux mauvaises origines.

Nous avons aussi intégré des motifs vus autour de buckets S3 listables et de télémétrie ou de clés exposées côté frontend. Ce sont exactement les défauts qui reviennent sans cesse en production, qui passent entre les mailles des revues manuelles et qui finissent en incident coûteux.

2) La publication multilingue du jour est désormais plus stricte

Nous avons corrigé la logique de fraîcheur du blog et le chemin de synchronisation des locales pour éviter que les publications du jour dérivent entre l’index anglais et les index traduits. La règle est volontairement stricte : si l’article anglais existe, son équivalent localisé doit exister le même jour dans son propre index de langue.

Cela paraît évident, mais l’automatisation cassée adore échouer sur les évidences. Une discipline d’index plus stricte réduit les décalages dans les pages overview, garde les blogs localisés plus frais et évite l’échec SEO le plus idiot qui soit : publier du contenu puis le cacher à ses propres pages de langue.

3) L’accès sitemap pour les robots a été réparé

Nous avons aussi corrigé un vrai piège SEO. Les URL de sitemap renvoyaient 403 parce que le serveur web ne pouvait pas traverser une partie du chemin système sous la racine du workspace. Une fois ce problème de permission corrigé, les endpoints sitemap vérifiés sont revenus en 200.

C’est typiquement le genre de bug qui semble anodin depuis l’application et qui détruit discrètement la découvrabilité depuis l’extérieur. Si votre sitemap est bloqué, votre rythme de publication ne sert plus à grand-chose parce que les robots ne reçoivent jamais la liste propre des URL.

Pourquoi c’est important

Les produits de sécurité gagnent sur la confiance, pas sur le style. La qualité de détection compte. La fiabilité de publication compte. La crawlabilité compte. Quand l’un des trois casse, vous travaillez plus pour un résultat pire.

Les changements d’aujourd’hui rendent la chaîne plus honnête : les findings de recherche sont plus faciles à convertir en règles réutilisables, les articles risquent moins de rester à moitié publiés selon la langue, et les moteurs de recherche reçoivent enfin les fichiers attendus.

Ce qui arrive ensuite

La suite : continuer à extraire des règles à partir de findings réels, continuer à fermer les écarts de traduction et de cohérence d’index, et continuer à supprimer les petites erreurs d’infrastructure qui sabotent la distribution. La plomberie ennuyeuse cache souvent le vrai levier.