Les licenciements se poursuivront jusqu'à ce que nous apprenions à utiliser l'IA
Auteur original : Arnav Gupta, ingénieur en IA
Bao Yu, analyst AI

Dans le bureau de la direction de notre entreprise, une liste de licenciements concernant jusqu'à 8000 personnes repose quelque part. J'ai 10 % de chances d'être sur cette liste. Dans quelques jours, le 20 mai, je connaîtrai mon sort.

Après avoir vu l'annonce de Coinbase concernant les licenciements liés à l'IA aujourd'hui, j'ai décidé d'écrire cet article. J'ai délibérément commencé avant le 20 mai, car je voulais partager des opinions les plus sincères possibles, sans aucune émotion personnelle du type « je reste ou je pars ». Ces réflexions ne concernent pas seulement ma propre situation de licenciement, ni même uniquement mon entreprise. Elles proviennent des véritables sentiments de mes amis travaillant dans de grandes et moyennes entreprises.

Il y a actuellement de nombreux articles qui débattent : cette nouvelle vague de licenciements (généralement considérée comme ayant commencé avec le licenciement de 40 % des employés de Square par Jack Dorsey) est-elle vraiment due à l’IA, ou s’agit-il simplement d’un « AI-washing » (c’est-à-dire que les entreprises utilisent l’adoption de l’IA comme prétexte pour cacher d’autres échecs commerciaux ou des objectifs réels de licenciement) ?

Je ne veux pas te torturer en remplissant l’article de liens vers des actualités et des articles scientifiques que tu as probablement déjà vus, ou que tu peux facilement trouver en faisant une recherche sur Google ou en posant la question à ChatGPT.

La « productivité IA » fortement vantée et les preuves évasives

L’IA nous rend-elle vraiment plus efficaces ? C’est une question majeure et très controversée ! Si nous y réfléchissons à l’envers et affirmons que « l’IA n’a rien changé », je pense que même les plus sceptiques quant à la valeur de l’IA ne seraient pas d’accord avec cette affirmation.

Dans les entreprises technologiques, la montée en flèche de l'utilisation de l'IA est un fait évident. Même les entreprises les plus conservatrices, qui limitent le budget dédié à l'IA et ne fournissent pas d'outils d'IA à leurs employés, ne peuvent nier qu'une partie du travail est effectivement accomplie par l'IA — même si les employés utilisent discrètement Gemini ou Copilot dans Google ou Microsoft Office pour éditer des documents.

Pour les entreprises plus visionnaires qui se sont plongées dans l'océan des tokens AI (l'unité de base traitée par les modèles d'IA, généralement facturée en fonction du nombre de tokens consommés lors de l'utilisation de grands modèles linguistiques), comme Uber ou Shopify (je n'inclus pas ici des entreprises comme Meta ou Microsoft qui développent leurs propres grands modèles linguistiques, ni Vercel ou Cloudflare qui construisent activement l'infrastructure AI ; je ne parle que des « utilisateurs » purs), leur consommation d'IA est devenue folle.

Nous y sommes habitués : de 90 % à 100 % du code généré par l’IA, à une augmentation de 2 à 5 fois du nombre de revues de code (PRs/diffs) soumises chaque semaine, jusqu’à la consommation en quelques mois seulement d’un budget annuel IA de centaines de millions de dollars.

Cependant, des critiques technologiques et investisseurs comme Ed Zitron, Will Manidis, Gary Marcus et Michael Bury vous poseront inévitablement une question fondamentale : si c'est le cas, pourquoi les revenus de ces entreprises n'ont-ils pas augmenté de 2 à 5 fois ? Pourquoi leurs applications semblent-elles presque identiques à ce qu'elles étaient il y a six mois ? Si l'IA est vraiment aussi productive, qu'ont-elles réellement produit avec l'IA ? Si elles ont écrit cinq fois plus de code, mais que les utilisateurs finaux n'en remarquent rien, quel est le sens de ce code ? C'est une question extrêmement percutante et raisonnable.

Entrée (Input), sortie (Output) et résultat (Outcome)

Nous devons d’abord faire une pause pour une leçon de base en gestion d’entreprise. Lorsqu’une entreprise de taille moyenne, en croissance rapide, surfinancée et qui dépense à tout va, fait enfin face à une pénurie de liquidités, vous allez consulter un PDG expérimenté. Il vous conseillera de faire venir des consultants de McKinsey. Les conseillers placeront une diapositive entièrement blanche en première page de leur présentation, avec les trois mots suivants écrits en police Arial par défaut : « Entrées, Sorties, Résultats ».

Ils te expliqueront l'essence commerciale que tout le monde comprend, mais oublie toujours :

Le code, c'est simplement un investissement.

La fonctionnalité, c'est ce qui produit.

