Un ingénieur a récemment partagé une expérience troublante : alors qu'il utilisait un agent d'IA pour automatiser des tâches de développement, un collègue dont l'anglais n'est pas la langue maternelle obtenait des résultats bien moins riches, bien que la demande fût identique. L'outil ne produisait pas d'erreur, mais il donnait une réponse plus pauvre. La différence résidait non dans la technique, mais dans les mots employés.

Le mécanisme de routage par mots-clés

Au cœur de l'agent se trouve un routeur nommé /do. Celui-ci ne réalise pas lui-même les tâches : il évalue la requête, la classe selon sa complexité, la redirige vers un agent spécialisé et ajoute des traitements supplémentaires. La première étape, la classification, repose sur un script (pre-route.py) qui compare le texte saisi à un fichier de déclencheurs littéraux. Chaque correspondance rapporte un point. Certains mots-clés sont pondérés à deux points. Si le score atteint un seuil élevé, le routeur ignore totalement le modèle de langage et applique un routage purement lexical. En deçà, une procédure de repli, plus lente et moins fiable, est déclenchée.

Ainsi, la même intention peut emprunter des chemins radicalement différents. Par exemple, « pousse mes modifications » (push my changes) déclenche un flux de travail de revue de code, tandis que « envoie mon travail en amont » (send my work upstream) ne correspond à rien. De même, « écris un billet de blog » (write blog post) aboutit à l'outil d'écriture vocale, alors que « aide-moi à dire quelque chose sur mon site » (help me say something on my site) reste sans correspondance.

L'étape d'enrichissement invisible

Le routeur ne se contente pas d'orienter la requête : il peut aussi ajouter des traitements supplémentaires. Des mots comme « complet » (comprehensive), « approfondi » (thorough) ou « exhaustif » (full) déclenchent l'envoi du code à trois réviseurs distincts (sécurité, logique métier, qualité). « Avec des tests » (with tests) ou « prêt pour la production » (production ready) ajoutent un pipeline de développement piloté par les tests. Ces améliorations sont totalement invisibles pour l'utilisateur. Demander « effectue une revue approfondie » (thorough review) active trois réviseurs ; « peux-tu vérifier cela soigneusement » (can you check this carefully) n'en active aucun, car « soigneusement » (carefully) ne figure pas dans la table de déclenchement.

Le problème de la connaissance invisible

L'ingénieur a d'abord pensé que la barrière était le jargon technique. Mais il a découvert que les mots qui font la différence sont souvent des termes simples du langage courant : « review » fonctionne, « look over » non ; « thorough » fonctionne, « carefully » non. Aucune règle linguistique ne permet de deviner lesquels sont des leviers. Un locuteur natif, immergé dans un environnement technique, absorbe ces subtilités par osmose. Un non-natif, en revanche, choisit naturellement la formulation la plus directe et correcte, qui est précisément celle qui échoue. Et aucun signal ne l'avertit qu'il a manqué un mot-clé.

L'ingénieur a montré à son collègue qu'il pouvait interroger le routeur sur son propre fonctionnement. L'outil peut décrire sa décision de routage. Mais encore faut-il savoir poser la question, dans les mots appropriés – ce qui suppose d'avoir déjà conscience qu'un levier a été manqué. La mitigation existe, mais elle est elle-même verrouillée derrière le même type de connaissance.

Implications pour la conception des agents

Cette situation met en lumière un problème de conception fondamental. Le routeur ne juge pas que l'utilisateur en langue simple a besoin de moins de rigueur : il ne voit tout simplement pas la demande comme une demande de rigueur, parce que la rigueur est indexée sur des mots que la personne n'a pas utilisés. La qualité du résultat dépend de la formulation, non du besoin réel. Pour l'ingénieur qui a partagé son expérience, cette prise de conscience est troublante : l'outil fonctionne parfaitement pour celui qui l'a construit, mais pénalise silencieusement ceux qui n'ont pas eu accès à cette connaissance invisible. Une réflexion plus large s'impose sur la manière de rendre les agents d'IA équitables, sans exiger de leurs utilisateurs qu'ils maîtrisent un vocabulaire implicite.