ASD-STE100, français rationalisé : et si un standard technique permettait d'écrire de meilleurs prompts ?

ASD-STE100 : pourquoi l'aéronautique a-t-elle normalisé l'écriture ?

ASD-STE100 Simplified Technical English est un langage naturel contrôlé destiné à la documentation technique. Son origine remonte aux travaux lancés au début des années 1980 par l'industrie aéronautique européenne, avec une première publication du guide en 1986. La version actuelle, Issue 9, a été publiée en janvier 2025.

Le standard repose sur deux éléments complémentaires : des règles d'écriture et un dictionnaire contrôlé. L'objectif n'est pas de produire un anglais élégant. Il faut réduire l'ambiguïté, faciliter la compréhension par des lecteurs dont l'anglais n'est pas toujours la langue maternelle et rendre les procédures techniques plus sûres.

Cela passe notamment par un vocabulaire maîtrisé, des phrases courtes, des instructions explicites et l'emploi cohérent des mêmes termes pour désigner les mêmes choses. Dans un manuel de maintenance, varier les synonymes pour rendre un texte plus agréable peut au contraire créer un doute.

Le français rationalisé poursuit la même logique

La France a développé une démarche comparable avec le français rationalisé, associé historiquement au GIFAS. Des travaux universitaires consacrés aux langages contrôlés décrivent ce guide comme une adaptation française créée dans le sillage du Simplified English. Son objectif était de produire des textes français plus faciles à comprendre et plus simples à traduire vers l'anglais technique simplifié.

Le français rationalisé ne doit pas être présenté comme la version française actuelle et officielle d'ASD-STE100. Il s'agit d'un guide historique de rédaction contrôlée. Pour un cadre français contemporain plus général, la NF ISO 24495-1, publiée en 2024, traite du langage clair et simple. Elle s'applique notamment aux documents destinés au public, à la rédaction technique et à l'usage de langages contrôlés.

Ces approches ne poursuivent pas exactement le même but, mais elles partagent une idée : la clarté peut être décrite par des règles plus précises que « écris clairement ».

Pourquoi cela peut-il améliorer un prompt ?

Un prompt comme « écris de manière claire, naturelle et professionnelle » laisse au modèle plusieurs décisions : quelle longueur de phrase est acceptable, quel niveau de vocabulaire utiliser, combien d'idées placer dans un paragraphe, s'il peut employer des synonymes ou ajouter des transitions.

Une consigne inspirée d'un langage contrôlé remplace une partie de cette interprétation par des critères observables :

• une idée principale par phrase
  
• phrases courtes
  
• voix active quand elle rend l'acteur plus clair
  
• même terme pour le même concept
  
• verbes d'action plutôt que formulations abstraites
  
• suppression des introductions et transitions qui n'apportent aucune information
  

Ce n'est pas une garantie qu'un LLM produira un texte conforme à ASD-STE100. Un vrai contrôle STE nécessite notamment de vérifier le vocabulaire autorisé, le sens des mots et leur catégorie grammaticale. En revanche, transformer une préférence stylistique en contraintes vérifiables est directement utile dans un prompt.

Exemple 1 : remplacer « sois concis » par des règles

Prenons une consigne classique :

Explique cette fonctionnalité de manière claire, concise et professionnelle.

Elle peut facilement produire :

> Notre plateforme innovante permet aux utilisateurs de bénéficier d'une synchronisation fluide et transparente de leurs données afin d'améliorer leur expérience globale.

On peut remplacer les adjectifs par des contraintes :

Une idée par phrase. Utilise des phrases de moins de 20 mots. Utilise un verbe d'action. Supprime les adjectifs qui n'ajoutent pas d'information. N'utilise pas de synonyme pour désigner la même fonction.

La sortie attendue devient plus facile à cadrer :

> La plateforme synchronise vos données entre vos appareils. La synchronisation se fait automatiquement lorsque vous êtes connecté.

