Dans un bureau de la haute direction de notre entreprise, quelque part, repose une liste de licenciements concernant jusqu'à 8000 personnes. J'ai 10% de chances de m'y trouver. Dans quelques jours, le 20 mai, je connaîtrai mon sort.

En voyant l'annonce de licenciements « liés à l'IA » par Coinbase aujourd'hui, j'ai décidé d'écrire cet article. Je le fais exprès avant le 20 mai, car je souhaite partager des réflexions brutes, sans les sentiments liés au fait que je sois gardé ou non. Ces pensées ne concernent pas seulement mon cas, ni seulement mon entreprise. Elles émanent des confidences sincères de mes amis travaillant dans diverses entreprises de taille moyenne à grande.

Actuellement, de nombreux articles débattent : cette nouvelle vague de licenciements (que beaucoup datent du moment où Jack Dorsey a licencié 40% des effectifs de Square) est-elle réellement causée par l'IA, ou s'agit-il simplement d'un « blanchiment à l'IA (AI-washing) »(fait pour les entreprises de dissimuler d'autres échecs commerciaux ou leurs véritables raisons de licencier derrière le prétexte d'adopter l'IA).

Je ne veux pas vous infliger un article bourré de liens vers des articles et études que vous avez probablement déjà vus, ou que vous pourriez trouver en une recherche Google ou en demandant à ChatGPT.

La « productivité de l'IA » tant vantée face aux preuves insaisissables

L'IA nous rend-elle vraiment plus productifs ? C'est une question explosive et controversée ! Si on raisonne à l'envers et qu'on affirme que « l'IA n'a rien changé », je pense que même les plus sceptiques quant à sa valeur ne seraient pas d'accord.

Particulièrement dans les entreprises technologiques, l'explosion de l'utilisation de l'IA est un fait tangible. Même dans les entreprises les plus conservatrices, qui limitent les budgets IA et n'équipent pas leurs employés d'outils IA, on ne peut nier qu'une partie du travail est effectivement faite par l'IA – même si les employés se contentent péniblement d'utiliser Gemini ou Copilot en cachette dans la suite Google ou Microsoft pour éditer des documents.

Quant aux entreprises plus visionnaires, plongées à corps perdu dans l'océan des tokens IA(unité de base utilisée par les modèles de langage pour traiter le texte, les entreprises étant généralement facturées en fonction du nombre de tokens consommés), comme Uber ou Shopify (je n'inclus pas ici les entreprises comme Meta ou Microsoft qui développent leurs propres LLMs, ni Vercel ou Cloudflare qui construisent activement l'infrastructure IA ; seulement les purs « utilisateurs »), leur consommation d'IA est devenue folle.

Nous en avons désormais l'habitude : de 90% à 100% du code généré par l'IA, au nombre de revues de code (PRs/diffs) soumises par semaine qui explose de 2 à 5 fois, en passant par des budgets annuels de l'IA de centaines de millions de dollars consommés en quelques mois.

Cependant, des commentateurs et investisseurs technologiques comme Ed Zitron, Will Manidis, Gary Marcus et Michael Bury vous retourneraient sûrement une question percutante : dans ce cas, pourquoi les revenus de ces entreprises n'ont-ils pas augmenté de 2 à 5 fois ? Pourquoi leurs applications semblent-elles presque identiques à celles d'il y a six mois ? Si l'IA est si productive, qu'ont-ils bien produit avec elle ? S'ils écrivent 5 fois plus de code sans que l'utilisateur final ne s'en aperçoive, à quoi sert ce code ? C'est une question extrêmement incisive et pertinente.

Inputs, Outputs et Outcomes

Faisons une petite parenthèse sur les bases du management d'entreprise. Quand une entreprise en croissance rapide, surfinancée, dépensant à tout va, se retrouve finalement à court de liquidités, vous allez demander conseil à un CEO chevronné. Il vous conseillera de faire appel à des consultants McKinsey. Le consultant commencera sa présentation avec une diapositive entièrement blanche, sur laquelle trois mots seront écrits en Arial par défaut : « Input, Output, Outcome ».

Ils vous expliqueront une vérité commerciale que tout le monde connaît mais oublie souvent :

Le code n'est qu'un input.

La fonctionnalité est l'output.

Ce pour quoi les utilisateurs sont prêts à payer, c'est l'outcome.

L'IA (ou du moins des produits comme Claude Enterprise) est fondamentalement un produit logiciel en tant que service pour les entreprises (B2B SaaS). Vous remarquerez que les produits SaaS sont tarifés et commercialisés différemment. Si un produit peut directement changer l'« outcome », ils factureront généralement un pourcentage sur cet outcome. Imaginez l'argument de vente : « Notre outil vous permet de conclure des leads 36% plus vite. Essayez-le maintenant, pour seulement 5% de frais de service sur vos ventes. »

C'est un argument imparable. Toutes choses égales par ailleurs, si vous concluiez 100 deals en 100 jours auparavant, vous n'en avez plus besoin que de 63. Les 36 jours gagnés (si mon calcul est bon) vous permettent d'en conclure 57 de plus ! Cela représente une augmentation potentielle des ventes de 57%. N'importe qui serait ravi de donner 5% de sa commission pour obtenir 57% de revenus supplémentaires. Et si vous n'utilisez pas le produit, vous ne payez rien.

Vous avez probablement deviné où je veux en venir – le modèle de tarification de Claude basé sur la consommation de tokens n'a rien à voir avec cela. Si vos ingénieurs logiciels sont accros à la programmation avec Claude (je viens de réaliser que les deux ont pour abréviation « cc »), générant 100 millions de tokens par jour, alors vous payez 100 dollars par jour et par ingénieur.

Même si une partie du code généré ne fonctionne pas et finit à la poubelle ;

Même si une partie cause un incident système grave (SEV)(SEV pour Severity, terme couramment utilisé dans les entreprises tech pour désigner un incident en ligne grave entraînant une interruption de service) et doit être annulée en urgence ;

Même si une autre partie ne sert qu'à relooker un outil interne pour que les vice-présidents trouvent le tableau de bord de données plus mignon ;

Vous payez tout. Parce que le code n'est qu'un « input ». Bien qu'en général, plus d'« inputs », dans la bonne direction, mènent souvent à plus d'« outputs », et donc à de meilleurs « outcomes ». Mais lorsque vous multipliez les inputs par 5 du jour au lendemain, cette règle ne s'applique plus nécessairement. Ces inputs supplémentaires peuvent soudainement devenir erratiques, s'éloignant complètement des outputs ou outcomes attendus.

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

Autrefois, chaque fois que le CEO ou le Product Manager (PM) voulait faire 10 choses, l'équipe de développement disait toujours qu'elle ne pouvait faire que les deux plus importantes, les 8 autres n'étant pas faisables faute de temps. La raison ? Parce que coder n'est pas un jeu, développer un logiciel complexe et fonctionnel prend énormément de temps.

Hmm... mais maintenant le code est quasi gratuit. Pourquoi ne faisons-nous toujours pas ces 8 choses restantes ?

La réponse a deux facettes : une que le CEO et le PM n'aiment pas entendre ; et une autre que les managers intermédiaires et les employés seniors n'aiment pas entendre.

1. En fait, ces 8 idées... ne sont-elles tout simplement pas bonnes ?

Le simple fait que le CEO ou le PM ait eu 10 idées ne signifie pas qu'elles se traduiront en résultats commerciaux tangibles. Même si vous livrez réellement 10 nouvelles fonctionnalités (outputs), rien ne garantit que les utilisateurs les adopteront toutes et utiliseront davantage votre app (outcomes).

En réalité, c'était justement la rareté passée des ressources de développement, cette « friction », qui obligeait à des débats plus intenses, permettant d'éliminer tôt les mauvaises idées avant qu'elles ne consomment trop de ressources, et de sélectionner les deux meilleures. Maintenant que coder est rapide et peu coûteux, débattre de la qualité des idées semble dénué de sens. Même si vous essayez de les contredire, pensez-vous pouvoir empêcher le CEO ou le PM de se tourner vers Claude lui-même pour lui soumettre sa demande ? Laissez tomber, n'essayez même pas.

2. Faire « aligner » tout le monde est trop douloureux.

Nous savons tous à quel point c'est pénible. Il faut d'abord obtenir un consensus de toutes les parties prenantes sur le « pourquoi » faire quelque chose ; ensuite, il faut une autre réunion pour discuter de « quoi » faire précisément ; enfin, tout le monde doit encore débattre sur le « comment » le faire.

Plus il y a d'équipes, plus de projets restent coincés dans cet « enfer de l'alignement ». Avant, la lenteur du codage masquait ce problème. Maintenant, c'est pire : une fois que le « quoi » est décidé, quelqu'un peut passer la nuit à coder un Produit Minimum Viable (MVP)(développer au coût le plus bas un produit qui démontre juste l'idée centrale, pour tester rapidement) et organiser immédiatement la réunion suivante le lendemain.

Lors de la réunion, vous découvrez avec stupéfaction qu'une autre équipe a aussi codé un MVP en secret ! Pire, parce que vous partez d'hypothèses différentes, les deux produits fonctionnent selon des logiques diamétralement opposées.

Bien sûr, vous pourriez vous asseoir et discuter pour déterminer quelles hypothèses sont correctes.

Soyons honnêtes. Vous et votre équipe, avec vos tokens Claude illimités, n'avez pas envie de faire ça. L'autre équipe non plus. Vous n'hésiterez pas à vous tourner vers Claude pour qu'il réimplémente le travail de l'autre équipe exactement comme vous le pensez parfait. Et Claude répondra simplement : « Vous avez absolument raison ! », et se mettra immédiatement à coder.

Que résolvent réellement les licenciements ?

D'accord, merci de m'avoir écouté avec patience énumérer ces évidences. Je sais que vous voulez voir le contenu essentiel.

Quel est le but des licenciements ? Selon mon hypothèse, si l'IA ne remplace pas réellement un employé sur un (je pense que nous pouvons être d'accord là-dessus ? Bien qu'elle soit meilleure qu'un employé junior pour de nombreuses tâches, elle est inférieure à l'humain pour d'autres – ce n'est absolument pas une pièce interchangeable, et encore moins capable de remplacer 10%, 20% ou même 30% du personnel d'une entreprise du jour au lendemain).

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.

1. Compenser les « dépenses en IA »

C'est simplement un calcul de trésorerie basique. Il est évident que si vos ingénieurs accros à Claude dépensent 100 dollars par jour sur Claude (soit 2500 dollars par mois, 30 000 dollars par an), cet argent équivaut déjà au salaire complet d'un ingénieur logiciel (SDE) en Inde ; à la moitié d'un SDE en Europe ; et au quart d'un SDE aux États-Unis.

En faisant un calcul simpliste : supposons une entreprise plate où tous les employés sont des SDE. Pour maintenir le même total de masse salariale (incluant les coûts en tokens), vous devez licencier 50% (Inde), 33% (Europe) ou 20% (États-Unis) des effectifs.

En réalité, puisque l'utilisation de l'IA augmente de manière incontrôlable, sans que les revenus de l'entreprise ne suivent, le licenciement devient une nécessité. Sinon, le bilan de l'entreprise s'effondrerait. Si vos coûts d'input augmentent de 50% mais que vos outcomes commerciaux finaux ne bougent pas d'un iota, alors l'économie unitaire de tout votre cycle de développement logiciel est complètement brisée.

Si nous avions vraiment appris à utiliser l'IA – compris comment transformer une augmentation de 50% des coûts d'input en une augmentation de 50% des revenus (outcomes), nous n'en serions pas là. Mais précisément parce que vous ne l'avez pas encore appris, certains d'entre vous doivent faire leurs valises pour libérer de l'argent afin de payer Anthropic.

2. Réduire la « taxe d'alignement »

Il ne fait aucun doute que toute grande entreprise est bien plus grande que ce qui serait nécessaire pour simplement « survivre ». C'est la nature des grandes entreprises, les grandes organisations accumulent fatalement de la « graisse organisationnelle », c'est une conséquence inévitable de leur conception.

Dans ces entreprises, même si quelqu'un part, le système continue de fonctionner car quelqu'un d'autre sait ce qu'il faisait. Dans de nombreuses grandes boîtes, vous pouvez prendre un congé parental de six mois en paix, et votre projet restera intact. Ce sont de bonnes choses ! Mais c'est aussi la preuve formelle : si une partie du personnel est licenciée, l'entreprise ne s'effondrera pas immédiatement. Au contraire, après les premières semaines de douleurs systémiques, les mois suivants pourraient même voir les choses aller plus vite !

Vous souvenez-vous des deux équipes qui s'affrontaient sur des approches techniques différentes ? C'est simple : licenciez l'une des deux équipes, et laissez l'équipe restante faire quelques nuits blanches pour terminer le travail – elles n'auront plus besoin de s'« aligner » avec qui que ce soit.

Nous ne pouvons pas prévoir ce qui se passera à long terme (ou pour citer l'économiste Keynes – « À long terme, nous serons tous morts »), mais à court terme, licencier 10 à 20% du personnel dans une grande entreprise ne fera qu'accélérer le rythme de travail.

Les grandes entreprises accumulent inévitablement avec le temps de la redondance, des postes superflus, comme une dette technique, elles accumulent une « dette organisationnelle ». C'est la maladie des grandes entreprises. Licencier 10% des effectifs aujourd'hui n'empêchera pas la rechute dans deux ans. Mais lorsque vous voyez tout le monde se vanter de soumettre 5 fois plus de code qu'avant, mais être bloqué par une autre équipe pour le déployer, le remède le plus direct et brutal est évidemment : licencier des gens, ainsi plus personne ne se bloquera mutuellement.

C'est cela, les licenciements liés à l'IA, même si l'IA n'a pas pris votre place

Votre poste a-t-il été remplacé par une nouvelle instance de Claude tournant sur une machine virtuelle ? Nous savons tous que ce n'est pas le cas.

Néanmoins, n'est-il pas vrai qu'il y a dans l'entreprise de nombreux flux de travail qui nécessitaient auparavant que vous tapiez du clavier ou cliquiez dans VS Code, Figma, Canva ou Google Docs pour produire quelque chose, mais qui sont maintenant devenus des cas où quelqu'un d'autre (la personne qui avait besoin de ce travail) crie simplement un prompt à un LLM, sans plus jamais prendre la peine de venir vous demander de l'aide ? C'est aussi un fait indéniable.

Ces licenciements relèvent-ils du « blanchiment à l'IA » ? C'est-à-dire – l'entreprise avait-elle déjà des problèmes fondamentaux sans rapport avec l'IA (comme un surrecrutement, une baisse des bénéfices, des pressions concurrentielles, de mauvaises décisions commerciales), et utilise-t-elle maintenant l'IA comme « excuse » pour licencier ? Hmm, dans une certaine mesure, cela tient aussi debout.

Vous pourriez aussi remarquer que si vous rassembliez tous les « emails de licenciement » envoyés par les CEO ces derniers temps, vous pourriez penser qu'ils ont créé un groupe de discussion pour se concerter sur leur rédaction. « Équipe native IA », « Managers qui codent », « Augmenter la portée managériale », « Structure plate », « Gérer des équipes d'agents IA »... Vous verriez ces nouveaux termes apparaître de manière identique dans chaque email. Comme s'ils avaient donné le même prompt à GPT.

Mais la vérité est que, même si ces licenciements ne sont pas dus au remplacement direct par l'IA, même s'ils contiennent une part de « blanchiment à l'IA », ces licenciements sont, en fin de compte, causés par l'IA. Et cette vague de licenciements continuera jusqu'à ce que nous apprenions vraiment à utiliser l'IA.

Jusqu'à ce que nous apprenions à transformer les masses de tokens IA en résultats commerciaux tangibles, et non pas seulement en inputs de code ; jusqu'à ce que nous apprenions à faire en sorte que la vitesse d'« alignement » organisationnel suive la nouvelle vitesse de génération de code ; jusqu'à ce que nous comprenions comment utiliser cette productivité supplémentaire pour poursuivre 10 nouvelles idées pleines de potentiel, au-delà des 2 bonnes idées et 8 mauvaises d'origine.

Avant que nous ne comprenions vraiment comment l'IA stimule la croissance du PIB mondial, pour combler les coûts annuels de tokens qui atteignent 70 milliards de dollars (chiffre d'affaires combiné d'OpenAI et Anthropic auprès des entreprises), les entreprises ne pourront que « rogner Pierre pour payer Paul » en réduisant les salaires.

Et avant que nous n'apprenions à fluidifier plus efficacement les blocages entre équipes, la solution ne sera toujours qu'une seule – nous effacer purement et simplement de l'organigramme.

Il me reste 15 jours pour connaître mon destin. Mais quel qu'il soit, je pense que j'en connais déjà la raison. Même si c'était moi qui prenais la décision dans le grand bureau du CEO au fond, je ne sais pas si je ferais mieux, peut-être que je ferais le même choix que tous les autres CEO qui se concertent.