Comment empêcher Claude de dire « porteur » (et autres expressions d'IA galvaudées)

Si vous avez passé suffisamment de temps à solliciter Anthropic et son modèle Claude pour des conseils en architecture logicielle, des revues de code ou des discussions sur la conception de systèmes, vous avez probablement rencontré une frustration familière : le modèle s'accroche à certaines expressions et ne les lâche plus. « Porteur » (load-bearing) est l'un des coupables les plus tenaces — apparaissant dans les discussions sur le refactoring, les analyses de dépendances, et partout où un composant système est jugé critique. Un fil de discussion récent sur Hacker News, totalisant 97 points et 164 commentaires, a fait remonter ce problème précis à la surface, suscitant un débat animé sur les raisons pour lesquelles Claude abuse de certaines terminologies et sur ce que les ingénieurs de prompt peuvent concrètement y faire.

Ce qui s'est passé : la discussion HN qui a mis le problème en lumière

Un article de blog intitulé « How to stop Claude from saying load-bearing » a atteint la page d'accueil de Hacker News il y a environ quatre heures, accumulant rapidement un engagement significatif. Le fil est devenu un point de ralliement pour les développeurs et les praticiens de l'IA échangeant des récits de guerre sur les tics verbaux de Claude — ces expressions auxquelles le modèle revient avec une fréquence presque comique. La discussion ne s'est pas limitée à des lamentations ; elle a fait émerger des techniques pratiques que les utilisateurs ont testées pour éloigner Claude d'un langage galvaudé et l'orienter vers une production plus fraîche et plus précise.

Pourquoi « porteur » est plus important que vous ne le pensez

Une seule expression galvaudée peut sembler n'être qu'un désagrément mineur. Mais pour les professionnels qui intègrent l'IA dans leurs flux de production, un langage répétitif révèle des problèmes plus profonds :

• Homogénéisation des résultats. Lorsque Claude utilise par défaut les mêmes métaphores dans des contextes différents, les équipes perdent la nuance qui rend les discussions architecturales précieuses. Tous les composants critiques ne sont pas « porteurs » — certains transportent des signaux, renforcent la stabilité ou isolent les défaillances.
• Érosion de la crédibilité. Les documents internes, les livrables clients ou le contenu destiné au public, parsemés d'expressions reconnaissables comme venant d'une IA, peuvent miner la confiance. Les lecteurs repèrent de plus en plus le texte généré par LLM grâce à ses empreintes verbales.
• Biais caché dans le raisonnement. La métaphore du « porteur » cadre implicitement les systèmes comme des structures physiques. Ce cadrage peut aveugler les équipes face à des modes de défaillance qui ne se traduisent pas nettement par des analogies d'ingénierie structurelle — comme la dégradation de latence en cascade ou les violations de cohérence éventuelle.

Qui devrait s'en préoccuper

Ce n'est pas une simple curiosité pour les bricoleurs de prompts. Trois groupes ont un intérêt direct à contrôler les défauts linguistiques de Claude :

• Les fondateurs techniques et CTO qui utilisent Claude pour des décisions d'architecture. Une IA qui qualifie réflexivement tout de « porteur » ne vous aide pas à distinguer les chemins véritablement critiques de ceux qui sont simplement importants.
• Les équipes de relations développeurs et de documentation qui rédigent du contenu public via l'API Anthropic. Vous avez besoin de la puissance analytique du modèle sans son bagage stylistique.
• Les constructeurs d'outils d'IA et développeurs d'agents qui composent des appels Claude en plusieurs étapes. Un résultat précoce qui abuse d'une expression peut contaminer toute la chaîne en aval, amplifiant le problème sur l'ensemble de la trace de raisonnement d'un agent.

Techniques pratiques pour contrôler le langage de Claude

En se basant sur les techniques discutées dans le fil HN et sur les pratiques établies d'ingénierie de prompt, voici des approches avec lesquelles les utilisateurs rapportent du succès :

1. Instruction négative proactive

La méthode la plus directe : dites explicitement à Claude quels termes éviter, en donnant le contexte du pourquoi. Plutôt qu'un générique « n'utilise pas porteur », formulez l'instruction comme une règle de qualité de communication :

« Évitez l'expression "porteur" et les métaphores similaires d'ingénierie structurelle pour décrire les dépendances logicielles. Utilisez un langage adapté au domaine comme "chemin critique", "dépendance forte" ou "point de défaillance unique" lorsque ces termes sont appropriés. »

2. Liste blanche de vocabulaire

Au lieu de simplement bannir des termes, fournissez une liste de vocabulaire préféré. Cela donne à Claude une boîte à outils alternative plutôt que de le laisser deviner ce que vous attendez :

« Pour décrire la criticité d'un composant, puisez dans ce vocabulaire : essentiel, fondamental, non négociable, dépendance transitive, contrainte amont, couplage fort, invariant architectural. »

3. Calibration stylistique par quelques exemples (few-shot)

Montrez à Claude des exemples de la façon dont vous souhaitez que l'analyse architecturale sonne. Un seul paragraphe d'exemple bien choisi, dépourvu de l'expression incriminée, peut redéfinir la ligne de base stylistique du modèle pour toute la conversation.

4. Renforcement par le prompt système pour les utilisateurs de l'API

Si vous appelez Claude via l'API Anthropic, le prompt système est votre surface de contrôle la plus efficace. Les préférences linguistiques placées ici se répercutent sur tous les messages d'une session. C'est particulièrement important pour les flux de travail d'agents construits sur Claude Code ou des chaînes d'outils personnalisées, où des formulations répétitives à une étape peuvent se propager en cascade.

5. Détection en post-traitement

Pour les productions à fort enjeu, certaines équipes effectuent une seconde passe — soit avec un script plus simple, soit avec un appel Claude séparé — spécifiquement pour signaler les termes galvaudés. Cela ajoute de la latence mais permet de détecter les problèmes avant que le contenu n'atteigne un public.

Limites et risques à surveiller

Ces techniques ne sont pas infaillibles. Comprendre leurs limites aide à définir des attentes réalistes :

• Dynamique de jeu de taupes. Bannir « porteur » peut amener Claude à sur-indexer sur vos termes de remplacement. Le modèle peut simplement déplacer son tic verbal vers l'alternative que vous avez fournie le plus en évidence.
• Pertinence dépendante du contexte. Parfois, « porteur » est véritablement la bonne métaphore — notamment lorsqu'on parle d'infrastructure physique, de répartiteurs de charge littéraux ou de problèmes d'ingénierie structurelle. Les interdictions générales sacrifient la précision dans ces cas particuliers.
• Sensibilité à la version du modèle. Les préférences d'expressions qui fonctionnent sur une version instantanée du modèle Claude peuvent ne pas tenir après la mise à jour suivante. Le fil HN a fait émerger des rapports anecdotiques de ce problème précis entre les versions du modèle.
• La sur-contrainte peut dégrader le raisonnement. Si Claude consacre son attention à la conformité lexicale, il peut en allouer moins à l'analyse réelle. Surveillez la qualité des résultats lorsque vous superposez plusieurs contraintes stylistiques.

Comment évaluer les outils d'IA pour le contrôle du langage

Si les habitudes verbales de Claude sont un problème récurrent pour votre équipe, évaluez les outils et plateformes de manière systématique :

• Testez la réactivité au prompt système. Tous les LLM ne respectent pas les instructions stylistiques de la même manière. Exécutez des tests A/B contrôlés comparant comment différents modèles d'Anthropic, d'OpenAI et d'autres adhèrent aux contraintes de vocabulaire.
• Vérifiez la granularité de contrôle au niveau de l'API. Des plateformes comme Amazon Bedrock offrent un accès à Claude avec des couches de garde-fous supplémentaires. Évaluez si le filtrage de contenu intégré peut servir également d'application des règles stylistiques.
• Envisagez le routage multi-modèle. Si un modèle ignore systématiquement les instructions de style pour certains types de tâches, router ces prompts vers un autre fournisseur peut être plus pratique que d'affiner les prompts sans fin.
• Constituez une suite de régression. Maintenez un petit ensemble de prompts connus pour déclencher des expressions galvaudées. Exécutez-les contre toute nouvelle version de modèle ou modification de prompt pour détecter les régressions avant qu'elles n'atteignent la production.

Foire aux questions

Le problème du « porteur » est-il propre à Claude ?

Non. Tous les grands LLM présentent des tics verbaux et une surutilisation d'expressions — c'est une conséquence de la manière dont ces modèles sont entraînés sur du texte humain, qui contient lui-même des motifs répétitifs. Les données d'entraînement spécifiques de Claude et son processus d'alignement peuvent rendre certaines métaphores d'ingénierie plus proéminentes dans ses résultats, mais les utilisateurs des modèles d'OpenAI rapportent des frustrations similaires avec des expressions différentes. Les techniques discutées ici se généralisent à tous les fournisseurs.

Le fine-tuning peut-il résoudre cela définitivement ?

Le fine-tuning peut modifier les tendances stylistiques d'un modèle, mais c'est une solution lourde pour un problème qui se situe au niveau des expressions. La plupart des équipes trouvent que des prompts bien conçus et un post-traitement léger sont plus faciles à maintenir, surtout compte tenu du rythme des mises à jour des modèles de base. Le fine-tuning vous lie également à une version spécifique du modèle, qui peut devenir obsolète rapidement.

Cela affecte-t-il la qualité de génération de code de Claude Code ?

La discussion HN s'est principalement concentrée sur l'analyse en langage naturel plutôt que sur la production de code. Lorsque Claude Code génère du code effectif, le problème du « porteur » est moins pertinent — le modèle écrit du code, pas des commentaires architecturaux. Cependant, si vous utilisez le mode conversationnel de Claude Code pour discuter de l'architecture avant de coder, l'expression peut tout à fait y apparaître.

Et si je veux réellement que Claude utilise « porteur » dans les contextes appropriés ?

C'est le résultat idéal : une pertinence contextuelle plutôt qu'une suppression générale. Essayez d'instruire Claude de n'utiliser les métaphores structurelles que lorsque le système reflète véritablement une dynamique de charge physique — par exemple, pour discuter d'infrastructure littérale ou de schémas de propagation de défaillance qui se traduisent clairement par des analogies d'effondrement structurel. Cela transforme l'expression d'un tic verbal en un choix délibéré et significatif.