Simon Willison cite Jeremy Morrell, mais des extensions IA sûres exigent plus qu’un sandbox

Simon Willison a mis en avant un conflit concret le 19 août 2026 : les LLM facilitent l’écriture d’extensions logicielles, tandis que leur code généré reste difficile à considérer comme fiable.

Cette observation vient de Jeremy Morrell, qui soutient que les applications web peuvent associer un cœur responsable à des extensions écrites par les utilisateurs. Les grands modèles de langage généreraient ces extensions, tandis que les sandbox des navigateurs limiteraient les ressources auxquelles le code obtenu peut accéder.

Ce modèle remet en cause deux approches familières. Les applications traditionnelles exposent des fonctionnalités fixes choisies par leurs développeurs. Les agents d’IA généralistes reçoivent un accès étendu et tentent d’utiliser des interfaces existantes pour le compte d’un utilisateur.

Morrell propose une troisième voie. L’application conserve son centre fiable, mais les utilisateurs peuvent décrire les capacités manquantes au moment où ils les rencontrent. Un LLM fournit du code circonscrit au lieu de contrôler l’ensemble du produit.

La proposition paraît simple parce que les navigateurs disposent déjà de mécanismes d’isolation. Pourtant, la génération de code et son exécution sécurisée ne résolvent qu’une partie du problème. Les produits doivent aussi contrôler les autorisations, les déplacements de données, les mises à jour, la responsabilité et la reprise lorsqu’une extension se comporte mal.

La véritable opposition n’est donc pas entre un logiciel fixe et une personnalisation illimitée. Elle se situe entre une extensibilité responsable et une autonomie IA sans restrictions.

Simon Willison remet les logiciels extensibles à l’ordre du jour

L’événement important n’est pas un lancement de produit, mais une hypothèse architecturale plus précise pour les logiciels d’IA.

Dans son billet du 19 août, Simon Willison a cité l’argument de Morrell concernant une nouvelle opportunité pour les logiciels web extensibles. Le billet classe l’idée sous les thèmes sandboxing, LLMs, IA et IA générative.

L’hypothèse de Morrell réunit deux évolutions souvent discutées séparément. Les LLM réduisent l’effort nécessaire pour produire de petites quantités de code applicatif. Les plateformes web modernes fournissent des primitives capables de limiter l’endroit où ce code s’exécute et ce qu’il peut faire.

Aucune de ces évolutions ne supprime l’ingénierie logicielle. Ensemble, toutefois, elles modifient l’économie d’une fonctionnalité qui ne sert qu’une personne ou une équipe.

Une équipe produit classique doit évaluer une demande, concevoir l’interaction, l’implémenter, la tester, la documenter et la maintenir. Ce processus est pertinent pour des fonctionnalités largement partagées. Il fonctionne rarement pour un flux de travail étroit utilisé par quelques personnes.

Un LLM peut transformer une demande précise en code sans attendre que la fonctionnalité entre dans une feuille de route publique. L’extension qui en résulte peut transformer un document, ajouter une visualisation personnalisée, valider un formulaire ou connecter deux sources de données autorisées.

Cela ne rend pas le code généré correct. Mais cela rend beaucoup moins coûteuse la tentative d’une première implémentation.

La seconde moitié de l’argument de Morrell concerne le déploiement. Historiquement, installer des extensions tierces impliquait souvent de faire confiance à un package, d’accorder de larges autorisations ou d’exécuter du code dans un processus applicatif privilégié.

Le navigateur offre une base différente. Un frame isolé crée un contexte de navigation distinct et peut désactiver des capacités à moins que l’hôte ne les rétablisse explicitement.

Les contrôles disponibles sont précis plutôt que symboliques. L’hôte peut restreindre les scripts, les formulaires, les fenêtres contextuelles, les téléchargements, l’accès au stockage et la navigation de niveau supérieur. Il peut également appliquer une Permissions Policy à des fonctionnalités telles que les caméras et les microphones.

Ces contrôles rendent possible une frontière de sécurité significative. Ils ne produisent pas automatiquement la frontière adéquate pour chaque extension.

