Post-mortem technique du 14 juillet 2026. Tout ce qui suit est documenté dans le bug 534655509 de Chromium.
Le matin du 14 juillet, n'importe quel visiteur de kiwop.com sous Chrome 150 qui cliquait sur un lien voyait son onglet mourir : écran « Aw, Snap! » et un code d'erreur, RESULT_CODE_KILLED_BAD_MESSAGE. La page d'accueil se chargeait parfaitement. Chaque page se chargeait parfaitement si on y accédait par URL directe. Ça ne cassait qu'à la navigation. Quatre heures plus tard, le bug a disparu sans que nous touchions à une seule ligne de code, et c'est la partie la plus intéressante de l'histoire.
Voici la chronique de la façon dont nous avons traqué ce crash jusqu'au code source de Chromium, pourquoi la cause la plus probable ne se trouvait pas sur notre site, et ce que nous avons appris sur le fait de construire avec des APIs expérimentales en production.
Ce que nous avions activé : WebMCP
WebMCP est l'API expérimentale de Chrome qui permet à un site web d'enregistrer des outils pour des agents d'IA : on expose des fonctions avec document.modelContext.registerTool(), et un agent (une extension, un assistant du navigateur) peut les découvrir et les exécuter au lieu de se battre avec l'interface à coups de clics simulés.
Nous l'avions activée via l'origin trial officiel (Chrome 149 à 156), avec le token dans une balise meta de toutes les pages. Deux outils impératifs et un déclaratif dans le formulaire du chat. Cela fait partie de notre pari sur l'agentic browsing : que les agents puissent opérer un site est la prochaine étape après qu'ils puissent le citer.
Sous Chrome 149, tout fonctionnait. Avec l'arrivée de Chrome 150 en version stable, le spectacle a commencé.
Un crash que les health checks ne voient pas
Ce qui rend cette panne insidieuse, c'est que toute notre supervision restait au vert. Les checks synthétiques interrogent des URLs et toutes répondaient 200. Le site était « sain » pour n'importe quel robot de surveillance, et cassé pour n'importe quel humain qui naviguait, parce que le crash ne se déclenchait que lors d'une navigation same-site initiée par un clic, celle qui réutilise le processus de rendu de Chrome.
Première leçon opérationnelle, que nous avons déjà transformée en règle interne : après un changement important, on se promène sur le site à coups de vrais clics dans un vrai navigateur. Un 200 ne dit pas que le site fonctionne, il dit que le serveur répond.
La bissection : quatre étapes pour l'acculer
Dans un environnement de développement, nous avons reproduit le crash et retiré les pièces une par une :
- Outils impératifs et déclaratif actifs : crash.
- Seulement les impératifs, déclaratif désactivé : crash.
- Origin trial actif et zéro outil enregistré (
getTools()renvoie une liste vide) : crash quand même. - Sans le token de l'origin trial (l'API n'existe même pas sur la page) : navigation parfaite.
La conclusion était inconfortable mais claire : ce n'était pas notre usage de l'API. La simple présence du token suffisait à casser la navigation de tout le site. Nous avons désactivé WebMCP en production et le site est revenu à la normale à l'instant.
Voici la deuxième leçon : le token vivait dans une variable d'environnement, donc désactiver la fonctionnalité n'a coûté que quelques minutes. S'il avait été codé en dur dans les templates, le site serait resté cassé pendant que nous aurions touché au code contre la montre. Toute API expérimentale en production a besoin de son interrupteur d'arrêt.
Ce que dit le code source de Chromium
L'incendie éteint, nous avons enquêté en profondeur. Première surprise : personne n'avait signalé ce crash. Ni dans le tracker de Chromium, ni dans le dépôt du standard, ni sur Stack Overflow. Nous étions, à notre connaissance, les premiers à le voir.
Deuxième constat : l'origin trial était intact sous Chrome 150. La fiche officielle de Chrome Platform Status confirme la plage de milestones 149 à 156 sans changement. La seule chose qui a changé en version 150, c'est la surface de l'API : navigator.modelContext a été déprécié au profit de document.modelContext.
Troisième constat, et c'est là le nœud du problème : nous avons comparé le code de WebMCP entre les branches de Chrome 149 et 150, et il est identique. Le gating de l'origin trial, les bindings, tout. La régression ne se trouvait pas dans le code de WebMCP.
Ce que nous avons trouvé, en revanche, c'est le mécanisme exact de l'erreur. Dans le processus principal de Chrome, le fichier model_context_user_data.cc surveille l'état de WebMCP document par document. Si le processus de rendu et le processus principal ne sont pas d'accord sur l'activation de WebMCP pour un document donné, le processus principal interprète le message du rendu comme un IPC illégal et le tue. Ce kill correspond littéralement au RESULT_CODE_KILLED_BAD_MESSAGE que nous voyions à l'écran. Et ce n'était pas la première fois que cette famille de bugs mordait : une CL de mai 2026 avait corrigé un crash identique dans sa mécanique, quand le rendu croyait WebMCP actif alors que le processus principal n'en avait pas connaissance.
Le rebondissement : le bug a disparu sans que nous touchions à quoi que ce soit
Dans l'après-midi, nous avons tenté de reproduire le crash sur un profil Chrome vierge, avec exactement le même build (150.0.7871.115). Impossible. Nous avons testé huit configurations, dont une réplique exacte de l'incident : le même site, le même token, une navigation à coups de clics réels. Rien.
Et quelques heures plus tard, le crash ne se reproduisait même plus dans le navigateur où il avait planté toute la matinée. Même build, même profil, même site, même token. De notre côté, rien n'avait changé, absolument rien.
Quand une panne reproductible à 100 % disparaît sans aucun changement côté client, l'explication qui reste vit côté serveur. Chrome active et désactive des fonctionnalités à chaud via Finch, son système d'expérimentations à distance : Google peut allumer une variante sur un pourcentage des installations et la faire revenir en arrière avec un killswitch en quelques heures, sans mise à jour du navigateur. Notre hypothèse de travail, et c'est ainsi que nous l'avons signalée, est qu'une expérimentation liée à WebMCP s'est activée ce matin-là, est entrée en conflit avec l'état par document de l'origin trial, et que quelqu'un chez Google a appuyé sur le bouton d'arrêt en voyant les crashs. De l'extérieur, nous ne pouvons pas le voir ; Google peut le vérifier dans son historique de variations en une minute, et c'est exactement ce que nous demandons dans le rapport.
Soyons honnêtes : c'est une hypothèse. Ce qui est un fait, c'est la séquence temporelle, les neuf dumps mémoire que les crashs ont laissés dans le Crashpad local et que nous conservons comme preuve, et le fait que la panne s'est éteinte toute seule.
Ce que nous avons appris, si vous construisez avec des APIs expérimentales
- Un origin trial fait entrer Google dans votre runtime. La fonctionnalité peut changer sous vos pieds sans que vous déployiez quoi que ce soit. Intégrez-le dès la conception : l'expérimental s'isole et doit pouvoir s'éteindre.
- Interrupteur d'arrêt ou rien. Variable d'environnement, flag distant, peu importe, du moment que ça éteint la fonctionnalité en quelques minutes sans toucher aux templates.
- Les health checks ne voient pas les pannes de navigation. Après chaque changement sérieux, de vrais clics dans un vrai navigateur. Sans exception.
- Bissectez une variable à la fois. Notre tableau en quatre étapes est ce qui transforme un « mon site est cassé » en un rapport qu'un ingénieur de Chromium peut exploiter.
- Conservez les minidumps. Le répertoire Crashpad de Chrome est la boîte noire de l'accident : les dumps de la matinée sont la seule preuve physique qui reste de l'incident.
Le rapport, et la suite
Le dossier complet se trouve dans le bug 534655509, avec les pages de reproduction publiques que nous avons montées pour l'équipe de Chromium. WebMCP reste désactivé sur kiwop.com et reviendra quand le bug aura une réponse ou quand Chrome 151 arrivera en version stable, selon ce qui se produit en premier. Le jour de son retour, le site sera repassé au crible à coups de clics avant de considérer quoi que ce soit comme acquis.
En attendant, la morale de fond ne change pas : le web agentique arrive avec des APIs jeunes, des expérimentations à distance et des erreurs qu'aucun monitoring classique ne détecte. C'est un terrain nouveau, et c'est précisément là que nous travaillons. Si vous voulez que votre site soit prêt pour les agents sans risquer la navigation en chemin, commencez par un audit IA ou écrivez-nous.
Questions fréquentes
Qu'est-ce que WebMCP ?
WebMCP est une API expérimentale de Chrome, portée par Google et Microsoft au sein du W3C, qui permet à une page web d'enregistrer des outils pour des agents d'IA via document.modelContext.registerTool(). En juillet 2026, elle est en origin trial sous Chrome depuis la version 149 jusqu'à la 156, avec un lancement stable prévu pour la version 157.
Que signifie l'erreur RESULT_CODE_KILLED_BAD_MESSAGE de Chrome ?
Cela signifie que le processus principal de Chrome a délibérément tué le processus de rendu d'un onglet pour lui avoir envoyé un message IPC jugé illégal ou malformé. Ce n'est pas un plantage du rendu : c'est une exécution défensive, pensée pour stopper des processus compromis. L'utilisateur le voit sous la forme d'un écran « Aw, Snap! ».
Qu'est-ce que Finch, le système d'expérimentations de Chrome ?
Finch est le mécanisme de Google pour activer ou désactiver des fonctionnalités de Chrome à distance, par pourcentages d'installations et sans publier de mise à jour. Chaque Chrome télécharge périodiquement une « seed » d'expérimentations qui détermine quelles variantes sont actives. Cela permet des déploiements progressifs, mais aussi des killswitches : faire revenir en arrière en quelques heures une fonctionnalité qui pose problème.
Est-il risqué d'activer un origin trial en production ?
C'est acceptable si vous le traitez pour ce que c'est : du code expérimental dont le comportement peut changer sans que vous ayez rien fait. Les trois règles qui fonctionnent chez nous sont d'isoler la fonctionnalité derrière un interrupteur capable de l'éteindre en quelques minutes, de vérifier le site en naviguant réellement après chaque changement de version de Chrome, et de surveiller aussi les parcours de navigation, pas seulement les codes de réponse.