Les utilisateurs sont prêts à payer volontairement pour votre produit, c’est là le véritable résultat.

L’IA (ou du moins des produits comme Claude Enterprise) est fondamentalement un produit de service logiciel destiné aux entreprises (B2B SaaS). Vous constaterez que les modèles de tarification et de marketing des produits SaaS varient considérablement. Si un produit peut modifier directement les « résultats », il prend souvent une part directe de ces « résultats ». Imaginez ce discours de vente : « Notre outil permet d’accélérer la génération de prospects de 36 %. Essayez-le dès maintenant en payant simplement une faible commission de 5 % sur vos ventes. »

Cela va absolument déchirer les clients. Toutes choses égales par ailleurs, si vous avez conclu 100 transactions au cours des 100 derniers jours, vous n'aurez désormais besoin que de 63 jours. Les 36 jours économisés (si je ne me trompe pas) vous permettront de conclure 57 transactions supplémentaires ! Autrement dit, vos ventes potentielles augmentent de 57 %. N'importe qui serait ravi de consacrer 5 % de ses commissions de vente pour obtenir un revenu supplémentaire de 57 %. Et si vous n'utilisez pas ce produit, vous ne payez rien du tout.

Vous avez probablement deviné ce que je vais dire — le modèle de tarification des tokens de Claude n'est pas du tout comme ça. Si vos ingénieurs logiciels sont accros à programmer avec Claude, comme des drogués (je viens de remarquer que leurs abréviations anglaises sont toutes les deux « cc »), et qu'ils génèrent 100 millions de tokens par jour, vous devrez payer 100 dollars par jour pour chaque ingénieur.

Même si une partie du code qu'ils ont généré a été jetée à la poubelle parce qu'elle ne fonctionnait pas ;

Même si certains codes ont ensuite provoqué des pannes système graves (SEV) (SEV signifie Severity, un terme couramment utilisé par les entreprises technologiques pour désigner des incidents en ligne graves entraînant une interruption de service) et ont été immédiatement rétrogradés ;

Même s'il reste encore un peu de code, juste pour donner un nouvel aspect aux outils internes, afin que les vice-présidents trouvent les tableaux de bord plus mignons lorsqu'ils consultent les données ;

Tout doit être accepté tel quel. Car le code n'est qu'un « investissement ». Bien qu'en général, une fois le cap correctement fixé, un plus grand « investissement » entraîne souvent un plus grand « rendement », et par conséquent de meilleurs « résultats », cette règle ne s'applique plus nécessairement lorsque vous multipliez soudainement votre investissement par cinq en une nuit. Les « investissements » que vous avez ajoutés pourraient soudainement devenir des mouches sans tête, complètement déviés des « rendements » ou « résultats » attendus.

Qu'est-ce qui nous empêche vraiment !

Par le passé, chaque fois que le PDG ou le produit manager (PM) voulait faire 10 choses, l'équipe de développement répondait toujours qu'ils ne pouvaient en réaliser que les deux les plus importantes, et qu'ils n'avaient pas le temps pour les 8 autres. Pourquoi ? Parce que coder, ce n'est pas un jeu d'enfant ; développer un logiciel complexe et fonctionnel demande beaucoup de temps.

Hmm... but code is almost free now. Why haven't we done the remaining 8 things yet?

Il y a deux réponses : l'une que le PDG et le produit n'aiment pas entendre ; l'autre que les cadres intermédiaires et les employés expérimentés n'aiment pas entendre.

Simplement parce que le PDG ou le produit manager a eu 10 idées en tête ne signifie pas qu'elles peuvent véritablement se traduire en résultats commerciaux concrets. Même si vous développez réellement 10 nouvelles fonctionnalités (production), cela ne garantit pas que les utilisateurs les adopteront et utiliseront davantage votre application (résultat).

En réalité, précisément parce que les ressources de développement étaient limitées par le passé, cette « friction » obligeait tout le monde à engager des débats plus acharnés, permettant ainsi d'éliminer rapidement les mauvaises idées avant qu'elles n'absorbent trop de ressources et de retenir les deux meilleures. Aujourd'hui, écrire du code est rapide et peu coûteux ; discuter de la qualité des idées semble alors sans objet. Même si vous tentez de les contredire, croyez-vous vraiment pouvoir empêcher le PDG ou le PM de se tourner directement vers Claude pour poser leur demande ? Laissez tomber, il ne vaut même pas la peine d'essayer.

Nous savons tous à quel point c’est épuisant. Il faut d’abord que toutes les parties prenantes s’entendent sur la raison de faire cela ; ensuite, il faut une autre réunion pour discuter précisément de ce qu’il faut faire ; enfin, tout le monde doit encore débattre de la manière de le faire.