L’expression de Morrell, « cœur solide et responsable », est la partie décisive de la proposition. L’application hôte continuerait de gérer l’identité, les données durables, les autorisations, l’historique d’audit et les opérations critiques.

Les extensions générées combleraient des lacunes locales autour de ce cœur. Elles ne remplaceraient pas silencieusement son modèle de sécurité et ne deviendraient pas la source de référence.

Cette distinction sépare les logiciels extensibles d’un chatbot généraliste de programmation. Un chatbot peut produire un fichier et laisser à l’utilisateur la responsabilité de l’exécuter en toute sécurité. Une application extensible peut définir où vit le code généré, quelles interfaces il reçoit et comment ses actions sont examinées.

Elle distingue aussi cette idée des boutiques de plugins ordinaires. Les plugins traditionnels sont généralement créés pour de nombreux utilisateurs, conditionnés comme des produits et distribués via un processus de révision. Les extensions générées par LLM peuvent cibler un seul flux de travail tout en restant dans un environnement d’exécution contrôlé.

L’événement importe car le billet de Willison donne à cette architecture un cadre public concis. L’affirmation n’est pas que l’IA devrait redessiner chaque interface. Elle est que l’IA peut rendre économiquement viable une personnalisation soigneusement délimitée.

C’est un argument plus restreint que « les agents remplaceront les applications ». Il est aussi plus facile à tester.

La pression s’exerce sur les produits SaaS fixes et les agents IA généralistes

Les produits subissent désormais la pression d’offrir de la personnalisation sans abandonner le contrôle des données utilisateur ni des flux de travail centraux.

Les logiciels fixes fonctionnent en prédisant les besoins communs. Leurs concepteurs choisissent les objets, commandes, vues, intégrations et règles d’automatisation disponibles avant que les clients ne rencontrent leurs cas particuliers.

Ce modèle apporte de la cohérence. Il crée aussi un backlog permanent de demandes trop spécifiques pour justifier un développement partagé.

Les clients d’entreprise contournent ces lacunes avec des feuilles de calcul, des scripts, des extensions de navigateur, des plateformes d’intégration et des procédures manuelles. Chaque contournement ajoute un lieu supplémentaire où la logique peut devenir obsolète ou invisible.

Les logiciels extensibles rapprochent cette logique de l’application qui possède les données concernées. Une extension générée peut utiliser une interface étroite définie par l’hôte au lieu d’extraire des écrans ou de copier des enregistrements ailleurs.

Prenons le cas d’un chef de projet souhaitant un panneau de revue fondé sur plusieurs champs de métadonnées inhabituels. Le produit ne proposera peut-être jamais ce panneau exact, car peu de clients en ont besoin.

Une extension pourrait demander des enregistrements approuvés, calculer le regroupement requis et afficher une vue temporaire. L’application centrale continuerait d’appliquer les règles déterminant quels enregistrements l’utilisateur peut lire.

Un chercheur pourrait vouloir un extracteur ponctuel pour un format de document récurrent. Un ingénieur pourrait avoir besoin d’un tableau de bord pour une convention de déploiement privée. Une équipe commerciale pourrait souhaiter une règle de validation liée à son propre processus de compte.

Ces demandes sont trop modestes pour la plupart des feuilles de route, mais trop répétitives pour un traitement manuel. Elles constituent l’ouverture économique derrière l’hypothèse de Morrell.

Geoffrey Litt a décrit une vision apparentée dans ses travaux antérieurs sur les logiciels malléables. Litt a soutenu que les LLM peuvent agir comme des développeurs locaux au sein d’environnements informatiques que les utilisateurs comprennent déjà.

Cette référence historique importe parce que la programmation par les utilisateurs finaux n’est pas nouvelle. Les feuilles de calcul, les macros, HyperCard, les scripts de navigateur et les outils d’automatisation visuelle ont tous permis aux personnes de modifier leur environnement de travail.

Le goulot d’étranglement persistant ne se limitait pas à la syntaxe. Les utilisateurs devaient traduire un objectif informel en logique exécutable, comprendre les interfaces disponibles et déboguer le résultat.

