Je passe mes journées à joueur avec des modèles, lire des logs, déboguer des pipelines. La communication, ce n’est pas ma tasse de thé, et pourtant, c’est probablement la compétence qui a le plus d’impact sur tout le reste de mon travail.

Depuis que j’intègre des LLM dans mes flux de travail, cette lacune en communication me coûte encore plus cher qu’avant. Un prompt flou, une doc ambiguë, un ticket mal rédigé et c’est l’IA qui partira dans la mauvaise direction pendant X minutes avant que je ne réalise que le problème venait de moi.

La bonne nouvelle est que les règles pour bien communiquer avec un humain et celles pour bien communiquer avec une IA sont quasiment les mêmes. J’aimerais faire une synthèse de deux lectures complémentaires à la fois sur le leadership et l’UX writing avec la propre perspective de quelqu’un qui vit entre les deux mondes.

Le contexte a changé, les fondamentaux non

Les temps changent, on a moins de temps, moins d’attention. Les boîtes mails débordent, les réunions s’enchaînent, et maintenant, on délègue en plus une partie de la lecture à des IA qui résument, classifient, reformulent. Dans ce contexte, une communication vague ne fait plus juste perdre du temps, elle génère de l’entropie. Un message ambigu que lit un humain fatigué peut être mal interprété. Ce même message lu par un LLM va être extrapolé. Les trous vont être comblés par des suppositions statistiques, et le résultat peut vite devenir du grand n’importe quoi. On dira que le modèle hallucine, parfois, c’est le cas, souvent, c’est le résultat de l’imprécision.

L’enjeu est double : être compris par des humains qui ne lisent pas vraiment (et ils ne l’admettront pas), et par des LLMs qui lisent littéralement « trop littéralement ».

Dire beaucoup avec peu

Le concept est simple : maximum d’information utile, minimum de bruit. Chaque mot doit justifier sa présence. En entreprise, ça ressemble à un leader qui prend dix minutes en stand-up pour poser clairement la direction, les risques et ce qu’on attend de chaque équipe. Les gens repartent avec quelque chose dans la tête. Pas de monologue de quarante-cinq minutes où tout le monde regarde son téléphone.

En UX writing, c’est la différence entre :

❌ "La transaction n'a pas pu être validée en raison d'un problème inattendu."

et

✅ "Paiement échoué. Réessaie."

Autant dire que tout le monde reconnaitra ces deux exemples. Pour communiquer avec un LLM c’est peu ou prou la même chose. Un prompt verbeux avec des circonvolutions oblige le modèle à inférer ce qui est important. Un prompt dense et structuré oriente directement l’attention. La différence de qualité de sortie est réelle. L’exercice que l’on peut se dire, avant d’écrire quoi que ce soit, est de se poser la question : « quelle est l’information centrale ? »

Exiger la clarté, même à soi-même

Le pire ennemi de la communication n’est pas le silence, c’est l’illusion de compréhension. Une réunion à l’issue de laquelle tout le monde hoche la tête sans avoir compris la même chose est sans doute pire que si cette réunion n’avait jamais eu lieu. Les bons communicants s’arrêtent sur le flou dès qu’ils voient les regards fuyant. Non pas pour être désagréables, mais pour que la décision qui suit soit fondée sur quelque chose de compris de tous.

Côté IA, ce principe se traduit par le fait de ne jamais laisser de zones grises dans les instructions :

❌ "Analyse ce texte et dis-moi ce que tu en penses."
VS

✅ "Identifie les 3 risques techniques principaux dans ce texte. Réponds sous forme de liste, une phrase par risque."

La clarté que l’on exige des autres, dois d’abord être exigée de soi-même.

Demander « pourquoi » plus d’une fois

Quand quelque chose casse, un bug en prod, un KPI qui plonge, la première explication est rarement la vraie cause, c’est une surface. La technique des « cinq pourquoi » (comme si on parlait à un enfant, ou comme le font les bons docteurs) permet de creuser, on traite la cause racine, pas le symptôme.  Dans un contexte IA, c’est exactement ce qu’il faut faire quand un modèle produit une mauvaise sortie. « Le modèle est nul, la data n’est pas bonne » est la réponse de surface. Est-ce que le prompt était ambigu ? Peut-être que le contexte manquait ? Ou bien que la tâche était trop complexe pour être traitée en une seule requête ? Finalement le modèle choisi était-il adapté à ce type de raisonnement ? Chaque « pourquoi » supplémentaire réduit la probabilité de répéter l’erreur.

