Une Agent Skill qui impose la rédaction de documents en anglais technique simplifié ASD-STE100

• SimpleEnglish est une Agent Skill qui amène les LLM à rédiger des documents techniques courts et sans ambiguïté, conformément au langage contrôlé ASD-STE100 utilisé dans l’aérospatiale depuis 1983.
• Elle applique 53 règles : limite de longueur des phrases, voix active, temps simples, placement des conditions avant les actions, une seule instruction par phrase, etc. Elle prend en charge les documents, messages d’erreur, runbooks, rapports d’incident, notes de version, prompts et la préparation à la traduction.
• Dans une évaluation de 96 exécutions comparant 6 modèles Claude et 8 tâches sous deux conditions, les violations STE par 100 mots ont diminué de 72,9 % en moyenne, et le nombre de tokens de sortie a aussi baissé pour tous les modèles.
• Elle peut être installée sans dépendances dans Claude Code, Cursor, VS Code Copilot, OpenAI Codex, Gemini CLI et d’autres environnements compatibles avec le standard Agent Skills. Dans les environnements non compatibles, elle peut être appliquée via un prompt système ou des instructions utilisateur.
• Les résultats ne constituent pas une certification officielle ASD et ne s’appliquent pas au marketing, aux blogs ni au ton de marque. Le mode par défaut combine des règles de structure et le vocabulaire métier, et le mode strict nécessite le standard officiel pour les décisions mot à mot.

---

Le problème que résout le projet

• SimpleEnglish est une Agent Skill qui transforme les phrases emphatiques et ambiguës des LLM en phrases techniques proches de l’ASD-STE100 Simplified Technical English.
• ASD-STE100 est un langage contrôlé utilisé dans l’aérospatiale depuis 1983 pour éviter qu’un technicien de maintenance fatigué interprète mal des instructions.
• La différence entre le texte original généré par Claude et le résultat avec la Skill se situe dans le niveau de précision et le caractère exécutable.
  • Une phrase comme « synchronise de façon transparente grâce à une architecture robuste » devient une description indiquant qu’une table Postgres est copiée vers S3 et qu’un fichier de configuration est nécessaire.
  • Un message générique d’échec de connexion devient une erreur de mot de passe pour l’utilisateur app et une action de correction sur DB_PASSWORD.
  • Une formulation d’incident indiquant que des utilisateurs non précisés ont pu être affectés devient une description avec l’heure de l’échec, 12 % de requêtes en échec, la cause liée au déploiement et l’heure du rollback.
• D’autres comparaisons pour README, messages d’erreur, rapports d’incident et notes de version figurent dans examples/before-after.md.

Installation et environnements compatibles

• Elle fonctionne dans environ 25 harnais compatibles avec le standard Agent Skills, dont Claude Code, Cursor, VS Code Copilot, OpenAI Codex, Gemini CLI, Goose et OpenCode.
• Le projet se compose d’un seul dossier, n’a aucune dépendance externe et utilise la licence MIT.
• La commande d’installation est la suivante :

npx skills add AminBlg/SimpleEnglish

• Le skills CLI détecte les agents installés et installe la Skill dans la cible choisie par l’utilisateur.
• Avant l’installation, il est possible de l’essayer avec la commande suivante :

npx skills use AminBlg/SimpleEnglish@simple-english

• Dans les environnements qui ne prennent pas en charge SKILL.md, il est possible d’ajouter prompts/system-prompt.md au prompt système, à AGENTS.md ou à .cursorrules.
  • Une version d’environ 60 tokens est aussi fournie pour les environnements à budget de tokens réduit.
  • On peut l’utiliser en demandant la rédaction d’un document technique ou en indiquant « rewrite this with simple-english ».

Utilisation dans les environnements sans terminal

• Les forfaits payants Claude.ai prennent en charge les Skills nativement.
  • Enregistrez SKILL.md.
  • Activez l’exécution de code dans Settings → Capabilities.
  • Téléversez le fichier dans Settings → Customize → Skills → Upload.
  • Lorsque la Skill est activée, elle s’applique aux demandes de rédaction de documentation technique.
• ChatGPT ne prend pas en charge les Skills ; il faut donc utiliser la version prompt.
  • Ajoutez le bloc de prompts/system-prompt.md dans Settings → Personalization → Custom Instructions, dans les instructions d’un Project ou d’un Custom GPT.