Les LLM condensent certaines parties de ce processus de traduction. Un utilisateur peut décrire un résultat dans le langage de son domaine, examiner une extension proposée et la réviser à l’aide d’exemples.

L’extension a néanmoins besoin d’un socle stable. Sans objets ni capacités définis, le modèle doit deviner le fonctionnement de l’application. Cela produit du code fragile et encourage l’automatisation d’écran.

Cela met les fournisseurs SaaS sous pression pour qu’ils exposent des briques plus petites et plus sûres. Un produit conçu uniquement pour les clics humains offre à un LLM moins de moyens fiables de l’étendre.

La même pression s’applique aux agents IA généralistes. Un agent ayant accès aux e-mails, aux fichiers, aux sessions de navigation et aux outils internes peut effectuer des tâches variées. Cet accès élargit aussi les conséquences d’une instruction erronée.

Une extension circonscrite adopte l’approche inverse. Elle ne reçoit que les capacités minimales nécessaires à une tâche. L’application environnante arbitre les opérations sensibles.

Le compromis est une autonomie réduite. Une extension étroite ne peut pas improviser entre tous les services ni récupérer des données arbitraires. Cette limitation est l’objectif, non un défaut.

Pour les acheteurs, la question devient plus concrète que de savoir si un produit « a de l’IA ». Ils peuvent demander si les utilisateurs peuvent créer des capacités locales sans accorder à un modèle un accès sans restrictions.

Ils peuvent aussi vérifier si le comportement généré reste visible. Un plan d’agent caché est difficile à auditer après une erreur. Une extension installée peut exposer son code, ses autorisations déclarées, ses entrées, ses sorties et son historique de révisions.

Les applications fixes ne disparaîtront pas avec ce modèle. Les fonctionnalités partagées nécessitent toujours une conception professionnelle, du travail d’accessibilité, des tests de performance, du support et une maintenance à long terme.

La pression probable concerne la frontière autour de ces fonctionnalités. Les fournisseurs qui maintiennent chaque flux de travail fermé devront concurrencer des produits qui permettent aux utilisateurs d’accomplir eux-mêmes, en toute sécurité, le dernier kilomètre.

Les équipes auront aussi besoin de meilleurs moyens pour préserver le contexte à l’origine des comportements personnalisés. Une base de connaissances d’ingénierie consultable peut documenter pourquoi une extension existe, quelles hypothèses elle formule et qui en est responsable.

Cette trace devient essentielle lorsque les extensions générées passent d’un utilisateur à un département. Une création peu coûteuse ne supprime pas le coût de la mémoire institutionnelle.

Les sandbox réduisent le coût du déploiement, pas celui de la responsabilité

Un sandbox peut contraindre l’exécution du code, mais le produit doit toujours concevoir chaque chemin significatif à travers cette frontière.

Un sandbox de navigateur n’est pas un unique mur de protection. C’est un ensemble de restrictions couvrant l’origine, les scripts, la navigation, le stockage, les capacités des appareils et la communication avec l’hôte.

L’attribut sandbox sur un iframe adopte au départ une posture restrictive. L’application peut ensuite rétablir certaines capacités au moyen de jetons explicites.

Il s’agit d’un modèle de capacités : le code reçoit des pouvoirs particuliers au lieu d’hériter de tous les privilèges détenus par son hôte. L’hôte peut autoriser le rendu et les calculs tout en refusant les téléchargements, la navigation de niveau supérieur ou le stockage de même origine.

La documentation des navigateurs signale également une combinaison dangereuse. Un frame de même origine auquel sont accordés à la fois les scripts et les privilèges de même origine peut supprimer son propre attribut sandbox dans certaines conditions.

Cet avertissement illustre la règle plus générale. Un sandbox ne reste utile que lorsque sa configuration, la conception de son origine et les interfaces qui l’entourent préservent la séparation prévue.

Servir le code d’extension depuis une origine distincte peut limiter les dommages si ce code devient hostile. Cela empêche également l’accès direct au Document Object Model de la page hôte selon la politique de même origine du navigateur.

La communication peut passer par postMessage, qui permet aux fenêtres d’échanger des messages structurés entre origines. L’hôte doit néanmoins valider l’expéditeur, le type de message, la charge utile et l’opération demandée.

