C’est trop effrayant.
L’idée que des données enregistrées de manière malveillante puissent l’emporter sur la mémoire et l’expérience, devenir des preuves
et servir à nous menacer.
Il n’existe pas tant de navigateurs que ça, alors pourquoi y a-t-il autant de frameworks ? Le mieux ne serait-il pas que les entreprises qui gèrent les navigateurs créent un framework optimal et l’entretiennent elles-mêmes ? Jusqu’à quand allons-nous répéter ce cercle vicieux ?
Comme le texte le mentionne aussi, la cause superficielle du phénomène est l’augmentation de la demande pour un « web façon application ».
Hier comme aujourd’hui, le web n’était pas vraiment adapté à la création de « quelque chose qui ressemble à une application », mais à force de bricolages on peut arriver à « faire quelque chose d’assez proche ».
En réalité, le web a été conçu à l’origine comme une plateforme destinée à partager des sortes de « documents », comme des articles scientifiques.
Il suffit de regarder les éléments de base de HTML pour s’en rendre compte.
Puis sont apparues des technologies capables de générer du contenu dynamique, comme CGI, et les navigateurs ont embarqué des langages de script, ce qui a permis d’ajouter du dynamisme au résultat ; c’est ainsi qu’a commencé la sortie du « web en tant que document ».
Le problème, c’est que depuis cette première bifurcation jusqu’à aujourd’hui, le socle du web reste malgré tout un système fondé sur le « document ».
Bien sûr, de nombreuses technologies nouvelles se sont éloignées de cette logique de « document » — WebSocket, WebRTC, WASM, etc. — mais la majorité des sites web continuent encore aujourd’hui d’être développés en s’appuyant sur la plateforme traditionnelle fondée sur le « document ».
Nous devons toujours empiler des balises div pour dessiner un écran.
Voilà pour l’analyse du phénomène ; la question est donc de savoir quelle serait la réponse.
Si l’on imagine les fonctionnalités idéales de la prochaine plateforme sans se soucier du tout du réalisme, cela donnerait quelque chose comme ceci.
(Je ne dis pas que tous les sites devraient fonctionner ainsi, mais seulement ceux qui ont une nature applicative.)
D’abord, le navigateur deviendrait une sorte de lanceur d’applications.
Une fois téléchargée, une application devrait pouvoir s’exécuter hors ligne.
Et l’application serait implémentée dans d’autres langages, en sortant du triptyque HTML/CSS/JS.
Dans ce processus, le navigateur pourrait fournir une sorte de framework, un peu comme Android.
La manière de communiquer avec le serveur pourrait elle aussi s’éloigner des requêtes web traditionnelles pour adopter un autre paradigme.
Pour les communications nécessitant du temps réel, on pourrait conserver les communications TCP telles quelles,
et on pourrait aussi créer et utiliser une forme de communication RPC plus simple, qui n’emploierait pas le protocole HTTP.
Il y a un mois, pour apprendre ce qu’était le codage avec l’IA en utilisant CURSOR, j’ai lancé le développement d’un framework de développement.
Pendant environ trois semaines, j’ai enchaîné les réussites puis les moments où du code source pourtant validé par l’AI Agent se retrouvait cassé, et j’ai tenté par tous les moyens de contrôler l’AI Agent, sans succès.
J’ai alors compris qu’avant de développer ce framework, la priorité était de développer le code source permettant de contrôler l’AI Agent.
Au final, exactement un mois après avoir commencé à vouloir comprendre ce qu’était vraiment l’IA, j’ai réussi à achever le développement d’un logiciel pouvant être implémenté à 100 % et exploité à 100 % par l’IA, avec un contrôle parfait de l’AI Agent — ou, plus précisément, sans avoir besoin de LLM externes ni d’AI Agent.
En ce moment, cela fait 14 jours que je poursuis le processus d’amélioration supplémentaire en réentraînant cette META AI et en élaborant des règles d’exploitation qu’elle doit respecter. En parallèle, je mène simultanément la migration, l’amélioration et la standardisation de trois systèmes MES que des humains avaient auparavant conçus de manière incomplète, et j’en suis désormais à la phase finale.
On peut considérer que la vision centrale de la technologie MCP-B est la suivante.
« Par l’intermédiaire fiable qu’est une extension Chrome, exploiter les informations utilisateur que le navigateur gère déjà de façon sécurisée (cookies, session, authentification, etc.) afin d’appeler et de piloter, depuis une fenêtre de chat IA, des “outils (Tools)” prédéfinis par les développeurs sur une page web au moyen de commandes en langage naturel. »
Mais, pour ma part, j’ai le sentiment que « les possibilités d’extension semblent limitées », et j’estime que les raisons sont les suivantes.
Réticence des utilisateurs : c’est l’obstacle principal. Les utilisateurs éprouvent instinctivement une résistance et des inquiétudes de sécurité à l’idée d’installer une extension qui accède aux informations de leur navigateur. Si la commodité offerte par cette technologie n’est pas suffisamment écrasante pour surpasser ces craintes, ils hésiteront à l’installer.
Charge pour les développeurs web : en plus de créer les API existantes, les développeurs de sites web doivent assumer la charge supplémentaire de définir et de maintenir séparément des “outils (Tools)” pour MCP-B. Si les bénéfices tirés d’une adoption large de cette technologie ne sont pas significatifs, les développeurs ne voudront pas fournir ce double effort.
Responsabilité en cas de problème de sécurité : si un incident de sécurité survient via cette technologie, il peut devenir flou de déterminer si la responsabilité incombe au développeur du site web, au développeur de l’extension ou au fournisseur du modèle d’IA. Cette complexité rend les entreprises réticentes à adopter la technologie.
Absence de plateforme centralisée : à l’heure actuelle, il n’existe pas de répertoire ni de plateforme standardisés indiquant « quels sites web proposent quels outils ». Avant même de visiter un site, il est difficile pour l’utilisateur de savoir quelles fonctionnalités IA y sont disponibles.
En conclusion,
l’idée même de MCP-B est techniquement très intéressante et innovante, mais elle ne semble pas pouvoir apporter une réponse claire à la question fondamentale, pour les utilisateurs comme pour les développeurs, de « pourquoi faudrait-il absolument utiliser cette approche ? ». Par rapport à l’approche API existante, les avantages obtenus restent flous, tandis que les inconvénients — préoccupations de sécurité et complexité de développement — sont, eux, bien réels.
Par conséquent, à ce stade, cette technologie pourra certes être utilisée à titre expérimental par quelques passionnés ou par des développeurs ayant des objectifs spécifiques, mais elle semble rencontrer de nombreuses difficultés pour s’étendre à l’ensemble de l’écosystème web.
Je partage l’idée de fond de cet article, mais certains passages me laissent tout de même perplexe.
Par exemple, un site web promotionnel pour un service précis exploité par notre entreprise conserve justement le même type de simplicité que cet article encense. Heureusement, ce site est composé en grande majorité d’éléments assez statiques. Le code frontend, comme le HTML et le CSS, a été écrit à la main sans aucun framework, et le JS se limite plus ou moins à jQuery et Google Analytics. Les annonces et le forum, entre autres, sont implémentés en AJAX avec jQuery, mais je ne pense pas que cela relève d’un niveau de complexité déraisonnable ou excessif. À mes yeux, c’est à peu près le niveau qu’on pouvait déjà construire avec jQuery quand j’ai débuté dans le développement web. À ma connaissance, ce site existe depuis l’époque d’Internet Explorer, donc je ne l’ai pas créé moi-même, mais je ne le trouve pas mauvais du tout.
Mais il est aussi géré avec le contrôle de version Git et un pipeline CI/CD, avec un serveur de staging séparé du serveur de production. Quand une Pull Request est fusionnée dans la branche Main, le pipeline déploie automatiquement sur le serveur de staging le résultat généré par le bundler, puis, après vérification du serveur de staging par le responsable et approbation finale du déploiement, cela est à nouveau déployé sur le serveur de production. Par le passé, on se contentait d’écraser directement les fichiers sources sur le serveur de production via FTP, mais après le transfert de cette activité à notre équipe, nous avons procédé à ce changement.
Est-ce vraiment une complexité irrationnelle ? Autrefois, modifier la balise de titre de ce site revenait simplement à ouvrir directement le fichier HTML du serveur de production avec AcroEdit prenant en charge la connexion FTP (oui, les personnes qui avaient rédigé directement le HTML du site utilisaient toujours cela), modifier une seule ligne, enregistrer, et tout était terminé. Il est donc probable que ces personnes le perçoivent ainsi.
Mais, pour ma part, je pense que ce niveau de complexité supplémentaire était tout à fait acceptable. Toutes les tâches ne se résument pas à modifier une simple balise de titre. Et le fait de pouvoir supprimer sans hésitation d’anciens bouts de code auparavant laissés en commentaires partout, puisqu’on peut toujours les restaurer, la possibilité d’un suivi transparent des changements et d’un rollback, ou encore le fait de pouvoir ajouter, si nécessaire, quelques optimisations de base via le bundler, sont à mes yeux de vrais avantages. On pourrait aussi dire que l’ajout d’un serveur de staging pour prévisualiser avant déploiement en environnement réel constitue une forme de complexité, mais je pense que c’était nécessaire.
Moi aussi, je suis très mécontent de la manière dont la structure interne du code de divers sites web est devenue excessivement complexe et lourde. L’application Outlook de Windows est aujourd’hui basée sur une web app, et récemment elle est devenue particulièrement plus lourde. Il suffit de rédiger le corps d’un mail à l’écran ou même de sélectionner tout le texte pour que cela rame, voire affiche « page sans réponse ». Je me suis demandé ce qui se passait, puis j’ai ouvert les outils de développement dans Outlook Web et j’ai été stupéfait. Après avoir vidé le cache et rechargé la page, des requêtes continuaient encore à apparaître une minute plus tard. En vérifiant dans le navigateur, j’ai vu que plusieurs gigaoctets de données étaient stockés rien que pour des sites liés à MS Office.
Cela dit, cet article mélange plusieurs sujets ; je suis d’accord avec certaines parties, mais beaucoup moins avec d’autres. Pour ce qui est du HTML sémantique et de l’accessibilité, j’ai plutôt l’impression que le passé était bien pire. Et l’idée selon laquelle l’amélioration de l’expérience développeur dégraderait l’expérience utilisateur ne me parle pas du tout, même si c’est peut-être parce que je ne suis pas développeur frontend web. Quant à l’affirmation selon laquelle tout le pouvoir et tout le contrôle se seraient concentrés chez les développeurs, elle me paraît franchement absurde. En entreprise, le pouvoir n’est-il pas du côté de la direction ? Ou bien la structure des entreprises en Occident est-elle à ce point différente de celle de la Corée ?
Comme toujours, je suis tout à fait d’accord sur le fait que l’équilibre et la modération, ainsi que la simplicité et le pragmatisme, sont des valeurs importantes et doivent être prioritaires dans la prise de décision. En revanche, cet article soutient que le fait de « traiter tous les sites web comme des produits logiciels » relèverait presque entièrement de la responsabilité des développeurs, et je pense que c’est précisément ce point qui brouille le problème de fond. Et les passages qui semblent idéaliser le « bon vieux temps » d’avant, quand rien n’était vraiment structuré, mériteraient au contraire d’être critiqués.
Les philosophies de développement poursuivies sont extrêmement variées, donc.........
Visiblement, même l’IA n’est pas impartiale.
C’est trop effrayant.
L’idée que des données enregistrées de manière malveillante puissent l’emporter sur la mémoire et l’expérience, devenir des preuves
et servir à nous menacer.
Il n’existe pas tant de navigateurs que ça, alors pourquoi y a-t-il autant de frameworks ? Le mieux ne serait-il pas que les entreprises qui gèrent les navigateurs créent un framework optimal et l’entretiennent elles-mêmes ? Jusqu’à quand allons-nous répéter ce cercle vicieux ?
Je me demande pourquoi cela a échoué.
La forme ultime de l’IA qui flatte l’utilisateur, c’était donc une IA qui flatte le patron...
Je partage le constat, mais pas la conclusion.
Comme le texte le mentionne aussi, la cause superficielle du phénomène est l’augmentation de la demande pour un « web façon application ».
Hier comme aujourd’hui, le web n’était pas vraiment adapté à la création de « quelque chose qui ressemble à une application », mais à force de bricolages on peut arriver à « faire quelque chose d’assez proche ».
En réalité, le web a été conçu à l’origine comme une plateforme destinée à partager des sortes de « documents », comme des articles scientifiques.
Il suffit de regarder les éléments de base de HTML pour s’en rendre compte.
Puis sont apparues des technologies capables de générer du contenu dynamique, comme CGI, et les navigateurs ont embarqué des langages de script, ce qui a permis d’ajouter du dynamisme au résultat ; c’est ainsi qu’a commencé la sortie du « web en tant que document ».
Le problème, c’est que depuis cette première bifurcation jusqu’à aujourd’hui, le socle du web reste malgré tout un système fondé sur le « document ».
Bien sûr, de nombreuses technologies nouvelles se sont éloignées de cette logique de « document » — WebSocket, WebRTC, WASM, etc. — mais la majorité des sites web continuent encore aujourd’hui d’être développés en s’appuyant sur la plateforme traditionnelle fondée sur le « document ».
Nous devons toujours empiler des balises
divpour dessiner un écran.Voilà pour l’analyse du phénomène ; la question est donc de savoir quelle serait la réponse.
Si l’on imagine les fonctionnalités idéales de la prochaine plateforme sans se soucier du tout du réalisme, cela donnerait quelque chose comme ceci.
(Je ne dis pas que tous les sites devraient fonctionner ainsi, mais seulement ceux qui ont une nature applicative.)
D’abord, le navigateur deviendrait une sorte de lanceur d’applications.
Une fois téléchargée, une application devrait pouvoir s’exécuter hors ligne.
Et l’application serait implémentée dans d’autres langages, en sortant du triptyque HTML/CSS/JS.
Dans ce processus, le navigateur pourrait fournir une sorte de framework, un peu comme Android.
La manière de communiquer avec le serveur pourrait elle aussi s’éloigner des requêtes web traditionnelles pour adopter un autre paradigme.
Pour les communications nécessitant du temps réel, on pourrait conserver les communications TCP telles quelles,
et on pourrait aussi créer et utiliser une forme de communication RPC plus simple, qui n’emploierait pas le protocole HTTP.
Oh là là, on dirait que l’avenir de Windsurf n’est pas si prometteur que ça non plus.
Il y a un mois, pour apprendre ce qu’était le codage avec l’IA en utilisant CURSOR, j’ai lancé le développement d’un framework de développement.
Pendant environ trois semaines, j’ai enchaîné les réussites puis les moments où du code source pourtant validé par l’AI Agent se retrouvait cassé, et j’ai tenté par tous les moyens de contrôler l’AI Agent, sans succès.
J’ai alors compris qu’avant de développer ce framework, la priorité était de développer le code source permettant de contrôler l’AI Agent.
Au final, exactement un mois après avoir commencé à vouloir comprendre ce qu’était vraiment l’IA, j’ai réussi à achever le développement d’un logiciel pouvant être implémenté à 100 % et exploité à 100 % par l’IA, avec un contrôle parfait de l’AI Agent — ou, plus précisément, sans avoir besoin de LLM externes ni d’AI Agent.
En ce moment, cela fait 14 jours que je poursuis le processus d’amélioration supplémentaire en réentraînant cette META AI et en élaborant des règles d’exploitation qu’elle doit respecter. En parallèle, je mène simultanément la migration, l’amélioration et la standardisation de trois systèmes MES que des humains avaient auparavant conçus de manière incomplète, et j’en suis désormais à la phase finale.
Et je prépare maintenant une autre évolution.
On peut considérer que la vision centrale de la technologie MCP-B est la suivante.
« Par l’intermédiaire fiable qu’est une extension Chrome, exploiter les informations utilisateur que le navigateur gère déjà de façon sécurisée (cookies, session, authentification, etc.) afin d’appeler et de piloter, depuis une fenêtre de chat IA, des “outils (Tools)” prédéfinis par les développeurs sur une page web au moyen de commandes en langage naturel. »
Mais, pour ma part, j’ai le sentiment que « les possibilités d’extension semblent limitées », et j’estime que les raisons sont les suivantes.
En conclusion,
l’idée même de MCP-B est techniquement très intéressante et innovante, mais elle ne semble pas pouvoir apporter une réponse claire à la question fondamentale, pour les utilisateurs comme pour les développeurs, de « pourquoi faudrait-il absolument utiliser cette approche ? ». Par rapport à l’approche API existante, les avantages obtenus restent flous, tandis que les inconvénients — préoccupations de sécurité et complexité de développement — sont, eux, bien réels.
Par conséquent, à ce stade, cette technologie pourra certes être utilisée à titre expérimental par quelques passionnés ou par des développeurs ayant des objectifs spécifiques, mais elle semble rencontrer de nombreuses difficultés pour s’étendre à l’ensemble de l’écosystème web.
Je partage l’idée de fond de cet article, mais certains passages me laissent tout de même perplexe.
Par exemple, un site web promotionnel pour un service précis exploité par notre entreprise conserve justement le même type de simplicité que cet article encense. Heureusement, ce site est composé en grande majorité d’éléments assez statiques. Le code frontend, comme le HTML et le CSS, a été écrit à la main sans aucun framework, et le JS se limite plus ou moins à jQuery et Google Analytics. Les annonces et le forum, entre autres, sont implémentés en AJAX avec jQuery, mais je ne pense pas que cela relève d’un niveau de complexité déraisonnable ou excessif. À mes yeux, c’est à peu près le niveau qu’on pouvait déjà construire avec jQuery quand j’ai débuté dans le développement web. À ma connaissance, ce site existe depuis l’époque d’Internet Explorer, donc je ne l’ai pas créé moi-même, mais je ne le trouve pas mauvais du tout.
Mais il est aussi géré avec le contrôle de version Git et un pipeline CI/CD, avec un serveur de staging séparé du serveur de production. Quand une Pull Request est fusionnée dans la branche Main, le pipeline déploie automatiquement sur le serveur de staging le résultat généré par le bundler, puis, après vérification du serveur de staging par le responsable et approbation finale du déploiement, cela est à nouveau déployé sur le serveur de production. Par le passé, on se contentait d’écraser directement les fichiers sources sur le serveur de production via FTP, mais après le transfert de cette activité à notre équipe, nous avons procédé à ce changement.
Est-ce vraiment une complexité irrationnelle ? Autrefois, modifier la balise de titre de ce site revenait simplement à ouvrir directement le fichier HTML du serveur de production avec AcroEdit prenant en charge la connexion FTP (oui, les personnes qui avaient rédigé directement le HTML du site utilisaient toujours cela), modifier une seule ligne, enregistrer, et tout était terminé. Il est donc probable que ces personnes le perçoivent ainsi.
Mais, pour ma part, je pense que ce niveau de complexité supplémentaire était tout à fait acceptable. Toutes les tâches ne se résument pas à modifier une simple balise de titre. Et le fait de pouvoir supprimer sans hésitation d’anciens bouts de code auparavant laissés en commentaires partout, puisqu’on peut toujours les restaurer, la possibilité d’un suivi transparent des changements et d’un rollback, ou encore le fait de pouvoir ajouter, si nécessaire, quelques optimisations de base via le bundler, sont à mes yeux de vrais avantages. On pourrait aussi dire que l’ajout d’un serveur de staging pour prévisualiser avant déploiement en environnement réel constitue une forme de complexité, mais je pense que c’était nécessaire.
Moi aussi, je suis très mécontent de la manière dont la structure interne du code de divers sites web est devenue excessivement complexe et lourde. L’application Outlook de Windows est aujourd’hui basée sur une web app, et récemment elle est devenue particulièrement plus lourde. Il suffit de rédiger le corps d’un mail à l’écran ou même de sélectionner tout le texte pour que cela rame, voire affiche « page sans réponse ». Je me suis demandé ce qui se passait, puis j’ai ouvert les outils de développement dans Outlook Web et j’ai été stupéfait. Après avoir vidé le cache et rechargé la page, des requêtes continuaient encore à apparaître une minute plus tard. En vérifiant dans le navigateur, j’ai vu que plusieurs gigaoctets de données étaient stockés rien que pour des sites liés à MS Office.
Cela dit, cet article mélange plusieurs sujets ; je suis d’accord avec certaines parties, mais beaucoup moins avec d’autres. Pour ce qui est du HTML sémantique et de l’accessibilité, j’ai plutôt l’impression que le passé était bien pire. Et l’idée selon laquelle l’amélioration de l’expérience développeur dégraderait l’expérience utilisateur ne me parle pas du tout, même si c’est peut-être parce que je ne suis pas développeur frontend web. Quant à l’affirmation selon laquelle tout le pouvoir et tout le contrôle se seraient concentrés chez les développeurs, elle me paraît franchement absurde. En entreprise, le pouvoir n’est-il pas du côté de la direction ? Ou bien la structure des entreprises en Occident est-elle à ce point différente de celle de la Corée ?
Comme toujours, je suis tout à fait d’accord sur le fait que l’équilibre et la modération, ainsi que la simplicité et le pragmatisme, sont des valeurs importantes et doivent être prioritaires dans la prise de décision. En revanche, cet article soutient que le fait de « traiter tous les sites web comme des produits logiciels » relèverait presque entièrement de la responsabilité des développeurs, et je pense que c’est précisément ce point qui brouille le problème de fond. Et les passages qui semblent idéaliser le « bon vieux temps » d’avant, quand rien n’était vraiment structuré, mériteraient au contraire d’être critiqués.
L’air de rien…
En Corée, tout finit toujours en Java-land, alors ça leur paraît étrange, haha.
Je pense que la technologie d’un autre pays != les données d’un autre pays
Je n’y croirai pas tant que ce ne sera pas dispo gratuitement. Grok est même à 30 dollars, ça fait peur de s’abonner...
MDRRR le doctorant soudain pris dans la ligne de mire, complètement sidéré ..
Utilisez Rails, soyez heureux
Je salue l’initiative, mais...
J’espère juste qu’ils ne referont pas le coup de créer une nouvelle organization et de jeter la 1.0 aux oubliettes.
(Corée) La vie en entreprise ? lol
J’aimerais bien qu’il sorte aussi en YCD~