Connecter les points au lieu de les lister et laisser la place.

Une réunion de leadership où les RH parlent de moral en baisse, l’ingénierie parle de bugs en hausse, et le support parle de clients frustrés ce sont trois problèmes séparés, ou un seul problème systémique (les équipes sont en sous-effectif et en mode réactif permanent) ? La synthèse, c’est savoir si « l’on a dix problèmes différents » ou « deux patterns qui se manifestent à cinq endroits ». C’est ce qui transforme une liste de faits en une compréhension utilisable. Comment fait-on ? En posant des questions…

Pour les IA, ce principe a une application directe : les LLM sont très bons pour résumer, mais ils synthétisent rarement d’eux-mêmes si tu ne le demandes pas explicitement. La différence entre :

❌ "Résume ces 5 rapports." VS ✅ "Lis ces 5 rapports et identifie le thème commun qui explique les résultats divergents."

La deuxième instruction active un raisonnement de second ordre, c’est l’utilisateur d’orienter la synthèse. On ne peut pas (pas encore ?) confier le choix de l’orientation au modèle. Tout en évitant bien sûr de sur-contraindre. Donner au modèle assez de structure pour répondre correctement, mais assez d’espace pour que sa réponse soit utile et non juste conforme. Trop de contraintes rigides tuent la qualité autant que trop peu.

Les règles Google : la base minimale qui fonctionne partout

En creusant des documents internes de Google sur l’UX writing, un ensemble de règles minimalistes ressort ce qu’ils appellent le « barely good » writing. Ce qui est intéressant, c’est que ces règles s’appliquent mot pour mot à la communication interpersonnelle et aux instructions pour les LLMs.

Voici les plus universelles :

  • Phrase courte, voix active, une solution : « Upload failed. Select a smaller file. »
  • Information au bon moment. Prévenir avant l’action, pas après : « Vous allez perdre vos modifications non sauvegardées »
  • Valeur utilisateur, pas fonctionnalité produit : « Sauvegarde automatique activée »
  • Score de lisibilité > 60 (Flesch) :  Si c’est trop dense à lire à voix haute, c’est trop dense à comprendre (ça coule de source)
  • Pas de jargon, il cache l’ignorance et ne transmet rien.

 Select a smaller file. Est un excellent exemple dans la mesure ou il donne à la fois la solution et la raison de l’échec. Adapter et tester ses prompts sur ces critères change drastiquement la qualité des sorties.

Ce que l’IA change vraiment

L’IA n’a pas inventé la nécessité de communiquer clairement. Elle l’a rendue urgente et coûteuse à ignorer. Avant, un message flou ralentissait une collaboration humaine. Maintenant, ce même message flou peut lancer un processus automatisé dans la mauvaise direction pendant des heures, ou produire une documentation erronée qui sera réutilisée par d’autres modèles et ainsi de suite. L’ambiguïté se propage plus vite et plus loin. Et au prix des tokens sur certains modèles ça se paye vite cher.

L’aspect positif est que les LLM sont finalement un miroir brutal de la qualité de notre communication. Si le modèle sort quelque chose d’inutile, la question à se poser n’est pas « pourquoi le modèle est mauvais » mais plutôt « qu’est-ce que j’aurais dû demander différemment ? » Ce genre feedback, on ne l’a que rarement avec les humains, car eux sont polis et comblent souvent les lacunes (pas toujours de manière pertinente) sans le signaler. Le LLM avec instruction adéquat sera capable de demander des précisions. Sinon, il déduira, complètera et partira dans une direction que lui seul connait.

L’IA nous force donc à maîtriser ce qu’on a considéré pourtant acquis : densité, clarté, structure, synthèse. Sauf que désormais, l’enjeu est double convaincre des humains qui n’ont plus le temps, et piloter des machines qui prennent tout au pied de la lettre. Le bonus : une même phrase peut faire les deux si elle est bien écrite.

By tech