Un pont de messages non sécurisé peut annuler une configuration iframe soigneuse. Si le code généré peut envoyer « supprimer tous les enregistrements » à un hôte qui ne pose aucune question, bloquer l’accès direct à la base de données n’offre qu’un faible réconfort.

Une meilleure conception expose des verbes étroits. Une extension pourrait demander readSelectedDocuments, renderChart ou proposeMetadataUpdate, sous réserve d’autorisation et de validation.

Les changements sensibles doivent passer par le noyau responsable. Ce noyau peut vérifier l’utilisateur actif, la version actuelle de l’enregistrement, l’ensemble des champs autorisés et la politique organisationnelle applicable.

Il peut également exiger une confirmation. Lire des valeurs approuvées pour un graphique est différent de l’envoi de ces valeurs vers un serveur externe.

La politique de sécurité du contenu ajoute une autre couche. Une politique de contenu permet aux sites de restreindre les origines possibles des scripts, images, cadres, styles et requêtes réseau.

Pour les extensions générées, le contrôle réseau compte autant que l’exécution du code. Un widget d’apparence inoffensive peut devenir un canal d’exfiltration de données s’il peut transmettre le contenu de l’application vers des domaines arbitraires.

Une politique stricte peut bloquer la plupart des connexions sortantes. L’hôte pourrait alors relayer les requêtes approuvées via un service appliquant l’authentification, les limites de débit, la journalisation et les règles de destination.

WebAssembly offre un autre environnement d’exécution possible pour les calculs bornés. Son modèle de sécurité décrit une exécution dans un environnement isolé et un accès via des API explicites fournies par l’intégrateur.

WebAssembly ne détermine pas les autorisations du produit. Il fournit un format d’exécution de plus bas niveau qui peut favoriser l’isolation lorsqu’il est associé à un hôte soigneusement conçu.

Certaines extensions n’auront besoin d’aucun code arbitraire. Un produit peut demander au LLM de générer une spécification déclarative décrivant les champs, filtres, mises en page, calculs et actions autorisées.

L’application interprète ensuite cette spécification à l’aide de composants de confiance. Cette approche limite l’expressivité, mais rend le comportement plus facile à inspecter et à valider.

D’autres tâches nécessitent du véritable code. La transformation de données, les visualisations personnalisées et l’analyse spécialisée dépassent souvent les limites d’un schéma fixe.

Une plateforme mature pourrait prendre en charge plusieurs niveaux d’exécution. Les extensions simples utilisent des règles déclaratives. Les plus complexes exécutent JavaScript ou WebAssembly sous un contrôle plus strict et avec des autorisations plus limitées.

L’hôte doit traiter la sortie du modèle comme non fiable à tous les niveaux. Une intention exprimée en langage naturel ne garantit pas que le code généré met en œuvre cette même intention.

Le modèle peut mal interpréter un champ, inverser une condition, omettre un cas limite ou dépendre d’un comportement non documenté. Il peut aussi reproduire des pratiques dangereuses apprises à partir de code public.

L’injection de prompt ajoute un autre risque. Une extension qui traite des documents ou des pages web peut rencontrer du texte conçu pour modifier le comportement du modèle.

Les recommandations d’OWASP sur l’injection de prompt expliquent pourquoi les instructions du modèle et les données externes ne peuvent pas toujours être séparées proprement. Le filtrage seul n’élimine pas le problème.

L’environnement d’exécution devrait donc supposer que la logique générée peut être erronée, même en l’absence d’attaquant. Les autorisations limitent les conséquences, tandis que les tests et les aperçus aident à détecter les erreurs.

Un flux de création utile présenterait le comportement demandé, l’implémentation générée, les entrées déclarées, les autorisations et un exemple de sortie avant l’installation.

L’extension devrait recevoir des jeux de données de test plutôt que des données de production lors de sa première exécution. Les utilisateurs peuvent comparer le comportement attendu et réel sans risquer un changement irréversible.

Pour les opérations d’écriture, l’hôte peut présenter un diff. L’extension propose des modifications, et le noyau ne les applique qu’après validation ou confirmation.