Le second prompt ne demande pas au modèle d'interpréter ce que signifie « professionnel ». Il lui donne des critères que l'on peut relire ou tester.

Exemple 2 : éviter l'ambiguïté dans une instruction

Une instruction générée par une IA peut être grammaticalement correcte tout en restant imprécise :

> Une fois les paramètres correctement configurés, le système peut être redémarré si nécessaire afin que les changements puissent être pris en compte.

Une version inspirée de la rédaction contrôlée sépare les actions :

> Enregistrez les paramètres. Redémarrez le système. Le système applique les nouveaux paramètres au démarrage.

Le changement paraît minime, mais il supprime plusieurs ambiguïtés : qui agit, à quel moment, et si le redémarrage est facultatif ou nécessaire.

Pour un agent IA chargé d'exécuter des étapes, cette différence compte encore davantage. Une phrase décorative gêne peu un lecteur humain. Une instruction ambiguë peut produire une mauvaise action.

Exemple 3 : lutter contre le style IA sans écrire « ne fais pas IA »

Les prompts éditoriaux accumulent souvent les interdictions : « pas de fluff », « pas de ton robotique », « pas de clichés », « écris naturellement ». Ces consignes peuvent aider, mais elles restent difficiles à mesurer.

On peut reformuler une partie du problème :

Chaque paragraphe commence par un fait, un argument ou un exemple. Supprime toute première phrase qui peut être retirée sans perte d'information. Une phrase ne doit contenir qu'une idée principale. Préfère un verbe précis à une expression abstraite. N'ajoute pas de conclusion qui répète le paragraphe.

Avant :

> Dans un monde où l'intelligence artificielle évolue à un rythme sans précédent, il devient essentiel de comprendre les nombreux enjeux liés à son adoption. Cette technologie puissante transforme profondément notre manière de travailler.

Après :

> Les assistants IA rédigent déjà des mails, résument des documents et modifient du code. Leur adoption change surtout la façon dont certaines tâches sont découpées et contrôlées.

La seconde version n'est pas meilleure parce qu'elle imite un ton humain. Elle répond à des règles plus précises.

Exemple 4 : transformer une règle de style en test automatique

L'intérêt devient encore plus évident dans un système de production. Une consigne comme sois lisible est difficile à vérifier automatiquement. Une règle comme aucune phrase ne dépasse 25 mots peut être testée par un script.

Même logique pour utilise toujours le terme client et jamais utilisateur, chaque procédure commence par un verbe d'action, n'utilise pas plus de trois niveaux de titres ou chaque réponse JSON doit contenir les champs id, status et message.

Le prompt cesse alors d'être la seule barrière de qualité. Les règles peuvent être partagées entre instruction au modèle et validation après génération. C'est probablement la leçon la plus utile des langages contrôlés pour les LLM : quand une règle compte, mieux vaut pouvoir la contrôler que demander au modèle de faire « au mieux ».

Faut-il demander directement « écris en ASD-STE100 » ?

Pas forcément. ASD-STE100 a été conçu pour de la documentation technique, pas pour un article, un roman, une publicité ou une conversation. Ses contraintes peuvent rendre un texte très efficace pour expliquer une procédure et beaucoup moins agréable pour raconter une histoire.

Demander à un LLM de respecter ASD-STE100 ne prouve pas non plus que le résultat est conforme au standard. Le modèle peut reproduire quelques caractéristiques visibles tout en utilisant un mot non approuvé ou un sens interdit par le dictionnaire.

La piste la plus utile consiste donc à reprendre les principes adaptés au contexte, puis à les traduire en règles explicites. Un article peut conserver une voix personnelle tout en imposant des phrases plus courtes. Une documentation peut aller plus loin avec un vocabulaire contrôlé. Une API peut transformer certaines règles en tests automatisés.

Le prompt engineering ressemble alors moins à l'art de trouver la bonne formule et davantage à un travail de spécification.