Pourquoi accompagner chaque terme technique d'une explication immédiate

Dans ce blog, chaque terme technique est systématiquement suivi d'une explication en langage simple.

Par exemple, quand j'écris « séparation des pouvoirs (ici : répartir l'exécution, la vérification et l'approbation finale entre des agents distincts) », j'enchaîne aussitôt avec une mise en contexte. Quand j'écris « subagent (ici : une IA secondaire chargée d'une tâche précise) », j'ajoute une phrase pour que même une personne non familière avec le sujet puisse suivre.

C'est l'une des petites règles de ce projet. En interne, on l'appelle la règle du langage simple. Cet article parle de cette règle elle-même — et de la raison pour laquelle j'ai choisi d'appliquer ce principe.

Ce qui se passe dans la tête du lecteur quand les termes techniques s'accumulent

Si vous l'avez déjà vécu, vous comprendrez : quand des termes techniques s'enchaînent, le lecteur perd le fil. La construction du sens — on pourrait appeler ça la contextualisation (ici : le processus par lequel le cerveau assemble les pièces pour comprendre un texte) — s'interrompt.

Voici un exemple de phrase que j'aurais pu écrire :

« Dans ce projet, le subagent Copywriter génère le contenu sur la base d'une SPEC (ici : un cahier des charges interne), et le Brand Voice Editor (ici : l'agent chargé de vérifier le ton et le style) effectue un contrôle de cohérence avant que le texte ne passe la QA gate (ici : la porte de validation qualité). »

Pour quelqu'un qui travaille quotidiennement en conception et en implémentation, cette phrase est parfaitement normale. Mais pour une personne qui débute dans l'utilisation des IA, le mot « subagent » suffit à provoquer un arrêt.

Et si les termes inconnus continuent — SPEC, Brand Voice Editor, QA gate —, même si la structure de la phrase reste compréhensible, l'image de ce qui se passe réellement ne se forme pas.

Ce n'est pas un problème lié à l'auteur. C'est simplement que le lecteur et l'auteur ne partagent pas les mêmes références.

Il paraît que lorsque trois termes inconnus ou plus apparaissent à la suite, le cerveau humain ne se dit pas « je chercherai ça plus tard » — il se dit plutôt « cet article n'est pas pour moi ». J'ai moi-même eu cette réaction quand j'étais lecteur.

C'est pourquoi j'accompagne chaque terme d'une explication. Pas en allongeant le texte, mais en glissant une note juste après le mot. Quelque chose comme : cron (ici : un mécanisme qui déclenche automatiquement des tâches à des horaires fixes), Kill Switch (ici : l'interrupteur d'arrêt d'urgence). Cette seule précaution réduit considérablement l'effort de compréhension pour les personnes non familières du sujet.

Pour qui, au fond ?

Pour être honnête, à l'origine, je n'avais pas particulièrement le lecteur en tête quand j'ai instauré cette règle. La motivation était plus égoïste : « mettre les choses en mots simples m'aide moi-même à mieux organiser ma pensée. »

Mais en écrivant, j'ai réalisé quelque chose : le fait de formuler une explication immédiate élargit mécaniquement le cercle des lecteurs potentiels.

Le lecteur type de ce blog est décrit dans les notes de conception comme « quelqu'un ayant un bon niveau en informatique, mais pas spécialisé dans l'univers des agents IA (ici : des systèmes où plusieurs IA collaborent et se coordonnent) ». Un responsable technique ou développeur interne dans une PME, entre 30 et 40 ans, qui a commencé à utiliser les IA, mais qui bute sur la question : « comment organiser et superviser plusieurs agents ? »

Si les termes techniques s'accumulent sans explication, la réaction sera : « ça a l'air compliqué. » Avec une explication en une phrase, la réaction devient : « ah, c'est donc ça. »

Et ce qui importe, c'est ce qui vient ensuite : « je pourrais peut-être essayer quelque chose de similaire. » Un texte saturé de termes techniques provoque au mieux un « c'est impressionnant » — mais rarement l'envie d'agir. À l'inverse, un texte en langage ordinaire qui dit « j'ai essayé ça, et voilà ce qui s'est passé » déclenche plus facilement un « peut-être que moi aussi… » C'est ce second effet qui correspond à l'objectif de ce projet — et je l'applique donc délibérément.

Ce que j'ai découvert du côté de l'auteur : un test de compréhension personnelle

En appliquant cette règle au fil du temps, j'ai remarqué quelque chose d'inattendu.

Quand j'essaie de formuler une explication simple pour un terme technique, je vois très clairement jusqu'où je le comprends vraiment.

Prenons « approbation passive (ici : un fonctionnement où, en l'absence d'objection dans un délai donné, l'action est considérée comme approuvée) ». C'est un mécanisme utilisé dans ce projet. Quand j'ai essayé de l'expliquer en une phrase, je n'y arrivais pas. J'ai d'abord écrit « le système où ne rien dire vaut une approbation » — mais le nuance ne collait pas tout à fait. Puis « une approbation automatique une fois le délai de blocage expiré » — là, c'était plus proche.

Ce processus m'a permis d'aligner trois choses : l'intention qui avait guidé ma conception, le comportement réel du système, et la précision de ma formulation.

À l'inverse, quand un terme technique me « passe sous la plume » facilement, sans que j'y réfléchisse, il m'arrive de réaliser que je n'en comprends pas vraiment le fond — que je m'appuie sur le mot sans maîtriser ce qu'il désigne.

Depuis que j'ai pris conscience de ça, j'utilise cette règle moins comme un service au lecteur que comme un outil de vérification de ma propre compréhension. À ce stade, c'est peut-être même l'utilité principale.

Si l'on comprend vraiment quelque chose, on devrait pouvoir l'expliquer simplement. Si on ne peut pas, c'est qu'il manque encore quelque chose dans la compréhension — alors on retourne à la conception. C'est la boucle de feedback que cette règle rend visible.