La possibilité d’annuler compte également. Si une extension met à jour correctement de nombreux enregistrements selon une mauvaise règle, le sandbox a techniquement réussi alors que l’utilisateur a tout de même subi un préjudice.

Une plateforme responsable a besoin d’un historique immuable ou d’opérations compensatoires. Elle doit identifier quelle révision d’extension a provoqué chaque changement et qui a approuvé son exécution.

C’est là que le « noyau responsable » de Morrell pèse davantage que les « primitives modernes de sandbox ». Le sandboxing réduit le coût d’infrastructure de l’isolation. La responsabilité exige une conception produit, une gouvernance et une discipline opérationnelle.

L’extension générée doit rester subordonnée à ces systèmes. Sinon, la plateforme ne fait que déplacer une large capacité d’action de l’IA dans une fenêtre plus petite.

La couche manquante est une gouvernance pour le code jetable

La génération de code bon marché crée un problème de maintenance, car les extensions utiles restent rarement jetables.

Un utilisateur peut générer un outil ponctuel pour une réunion et ne plus jamais l’ouvrir. C’est le cas le plus simple, car la valeur et le risque de l’extension prennent fin ensemble.

Les extensions réussies se comportent différemment. Des collègues les copient, les flux de travail commencent à en dépendre et des hypothèses temporaires deviennent une infrastructure officieuse.

À ce stade, l’attribution de l’auteur devient complexe. L’utilisateur a fourni l’intention, le modèle a fourni une grande partie de l’implémentation et l’hôte a fourni les interfaces et les contrôles d’exécution.

La plateforme a toujours besoin d’un propriétaire responsable. Quelqu’un doit décider si l’extension reste valide lorsque les données, politiques ou API de l’application changent.

Le code généré peut être peu coûteux à remplacer, mais le flux de travail qui l’entoure ne l’est pas nécessairement. Une équipe peut dépendre d’un rapport pour prendre des décisions opérationnelles ou financières.

Le noyau responsable devrait classer les extensions selon leur portée et leurs conséquences. Une vue personnelle en lecture seule mérite un processus plus léger qu’une automatisation à l’échelle de l’organisation avec accès en écriture.

La promotion peut déclencher des contrôles plus rigoureux. Le partage d’une extension pourrait nécessiter des tests automatisés, un propriétaire désigné, une revue des autorisations et une date d’expiration.

Un déploiement plus large pourrait exiger l’approbation d’un administrateur ou du propriétaire de l’application. La revue devrait se concentrer sur les capacités et les flux de données, pas uniquement sur le code source.

La revue de code seule est insuffisante, car le code généré peut changer fréquemment. Les réviseurs ont besoin de descriptions stables de ce qu’une extension lit, envoie, modifie et conserve.

Ces descriptions devraient être appliquées plutôt que décoratives. Si une extension déclare qu’elle lit des enregistrements sélectionnés, l’environnement d’exécution devrait empêcher l’accès à des enregistrements non liés.

Le versioning est tout aussi important. Régénérer une extension après une demande utilisateur crée un nouveau comportement, même si le nom visible reste inchangé.

La plateforme devrait conserver chaque révision, sa demande de génération, la configuration du modèle, les autorisations, les tests et son statut d’approbation. Les utilisateurs existants ne devraient pas recevoir de changements silencieux.

Les mises à jour de modèles introduisent une autre incertitude. La même instruction peut produire un code différent après qu’un fournisseur a modifié un modèle.

La reproductibilité peut nécessiter de stocker l’artefact généré plutôt que de le régénérer à chaque exécution. L’artefact peut être testé et signé avant son exécution.

Les dépendances créent un risque connexe. Autoriser le code généré à importer des paquets arbitraires élargit la surface de confiance et complique l’exploitation à long terme.

Une bibliothèque standard contrainte serait moins flexible, mais plus fiable. L’hôte pourrait fournir des composants validés pour les graphiques, l’analyse, les dates, le stockage et l’interaction utilisateur.