• Dans Gemini, créez un Gem et collez le même prompt dans les instructions.
• Dans les autres chatbots, joignez le fichier de prompt ou collez son contenu, puis demandez son application à toutes les sorties.

Règles de rédaction issues d’ASD-STE100

• La Skill applique aux documents techniques les 53 règles réparties en 9 sections créées en 1983.
• Les règles principales sont les suivantes :
  • Limiter les instructions à 20 mots et les phrases explicatives à 25 mots.
  • Utiliser un seul sens par mot dans tout le document pour éviter le mélange d’expressions comme check, verify, confirm et validate.
  • Utiliser uniquement des temps simples et écrire directement qui a modifié quoi, au lieu de « has been updated ».
  • Ne pas utiliser les formes verbales en -ing ni les propositions supplémentaires qui s’y rattachent.
  • Utiliser la voix active pour supprimer les tournures indirectes comme « it should be noted that ».
  • Interdire should, would, may et might, mais autoriser can, will et must.
  • Placer la condition avant l’ordre pour éviter que l’utilisateur lise la condition trop tard.
  • Mettre une seule instruction par phrase.
  • Conserver les articles et that, et ne pas créer de phrases télégraphiques même si elles sont courtes.
• Les règles complètes de réécriture, avec des exemples logiciels, figurent dans SKILL.md.
• Le marketing n’entre pas dans le périmètre de STE : les règles ne s’appliquent donc pas aux formulations marketing du README, et la Skill ne s’applique qu’à la rédaction documentaire.

Périmètre hors documentation technique

• use-cases.md fournit des règles adaptées à plusieurs formats.
  • Les messages d’erreur indiquent, dans l’ordre, ce qui s’est produit, la cause et ce que l’utilisateur doit faire.
  • Les runbooks sont similaires aux manuels de maintenance ; STE s’y applique directement.
  • Les rapports d’incident utilisent le passé simple et suppriment les formulations incertaines et euphémisées.
  • Pour les changements cassants dans les notes de version, l’avertissement place d’abord la commande, puis le risque.
  • AGENTS.md et les prompts système sont traités comme des procédures destinées à des lecteurs qui ne peuvent pas poser de questions, et should, que le modèle pourrait interpréter comme optionnel, est interdit.
  • Avant traduction, les documents sont restructurés dans une forme plus facile à lire pour des non-natifs et moins coûteuse à localiser.
• La Skill ne s’applique pas aux textes marketing, au style de blog ni à la rédaction de marque ; le style plat est une caractéristique intentionnelle.

Résultats du benchmark

• L’évaluation a exécuté 8 tâches de rédaction sur 6 modèles Claude, avant et après application de la Skill, soit 96 résultats générés au total.
• Les violations STE par 100 mots ont diminué de 72,9 % en moyenne globale.
  • claude-opus-4-8 : baisse de 1,05 à 0,62, soit une amélioration de 41 %.
  • claude-opus-4-7 : baisse de 2,28 à 0,42, soit une amélioration de 82 %.
  • claude-opus-4-6 : baisse de 2,24 à 0,40, soit une amélioration de 82 %.
  • claude-opus-4-5 : baisse de 2,55 à 0,57, soit une amélioration de 78 %.
  • claude-sonnet-5 : baisse de 2,67 à 0,53, soit une amélioration de 80 %.
  • claude-sonnet-4-6 : baisse de 2,06 à 0,52, soit une amélioration de 75 %.
• Pour tous les modèles, le nombre de tokens de sortie a diminué, et la longueur moyenne des phrases est passée de 11,2 à 9,7 mots.
• L’évaluation a utilisé un linter déterministe à expressions régulières appliquant les mêmes règles aux deux conditions. La méthode complète et ses limites figurent dans evals/results/RESULTS.md.
• Il suffit d’avoir le CLI Claude Code connecté pour reproduire les résultats avec la commande suivante :

python3 evals/run_bench.py

Méthode de vérification des règles

• La Skill a été construite par une approche pilotée par les tests à partir du texte original de l’Issue 9 de 2025, et non à partir d’un résumé de blog.
• L’agent de référence sans Skill écrivait des phrases de 40 mots et inventait parfois des numéros de règle inexistants.
  • Un résultat citait la règle sur les phrases courtes comme « Rule 3.1 », alors que la vraie Rule 3.1 concerne les formes verbales.
