Le dilemme du traducteur : Pourquoi Jensen Huang a raison (et pourquoi c'est plus difficile qu'il ne le pense)

Je regardais l'entretien de Jensen Huang depuis mon bureau à Hong Kong il y a deux jours, en buvant un café tiède à 23h, lorsqu'il a lancé cette phrase : *« L'IA ne cause pas de licenciements. Ce sont les dirigeants sans imagination qui le font. »*

J'ai mis la vidéo en pause. J'avais envie d'applaudir.

Il a techniquement raison. Si vous donnez à une équipe un outil de productivité 10 fois plus puissant, un leader créatif augmente la production de 10 fois, et ne licencie pas 90 % de l'équipe. Mais Huang se tenait sur une scène à Santa Clara, regardant le monde à travers le prisme d'un visionnaire qui crée de la demande à partir de rien. Pour ceux d'entre nous qui sommes dans les tranchées - gérant une entreprise, dirigeant des équipes de produit, payant le loyer à Tokyo et à Hong Kong - ses conseils ressemblaient à dire à une personne noyée de nager plus fort sans reconnaître que la piscine s'évacue.

Voici la vérité dérangeante qui explique pourquoi tant de personnes brillantes mettent actuellement à jour leur LinkedIn sur "Disponible pour le travail" : Sans parler du travail à la con.La plupart des emplois ne sont pas vraiment des emplois. Ce sont des services de traduction.

Et la traduction est exactement ce que l'IA vient d'apprendre à faire gratuitement.

Les trois couches de l'utilité réelle

Si vous éliminez les titres et le théâtre LinkedIn, il n'y a que trois types de travail qui créent de la valeur :

Couche 1 : Créer la demande

C'est le moment Steve Jobs - tenir un rectangle de verre en 2007 et convaincre les gens qu'ils le veulent avant qu'ils ne sachent qu'il existe. Cela nécessite une combinaison terrifiante d'intuition et de tolérance au risque. Vous ne résolvez pas un problème déclaré ; vous inventez la catégorie. Peut-être que 0,1% des gens peuvent le faire de manière cohérente sans se détruire eux-mêmes.

Couche 2 : Définir l'exigence

C'est là que l'argent réel vit en ce moment. Une fois que quelqu'un veut l'iPhone, vous devez définir : Qu'est-ce que ça fait exactement ? Quelles sont les spécifications de la batterie ? Quelles fonctionnalités sont dans V1 par rapport à V2 ? Comment mesurons-nous le succès ?

C'est la couche Architecte. Vous n'exécutez pas le plan - vous le dessinez. Vous regardez l'ambiguïté (maux des clients, écarts de marché, contraintes techniques) et vous la cristallisez en problèmes spécifiques et solubles.

Couche 3 : Exécution de l'exigence

C'est là que 85 % d'entre nous ont passé leur carrière. La couche des "Traducteurs".

L'ingénieur logiciel qui prend le ticket Jira ("Construire une page de connexion") et le traduit en composants React. L'avocat qui prend le litige ("Le client veut poursuivre pour violation") et le traduit en mémoires juridiques. Le responsable du marketing qui prend l'directive ("Augmenter les prospects du T3") et la traduit en mécanismes de campagne.

Si votre travail nécessite d'attendre que quelqu'un vous remette une exigence bien définie, puis d'utiliser votre compétence spécialisée pour convertir cette exigence en sortie - vous êtes un traducteur. Et GPT-4 est un traducteur qui ne dort pas, ne négocie pas de salaire et n'a pas besoin d'assurance maladie.

Comment Cesser d'être un Traducteur (Et Devenir Utile)

Je n'ai pas compris cette distinction jusqu'à ce que je sois presque devenu obsolète moi-même. Il y a trois ans, Mercury était essentiellement un service de traduction sophistiqué. Les clients venaient nous voir avec des problèmes définis : "Construire un site Web pour nous." "Migrer notre CMS." "Réparer notre SEO."