Les extensions pourraient combiner ces composants sans télécharger de nouveau code. Lorsqu’une vulnérabilité apparaît, la plateforme pourrait mettre à jour le composant partagé de façon centralisée.

L’expérience utilisateur a également besoin de limites. Demander aux personnes d’approuver une longue liste d’autorisations techniques conduit à l’habituation plutôt qu’à un consentement éclairé.

Les demandes d’autorisation devraient décrire les conséquences dans le langage de la tâche. « Envoyer les documents sélectionnés à api.example.com » est plus utile qu’une invite générique d’accès réseau.

Les paramètres par défaut devraient favoriser le comportement en lecture seule, les périmètres limités et les autorisations temporaires. L’accès persistant devrait exiger une justification liée à un flux de travail récurrent.

L’objection la plus forte à l’hypothèse de Morrell n’est donc pas que le sandboxing échoue. C’est que la démonstration attrayante s’arrête avant que la gouvernance ne commence.

Un widget généré peut sembler réussi après un seul prompt. Un système d’extensions fiable doit survivre à l’usage partagé, aux changements de politique, aux entrées malveillantes, aux changements de modèle et au renouvellement du personnel.

Ce travail peut dépasser le coût initial de l’écriture du code. Il ne disparaîtra pas parce que l’application s’exécute dans un navigateur.

Il existe aussi un risque de conception produit. Une personnalisation sans fin peut rendre une application plus difficile à comprendre, à prendre en charge et à utiliser de manière cohérente.

Deux collègues peuvent voir des commandes, champs et calculs différents dans ce qui semble être le même produit. Les équipes de support peuvent avoir du mal à reproduire un problème.

Les organisations peuvent réagir en standardisant les extensions qui réussissent. La plateforme peut observer des besoins locaux récurrents et promouvoir des solutions mûres en fonctionnalités prises en charge.

Cela crée une boucle de rétroaction utile. Les utilisateurs explorent la longue traîne, tandis que le fournisseur identifie les schémas qui méritent une conception et une maintenance permanentes.

Le modèle ne remplace pas l’équipe produit dans cette boucle. Il aide les utilisateurs à prototyper des preuves de besoins non satisfaits.

Les extensions qui restent limitées peuvent demeurer locales. Celles qui deviennent importantes peuvent passer par une revue plus rigoureuse et finir par intégrer le noyau.

C’est plus responsable que de traiter chaque artefact généré comme jetable ou prêt pour la production. Cela reconnaît que le statut d’un logiciel change lorsque des personnes commencent à en dépendre.

La question non résolue est de savoir si les fournisseurs construiront ce cycle de vie avant que les utilisateurs ne créent un écosystème fantôme incontrôlé. Les LLM rendent déjà la génération de code assez facile pour dépasser la gouvernance.

Ce que les lecteurs de Simon Willison devraient surveiller ensuite

L’hypothèse gagnera en crédibilité lorsque les produits proposeront des systèmes d’extensions contraints que les utilisateurs ordinaires peuvent exploiter sans accorder un large accès aux agents.

Le premier signal est un véritable modèle d’autorisations conçu pour les extensions générées. Recherchez des produits qui proposent des capacités limitées, des origines d’exécution distinctes, des contrôles réseau sortants et des manifestes d’autorisations lisibles.

Une implémentation convaincante fera du refus le comportement par défaut. Les extensions ne devraient recevoir que les données et opérations nécessaires à leur objectif déclaré.

La preuve la plus solide viendrait d’un système qui gère l’accès en écriture de manière sûre. Aperçus, diffs, confirmations, enregistrements d’audit et annulation devraient fonctionner ensemble plutôt que d’apparaître comme des options distinctes.

Si les fournisseurs livrent ces contrôles, le modèle de noyau responsable de Morrell devient nettement plus solide. Si les extensions exigent régulièrement des jetons étendus ou un accès complet à la page, le modèle s’affaiblit.

Le deuxième signal concerne la manière dont les plateformes gèrent une extension après sa première exécution réussie. Les démonstrations de création abondent, mais les preuves concernant le cycle de vie restent plus précieuses.

Recherchez l’épinglage de versions, les tests automatisés, la propriété, l’expiration, les contrôles des dépendances et un chemin de promotion de l’usage personnel à l’usage en équipe.

