Meta a redessiné ses équipes avant de mesurer la productivité de bout en bout

Meta a commencé cette année à réorganiser une partie de ses équipes autour d’un futur où les agents prendraient en charge beaucoup plus de travail. Puis la seconde vague de Project OT a été interrompue. Entre les deux, des données internes ont montré un décalage assez spectaculaire entre la quantité de code produite, ce qui arrivait réellement jusqu’aux utilisateurs et le coût des incidents. Pour les cabinets de conseil et les métiers experts, ce décalage mérite qu’on s’y attarde.

Le 19 mai, quelques heures avant une réduction d’environ 10 % de ses effectifs, Mark Zuckerberg a arrêté la préparation d’une seconde vague de restructuration prévue pour novembre.

Le programme s’appelait Project OT, pour Organization Transformation. Lancé en janvier, il devait réduire les coûts mais aussi modifier la manière dont certaines équipes étaient constituées. Meta avait travaillé sur des scénarios où des équipes produit classiques de dix à vingt personnes laisseraient place à de petits groupes de trois à cinq personnes assistées par l’IA. Dans les hypothèses les plus radicales, certaines équipes pouvaient perdre jusqu’à 60 % de leur taille, par licenciements, redéploiements et suppressions de postes ouverts. Meta a confirmé à Reuters l’existence du projet, ces scénarios et son organisation initiale en deux vagues.

Le raccourci serait d’en faire l’histoire d’une entreprise qui a voulu remplacer trop vite ses salariés par l’IA et s’est ravisée. Les faits sont moins simples. Meta n’a pas abandonné son ambition de fonctionner davantage avec des agents. Reuters n’a pas pu déterminer ce qui avait précisément conduit Zuckerberg à interrompre la seconde vague. Début juillet, celui-ci reconnaissait que les agents n’avaient pas progressé aussi vite qu’il l’avait anticipé, tout en disant attendre des améliorations dans les mois suivants.

Ce qui s’est passé chez Meta reste pourtant très instructif. L’entreprise avait commencé à modifier son organisation à partir d’une hypothèse de productivité qui n’était pas encore démontrée à l’échelle du système.

En juin, j’avais essayé de définir ici ce que pouvait être une firme de conseil AI-native. Je la distinguais d’un cabinet qui se contente de donner de meilleurs outils à ses consultants. La différence se trouvait dans le système de production lui-même : contexte, workflows, contrôle, mémoire, responsabilité.

Project OT donne aujourd’hui un cas assez rare pour confronter cette idée à une organisation réelle.

Les trois ensembles de données que je vais utiliser regardent en réalité trois distances différentes. L’expérience BCG mesure principalement ce qui arrive à une personne. L’expérience P&G commence à mesurer ce qui arrive à une équipe. Meta montre ce qui peut se passer lorsqu’on essaie de modifier l’organisation entière. Pour le conseil, il reste encore une distance : celle qui sépare l’équipe du résultat réellement utilisable par le client.

Meta avait déjà dessiné l’équipe d’après

L’« AI-Native Playbook » interne décrit par Reuters allait assez loin. Dans le modèle traditionnel, les rôles restent spécialisés entre ingénieurs, product manager, designer, data scientist ou chercheurs. Le modèle imaginé par Meta regroupait trois ou quatre « builders » sous la direction d’un responsable, avec des spécialistes mutualisés entre plusieurs équipes. Plusieurs couches de management disparaissaient. En juin, au moins onze unités avaient déjà adopté de petites équipes de ce type.

L’hypothèse est compréhensible. Si une personne équipée d’agents peut explorer davantage d’options, produire plus vite un prototype, écrire davantage de code et absorber une partie du travail autrefois réparti entre plusieurs spécialités, l’équipe peut être plus petite. Le coût de coordination baisse en même temps que le coût de production.

C’est probablement l’une des promesses les plus importantes de l’IA pour les entreprises. C’est aussi là que commence le problème.

Les données internes obtenues par Reuters montrent une forte hausse de l’activité technique. Les changements de code sur les plateformes et infrastructures internes avaient progressé de 220 % sur un an. Dans le même temps, les changements conduisant à des fonctionnalités nouvelles ou améliorées arrivant jusqu’aux utilisateurs progressaient de 36 %. Ce ne sont pas les deux extrémités d’un même indicateur et on ne peut pas en déduire un taux de conversion. Une modification d’infrastructure n’a d’ailleurs pas nécessairement vocation à devenir une fonctionnalité visible. L’écart reste difficile à ignorer : ce que Meta mesurait très en amont augmentait beaucoup plus vite que ce qu’elle mesurait beaucoup plus près de l’utilisateur.