Nous étions des traducteurs qualifiés - prenant leurs exigences et les transformant en code propre et livrables. Nous facturions à l'heure, ce qui est le modèle économique parfait pour le travail de traduction. Plus d'heures = plus de valeur, supposément.

Ensuite, fin 2023, j'utilise ChatGPT pour écrire le script Python que nous facturerions normalement quarante heures à construire. Ce n'était pas un code parfait. C'était désordonné, buggé, non sécurisé. Mais c'était *dans la bonne direction*, et cela a pris à l'IA trente secondes.

C'est à ce moment-là que j'ai réalisé :Être bon dans l'exécution n'est plus une barrière.

Ainsi, au cours des trois dernières années, j'ai forcé moi-même et ma société à migrer vers le haut de la pile. Voici à quoi cela a vraiment ressemblé :

1. Apprendre à tolérer l'ambiguïté

Les traducteurs détestent l'ambiguïté. Ils ont besoin d'entrées claires pour produire des sorties claires. Les architectes vivent dans l'ambiguïté.

J'ai commencé à m'obliger à assister à des réunions où le client ne savait pas ce qu'il voulait. Pas seulement inconfortable - incertain au sens existentiel. Un client de l'hôtellerie dirait, "Nous devons être plus numérique." C'est tout. Pas de spécifications. Pas de KPI.

L'ancien James aurait insisté pour avoir un document de spécifications. Le nouveau James a dû apprendre à dire : "Je pense que votre vrai problème est que votre programme de fidélité perd des clients à haute valeur pour les OTA car votre CRM actuel traite un client de 5 000 $ de la même manière qu'un client de 50 $. Voici comment nous redéfinissons la logique de segmentation..."

Je ne remplissais plus un cahier des charges. Je définissais celui qu'ils ne savaient pas qu'ils avaient.

2. Prendre des décisions avec des données incomplètes

L'IA est excellente pour l'exécution car l'exécution nécessite des informations complètes. Vous avez besoin de toutes les variables pour écrire la fonction.

Mais la définition des problèmes se déroule dans le brouillard. Vous avez 40% des données, un sentiment gut et un délai.

Il y a trois ans, j'ai pris la décision terrifiante de pivoter Mercury de "agence de transformation numérique" à "architecte d'infrastructure IA" avant d'avoir un seul client IA. Les données disaient que l'ancien modèle mourait, mais le nouveau modèle n'existait pas encore. J'ai dû construire des architectures d'agents avant que personne ne paie pour eux. J'ai passé six mois à brûler de l'argent sans preuve que cela fonctionnerait.

C'est le travail d'un architecte. Vous faites des paris avant que la piste ne soit construite.

3. Correspondance des motifs inter-domaines

Les traducteurs opèrent dans un domaine donné. Le développeur React reste dans React. Le spécialiste du référencement reste dans le référencement.

Les architectesvolent des motifsde partout.

Lorsque nous avons construit la pipeline d'agents autonomes qui a migré 18 000 articles (le système à 11 agents dont j'ai parlé récemment), je ne faisais pas simplement "une migration de CMS". J'appliquais des concepts d'architecture de systèmes distribués, de théorie du design organisationnel et même de structures de commandement militaire (le modèle "forces spéciales") à un problème de contenu.

La valeur n'était pas dans le code.La valeur était dans la reconnaissance que la migration n'est pas un problème technique - c'est un problème de coordination organisationnelle, et les agents sont meilleurs coordinateurs que les humains pour certains types de cognition répétitives.

4. Posséder le résultat, pas la tâche

C'était le changement mental le plus difficile. En tant que traducteur, tu peux dire : "J'ai construit la fonctionnalité que tu as demandée. Si elle ne fonctionne pas sur le marché, c'est ton problème."