Une plateforme devrait également montrer ce qui se passe après un changement de son API. Les extensions ont besoin de contrats de compatibilité ou d’échecs explicites, pas de résultats silencieusement incorrects.

Une gestion réussie du cycle de vie démontrerait que la création bon marché ne produit pas une dette logicielle ingérable. Des pannes fréquentes renforceraient le point de vue sceptique.

Le troisième signal est le comportement des utilisateurs. La théorie repose sur le fait que les personnes créent des outils spécifiques qui restent plus sûrs et plus utiles que des agents généralistes ou des contournements externes.

Parmi les mesures utiles figurent la réutilisation des extensions, les refus d’autorisation, la fréquence des annulations, le temps de réparation et la part des créations qui deviennent des flux de travail récurrents.

Ces chiffres doivent être interprétés avec prudence. Un nombre élevé de créations peut indiquer de l’expérimentation, de la confusion ou de la nouveauté plutôt qu’une valeur durable.

Le résultat le plus révélateur est de savoir si les utilisateurs résolvent des tâches auparavant négligées sans augmenter les incidents de sécurité ou la charge du support.

Les chercheurs et acheteurs en entreprise devraient également surveiller où les extensions s’exécutent. L’isolation du navigateur est attrayante, mais certaines charges de travail nécessitent des fichiers locaux, des services privés ou des calculs intensifs.

Les plateformes peuvent utiliser des conteneurs distants, des isolats en périphérie, des environnements d’exécution WebAssembly ou des combinaisons de ces systèmes. Chaque choix modifie la latence, le coût, l’exposition des données et la responsabilité opérationnelle.

Le navigateur reste précieux, car il assure déjà la médiation entre les origines, les autorisations et les interactions utilisateur. Ses contrôles sont également largement compris par les équipes de sécurité.

Pourtant, aucun environnement d’exécution ne peut déduire la bonne autorisation métier à partir de code généré. L’hôte doit fournir cette politique depuis son noyau de confiance.

Pour les développeurs, la question pratique n’est pas de savoir si les LLM peuvent écrire une extension. Ils produisent déjà suffisamment souvent du code utile pour que cet espace de conception soit pertinent.

La question est de savoir si une application peut rendre l’échec ordinaire et récupérable. Une mauvaise sortie doit être confinée, visible, réversible et peu coûteuse à remplacer.

Pour les acheteurs en entreprise, demandez aux fournisseurs de démontrer une extension hostile ou incorrecte, et pas seulement une extension qui fonctionne. Observez aux quelles données elle peut accéder et quelles actions l’hôte refuse.

Pour les travailleurs du savoir, recherchez une personnalisation qui reste compréhensible une fois la conversation terminée. Vous devez pouvoir examiner ce que fait l’outil, le modifier, le désactiver et identifier ses effets.

La citation de Simon Willison est importante, car elle présente le code généré par l’IA comme un composant plutôt que comme le produit dans son ensemble. Ce cadrage modeste donne à l’idée sa crédibilité.

L’hypothèse de Morrell n’exige pas que chaque utilisateur devienne ingénieur logiciel. Elle exige que les applications exposent des matériaux sûrs qu’un LLM peut assembler sous la direction de l’utilisateur.

L’opportunité est réelle, mais le produit gagnant ne sera pas celui qui génère le plus de code. Ce sera celui qui rend les comportements générés responsables et traçables.

Lors de l’évaluation du prochain produit d’IA extensible, demandez une personnalisation limitée, puis fournissez-lui délibérément une entrée trompeuse. Pouvez-vous voir ses autorisations, examiner les modifications qu’il propose et annuler le résultat ?

Ces questions en révèlent davantage qu’une démonstration de génération soignée. Elles permettent de vérifier si le produit a construit le noyau solide décrit par Morrell.

Continuez à suivre la couverture de Simon Willison pour des implémentations concrètes, mais appliquez le même critère à chacune d’elles. Le système se contente-t-il d’exécuter du code écrit par l’IA, ou rend-il ce code gouvernable durant toute sa vie utile ?