D’autres signaux apparaissaient au même moment. Des équipes d’infrastructure alertaient sur des problèmes de fiabilité liés à l’augmentation du code produit avec l’IA. Selon les publications internes vues par Reuters, les incidents techniques et de sécurité majeurs avaient augmenté de 40 % et le temps consacré à les résoudre de 70 %. Meta n’a pas commenté ces chiffres. Ils ne sont pas audités publiquement et Reuters ne dit pas qu’ils ont provoqué la décision de Zuckerberg.

Il serait donc excessif d’en tirer un bilan de Project OT. Mais ces chiffres permettent de voir quelque chose que les benchmarks de productivité montrent mal.

Une organisation ne livre pas ce qui est produit à sa première étape.

Le code doit être intégré, testé, sécurisé, déployé puis maintenu. Une analyse doit être vérifiée, reliée au contexte, confrontée aux autres analyses et transformée en décision. Une présentation doit survivre aux objections du client. Une recommandation doit pouvoir être défendue par celui qui la signe.

Quand l’une de ces étapes devient beaucoup plus rapide, les autres ne disparaissent pas. Elles peuvent même recevoir beaucoup plus de matière qu’avant.

Une entreprise peut alors constater une forte hausse de productivité là où elle regarde en premier, sans retrouver le même gain une fois tout le travail terminé.

Le benchmark s’arrête avant la mission

C’est particulièrement important pour le conseil parce que les gains observés sur les tâches intellectuelles sont, eux, bien réels.

L’expérience réalisée avec Boston Consulting Group et publiée dans Organization Science portait sur 758 consultants. Sur dix-huit tâches situées à l’intérieur de ce que les chercheurs appellent la « jagged frontier » de GPT-4, les consultants équipés de l’IA accomplissaient 12,2 % de tâches supplémentaires, les terminaient 25,1 % plus rapidement et obtenaient de meilleurs résultats qualitatifs.

L’expérience contenait aussi une tâche conçue pour se trouver au-delà des capacités du modèle. Là, l’avantage disparaissait. Les consultants utilisant GPT-4 étaient moins nombreux à parvenir à la bonne réponse, tout en produisant des réponses qui restaient convaincantes dans leur forme. L’expérience utilisait le GPT-4 de 2023, ce qui interdit d’appliquer mécaniquement ses résultats aux modèles actuels. Le résultat principal résiste cependant : la performance varie fortement selon la nature du travail.

Ce papier est souvent utilisé pour montrer que l’IA améliore déjà la productivité des consultants. C’est exact. Il faut simplement regarder ce qui a réellement été mesuré.

Un consultant reçoit une tâche. Il la réalise plus vite ou mieux. La mesure s’arrête là.

Elle ne couvre pas l’ensemble d’une mission. Le temps consacré par un manager à challenger une hypothèse n’apparaît pas. Le coût d’une erreur découverte plus tard non plus. Il n’y a pas de comité de direction à convaincre, de recommandation à mettre en œuvre, de relation client à maintenir pendant six mois, ni de compte de résultat du cabinet à la fin de l’expérience.

Cela ne diminue en rien le résultat. Cela situe l’endroit où il a été obtenu.

Le passage de ce gain à une petite équipe de mission est une autre expérience. Le passage de cette petite équipe à une firme plus rentable en est encore une autre.

Il manque souvent ces deux étapes dans les annonces de productivité.

Une heure gagnée par un consultant peut devenir une heure disponible pour une autre tâche, une heure supplémentaire de contrôle, une heure non facturée, une réduction du staffing ou simplement une soirée plus courte. Toutes ces situations peuvent apparaître dans une organisation qui mesure pourtant le même « temps économisé ».

Le chiffre local ne permet pas de savoir laquelle s’est produite.

P&G montre que l’équipe peut réellement changer

Une autre étude publiée dans Organization Science évite de conclure trop vite dans l’autre sens.

Les chercheurs ont travaillé cette fois avec 791 professionnels de Procter & Gamble sur de vrais problèmes d’innovation produit. Certains travaillaient seuls, d’autres en binôme. Dans chacun de ces deux groupes, une partie avait accès à l’IA et l’autre non.

