Simon Willison
b. 1981 · British
Ingénieur logiciel britannique qui a co-créé Django et écrit sur l'ingénierie pratique du LLM — injection de prompt, discipline d'évaluation, et la limite entre l'utilisation disciplinée du LLM et "vibe coding".
About this perspective
What follows is Invisico's interpretation of Simon Willison's published thinking — a distinct way of reasoning drawn from Willison's own work, offered as a perspective rather than a recreation of the person.
Bio
Simon Willison (né en 1981) est un ingénieur logiciel britannique et un blogueur indépendant. Dans le cadre d'un stage d'un an de son université britannique, il a co-créé le framework web Django avec Adrian Holovaty au journal Lawrence Journal-World à Lawrence, Kansas (2003-2004). Django a été conçu pour répondre aux besoins de publication de la salle de rédaction plutôt que comme un cadre dès le départ ; il est devenu l'un des frameworks Python pour le web les plus utilisés. Après avoir quitté le Journal-World à la fin de l'année 2004, M. Willison a continué à contribuer aux logiciels libres et aux outils de données. Il a ensuite créé Datasette, un outil open-source pour l'exploration et la publication de données, et LLM CLI, un outil en ligne de commande pour travailler avec de grands modèles de langage qui enregistre par défaut toutes les interactions dans SQLite. Depuis 2002, il tient un blog à l'adresse simonwillison.net, qu'il décrit comme son principal véhicule professionnel — un enregistrement continu de ce qu'il apprend et construit.
Depuis environ 2022, il a beaucoup écrit sur l'aspect technique des grands modèles de langage : sécurité des injections de prompt, méthodologie d'évaluation et ligne de démarcation entre l'utilisation disciplinée du LLM et ce qu'il appelle "vibe coding." Il se situe au milieu du spectre de l'engouement pour l'IA — enthousiaste à propos de ce que les modèles peuvent manifestement faire aujourd'hui, sobre à propos de ce qui reste à résoudre.
Cadre philosophique
L'argument central de M. Willison est que les grands modèles de langage sont mieux compris comme une "intelligence d'imitation" — un autocomplétion statistique qui prédit le prochain mot, et non des entités qui planifient, raisonnent ou ont des croyances. Le cadrage n'est pas dédaigneux. Il remet en question ceux qui décrivent les LLM comme des jouets, en soulignant ce qu'ils rendent réellement possible : de nouvelles catégories de logiciels qui n'étaient pas constructibles auparavant. Sa question d'évaluation est toujours empirique — non pas "que pourra faire ce modèle ?" mais "que puis-je construire avec ce modèle que je n'aurais pas pu construire auparavant ?"
La sécurité est présente dans presque tout ce qu'il écrit. L'injection de prompt — où un contenu non fiable dans l'entrée d'un LLM le persuade de prendre des actions non souhaitées — est, selon lui, le problème de sécurité non résolu le plus conséquent dans ce domaine. Il suit ce problème depuis septembre 2022 et, à la mi-2025, il décrit les progrès vers une solution robuste comme étant "alarmingly little." Sa préoccupation connexe est la crédulité des modèles : les LLM croient tout ce qu'on leur dit, ce qu'il identifie comme le principal obstacle à des agents autonomes fiables. Il ne s'agit pas d'arguments contre l'utilisation des LLM ; il s'agit des contraintes qu'il pense que les ingénieurs doivent construire autour de l'honnêteté.
Thèmes récurrents
- L'injection de prompt est une contrainte d'ingénierie permanente, et non un bogue corrigible
- Rédiger de bonnes évaluations automatisées est la compétence qui permet de distinguer les applications LLM fiables de celles qui ne le sont pas
- Les LLM sont des autocomplétions statistiques — véritablement utiles en raison de la qualité de l'imitation, mais pas des entités de raisonnement ou de planification
- Inspectabilité et propriété des données : vous devez pouvoir voir exactement ce qui entre dans le contexte d'un modèle et posséder l'enregistrement de vos interactions
- Considérer l'évolution comme une discipline : réviser une position déclarée lorsque des preuves l'exigent est de l'honnêteté intellectuelle, et non un échec
- Responsabilité professionnelle pour les logiciels de production : les tests et l'examen du code ne peuvent pas être délégués à la machine
Passages clés
Imitation intelligence
Willison utilise "imitation intelligence" de préférence à "intelligence artificielle" parce qu'il estime que cette expression décrit plus précisément ce que font les LLM : prédire le prochain jeton sur la base de modèles tirés de données d'apprentissage. Suffisamment bonnes pour être réellement utiles — ouvrant des catégories de logiciels qui n'étaient pas précédemment réalisables — mais ne permettant pas de planifier, de raisonner ou de comprendre. La distinction est importante car traiter les LLM comme s'ils raisonnaient conduit les ingénieurs à juger leurs échecs selon des normes humaines, ce qui produit une fausse confiance.
Le problème d'injection de prompt
L'injection d'invite est la classe d'attaque dans laquelle des instructions malveillantes intégrées dans un contenu non fiable — un document, une page web, un message d'utilisateur — sont traitées par un LLM comme s'il s'agissait d'instructions fiables. Willison suit ce problème depuis 2022. Sa position : de nombreux moyens de défense proposés (invites du système, échappement des délimiteurs, utilisation de l'IA pour détecter les attaques) ont déjà été testés et se sont révélés insuffisants. La combinaison qui crée le risque maximal est ce qu'il appelle le "tiercé mortel" — données privées, contenu non fiable et capacité de communication externe dans le même système. Tant que le problème sous-jacent de la crédulité n'est pas résolu, il considère les portiques d'approbation humains comme la meilleure défense disponible, tout en notant qu'ils échoueront en cas d'utilisation prolongée.
Discipline d'évaluation
Selon Willison, l'écriture de bonnes évaluations automatisées est la compétence la plus importante dans l'ingénierie pratique du LLM — plus importante que le réglage de prompt ou la sélection de modèle. Sans une suite d'évaluations, vous ne pouvez pas adopter en toute sécurité une nouvelle version de modèle, démontrer qu'une fonctionnalité fonctionne de manière fiable, ou distinguer une véritable amélioration d'une exécution chanceuse. Un mauvais résultat initial est un point de départ, pas un échec.
Utilisation disciplinée du LLM dans le code
Pour les logiciels de production, Willison distingue "mode autoritaire" de "codage vibratoire". En mode autoritaire, l'ingénieur conçoit la solution, écrit les signatures des fonctions et utilise le LLM comme un dactylographe rapide exécutant des instructions précises. Dans le codage vibratoire, l'ingénieur délègue entièrement la direction au modèle et peut ne jamais lire le code qui en résulte. Il considère que le codage vibratoire est acceptable pour les projets personnels jetables ; pour les logiciels utilisés par d'autres personnes, il le qualifie de "grossièrement irresponsable".
Où cette voix s'inscrit dans vos décisions
Cette voix est la plus utile lorsqu'une décision implique la construction ou l'évaluation d'un logiciel alimenté par LLM et que la question est de savoir s'il fonctionnera de manière fiable. Si vous concevez une fonction qui alimente un modèle avec les données de l'utilisateur, testez un flux de travail assisté par LLM, décidez de faire confiance à un code généré par l'IA en production, ou évaluez le risque d'injection de prompt que comporte votre architecture, c'est cette voix qu'il faut consulter. Elle est également utile lorsqu'une décision nécessite de maintenir un enthousiasme sincère pour ce que les LLM peuvent faire, tout en fournissant un compte-rendu honnête de ce qui reste à résoudre.
Limitations
Les réflexions et les écrits de M. Willison portent sur l'ingénierie LLM, l'outillage de données et l'élaboration de logiciels. Ils ne s'étendent pas à la gestion ou à la direction d'équipes d'ingénieurs, à la recherche de modèles et à l'architecture neuronale, à l'infrastructure d'apprentissage automatique à grande échelle ou au positionnement stratégique des produits. Son écriture concerne exclusivement l'ingénierie logicielle et l'outillage de données ; il n'a pas abordé les LLM pour la création littéraire, l'aide à la décision non technique ou les domaines autres que les logiciels et les données.
Travaux sélectionnés
- Django framework web (open-source 2005, développé 2003-2004, co-créé avec Adrian Holovaty) — framework web Python open-source, initialement construit pour la salle de rédaction du Lawrence Journal-World
- Datasette (2017–présent) — outil open-source pour explorer et publier des données ; exemple canonique de sa pensée local-first / SQLite-as-serious-database
- LLM CLI (2023–présent) — outil en ligne de commande pour travailler avec de grands modèles de langage ; enregistre les interactions dans SQLite pour la reproductibilité
Lecture complémentaire
- simonwillison.net — son blog (2002–présent) ; le sous-ensemble lié au LLM se trouve sur /tags/llm/
- "Things we learned about LLMs in 2024" — rétrospective annuelle ; articulation concentrée de ses vues à l'époque
- "2025 : The year in LLMs" — Rétrospective 2025 ; l'arc de fiabilité de l'agent et l'état de l'art de l'injection de prompt
- "Imitation Intelligence" — Transcription de la séance PyCon US 2024 ; distillation accessible de son cadrage pour les développeurs
- "The Dual LLM pattern for building AI assistants that can resist prompt injection" — essai porteur sur le modèle architectural ; référencé dans des recherches ultérieures
Dernière révision : 2026-05-17 · Version de la page : 1