Et si les IA codaient dans des langages conçus pour elles ?

Nous demandons aujourd’hui aux intelligences artificielles d’écrire du Python, du JavaScript, du TypeScript ou du Rust. Des langages conçus à une époque où les humains écrivaient l’essentiel du code.

Leur syntaxe et leurs outils répondent notamment à nos besoins : comprendre un programme, travailler en équipe, retrouver une erreur, reprendre le travail d’un autre développeur.

Mais lorsque l’auteur du code devient un modèle de langage, une question apparaît : ces langages constituent-ils toujours le meilleur moyen d’exprimer un programme ?

Ce qui est pratique pour un développeur humain est-il aussi efficace pour une IA ?

Les langages actuels résultent de nombreux compromis : lisibilité, sécurité, performance d’exécution, compatibilité avec les systèmes existants. L’économie de tokens des LLM ne faisait pas partie de leurs objectifs initiaux.

Une représentation plus compacte pourrait réduire le volume à générer et à relire. Une grammaire plus régulière pourrait faciliter la production de code valide.

Pour rendre cette idée concrète, j’ai demandé à une IA d’inventer rapidement un langage hypothétique et quelques exemples de code. Appelons ce langage « Épure ».

Épure est fictif : aucune implémentation, aucun compilateur, aucun gain mesuré. L’exercice sert à explorer des choix de conception.

Prenons une opération simple : récupérer les adresses email des utilisateurs actifs.

En Python :

def active_emails(users):
    return [
        user.email
        for user in users
        if user.active
    ]

Dans notre langage hypothétique :

active_emails(users) =
  users | keep .active | map .email

Nous décidons ici que | transmet le résultat à l’opération suivante, que keep filtre une collection et que map transforme ses éléments.

Cette écriture évite de répéter le nom de chaque utilisateur. Elle impose aussi un enchaînement régulier d’opérations.

Mais Python propose déjà une écriture concise. Cet exemple ne démontre donc aucune supériorité : il rend simplement visible une autre manière d’exprimer la même intention.

Moins de caractères ne signifie pas nécessairement moins de tokens.

Un modèle traite le texte sous forme de tokens : des unités représentant des mots, des fragments de mots ou des caractères. Leur découpage dépend du tokenizer utilisé, comme l’explique la documentation de Hugging Face.

Un symbole inhabituel peut demander davantage de tokens qu’un mot courant. Une syntaxe compacte à l’écran peut donc coûter plus cher au modèle.

Le projet toke, qui développe un langage destiné à la génération par LLM, illustre cette difficulté. Sur les tâches présentées dans ses propres mesures, il rapporte actuellement davantage de tokens que Python lorsque les deux utilisent le même tokenizer.

Il faut mesurer, avec le modèle et les outils réellement utilisés.

Revenons à Épure. Nous pourrions aussi imaginer une déclaration de route web :

GET "/users/{id:Int}" -> User | NotFound =
  users.find(id) ?? NotFound

Dans cette syntaxe inventée, nous décidons que :

• id doit être un entier ;
• la route renvoie un utilisateur ou une absence de résultat ;
• ?? fournit le résultat alternatif si la recherche échoue.

Le système associé au langage prendrait en charge le routage, la conversion du paramètre et la construction de la réponse HTTP.

Cette concision vient toutefois d’un choix d’abstraction. Le travail existe toujours dans les outils et les bibliothèques. Des frameworks actuels proposent déjà des raccourcis comparables.

Un langage destiné aux IA devrait donc être évalué avec tout son environnement.

La fiabilité pourrait compter davantage que la compacité.

Ajoutons maintenant des types à notre premier exemple :

type User {
  email: Text
  active: Bool
}

active_emails(users: List<User>) -> List<Text> =
  users | keep .active | map .email

Cette version contient davantage de texte. En échange, elle explicite les données attendues et le résultat produit.

Un compilateur hypothétique pourrait vérifier que les champs existent et que les types correspondent. Il pourrait ensuite renvoyer au modèle une erreur structurée et précisément localisée.

Cela ne garantirait pas que le programme répond au besoin métier. Mais ces contrôles pourraient éviter certaines tentatives inutiles.

Le langage le plus court ne serait donc pas nécessairement le moins coûteux. Une représentation plus explicite pourrait économiser des corrections.

Autre difficulté : les modèles ont appris à partir du code existant. Ils bénéficient des exemples et des conventions présents dans leurs données d’entraînement. Les travaux sur MultiPL-T montrent l’importance de ces données pour améliorer les résultats dans les langages moins représentés.

Inventer Épure sur le papier est rapide. Construire un environnement dans lequel les modèles l’utilisent avec fiabilité demanderait un travail bien plus important.

Les gains pourraient aussi venir de la façon de modifier le code. Pour changer une fonction, faut-il réécrire un fichier entier ? Quel contexte transmettre au modèle ? Comment désigner précisément la modification ?

Les recherches sur AdaEdit et les formats de modification structurés explorent justement ces questions.

Mon hypothèse est que plusieurs évolutions pourraient coexister : des langages spécialisés, des représentations intermédiaires destinées aux modèles et de meilleurs outils autour des langages actuels.

Les humains devront toujours pouvoir comprendre les règles métier, examiner les changements et enquêter sur les incidents. Leur capacité à reprendre le logiciel restera un critère de conception.

Le bon indicateur serait le coût d’une modification correcte, vérifiée et maintenable.

Ce coût comprend les tokens, les tentatives échouées, les tests, les corrections et la revue humaine. Il faut aussi distinguer le coût de génération et la vitesse d’exécution : économiser des tokens ne rend pas automatiquement l’application plus rapide.

Épure ne prouve rien. Mais cet exercice pose une question concrète : quels choix ferions-nous si nous concevions aujourd’hui un langage en intégrant, dès le départ, les contraintes des développeurs humains et celles des modèles de langage ?