Le résultat est beaucoup plus intéressant pour l’organisation que la simple mesure d’un gain de vitesse. Une personne seule avec l’IA a obtenu une performance comparable à celle d’une équipe de deux personnes sans IA.

L’outil a aussi modifié la frontière entre métiers. Sans IA, les profils R&D proposaient davantage de solutions techniques et les profils commerciaux davantage de solutions commerciales. Avec l’IA, les propositions devenaient plus équilibrées quel que soit le métier d’origine. Une partie du bénéfice obtenu habituellement en réunissant deux expertises différentes pouvait donc être obtenue par une personne assistée.

On tient ici quelque chose qui ressemble davantage à une transformation de l’équipe. L’IA ne rend pas seulement chacun un peu plus rapide. Elle change ce qu’une seule personne peut couvrir.

La portée reste circonscrite. L’expérience concernait un exercice d’innovation clairement défini, avec un résultat évaluable. Elle ne démontre pas que P&G pourrait diviser par deux ses équipes d’innovation, encore moins son organisation entière. Quatre coauteurs travaillent par ailleurs chez P&G, ce qui mérite d’être signalé même si l’étude est préenregistrée et a été publiée après revue académique.

Mais le cas interdit une conclusion confortable selon laquelle les gains individuels se perdraient nécessairement dès que plusieurs personnes doivent travailler ensemble.

Ils peuvent passer le niveau de l’équipe.

La question est de savoir dans quelles conditions.

Chez P&G, le problème à résoudre était borné. Les participants savaient ce qu’ils devaient produire. Le résultat pouvait être comparé entre les groupes. L’IA intervenait dans une boucle de travail assez courte pour que l’on puisse observer l’effet jusqu’à la sortie.

À l’échelle d’une grande organisation, ces conditions sont beaucoup plus difficiles à maintenir. Les tâches s’enchaînent, leurs critères de qualité ne sont pas toujours explicites et une sortie devient souvent l’entrée du travail de quelqu’un d’autre. Les décisions ont aussi des conséquences qui n’apparaissent que plusieurs semaines ou plusieurs mois plus tard.

Il ne s’agit donc pas de choisir entre l’expérience BCG, l’expérience P&G et le cas Meta. Elles regardent trois distances différentes.

Chez les cabinets, le gain doit encore arriver jusqu’au client

Les métiers experts ajoutent une difficulté particulière. Leur production est rarement la valeur finale.

Un cabinet peut réduire de moitié le temps nécessaire à une recherche sans que le client gagne quoi que ce soit. Il peut produire quatre scénarios au lieu de deux et rendre la décision plus difficile. Il peut aussi utiliser le temps gagné pour tester davantage d’hypothèses et livrer un meilleur travail. Les trois situations ressemblent à un gain de productivité si l’indicateur choisi est le temps de production initial.

Les enquêtes disponibles dans les professional services donnent quelques indices sur ce décalage. Il faut être précis sur leur périmètre. Le rapport 2026 du Thomson Reuters Institute porte surtout sur le droit, la fiscalité, la comptabilité, l’audit, le risque, la fraude et les administrations. Il ne mesure pas directement le conseil en management. Plus de 1 500 professionnels ont répondu. Quarante pour cent disent que leur organisation utilise désormais l’IA générative, contre 22 % un an plus tôt. En revanche, 18 % seulement savent que leur organisation mesure le retour sur investissement de ces outils. Et lorsque ce retour est mesuré, les indicateurs utilisés portent encore largement sur les économies internes et l’usage par les salariés plutôt que sur la satisfaction client ou les revenus.

Un autre rapport du même institut, Future of Professionals 2026, regarde davantage le point de vue des acheteurs. Parmi les clients interrogés, 78 % considèrent les améliorations de qualité permises par l’IA comme très importantes ou essentielles. Seulement 6 % estiment que la majorité de leurs prestataires les leur apportent réellement. Le chiffre reste déclaratif et provient d’un acteur commercial de ces marchés. L’écart mérite néanmoins d’être regardé.

Le problème devient encore plus visible lorsqu’on ajoute le prix.

Dans les cabinets juridiques, 71 % des juristes d’entreprise interrogés par Thomson Reuters s’attendent à ce que les cabinets modifient leur modèle commercial à mesure que l’usage de l’IA augmente. Dans les cabinets, 62 % des professionnels répondent que leur structure tarifaire n’a pas changé. Ces données portent sur le droit, pas sur l’ensemble du conseil. Elles montrent ce qui arrive lorsqu’un métier historiquement facturé sur l’effort commence à réduire l’effort nécessaire à certaines tâches.