Plus il y a d'équipes, plus il y a de projets coincés dans l'« enfer d'alignement ». Avant, ce problème était masqué par la lenteur du développement logiciel. Maintenant, dès qu'une action est décidée, quelqu'un crée immédiatement un produit minimum viable (MVP) en travaillant toute la nuit (un produit développé au moindre coût, juste suffisant pour démontrer l'idée centrale, afin de tester rapidement), et organise déjà la prochaine réunion le lendemain.

Lors de la réunion, vous avez été surpris de découvrir qu'une autre équipe avait également secrètement développé un MVP ! Pire encore, comme vous vous étiez basés sur des hypothèses différentes, les logiques de fonctionnement des deux produits étaient totalement opposées.

Of course, you can sit down and take your time to discuss whose assumptions are correct.

Mais soyons honnêtes : vous et votre équipe, avec vos tokens Claude illimités, n’auriez jamais fait ça. Un autre équipe non plus. Vous vous tourneriez sans hésiter vers Claude et lui demanderiez de réimplémenter le travail de l’équipe adverse exactement comme vous le voyez le plus parfaitement. Et Claude vous répondrait gentiment : « Vous avez tout à fait raison ! » avant de se mettre immédiatement à coder.

Quels problèmes les licenciements peuvent-ils vraiment résoudre ?

D'accord, merci d'avoir écouté patiemment mes longues explications sur ces évidences. Je sais que vous voulez voir le cœur du sujet.

À quoi servent vraiment les licenciements ? Selon mon hypothèse, si l’IA ne remplace pas réellement un à un 30 % des employés (ce que la plupart d’entre nous devraient pouvoir accepter — bien qu’elle soit supérieure aux employés juniors pour certaines tâches, elle est inférieure aux humains pour d’autres ; elle n’est certainement pas une pièce interchangeable que l’on peut simplement brancher ou débrancher, et encore moins capable de remplacer directement 10 %, 20 % ou même 30 % des personnes dans une entreprise).

Dans ce cas, quelle est la logique des licenciements ? Parce qu'ils résolvent immédiatement deux problèmes à court terme qui sont sur la table.

C’est simplement un problème d’arithmétique de flux de trésorerie de base. Il est évident que si vos ingénieurs dépendants de Claude dépensent 100 $ par jour sur Claude (soit 2 500 $ par mois et 30 000 $ par an), cette somme correspond au salaire complet d’un ingénieur en développement logiciel (SDE) en Inde, à la moitié d’un SDE en Europe, et au quart d’un SDE aux États-Unis.

Si l'on effectue un calcul simple et direct : supposons que dans une entreprise à structure plate, tous les employés sont des SDE. Pour maintenir le montant total des salaires actuels (y compris les dépenses liées à l'achat de tokens), vous devez licencier 50 % (Inde), 33 % (Europe) ou 20 % (États-Unis) des employés.

En effet, puisque l'utilisation de l'IA connaît une croissance folle sans tenir compte de rien, tandis que les revenus de l'entreprise n'augmentent pas de manière correspondante, les licenciements deviennent une nécessité. Sinon, le bilan de l'entreprise s'effondrerait complètement. Si vos coûts d'investissement augmentent de 50 %, mais que les résultats commerciaux finaux n'ont aucune amélioration, voire restent inchangés, alors l'économie unitaire de votre cycle de développement logiciel s'effondre entièrement.

Si nous avions vraiment appris à utiliser l’IA — si nous avions compris comment transformer une augmentation de 50 % des coûts d’investissement en une augmentation de 50 % des revenus — nous n’aurions pas besoin de passer par cette étape. Mais comme vous ne l’avez pas encore appris, certains d’entre vous devront partir pour libérer des fonds afin de payer Anthropic.

Il ne fait aucun doute que la taille de n'importe quelle grande entreprise dépasse largement ce qui est nécessaire pour sa simple « survie ». C'est précisément là la caractéristique des grandes entreprises : les grandes organisations sont destinées à accumuler du « gras organisationnel », ce qui est une conséquence inévitable de leur conception structurelle.

Dans ces entreprises, même si quelqu’un part, le système continue de fonctionner, car quelqu’un d’autre sait toujours ce qu’il faisait auparavant. Dans de nombreuses grandes entreprises, vous pouvez même prendre un congé parental de six mois en toute sérénité, et votre projet continuera de fonctionner normalement. Ce sont là des signes positifs ! Mais c’est aussi une preuve irréfutable : si l’on licencie une partie du personnel, l’entreprise ne s’effondrera pas immédiatement. Au contraire, après quelques semaines de douleurs systémiques initiales, le fonctionnement deviendra même plus rapide au cours des mois suivants !

Rappelez-vous les deux équipes mentionnées précédemment qui étaient bloquées sur une solution technique ? C’est très simple : il suffit de licencier l’une des deux équipes, puis de laisser l’autre passer plusieurs nuits blanches pour terminer le travail — elles n’auront plus jamais à « s’aligner » avec personne.