• Contrairement à certaines sources secondaires, le PDF officiel autorise can et will.
• La Skill a été rédigée pour bloquer un par un les échecs de référence enregistrés, puis testée à nouveau jusqu’à ce que l’agent réussisse. Les scénarios et résultats figurent dans evals/pressure-tests.md.

Limites d’application et statut du standard

• Les résultats ne sont pas des documents certifiés STE.
  • ASD ne certifie aucun outil.
  • Le mode par défaut combine des règles de structure et le vocabulaire métier de l’utilisateur.
  • Le mode strict se rapproche davantage du standard, mais les décisions mot à mot nécessitent le standard officiel.
• Les résultats sont rédigés comme des manuels Airbus : plats et difficiles à mal interpréter. Le style personnel est prévu pour rester dans d’autres usages, comme les blogs.
• Contrairement à une consigne subjective comme « écrivez clairement », « rédigez des phrases de 20 mots ou moins » est une spécification vérifiable, qu’un agent peut suivre.
• ASD-STE100 est un standard vieux de plus de 40 ans, mais il est maintenu et mis à jour jusqu’à l’Issue 9 de janvier 2025 ; il est numéroté et testable.

Licence et statut non officiel

• L’ensemble du dépôt est fourni sous licence MIT.
• Les règles sont reformulées à des fins pédagogiques, sans reproduire le texte de la spécification officielle ni le contenu du dictionnaire.
• Le projet n’est ni affilié à ASD ou STEMG, ni approuvé par eux, et ASD-STE100 est une marque déposée d’ASD.

[GN⁺]

Avis de Hacker News

• Il suffit d’ajouter au début d’un exemple la phrase « réécris en anglais technique simplifié ASD-STE100 » pour obtenir un résultat tout à fait correct. Une ou deux phrases d’instructions devraient suffire ; je me demande donc pourquoi une skill aussi énorme est nécessaire, alors que ASD-STE100 a de fortes chances de déjà faire partie des données d’entraînement.

  • Je comprends l’idée selon laquelle le modèle devrait exploiter de lui-même ses connaissances issues du préentraînement, mais il semble qu’aux dernières étapes de l’entraînement les données de préentraînement soient assez fortement mélangées.

• J’ai créé une skill qui applique le guide de style de The Economist aux phrases générées par les LLM : https://github.com/TAJD/economist-style-guide-plugin
  Elle produit des textes relativement bien structurés et faciles à éditer.

• C’est à propos de la mauvaise application de STE et de son adoption limitée : https://en.wikipedia.org/wiki/Simplified_Technical_English#M...

  • Une phrase dans les critiques m’a marqué : « pour écrire correctement en STE, il faut une excellente maîtrise de l’anglais et une connaissance suffisante du sujet ». Ce ne sont en fait que les conditions nécessaires pour bien écrire en anglais, dans n’importe quel domaine, que l’on utilise STE ou non.
  • Les LLM traduisent bien, donc ils devraient être particulièrement bons pour ce type d’écriture. En pratique, après l’avoir appliqué à tous mes prompts pendant la semaine écoulée, cela s’est révélé efficace pour éliminer le gras stylistique, et je n’ai pas vu du tout de redondances adjectivales excessives.

• J’aime l’idée, mais je ne suis pas convaincu par la skill elle-même. En revanche, j’ai découvert https://vale.sh et plusieurs linters, que je compte essayer.

  • STE figure déjà dans les données d’entraînement, donc la skill est redondante et ne fait que polluer la fenêtre de contexte.
  • Je me demande comment Vale pourrait être utilisé dans un travail de documentation avec des LLM.

• Cela semble faire beaucoup trop de choses, alors qu’une seule ligne dans le prompt système fonctionne déjà assez bien : « Les tokens de sortie sont précieux, réponds donc de façon concise et utilise l’anglais technique simplifié ASD-STE100. »

  • Je me demande si cela continue vraiment à bien fonctionner. Même en ajoutant des règles au profil utilisateur et à CLAUDE.md, le modèle finit par sortir de sa trajectoire et par déverser du jargon technique dans les docstrings et les explications.
    Je suis prêt à essayer tout ce qui peut rendre les explications de code plus accessibles et plus simples, donc cela m’intéresse aussi.