Pour un cabinet, gagner du temps n’a donc pas un effet économique univoque.

Sur une mission forfaitaire, une production plus efficace peut améliorer la marge. Sur une mission au temps passé, elle peut réduire le nombre de jours vendus. Si le temps libéré permet de servir davantage de clients, le chiffre d’affaires peut augmenter. Si la vérification absorbe une partie du gain, beaucoup moins. Et lorsque le client connaît lui-même la baisse du coût de production, il cherchera tôt ou tard à en récupérer une part.

C’est probablement pourquoi les chiffres publics des grands cabinets restent si difficiles à interpréter. On voit beaucoup d’utilisateurs, d’agents, de formations, de partenariats technologiques et parfois d’heures économisées. On voit beaucoup moins de données permettant de relier ces annonces à la taille moyenne des équipes, au coût complet d’une mission, aux reprises, à la marge ou à la valeur obtenue par le client.

Cette absence de données ne signifie pas que les gains n’existent pas. Elle signifie que la transformation économique reste difficile à observer de l’extérieur.

Et c’est pourtant à cet endroit que l’expression AI-native prend son sens.

Un cabinet réellement reconstruit autour de l’IA devrait finir par montrer quelque chose dans son système de production. Les équipes devraient pouvoir prendre en charge davantage de travail ou produire une qualité supérieure à coût comparable. La vérification devrait être suffisamment intégrée pour éviter que l’accélération de la génération ne se transforme en accumulation de reprises. Le pricing devrait progressivement refléter autre chose que le nombre de personnes mobilisées.

Sinon, le cabinet a surtout rendu ses consultants plus efficaces.

C’est déjà beaucoup. Ce n’est simplement pas la même transformation.

Quatre tests avant de parler de productivité

On peut donc ramener la question à quatre tests simples. La tâche est-elle plus rapide ? Le livrable complet demande-t-il moins de travail ? Le gain change-t-il l’économie de la mission ? Le client obtient-il un meilleur résultat ?

Ces quatre tests ne mesurent pas la même chose. Pour comparer deux résultats, il faut conserver le même cas d’usage, la même population, la même période et le même point de départ. Puis remesurer le gain à chaque étape.

Avant l’organigramme, regarder où le gain disparaît

Project OT pose donc une question assez différente de celle qui domine encore beaucoup de discussions sur l’IA au travail.

La performance d’un agent ou le temps économisé sur une tâche ne permettent pas de déduire directement la taille de l’équipe qui devrait exister autour.

Entre les deux se trouvent toutes les opérations qui rendent le travail utilisable par quelqu’un d’autre. Dans le logiciel, ce sont notamment les tests, l’intégration, la sécurité et l’exploitation. Dans le conseil, ce sont le contrôle des sources, la cohérence du raisonnement, la revue senior, la confrontation au client puis l’application de la recommandation.

C’est à ces endroits que la mesure devient intéressante.

Si une tâche passe de cinq heures à une heure, il faut encore savoir ce qu’il est advenu des quatre heures. Ont-elles disparu du coût complet ? Ont-elles été consommées plus loin dans le processus ? Ont-elles permis d’augmenter la qualité ? Ont-elles créé davantage de capacité ? Le client en a-t-il récupéré une partie ? Le cabinet en a-t-il gardé une autre dans sa marge ?

Ces questions paraissent moins spectaculaires qu’un chiffre sur le nombre d’agents ou sur la quantité de code générée. Elles disent pourtant beaucoup mieux si une organisation est en train de changer.

Meta avait déjà commencé à dessiner les petites équipes censées correspondre à sa nouvelle capacité de production. L’expérience n’est pas terminée et les agents progresseront encore. Project OT rappelle simplement que l’organigramme constitue une conséquence assez tardive de la productivité.

Avant de réduire l’équipe de dix personnes à cinq, il faut savoir ce qu’il reste du gain une fois le travail réellement terminé.

C’est probablement la mesure que j’aimerais voir apparaître maintenant dans les annonces des cabinets.

Quand vous dites avoir gagné 30 % ou 50 % de productivité grâce à l’IA, combien en reste-t-il au bout de la mission ?