Nous ne pouvons pas prédire ce qui se passera à long terme (ou, pour reprendre les mots de l'économiste Keynes — « À long terme, nous serons tous morts »), mais à court terme, licencier 10 à 20 % des employés dans les grandes entreprises ne fera qu'accélérer le rythme de travail.

Au fil du temps, les grandes entreprises accumulent inévitablement des redondances et un surpeuplement organisationnel, tout comme elles accumulent une dette technique ; elles accumulent ainsi une grande quantité de « dette organisationnelle ». C’est là le mal commun des grandes entreprises. Supprimer 10 % du personnel aujourd’hui ne empêchera pas la réapparition des mêmes problèmes dans deux ans. Mais lorsque vous voyez tout le monde se vanter d’avoir soumis cinq fois plus de code qu’avant, tout en étant bloqué par d’autres équipes et incapable de déployer ses fonctionnalités, le remède le plus direct et le plus brutale semble clairement être : licencier certaines personnes, afin que personne ne bloque plus les autres.

C'est le licenciement par l'IA, même si l'IA ne remplace pas directement votre poste.

Votre numéro d’employé a-t-il été remplacé par une nouvelle instance de Claude s’exécutant sur une machine virtuelle ? Nous savons tous que ce n’est pas le cas.

Pourtant, n'y a-t-il pas dans l'entreprise de nombreux processus qui exigeaient autrefois que vous tapiez au clavier ou cliquiez avec la souris dans VS Code, Figma, Canva ou Google Docs, et qui sont désormais accomplis par d'autres (ceux qui avaient besoin de vos livrables) en criant simplement une invite à un grand modèle linguistique, sans plus jamais avoir à vous solliciter ? C'est aussi un fait incontestable.

Ces licenciements constituent-ils vraiment un « blanchiment par l’IA » ? Autrement dit — les entreprises n’avaient-elles pas déjà des problèmes fondamentaux non liés à l’IA (comme un recrutement excessif, une baisse des bénéfices, une pression concurrentielle, de mauvaises décisions commerciales), et n’utilisent-elles simplement l’IA comme un « prétexte » pour licencier ? Eh bien, d’une certaine manière, cela a du sens.

Vous pourriez également remarquer que si vous recueillez tous les e-mails de licenciement envoyés par les PDG pendant cette période, vous pourriez penser qu'ils ont créé un groupe de discussion pour se coordonner et rédiger ces e-mails ensemble. « Équipe native AI », « gestionnaires de codage », « augmentation de la portée de gestion », « structure plate », « gestion d'équipes d'agents intelligents AI »... Vous constaterez que ces nouveaux termes apparaissent de manière identique dans chaque e-mail. Cela ressemble exactement à ce qu'on obtiendrait en fournissant à GPT le même prompt.

Mais la vérité est que, même si ces licenciements ne sont pas directement dus à l'IA vous remplaçant, même s'ils sont mêlés d'une composante de « blanchiment par l'IA », ces licenciements sont fondamentalement causés par l'IA. Et cette vague de licenciements continuera jusqu'à ce que nous apprenions réellement à utiliser l'IA.

Jusqu'à ce que nous apprenions à transformer d'immenses quantités de tokens AI en résultats commerciaux concrets, et non seulement en investissements en code ; jusqu'à ce que nous apprenions à faire en sorte que la vitesse d'alignement entre les organisations suive le rythme du codage de la nouvelle génération ; jusqu'à ce que nous comprenions comment utiliser cette productivité supplémentaire pour poursuivre 10 autres idées prometteuses, au-delà des 2 bonnes idées et des 8 mauvaises idées d'origine.

Avant de comprendre réellement comment l'IA stimule la croissance du PIB mondial, les entreprises ne peuvent que compenser les coûts annuels de jetons atteignant 7 milliards de dollars (le total des revenus professionnels d'OpenAI et d'Anthropic) en réduisant les salaires des employés.

Avant d'apprendre à résoudre plus efficacement les phénomènes de blocage mutuel entre les équipes, la seule solution reste toujours la même — nous supprimer directement de l'organigramme.

Il me reste 15 jours pour connaître mon destin. Mais peu importe le résultat, je pense que j'ai déjà compris la raison. Même si j'étais la personne qui avait pris la décision dans le vaste bureau du PDG, je ne sais pas si j'aurais pu faire mieux ; je n'aurais probablement fait qu'une sélection identique à celle des autres PDG qui ont créé des groupes.

Lien original

Cliquez pour en savoir plus sur les postes vacants chez BlockBeats

Rejoignez la communauté officielle de律动 BlockBeats :

Groupe Telegram abonné : https://t.me/theblockbeats

Groupe Telegram : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia