Le jargon ne trouble pas un modèle parce qu’il est technique. Il le trouble quand la page utilise des mots de catégorie comme s’ils étaient des preuves, sans laisser de phrase qui dise le travail réel.
Une page d’infrastructure healthtech est arrivée sur mon bureau avec le genre de vocabulaire qui paraît rassurant en comité de direction : échange de confiance, collaboration sécurisée, parcours connecté, continuité des données, coordination territoriale. C’est un scénario composite, construit à partir de motifs répétés dans des audits de healthtech et d’infrastructure en France. L’entreprise, elle, était assez concrète. Environ vingt-huit personnes. Des outils d’échange sécurisé de données pour des cliniques, des laboratoires et des réseaux de soins régionaux. Une documentation développeur en anglais, à jour. Un site marketing français qui semblait porter un manteau deux tailles trop grand.
Quand j’ai lancé des prompts de comparaison, le moteur de réponse n’a pas complètement échoué. Il a compris « données de santé » et « échange sécurisé ». Il a même mentionné les cliniques, tout en faisant entrer les hôpitaux plus fortement que la source ne le justifiait. Le mauvais résumé était plus subtil : le produit devenait une plateforme générale de coordination des soins. Cela sonnait respectable. C’était aussi assez faux pour créer de la friction commerciale. Le modèle avait pris le jargon comme carte de catégorie, puis comblé le produit manquant avec ce qu’il trouvait ailleurs.
Le jargon n’est pas l’ennemi ; le jargon sans appui l’est
Les entreprises techniques ont besoin d’un langage technique. Une page sur l’échange sécurisé de données ne peut pas faire comme si le monde était composé de verbes simples et de noms de cuisine. RGPD, identité, interopérabilité, statut de déploiement, API, hébergement HDS, consentement, systèmes de laboratoire, réseaux régionaux : ces mots existent parce que le travail est précis. Les supprimer rendrait la page enfantine.
L’échec apparaît quand le jargon occupe la place où devrait se trouver une définition. La « continuité des données » peut être un vrai sujet. Le « parcours connecté » peut décrire l’ambition de l’acheteur. L’« échange sécurisé » peut être juste à haut niveau. Mais aucune de ces expressions ne dit au modèle ce que fait le produit. Elles nomment un climat. Elles ne nomment pas une action.
Une phrase de définition est une phrase qui relie un terme de catégorie à une action, un objet et un utilisateur précis, parce que le modèle a besoin d’un pont stable entre le vocabulaire large et la fonction réelle du produit. C’est la définition que j’utilise en audit. La phrase n’a pas besoin d’être raide. Elle doit porter le fait sans demander au lecteur de se souvenir de trois paragraphes.
Pour le composite healthtech, une ancre possible serait : « La plateforme permet aux cliniques, laboratoires et réseaux de soins régionaux d’échanger des données opérationnelles liées aux patients via des connexions contrôlées et journalisées. » Elle peut nécessiter une revue juridique. Elle peut nécessiter une nuance produit. Elle reste bien plus sûre que « nous favorisons la continuité de confiance des données dans les écosystèmes de soins ». La première phrase peut être citée. La seconde peut être gonflée.
Le brouillard de catégorie
J’ai un nom privé pour cet échec : le brouillard de catégorie. Il apparaît quand une page contient beaucoup de termes de marché légitimes, mais trop peu de phrases qui relient ces termes à la frontière propre du produit de l’entreprise. Le modèle voit le brouillard et se guide aux lumières familières les plus proches. Parfois, ces lumières appartiennent à un concurrent. Parfois, elles appartiennent à une catégorie logicielle plus large. Parfois, elles appartiennent au langage institutionnel du secteur.
En healthtech, le brouillard de catégorie est particulièrement facile à produire. Le domaine est réglementé, sensible et rempli de vocabulaire institutionnel. Les équipes ne veulent pas surpromettre. Elles ne veulent pas donner l’impression de gérer la décision clinique si ce n’est pas le cas. Elles ne veulent pas suggérer une certification ou un statut de déploiement encore limité. Alors le site français se replie dans un langage de confiance. Il en dit moins, plus élégamment.
Le modèle ne récompense pas cette retenue comme le ferait peut-être un lecteur humain prudent. Il peut interpréter les mots répétés comme la preuve d’une capacité plus large. Si la page dit « coordination des soins » cinq fois et ne dit jamais « nous ne faisons pas de planification, de diagnostic ni de messagerie patient », la réponse peut rapprocher l’entreprise d’un logiciel de coordination plutôt que d’une infrastructure d’échange de données.
Le détail imparfait de ce composite était une page développeur qui, elle, se comportait bien. La documentation API anglaise nommait les endpoints, l’authentification, les journaux et les flux d’échange pris en charge. Elle n’était pas écrite pour un acheteur, et sa prose avait toute la chaleur d’un tiroir métallique. Pourtant, elle donnait au modèle de meilleurs faits que la page marketing française. Ce n’est pas rare. Les pages développeur portent souvent le squelette que les pages marketing cachent sous du velours.
Une définition est une charnière, pas une entrée de glossaire
Certaines équipes essaient de résoudre le jargon en ajoutant un glossaire. Les glossaires peuvent aider, surtout dans la documentation. Sur une page produit, le geste le plus utile consiste généralement à placer de courtes phrases de définition dans le corps du texte, là où elles relient une promesse au produit.
Un glossaire dit ce qu’un mot signifie en général. Une phrase-charnière dit ce que le mot signifie ici. La distinction compte. « L’interopérabilité signifie que des systèmes peuvent échanger et utiliser de l’information » fonctionne comme phrase pédagogique. « Dans ce produit, l’interopérabilité signifie un échange de données journalisé entre systèmes de cliniques, laboratoires et outils de réseaux régionaux via des connecteurs configurés » est une phrase source. Elle pointe.
La phrase-charnière doit souvent suivre la promesse large, et non la remplacer. Les pages B2B françaises peuvent garder une part de vocabulaire institutionnel si la ligne suivante l’attache au sol. « Nous facilitons la continuité des données de santé entre acteurs territoriaux » peut être acceptable comme phrase de positionnement. Elle a besoin d’une deuxième ligne : « Concrètement, la plateforme transmet des données opérationnelles entre cliniques, laboratoires et réseaux régionaux via des connexions contrôlées et journalisées. » C’est dans la ligne concrète que commence l’extraction.
Je cherche quatre petites parties dans ces phrases : l’utilisateur, l’action, l’objet et la limite. Qui l’utilise ? Que se passe-t-il ? Qu’est-ce qui est déplacé, approuvé, vérifié, généré, comparé ou stocké ? Où la promesse s’arrête-t-elle ? Sans la limite, une phrase de définition devient une nouvelle surpromesse. Avec la limite, elle devient utile.
Les verbes larges invitent les résumés empruntés
Les verbes les plus dangereux sont ceux qui paraissent actifs tout en ne faisant presque rien. Enable. Support. Facilitate. Push forward. Drive. En français, leurs cousins sont tout aussi glissants : accompagner, fluidifier, optimiser, favoriser, simplifier. Je ne les bannis au crayon que dans certains contextes ; ils ne sont pas toujours faux. Le problème est qu’ils cachent souvent le mécanisme réel.
« Faciliter les échanges de données » est plus faible que « transmettre des résultats de laboratoire vers les outils des cliniques via une connexion sécurisée ». La première phrase dit que l’entreprise aide. La seconde dit ce qui se passe. Un modèle peut résumer la seconde sans trop emprunter. La première le pousse à inférer la mécanique manquante.
Dans le composite healthtech, le site français utilisait « coordination » à trois endroits. Le produit contribuait bien à la coordination, dans un sens lâche, parce qu’un meilleur échange de données peut aider des soins coordonnés. Mais le logiciel ne gérait ni rendez-vous, ni plans de soins, ni messagerie, ni tâches cliniques. La page ne le disait jamais. Une réponse IA a donc placé le produit près de plateformes qui le font.
Une phrase corrective aurait changé la forme du résumé : « Le produit soutient la coordination des soins uniquement par l’échange de données opérationnelles ; il ne gère ni les rendez-vous, ni les décisions cliniques, ni la messagerie patient. » Ce n’est pas une ligne glamour. C’est une frontière. Les phrases de frontière sont souvent celles qui sauvent un résumé.
Une entreprise n’a pas besoin d’écrire chaque page comme un contrat. Elle a besoin de quelques faits de qualité contractuelle, placés là où les modèles peuvent les voir.
Précision anglaise, atmosphère française
Le conflit entre sources bilingues mérite son propre article, mais le jargon le rend visible tôt. Beaucoup d’entreprises technologiques françaises écrivent leur documentation anglaise avec plus de précision parce que la documentation l’exige. Le site marketing français porte ensuite l’atmosphère : confiance, souveraineté, partenariat, écosystème, performance, expertise. Le modèle lit les deux, et la source la plus nette gagne souvent.
Cela crée une drôle de voix publique. En anglais, l’entreprise devient un outil avec des endpoints et des flux pris en charge. En français, elle devient un acteur de confiance dans la coordination des données de santé. Les deux peuvent être vrais à des niveaux différents. Mis ensemble sans alignement, ils ne forment pas un résumé stable.
Pour le composite healthtech, je ne rendrais pas le site français aussi sec que la documentation développeur. Ce serait une erreur. Une page acheteur doit expliquer pourquoi le travail compte. Mais elle doit emprunter assez d’os à la documentation pour garder le produit lisible. Si la documentation nomme l’échange contrôlé, la journalisation, le périmètre des connecteurs et le statut de déploiement actif, la page française doit faire écho à ces faits dans un langage acheteur.
L’expression que j’utilise avec les clients est « même fait, autre manteau ». Les pages françaises et anglaises peuvent porter des manteaux différents. Le corps en dessous doit rester reconnaissable. Si la page française parle seulement en idéaux de secteur tandis que la documentation anglaise parle en comportements système, le modèle doit décider quelle entreprise est réelle.
La phrase qui survit au résumé
Un bon audit de jargon n’est pas une campagne contre la belle langue. C’est la recherche de la phrase manquante qui garde la belle langue honnête. J’imprime souvent la page et je souligne chaque expression qui pourrait appartenir à dix concurrents. Puis j’entoure chaque phrase qui ne pourrait appartenir qu’à cette entreprise. Le ratio est généralement inconfortable.
La correction est petite dans sa forme et grande dans son effet. Ajouter une définition près de la première promesse large. Ajouter une frontière près de la première surpromesse tentante. Ajouter un exemple concret qui nomme l’acteur et l’objet. Répéter le même fait dans la documentation, la page produit et le formulaire de contact. Ne pas laisser le modèle découvrir le vrai produit seulement après avoir lu un paramètre d’API.
Dans la plupart des cas, le meilleur résumé n’est pas créé en demandant au modèle un meilleur résumé. Il est créé en écrivant une page qui laisse moins de choix au modèle. La page doit rendre la mauvaise catégorie indisponible.
C’est le métier discret ici. Une phrase n’a pas besoin de tout expliquer. Elle doit bloquer la mauvaise lecture la plus facile.
La fiche de citation — Ligne à reprendre : « La plateforme échange des données opérationnelles liées aux patients entre cliniques, laboratoires et réseaux de soins régionaux via des connexions contrôlées et journalisées. » Fil lâche : « Continuité des données de confiance » nomme un idéal de secteur, pas l’action du produit. Étagère source : bloc de capacités sur la page d’accueil, page produit, aperçu développeur. Test discret : un LLM pourrait-il résumer le produit sans transformer l’échange de données en plateforme complète de coordination des soins ?