En tant qu'Architecte, tu dis : "Tu dois augmenter la rétention des clients de 15%. Je définirai l'espace du problème, identifierai les points d'intervention et déployerai la solution. Si ça ne fait pas 15%, je ne suis pas pleinement payé."

Nous sommes passés de la facturation des heures (unités de traduction) à la facturation des résultats (résultats architecturaux). Certains mois, on gagne moins d'argent parce qu'on a parié faux. Certains mois, on gagne 3 fois plus parce qu'on a parié juste. Mais nous ne sommes plus interchangeables avec le logiciel.

Ce que j'ai réellement fait pendant trois ans

Laissez-moi être précis concernant les 36 derniers mois, car "devenir architecte" est un conseil abstrait jusqu'à ce que vous voyiez les cicatrices.

Année un (2023) : La panique

Je vendais toujours des produits/solutions. Mais j'ai commencé à remarquer que les clients utilisaient l'IA pour rédiger leur propre copie, générer leurs propres extraits de code, concevoir leurs propres logos. Mes services de traduction étaienten train de se banaliseren temps réel.

J'ai commencé à passer mes nuits à lire sur les architectures RAG, l'orchestration d'agents et les graphes de connaissance - pas parce que je voulais redevenir ingénieur, mais parce que j'avais besoin de comprendre où laambigüité se déplaçait. L'exécution devenait automatisée. L'architecture de *quoi exécuter* devenait précieuse.

Année Deux (2024) : Le Brutal Pivot

J'ai licencié la moitié de mon équipe. Pas parce qu'ils étaient mauvais - parce qu'ils étaient d'excellents traducteurs dans un monde qui n'avait plus besoin de traduction.

J'ai gardé les personnes qui discutaient avec moi sur la stratégie. Ceux qui disaient : "Je ne pense pas que ce client ait besoin d'un nouveau site web. Je pense qu'ils doivent cesser d'exister." (Nous avons perdu ce client, mais avons gagné trois qui avaient réellement besoin d'exister.)

Nous avons arrêté d'accepter des projets avec des demandes de propositions détaillées (RFP).If a client knew exactly what they wanted down to the feature list, they were going to buy a template and an AI subscription. We started targeting clients who said, "Something is broken. We don't know what. Fix it."

Year Three (2025-2026): The New Model

Now we deploy autonomous agents that handle the translation work. The 11-agent migration system I described recently? That's the new model. The agents are the translators. My human team are the Architects who define the problem space, set the constraints, and verify that the outcomes match the business goal.

I spend my days on things that sound vague and unbillable: "defining the ontology of a client's knowledge graph," "negotiating the political implications of a data migration with their C-suite," "deciding whether a problem is worth solving given their budget constraints."

None of this work can be prompted into an LLM because the inputs are too messy, too human, too political. I'm not writing code anymore. I'm defining the problem space such that code *can* be written.

The Hard Truth

Jensen Huang makes it sound like a failure of imagination. It's not. It's a failure of courage.

Walking away from the herd of translators is terrifying. Three years ago, my peers were making steady money building websites and running Google Ads campaigns. I was bleeding cash, learning about vector databases, and wondering if I'd destroyed my company.

The programmers who stayed in the herd—who kept translating Jira tickets into clean code—are currently being optimized out of existence by GitHub Copilot and Cursor. The marketers who kept translating "brand guidelines" into Instagram posts are being replaced by generative tools.

The ones who survived are the ones who stepped into the fog and started drawing maps.

How to Start Today

If you're reading this and recognizing yourself in the "Translator" category, here's the concrete shift:

Stop asking: "How do I execute this requirement better/faster/cheaper?"

Start asking: "Who defined this requirement? What problem are they actually trying to solve? Would I bet my salary that this is the right problem to solve?"

If the answer to that last question is "no," you have two choices: become the person who redefines the problem, or become obsolete.

The pool is draining. Swim upward.

*— James Huang, Mercury Technology Solutions, avril 2026*