• L’ironie, c’est que le README affiche d’emblée un style typique des LLM, avec des formules du genre « 9 sections, 53 règles, rédigées en 1983 par des gens dont les lecteurs pouvaient mourir à cause d’une seule phrase ambiguë ». Ce n’est pas un signal très prometteur pour une skill d’écriture.

  • Ils le reconnaissent, mais je n’aime vraiment pas le style du README. On y trouve des phrases du genre : « Ce README enfreint la moitié des règles, mais le marketing est explicitement hors périmètre de STE, et la skill le sait et reste dans la documentation », ou « elle refuse les formulations marketing, le style blog et l’écriture de marque, et écrit délibérément de façon plate ».
    Chaque phrase avait aussi un emoji, supprimé sur HN.
  • Après avoir utilisé quelque temps un prompt ASD-STE100 ordinaire, j’aime un peu plus l’anglais simplifié de l’agent, mais cela ne change pas la structure globale du texte.
    Les phrases deviennent plus courtes, les introductions exagérées et les titres de sections creux façon présentation diminuent, ce qui améliore nettement la qualité, mais ce n’est pas révolutionnaire et cela ne résout pas complètement le problème.
  • Le README paraît concis et précis, et d’après mes essais il fonctionne bien. Il est meilleur que beaucoup de README écrits par des humains que j’ai vus autour de moi.

• Le tout premier exemple de la norme Issue 9 est contradictoire. Test est autorisé comme nom, mais pas comme verbe, alors que l’exemple STE dit : « Test B is an alternative to test A ».
  Sans connaître les règles propres à STE, c’est une phrase manifestement ambiguë, donc loin d’être claire. Comme le site officiel cache le téléchargement derrière un Google Form, je laisse aussi un lien direct : https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pd...

  • Je ne vois pas ce qu’il y a d’ambigu. Pour lire le premier Test comme un verbe, il faudrait supposer que that est omis dans « test whether B is an alternative to A » ; or il serait verbe au début et nom ensuite, ce qui casse le parallélisme.
    En plus, l’interprétation selon laquelle on donnerait une instruction à quelqu’un de faire cette action est en soi très peu probable.

• Je me demande si la soudaine attention portée à ASD-STE100 vient d’un tweet viral. J’en ai entendu parler par un ami et j’ai publié la spécification il y a quelques jours : https://asd-web-be-prod.azurewebsites.net/media/wunhmi5y/asd...
  La copie depuis le PDF est interdite, ce qui est étrange puisqu’on peut facilement contourner cette restriction. Pour bloquer les mots non autorisés, il faudrait un linter pour l’anglais, comme ruff ; sinon, l’agent oubliera presque certainement une instruction d’une seule ligne.

  • C’est bien un tweet viral : https://x.com/geogristle/status/2078492579511906771

• Je me demande quel effet ce type d’instructions a sur l’intelligence ou la capacité de raisonnement du modèle. Si cela modifie la sortie ou le processus de pensée, les capacités du modèle peuvent aussi changer, surtout s’il n’a pas été entraîné pendant l’apprentissage à utiliser ce type de langue.

  • Cela devrait sans doute être implémenté comme couche de post-traitement, plutôt que comme instruction.

• Dans https://youtu.be/uJblcC4lKYw, plusieurs skills et prompts, dont une skill STE, ont été comparés et évalués face aux 6 règles d’écriture de George Orwell ; globalement, Orwell a donné les meilleurs résultats.
  Cela n’ajoute pas beaucoup de tokens au contexte d’entrée, et en comparant des prompts de prose avec et sans ces règles, j’ai préféré les résultats avec règles. Il s’agit d’éviter les métaphores familières, de ne pas utiliser un mot long quand un mot court suffit, de supprimer tout mot supprimable, d’utiliser la voix active plutôt que la voix passive, d’éviter les mots étrangers, scientifiques ou techniques lorsqu’un mot courant existe, et d’enfreindre ces règles plutôt que d’écrire une phrase barbare.

  • Je ne sais pas si c’est parce que j’ai trop lu de textes générés par IA, mais le script de narration de la vidéo donne l’impression d’avoir été écrit par Claude sans appliquer une seule de ces règles.
    Il y a trop de clichés et de tournures typiques de l’IA, comme « pour être honnête, l’amélioration de la traduction était réelle mais faible », « maintenant vient la partie honnête », « la même maladie, mais des symptômes différents », ou « ce chiffre brutal de 3 % n’était pas une loi de la nature, mais une particularité de Claude ».